"Кто проверяет вашего 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-судей по оценкам экспертов и разбирать расхождения, в том числе случаи, когда судья бракует корректное решение. Вот с чего можно начать аудит своего судьи: 1. Взять реальные результаты агента и разметить вслепую: скрыть названия моделей и версий, не смотреть на вердикты судьи. Зафиксировать, что принимаем, что отклоняем и почему. Если не хватает знаний предметной области, здесь нужен человек, у которого они есть. 2. Сопоставить решения. Где судья пропускает плохой результат, а где бракует хороший? Посмотреть отдельно на разные типы задач и ошибок: например, статьи, для которых в документации есть ответ, и те, где его нет. Общая высокая оценка может скрывать провал именно во второй группе. 3. Разобрать расхождения. Судье не хватило источников? Критерий был размыт? Он принял отчёт агента о проверке за свидетельство её выполнения? Или мы сами только на примере поняли, что хотим считать хорошим результатом? 4. Поправить проверку и испытать её на других случаях. Если исправлять судью и проверять улучшение на одних и тех же примерах, легко подогнать его под знакомые ответы. Кстати, одно из лучших пособий по тому, как разбирать ошибки моделей, вышедшее еще до эры chatgpt - Andrew Ng-овское Machine Learning Yearning. Идеи и подходы актуальны и сейчас На AI Product Engineer Vol.2, стартующем в выходные, этому как раз посвящена отдельная сессия: аудит судьи по ручной разметке, поиск слепых зон и повторная оценка решения, которое мы раньше приняли по его вердиктам. Возможно, «лучшая» модель или архитектура после такой проверки окажется уже не лучшей."