Ragas: как проверять ответы RAG-системы

Ragas: как проверять ответы RAG-системы можно двумя метриками, которые покрывают разные звенья конвейера. Faithfulness измеряет, опирается ли ответ на извлечённый контекст. Context Precision измеряет, стоят ли релевантные фрагменты выше нерелевантных. Дальше — исходный набор, ручной эталон и маршрут запуска.

Что такое Ragas и где границы задачи

Библиотека Ragas описана в первичной документации проекта (docs.ragas.io) как инструмент перехода от проверок «на глаз» к систематическим циклам оценки приложений на больших языковых моделях. Документация называет три опоры: метрики на основе LLM, систематическое экспериментирование и цикл непрерывного улучшения. Там же перечислены ключевые возможности: подход «сначала эксперименты», собственные метрики через декораторы, готовый набор метрик, управление наборами данных, отслеживание результатов и интеграции с LangChain, LlamaIndex и другими фреймворками.

Граница задачи для читателя узкая. Ragas оценивает ответ по отношению к контексту и порядок фрагментов в выдаче ретривера. Он не подтверждает истинность самого источника, полноту ответа и готовность системы к релизу. Документация Qdrant (qdrant.tech) в разделе об оценке качества вывода конвейера прямо разделяет эти вещи: качество извлечения и качество генерации проверяются разными наборами метрик, и одна метрика не заменяет другую.

Практический вывод: выбирайте метрику под конкретный вопрос. Ответ содержит утверждение, которого нет в контексте, — смотрите Faithfulness. Релевантный фрагмент лежит ниже нерелевантного — смотрите Context Precision. Обе метрики возвращают значение от 0 до 1, где большее значение означает лучшее совпадение с ожиданием.

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

Исходный набор, эталон и маршрут запуска

Соберём полный вход для проверки. Возьмём синтетический вопрос Q1: «Какой лимит проекта?». Контекст R1: «Лимит проекта — 12 заявок в день». Контекст R2: «Заявки принимаются после 09:00». Это синтетический учебный пример.

Эталон задаётся вручную до запуска. Для Q1 эталонный ответ: «Лимит 12 заявок в день, приём после 09:00». Если данных о сроке в источниках нет, эталон формулируется как «В источниках нет данных». Такая запись фиксирует ожидаемое поведение системы на неизвестном значении.

Поля записи набора данных в документации Ragas перечислены явно: user_input, retrieved_contexts, response, reference. К ним добавляется стабильный ID вопроса, чтобы сравнивать прогоны между собой. Документация показывает сборку списка словарей и загрузку в EvaluationDataset через from_list.

Маршрут запуска по документации: подготовить набор данных, выбрать evaluator LLM, вызвать evaluate с набором метрик. В примере документации используются LLMContextRecall, Faithfulness и FactualCorrectness, а результат печатается словарём со значениями по каждой метрике. Для одиночной проверки документация показывает collections API: метрика создаётся с моделью, затем вызывается ascore или score с полями user_input, response, retrieved_contexts.

Порядок действий для приёмки:

1. Зафиксировать набор вопросов и версию метрики.
2. Заполнить эталонные ответы вручную.
3. Прогнать систему и сохранить response и retrieved_contexts.
4. Посчитать метрики и сравнить с ручным разбором.
5. Менять retriever только после фиксации набора.

Ручной эталон и результат запуска

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

Разберём ответ A: «Лимит 12 заявок в день, приём после 09:00». Ручная проверка: подтверждены 2 утверждения из 2. Ответ B: «Лимит 20 заявок в день, приём после 09:00». Подтверждено 1 из 2, потому что число 20 противоречит R1. Это ручная учебная иллюстрация доли поддержанных утверждений: реальный судья может иначе разделить ответ на утверждения.

Отсюда практическое правило. Ручной расчёт показывает, чего вы ждёте от системы. Запуск Ragas показывает, что увидела модель-судья. Расхождение между ними — повод посмотреть, как судья нарезал утверждения, и уточнить формулировки эталона.

Документация Ragas описывает и альтернативу LLM-судье. Для шага сверки утверждений с контекстом доступна модель HHEM-2.1-Open от Vectara: классификатор на базе T5, обученный находить галлюцинации в тексте, порождённом моделью. Документация называет её бесплатной, небольшой и открытой, пригодной для продуктивных сценариев. По умолчанию модель загружается на CPU с размером батча 10; устройство и размер батча задаются аргументами device и batch_size.

Отрицательный случай и неизвестные значения

Отрицательный случай показывает, что метрика ловит. Возьмём контекст R9 «Кафетерий закрыт» — он нерелевантен вопросу Q1. Случай C: порядок [R9, R1], маска релевантности [0, 1], average precision = 1/2. Случай D: порядок [R1, R9], маска [1, 0], average precision = 1. Ответ может оставаться правильным, порядок контекста различается.

Эти значения рассчитаны вручную по заданной маске релевантности. Они показывают механику метрики: релевантный фрагмент на первой позиции даёт полный вклад, на второй — половину.

Документация Ragas подтверждает эту механику на своём примере с Context Utilization. Когда нерелевантный фрагмент стоит на второй позиции, значение остаётся высоким. Когда тот же нерелевантный фрагмент оказывается на первой позиции, значение падает примерно вдвое. По формуле Ragas, Context Precision суммирует precision@k на релевантных позициях и делит сумму на число релевантных фрагментов в выдаче. В precision@k учитываются все фрагменты с первой позиции по k включительно: число релевантных среди них делится на k.

