# Как оценить качество RAG: поиск, цитаты и ответы

Источник: https://modelium.tech/zhurnal/ocenka-kachestva-rag/

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

**Источники проверены 24 сентября 2026 года.** Это протокол для вашей команды, не результат испытания Modelium. Примеры условий проверки ниже — предложения для собственного пилота, а не измеренные показатели, юридическая оценка или гарантированные пороги качества.

## Что именно означает «качество RAG»?

RAG (retrieval-augmented generation) состоит как минимум из поиска контекста и ответа по нему. Ragas перечисляет отдельные метрики для поиска и генерации: контекстную точность и полноту, релевантность ответа и согласованность с найденным контекстом [s1](#src-s1). Если ответ неверен, сначала сохраните **список найденных фрагментов до генерации**, иначе невозможно отличить промах поиска от выдумки модели.

Для локального пилота возьмите одну задачу, например поиск актуального порядка согласования заявок. Результат каждого запроса — список фрагментов с идентификатором документа, разделом и версией, ответ с привязкой каждого существенного утверждения к фрагменту либо явный отказ отвечать. Это **критерий, который вы задаёте системе**, а не свойство любого RAG «из коробки». Архитектуру узкого пилота и маршрут документов смотрите в [разборе RAG для бизнеса](/zhurnal/rag-sistema-dlya-biznesa/).

## Как собрать проверочные вопросы до настройки модели?

Заведите контрольную таблицу: `question_id`, текст вопроса, допустимые `document_id` и редакции, эталонные фрагменты, ожидаемый ответ или отказ, права тестовой роли. Разметку исходных документов делает владелец процесса; нельзя назначать «правильным» текст, который только что сгенерировала проверяемая модель. Для оценки полноты поиска нужен эталонный ответ или эталонные контексты: так устроена метрика Context Recall [s3](#src-s3).

Включите разные случаи: факт из одного абзаца, значение из таблицы, два похожих регламента с разными датами, вопрос без ответа в корпусе, противоречащие редакции, вопрос к закрытому для роли документу и запрос с точным артикулом. Каждый случай имеет собственный ожидаемый исход. Если таблицы в PDF разобраны неправильно, ошибка начинается **до** поиска и генерации; храните оригинал рядом с извлечённым текстом. Не используйте клиентские персональные данные в открытом тестовом наборе без разрешения владельца данных.

Зафиксируйте до прогона версию корпуса, метод извлечения и разбиения, embedding-модель, конфигурацию поиска, генеративную модель, параметры контекста и права тестовой роли. После смены embedding-модели индекс придётся согласовать с новым способом получения векторов: Ollama отдельно рекомендует использовать ту же embedding-модель при индексации и запросе [s5](#src-s5). Если эти условия меняются между попытками, сравнение вариантов не изолирует причину ошибки.

## Как отдельно оценить выдачу поиска?

Для каждого вопроса сохраните первые `k` найденных фрагментов **в исходном порядке** с `document_id`, редакцией и местом в документе. Человек размечает для каждого: содержит ли он нужное доказательство, не устарел ли и разрешён ли именно этой роли. Сначала проверяйте, появился ли хотя бы один необходимый фрагмент; затем — сколько обязательных частей эталона пропущено. Context Precision учитывает положение релевантных фрагментов в ранжированной выдаче; Context Recall оценивает, покрывает ли контекст эталонные сведения [s2](#src-s2) [s3](#src-s3).

Не путайте эти величины: выдача может содержать один полезный фрагмент наверху, но пропустить второе условие из другого документа. И наоборот, все нужные фрагменты могут найтись, но быть погребены среди неподходящих. Определите `k` и правило разметки **до** просмотра результатов. В отдельном журнале фиксируйте отсутствие нужного фрагмента, неправильную редакцию и нарушение прав доступа; усреднённая оценка не должна скрывать критический провал.

Если нужен собственный индекс, quickstart Qdrant показывает локальный контейнер, коллекцию, загрузку точек с payload и запрос поиска [s8](#src-s8). Ollama документирует `POST /api/embed` с входным текстом и возвращаемыми векторами; embedding-вариант для документов и вопросов должен совпадать [s5](#src-s5) [s6](#src-s6). Это компоненты возможного стека, **не** готовый RAG-пилот и не обещание качества на русском. Qdrant предупреждает, что локальная конфигурация по умолчанию не имеет аутентификации и шифрования: не публикуйте её порт наружу при работе с корпоративным корпусом [s8](#src-s8).

## Как проверить цитаты и ответ?

Передавайте найденные фрагменты генеративной модели с явными идентификаторами. Ollama предоставляет `POST /api/chat` и поле `messages` для такого запроса [s7](#src-s7). Но сам вызов chat API не присоединяет документы, не проверяет полномочия и не гарантирует настоящие цитаты. Эти действия должна реализовать и проверить ваша обвязка.

Разберите ответ на проверяемые утверждения. Для каждого вручную откройте указанный `document_id` и фрагмент в исходной редакции: цитата существует, относится к разрешённому документу и действительно поддерживает **именно это** утверждение? Если ссылка ведёт к реальному, но нерелевантному абзацу, это не подтверждение. Если ответ звучит разумно, но найденный текст его не подтверждает, это отдельная ошибка генерации. Faithfulness в Ragas сравнивает утверждения ответа с **найденным** контекстом [s4](#src-s4). Такая оценка не доказывает правдивость самого документа, правильность версии, право доступа или совпадение цитаты с оригинальным файлом — их проверяют отдельно.

Проверьте и второй критерий: ответ должен решать **исходный вопрос**, а не просто пересказывать релевантный абзац. Вопрос без доказательства требует честного отказа; противоречащие версии — указания на конфликт и передачи человеку, если автоматическое правило выбора версии не утверждено. Не превращайте заполненный JSON или одну «хорошую» демонстрацию в процент точности. В примере автоматического вычисления Faithfulness документация Ragas использует внешний LLM-клиент; это **не локальный оценщик по умолчанию**. Для закрытого контура используйте ручную разметку или отдельно проверенный локальный оценщик, не отправляя внутренние фрагменты в облачный API [s4](#src-s4).

## Каким должен быть отчёт о пилоте?

Сохраняйте одну строку на вопрос: `question_id`, контрольная роль, эталонная редакция, версия стека, найденные ID в порядке выдачи, ответ, заявленные цитаты, отметка «нашёл нужное», отметка «каждое утверждение подтверждено», отметка «права соблюдены», тип ошибки и решение проверяющего. Для каждой ошибки укажите слой: извлечение документа, поиск, доступ/версия, генерация или цитирование. Пороги приемки, допустимые отказы и последствия ошибок утверждает владелец задачи **до** сравнения вариантов; универсального порога для договора, справочника и внутренней инструкции здесь нет.

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

**Следующий шаг:** [соберите узкий RAG-пилот](/zhurnal/rag-sistema-dlya-biznesa/) и до настройки модели подготовьте контрольную таблицу вопросов и разрешённых исходных фрагментов. Для выбора способа локального запуска откройте [Ollama](/zapusk/ollama/); для разбора неподтверждённых утверждений — [методику о галлюцинациях](/zhurnal/gallyucinacii-ii/).

## Источники

1. [Ragas — список метрик оценки RAG](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/) — получено 2026-09-24
2. [Ragas — Context Precision](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_precision/) — получено 2026-09-24
3. [Ragas — Context Recall](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_recall/) — получено 2026-09-24
4. [Ragas — Faithfulness](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/faithfulness/) — получено 2026-09-24
5. [Ollama — Embeddings](https://docs.ollama.com/capabilities/embeddings) — получено 2026-09-24
6. [Ollama — API Generate embeddings](https://docs.ollama.com/api/embed) — получено 2026-09-24
7. [Ollama — API Generate a chat message](https://docs.ollama.com/api/chat) — получено 2026-09-24
8. [Qdrant — Local Quickstart](https://qdrant.tech/documentation/quickstart/) — получено 2026-09-24