Production RAG: чек-лист из 50 пунктов для продакшна

Почему production RAG ломается на практике

RAG в демо выглядит просто: подключили векторный индекс, добавили prompt, получили ответы на основе документов. Но production-среда намного сложнее. Системе нужны аутентификация, авторизация, контроль доступа к документам, защита от prompt injection, работа со stale content, стабильная оценка качества, наблюдаемость, контроль latency и бюджета на токены. Без этого прототип может выглядеть хорошо на тестовом наборе и плохо работать на реальном трафике.

Этот чеклист предназначен для команд, которые выводят RAG в production. Он фокусируется на операционных рисках, а не на презентационных обещаниях. Используйте его на архитектурном ревью, security review, перед запуском и в регулярной эксплуатации.

Пять направлений ниже — не формальность: каждое закрывает конкретный класс отказов, который и выкашивает RAG на реальном трафике. Пройдите список честно, не закрывая пункты формулировкой «у нас это за политикой», — и получите не список пожеланий, а карту реальных пробелов.

Пять операционных направлений

Обычно production RAG нужно проверять по пяти направлениям:

1. Security и access control — пользователь видит только те данные, к которым у него есть доступ.
2. Evaluation и quality — качество retrieval и quality ответов измеряется регулярно и воспроизводимо.
3. Observability и debugging — каждый запрос можно трассировать от input до final answer.
4. Cost и performance control — latency, token spend и инфраструктурные расходы остаются под контролем.
5. Content lifecycle governance — ingestion, freshness, удаление, ownership и rollback управляются явно.

Чеклист по направлениям

1) Security и access control

• Аутентификация выполняется до обращения к RAG service.
• Авторизация проверяется на уровне document, row, tenant или ACL, а не только в UI.
• Server-side retrieval filters нельзя обойти через prompt manipulation.
• Защита от prompt injection работает и для пользовательского ввода, и для retrieved content.
• Sensitive fields редактируются или маскируются до индексации, если это требуется.
• Secrets, API keys и credentials не попадают в prompt или logs.
• Политики хранения данных определены для chat transcripts, traces и embeddings.
• External tools и MCP connectors работают только по allowlist и с ограниченным scope.
• Tenant boundaries проверяются негативными test cases.
• Security review покрывает jailbreaks, exfiltration и unsafe tool invocation.

Разбор: security trimming на уровне Claims

В проекте с документацией заказчика — десятки тысяч документов, десятки гигабайт — доступ различался на уровне отдельного документа, а не папки и не роли. Каждому пользователю соответствует свой набор claims, и ответ должен собираться только из разрешённых ему чанков.

Наивный способ — добавить фильтр по права прямо в запрос к векторному индексу — даёт тихую деградацию: сужение кандидатной выборки снижает recall, и качество проседает без единой ошибки в логах. На таком объёме это особенно заметно: отсечение половины корпуса внутри запроса превращает поиск по индексу в почти полное сканирование. Рабочая схема — post-retrieval trimming: кандидаты извлекаются с запасом, отсекаются по claims и только потом идут в генерацию.

Отсекалось в среднем 10–20% кандидатов: права в основном совпадали с корпусом, поэтому основная работа ушла не на фильтрацию, а на индексацию. При объёме в десятки тысяч документов эмбеддинги считаются офлайн-батчем, а пользователю достаётся поиск по готовому индексу — и именно эта разница между офлайном и рантаймом решает, успеет ли система отвечать.

public sealed class ClaimTrimmingRetriever(
    IRetriever retriever,
    ILogger<ClaimTrimmingRetriever> logger)
{
    // Запас нужен именно из-за отсечения: при k = 8 и 20 % отсечённых
    // документов на генерацию попадёт около шести релевантных чанков.
    private const int OverFetchFactor = 4;

    public async Task<IReadOnlyList<Chunk>> RetrieveAsync(
        string query, ClaimsPrincipal user, int topK, CancellationToken ct)
    {
        var candidates = await retriever.SearchAsync(query, topK * OverFetchFactor, ct);

        var allowed = candidates
            .Where(c => user.HasPermission(c.Acl))
            .ToList();

        logger.LogInformation(
            "trimmed {Trimmed} of {Fetched} chunks for {User}",
            candidates.Count - allowed.Count, candidates.Count, user.Identity?.Name);

        return allowed.Take(topK).ToList();
    }
}

Три правила, которые из этого следуют и которые чаще всего нарушают:

1. Отсечка — строго между retrieval и генерацией. Модель, увидевшая лишний чанк, уже получила данные. Проверка «после генерации» — не защита, а признание утечки.
2. Доля отсечённых — метрика, а не строчка в логе. Если она растёт, ACL и корпус разошлись: документы есть, а прав на них нет. Это сигнал разбирать качество источника, а не крутить порог.
3. Область доступа входит в ключ кэша. Иначе ответ, собранный для одного набора прав, отдаётся другому пользователю.