Неизвестные значения обрабатываются отдельно. Если система не знает срок, эталон фиксирует «В источниках нет данных». Тогда проверяется, признаёт ли система незнание или подставляет выдуманное число. Выдуманное число в ответе при отсутствии его в контексте снижает Faithfulness.

Отдельно про истинность. Faithfulness проверяет опору на данный контекст. Если сам контекст содержит ошибку, верный по форме ответ получит высокую оценку. Документация Qdrant разделяет оценку извлечения и оценку генерации именно по этой причине.

Условия доступа и рабочий код

Документация Ragas описывает установку и быстрый старт, ссылаясь на инструкцию по установке и руководство quickstart с заявленным временем старта в 5 минут. Модель-судья и модель эмбеддингов задаются вами; документация показывает langchain_openai с ChatOpenAI и OpenAIEmbeddings как пример, оговаривая, что можно выбрать любую другую модель.

Тарифы, квоты и условия доступа из России в первичных документах не раскрыты. Планируйте расходы на стороне выбранного провайдера модели-судьи: показанные ниже LLM-варианты Faithfulness и Context Precision обращаются к этой модели. ID-based и другие non-LLM варианты используют свои способы вычисления.

Ниже — учебный маршрут для одной записи. Он собирает поля из reader_artifact и вызывает метрику Faithfulness через collections API. Импорты и классы сверяйте с текущей первичной документацией перед запуском.

import os
from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.metrics.collections import Faithfulness, ContextPrecision

client = AsyncOpenAI(api_key=os.environ["OPENAI_API_KEY"])
llm = llm_factory("gpt-4o-mini", client=client)

faithfulness = Faithfulness(llm=llm)
context_precision = ContextPrecision(llm=llm)

user_input = "Какой лимит проекта?"
retrieved_contexts = [
    "Лимит проекта — 12 заявок в день",
    "Заявки принимаются после 09:00",
]
response = "Лимит 12 заявок в день, приём после 09:00"
reference = "Лимит 12 заявок в день, приём после 09:00"

async def main():
    f = await faithfulness.ascore(
        user_input=user_input,
        response=response,
        retrieved_contexts=retrieved_contexts,
    )
    p = await context_precision.ascore(
        user_input=user_input,
        reference=reference,
        retrieved_contexts=retrieved_contexts,
    )
    print("faithfulness:", f.value)
    print("context_precision:", p.value)

if __name__ == "__main__":
    import asyncio
    asyncio.run(main())

Задача промпта — получить от модели-судьи разбор утверждений ответа до вызова метрики, чтобы сверить нарезку с вашим ручным эталоном.

Ты проверяешь ответ RAG-системы на опору в контексте.
Вопрос: [ваш вопрос]
Контекст: [ваши retrieved_contexts]
Ответ системы: [response]

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

Меняйте под себя вопрос, контекст и ответ. Вариации той же задачи: проверка ответа на неизвестное значение; сверка двух ответов на один вопрос; разбор ответа с числом, которого нет в контексте; проверка ответа после смены retriever; разбор ответа на вопрос с двумя контекстами.

Проверка фактов, ограничений и ссылок

Сверяйте четыре вещи перед приёмкой. Первое: версия метрики и модель-судья зафиксированы в отчёте. Второе: поля записи заполнены полностью, включая стабильный ID. Третье: ручные расчёты помечены как ручные. Четвёртое: результат запуска сохранён вместе с версией набора.

Документация Ragas предупреждает о смене API. Legacy-метрики на основе SingleTurnSample будут объявлены устаревшими в версии 0.4 и удалены в версии 1.0; для новых проектов документация рекомендует collections API. Смешивать оба подхода в одном файле не стоит: импорты и вызовы различаются.

Таблица различий между двумя метриками:

Таблица вариантов Context Precision по документации:

Для IDBasedContextPrecision документация приводит пример: из четырёх извлечённых ID два найдены среди эталонных, итог — 0.5. Для NonLLMContextPrecisionWithReference нужен пакет rapidfuzz.

Ссылки для сверки: документация Ragas, руководство по оценке RAG, описание Faithfulness, описание Context Precision.

Частые вопросы

Что такое ragas evaluation?

Это оценка RAG-системы набором метрик библиотеки Ragas. Документация проекта описывает переход от проверок «на глаз» к систематическим циклам: набор данных, метрики, эксперименты, повторные прогоны. Рассматриваемые Faithfulness и Context Precision возвращают значения от 0 до 1. Выбор метрики определяется звеном конвейера, которое вы проверяете.

Чем Faithfulness отличается от истинности источника?

Faithfulness измеряет, опираются ли утверждения ответа на извлечённый контекст. Истинность самого источника метрика не проверяет. Если контекст содержит ошибку, ответ с опорой на него получит высокую оценку. Документация Qdrant разделяет оценку извлечения и оценку генерации по этой причине.

Нужен ли эталонный ответ для Context Precision?

Зависит от варианта метрики. LLMContextPrecisionWithReference требует эталон. LLMContextPrecisionWithoutReference сравнивает фрагменты с ответом системы. NonLLMContextPrecisionWithReference сравнивает извлечённые фрагменты с эталонными контекстами. IDBasedContextPrecision работает с идентификаторами документов.

Как считать Faithfulness вручную?

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

Можно ли смешивать collections API и legacy-метрики?

Документация рекомендует collections API для новых проектов. Legacy-метрики на основе SingleTurnSample будут объявлены устаревшими в версии 0.4 и удалены в версии 1.0. Импорты и вызовы у двух подходов различаются, поэтому в одном файле их лучше не смешивать.