Стратегии пакетной обработки (Batch API)

Суть

Batch API: экономия 50%, но окно до 24 часов, без гарантии задержки (SLA) и без многоходового вызова инструментов. Расчёт частоты подачи: требуемая частота = дедлайн SLA − максимальное время обработки пакета (24ч).

Когда не подходит и восстановление

Batch непригоден для любого блокирующего процесса с SLA менее 24 часов. При сбоях используйте custom_id: переотправляйте только упавшие документы, а не весь пакет (иначе перерасход в десятки раз).

Восстановление пакета по custom_id

// Каждый запрос помечен уникальным custom_id.
results := client.Batches.Results(batchID)

var failedIDs []string
for _, r := range results {
	if r.Result.Type == "errored" {
		failedIDs = append(failedIDs, r.CustomID)
	}
}

// Переотправляем ТОЛЬКО упавшие документы, не весь пакет.
var resubmit []BatchRequest
for _, cid := range failedIDs {
	resubmit = append(resubmit, requestsByID[cid])
}
client.Batches.Create(resubmit)

Anti-patterns

Ловушка	Почему не работает	Верный паттерн
Batch для блокирующей pre-merge проверки, которую ждут	До 24ч — разработчики не могут ждать неограниченно	Синхронный API для блокирующего; batch — для неблокирующего
Batch для агентного извлечения с вызовом инструментов по ходу	Batch не поддерживает многоходовой вызов инструментов	Синхронный API для tool-calling; batch — для одноходового
Переотправлять весь пакет при сбое нескольких документов	Переобработка успешных — перерасход в 50 раз	По `custom_id` переотправлять только упавшие

Exam traps

Ловушка	Почему не работает	Верный паттерн
Batch для блокирующих процессов	Нарушает гарантии задержки	Синхронный API
Batch для многоходового вызова инструментов	Не поддерживается	Синхронный API
Полная переотправка пакета при частичном сбое	Неэффективно по стоимости	`custom_id` для точечной переотправки

Практическое задание (T5)

Подать пакет из 50 документов с уникальным custom_id на каждый; проверить сопоставление результатов.
Включить 3 негабаритных документа сверх лимита контекста; реализовать переотправку с дроблением только для них.
Рассчитать частоту подачи для SLA 30 часов при окне пакета 24ч (ответ: каждые 6 часов).
Прогнать выборку из 10 документов до пакета на 50; найти и починить пробелы; измерить рост успеха с первого раза.
Составить матрицу решения: какие 3 вопроса определяют batch vs синхронный API.

Проверка знаний

Извлечение структурированных данных

Система обработки документов с SLA 36 часов; документы поступают непрерывно; команда хочет Batch API (обработка до 24 часов). Как часто подавать пакеты?

A Каждые 24 часа — пакеты завершаются за 24ч, укладываясь в SLA 36ч
B Каждые 36 часов — всё окно SLA как максимальный интервал подачи
C Каждые 12 часов — документ подаётся в течение 12ч, значит 24ч пакета + 12ч подачи = ≤36ч SLA
D Batch непригоден — окно 24ч делает любой SLA меньше 24ч невозможным

Агент разрешения обращений поддержки

Конвейер обрабатывает 10 000 тикетов/день при SLA 36 часов; сквозная задержка пакета 24 часа; пакет запускается ежедневно в полночь. Тикет приходит в 23:58. Сколько буфера остаётся после завершения обработки до дедлайна SLA?

A 36 часов
B 24 часа
C 12 часов
D 0 часов

Агент разрешения обращений поддержки

Один пакетный запрос на 10 000 дневных тикетов; иногда весь пакет падает из-за единственного некорректного тикета, требуя полного перезапуска. Что сделать?

A Добавить логику повтора, переотправляющую весь пакет при любом сбое
B Обрабатывать пакетами поменьше (по 100), чтобы один сбой затрагивал лишь свой пакет
C Добавить валидацию входа до подачи, чтобы ловить некорректные тикеты
D Использовать dead-letter queue для отдельной маршрутизации упавших тикетов