// Область доступа — часть ключа, а не проверка после чтения.
var cacheKey = $"{scope.TenantId}:{scope.PermissionSetHash}:{query}";

2) Evaluation и quality

• Есть gold set из типовых вопросов и ожидаемых результатов.
• Отслеживаются retrieval metrics, например recall@k или MRR.
• Answer quality оценивается отдельно от retrieval quality.
• Перед релизом запускаются tests на hallucination и groundedness.
• Измеряются empty-answer, partial-answer и wrong-answer rates.
• Для high-risk запросов включён human review.
• Regression tests покрывают chunking, embeddings, prompts и rerankers.
• Online feedback собирается в полезной форме, а не только thumbs up/down.
• Evaluation stratified по языку, tenant, типу контента и типу запроса.
• Критерии релиза задокументированы и обязательны для rollout.

3) Observability и debugging

• У каждого запроса есть trace ID, связывающий input, retrieval, reranking и generation.
• В логах видны version model, embedding version, index version и prompt template version.
• Retrieval candidates и scores доступны для отладки.
• Tool calls и external calls логируются вместе с latency и status.
• Ошибки различают retrieval miss, timeout, guardrail block и model error.
• Дашборды показывают latency percentiles, error rates, token usage и cache hit rates.
• Sampling настроен так, чтобы sensitive content не попадал в логи сверх меры.
• Есть alerts на latency regression, cost spikes и quality drops.
• Postmortem позволяет восстановить точный путь ответа.
• On-call команда знает, где искать причину падения retrieval quality.

4) Cost и performance control

• Определены token budgets на запрос, tenant и workflow.
• Context window минимально достаточен для задачи.
• Chunking strategy снижает wasteful retrieval и дублирование контекста.
• Reranking включается только там, где он реально улучшает качество.
• Используется caching для embeddings, retrieval results и безопасных шаблонов ответов.
• Ingestion, reindexing и evaluation выполняются batch job-ами, если latency не критична.
• Есть fallback для медленной, недоступной или слишком дорогой модели.
• Выбор модели основан на критичности задачи, а не на максимальном размере.
• Search latency и generation latency измеряются отдельно.
• Регулярно пересматривается cost per answer и cost per resolved query.

5) Content lifecycle governance

• Для каждого corpus определён source of record.
• Ingestion pipeline валидирует schema, encoding и deduplication.
• Stale content переиндексируется или истекает по понятному графику.
• Запросы на deletion распространяются на source data, indexes, caches и logs, если это требуется.
• Для каждого corpus назначен owner и escalation path.
• Есть versioning для documents, embeddings, prompts и policies.
• Процедуры rollback проверены для bad uploads и bad index builds.
• Corpus drift отслеживается по мере изменения контента.
• Правила localization и language-specific content определены.
• Устаревшие документы не должны silently влиять на ответы.

Матрица решений

Краткое описание диаграммы

Сделайте простую схему слева направо из пяти блоков: User request → Retrieval with ACLs → Rerank/guardrails → LLM generation → Logged response and feedback. Под retrieval покажите index, metadata filters и policy checks. Под generation покажите token budget и citation checks.

FAQ

1. Нужно ли закрывать все пять направлений до запуска?
Для production — да. Для узкого pilot возможны исключения, но каждое исключение должно иметь owner, срок и mitigation plan.

2. Достаточно ли vector search для качества RAG?
Обычно нет. Чаще нужны metadata filters, reranking, дисциплина prompt и цикл evaluation.

3. Как понять, что hallucinations реально уменьшаются?
Смотрите groundedness, citation accuracy и human-rated correctness на фиксированном gold set и на сэмплах реального трафика.

4. Где должен быть контроль доступа?
На границе сервиса и внутри retrieval. Проверок только в UI недостаточно.

5. Как часто нужно переоценивать систему?
После значимых изменений данных, prompt-ов, embeddings, rerankers или model version, а также по регулярному графику для отслеживания drift.

Похожие материалы

• Архитектура enterprise AI: четыре решения, которые всё определяют
• RAG на .NET: архитектура, которая переживает продакшн
• .NET и Azure для AI-систем: референсная архитектура
• Как вывести AI PoC в продакшн: 90 дней по фазам

CTA

Готовы укрепить свой RAG stack?

Если вы переводите RAG из prototype в production, используйте этот чеклист как launch gate и шаблон для регулярного review.

Прогнать чек-лист по своей системе и получить разбор с приоритетами поможет технический аудит — вернём список реальных пробелов, а не общий список пожеланий.