Аудит RAG-системы: чек-лист качества, безопасности и эксплуатации
Найдите слабый evidence path до того, как менять модель
Source lifecycle, retrieval, answer, safety controls, operations и исправляемые audit findings
AUDIT-RAG-9 — авторская public synthetic matrix с явными ограничениями, не certification или customer benchmark
аудит RAG системы, оценка качества RAG, безопасность RAG, RAG evaluation и чек-лист эксплуатации RAG
$ audit-rag --contract AUDIT-RAG-9
> bind: system version / intended audience / permitted corpus
> sample: current / stale / removed / denied / adversarial fixtures
> inspect: source / retrieval / answer / safety / operations
> classify: coverage / scope / retrieval / context / answer
> route: fix / retest / hold / release / owner-reviewАудит RAG-системы — это структурированная проверка пути от запроса до ответа, отказа, уточнения или human review. Это не проверка одного prompt и не рейтинг демо. Полезный вопрос звучит так: может ли команда объяснить, какой источник, scope, configuration и control привели к material answer — и исправить слабое место без догадок?
Широкую задачу внедрения покрывают RAG-системы и /ru/ai-specialist-armenia. Эта статья даёт long-tail criteria для технической диагностики, не заменяет эти landing pages, не сертифицирует compliance и не обещает результат.
Зафиксируйте область аудита и owner решения
Сначала назовите версию системы, аудиторию, разрешённые collections и решения, которые ассистент вправе поддерживать. Production RAG — это не только vector index: identity, access policy, ingestion, parsing, retrieval, ranking, prompt assembly, answer UI, tool boundary, monitoring и review process влияют на результат.
Для каждого важного route назначьте owner, который способен подтвердить допустимость поведения. Обычно это cited answer, clarification, no-answer, access denial, incident hold и human review. Если у route нет owner, dashboard не превратит его в control.
Вместо одной средней метрики используйте audit matrix
AUDIT-RAG-9 — авторская публичная matrix для architecture conversation. Она разделяет пять областей. Уровни не являются customer benchmark или certification: их задача — сделать видимым отсутствие доказательств.
| Область | Уровень 1: demo | Уровень 2: repeatable | Уровень 3: controlled | Evidence для аудита |
|---|---|---|---|---|
| Sources | файлы загружены | известны owner и revision | проверены lifecycle, removal и permitted scope | source register и sample locators |
| Retrieval | ответ выглядит правдоподобно | у queries есть expected evidence | filters, ranking и no-answer проверяются по срезам | declared evaluation set и run receipt |
| Answer | модель пишет prose | видны citations | material claims сверяются с current permitted evidence | cited-answer и failure fixtures |
| Safety | есть prompt warning | проверяется access | тестируются document trust, action gates и deny paths | denied-scope и injection fixtures |
| Operations | есть логи | записываются versions | redaction, ownership, alerts и rollback reviewable | decision receipt и release record |
Не сводите уровни в маркетинговое число. Зрелый retrieval не компенсирует непроверенный permission filter, а хороший текст не компенсирует неизвестную revision источника.
Начните с source и ingestion contract
Многие дефекты ответа возникают до retrieval. Проверьте owner каждой collection, способ approval источника, момент смены current revision, удаление документа и исчезновение derived chunks после removal. Посмотрите, как parser обрабатывает tables, scans, headers, дубликаты страниц и locales, а не считайте успешный upload доказательством пригодного evidence.
Подготовьте небольшой fixture set: current source, stale source, removed source, duplicate, restricted document и документ, у которого layout теряет важное условие. Желаемый результат не всегда answer. Restricted или removed source не должен становиться evidence только потому, что его embedding остался в index.
Диагностируйте retrieval до обвинения generation
Audit case нужен с declared question, permitted corpus, expected evidence и expected terminal route. Посмотрите retrieved locators, filter decisions, index version, top-k candidates и rank order. Затем классифицируйте failure:
- Coverage: нужный источник не ingested или stale.
- Scope: entitlement, tenant, locale или metadata filter исключил нужный source либо допустил чужой.
- Retrieval: query, chunking или ranking не принесли expected evidence в candidate set.
- Context: полезное evidence retrieved, но потерялось, противоречит само себе или dilute при assembly.
- Answer: evidence было доступно, но ответ сделал unsupported claim или пропустил boundary.
Эта последовательность не даёт преждевременно менять модель. Метрики retrieval помогают объявить evidence set и denominators, а observability RAG — связать incident с versioned route.
Проверьте access и границу unsafe instructions
Security review должен быть конкретным. Убедитесь, что identity и entitlement применяются до retrieval, source locators имеют отдельный access control, а revocation меняет eligibility. Проверьте, может ли текст из документа переопределить application policy, вызвать tool или обойти approval path. Он не должен этого делать.
Запустите безвредные fixtures: denied scope, cross-tenant search, stale access, instruction-like document content и action proposal. Expected routes должны быть явными: deny before retrieval, answer только по permitted current evidence, no-answer, clarification или review. Prompt injection через документы подробнее объясняет границу evidence и authority.
Приоритизируйте исправления по вреду, охвату и проверяемости
Первой задачей редко оказывается самая низкая автоматическая метрика. Приоритет получает дефект с существенным вредом, большим охватом, слабым detection и узким проверяемым исправлением. В audit report фиксируйте observed case, evidence, failure class, owner, recommended correction, verification fixture и release decision.
$ audit-rag --contract AUDIT-RAG-9
> bind: system version / intended audience / permitted corpus
> sample: current / stale / removed / denied / adversarial fixtures
> inspect: source / retrieval / answer / safety / operations
> classify: coverage / scope / retrieval / context / answer
> route: fix / retest / hold / release / owner-reviewНе оставляйте vague recommendations. Report становится рабочим, когда у finding есть воспроизводимый fixture и условие закрытия. Например, «исправить metadata» превращается в: «current HR-policy fixture возвращает только permitted revision X; revoked fixture выдаёт denial; run receipt содержит policy и index versions».
Что должно быть в итоговом отчёте
Короткий аудит содержит scope и exclusions, architecture map, maturity matrix, test fixtures, findings по routes и failure classes, приоритизированный remediation backlog, evidence links, owners и решение release/hold. Отдельно назовите то, что не проверяли: coverage customer corpus, legal interpretation, penetration testing и production latency — это разные scope, если они не были явно включены.
AUDIT-RAG-9 — public synthetic engineering pattern, не security guarantee, compliance assessment или customer result. Он полезен для controlled technical review: сделайте routes и evidence наблюдаемыми, исправьте наименьшее подтверждённое слабое звено, повторите fixture и сохраните decision receipt. Для scoped architecture review начните с RAG-систем или /ru/ai-specialist-armenia.
require(scope.audience && scope.permittedCorpus && scope.systemVersion);
require(fixtures.current && fixtures.stale && fixtures.removed && fixtures.denied);
require(receipt.policyVersion && receipt.indexVersion && receipt.terminalRoute);
if (source.removedButEligible) route = "hold-and-reconcile";
if (scope.denied) route = "deny-before-retrieval";
if (evidence.missing) route = "clarify-or-no-answer";
if (claim.unsupported || action.ungated) route = "hold-for-review";