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

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

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

Для локального пилота возьмите одну задачу, например поиск актуального порядка согласования заявок. Результат каждого запроса — список фрагментов с идентификатором документа, разделом и версией, ответ с привязкой каждого существенного утверждения к фрагменту либо явный отказ отвечать. Это критерий, который вы задаёте системе, а не свойство любого RAG «из коробки». Архитектуру узкого пилота и маршрут документов смотрите в разборе RAG для бизнеса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующий шаг: соберите узкий RAG-пилот и до настройки модели подготовьте контрольную таблицу вопросов и разрешённых исходных фрагментов. Для выбора способа локального запуска откройте Ollama; для разбора неподтверждённых утверждений — методику о галлюцинациях.