Два уровня отказа в RAG‑системах
В традиционных больших языковых моделях (LLM) основной источник ошибок – неверная генерация текста. В RAG‑архитектуре (Retrieval‑Augmented Generation) отказ может происходить на двух независимых уровнях: retrieval (поиск релевантных фрагментов) и generation (синтез ответа).
- Retriever может вернуть нерелевантные чанки, упустить необходимые документы или неправильно их ранжировать.
- Generator способен проигнорировать полученный контекст и сформировать ответ, опираясь исключительно на свои внутренние веса.
Эти два типа ошибок требуют разных подходов к измерению качества и к автоматизации контроля.
Метрики, покрывающие обе поверхности
RAGAS – набор специализированных метрик
Для оценки качества RAG‑системы часто используют набор RAGAS, который включает четыре ключевых показателя с практическими порогами:
| Метрика | Целевой порог | Что измеряется |
|---|---|---|
| Faithfulness | ≥ 0.80 | Степень соответствия ответа исходному документу (отсутствие выдумок). |
| Context Precision | ≥ 0.70 | Доля использованных в ответе фрагментов, действительно относящихся к запросу. |
| Context Recall | ≥ 0.70 | Доля всех релевантных фрагментов, попавших в набор контекста. |
| Answer Relevancy | ≥ 0.70 | Насколько полученный ответ соответствует задаче пользователя. |
Эти метрики учитывают как качество извлечения, так и генерацию, поэтому они более информативны, чем традиционные оценки только финального текста.
Классические 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 выглядит так:
- Подготовка тестовых наборов – фиксированные запросы и эталонные документы хранятся в репозитории.
- Запуск RAGAS и IR‑метрик – через
pip install ragasи скрипты Python рассчитываются все показатели. - Проверка порогов – если любой из порогов не достигнут, pipeline завершается с ошибкой.
- Security‑тесты – Promptfoo исполняет сценарии document poisoning и context injection; отклонения фиксируются в отчёте.
- 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‑решения надёжными и готовыми к масштабному продакшн‑использованию.