RAG 可观测性是什么
RAG 出错时最需要回答的是一个具体问题：这次答错，是改写跑偏、检索没召回、重排排错，还是生成端把材料读错？要能回答它，就必须把链路中间态完整记录下来——改写后的查询、召回片段 id 与分数、重排结果、真正进上下文的片段、模型与提示词版本、各环节耗时。这些数据同时是沉淀评测集的原料：用户差评或转人工的会话，打标后就能回流成回归用例。
基本信息
| 记录粒度 | 每次问答一条结构化记录，按 trace id 串联 |
|---|---|
| 必记字段 | 原问题、改写查询、召回与重排片段 id 及分数、进上下文片段、模型与提示词版本 |
| 耗时拆分 | 检索、重排、生成分别计时 |
| 常用工具 | Langfuse、LangSmith、Phoenix 等追踪平台 |
| 合规要求 | 问题与片段入库前脱敏，访问权限收窄 |
典型使用场景
- 线上排错：用户报“答错了”，按 trace id 取回全过程复现判断
- 评测集沉淀：低分与转人工会话打标后加入回归集
- 成本与延迟分析：按环节拆分耗时，定位优化重点
- 模型迭代对比：换模型或提示词后按版本分组比指标
- 容量规划：按召回条数与上下文长度统计资源消耗趋势
结构化日志示例
结构化日志示例
{"trace_id": "8f3a...", "question": "报销标准是多少",
"rewritten": "差旅费报销标准",
"retrieved": [{"chunk_id": "hr-3#c2", "score": 0.83}],
"reranked": [{"chunk_id": "hr-3#c2", "score": 0.91}],
"used_in_context": ["hr-3#c2"], "model": "large-v2", "prompt_version": "v3",
"latency_ms": {"rewrite": 320, "retrieval": 28, "rerank": 210, "generate": 2600}}关键字段与用途
| 字段 | 用途 | 缺失后果 |
|---|---|---|
| 改写查询 | 判断是否跑题 | 无法区分改写问题与检索问题 |
| 召回 id 与分数 | 复现检索层表现 | 调参无依据 |
| 进上下文片段 | 定位模型实际看到什么 | 误把召回内容当成模型输入 |
| 模型与提示词版本 | 按版本对比指标 | 质量变化无法归因 |
日志含用户问题与文档片段，属于敏感数据：写入前脱敏、访问权限收窄、保留期限按合规要求设定，并且不要把完整的系统提示明文落盘。