RAG отвечает правильно в 90% случаев, а пользователи говорят, что модель плохая

Кейс из жизни. Мы сделали RAG для службы поддержки банка. Качество — 90%. Для простоты это точность: ответ либо полностью правильный, либо нет. Бизнес-метрику не зафиксировали, отправили в прод.

Через какое-то время приходит обратная связь: модель плохая. Начинаем разбираться. Оказалось, что модель отвечает правильно, но поддержке тяжело пользоваться ответом. RAG выдавал релевантные фрагменты документации, а сотрудники хотели получать ответ в привычном для себя формате — не цитаты из документации, а переписанный текст.

Невозможно улучшать систему, не умея её измерять. Ранее я писал, что при проработке новой задачи важно зафиксировать функциональные и нефункциональные требования, но о метриках ничего не написал. В предыдущем посте разбирал accuracy и её доверительный интервал, но это модельная метрика. А модель мы делаем, чтобы улучшить бизнес-процесс, и одной модельной метрики для этого мало.

Проблем в этой истории несколько.

Проблема 1. Не выяснили, что нужно пользователю. С метриками она не связана: недостаточно проработали с поддержкой, в каком виде им нужен ответ.

Проблема 2. Модельная метрика не говорит о пользе. Вытекает из первой. Метрика RAG показывает, правильный ли ответ по содержанию, но не показывает, удобно ли им пользоваться. Один и тот же RAG с качеством 90% в зависимости от генерации может устраивать пользователей, а может и нет.

Проблема 3. Не зафиксировали бизнес-метрику. Предположим, цель бизнеса — уменьшить время на обработку обращения. Без RAG сотрудник идёт в документацию и сам ищет материалы, с RAG сразу получает нужные фрагменты. Это время и надо было зафиксировать до запуска.

Проблема 4. Бизнес-метрика тоже может обмануть. Предположим, метрику всё же зафиксировали: время на обработку обращения. Запустили в прод — время значимо уменьшилось. Радуемся за модель, открываем шампанское. А в реальности на это направление перевели несколько опытных сотрудников, а пользоваться RAG сотрудники отказались. Время уменьшилось из-за скрытого фактора, а не из-за модели.

Как этого избежать:

• использовать A/B — тогда перевод опытных сотрудников одинаково повлияет на обе группы
• держать в арсенале прокси-метрики. Например, пользуются ли сотрудники сервисом вообще: доля обращений, в которых открыли ответ RAG
• держать guardrail-метрики — то, что не должно ухудшиться, пока сокращаем время. Например, доля повторных обращений

Итоги:

• Важна не только модельная метрика, но и бизнес-метрика
• До метрик нужно выяснить с пользователем, в каком виде ему нужен результат
• Мало один раз поговорить о метриках — нужен процесс: зафиксировать до запуска, проверить в A/B, следить после запуска
• Задизайнить метрики — сложная задача. На неё нужно потратить ресурсы и ML-инженеров, и бизнеса

#процессы