Observability для RAG: какие события и контексты логировать

Observability RAG — не просьба хранить каждый prompt, passage и completion навсегда. Его задача — дать owner точный инженерный ответ: какой route прошёл запрос, какие versioned evidence были eligible и где результат стал unsafe, недоступным или бесполезным?

Для этого нужен receipt, а не архив наблюдения. Receipt сохраняет связанные events, достаточные для проверки failure class, но минимизирует sensitive content. Широкую задачу продукта и внедрения покрывают RAG-системы и /ru/ai-specialist-armenia. Эта статья поддерживает их implementation criteria, не подменяет commercial intent и не обещает compliance.

Сначала определите наблюдаемое решение, потом выбирайте tracing tool

Начните с routes, по которым системе разрешено идти. Запрос может вернуть cited answer, попросить clarification, дать no-answer, отказать в доступе или ждать review. Для каждого route назовите owner, который способен определить, был ли он ожидаемым. Затем сохраните stable requestReceiptId, версии конфигурации и безопасные references на relevant inputs.

OBSERVE-8 связывает четыре records:

Идентификатор не становится безопасным автоматически. Делайте cross-system IDs opaque, ограничивайте access к raw events и согласуйте retention с владельцем данных. Не записывайте prompt или excerpt документа только потому, что по полю удобно искать.

OBSERVE-8: event flow с границей redaction

Workflow отделяет product behavior от telemetry behavior. Authorization решает, можно ли начинать retrieval. Retrieval отдаёт counts и permitted locators, а не весь candidate payload. Отдельный шаг redaction удаляет или хеширует поля, которым не место в operational telemetry. Routing сохраняет, почему система ответила, уточнила, отказала, остановилась или отправила case на review.

request -> authorize -> retrieve eligible evidence -> compose bounded proposal
        -> redact telemetry fields -> evaluate route -> answer | clarify | deny | review
        -> link receipt IDs, versions and reason codes

Source locator нуждается в независимом access rule: reviewer с доступом к trace всё ещё может не иметь права открыть underlying customer document. И наоборот, support dashboard не должен собирать secret из fragments events. Контроль доступа RAG раскрывает upstream eligibility, а метрики retrieval — измерения в declared evaluation set.

Выбирайте events, которые объясняют failure без записи разговора

Полезные events узкие и typed. Они фиксируют transition, version или reason code, а не неограниченный prose blob. Начать можно с такой event family:

Bounded samples сохраняйте только там, где их требует approved incident process. Храните sample отдельно, encrypt и access-control его, добавляйте expiry и отражайте решение в receipt. Это не то же самое, что незаметно класть полный content в каждый trace.

Проверьте один synthetic run от input до route

Используйте harmless fixture documents, чтобы проверить correlation до customer records. В synthetic example пользователь задаёт support question. Trusted scope разрешает одну current help collection; ожидаемый answer зависит от двух известных locators.

{
  "requestReceiptId": "obs_demo_017",
  "policyVersion": "rag-policy-2026-09",
  "indexVersion": "help-current-42",
  "events": [
    { "name": "request.accepted", "purpose": "support" },
    { "name": "retrieval.completed", "eligibleCount": 12, "selectedLocators": ["help:returns#v4", "help:delivery#v7"] },
    { "name": "evidence.selected", "coverage": "sufficient" },
    { "name": "route.decided", "route": "cited-answer", "reason": "permitted-current-evidence" }
  ]
}

Важно не число 12, а связь: reviewer находит policy и index version, видит permitted locators и отличает проблему evidence от routing problem. Если locator стал stale, synthetic test должен ожидать review или no-answer, а не уверенный stale response.

Тестируйте telemetry contract рядом с RAG contract

Observability тоже может ломаться. Добавьте к evaluation set и release process такие проверки:

1. Correlation. У каждого terminal route есть receipt ID, required version fields и bounded reason code.
2. Minimization. Deliberately sensitive fixture не появляется в permitted event fields, queryable dimensions или exported dashboards.
3. Authorization. Пользователь с trace access не открывает source locator без отдельного document policy.
4. Completeness. Simulated timeout, empty retrieval, denied scope и review route выдают ожидаемый terminal event ровно один раз.
5. Change detection. Изменение prompt, policy, index или tool даёт distinguishable version receipt; неизвестная version удерживает release для review.
6. Operational use. Owner проходит один synthetic receipt от symptom к route и выбирает next action, не читая customer conversation.

Держите результаты раздельно по route и risk class. Один average latency или answer score не докажет, что denied retrieval был правильно denied, no-answer — честным, а новая index version не убрала evidence. Route distribution может подсказать расследование, но сам по себе не доказывает качество продукта.

Сделайте review и retention частью production boundary

До включения нового trace field назовите purpose, audience, retention period, storage boundary и removal path. Перепроверьте поле при изменении prompt template, tool call, collection или downstream analytics destination. Если команда не может объяснить, зачем поле нужно, не собирайте его default.

OBSERVE-8 — авторский public engineering pattern, а не specification observability product, юридическая рекомендация или утверждение о безопасности RAG. Используйте его для controlled architecture review: определите terminal routes, докажите telemetry minimization synthetic fixtures и назначьте owners для redaction, access, retention и release decisions. Для scoped implementation discussion начните с RAG-систем или /ru/ai-specialist-armenia.