事故 001 · SEV-2
系统把昨天的事实，当成了今天的答案。
你是当前值班的 AI Engineer。
客户询问 40 天前购买的商品还能否退货。客服 Agent 拒绝了退款，并引用了一份旧政策。运营确认，两天前已经发布新版退款政策，而且新文档早已完成索引。
目标
恢复证据的新鲜度与 Grounding，同时不能突破 6k Context、延迟与成本预算。
风险
一次错误回答，可能规模化拒绝本来有效的退款请求。
Context × Evaluation · 上下文 × 评估·生产事故·15 分钟
失效的 RAG Pipeline
新退款政策已经在知识库里，客服 Agent 却仍然按旧政策回答。你需要在错误继续影响客户之前，定位证据链路出了什么问题。
01
体验
先处理问题，再阅读解释。
一句话理解
RAG 的可靠性是整条证据管线的属性：检索分数、时效性、来源权威性、重排与上下文策略必须共同决定什么证据能进入模型。
正在加载 Mission Engine…
02
反思
把结果整理成可以复用的判断。
工程复盘
真正的问题，从来不是 Context 不够多。
Retrieval Quality 是整条 Pipeline 的属性。更多 Context 不等于更好的证据。
这次事故的根因，是过期来源在排序中压过了当前权威来源。单纯提高 Top-K 可能看起来提升了 Recall，却会继续保留错误证据，同时吞掉更多 Context。可靠的策略需要同时处理检索信号、时效性、来源权威、Rerank，以及不会损失关键细节的 Context 策略。
- —Similarity 不等于 Authority。
- —Freshness 应该属于 Retrieval Policy，而不是检索完成后再靠 Prompt 补救。
- —激进压缩可能把正确的证据集合重新压成一个 Grounding 不足的答案。
- —先追踪证据链，再决定要不要调模型。
关键要点
Retrieval 是一条 Pipeline
Chunking、候选召回、Rerank、Freshness 与 Context 策略会相互影响。
权威来源优先于热门结果
相似度最高的文档，不应该天然拥有覆盖当前事实的权力。
先观察，再调参
Retrieval Trace 能区分“证据没找到”“找到的是旧证据”和“Context 丢失”三类问题。
03
深入理解
把这次体验连接到概念、参考与迁移。
LEARNING CONTEXT
学习连接
Retrieval Quality 是整条证据管道的属性：Freshness、Authority、Selection 与 Grounding 必须彼此一致。
未看过
Mental Model
- S02-M04证据粒度与 Chunking
- S02-M05Dense、Sparse 与 Hybrid Retrieval
- S02-M06把 Reranking 视为第二阶段证据筛选
- S02-M07Freshness、Authority 与 Source Priority
- S07-M01把 Traceability 作为因果执行历史
- S07-M03Evaluation Environment 与 Verifier 设计
迁移这个模型
最新文档已经检索出来，但更旧的一份文件才具有法律权威。Evidence Policy 应该如何决定？
04
下一步
把这个判断带到另一个问题或构建中。