Как построить eval пайплайн для RAG-агента: кейс Битрикс24

Почему eval пайплайн - это не опция, а базовая гигиена

Типичная история: вы запилили RAG-агента для Битрикс24. Он тащит документы из базы знаний, отвечает на вопросы менеджеров. Первые дни всё супер. Потом кто-то меняет шаблон документа, кто-то добавляет новую сущность - и агент начинает нести чушь. Но вы узнаете об этом только когда клиент присылает скриншот с абсурдным ответом. Знакомо?

Без eval пайплайна вы летите вслепую. Вы не знаете, улучшили ли систему или сломали. В 2026 году, когда RAG-агенты уже не игрушка, а часть бизнес-процессов (особенно в таких системах как Битрикс24), оценка качества - это must have. Нельзя доверять LLM без измерителя. Eval пайплайн - это ваш приборная панель, которая показывает, не разбились ли вы.

Конечно, можно продолжать тестировать агента вручную - задавать десять вопросов и смотреть, не галлюцинирует ли. Это работает ровно до того момента, пока у вас не появится второй агент, третий, а потом прилетает задача "выкатить обновление до обеда". Тут-то и выясняется, что ручные тесты не воспроизводимы, метрики не сходятся, а прошлая версия была лучше. Но вы это уже знаете, иначе бы не читали эту статью.

Проблема: что именно мы оцениваем?

RAG-агент состоит из двух этапов: retrieval (поиск релевантных документов) и generation (формирование ответа). И их надо оценивать по отдельности.

Типичная ошибка - мерять только качество ответа. Если ответ классный, но контекст взят не из тех документов - агент всё равно опасен. Он может быть прав случайно. А в Битрикс24, где документация по продукту меняется каждую неделю, это критично.

Поэтому eval пайплайн обязан включать метрики для обоих этапов.

Метрики для retrieval

• Recall@K - доля релевантных документов среди K возвращённых. Показывает, не упустили ли мы важный контекст. Для К часто берут 3-5.
• MRR (Mean Reciprocal Rank) - насколько высоко в выдаче первый релевантный документ. Если нужный документ на 10-м месте - беда.
• Precision@K - сколько из возвращённых документов действительно релевантны. Помогает не зашумлять контекст мусором.

Метрики для генерации

• Faithfulness - фактологическая согласованность ответа с предоставленным контекстом. Никаких выдумок.
• Answer Relevancy - насколько ответ попадает в вопрос. Бывает, агент отвечает правильно, но не на то, что спрашивали.
• Context Precision - насколько контекст, выбранный для генерации, релевантен вопросу. Позволяет отловить ситуации, когда агент игнорирует найденные документы.

Все эти метрики (кроме разве что MRR) можно считать автоматически с помощью RAGAS и LLM-as-a-judge. Но обо всём по порядку.

Решение: пошаговый план построения eval пайплайна на Python

Перейдём к делу. Ниже - проверенный на бою (точнее, на пяти сотнях вопросов из реального Битрикс24) план. Каждый шаг содержит код, промпты и грабли.

1 Собираем датасет для оценки

Без качественного датасета eval пайплайн - профанация. Откуда брать данные?

• Реальные логи. Выгрузите вопросы из чатов поддержки Битрикс24. Это золото. Но часто таких вопросов мало, и они однотипны.
• Синтез с помощью LLM. Скармливаете пару десятков документов из базы знаний и просите GPT-4o придумать вопросы, на которые эти документы отвечают. Потом вручную чистите.
• Продакшн данные. Если агент уже работает - логируйте запросы и ответы, потом размечайте ground truth.

Важно: на каждый вопрос нужно подготовить эталонный ответ и список id релевантных документов (chunk-ов). Это самая дорогая часть. Для Битрикс24 я советую начать со 100 вопросов. Этого достаточно, чтобы отлавливать явные регрессии.

Формат датасета для RAGAS:

dataset = {
    "question": ["Как создать сделку в Битрикс24?"],
    "answer": ["Перейдите в раздел CRM, нажмите Создать сделку..."],
    "contexts": [["Для создания сделки откройте CRM...", "В CRM есть кнопка Создать сделку..."]],
    "ground_truth": ["Для создания сделки зайдите в CRM и выберите Создать сделку."]  # опционально
}

2 Поднимаем retrieval и генерацию

Допустим, ваш агент уже работает. Но для eval пайплайна нужно зафиксировать версию пайплайна. Заморозьте код, чтобы при изменении документации не валились тесты.

Пример настройки гибридного поиска (BM25 + эмбеддинги) с помощью LangChain:

from langchain_community.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
from langchain_chroma import Chroma
from langchain_openai import OpenAIEmbeddings

# загружаем документы
bm25_retriever = BM25Retriever.from_texts(docs, k=3)
vectorstore = Chroma.from_texts(docs, OpenAIEmbeddings(model="text-embedding-3-large"))
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

ensemble = EnsembleRetriever(retrievers=[bm25_retriever, vector_retriever], weights=[0.3, 0.7])

Промпт для генерации - отдельная песня. Не стоит использовать дефолтный. Подробные шаблоны смотрите в статье “Промпты для RAG: готовые шаблоны, которые не дадут ИИ наврать”. Отмечу, что для Битрикс24 критично указывать формат ответа: например, ссылки на конкретные разделы CRM.

