Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Качество автоматической проверки ответов LLM сильнее зависит от показанного оценщику материала, чем от выбора самого оценщика. Nitish Kumar, Prateik Pothuneedi и Greg Bandak получили этот результат на трёх моделях с разницей в цене в 10–17 раз; работа не прошла рецензирование, а числа получили сами авторы. Если отзыв оценщика запускает исправление ответа, неполный контекст может опустить систему ниже исходного качества.
Без обязательного контекста обратная связь ухудшает ответ
Модель-оценщик — это LLM, которая проверяет чужой ответ и выдаёт замечания или оценку. На практике такой отчёт часто не заканчивает процесс: другая модель получает его и переписывает ответ, система выбирает лучший вариант или автоматически запускает следующую попытку.
В работе меняли только материал, который видит оценщик. Проверка охватывала семь публичных бенчмарков с задачами на соблюдение инструкций, ответы на вопросы, пересказ новостей и сверку текста с источником.
Когда оценщик не видел материал, требования которого нужно было соблюдать, исправленные ответы оказались хуже исходных. В задачах на соблюдение инструкций качество продолжало падать с каждым раундом. Эффект сохранился и тогда, когда оценщик видел запрос пользователя, но не видел ограничений, а также при переходе к другому семейству моделей.
Это разделяет два вида контекста, которые легко спутать при проектировании системы. Запрос объясняет, что нужно сделать, а ограничения задают границы допустимого ответа. Оценщик, которому передали только запрос, может дать убедительный отзыв, но направить исправление в сторону, запрещённую исходными условиями.
Поскольку материал подготовлен по абстракту, а не по полному тексту, из него нельзя восстановить названия бенчмарков, точную схему выдачи контекста и конкретные значения метрик. Большинство количественных предсказаний исходной теории при этом не подтвердилось, поэтому практический вывод опирается на измеренные эффекты, а не на всю предложенную авторами модель.
Эталонный ответ помогает только в подходящей задаче
Добавление правильного эталона дало противоположные результаты в разных типах задач. В вопросах с единственным правильным ответом эталон помог оценщику. При пересказе новостей правильная эталонная сводка рядом с исходной новостью, напротив, свела на нет большую часть пользы от самого источника.
Значит, эталон нельзя считать универсальной заменой исходному материалу. Для короткого фактического ответа он задаёт ясную точку сравнения. При пересказе оценщик должен сверять не только сходство с готовым вариантом, но и то, какие факты содержатся в источнике, что пропущено и не добавилось ли неподтверждённое утверждение.
Передавать весь документ тоже нужно не всегда. Около одной десятой исходного материала обеспечило почти всю пользу контекста. Абстракт не уточняет, как именно выбирали этот фрагмент, поэтому результат показывает потенциал отбора, но не даёт готового алгоритма сжатия.
Для текста, который должен опираться на источник, небольшой граф логического следования находил ошибки на уровне LLM-оценщика. Такой граф связывает утверждения с тем, что должно следовать из исходного материала. Это даёт основание тестировать структурную проверку там, где не нужен свободный разбор стиля или сложной инструкции.
Как это меняет планы команд
Работа меняет порядок проектирования контура проверки. Начинать стоит не с выбора более дорогой модели, а с договора о контексте: какие исходные документы, ограничения, эталоны и части запроса оценщик получает для каждого типа задачи.
Этот договор лучше проверять удалением отдельных элементов. Если без ограничения или источника оценщик продолжает выставлять похожие оценки, это ещё не доказывает устойчивость системы: важнее проверить, улучшают ли его замечания следующий ответ. Исследование показывает, что оценка может выглядеть пригодной, пока цикл исправления уже уводит качество ниже начального уровня.
Для автоматического исправления нужен отдельный предохранитель: каждую новую версию сравнивают с исходной по тем же требованиям, которые видел оценщик. Если система проводит несколько раундов, проверку повторяют после каждого, поскольку ошибка обратной связи может накапливаться.
Эталонные ответы следует подключать по типам задач, а не общей настройкой для всего продукта. В фактических вопросах они могут помочь, но в пересказе или проверке текста по документу оценщику нужен сам источник. Если контекст велик, можно отдельно проверить отбор релевантного фрагмента, не предполагая заранее, что краткая выжимка сохранит нужные ограничения.
Выбор модели и стоимость API переходят на следующий этап. Сначала команда фиксирует достаточный контекст и проверяет, что обратная связь действительно улучшает результат. Затем можно сравнивать оценщиков на одинаковом наборе входных материалов: иначе цена модели маскирует ошибку в архитектуре проверки.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
