Как оценивать RAG-пилот в 2026

RAG отлично выглядит на презентации, когда модель отвечает на один вопрос, который ей фактически подложили под нос. В проде интереснее другое: нашла ли система правильный источник, не потеряла ли исключение, показала ли цитату и поняла ли момент, когда лучше отдать задачу человеку.

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

В техническом слое смотрим скучные, но полезные вещи: попал ли нужный документ в top-k, насколько контекст релевантен, нет ли мусора в найденных фрагментах. В ответе - groundedness, faithfulness, полноту и нормальный отказ, когда отвечать нельзя.

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

Для первой проверки достаточно 30-80 вопросов. Нужны обычные вопросы, редкие исключения, кривые формулировки, вопросы с несколькими источниками и вопросы, на которые система обязана сказать: «не знаю».

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

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

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

У RAG две большие зоны ошибки: система может не найти правильный источник или найти источник, но собрать из него плохой ответ. Поэтому retrieval нужно проверять отдельно от генерации. Если нужный документ не попал в top-k, дальнейшая модель уже играет в угадайку. Если попал, но рядом лежит много мусорных фрагментов, ответ будет нестабильным и чувствительным к формулировке вопроса.

Практически это выглядит так: для каждого вопроса указываем один или несколько эталонных источников, затем смотрим hit rate, position, context precision и context recall. В бизнесовой версии этого же отчёта можно писать проще: «источник найден», «источник найден, но ниже пятого места», «источник не найден», «найден конфликтующий документ». Такой отчёт понятен не только ML-инженеру, но и владельцу базы знаний.

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

Для ручной проверки удобно использовать шкалу 0-2 по нескольким критериям. Groundedness: всё ли подтверждается источником. Completeness: закрыты ли все условия вопроса. Actionability: понятно ли, что делать дальше. Refusal quality: корректно ли система отказалась, если ответа нет. Через 50-80 вопросов уже видно, какие ошибки системные: плохие документы, неправильный chunking, слабый rerank или слишком смелый промпт.

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

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

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

Хороший итог пилота - backlog улучшений с приоритетами. Например: сначала чистим базу знаний и метаданные, затем меняем chunking, потом добавляем hybrid search, затем rerank, и только после этого сравниваем модели. Так вы улучшаете систему последовательно и понимаете, что именно дало прирост качества.