3 Подключаем RAGAS и считаем метрики

Устанавливаем RAGAS и запускаем оценку:

pip install ragas==0.4.1

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall

dataset = load_your_dataset()
result = evaluate(dataset, metrics=[faithfulness, answer_relevancy, context_recall])
print(result.to_pandas())

RAGAS внутри использует LLM для оценки. По умолчанию - GPT-4o. Если вы работаете с русскоязычными документами, советую переключиться на GigaChat Pro (последняя версия на июнь 2026) - он дешевле и на русском не хуже.

from ragas.llms import LangchainLLM
from langchain_community.chat_models import GigaChat

gigachat = GigaChat(model="GigaChat-Pro", verify_ssl_certs=False, temperature=0.0)
for metric in [faithfulness, answer_relevancy]:
    metric.__setattr__('llm', LangchainLLM(gigachat))

4 Добавляем LLM as a judge для субъективных метрик

RAGAS-метрики в основном анализируют факты. Но есть аспекты, которые не укладываются в бинарные шкалы: “полезно ли ответил агент?”, “понятно ли объяснение?”, “не перегружен ли текст терминами?”. Тут на помощь приходит LLM as a judge.

Вы передаете второй LLM (не той, что генерировала ответ) промпт с вопросом, контекстом, ответом агента и просите оценить по шкале от 1 до 5. Пример промпта для оценки полезности:

judge_prompt = """Оцени ответ помощника по шкале от 1 до 5 по критериям:
- Полнота: ответ покрывает все необходимости пользователя?
- Точность: нет ли фактических ошибок относительно документации?
- Ясность: ответ легко понять?

Вопрос: {question}
Контекст: {context}
Ответ агента: {answer}

Выведи только число от 1 до 5."""

Проблема: judge-модели склонны к bias (например, GPT-4o предпочитает длинные ответы). Решение - усреднять по трем запускам или использовать ансамбль моделей. Для Битрикс24 я делал так: три judge (GPT-4o, Claude 4 Opus, GigaChat Pro) и берется медианная оценка. Дорого, но позволяет отловить галлюцинации, которые пропустила одна модель.

Более глубокий подход к автономному тестированию LLM описан в статье “Автономный агент для бенчмаркинга LLM: тестируй модели на своих данных без головной боли”.

5 Автоматизируем в CI/CD

Теперь объединим всё в пайплайн, который будет запускаться при каждом изменении кода или данных. Пример для GitHub Actions:

name: RAG Eval
on: [push]
jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install -r requirements.txt
      - run: python run_eval.py
      - name: Check metrics
        run: python check_thresholds.py --faithfulness 0.85 --answer-relevancy 0.7

В check_thresholds.py вы сравниваете метрики с пороговыми значениями. Если метрика упала ниже порога - пайплайн красный. Пороги нужно подбирать опытным путем. Для начала: faithfulness >= 0.85, answer_relevancy >= 0.7, context_recall >= 0.8.

Нюансы и типичные ошибки

За полгода эксплуатации eval пайплайна на Битрикс24 мы собрали грабли. Вот главные:

• Датасет перекашивает. Если в датасете 90% вопросов про сделки, агент может начать отвечать про сделки на любой вопрос. Нужно следить за распределением тем.
• Judge-модель либеральничает. GPT-4o часто ставит 5 из 5, даже если ответ не идеален. Калибруйте: подмешивайте заведомо плохие ответы и смотрите, насколько оценка падает.
• Стоимость каждого запуска. 100 вопросов * 3 judge модели = 300 вызовов LLM. На CI каждом пуше это становится дорого. Решение: кэшировать результаты retrieval (если документы не менялись) и использовать для judge маленькую модель (например, Llama 4 Instruct 8B через API).
• Проклятие полноты. Ответ может быть верным фактологически, но совершенно бесполезным: "Для создания сделки войдите в CRM и нажмите создать". А пользователь хотел узнать про автозаполнение полей. Для этого и нужна метрика Answer Relevancy и judge-оценка полезности.

В 2026 году RAG сталкивается с новыми вызовами: хакеры атакуют, таблицы сопротивляются, а фейки процветают. Об этом мы писали в обзоре “RAG в 2026: хакеры атакуют, таблицы сопротивляются, а фейки процветают”. Eval пайплайн - лучшая защита от регрессий, но он не панацея. Если модель атакуют prompt injection-ом, метрики могут ничего не показать.

Мой неочевидный совет

Не пытайтесь построить идеальный eval пайплайн с первого раза. Начните с 10 вопросов и одного документа. Пусть это будет критичный сценарий, например, "Как восстановить пароль в Битрикс24?". Добейтесь, чтобы агент отвечал на него стабильно хорошо. Затем постепенно расширяйте датасет. Иначе рискуете потратить месяц на настройку метрик и так и не начать оценивать.

Помните: eval пайплайн нужен не для галочки, а чтобы быстро находить проблемы до того, как их увидят пользователи. В Битрикс24 цена ошибки может быть потерянной сделкой. Не дайте агенту ее провалить.

Подписаться на канал