LLM-судья выбрал первый ответ только из-за порядка

Команда сравнивает два ответа чат-бота через LLM-судью. В промпте старая версия всегда обозначена A, новая — B. Судья выбирает A в 70% случаев, и отчёт объявляет старую версию лучше. Но если поменять ответы местами, тот же судья опять часто выбирает A. Предпочтение связано с позицией в запросе, а не с содержанием ответа.

Одна пара — два порядка

Для каждого вопроса дайте судье пару A=old, B=new, затем ту же пару A=new, B=old. Сохраняйте не букву A/B, а идентификатор выбранного ответа. Если в обоих порядках победил old, это устойчивое направленное решение. Если в первом судья выбрал A и во втором тоже A, он выбрал разные ответы: пометьте пару как нестабильную. Ничья также должна оставаться ничьёй, а не превращаться при подсчёте в победу новой версии.

Пример журнала для одного вопроса: order1=(old,new), verdict=A; order2=(new,old), verdict=B. В обоих случаях выбран old. Для другой пары A в обоих порядках означает противоречие. Такие пары отдайте человеку или судье с другой рубрикой. Не удаляйте их молча из знаменателя: отдельно показывайте долю устойчивых решений и долю расхождений.

Считайте не только победителя

Отчёт может содержать четыре числа: устойчивые победы новой версии, устойчивые победы старой, устойчивые ничьи и неустойчивые пары. Если неустойчивых много, общий win rate нельзя использовать как единственный гейт релиза. Проверьте, не вызывают ли смещение формат, длина ответа, метки версий или порядок перечисления критериев. Одинаковая рубрика в двух прогонах обязательна; меняется только позиция ответов.

Публикуемые исследования LLM-as-a-judge фиксируют позиционное смещение и используют перестановку как тест. Она выявляет проблему, но не доказывает правильность устойчивого решения: судья может ошибаться одинаково в обоих порядках. Поэтому держите выборку с человеческой разметкой и сравнивайте её с вердиктами. Для пограничных случаев просите разъяснение по конкретным критериям, но оценивайте его отдельно от выбора победителя.

Повторяемость зависит и от параметров самого судьи. Сохраните версию модели, системный промпт, рубрику, настройки генерации и исходные ответы без редактирования. Запускайте оба порядка рядом по времени, чтобы смена версии сервиса не смешалась с перестановкой. Если судья отвечает свободным текстом, парсер вердикта тоже может создавать «позиционный эффект»: метка A встречается в объяснении чаще, чем в итоговом решении. Используйте структурированный итог с отдельным полем победителя и считайте нераспознанные ответы отдельно.

Соседняя задача — калибровка самой рубрики судьи. Порядок ответов проверяйте даже после калибровки: согласие по критериям не гарантирует отсутствие предпочтения позиции.

В платном курсе LLMOps & Evaluation: из песочницы в продакшн вы применяете LLM-based judges, строите тестовые наборы и quality-гейты. Двойной порядок легко включить в такой eval: он покажет, насколько решение судьи устойчиво до того, как метрика попадёт в отчёт о релизе. Откройте программу курса, чтобы собрать весь цикл оценки.

Продолжить на практике

  • LLMOps & Evaluation: из песочницы в продакшн ↗

    Практический курс по LLMOps. Соберёте продакшн-контур для LLM: eval-фреймворк (LangSmith/Ragas/OpenAI Evals), quality-гейты в CI/CD, алёрты на дрейф, монитринг скорости и стоимости, управление промпт-версиями и безопасность. Плюс профессиональные блоки: synthetic data для тестов, LLM-based judges, отчётность для релиз-комитета и runbook’и инцидентов.