Как обработать несколько независимых запросов через LangChain model.batch

1. Подготовьте список независимых входов и ID, чтобы связать каждый ответ с конкретной задачей.
2. Проверьте один prompt через invoke и поведение модели при пустом исходном тексте.
3. Вызовите batch с небольшим max_concurrency, например 2, и сравните длину результатов с числом входов.
4. Если нужны ответы по мере готовности, используйте batch_as_completed и восстанавливайте соответствие по index.
5. Сохраните ошибки по отдельным входам, не публикуйте частичную обработку как полностью завершённую.

Пример ниже предназначен для демонстрационного окружения: установите соответствующий пакет интеграции, настройте ключ через секреты сервера и убедитесь, что модель доступна вашему аккаунту. Если доступ к указанному model ID отсутствует, выберите поддерживаемую модель со сходными возможностями и заново проверьте работу именно на ней. Ни один пример не содержит действующего API-ключа и не разрешает обход ограничений провайдера.

Готовый шаблон на Python

from langchain.chat_models import init_chat_model

# Важно: ключ провайдера задаётся в окружении процесса.
model = init_chat_model("openai:gpt-5.5")
inputs = ["Сжато объясни embeddings.",
          "Сжато объясни RAG.",
          "Сжато объясни reranking."]
answers = model.batch(inputs, config={"max_concurrency": 2})
assert len(answers) == len(inputs)
for original, answer in zip(inputs, answers):
    print(original, "=>", answer.content)

Конкретные входные и ожидаемые данные

Вход: три самостоятельных русских вопроса об embeddings, RAG и reranking. Ожидается ровно три ответа, каждый соответствует исходному вопросу по индексу; фактический текст зависит от модели. Если второй вызов отказал по квоте, обработка должна сообщить о неполном результате, а не поставить ответ третьего вопроса на его место.

Оценивать стоит не красоту формулировки, а проверяемое выполнение задачи. Сохраните исходный текст, ID пользователя или теста и ожидаемое значение отдельно от ответа модели. Если пример выдаёт неверный факт, разберите данные на входе и состояние инструмента до изменения промпта: иначе можно замаскировать ошибку инфраструктуры удачной перефразировкой.

Диагностика и границы решения

Используйте batch только для независимых задач: если ответ второго вопроса зависит от первого, параллельное исполнение меняет смысл работы. Для отчёта или SEO-черновиков присваивайте каждому входу собственный stable ID, чтобы при повторном запуске не перемешать ответы. В отличие от фонового batch endpoint провайдера, model.batch отправляет вызовы из текущего приложения; ограничение max_concurrency защищает от локального штормового старта, но не гарантирует, что провайдер примет всю нагрузку. Следите за rate limits и задержкой. При использовании batch_as_completed индекс обязателен: ответы прибывают в порядке завершения, который нельзя объявить исходным порядком. Для медленного вопроса не держите отображение остальных, если задача допускает прогресс; однако финальное сохранение пакета должно учитывать статусы всех элементов. Затраты могут расти вместе с числом вызовов, даже если стена времени уменьшается; не обещайте скидку из-за параллелизма. Формируйте логи по ID, индексу, модели, status и длине ответа, исключая персональные тексты, если они не нужны для диагностики.

Контрольный эксперимент

Для измерения начните с трёх входов и max_concurrency=1, затем 2 на том же наборе и аккаунте. Запишите число ошибок, p95 и общее время выполнения, а также корректность сопоставления input/output. Если скорость упала или участились 429, повышать параллельность дальше нельзя без пересмотра квот. Повторяйте только ошибки, которые безопасно повторять: у чисто текстовой генерации последствия иные, чем у агента, который создаёт запись в CRM. batch_as_completed полезен для UI прогресса, но каждый ответ помечайте исходным ID до отображения. В контентном pipeline проверяйте смысл каждого результата, потому что успешный объект AIMessage не удостоверяет правильность технического факта. Наконец, держите тест с двумя почти одинаковыми вопросами, чтобы выявить ошибку индексации ответов, не заметную на разнородных темах.

Дополнительный проверочный сценарий

В массовой обработке полезно разделять валидность ответа и его соответствие входу. Сохраните input_id, исходный вопрос, status, результат, версию модели и время каждого элемента. Не склеивайте три результата в один текстовый blob: повторная проверка отдельного ответа станет невозможной. Для ошибочного элемента можно сделать ограниченный повтор с тем же ID, сохранив первую ошибку для анализа; нельзя тихо заменить его ответом другого вопроса. Контролируйте и длину каждого входа: один огромный документ может исчерпать контекст и испортить всю ожидаемую структуру работы. Если эти запросы содержат личные данные разных пользователей, не отправляйте их вместе без изоляции прав и согласованного режима хранения у провайдера.