RAG‑тестирование: как обеспечить надёжную работу retrieval и генерации

Два уровня отказа в RAG‑системах

В традиционных больших языковых моделях (LLM) основной источник ошибок – неверная генерация текста. В RAG‑архитектуре (Retrieval‑Augmented Generation) отказ может происходить на двух независимых уровнях: retrieval (поиск релевантных фрагментов) и generation (синтез ответа).

• Retriever может вернуть нерелевантные чанки, упустить необходимые документы или неправильно их ранжировать.
• Generator способен проигнорировать полученный контекст и сформировать ответ, опираясь исключительно на свои внутренние веса.

Эти два типа ошибок требуют разных подходов к измерению качества и к автоматизации контроля.

Метрики, покрывающие обе поверхности

RAGAS – набор специализированных метрик

Для оценки качества RAG‑системы часто используют набор RAGAS, который включает четыре ключевых показателя с практическими порогами:

Эти метрики учитывают как качество извлечения, так и генерацию, поэтому они более информативны, чем традиционные оценки только финального текста.

Классические IR‑метрики для быстрой проверки retrieval

Для ранней диагностики работы ретривера удобно применять проверенные в информационном поиске показатели:

• Precision@K – доля релевантных документов среди топ‑K результатов.
• Recall@K – доля всех релевантных документов, найденных в топ‑K.
• Mean Reciprocal Rank (MRR) – среднее обратное положение первого релевантного результата.

Эти метрики не требуют участия LLM‑судьи и позволяют быстро отсеять грубые проблемы с ранжированием.

Тесты на безопасность и устойчивость

RAG‑системы открыты к атакам, которые используют их способность принимать внешние документы. В набор тестов включаются:

• Document poisoning – подмена или добавление вредоносных фрагментов в базу знаний с целью изменить вывод модели.
• Context injection – внедрение скрытых инструкций в контекст, которые могут заставить генератор выполнить нежелательные действия.
• Cross‑tenant leakage – утечка данных между различными клиентами при мультиарендных развертываниях.

Для их реализации часто используют Promptfoo, инструмент, позволяющий описать сценарии атак и автоматически проверять их влияние на ответы модели.

Автоматизация в CI/CD: quality gate для knowledge base

Контроль качества RAG‑системы должен входить в конвейер поставки. Примерный workflow выглядит так:

1. Подготовка тестовых наборов – фиксированные запросы и эталонные документы хранятся в репозитории.
2. Запуск RAGAS и IR‑метрик – через pip install ragas и скрипты Python рассчитываются все показатели.
3. Проверка порогов – если любой из порогов не достигнут, pipeline завершается с ошибкой.
4. Security‑тесты – Promptfoo исполняет сценарии document poisoning и context injection; отклонения фиксируются в отчёте.
5. GitHub Actions / GitLab CI – все шаги описаны в YAML‑конфигурации, что обеспечивает воспроизводимость и прозрачность.

Такой подход превращает обновление knowledge base в quality gate: любые изменения в базе проходят автоматическую проверку, и только после успешного прохождения тестов они попадают в продакшн.

Практический пример конфигурации

name: RAG Quality Gate
on: [push, pull_request]

jobs:
  test-rag:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'
      
      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install ragas promptfoo
      
      - name: Run RAGAS metrics
        run: |
          python scripts/run_ragas.py \
            --queries data/queries.json \
            --docs data/docs/ \
            --output reports/ragas.json
      
      - name: Verify thresholds
        run: |
          python scripts/check_thresholds.py reports/ragas.json
      
      - name: Security tests (Promptfoo)
        run: |
          promptfoo test security.yaml --output reports/security.json
      
      - name: Fail on security issues
        run: |
          python scripts/check_security.py reports/security.json

В этом примере run_ragas.py собирает ответы модели, рассчитывает RAGAS и сохраняет результаты. check_thresholds.py сравнивает их с целевыми порогами, а check_security.py проверяет, не превысили ли атаки допустимые уровни отклонения. При любой ошибке CI‑pipeline останавливается, не позволяя слить изменения в основную ветку.

Итоги практического применения

Тестирование RAG‑системы требует двойного фокуса: retrieval и generation. Специфические метрики RAGAS дают полную картину качества, а классические IR‑показатели позволяют быстро диагностировать проблемы на этапе поиска. Безопасность измеряется через атакующие сценарии, реализованные в Promptfoo. Интеграция всех проверок в CI/CD обеспечивает автоматический quality gate, который защищает как точность ответов, так и целостность базы знаний. Такой комплексный подход делает RAG‑решения надёжными и готовыми к масштабному продакшн‑использованию.