Оценка качества RAG
RAG — это два независимых блока: ретривер ищет, генератор отвечает. Мерить их надо по отдельности — иначе невозможно понять, кто из двоих виноват в плохом ответе и что именно чинить.
Интуиция
Ответ RAG-системы плох. Почему? Вариантов ровно два: либо поиск не принёс нужный фрагмент (генератору не из чего отвечать — он честно скажет «не знаю» или, хуже, нафантазирует), либо фрагмент пришёл, а модель им не воспользовалась или переврала. Это разные болезни с разным лечением: первую чинят чанкингом, моделью эмбеддингов и гибридным поиском, вторую — промптом, выбором LLM и форматом контекста. Единая метрика «хороший ответ / плохой ответ» смешивает обе болезни в кашу.
Метрики ретривера
Для оценки поиска нужен золотой сет (golden set): пары «вопрос → релевантные чанки», размеченные руками. Дальше считаем:
- Recall@k — главная метрика: доля вопросов, для которых релевантный чанк попал в топ-k выдачи. Если его нет в контексте, генератор бессилен.
- Precision@k — какая доля из k подтянутых чанков действительно релевантна: показывает, сколько мусора едет в контекст.
- MRR (mean reciprocal rank) и nDCG — учитывают позицию: релевантный чанк на первом месте ценнее, чем на пятом.
Метрики генерации
- Faithfulness / groundedness — опирается ли ответ на переданный контекст или содержит выдуманные утверждения. Именно эта метрика ловит галлюцинации.
- Answer relevance — отвечает ли текст на заданный вопрос (можно быть верным контексту, но отвечать не о том).
- Полнота — использованы ли все нужные факты из контекста.
Считать их руками дорого, поэтому применяют LLM-as-judge: сильная модель сверяет каждое утверждение ответа с контекстом. Помни про её систематические ошибки (biases): любовь к длинным ответам, позиционные предпочтения, снисходительность к «своим» текстам. Готовые фреймворки — RAGAS и подобные, но многие команды пишут своих судей: свой домен — свои критерии.
Прогони eval при k=1: recall 40%, и faithfulness ровно такой же — там, где поиск принёс не тот чанк (Q2 нашёл «Обмен товара» вместо «Возврата»), модель уверенно галлюцинирует. Подними k до 3 — recall 100%, галлюцинации исчезли сами, хотя генератор никто не трогал. А теперь k=5: recall остался 100%, но faithfulness просел — в контекст Q4 заехал устаревший чанк «Оплата (архив 2019)», и генератор цитирует отменённые правила. Узкое место сместилось с retrieval на generation.
Процесс: регрессии и онлайн-сигналы
Оффлайн-оценку гоняют как регрессионные тесты — при каждом изменении пайплайна: поменяли чанкинг, модель эмбеддингов, промпт, версию LLM — прогнали золотой сет, сравнили метрики с прошлым запуском. Без этого улучшение одного куска незаметно ломает другой: например, более крупные чанки подняли faithfulness, но уронили recall.
В проде добавляются онлайн-сигналы: явный фидбек пользователей (лайки/дизлайки), доля ответов «не знаю», доля эскалаций на человека, повторные переформулировки одного и того же вопроса. Рост доли «не знаю» при стабильном трафике — типичный ранний симптом деградации ретривера: например, в базу залили документы нового формата, которые чанкер режет в кашу.
- «Как оценить качество RAG-системы?» — раздельно: ретривер (recall@k, precision@k, MRR/nDCG на золотом сете) и генератор (faithfulness, answer relevance через LLM-as-judge).
- «Ответы плохие — что проверишь первым?» — retrieval: чаще всего нужного чанка просто нет в контексте.
- «Что будет, если сильно увеличить k?» — recall вырастет, но в контекст поедет мусор: faithfulness и точность ответов могут упасть, латентность и стоимость вырастут.
- «Какие проблемы у LLM-as-judge?» — предпочтение длинных ответов, позиционный bias, снисходительность к текстам похожего стиля; лечится калибровкой на человеческой разметке.