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

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

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

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

LLM-as-a-judge

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

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

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

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

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

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

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

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

5 — конспект идеален. Ни одного искажения, ни одной интерпретации.
    Длина уместна: короткая запись — короткий конспект.

4 — конспект хорош, есть мелкие недочёты.
    Лёгкая переформулировка без потери смысла, или два предложения
    вместо одного без искажения.

3 — конспект приемлем, но есть заметные проблемы.
    Заметное искажение смысла ИЛИ потеря детали ИЛИ конспект заметно
    длиннее записи, чем следовало бы.

2 — конспект плох, нарушены ключевые критерии.
    Искажение, добавленная интерпретация, совет/оценка, потеря
    действующего лица.

1 — конспект не соответствует задаче.

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

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

Ссылка на мой проект – https://svechka.hey-savvy.online ^[3]