RAG · Retrieval-augmented generation · урок 7 · 13 мин

Как измерять RAG

Measuring RAG

Пройдено

Зачем

После урока ты объяснишь, как измерять RAG по половинам: метрики retrieval отдельно, метрики generation отдельно, — и как собрать набор вопросов, на котором эти цифры что-то значат. На собеседовании это ответ на «how do you evaluate a RAG system?», а на работе — способ понять, какая половина сломалась, до того как что-то чинить.

Почему одной цифры мало

Цифра «ответ верен в 82% случаев» полезна для отчёта, но бесполезна для починки. RAG (retrieval-augmented generation, генерация с опорой на найденные документы) состоит из двух половин, которые ломаются независимо: retrieval (выборка нужных chunks — кусков документов) и generation (ответ модели по ним). При 18% неверных ответов непонятно, что делать: менять поиск, нарезку, reranker (модель, пересортировывающую найденное) или инструкцию модели. Поэтому меряют три вещи: retrieval, generation и итог целиком.

Метрики retrieval: нашли ли нужное

Вопрос этой половины: были ли нужные chunks среди найденных, и как высоко.

Recall@k (полнота в первых k) — какая доля нужных chunks попала в top-k (первые k результатов). Нужно 2 chunk, в top-5 один — recall@5 = 0,5.
Ранг первого верного — как высоко стоит первый нужный chunk; из него считают MRR (средний обратный ранг). Подробно эти метрики — в уроке про метрики ранжирования.

Ragas (открытая библиотека для оценки RAG) называет родственные метрики так:

Context Recall — сколько нужного найдено. В варианте с LLM (large language model, большая языковая модель) эталонный ответ режут на утверждения и проверяют, какую долю из них можно подтвердить найденным context (тем, что поиск передал модели). В варианте по ID сравнивают списки ID: найдено doc_1, doc_2, doc_3, нужны doc_1, doc_4, doc_5, doc_6 → 1 из 4 = 0,25.
Context Precision — стоят ли нужные chunks выше ненужных. Это не простая доля: precision на каждой позиции, где стоит нужный chunk, усредняется, поэтому мусор на первом месте штрафуется сильнее, чем на пятом. Пример на трёх найденных chunks, два из них нужные. Порядок «нужный, мусор, нужный»: precision на 1-й позиции = 1, на 3-й = 2/3, среднее (1 + 0,67) / 2 ≈ 0,83. Порядок «мусор, нужный, нужный»: на 2-й = 1/2, на 3-й = 2/3, среднее ≈ 0,58. Набор chunks тот же, recall тот же, а context precision упала, потому что мусор встал первым.

Главная практическая мысль: если в golden set (наборе вопросов с эталоном) записаны ID верных chunks, retrieval меряется вообще без LLM — простым сравнением списков. Это дёшево, быстро и детерминированно, его можно гонять на каждое изменение.

Метрики generation: верно ли использовал

Вопрос этой половины: опирается ли ответ на найденное и отвечает ли он на вопрос.

Faithfulness (верность источнику; в других местах — groundedness, заземлённость) — доля утверждений ответа, подтверждённых найденным context. Формула Ragas: число подтверждённых утверждений, делённое на число всех утверждений ответа. Шаги: разрезать ответ на утверждения, проверить каждое по context, поделить.

Пример. Вопрос: «Сколько стоит досрочное погашение автокредита?» В context chunk: «Досрочное погашение — 1% от остатка, не менее 5 000 ₸. Подать заявление можно в приложении». Ответ модели: «Комиссия 1% от остатка, минимум 5 000 ₸, заявление подаётся в приложении или в отделении, рассмотрение занимает 1 день». Утверждений четыре: 1% — есть; 5 000 ₸ — есть; приложение или отделение — «отделение» не подтверждено; один день — не подтверждено. Faithfulness = 2 / 4 = 0,5. Retrieval сработал идеально, а generation досочинила.

Response relevancy (релевантность ответа; в старых текстах answer relevancy) — отвечает ли ответ на заданный вопрос. Ragas считает так: модель по ответу придумывает 3 вопроса, на которые он мог бы отвечать, затем считается cosine similarity (косинусная близость векторов) каждого с исходным вопросом, и берётся среднее. Метрика не проверяет факты: она ловит ответы не на тот вопрос, неполные и с лишним.

Citation accuracy (точность ссылок) — действительно ли процитированный chunk подтверждает утверждение, к которому стоит ссылка. Ответ может быть верным, а ссылка — на соседний пункт; аудитор банка такой ответ не примет.

Как читать сочетания

Retrieval	Faithfulness	Relevancy	Диагноз
низкий	—	—	чинить поиск, нарезку, фильтры
высокий	низкая	высокая	модель досочиняет: инструкция, проверка чисел, tool
высокий	высокая	низкая	отвечает честно, но не на тот вопрос: query rewrite, инструкция
высокий	высокая	высокая	итог плохой? проверь эталон и сам вопрос

