Ragas или DeepEval: выбор оценки ответов LLM начинается с требований команды. Документация Ragas описывает сбор датасета с полями user_input, retrieved_contexts, response и reference, а затем запуск evaluate с метриками. Документация DeepEval описывает тест-кейсы, метрики и запуск deepeval test run через pytest. Обе библиотеки оценивают наборы и обе применимы в автоматизации.
Требования команды и заполненные решения
Универсального рейтинга здесь нет. Выбор идёт от того, какой процесс уже существует и какие входы команда готова поддерживать. Документация Ragas показывает базовый путь: строится простой RAG, документы векторизуются, ответ генерируется, затем собирается датасет и вызывается evaluate с метриками LLMContextRecall, Faithfulness и FactualCorrectness. Документация DeepEval показывает другой вход: тест-файл с LLMTestCase, метрикой GEval и вызовом assert_test, который затем исполняется командой deepeval test run.
Заполненное решение A. Команда уже хранит датасет в формате Ragas и настраивает retrieval. Решение: продолжить работу на фиксированном наборе, если выбранные метрики подходят по смыслу. Датасет собирается списком словарей, затем загружается в EvaluationDataset.from_list, после чего evaluate принимает датасет, список метрик и evaluator LLM.
Заполненное решение B. Команда уже использует pytest и требует критерий прохода в тесте. Решение: проверить DeepEval в этом процессе. Документация DeepEval описывает подключение к pytest: deepeval test run собирает и запускает файлы так же, как pytest. Порог threshold определяет, прошёл тест или нет.
Заполненное решение C. Команда хочет сравнить числа из двух библиотек. Решение: сначала сопоставить определения метрик, режимы, judge, шаблоны и версии. Одинаковое имя метрики само по себе не доказывает сопоставимость, а разные библиотеки могут случайно выдать одинаковое число.
| Требование команды | Что проверить | Решение |
|---|---|---|
| Есть датасет Ragas, настроен retrieval | Подходят ли выбранные метрики | Продолжить Ragas на фиксированном наборе |
| Есть pytest, нужен критерий прохода | Работает ли assert_test с порогом | Проверить DeepEval в этом процессе |
| Нужно сравнить числа двух библиотек | Совпадают ли определения и режимы | Сопоставить метрику, режим, judge, шаблон, версию |
Полный набор входов и ручные эталоны
Обе библиотеки требуют явного набора полей. Документация Ragas собирает словарь с ключами user_input, retrieved_contexts, response и reference, а затем загружает его в EvaluationDataset. Документация DeepEval для RAGAS-метрик требует четыре поля LLMTestCase: input, actual_output, expected_output и retrieval_context. Карта соответствия между библиотеками выглядит так.
| Ragas | DeepEval | Смысл |
|---|---|---|
| user_input | input | Вопрос пользователя |
| response | actual_output | Ответ системы |
| retrieved_contexts | retrieval_context | Найденные фрагменты |
| reference | expected_output | Эталонный ответ |
Для каждой метрики проверяется её собственный required input. Reference входит в набор полей датасета Ragas, и его наличие в примере не делает его обязательным для всех метрик. Документация DeepEval прямо указывает, что не все метрики требуют expected_output: метрика GEval в примере быстрого старта использует actual_output и expected_output, а FaithfulnessMetric требует input, actual_output и retrieval_context.
Ручной эталон задаётся отдельно от запуска. Учебный пример: question — «Какой лимит проекта?»; context — «R1: Лимит проекта — 12 заявок в день»; response — «Лимит проекта — 20 заявок в день»; gold — «12 заявок в день на проект». Ручной oracle: число 20 не поддержано контекстом и противоречит 12. Это ручная разметка человеком. Score Ragas и DeepEval на этом примере не вычислялся. Число 12 здесь задано в условном учебном входе. К лимитам продуктов оно не относится.
Порядок действий для ручного эталона: выписать вопрос, сохранить найденный контекст, зафиксировать ответ системы, отдельно записать эталонный ответ. Затем сверить утверждения ответа с контекстом вручную и отметить неподдержанные. Только после этого запускать метрику.
Условия выбора, документированные возможности, неизмеренные свойства
Условия выбора опираются на документированные возможности. Документация Ragas описывает метрику Faithfulness как долю утверждений ответа, поддержанных найденным контекстом, со шкалой от 0 до 1. Там же приведён разбор: ответ про дату рождения Эйнштейна делится на утверждения, каждое проверяется по контексту, и при одном поддержанном утверждении из двух оценка равна 0.5. Документация Ragas также описывает вариант FaithfulnesswithHHEM с классификатором HHEM-2.1-Open, который загружается на CPU с размером батча 10 по умолчанию.
Документация DeepEval описывает native FaithfulnessMetric как LLM-as-a-judge: метрика извлекает утверждения из actual_output и классифицирует каждое по retrieval_context. Утверждение считается truthful, если оно не противоречит фактам контекста. Формула — отношение числа truthful claims к общему числу claims. Документация DeepEval перечисляет три режима: llm, hybrid и system_one. В режиме hybrid классификацию выполняет модель System One, где вероятность выше 0.65 считается truthful, ниже 0.35 — противоречием, промежуток — пограничным случаем. В режиме system_one оценка приходит из ответов модели и представляет собой взвешенное среднее. Вычислительная цепочка отличается от режима llm.
Неизмеренные свойства остаются за пределами выбора. Документация DeepEval для RAGAS-метрик описывает RagasMetric как обёртку над библиотекой ragas: она усредняет четыре метрики — answer relevancy, faithfulness, contextual precision и contextual recall. Это отдельный путь, который разбирается особо. Совпадение имён метрик в двух библиотеках не даёт основания переносить числа.
Чужие benchmark, тарифы и непроверенные defaults
Числа из внешних обзоров в решение не переносятся. Обзор на evalsreview.com приводит собственные установочные прогоны, локальные замеры и два сторонних исследования, включая цены, время выполнения и число обращений к провайдеру. Эти значения получены в чужих условиях и не подтверждены первичной проверкой. Переносить их как актуальные факты нельзя.
Тарифы и лимиты провайдеров меняются независимо от библиотеки. Документация DeepEval в разделе частых вопросов объясняет зависание оценки: метрики LLM-as-a-judge обращаются к модели оценки, и при ограничении скорости, исчерпанной квоте или медленном ответе провайдера прогон может выглядеть остановившимся. Проверяются ключ провайдера, квота и сетевой доступ. Это возможная причина. Частота её возникновения здесь не измерялась.
Непроверенные defaults тоже требуют внимания. Документация DeepEval для FaithfulnessMetric перечисляет параметры: threshold со значением по умолчанию 0.5, model со значением по умолчанию, include_reason со значением True, strict_mode со значением False, async_mode со значением True, truths_extraction_limit со значением None, penalize_ambiguous_claims со значением False. Документация Ragas для FaithfulnesswithHHEM указывает устройство CPU и размер батча 10 по умолчанию. Эти значения принадлежат конкретной версии и конкретной метрике.
Число 0.7 встречается в примерах документации DeepEval как порог, заданный в коде примера. Это пример пользовательского порога. Универсальный default и редакционная рекомендация этим значением не устанавливаются.
Отрицательный случай, доступность API и актуальность пути
Отрицательный контроль строится на подмене условий. Берётся одинаковое имя Faithfulness, режим eval_mode не проверяется, и оценка 0.7 объявляется универсальным порогом. Такой вывод не принимается: в режиме system_one оценка приходит из взвешенного среднего ответов модели, а в режиме llm — из цепочки извлечения утверждений и классификации. Семантика различается, и обобщать её на все режимы нельзя.
Положительный контроль процедуры: одна и та же метрика, режим, версия, judge и шаблон; фиксированный датасет; отдельная ручная разметка. Здесь описан протокол. Фактических выходов двух прогонов в этом примере нет.
Доступность требуемого API проверяется до запуска. Документация Ragas в примере использует ChatOpenAI с моделью gpt-4o и OpenAIEmbeddings с клиентом openai. Там же отмечено, что ragas.embeddings.OpenAIEmbeddings предоставляет embed_text для одиночного текста и embed_texts для пакета, а методов embed_query и embed_documents у него нет. Пример вызывает embed_texts для документов и embed_text для запроса. Если код ожидает методы другого враппера, вызов упадёт.
Актуальность продуктового пути проверяется по документации. Документация Ragas помечает старый API метрик как legacy и указывает, что он будет объявлен устаревшим в версии 0.4 и удалён в версии 1.0, рекомендуя collections-based API. Документация DeepEval описывает локальный запуск и отдельно указывает, что Confident AI подключается опционально для продакшена. Проверка пути означает сверку с текущей документацией выбранной версии перед запуском.
Ограничения и статус ручного эталона
Ограничения фиксируются до интерпретации чисел. Ручной эталон остаётся разметкой человека. В учебном примере oracle отмечает, что число 20 не поддержано контекстом и противоречит 12. Это утверждение о ручной разметке. Score Ragas или DeepEval не вычислялся. Ни один из этих инструментов в примере не запускался.
Для реального применения фиксируются версия, метрика, режим, judge и шаблон. Документация DeepEval предупреждает: оценка в режиме system_one приходит из ответов модели, поэтому метрику следует держать в одном режиме при сравнении результатов между прогонами. Документация DeepEval для RAGAS-метрик указывает, что ragas возвращает NaN при невалидном JSON от модели, и RagasMetric передаёт это значение напрямую.
Проверка ошибок в учебном примере: ответ содержит утверждение, которого нет в контексте; ручная сверка помечает его как неподдержанное; метрика запускается только после этого. Если ответ противоречит контексту, ручная разметка фиксирует противоречие отдельно от неподдержанности.
Готовый промпт для извлечения утверждений из ответа перед ручной сверкой:
Ты помогаешь подготовить ручную разметку для оценки ответа RAG-системы.
Вопрос пользователя: [ваш вопрос]
Найденный контекст: [ваши фрагменты]
Ответ системы: [ответ вашей системы]
Эталонный ответ: [ваш эталон]
Разбей ответ системы на отдельные утверждения. Для каждого утверждения укажи:
1. Текст утверждения.
2. Поддержано ли оно найденным контекстом: да, нет или противоречит.
3. Фрагмент контекста, который подтверждает или опровергает утверждение.
Не выставляй числовую оценку. Не сравнивай с эталонным ответом. Верни таблицу.
Вариации той же задачи: разбор ответа на утверждения без эталона; сверка утверждений с эталонным ответом отдельно от контекста; список противоречий между ответом и контекстом; проверка, покрывает ли контекст вопрос пользователя; подготовка набора вопросов для датасета.
Частые вопросы
Ragas или DeepEval: что выбрать для RAG-пайплайна?
Выбор идёт от процесса команды. Документация Ragas описывает сбор датасета и запуск evaluate с метриками контекста и достоверности. Документация DeepEval описывает тест-кейсы и запуск через pytest. Обе библиотеки оценивают наборы и обе применимы в автоматизации.
Можно ли сравнивать числа Faithfulness из двух библиотек?
Сначала сопоставляются определения метрик, режимы, judge, шаблоны и версии. Документация DeepEval описывает три режима с разной семантикой. Одинаковое имя метрики не доказывает сопоставимость, а разные библиотеки могут случайно выдать одинаковое число.
Какие поля нужны для датасета?
Документация Ragas собирает user_input, retrieved_contexts, response и reference. Документация DeepEval для RAGAS-метрик требует input, actual_output, expected_output и retrieval_context. Для каждой метрики проверяется её собственный required input, и reference входит в набор полей датасета.
Что такое RagasMetric в DeepEval?
Документация DeepEval описывает RagasMetric как обёртку над библиотекой ragas, усредняющую четыре метрики: answer relevancy, faithfulness, contextual precision и contextual recall. Это отдельный путь, который разбирается особо при сравнении с native метриками DeepEval.
Почему оценка зависает или возвращает NaN?
Документация DeepEval объясняет зависание обращением к модели оценки при ограничении скорости, исчерпанной квоте или медленном ответе провайдера. Документация DeepEval для RAGAS-метрик указывает, что ragas возвращает NaN при невалидном JSON от модели. Проверяются ключ, квота и сетевой доступ.