Как оценивать качество ответов ИИ без команды аналитиков

Почему впечатлений недостаточно

Обычно ИИ-функцию оценивают так: кто-то меняет промпт, пробует три раза, доволен увиденным и выкатывает. Это не работает по вполне конкретной причине: вывод модели меняется от вызова к вызову, три случайно выбранных запроса редко оказываются трудными, и никто не помнит, что предыдущая версия делала на том же входе. Без фиксированного набора запросов и одинакового способа их оценивать вы не отличите настоящее улучшение от хорошего настроения и не заметите день, когда изменение сломало что-то другое.

Начните с двадцати реальных запросов

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

Для каждого запроса запишите, как выглядит приемлемый ответ. Не точные слова — короткое описание важных свойств. «Называет правильный тариф, не выдумывает цену, укладывается в четыре предложения». Именно это описание делает оценку воспроизводимой для человека, который не писал промпт.

Оценивайте так, чтобы это можно было повторить

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

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

Пусть первый проход делает модель, но проверяйте её

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

Как честно прочитать результат

Две привычки не дадут себя обмануть. Первая: прогоняйте на обеих версиях весь набор, а не только те случаи, которые вы чинили, — самый частый исход правки промпта в том, что она чинит три запроса и ломает два других, и видно это только на полном прогоне. Вторая: помните, что двадцать запросов — маленькая выборка: переход с шестнадцати успехов на семнадцать ничего не доказывает. Считайте мелкие сдвиги шумом и ищите изменения, достаточно крупные, чтобы их было видно, либо увеличивайте набор.

Держите цикл живым

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