Оценка качества RAG-системы (RAGAS, precision, recall, faithfulness)

Почему оценка RAG ломается на реальных данных

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

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

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

Отсюда третий слой — верность источнику: какую долю утверждений в ответе можно подтвердить процитированным фрагментом. Мы разводим метрики по слоям — каркас берём из открытого RAGAS — и видим, где именно проседает качество ответов ассистента. Разбираем, как это закрывается на каждом слое.

Что меняется после внедрения регулярных проверок

Регулярный прогон на замороженном наборе вопросов переводит качество ответов из ощущений в метрику. Мы фиксируем эталонные пары «вопрос → ожидаемый ответ и источник» и после каждой правки промпта, модели или поискового индекса считаем faithfulness, precision и recall через RAGAS — результаты сравнимы между релизами, а не «в этот раз вроде отвечает лучше». Что меняется по пунктам:

• Доля отказов падает. Ответы, у которых faithfulness ниже порога или нет опоры на поднятый фрагмент, отсекаются до выката: в прод уходит версия, где доля недостоверных ответов меньше в разы, а не «примерно как раньше».
• Обновления индекса выходят быстрее. Пересборка и проверка идут одним прогоном, поэтому правка в базе знаний занимает часы вместо дней ручного просмотра десятков диалогов.
• Регрессии видны на пороге релиза. Сравнение с предыдущим прогоном показывает, какие группы вопросов просели после смены модели или разбиения документов на фрагменты.
• Спорные ответы всплывают до выпуска. Список вопросов с низким recall показывает дыры в базе знаний — их закрывают контентом, а не очередной правкой промпта.
• Разбор стал предметным. По любому ответу есть трассировка: какие фрагменты подняты, что попало в контекст, на каком шаге потерялся нужный факт.

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

Способы проверки: от ручной разметки до автотестов

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

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

Рабочая схема — комбинированная: эталон из ручной разметки (обычно сто-двести вопросов, включая редкие сценарии), синтетика для объёма и автоматический прогон на каждом изменении. Открытые наборы метрик вроде RAGAS закрывают базовые измерения, но их показатели сверяем с ручными — расхождение сразу показывает, где метрика врёт, и тогда веса пересматриваются. Набор тестов живёт вместе с системой: новые обращения пользователей превращаются в вопросы эталона, поэтому регресс ловится до выпуска, а не после жалоб.

Этапы внедрения контура контроля качества

Контур контроля качества не появляется вместе с первой версией ответов: его собирают поэтапно, оставляя на каждом шаге артефакт, который переживёт смену модели и переиндексацию корпуса. Ниже — порядок работ от инвентаризации данных до регламента, по которому прогоны запускаются уже без нашего участия.

1. Аудит данных — перечень источников, проверка актуальности и дублей, разметка тем: что корпус покрывает плотно, а что собирается из нескольких фрагментов.
2. Эталонные вопросы — простой факт, сводка по нескольким документам, вопрос без ответа в корпусе. К каждому — ожидаемые фрагменты-источники, а не только верная формулировка.
3. Метрики и опорный замер — точность поиска, полнота выдачи, верность ответа опорным фрагментам. Первый прогон даёт точку отсчёта для всех последующих правок.
4. Пороги приёмки — отдельно по каждой метрике: что достаточно для выпуска, а что блокирует релиз. Беглость формулировок не должна маскировать провал по полноте.
5. Регрессионные прогоны — на смене модели, схемы разбиения или правке корпуса; расхождение с опорным замером разбираем до выпуска, а не после жалоб.
6. Разбор ошибок — классификация провалов: фрагмент не найден, найден устаревший, ответ собран не по источникам. По доле групп видно, что править — поиск или корпус.
7. Передача регламента — набор вопросов, пороги и порядок прогонов уходят вашей команде документом, который она запускает сама.

Регламент описывает, что прогонять после каждой правки корпуса и как трактовать расхождения, — качество перестаёт зависеть от того, кто сегодня дежурит на релизе. По мере появления новых сценариев набор эталонных вопросов расширяется.

Что передаём: наборы тестов, пороги, регламенты

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

• Набор тестов — вопросы, собранные из реальных обращений, размеченные по типам: поисковые, уточняющие, многошаговые и заведомо без ответа в базе знаний.
• Эталонные ответы — для каждого вопроса зафиксировано, что считается верным, и указан фрагмент-источник, которым этот ответ подтверждается.
• Отчёт по метрикам — точность и полнота поиска, доля ответов, подтверждённых источником, и доля корректных отказов «данных в базе нет».
• Срезы по группам — метрики считаются отдельно по темам и типам запросов: средний балл по всей выборке скрывает провал на узком, но важном сегменте.
• Правила приёмки — пороговые значения по каждой метрике и условия, при которых релиз блокируется, а не «дорабатывается потом».
• Конфигурация прогона — размер фрагментов, схема разбиения документов, параметры поиска и версия индекса: без этого два отчёта нельзя сопоставить.
• Регламент сопровождения — порядок пополнения набора тестов после каждого разбора сбоя и правило, кто обновляет эталоны при изменении базы знаний.

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

Кейс: оценка RAG на потоке обращений клиентов

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

Что было

Проверяли на десятке удобных вопросов, где система отвечала хорошо: реальные формулировки с опечатками, смешанной терминологией и уточнениями в длинном диалоге в выборку не попадали. Точностных метрик не существовало — только субъективное «стало лучше». Из-за этого правку нельзя было ни принять обоснованно, ни откатить: непонятно, что именно улучшилось и не сломалось ли что-то на соседних сценариях.

Что стало

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

Точность попадания в контекст выросла с 0,61 до 0,87, верность ответа — с 0,72 до 0,94, полнота выборки — с 0,58 до 0,83. Доля ответов, построенных на нерелевантном фрагменте, снизилась примерно втрое — ушли неверные советы и повторные обращения по той же теме.

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

Чем отличается проверка поиска от проверки генерации

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

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

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

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

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

Частые технические вопросы и ограничения

Перед стартом фиксируем границы замера: метрики вроде faithfulness, precision и recall описывают поведение системы на подготовленном наборе вопросов, а не её качество вообще. Поэтому к цифрам всегда добавляем разбор ошибок — иначе рост faithfulness маскирует ответы, которые формально опираются на контекст, но не решают задачу пользователя.

Какие ограничения у самих метрик?

Ни одна метрика не ловит неполный ответ: он может быть верным, но пропускать важную часть контекста. Дополняем автозамер набором «больных» вопросов и ручной проверкой случайной выборки — так деградация видна там, где усреднённый балл её скрывает.

Как часто прогонять оценку и когда обновлять набор?

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

Обсудим задачу и вернёмся с планом работ

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

• сценарий: какие вопросы задают пользователи и какой ответ считается правильным;
• 20–50 реальных запросов с эталонными ответами и ссылкой на фрагмент-источник;
• текущая конфигурация поиска: как документы режутся на чанки, какая модель эмбеддингов, сколько фрагментов подаётся в контекст;
• корпус документов или его обезличенный срез — проверки прогоняем на ваших данных, а не на демонстрационном наборе;
• метрики, если уже считаете: precision, recall, faithfulness, доля ответов без опоры на контекст;
• замеченные сбои: выдуманные факты, устаревшие фрагменты, потеря информации из середины документа;
• ограничения по данным: где можно разворачивать контур, какие внешние сервисы допустимы.

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

Опишите задачу — вернёмся с оценкой и планом.