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’и инцидентов.
