Прибуток:
- Визначає, для яких робочих навантажень підходить пакетна обробка
- Розуміє співвідношення вартості/затримки між синхронною, асинхронною та пакетною обробкою
- Створює надійний пакетний робочий процес, який відповідає custom_id результатам
Більшість інтеграцій LLM зосереджені на «живих» сценаріях, коли користувач чекає на відповідь перед екраном. Але більшість професійних завдань насправді не працюють: додавання тегів до тисяч документів за одну ніч, узагальнення цілого набору даних, класифікація всіх записів дзвінків в архіві. У цих питаннях ніхто не очікує миттєвої відповіді; Головне – зробити роботу дешево та надійно. Пакет саме для таких навантажень. У цьому розділі ви дізнаєтесь про різницю між синхронною, асинхронною та пакетною обробкою, коли пакетна є правильним вибором, і надійний потік, який впевнено відповідає custom_id і результатам.
Три режими роботи
режим
Як це працює
затримка
Типова вартість
підходяща робота
синхронний
Ви робите запит і чекаєте на відповідь
секунд
Стандартний
Живий чат, миттєвий помічник
асинхронний
Ви ставите завдання в чергу та отримуєте сповіщення, коли воно буде завершено.
Секунди–хвилини
Стандартний
Фонові завдання, етапи автоматизації
партія
Надсилає тисячі запитів одним пакетом, а потім отримує результати
Хвилини–години
Зазвичай зі знижкою
Роботи великого обсягу, стійкі до затримок
Пакетна обробка полягає в наступному: ви надсилаєте сотні/тисячі запитів як одне «завдання» постачальнику; Постачальник обробляє їх у власному темпі та повертає всі результати масово після завершення. Натомість ви отримуєте дві речі: (1) загалом нижчу вартість одиниці, (2) можливість переміщати великий обсяг без необхідності мати справу з обмеженнями швидкості. Ціна в тому, що результати приходять не миттєво, а через деякий час.
Коли робити пакети, коли ні?
Рішення зводиться до одного питання: чи чекає користувач зараз на результат?
- Ні, я можу тримати → пакетний кандидат. Нічне тегування, підсумовування пакетів, класифікація архіву, збагачення даних, виконання оцінки (eval).
- Так, очікування на екрані → синхронізація. Живий чат, миттєва консультація, допомога при заповненні форм.
Порада: в одному продукті можуть співіснувати два режими. Користувач працює синхронно в чаті; Вночі ви віддаєте всі розмови цього дня в пакет для якісного аналізу. Відокремлення «життєвої потреби» від «колективної потреби» є першим рішенням архітектури.
Анатомія надійного пакетного потоку
Найважливішим технічним правилом пакетної обробки є відповідність результатів.
- Надайте кожному запиту унікальний `custom_id`. Це створений вами ідентифікатор, який ідентифікує запит (наприклад, invoice-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>. Приклад: request-20260718-000431Правило: ніколи не повторювати в роботі; Вставте в нього ідентифікатор запису ресурсу.
# Картка пакетного завдання (шаблон планування) Назва завдання: .............Кількість записів: .............Модель: ............. (просте завдання → швидка модель)Макс_токенів на запит: .............Очікуваний час доставки: ......... годин Ключ відповідності результату: custom_idУ разі помилки: повторна спроба / черга / звіт
# Запит на один пакет у групі (короткий і схематичний) Класифікуйте цей документ. Просто поверніть цей JSON, коментуючи:{"category":"...","urency":"low|medium|high"}Документ: """{{document}}"""
# Псевдокод обробки результату для кожного результату: if result.status == "success": record = find(custom_id) save(record, result.output) в іншому випадку: add_to_fail(custom_id, result.error) # потім повторіть спробу
Слабка підказка / Сильна підказка (пакетний дизайн завдання)
# СЛАБКИЙ (тендітний дизайн) Надішліть 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 і порівнюю результати за ідентифікатором.
- [ ] Я можу окремо обробляти невдалі/прострочені результати.
- [ ] Я знаю переваги вибору швидкої моделі в простих серійних роботах.