TL;DR
Если попросить LLM отфильтровать 50 резюме или 100 отзывов за один запрос — модель примет другие решения, чем если бы вы показывали каждый объект отдельно. И это не случайный шум, а системный сдвиг: когда среди объектов мало "подходящих" (редкий класс), модель в batch-режиме начинает пропускать больше кандидатов, чем при поштучной проверке. Когда объектов "за" и "против" примерно поровну — наоборот, становится строже.
Боль в том, что вы не заметите этот сдвиг, если смотрите только на итоговую метрику качества. Модель может показывать одинаковый (или даже лучший) общий результат, но при этом половина решений внутри батча поменялась местами — одни ошибки исчезли, зато появились новые, просто в других объектах. А попытка "подсказать" модели заранее: "здесь обычно проходит только 3% кандидатов" — почти не помогает исправить эту предвзятость.
Исследование показывает: если задача критична (например, фильтруете кандидатов на вакансию или отбираете жалобы, требующие реакции), нельзя слепо доверять batch-обработке — нужно сверять результат с поштучной проверкой хотя бы на небольшой выборке, прежде чем полагаться на групповую обработку.
Схема метода (как проверить свою задачу на batch-эффект)
ШАГ 1: Возьми выборку из 15-20 объектов (резюме, тикетов, статей) → отдельный чат
ШАГ 2: Прогони их через LLM ПОШТУЧНО (один объект — один запрос) → зафиксируй решения
ШАГ 3: Прогони ТЕ ЖЕ объекты ОДНИМ запросом (все вместе, батчем) → зафиксируй решения
ШАГ 4: Сравни: сколько решений совпало, сколько поменялось → оцени риск
ШАГ 5: Если совпадений < 90% — используй поштучную обработку для финальной фильтрации
Шаги 2 и 3 — это два отдельных запроса в разных чатах (или один чат, но без "утечки" контекста между режимами).
Пример применения
Задача: HR-менеджер отбирает резюме на узкую техническую вакансию. Из 150 присланных откликов реально подходят человек 10-15 (редкий положительный класс — как раз ситуация, где batch-эффект максимален).
Промпт для проверки (шаг 2, поштучно):
Ты — рекрутер. Вот требования к вакансии: {критерии_вакансии}.
Вот одно резюме:
{текст_резюме}
Оцени: подходит кандидат под требования — да или нет?
Ответь только: "Подходит" или "Не подходит" и одна строка обоснования.
(повторить для каждого резюме из тестовой выборки — 15-20 штук)
Промпт для проверки (шаг 3, батчем):
Ты — рекрутер. Вот требования к вакансии: {критерии_вакансии}.
Вот список резюме кандидатов:
1. {резюме_1}
2. {резюме_2}
...
20. {резюме_20}
Для каждого кандидата укажи: подходит или не подходит под требования.
Формат ответа: номер — решение — короткое обоснование.
Результат: Вы получите два списка решений по одним и тем же 20 резюме. Если это редкая вакансия (мало подходящих), скорее всего в batch-варианте пройдёт больше кандидатов, чем в поштучном — модель "смягчается" в группе. Дальше решаете: доверять батчу для оставшихся 130 резюме или проверять их поштучно, несмотря на то, что это дольше.
Почему это работает
LLM не хранит железный чек-лист критериев в голове и не проверяет каждый объект абсолютно независимо, даже если вы просите именно так. Когда модель видит много объектов в одном контексте, она неявно сравнивает их друг с другом и подстраивает решения так, чтобы получилось что-то похожее на "разумную" пропорцию — как будто ищет баланс, а не строго следует правилу.
Это похоже на эффект, когда человек оценивает 20 работ подряд: если первые десять были слабые, следующая средняя работа вдруг кажется "хорошей" на контрасте. LLM подвержена такому же относительному сравнению внутри одного запроса.
Рычаг управления: размер батча. Меньше объектов в одном запросе → меньше искажение, но выше стоимость и время. Для критичных задач (найм, юридическая проверка, отбор пациентов для исследования) — снижайте размер батча или переходите на поштучную обработку. Для рутинных задач с невысокой ценой ошибки — батч можно оставить, экономия времени оправдана.
Шаблон промпта
Ты выполняешь классификацию списка объектов по критерию: {критерий}.
Вот список объектов:
{список_объектов_с_номерами}
Оцени КАЖДЫЙ объект СТРОГО НЕЗАВИСИМО от других — не сравнивай объекты между собой,
оценивай каждый только по критерию, будто видишь его в первый и единственный раз.
Формат ответа: номер — решение (да/нет) — краткое обоснование.
Это не устраняет эффект полностью (исследование показывает: даже прямая инструкция "оценивай независимо" не была протестирована как решение — авторы проверяли только метаданные о доле нужного класса, и она почти не помогла). Но явное требование "не сравнивай объекты" — логичный шаг, который стоит попробовать и сверить с поштучной проверкой.
🚀 Быстрый старт — вставь в чат:
Мне нужно отфильтровать список объектов ({твоя_задача}) по критерию.
Помоги составить два промпта: один для проверки объектов по одному,
второй — для проверки всех сразу батчем. Задавай вопросы, чтобы уточнить критерии.
[вставить шаблон выше]
LLM спросит про критерий отбора и формат объектов — потому что без этого не собрать точный промпт для сравнения двух режимов.
Ограничения
⚠️ Узкая проверенная область: эксперимент проводился только на задаче отбора научных статей для литературных обзоров, на пяти обзорах и двух моделях. Перенос выводов на резюме, тикеты поддержки или другие задачи — это экстраполяция, а не прямое доказательство.
⚠️ Направление эффекта непредсказуемо: для сильно несбалансированных данных батч делал модель мягче, для сбалансированных — жёстче. Но это наблюдение на одном обзоре с балансом 53%, авторы прямо пишут — это не установленный механизм, а один наблюдаемый случай.
⚠️ Метаданные не спасают: если вы подскажете модели "ожидаемая доля нужных объектов — 5%", это почти не изменит поведение в батч-режиме. Не рассчитывайте на этот приём как на исправление проблемы.
⚠️ Итоговая метрика может обманывать: общий результат (F2-score) может остаться прежним или даже улучшиться, при этом конкретные решения по конкретным объектам сильно поменяются — что означает риск для отдельных кейсов, даже если "в среднем" всё хорошо.
Как исследовали
Исследователи взяли пять обзоров научных статей из готового датасета SESR-Eval — с разной долей "подходящих" статей: от 2,9% до 53%. Каждую статью прогнали через две модели (Llama-3.3-70B и GPT-5-mini) в четырёх режимах: поштучно и батчами по 20 статей, с подсказкой о нужной доле и без неё.
Сравнивали не только итоговую точность, но и сколько конкретных решений поменялось между режимами (Decision Flip Rate) и в какую сторону — модель стала мягче или строже (net shift). Это ключевая деталь дизайна: обычные исследования смотрят только на среднюю метрику, а здесь копнули на уровень отдельных объектов.
Результат удивил авторов: подсказка о нужной доле почти не сработала (у одной модели вообще ноль изменений), а сам факт групповой обработки — сработал очень сильно, причём по-разному в зависимости от того, сколько "положительных" объектов реально в выборке. Это и есть главный вывод — batch-режим нужно оценивать не только по цене, но и по тому, как он меняет логику принятия решений.