LLM-судья и дневники 20 писателей: как тестировать ИИ-системы

Разбор новинки простыми словами. что это, кому нужно и брать ли.

LLM-as-a-judge с датасетом-"золотым стандартом" даёт маленькой команде способ выпускать LLM-фичи в прод без дорогих прогонов на каждый коммит.

Связанные услуги: AI Boost Team, каталог, стать клиентом.

Собственник запускает ИИ-фичу. Нейросеть конспектирует записи клиентов, сама решает, задать ли уточняющий вопрос, раз в неделю собирает ретроспективу. На демо всё работает. Потом приходит вопрос, как это тестировать. Юнит тесты зеленые, circuit breaker отработал, через 3 попытки бросил исключение, лимиты на ввод режут правильно. А как проверить, что конспект не исказил смысл и не придумал клиенту проблемы, которой не было. Тут классический тест-дизайн обрывается. Слишком много вводных для попарного тестирования и таблиц решений.

Разработчик под ником Wolffther столкнулся с этим на собственном проекте, ИИ-дневнике, и описал выход на Хабре. Один человек на роли фулстека, тестировщика, девопса и продакта. Вечера после основной работы. Ручные сценарии в количестве 10, 20, 100 штук растянули бы стадию тестирования на месяцы. Он пошел другим путем, и этот путь стоит дешевле, чем кажется.

Что такое LLM-as-a-judge простыми словами

Идея прямая. Подключается вторая нейросеть, судья. Она получает промпт, в котором описано, что считает хорошим ответом, и выставляет балл от 1 до 5. Пять означает конспект без искажений и интерпретаций, длина в тему. Четыре, хороший конспект с мелкими недочетами, легкая переформулировка без потери смысла. Три, приемлемо, но есть заметные проблемы, искажение смысла, потеря детали или раздутый текст. Два, плохой, нарушены ключевые критерии. Один, не соответствует задаче.

Порог допуска в прод, оценка не ниже 4. Ниже правим промпт основной модели и гоняем снова.

Где взять тестовые данные, если команда из одного человека

Судья нужен, но ему чем-то кормить. Ручные сценарии писать долго, а разнообразия все равно не хватит. Автор взял дневники и заметки 20 писателей разных эпох и стилей. В выборке Довлатов с краткими колкими заметками, Толстой с подробным описанием дня и склонностью к саморефлексии, Басё с краткой философской отрешенностью, плюс Достоевский, Майер, Толкин, Сент-Экзюпери. Разные языки, разные длины, разные манеры.

Этим набором закрывается спектр "сырого" ввода, который в реальности присылают люди. Прогонов вышло около 100, после нескольких правок промптов качество дошло до нужной планки.

Как встроить это в CI/CD и не сжечь бюджет

100 прогонов стоят денег и нагрузки. Запихивать их в пайплайн на каждый коммит, значит платить за каждый чих и тормозить команду. Проверку вынесли в отдельную gradle-задачу с ручным триггером. Запускается только перед релизом. Это не регрессия, это скорее тестирование вменяемости, если применять классические термины.

Механика простая. Коммит, сборка, юнит и интеграционные тесты как обычно. Перед релизом руками дергаем таску, судья гоняет набор, смотрит на баллы. Ниже четверки не выкатываем. Лимиты модели живут, сломанная версия в прод не уходит.

Подвохи, которые ломают цифры

Первый. Промпт судьи должен перекликаться с промптом основной модели. Иначе оценки плывут и не имеют отношения к задаче. Как прийти в проект и начать тестировать систему торгов на фондовом рынке, не понимая, что такое акция, облигация, срочная сделка.

Второй. Тройка от судьи не всегда означает, что виновата основная модель. Иногда путается сам судья, и ему нужно прописать строже, как относиться к интерпретации, обобщению или заданному вопросу. Снимать результаты нужно аккуратно, иначе начнете чинить то, что не сломано.

Третий и главный. Писатели на то и писатели, чтобы хорошо и красиво орудовать словом, и они могут не отражать реальных пользователей. Этот набор работает как золотой стандарт для выхода в бету, не как замена живым тестам на реальной аудитории.

Различия начинаются там, где LLM перестает задавать набор определенных вопросов по набору бизнес правил, и начинает обрабатывать "сырой" пользовательский ввод.

Брать или подождать

Брать, если у вас маленькая команда и вы выпускаете LLM-фичи в прод. Методика дает способ отсекать откровенный брак без дорогих прогонов на каждый коммит. Ограничение честное, тексты писателей не заменят реальных пользователей, это мост до беты, а не финиш.

Подождать стоит только если у вас нет четкого понимания задачи основной модели. Без этого судья выставит красивые цифры, которые ни о чем не значит.

FAQ

Нужна ли отдельная модель для судьи

Нет. Можно взять ту же модель, но с другим промптом. Главное, чтобы промпт судьи перекликался с промптом основной, иначе оценки расходятся с задачей.

Сколько тестовых примеров нужно

В кейсе автора около 100 прогонов на выборке из 20 писателей. Цифра ориентир, не закон. Начните с 20, добейте до порога 4, потом расширяйте набор.

Заменит ли это живое тестирование

Нет. Это тест на вменяемость перед релизом. После беты нужны реальные пользователи и их реальный "сырой" ввод.

Что делать, если судья поставил 3

Не бежать править основную модель. Сначала проверьте промпт судьи, возможно, он сам путается в критериях строгости.

Цена ошибки здесь простая. Без судьи выкатываете сломанную версию и узнаете по жалобам. С неправильным промптом судьи выкатываете сломанную версию и узнаете по цифрам, которые врут.

Мария Селезнёва, полевой консультант.