Оценка качества LLM: 7 ошибок при запуске ИИ в агентстве

Когда продюсер запускает для клиента чат-бота или ассистента для креатива, после пары удачных тестов всё кажется отличным. Но в реальной работе пользователи отправляют нестандартные запросы, и система «плывёт». Если оценка качества LLM в агентстве строится по принципу «вроде бы отвечает нормально», есть риск слить бюджет. Проект в продакшене будет регулярно галлюцинировать и злить клиентов. Я расскажу, почему стандартные дашборды разработчиков врут и как настроить реальный контроль качества ИИ-решений.

Почему тесты на глаз ломают бизнес-логику ИИ

В статье на Хабре Сергей Прощаев подробно разобрал, как команды теряют контроль над ИИ-продуктами. Первая типичная проблема – проверка качества работы нейросети «на коленке». Разработчик поправил промпт, прогнал три любимых запроса, увидел хороший ответ и выкатил обновление клиенту. В итоге одно исправление чинит один сценарий, но ломает два других.

Чтобы этого избежать, нужно создать фиксированный набор из 30–50 реальных запросов (дымовой тест) и запускать его автоматически при любом изменении кода или инструкций. Для аналитики потребуются сотни кейсов, но начать нужно хотя бы с этого минимума. Иначе придётся бесконечно ходить по кругу: чинить одни баги и получать новые.

Забытые логи и слепые зоны в цепочках запросов

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

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

Почему ИИ-судья без калибровки бесполезен

Часто для проверки качества работы одной нейросети используют другую. Этот метод называют «ИИ-судья» (LLM-as-a-Judge). Это удобный инструмент, но без настройки он начнет подыгрывать сам себе. Модели склонны завышать оценки собственным текстам. Они часто предпочитают длинные и многословные ответы, даже если те не несут пользы. В итоге на графиках будет красивая оценка в 4,3 балла из 5, а служба поддержки клиента утонет в жалобах.

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

Метрики под реальные сценарии, а не из учебника

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

В кейсе ИИ-ассистента для управляющих компаний Nurture Boss система поначалу проваливала две трети запросов с датами. Например, когда просили записать на встречу «через пару недель». Команда детально изучила ошибки, написала тесты под этот конкретный случай и внедрила проверку. В результате точность обработки дат выросла с 33% до 95%.

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