RAG 链路 Trace 应该记录哪些信息？

简化版

RAG Trace 要串起一次请求的查询处理、过滤、召回、重排、上下文组装、模型生成、引用校验和最终反馈。每段记录版本、耗时、Token、候选/淘汰的文档 ID 与分数、权限决策和错误，但对原文、Prompt 和用户数据默认脱敏；用统一 trace_id 才能分层定位“没入库、没召回、没装入还是没用对”。

详细版

入口记录匿名主体/租户、query hash、语言与路由；检索记录 index/embedding/chunker 版本、filter AST、Top-k、chunk ID 和分数；rerank 记录模型与前后排名；packing 记录最终 source ID、Token 和截断原因；生成记录 Prompt/模型/参数版本、输入输出 Token、首 Token/P95、状态和 citations。

安全上不把敏感正文直接写普通日志，使用 ID、hash、长度与分类标签，受控短期 payload store 仅供授权回放。指标由 trace 聚合：分阶段延迟、零召回、证据 Recall、引用失败、无答案、缓存命中和成本。采样策略对普通成功请求低比例，对错误/高风险全采，并保证跨服务时钟和 span 父子关系正确。

request span
 ├─ rewrite/router
 ├─ retrieve/filter
 ├─ rerank
 ├─ pack
 ├─ generate
 └─ validate/citation/tool

完整版教学

一、为什么只有最终答案日志不够

用户看到错答，可能是文档未入库、过滤过严、召回排序差、上下文截断或模型没依据证据。只保存问题与答案无法区分这些层，团队会盲目改 Prompt。Trace 让每个中间决策可关联和重放。

可观测性不等于全量记录隐私原文。目标是保存足够的结构、版本和 ID，在有权限时可回源；默认日志应最小化内容。

二、Span 结构如何设计

一个请求为 root span，各阶段为 child span，工具/模型外部调用继续嵌套。每个 span 统一记录 start/end、status、retry、service 和 version。并行多查询检索可有多个 sibling span，随后 fusion span 汇总。

{"trace_id":"t1","span":"retrieve","parent":"root",
 "index_version":"idx-42","top_k":20,"latency_ms":83,
 "result_ids":["c17","c93"],"status":"ok"}

记忆钩子：Trace 要记录“做了什么选择、基于哪个版本、花了多久”，内容本身只在必要和授权时回放。

三、检索阶段记录哪些字段

保存原查询 hash、规范化/扩展 query 的 ID、filter AST、index snapshot、embedding 模型、ANN 参数和候选 chunk/document ID、raw/rerank 分数。权限过滤前后的数量要记录，但无权文档 ID 也需按安全策略限制可见。

阶段	关键字段	可诊断问题
入库	doc/chunker/embed版本	旧索引、切块错误
召回	query、filter、Top-k	漏召回、过严过滤
重排	输入/输出排名	真证据被降权
Packing	选中ID、Token、截断	证据被丢
生成	模型/Prompt、Token	忽略证据、成本
校验	claim/citation状态	不支持声明

候选与最终上下文必须都记，才能知道证据在哪一步消失。

四、生成与验证怎样记录

记录模型精确版本、Prompt manifest、temperature、max tokens、输入/输出 Token、TTFT、总延迟、finish_reason 和重试。最终渲染 Prompt 可保存加密短期快照或 hash+依赖，以满足复现与隐私平衡。

引用校验记录每个 claim 的 source_ids、validity、entailment 与权限结果。无答案应有 reason code，例如 no_retrieval_hit、insufficient_support、conflicting_sources，而不是统一 success=false。

五、隐私与安全边界

日志本身可能聚合用户问题、合同和模型答案，成为高价值敏感库。默认记录稳定 ID、hash、长度、分类和数值指标；正文进入权限隔离、加密、有保留期的 payload store，并对访问审计。密钥和凭据永不记录。

跨租户 dashboard 做聚合，不能显示单条文档标识给无权运维人员。用户删除请求要覆盖日志和 payload；采样也不能把高风险正文以“调试”为由永久保存。

六、从 Trace 聚合哪些指标

系统指标包括各 span P50/P95/P99、错误率、重试和队列时间；RAG 指标包括零结果、过滤后候选数、rerank 提升、context Token、无答案、citation failure；成本包括 embedding/LLM Token 与 cache hit。质量标签通过 feedback_id 回连 trace。

假设总 P95 2.4秒，其中 retrieval 0.1、rerank 0.8、generate 1.3、其他 0.2，优化向量库收益有限。若真证据候选中出现但最终 context 没有，重点修 packing。Trace 使性能和质量优化都有证据。

七、采样与回放

全量详细 payload 成本与隐私压力高。可全量保留轻量 metadata，对成功请求 1% 保存详细 trace，对错误、低置信、权限拒绝和高延迟全采样。采样决定应尽量在结果后做 tail-based sampling，否则事前不知道哪些是异常。

回放环境固定索引快照、Prompt/模型版本和候选 ID。外部模型可能不可完全复现，仍可比较结构输出和阶段行为。生产 payload 回放到测试环境前先脱敏，禁止意外调用真实写工具。

八、常见误区与追问

误区：记录最终 Prompt 和答案就叫可观测。 缺候选、过滤和版本，无法定位链路故障。
误区：为了调试应永久全量保存原文。 会制造严重隐私与合规风险，metadata 与受控 payload 分层。
误区：平均延迟足够。 尾延迟和各 span 分解才指向瓶颈。
追问：最关键的关联字段是什么？ trace_id 加不可变版本 manifest，贯穿请求和反馈。
追问：如何定位真证据在哪里丢失？ 比较召回候选、rerank 排名和最终 packing ID。
追问：怎样控制日志成本？ 轻量字段全量，异常 tail sampling，正文短期受控存储。

九、加强记忆

RAG Trace 可记成“链路全、版本全、正文少、异常多采、反馈可回连”。从 query 到 validation 每步都有 span，记录候选与淘汰决策、Token 和延迟；用 ID/hash 保护隐私，异常详细采样；把用户反馈连回当时版本。这样错答才可分层、慢请求才可归因、事故才可重放。

简化版

详细版