很多团队把运维手册、发版 SOP 和应急处置流程接进 RAG本意是让值班同学少翻 Wiki。⚠️ 真到故障时系统却常把已经废弃的回滚步骤重新答出来最危险的不是完全答错而是旧流程只错一两步看上去还像真。这类问题往往不是 embedding 不够强而是检索层默认把“最新上传”当成“当前有效”。 对 runbook 来说真正决定答案能不能执行的不是文本相似度而是生效时间、适用环境和版本边界一旦这些维度没进索引模型就会把历史流程和现行流程混成一锅。[外链图片转存中…(img-DoiNrgZQ-1778048469769)]图 1文档型 RAG 最危险的不是没召回而是召回了已经失效的旧步骤旧流程为什么会被检索回来运维手册和普通知识文档最大的区别是它天然带有时间语义。 同一条“先切只读、再扩副本”的步骤在大促前、双活切换后和数据库升级完成后适用条件完全不同。很多团队只给文档存updated_at却没有存valid_from、valid_to和环境标签结果 rerank 只能按相似度拍板。更隐蔽的坑是“最新版本”不等于“查询时刻的正确版本”。 事故问答常常要回放某个时间点发生了什么如果检索时只拿当前文档就会把事后修订的流程倒灌回历史语境。这样生成的答案文字顺畅审计时却无法解释当班人员当时为什么按另一套步骤操作。方案正确流程命中率过期步骤引用率维护成本只检索最新文档67%22%低召回后按生效时间过滤81%9%中快照检索 时间过滤 环境标签89%3%中[外链图片转存中…(img-MtdaQCv0-1778048469773)]图 2只要索引里没有时间边界离线召回再高也会被旧流程拖穿回放里最致命的是时间错位一组回放把问题暴露得很直接选取860份运维手册、43次流程变更和1900条问答记录基线方案直接检索最新文档第二组加effective_date过滤第三组再引入policy_snapshot_id把一次发布窗口内的文档视为同一快照。 结果显示时间过滤能挡住旧步骤快照检索才真正解决“半新半旧”的混答。defretrieve_runbook(query,event_time,env,top_k5):candidatesann.search(query,top_k30)active_docs[docfordocincandidatesifdoc.valid_fromevent_timedoc.valid_toandenvindoc.environments]rerankedrerank(query,active_docs,features[policy_version,policy_snapshot_id,owner],)returnreranked[:top_k]这段逻辑的关键不在于多做一次过滤而在于把“问题发生时刻”提升为一等检索条件。✅ 只有先按生效区间缩小候选再让 rerank 看版本号、环境和 owner模型拿到的上下文才是同一制度面上的证据而不是拼接出的伪答案。[外链图片转存中…(img-ZcA3rTA8-1778048469773)]图 3把事件时刻和文档快照一起带进检索RAG 才能回答“当时该怎么做”Policy Snapshot 才是可回放的索引边界笔者认为文档型 RAG 要想摆脱“答旧流程”核心不是更激进的 query rewrite而是把 policy snapshot 做成知识底座。️ 每次制度变更、发版冻结和架构切换都应该产出可回放的快照 ID主索引回答当前问题审计索引回答“当时为什么这样做”两条链路不能混用。更稳的做法是把effective_date、环境标签和流程 owner 做成显式特征。 一旦这些元数据进入索引系统就能区分“文本很像但已经失效”的老流程和“相似度略低但当前生效”的新流程回答稳定性通常会比单纯更换 embedding 提升得更明显。[外链图片转存中…(img-9u9VeY4b-1778048469774)]图 4真正稳的不是把更多文档塞进 RAG而是把“哪版文档此刻有效”建成索引规则这类 RAG 会越来越像制度执行系统未来3 - 6个月越来越多团队会把 SOP、告警抑制规则和工单状态一起接进同一套检索系统。 谁先把effective_date、环境标签和快照回放打通谁就更容易让 RAG 进入值班场景反过来只靠“最新文档 大模型总结”撑系统旧流程迟早会在高峰时跳出来。⭐ 你们现在的 RAG检索的是知识还是过期操作