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

Чек-лист вывода RAG в продакшн: безопасность, оценка качества, observability, контроль стоимости и управление жизненным циклом контента.

> For the index of this section of the site, see [llms.txt](https://anetlab.com/llms.txt)

17 октября 2026 г.8 мин чтения

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

Чек-лист вывода RAG в продакшн: безопасность, оценка качества, observability, контроль стоимости и управление жизненным циклом контента.

[Виктор Бузин](https://anetlab.com/about.md) · Founder & Principal Engineer, AnetLab

16+ лет в enterprise-разработке: .NET, AI/LLM-системы, RAG, MCP. Автор материала и практик в студии.

## Почему 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 влиять на ответы.

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

| Направление | Основной владелец | Обязательные меры | Типичный сбой | Гейт релиза |
| --- | --- | --- | --- | --- |
| Security | Security + platform | ACL enforcement, redaction, injection defenses | Утечка данных | Пройти negative-access tests |
| Evaluation | ML + product | Gold set, regression suite, human review | Скрытая деградация качества | Достичь baseline metrics |
| Observability | SRE + platform | Traces, logs, dashboards, alerts | Недиагностируемые инциденты | Трассировать каждый запрос |
| Cost control | Platform + finance | Budgets, caching, model tiers | Взрыв token spend | Уложиться в бюджет |
| Governance | Data + content owners | Freshness, deletion, versioning | Устаревшие или неверные ответы | Подтверждён rollback path |

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

Сделайте простую схему слева направо из пяти блоков: 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: четыре решения, которые всё определяют](https://anetlab.com/blog/enterprise-ai-architecture.md)
*   [RAG на .NET: архитектура, которая переживает продакшн](https://anetlab.com/blog/rag-na-dotnet.md)
*   [.NET и Azure для AI-систем: референсная архитектура](https://anetlab.com/blog/dotnet-azure-ai-architecture.md)
*   [Как вывести AI PoC в продакшн: 90 дней по фазам](https://anetlab.com/blog/ai-poc-to-production.md)

## CTA

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

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

Прогнать чек-лист по своей системе и получить разбор с приоритетами поможет [технический аудит](https://anetlab.com/contact.md) — вернём список реальных пробелов, а не общий список пожеланий.

Читайте также

20 октября 2026 г.AI/LLM

### [Оценка качества RAG на .NET: Recall@5, MRR и гейт релиза](https://anetlab.com/blog/rag-evaluation-dotnet.md)

Как измерять качество RAG на .NET: Golden Set из 50–100 вопросов, расчёт Recall@5 и MRR, измерение faithfulness и eval-как-гейт-релиза в CI.

[Читать разбор](https://anetlab.com/blog/rag-evaluation-dotnet.md)

[.NET](https://anetlab.com/blog?tag=.NET)[RAG](https://anetlab.com/blog?tag=RAG.md)[Оценка качества](https://anetlab.com/blog?tag=%D0%9E%D1%86%D0%B5%D0%BD%D0%BA%D0%B0%20%D0%BA%D0%B0%D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%B0.md)

18 октября 2026 г.AI/LLM

### [Архитектура enterprise AI: четыре решения, которые всё определяют](https://anetlab.com/blog/enterprise-ai-architecture.md)

Практическое руководство по архитектуре корпоративных AI-систем: RAG против дообучения, агенты против workflows, оценка качества и governance.

[Читать разбор](https://anetlab.com/blog/enterprise-ai-architecture.md)

[Архитектура](https://anetlab.com/blog?tag=%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0.md)[Оценка качества](https://anetlab.com/blog?tag=%D0%9E%D1%86%D0%B5%D0%BD%D0%BA%D0%B0%20%D0%BA%D0%B0%D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%B0.md)