Уверен, на Хабре найдётся немало статей, посвященных оценке качества RAG систем. Тема по-прежнему остаётся актуальной, потому что даже готовые библиотеки вроде RAGAS не очень-то работают из коробки, требуют навыков программирования и некоторой квалификации. При этом сам процесс оценки - повторение достаточно простых операций и мне всегда хотелось переложить его на AI-ассистента.
Повод попробовать появился неожиданно: свободное время и курс по Claude Code на Stepik. Для финала как раз нужен был проект, посвященный автоматизации реальной рутинной задачи, желательно без кода (курс про вайб-воркинг, для непрограммистов). Конечно, я сразу вспомнил про задачу оценки качества. Дальше - честная история со всеми проблемами. Забегая вперёд, скажу, что совсем без программирования не вышло. Но, может, это профессиональная деформация.
Шаг первый и первый фейл
Как начать? Я взял собственный готовый бенчмарк, таблицу с кейсами «вопрос; ответ; контекст» и отдал Клоду. Он быстро понял, что там русский язык UTF-8, но не определил разделитель полей, так как я использую точку с запятой в CSV, привычка. Дал подсказку. На что он сразу предупредил что будет гигантский расход токенов, а ещё ему нужен ключ, чтобы использовать SDK Anthropic. Ключа у меня нет, Клод предложил использовать эвристики на регулярных выражениях. Мы попробовали на одной метрике. Результат - 100% качество, что конечно жёсткая неправда. А ещё была путаница в чанках контекста, которые были склеены в один блок текста в бенчмарке.
Шаг второй. Внешняя модель
Регулярные выражения помогают только в одном случае, если в вопросе, контексте и ответе есть какой-то код, аббревиатура или шаблон, который легко извлечь. В других случаях нужен LLM-судья. И я решил его сделать на внешней модели. Выбрал gpt-4o-mini от прокси-провайдера, она часто используется в примерах для библиотеки RAGAS.
В RAGAS много метрик, не все из них полезны я планировал использовать только три. Они оценивают не качество ответа, а качество контекста, который система передаёт в модель.
Метрики
Точность контекста, Context Precision
оценивает, насколько высоко в выдаче RAG ранжированы чанки, полезные для правильного ответа. Чем выше полезный чанк, тем выше метрика.
Релевантность контекста, Context Relevance
оценивает, насколько высоко ранжированы чанки, релевантные вопросу пользователя. В отличие от Precision, не требует эталонного ответа.
Полнота контекста, Context Recall
оценивает, какая доля значимых фактов из эталонного ответа подтверждается найденным контекстом
Context Precision и Context Recall - метрики RAGAS. Context Relevance, если не ошибаюсь, нет. Она обычно получается выше чем Precision, нужно настраивать промпт, зато «не подсматривает в ответ».
В качестве первой пробной метрики решил взять Context Precision. Провёл пару экспериментов, Клод без проблем запускает скрипты из командной строки (пришлось сделать виртуальное окружение на Python). И главное - он не против внешних моделей для рутины, даже пишет, что это штатный режим, верим.
А вот проблема с парсингом контекста, если все чанки в одной ячейке таблицы, никуда не делась. Я попробовал вставлять в контекст разделители между чанками, оказалось не очень-то и надежно. Тогда появилась идея оставить в бенчмарке только вопрос и ответ, а контекст получать из RAG системы в процессе оценки каждого кейса. Это не только упростило подготовку бенчмарка, теперь я легко мог менять количество чанков в контексте.
Шаг третий. Сервис RAG и танцы вокруг MCP
План: сделать простенькую RAG систему с векторным поиском, добавить Model Context Protocol и далее использовать в субагентах. За пару часов я собрал её на FastAPI, LangChain и ChromaDB, загрузил туда тестовый контекст, всё проверил и решил добавить MCP. С библиотекой fastapi_mcp - пять минут работы.
Оказалось, не всё так просто. Клод упорно отказывался находить MCP сервер. Я прямо указывал на .mcp.json в проектной папке, на что он отвечал, что вероятно RAG система запущена после старта сессии, и что надо всё перезапустить. Ситуация повторялась снова и снова. Решил, что нужен какой-то тестер, нашёл MCP inspector (нужен Node.js).
Инспектор помог понять следующее - ни с каким видом транспорта (SSE, HTTP) моя система на запросы не отвечает, а вот если включить MCP Proxy, всё сразу начинает работать и в консоли появляется заветное 202 Accepted. Значит проблема в транспорте, который я использую. Ещё несколько экспериментов и решение было найдено, спасибо Google!
Решение
1. В блок импорта основного скрипта api.py добавить
from fastapi.middleware.cors import CORSMiddleware
2. Перед инструкциями app.include вставить блок кода
app.add_middleware(
CORSMiddleware,
allow_origins=["*"], # Or specify your Web UI's origin
allow_credentials=True,
allow_methods=["GET", "POST", "OPTIONS"],
allow_headers=["*"],
)3. Использовать mcp.mount() вместо mount_sse() или mount_http(), хотя это устаревшая инструкция.
Полагаю, что есть ещё варианты, которые решают проблему. Код сервера со всем необходимым - в репозитории. А README к нему, как и к этому проекту, подготовил Клод. Вот уж точно полезный навык.
Шаг четвертый. «Шумные» субагенты
Сделал два субагента — один для Context Precision, он «видит» из бенчмарка вопрос, ответ и получает контекст из RAG системы, второй — для Context Relevance. Этот, в отличие от первого, не видит ответа и оценивает контекст только по вопросу.
Клод без каких либо проблем справился с этими агентами. Увы, они оказались слишком шумными, контекстное окно засорялось прямо на глазах, по 1-2k на один кейс бенчмарка (у меня 48 кейсов и два варианта вопросов — попроще и посложнее). Клод предложил для субагентов добавить инструкцию «Do not narrate your steps between tool calls», это не очень помогло в плане токенов.
Шаг пятый. Легкий навык и инструменты
Единственное полезное, что я взял из предыдущего шага - формат отчета. По каждому кейсу мне нужна была следующая информация:
{
"case_id": 0,
"question": "question text",
"answer": "answer text",
"context": ["chunk_1", "chunk_2", "chunk_3", "chunk_4"],
"labels": [1, 0, 1, 1],
"explanation": ["explanation_1", "explanation_2", "explanation_3", "explanation_4"],
"score": 0.875
}Уточнив у Клода, в каком виде ему удобнее было бы с такой структурой работать, выяснил, что лучше всего подходит JSONL, текст, где каждая строка - отдельный JSON. На том и порешили.
Далее план был следующий — сделать инструмент с командной строкой (eval_context.py), который бы выполнял всю основную работу. Проходил последовательно по кейсам, запускал тесты и записывал результаты в отчёт. А навык всё запускал и управлял параметрами оценки.
Чтобы упростить код я взял свою готовую библиотеку CPCR_lib.py, это тоже обёртка для LLM-судьи, которая умеет выносить вердикт для оценок по всем трём метрикам.
Нужный класс импортируется в eval_context.py, так мы экономим токены на генерации промптов. Они не попадают в контекстное окно.
MCP в этой версии используется только как необязательная проверка доступности RAG системы. Оставил для будущих релизов. Все запросы — через REST API, что нормально для инструмента на Python. Если у кого-то получилось подключить FastAPI через MCP без дополнительных усилий, поделитесь, пожалуйста, рецептом в комментариях.
Объяснил Клоду изменения в архитектуре и попросил три вещи:
1. подготовить навык для работы с инструментом eval_context.py
2. сделать HTML вьювер для отчетов с учетом особенностей Recall (контекст склеен в один кусок,
а вместо чанков оцениваются факты)
3. подготовить дашборд для оценок по всем трём метрикам.
Навык
---
name: rag-evaluation
description: Запускает инструменты оценки качества RAG-системы, когда пользователь просит оценить RAG, запустить метрику, или произносит слова: «оцени», «запусти оценку», «рассчитай метрику», «Context Precision», «Context Relevance», «Context Recall».
---
# RAG Evaluation Skill
Этот skill запускает оценку качества RAG-системы по выбранной метрике.
## Trigger
Используй этот skill когда пользователь просит оценить RAG, запустить метрику, или произносит слова: «оцени», «запусти оценку», «рассчитай метрику», «Context Precision», «Context Relevance», «Context Recall».
## Процедура
### 1. Собери параметры
Используй инструмент `AskUserQuestion` — задай все четыре вопроса одновременно с вариантами для клика:
1. **Метрика** — `precision` / `relevance` / `recall`
2. **Benchmark файл** — `benchmark_simple.csv` / `benchmark_hard.csv`
3. **max_k** — `3` / `5` / `7`
4. **Количество кейсов** — `5` / `10` / `все`
### 2. Запусти скрипт
```powershell
venv\Scripts\python.exe eval_context.py --scenario <scenario> --benchmark benchmarks/<file> --max-k <max_k> --cases <cases>
```
Если пользователь не указал `--cases`, не передавай этот параметр (обработаются все кейсы).
### 3. Сообщи результат
После завершения скрипта сообщи пользователю:
- Mean метрику
- Путь к JSONL файлу
- Путь к Markdown отчётуAskUserQuestion - внутренний инструмент Клод, даёт пользователю выбор из вариантов и превращает это в текстовые инструкции.
Прошу не удивляться PowerShell, проект сделан на windows-машине.
Универсальный вьювер для отчетов: Кейсы детализируются. Есть вердикт по каждому чанку.
Дашборд для трех метрик. Красотища :) Можно посмотреть вклад каждого кейса в общую оценку.
Подвожу итог. Оценка качества для одной метрики в расчёте на 10 кейсов занимает примерно 2-3 минуты (RAG работает на CPU). Расход токенов минимальный, в районе 500-800 на метрику. В качестве судьи можно использовать локальную модель. Рекомендация: модель не хуже 27b.
Оценку по всем трем метрикам и всем кейсам в проекте я делал несколько раз. Суммарно на LLM-судью получилось около 2М токенов (примерно 60 рублей). И ещё около 415k токенов в Claude Code на разработку: в районе 400k на все предыдущие шаги и 15k на финальную часть вместе с тестами. В плане работы, если бы делал то же самое в Python-ноутбуках - написание скриптов, отладку кода, прогон кейсов, подготовка отчетов, анализ результатов - полагаю, это заняло бы неделю на весь бенчмарк.
Ссылки:
Репозиторий проекта
Репозиторий naive-rag-mcp сервера
Документация на fastapi_mcp
Метрики в RAGAS
Откуда взялся мой бенчмарк (статья)