Качество и оценка

Сломанный RAG не падает, а уверенно отвечает неправильно, да ещё со ссылками на источники. Ошибку находят не в мониторинге, а через месяц, когда кто-то уже принял по ней решение.

Поэтому качество здесь измеряют, а не оценивают на глаз по ощущению «вроде отвечает нормально». Причём измерять нужно две вещи по отдельности.

Две половины качества

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

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

Смешивать их нельзя, иначе непонятно, что чинить: нарезку и поиск или промпт и модель. Метрик, которых хватает на практике, четыре:

Доля вопросов, где нужный документ попал в выдачу. Основная метрика поиска, считается по золотому набору, где эталонный источник известен заранее.
Обоснованность ответа (groundedness). Доля утверждений в ответе, подтверждённых переданными фрагментами. Всё остальное домыслы, даже если они верны.
Доля честных «не нашёл». Система обязана уметь этот ответ. Если её процент подозрительно мал, она не осторожна, она выдумывает.
Полнота. Ответ верен, но упускает существенное условие. Дефект частый и самый опасный: проверить его труднее, чем прямую ошибку.

Золотой набор вопросов

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

Где их взять в «Маркете»:

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

Что обязательно включить, чтобы набор не был декоративным:

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

Регрессии

Золотой набор собирают один раз, а прогоняют при каждом изменении: смене модели, изменении размера фрагментов, добавлении источника, включении реранкинга.

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

Ссылки на источники как механизм доверия

Ответ без ссылок непроверяем, а значит, бесполезен для любого решения с ценой. Ответ со ссылкой проверяется за секунды: открыл, увидел абзац, поверил или не поверил.

Логика здесь та же, что и в проверке результатов агента: результат RAG остаётся черновиком. Разница лишь в том, что проверять его дёшево, если система сама показывает, откуда взяла. Требовать ссылки нужно затем, чтобы люди вообще могли пользоваться системой в серьёзных вопросах.

Что смотреть в проде

Золотой набор ловит регрессии, но не расскажет, как система живёт. Для этого нужно наблюдение за реальным использованием:

Доля ответов «не нашёл». Если она растёт, появились вопросы, которые нечем закрыть; это очередь на новые источники или новую документацию.
Переходы по ссылкам-источникам. Никто не открывает источники: либо ответам верят вслепую, либо ими не пользуются для важного.
Переформулировки одного вопроса подряд. Верный признак, что с первого раза не ответили.
Явные оценки от пользователей. Дёшево собирать, полезно как сигнал, но принимать по ним решения нельзя: люди оценивают уверенность тона не меньше, чем правильность.
Частые вопросы без хорошего источника. Самый ценный отчёт из всех: это список того, что в компании пора наконец задокументировать.

Антипаттерны оценки

Демонстрация на десяти удачных вопросах. Показывает, что система работает на вопросах, под которые её настраивали.
Оценка автором системы. Автор знает, как спросить, чтобы нашлось. Пользователь не знает.
«Нравится / не нравится» вместо набора. Ощущение качества смещается вместе с привычкой к тону ответов.
Тюнинг под демо. Улучшения, сделанные под конкретные вопросы показа, обычно ухудшают всё остальное.
Оценка только удачных сценариев. Если в наборе нет вопросов без ответа, вы измеряете что угодно, кроме надёжности.

Что дальше

Внедрение в процессы разработки: как довести систему от пилота до ежедневной привычки команд.
Проверка результатов агента: общие приёмы проверки того, что выдал ИИ.

Автор учебника: Шахматов Алексей