Суть
RAG Metrics меряет качество offline — на golden-наборе с порогами (Hit Rate, Faithfulness и т.д.). Online-observability отвечает на другой вопрос: что и почему сломалось на живом трафике — когда golden-набор уже пройден, а в проде ответы деградируют.
Зачем это нужно
Главная ловушка прод-RAG: фейлы выглядят как проблемы LLM, а на деле это проблемы retrieval — модель «уверенно ошиблась» не потому что галлюцинировала, а потому что добросовестно рассуждала по неверному (например, устаревшему) контексту. Без трейсинга retrieval эти два режима отказа неразличимы.
Как работает
- Retrieval tracing — логировать событие
chunk_retrieved(какие чанки и с какими скорами пришли), а не только финальный вывод LLM. - Chunk-level attribution на запрос — фиксировать, какие чанки реально попали в контекст → разделяет retrieval-проблему (не те документы) и generation-проблему (верный контекст проигнорирован).
- Index version attribution — писать версию/alias индекса (см. Vector Store Persistence) в каждый retrieval-span → можно скоррелировать падение качества с обновлением индекса («качество упало во вторник» → отфильтровать трейсы по новой версии, сравнить со старой). Это детектор drift.
- 3 production-слоя: indexing pipeline + retrieval layer + observability layer (трекинг retrieval-качества во времени + связь версий индекса с регрессиями ответов). Без observability-слоя «работало на staging» молча отдаёт устаревшее/неверное в проде.
- Инструменты (Arize Phoenix, LangSmith, Langfuse) — см. ландшафт в RAG Metrics; на уровне агента/графа — LangGraph Observability.
Состав спана и порог алерта
Минимальный набор полей — тот, по которому можно восстановить, почему пришёл именно этот контекст: идентификаторы чанков, их score, версия индекса и модели эмбеддингов, число кандидатов до и после реранкинга, латентность этапа. Версия индекса здесь не формальность: без неё нельзя отличить «поиск сломался» от «переиндексировали и стало иначе», а это самая частая причина внезапного падения качества. Раскладывать поля стоит по конвенциям OpenTelemetry GenAI, чтобы трейс читался любой платформой (OpenInference).
Порог алерта ставится не абсолютным значением метрики, а относительно её же baseline: p95 за прошлую неделю по этому типу запросов, множитель калибруется на своей истории (Agent Observability, Cost Anomaly Alerting). Специфика retrieval-дрейфа в том, что он ступенчатый, а не плавный: качество падает в момент переиндексации или смены модели эмбеддингов, поэтому полезнее не порог на значение, а сравнение до/после версии индекса — именно она и есть та переменная, которая меняется скачком.
Связано с
- RAG Metrics — offline-метрики качества ↔ online-трейсинг (эта заметка) = две стороны оценки RAG
- RAG — observability-слой поверх retrieval-конвейера
- Vector Store Persistence — версия индекса в трейсе ↔ alias/версионирование индекса
- LangGraph Observability — observability на уровне агента (трейсинг шагов/tools), здесь — на уровне retrieval