Прибыль:
- Определяет, для каких рабочих нагрузок подходит пакетная обработка.
- Понимает компромисс между стоимостью и задержкой между синхронной, асинхронной и пакетной обработкой.
- Разрабатывает надежный пакетный рабочий процесс, который сопоставляет custom_id с результатами.
Большинство интеграций LLM ориентированы на «живые» сценарии, когда пользователь ждет ответа перед экраном. Но большинство профессиональных задач на самом деле не выполняются в реальном времени: маркировка тысяч документов в одночасье, обобщение всего набора данных, классификация всех записей разговоров в архиве. В этих вопросах никто не ожидает мгновенного ответа; Главное – выполнить работу дешево и надежно. Пакетная обработка предназначена именно для этих рабочих нагрузок. В этом модуле вы узнаете разницу между синхронной, асинхронной и пакетной обработкой, когда пакетная обработка является правильным выбором, а также надежный поток, который уверенно сопоставляет custom_id и результаты.
Три режима работы
режим
Как это работает
задержка
Типичная стоимость
подходящая работа
синхронный
Вы делаете запрос и ждете ответа
секунды
Стандартный
Живой чат, мгновенный помощник
асинхронный
Вы ставите задание в очередь и получаете уведомление, когда оно будет завершено.
Секунды–минуты
Стандартный
Фоновые задачи, этапы автоматизации
Пакетный
Отправляет тысячи запросов в одном пакете, затем получает результаты
Минуты–часы
Обычно со скидкой
Высокообъемные задания с устойчивостью к задержкам
Пакетная обработка заключается в следующем: вы отправляете провайдеру сотни/тысячи запросов как одно «задание»; Поставщик обрабатывает их в своем собственном темпе и возвращает все результаты сразу после завершения. Взамен вы получаете две вещи: (1) как правило, более низкую стоимость единицы продукции, (2) возможность перемещать большие объемы без необходимости иметь дело с ограничениями скорости. Цена в том, что результаты приходят не мгновенно, а через некоторое время.
Когда группировать, а когда нет?
Решение сводится к одному вопросу: ждет ли пользователь результата сейчас?
- Нет, могу подержать → кандидат в партию. Ночная маркировка, обобщение партий, классификация архивов, обогащение данных, выполнение оценки.
- Да, ожидаю на экране → синхронизировать. Живой чат, мгновенная консультация, помощь при заполнении форм.
Совет: В одном изделии могут сосуществовать два режима. Пользователь работает синхронно в чате; Ночью все разговоры этого дня отдаешь в пакет для качественного анализа. Отделить «живую потребность» от «коллективной потребности» — первое решение архитектуры.
Анатомия надежного пакетного процесса
Наиболее важным техническим правилом пакетной обработки является сопоставление результатов.
- Присвойте каждому запросу уникальный «custom_id». Это созданный вами идентификатор, идентифицирующий запрос (например, счет-2026-07-18-000431).
- Отправьте работу. Все запросы идут одним пакетом; каждый со своим собственным custom_id.
- Опросите ситуацию. Вы запрашиваете статус через определенные промежутки времени, пока работа не будет «выполнена».
- Сопоставьте результаты с «custom_id». Результаты могут быть возвращены в порядке, отличном от порядка отправки; поэтому никогда не сопоставляйте по положению, а по custom_id, который несет каждый результат.
- Проверьте тип каждого результата. Один запрос может быть успешным, другой — неудачным, срок действия одного может истечь. Процесс, основанный на успехе/неуспехе.
{ "requests": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Классифицировать счет. Возвращать только JSON.", "messages": [{ "role": "user", "content": "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Классифицировать счет. Возвращать только JSON.", "messages": [{ "role": "user", "content": "{{invoice_text_2}}" }] } } ]}
Внимание: сопоставление результатов на основе порядка отправки — ошибка номер один при пакетной обработке. Очередь не сохраняется. Без custom_id вы не можете с уверенностью знать, какой результат к какому документу принадлежит — неправильное сопоставление незаметно приводит к неправильным данным.
Копируемые шаблоны
# Правило генерации custom_id (уникальное и отслеживаемое) Формат: <isture>-<date>-<sequence>. Пример: запрос-20260718-000431Правило: никогда не повторять в работе; Вставьте в него идентификатор записи ресурса.
# Карточка пакетного задания (шаблон планирования) Имя задания: .............Количество записей: .............Модель: ............. (простое задание → быстрая модель)Макс. токенов на запрос: .............Ожидаемый допуск времени доставки: ......... часов Ключ сопоставления результата: custom_idВ случае ошибки: повторите попытку/очередь/отчет
# Пакетный запрос с одним запросом (кратко и схематично). Классифицируйте этот документ. Просто верните этот JSON, прокомментировав: {"category":"...","срочность":"low|medium|high"}Document: """{{document}}"""
# Псевдокод обработки результатов для каждого результата: if result.status == "success": Record = find(custom_id) save(record, result.output) иначе: add_to_fail(custom_id, result.error) # затем повторите попытку
Слабая подсказка/Сильная подсказка (проектирование пакетного задания)
# WEAK (хрупкая конструкция) Отправьте 10 000 документов по порядку с помощью сильной модели, сохраните возвращенные результаты в том порядке, в котором они поступили.
# НАДЕЖНОСТЬ (надежная конструкция) Отправляйте 10 000 документов за один пакет с помощью быстрой модели. Присвойте каждому документу уникальный custom_id, содержащий идентификатор исходной записи. Сопоставьте результаты с custom_id; поставьте в очередь неудачные и повторите попытку. Запускайте в ночном окне; Срок доставки 6 часов.
Мощная версия; Он заранее определяет выбор модели, ключ сопоставления, обработку ошибок и время. В этом и заключается разница в безопасной обработке десятков тысяч записей.
Три мини-кейса
Случай 1 — Ночное мечение. Команда электронной коммерции рассортировала 200 000 обзоров продуктов по тегам настроений. Синхронная потоковая передача в реальном времени имела ограничения скорости и была дорогостоящей. Работу несли до поздней ночи партиями с быстрой моделью; Стоимость единицы снизилась, весь комплект был готов уже утром, проблем с ограничением скорости не возникло.
Случай 2 — Путаница заказов. Исследовательская группа отобрала 5000 статей, но записала результаты в файлы в том порядке, в котором они поступили. Поскольку результаты были возвращены в другом порядке, примерно 900 из 5000 тезисов были связаны с неправильной статьей. Они переназначили его на custom_id; проблема решена, и этот опыт стал постоянным правилом: «Всегда custom_id в пакете».
Случай 3 — Живой режим ожидания в неправильном режиме. Служба поддержки попыталась дать пакетные ответы, которые пользователь ожидал на экране; Пользователи отказались, потому что результаты пришли через несколько минут. Они вернули живое задание обратно в режим синхронизации, оставив в пакете только ночной анализ качества. Урок: пакетная обработка не предназначена для режима ожидания.
Распространенные ошибки
- Результаты сопоставления по позиции: Порядок не сохраняется; Используйте custom_id.
- Перенос текущего задания в пакет: пользователь не может ждать несколько минут; Пакетная обработка предназначена для заданий, терпимых к задержкам.
- Не обрабатываются случаи ошибок: некоторые запросы могут возвращать сообщение об ошибке или срок действия истек; Поместите его в отдельную очередь и повторите попытку.
- Сильный рефлекс использования модели в пакетном режиме: быстрая модель + пакетная обработка — самая дешевая комбинация в простых заданиях.
- Невозможность отслеживания custom_id: если в идентификатор не встроена исходная запись, становится сложно связать результат обратно.
- Забывание изучить ситуацию: Ожидание результатов до завершения работы; Проверьте статус завершения.
Глубже: мониторинг партии и управление частичными сбоями
Самый зрелый аспект пакетной обработки заключается в том, что она требует иного мышления, чем отдельные вызовы: пакетное задание — это «процесс», а не «событие». Предполагать, что десятки тысяч запросов будут успешными, хрупко; Реалистичный дизайн с самого начала допускает частичные неудачи. Статус каждого результата может быть разным: успешный, неудачный (например, неверный ввод), отменен или срок действия истек. Надежный поток обрабатывает состояние каждого результата отдельно по мере его прохождения, помещает сбои в отдельную «очередь повторов» и запускает эту очередь отдельно.
Второй подход заключается в разработке с учетом идемпотентности (когда выполнение одного и того же задания дважды не причинит никакого вреда). Если пакет прерван и вы его перезапускаете, не следует повторно обрабатывать и записывать дважды уже обработанные записи. Привязка custom_id к исходной записи работает и здесь: «Эта запись уже обработана?» перед сохранением результата. Проверка предотвращает двойной ввод.
Третий момент — чередовать прямые трансляции с пакетной передачей. Некоторые задания имеют как текущие, так и пакетные измерения: когда пользователь загружает документ, вы предоставляете ему быструю предварительную сводку (синхронно) и повторно обрабатываете тот же документ для более глубокого анализа ночью (пакетно). Сознательное разделение этих двух режимов оптимизирует как удобство использования, так и затраты.
Наконец, пакетная обработка также является способом борьбы с ограничениями скорости (раздел 8). Отправка большого объема в реальном времени в синхронном потоке дает константу 429, в то время как отправка того же объема в пакетную передачу ограничивает нагрузку на собственное планирование поставщика и делает работу более предсказуемой.
В итоге
Пакетная обработка, как правило, является более дешевым и надежным режимом для устойчивых к задержкам и больших объемов рабочих нагрузок. Его решение было: «Ждет ли пользователь результата сейчас?» определяет вопрос. Наиболее важным техническим правилом является присвоение каждому запросу уникального custom_id, сопоставление результатов по идентификатору, а не по местоположению, и обработка успеха/неудачи каждого результата отдельно.
Задача приложения
Выберите объемную работу (например, классификацию архива). (1) Определите, живое это произведение или коллективное, и обоснуйте его. (2) Создайте формат custom_id (включая запись ресурса). (3) Заполните карточку пакетного задания (модель, max_tokens, допуск, политика ошибок). (4) Напишите псевдокод обработки результатов, включающий невыполненные запросы.
контрольный список
- [ ] Я могу различать синхронный, асинхронный и пакетный режимы на оси стоимость/задержка.
- [ ] Я могу решить, подходит ли работа для пакетной обработки, задав правильный вопрос.
- [ ] Я присваиваю каждому запросу уникальный custom_id и сопоставляю результаты по идентификатору.
- [ ] Я могу обрабатывать неудачные/просроченные результаты отдельно.
- [ ] Я знаю преимущества выбора быстрой модели при выполнении простых пакетных заданий.