Кто проверяет вашего LLM-судью?
Разбирали недавно учебный кейс: один агент пишет статьи для базы знаний по мотивам обращений в саппорт, а LLM-as-a-judge оценивает, можно ли их публиковать.
Одной статье судья поставил 5 из 5. Она уверенно сообщала, что у продукта нет определённой функции. Но документация об этом молчала: правильным действием было направить клиента в поддержку за уточнением.
Оказалось, судья читал только саму статью. Ни документации, ни исходных обращений клиентов он не видел. Откуда ему было знать, что уверенное «нет» взялось из отсутствия информации?
У меня похожие ситуации возникали с проверками кода: агент говорил, что всё готово, а на вопрос «ты это запускал?» отвечал, что нет. В итоге в CLAUDE.md появилось правило:
When I ask you to test something - especially "from the user's / student's POV" - actually RUN and USE the real artifacts the person would touch: execute every skill/command, click through every prototype/link, follow every exercise end-to-end, open every deck/video/file. Do NOT just read, summarize, or reason about them.
После этого стало находиться много проблем, которые до этого оставались незамеченными.
В свежей работе про Interaction-as-a-Judge похожая идея: судье давали не только код приложения, но и запись взаимодействия с ним. Пример требования из статьи: Марио должен побеждать противника, прыгая на него. Судья видит действия и их результат в игре. На их наборах задач это помогало точнее проверять выполнение требований.
У Карпатого в лекции была тоже наглядная иллюстрация: GPT по просьбе изображает Linux-терминал с выводом команд, хотя реального выполнения за этим текстом нет. И если LLM судья видит лишь этот текст, то может принять выполнение за чистую монетку.
Имхо, с судьёй важно так же разбираться: что именно он проверил и на основании чего? Особенно если по его оценкам мы выбираем модель, меняем промпт или разрешаем агенту самому себя улучшать.
Anthropic в своём прошлогоднем гайде по эвалам тоже рекомендует проверять самого проверяющего: калибровать LLM-судей по оценкам экспертов и разбирать расхождения, в том числе случаи, когда судья бракует корректное решение. Вот с чего можно начать аудит своего судьи:
- Взять реальные результаты агента и разметить вслепую: скрыть названия моделей и версий, не смотреть на вердикты судьи. Зафиксировать, что принимаем, что отклоняем и почему. Если не хватает знаний предметной области, здесь нужен человек, у которого они есть
- Сопоставить решения. Где судья пропускает плохой результат, а где бракует хороший? Посмотреть отдельно на разные типы задач и ошибок: например, статьи, для которых в документации есть ответ, и те, где его нет. Общая высокая оценка может скрывать провал именно во второй группе
- Разобрать расхождения. Судье не хватило источников? Критерий был размыт? Он принял отчёт агента о проверке за свидетельство её выполнения? Или мы сами только на примере поняли, что хотим считать хорошим результатом?
- Поправить проверку и испытать её на других случаях. Если исправлять судью и проверять улучшение на одних и тех же примерах, легко подогнать его под знакомые ответы
На AI Product Engineer Vol.2, стартующем в выходные, этому как раз посвящена отдельная сессия: аудит судьи по ручной разметке, поиск слепых зон и повторная оценка решения, которое мы раньше приняли по его вердиктам. Возможно, «лучшая» модель или архитектура после такой проверки окажется уже не лучшей.