Ловушка «зеленых метрик», или Работоспособность не равна эффекту

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

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

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

Как подготовить данные

До промышленной эксплуатации систему стоит прогнать через несколько уровней проверки: сначала юнит-тесты отдельных компонентов (проверки мелких кусков системы по отдельности), потом интеграционные, и только затем пилот на реальных сценариях. Пилот на одной задаче у нас шел шесть недель и за это время всплыло с десяток ситуаций, которых за столом не придумали бы никогда. Вопросы с опечатками, запросы на двух языках вперемешку, просьбы «сделай как в прошлый раз». Ни одной из этих строк не было в исходном плане тестирования.

Самое коварное в тестовых наборах вот что. Вручную собранные типовые вопросы показывают отличные результаты и усыпляют бдительность. Реальное распределение запросов нередко шире. Попадаются редкие кейсы, странные формулировки, и именно они заваливают всю модель. Неплохо работает прием с логами за несколько месяцев, из них в набор включают не только популярные сценарии, но и хвост распределения. Сценарии стоит готовить вместе с бизнес-пользователями: разработчик видит структуру, а пользователь знает, где реально болит.

Борьба с галлюцинациями и дрейфом модели

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

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

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

Есть такая неочевидная проблема как дрейф. Так называют постепенное расхождение между тем, что модель выдает, и тем, что от неё ждут. Входные данные меняются. В базу знаний добавили документы, обновились прайсы, у регламента поменяли два пункта. Каждый сдвиг сам по себе мелочь, а суммарно качество ползет. Замечали ситуации, когда в течении месяца-двух никто ничего не видел, потому что ухудшение шло незаметно, цифры чуть менее точные, ответы чуть более расплывчатые... Кто в такой ситуации поднимет тревогу? Поэтому важен непрерывный мониторинг ключевых метрик с алертами при отклонениях. Ловить сползание на дашборде проще, чем объяснять, почему ответы поплыли.

Верификация: экспертная оценка и обратная связь

Автоматические метрики вроде BLEU и ROUGE (если расшифровать, это способы сравнить сгенерированный текст с эталоном) полезны технической команде, но у них есть потолок. Текст может получить отличные цифры и при этом не отвечать на вопрос пользователя. Экспертная оценка закрывает этот пробел, и проводить её надо регулярно, причем разными ролями. Конечные пользователи смотрят на полезность. Руководители процессов проверяют соответствие регламенту. Специалисты по качеству оценивают риски, и их мнение нередко самое резкое. Например, можно собирать оценки раз в две недели, короткой сессией по двадцать случайных ответов. Полдня работы, а картинка становится существенно яснее.

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

Управление рисками. От классификации сценариев до аудита промптов

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

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

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

С недавних пор в карточке каждого ИИ-сценария у нас висит строчка: «кто отвечает за качество и когда проверяли последний раз».

Пустая строка означает, что сценарий не внедрен, даже если технически всё летает. Кто-то назовет это формальностью, и пусть.

С тех пор, как строчка появилась, сюрпризов с качеством стало сильно меньше.