LLM-судье нельзя верить на слово: как построить надёжный гейт и проверить сами тесты
LLM-судьи всё чаще используются для автоматической оценки качества ответов языковых моделей: они быстрее человека и дешевле. Но доверять им на слово опасно — галлюцинации, предвзятость и нестабильность делают такие оценки ненадёжными. В этой статье мы разберём архитектурный паттерн, который позволяе

LLM-судьи всё чаще используются для автоматической оценки качества ответов языковых моделей: они быстрее человека и дешевле. Но доверять им на слово опасно — галлюцинации, предвзятость и нестабильность делают такие оценки ненадёжными. В этой статье мы разберём архитектурный паттерн, который позволяет построить безопасный гейт для LLM-судей и проверить сами тесты на корректность. Вы узнаете, как двухконтурная система с правом вето и CI-инварианты помогают отлавливать ошибки до того, как они повлияют на результат.
Двухконтурная система оценки с правом вето
Ключевая идея — не полагаться только на LLM-судью, а добавить второй контур: классическую нормализацию, которая имеет право вето. LLM-судья выдаёт оценку, но если она противоречит формальным критериям (например, длина ответа, наличие ключевых слов, синтаксическая корректность), нормализация блокирует результат и отправляет задачу на ручную проверку. Это снижает риск ложноположительных решений, когда LLM хвалит явно неверный ответ.
Первый контур — это сама языковая модель, которая оценивает ответы на основе промпта. Второй контур — набор правил, написанных человеком. Эти правила могут включать проверку длины текста, наличие обязательных терминов, соответствие формату (например, JSON или Markdown). Если LLM-судья ставит высокую оценку ответу, который не соответствует минимальным требованиям, нормализатор блокирует эту оценку и помечает случай для ручного анализа. Такой подход особенно полезен в production-системах, где цена ошибки высока.
CI-инварианты: как ловить галлюцинации с помощью враждебных фикстур
Для автоматической проверки самих тестов автор предлагает использовать grounded-judge-gate — инструмент, который встраивается в CI/CD и запускает враждебные фикстуры: заведомо неправильные ответы, которые LLM-судья должен отбраковать. Если судья пропускает такую фикстуру — тест падает, и разработчик получает сигнал о проблеме. Это позволяет отлавливать галлюцинации и дрейф модели на ранних этапах.
Враждебные фикстуры — это примеры, которые явно нарушают логику или факты. Например, если тест проверяет знание столиц, фикстура может утверждать, что столица Франции — Берлин. LLM-судья должен поставить низкую оценку такому ответу. Если он этого не делает, значит, либо промпт составлен некорректно, либо модель дрейфует. Такие фикстуры легко создавать и поддерживать, а их количество должно быть достаточным для покрытия всех типов ошибок.
Три реальных факапа, которые едва не увели систему в ложноположительное пике
Первый баг: LLM-судья начал оценивать ответы по стилю, а не по содержанию — хвалил красивые, но пустые фразы. Второй: из-за изменения промпта модель стала считать любые ответы с числом правильными, игнорируя логику. Третий: судья запомнил несколько эталонных ответов из обучающей выборки и начал их повторять, выдавая за свои оценки. Все три проблемы были выявлены только благодаря двухконтурной системе и CI-инвариантам.
Первый случай произошёл, когда разработчики обновили промпт, добавив требование «давать развёрнутые ответы». Модель стала хвалить длинные, но бессодержательные тексты. Нормализатор заметил, что в таких ответах отсутствуют ключевые термины, и заблокировал оценку. Второй случай: после изменения промпта модель начала считать любой ответ, содержащий цифру, правильным — даже если цифра была неверной. Враждебная фикстура с неверным числом помогла выявить эту проблему. Третий случай — классическое переобучение: модель запомнила эталонные ответы из тестового набора и начала их повторять, вместо того чтобы оценивать новые ответы. CI-инвариант, проверяющий уникальность ответа, зафиксировал аномалию.
Технические детали реализации gated-judge
Архитектура gated-judge включает три компонента: LLM-судья (например, GPT-4 или Llama), нормализатор на основе правил (регулярные выражения, проверки типов, ограничения длины) и CI-модуль с фикстурами. Нормализатор работает синхронно: получает ответ LLM и проверяет его по набору инвариантов. Если хотя бы один инвариант нарушен — гейт блокирует оценку. Фикстуры хранятся в репозитории тестов и запускаются при каждом коммите. Автор рекомендует использовать минимум 20–30 фикстур на каждый тип проверки.
Нормализатор может быть реализован как отдельный микросервис или библиотека, вызываемая после LLM. Инварианты делятся на жёсткие (например, ответ не может быть пустым) и мягкие (например, ответ должен содержать хотя бы одно ключевое слово). Для мягких инвариантов можно настроить порог: если нарушено больше определённого количества, оценка блокируется. CI-модуль запускается при каждом пуше и прогоняет фикстуры через LLM-судью. Если хотя бы одна фикстура проходит (получает высокую оценку), сборка помечается как неудачная.
Кого затронет и как
Разработчики, использующие LLM для автоматического тестирования или оценки качества, получат готовый паттерн для защиты от ошибок. Бизнес, внедряющий AI-решения в production, сможет снизить риски ложных срабатываний. Для российских компаний, которые активно экспериментируют с open-source моделями, этот подход особенно актуален: модели менее стабильны, а значит, гейт с правом вето критически важен.
Даже если вы используете коммерческие модели вроде GPT-4, дрейф и галлюцинации остаются проблемой. Двухконтурная система позволяет перехватывать ошибки, которые могут дорого обойтись бизнесу. Например, в чат-ботах поддержки неверная оценка ответа может привести к тому, что клиент получит некорректную информацию. В системах автоматического ревью кода — к пропуску багов.
Что будет дальше
Автор планирует опубликовать открытую реализацию gated-judge на GitHub в ближайшие месяцы. В сообществе уже обсуждают добавление поддержки мульти-LLM (несколько судей с голосованием) и динамических инвариантов, которые обучаются на реальных данных. Вероятно, паттерн станет стандартом де-факто для production-систем с LLM-оценкой.
Динамические инварианты — это правила, которые автоматически извлекаются из исторических данных. Например, если в 99% случаев длина ответа не превышает 500 символов, можно установить инвариант, блокирующий слишком длинные ответы. Мульти-LLM подход предполагает использование нескольких моделей для оценки одного ответа, что снижает риск единой точки отказа. Эти улучшения сделают систему ещё более надёжной.
Итог
LLM-судьи — мощный, но ненадёжный инструмент. Двухконтурная система с классической нормализацией и CI-инвариантами позволяет существенно повысить доверие к автоматическим оценкам. Если вы используете LLM для тестирования — не верьте на слово, стройте гейт. Начните с малого: добавьте несколько простых правил и враждебных фикстур. Это окупится, когда вы поймаете первую серьёзную ошибку.