Введение (Проблема классического тестирования)

Недавно я запустил свой первый проект на основе ИИ. Это личный дневник, в котором нейросеть выполняет роль наблюдателя, а не психолога или советчика. То есть пользователь делает запись, ИИ ее конспектирует, принимает решение — задать ли наводящий вопрос на основе этой записи, а раз в неделю или месяц собирает ретроспективу по сделанным записям.

Перед запуском, естественно, встал вопрос тестирования, и, если с юнит тестами или интеграционными все более‑менее понятно — там, проверили, что circuit breaker отработал и через 3 попытки бросил исключение, или что отработали лимиты по вводу для отдельной записи — то как тестировать те самые конспекты и вопросы? И вот тут начинается область, где классические техники тест‑дизайна перестают работать — слишком много вводных для того же попарного тестирования или таблицы принятия решений. Я не хочу сказать, что они в принципе не применимы ко всем LLM системам — наоборот, в практике я уже их использовал для агента создания рекламных кампаний. Различия начинаются там, где LLM перестает задавать набор определенных вопросов по набору бизнес правил, и начинает обрабатывать «сырой» пользовательский ввод.

LLM‑as‑a‑judge

Для таких случаев тоже есть подход — называется он LLM‑судья (LLM‑as‑a‑judge). Подключаем еще одну нейросеть (или ту же, но с другим промптом) и пропускаем через нее пользовательский ввод, обработанный изначальной ИИ. Судья по своему промпту оценивает ввод ИИ и ставит оценку, в зависимости от системы баллов, которую мы ему даем.

И остается последний вопрос — где взять вводные данные для тестирования? Можно, конечно, написать 10–20-100 сценариев вручную и все их прогнать через судью. И хорошо, когда есть команда разработчиков/тестировщиков, которые эти сценарии придумают — все равно это долго, но есть хотя бы несколько мозгов. В моем же случае был один разработчик‑фуллстак, один тестировщик, один девопс и один продакт — и все эти роли были на мне. А разработкой я занимался по вечерам после основной работы. При таком подходе стадия тестирования могла растянуться на месяц(ы).

Где взять тестовые данные

И вот тут в работу возвращается творчество. Где взять столько разнообразных пользовательских записей, которые именно выглядят как записи в дневники? Ответ — взять реальные дневники реальных людей, которые в разных степенях владеют литературным языком. Писателей. Берем 20 писателей из разных эпох, разных стилей и писавших на разных языках. Моя выборка включала в себя Довлатова, Достоевского, Толстого, Майер, Басё и так далее, включая Толкина и Сент‑Экзюпери. Таким списком я смог закрыть потребности в обработке нескольких видов данных — от Довлатова с его краткими и колкими заметками, Толстого, с подробными описаниями дня и склонностью к саморефлексии, до Басё — краткого и философски‑отрешенного.

Результаты и ограничения подхода

Так, за несколько прогонов набора тестов (приблизительно 100) и несколько правок оригинальных промптов я смог дойти до оценки не ниже 4 от судьи, чтобы это можно было уже выводить в прод.

Сама проверка шла автоматически с помощью выделенной gradle‑таски, чтобы при выстраивании CI/CD для проекта при деплое не бежали 100 довольно дорогих в плане нагрузки и денег тестов. Это не регрессия, это скорее тестирование вменяемости, если применять классические термины. Архитектурно эти тесты не запускаются на каждый коммит в ветку разработки. Они вынесены в отдельный ручной триггер, который запускается только перед релизом. Это позволяет не тратить лимиты нейросетки на каждый чих, но при этом гарантирует, что в прод не уйдет сломанная версия.

Из технических деталей: при таком подходе промпт для судьи должен перекликаться с промптом для изначальной ИИ. То есть это как прийти в проект и начать тестировать систему торгов на фондовом рынке, ни беса не понимая, что такое вообще акция/облигация, срочная сделка и так далее. Конкретно моя шкала для судьи выглядела так:

5 — конспект идеален. Ни одного искажения, ни одной интерпретации.
Длина уместна: короткая запись — короткий конспект.
4 — конспект хорош, есть мелкие недочёты.
Лёгкая переформулировка без потери смысла, или два предложения
вместо одного без искажения.
3 — конспект приемлем, но есть заметные проблемы.
Заметное искажение смысла ИЛИ потеря детали ИЛИ конспект заметно
длиннее записи, чем следовало бы.
2 — конспект плох, нарушены ключевые критерии.
Искажение, добавленная интерпретация, совет/оценка, потеря
действующего лица.
1 — конспект не соответствует задаче.

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

ВАЖНО: такой набор данных хорошо работает, как «золотой стандарт». Писатели на то и писатели, чтобы хорошо и красиво орудовать словом и они могут не отражать реальных пользователей. Но в условиях ограниченного времени, инфраструктуры и финансов они могут дать тот уровень качества в тестировании, который позволит вывести проект в бету.

Ссылка на мой проект

Про тестирование недетерминированных систем