Golden set: на чём меряют

Метрика стоит столько, сколько набор, на котором её считают. Golden set — вопросы, для каждого: ID верных chunks, эталонный ответ и, где нужно, дата и язык. Как собрать:

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

Начинать можно с малого: Anthropic в статье об оценке агентов советует стартовать с 20–50 задач из реальных провалов (статья «Demystifying evals for AI agents», ссылка проверена 08.10.2026), а дальше расти по мере новых провалов.

Судья и человек

Faithfulness и relevancy обычно считает LLM-судья (модель, которая оценивает ответы). Его оценку нельзя принимать на веру: сначала сравнить с разметкой людей на выборке, и только потом доверять. Там, где правило чёткое — число в ответе против числа в chunk или в системе учёта, — судья не нужен: это проверяет код, дешевле и надёжнее.

Offline и online

Offline-оценка (на golden set до выкатки) отвечает «не стало ли хуже». Online-наблюдение (в production, на реальных пользователях) ловит то, чего нет в наборе: новые темы, новый язык, новые форматы. Найденный в production провал становится новым вопросом golden set — так набор растёт вместе с системой.

Схема

golden set: вопрос + ID верных chunks + эталон

retrieval: recall@k, context precision — без LLM, по ID

generation: faithfulness, relevancy, citation accuracy

отчёт по срезам: язык, тип вопроса, версии

провал из productionновый вопрос в golden set

Термины · Key terms

recall@k: доля нужных chunks, попавших в первые k результатов
context recall: метрика Ragas: сколько нужного найдено
context precision: метрика Ragas: стоят ли нужные chunks выше ненужных
faithfulness: доля утверждений ответа, подтверждённых найденным context
groundedness: то же, что faithfulness: опора ответа на источник
response relevancy: отвечает ли ответ на заданный вопрос
citation accuracy: подтверждает ли процитированный chunk своё утверждение
golden set: набор вопросов с ID верных chunks и эталонными ответами
LLM judge: модель, которая оценивает ответы другой модели
slice: срез отчёта: язык, тип вопроса, версия документа

Сделай сам

Придумай вопрос, два chunk и ответ модели, в котором retrieval сработал (нужный chunk найден), но одно утверждение ответа в chunks не подтверждено. Подчеркни это утверждение и посчитай faithfulness по формуле Ragas.

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

Проверь себя · ответ под вопросом

1Почему одной цифры «ответ верен» недостаточно?

Она не говорит, какая половина сломалась: поиск не принёс нужное или модель неверно использовала принесённое. Исправления у этих случаев разные. Поэтому retrieval и generation меряют отдельно и отчитываются по срезам.

2Faithfulness высокая, answer relevancy низкая — что произошло?

Модель честно пересказала найденное, но ответила не на тот вопрос или не полностью. Искать стоит в query rewrite, в том, что принёс retrieval, и в инструкции модели. Факты при этом верны — проблема в адресности ответа.

3Какую метрику retrieval можно посчитать вообще без LLM, если есть golden set с правильными ID chunks?

Recall@k, или ID-based context recall: доля верных ID среди найденных. Также precision@k и MRR по рангам. Это детерминированно и дёшево, поэтому гоняется на каждое изменение.

Interview questions · US / UK

1How do you evaluate a RAG system?

Strong answer: separate halves — retrieval (recall@k, context precision, rank of first relevant) and generation (faithfulness, response relevancy, citation accuracy), plus end-to-end correctness; golden set from real queries; per-language slices; offline gate plus online monitoring.

2How would you build the golden set, and how big should it be to start?

Strong answer: real user questions and past failures; correct chunk IDs and reference answers; hard cases (versions, tables, digits in other scripts, unanswerable); start with dozens, grow from production failures; report by slice, not one average.

3Follow-up probe: your LLM judge says faithfulness is 0.95. Do you trust it?

Strong answer: only after validating it against human labels on a sample, per language; check what it misses, not just agreement; replace it with code where the rule is crisp, such as numbers against the source or a fee tool.

Ключевые фразы · Say it aloud

Measure the halves separatelyмерить половины отдельно
Retrieval can be scored without an LLM if the golden set has chunk IDsretrieval меряется без LLM по ID
Faithfulness is the share of claims supported by the retrieved contextfaithfulness — доля подтверждённых утверждений
Report by slice, not one blended numberотчёт по срезам, а не одной средней цифрой
Every production failure becomes a new golden-set itemкаждый провал становится вопросом набора

Материалы

Ragas — Faithfulness — определение, формула и пример с утверждениями (5 мин)
Ragas — Context Recall — три варианта: LLM, без LLM, по ID (5 мин)
Ragas — Context Precision — формула с весом по позиции (5 мин)
Ragas — Response Relevancy — как считается через придуманные вопросы (4 мин)