企业官网建设流程全解析

RAG文档更新后还答旧内容，怎么排查？

产品说明已换成新版，AI却还在引用旧段落。先把这次回答保存下来。不要只改一句提示词，便认为问题已经解决。

同一句旧话，可能来自不同位置：原文件没有替换；解析后的片段没有更新；检索返回了旧版本；应用复用了旧答案。处理办法也各不相同。

本文给出一条排查路径。再用一段离线程序，检查检索结果的版本。程序不连接生产系统，也不替你删除文档。

1. 先保存一条能追查的失败记录

记录用户问了什么，以及当时的时间。再保存系统回答和引用位置。若有请求编号，一并记下。

随后找资料负责人确认：这道问题现在应当怎样答？依据是哪份文件的哪一段？不要用文件名里的“最终版”代替确认。

举一个演示例子：产品手册的旧版要求线下申请。新版改成了在线申请。测试问题仍是“怎样开通这个功能”。下文只用这个虚构例子，不代表客户项目。

把问题拆成四次核对：

1. 源文件打开后，是在线申请，还是线下申请？
2. 解析出来的片段，是否保留了新版说明？
3. 检索接口返回的片段，属于哪个版本？
4. 本次回答是否真的用了这些片段？

第一步就错了，应先找资料负责人。第三步错了，再查索引和过滤条件。第四步才需要检查上下文与答案缓存。

2. 用稳定编号串起原文和片段

一份文件往往会被拆成多个片段。只记录文件名，更新后很难逐个对照。

可为演示系统保留以下字段：

• doc_id：同一份业务文件的稳定编号。
• version：经负责人确认的内容版本。
• chunk_id：这个版本中的具体片段。
• status：当前允许使用，还是已下架。
• source_updated_at：来源什么时候发生变更。
• index_ready_at：检索侧什么时候完成准备。

这是一份建议字段清单，并非平台通用接口。真实系统应按现有数据结构调整。

特别注意两种时间。上传成功的时间，不能代替检索可用的时间。异步解析还没结束时，界面应显示“处理中”。任务失败则保留失败原因，交给明确的人处理。

Dify 官方知识检索文档也区分了检索与生成。检索节点返回文档片段及元数据，再供模型使用。文档还说明了元数据过滤功能。能配置过滤，并不等于当前应用已经正确启用。[1]

3. 先检查检索结果，不让模型代替判断

下面的程序只查一件事：返回的片段，是否属于登记的有效版本。

current是演示用的可信登记表。生产系统不能接受用户随意填写这张表。权限检查也应在服务端单独完成。

def audit_hits(hits, current): problems = [] for hit in hits: doc = hit.get("doc_id") active = current.get(doc) reasons = [] if active is None: reasons.append("unknown_document") elif not active["enabled"]: reasons.append("document_disabled") elif hit.get("version") != active["version"]: reasons.append("stale_version") if not hit.get("chunk_id"): reasons.append("missing_chunk_id") if hit.get("status") != "active": reasons.append("chunk_not_active") if reasons: problems.append({ "chunk_id": hit.get("chunk_id"), "reasons": reasons, }) return problems current = {"manual": {"version": "v2", "enabled": True}} hits = [{"doc_id": "manual", "version": "v1", "chunk_id": "manual-v1-01", "status": "active"}] print(audit_hits(hits, current))

这组输入会得到stale_version。把它放在检索日志旁，就能知道问题发生在哪一层。

没有报错，也不能直接宣布答案正确。程序不检查片段是否完整，不判断引用是否支撑结论，也不证明权限正确。它只是把“旧版本混进来了”变成一项确定检查。

如果没有检索结果，要另记“无可用依据”。不要把空列表误当成回答通过。

4. 新版准备好后，再决定何时切换

普通内容更新，可以先准备新片段。检查解析、索引与代表性问题后，再切换允许使用的版本。每一步留下任务编号与状态。

但旧版若已明确失效，就不能继续用它兜底。新版本还没准备好时，可暂时停止相关自动回答。界面说明正在更新，并给出人工接手入口。

删除也要分清范围。源文件、向量索引、全文索引和缓存，可能是不同存储。只从文件列表删掉一项，不足以说明其他位置已清理。

Pinecone 官方文档列出按记录 ID 删除的方法，也列出按元数据条件删除的方法。[2] 具体系统用哪种方式，要依据实际接口与文档编号关系。本文不建议复制一条清空命令到生产库。

删除后应核对目标编号和检索结果。敏感材料还涉及其他留存位置，不能仅凭“检索不到”就声称全部副本消失。

5. 更新完成后，分四次复查

第一，直接调用检索，检查返回版本。第二，让应用回答同一问题，点开引用。第三，换一种问法，确认没有只修固定句子。第四，检查旧会话是否带着旧上下文。

应用答案缓存和模型提供方的提示缓存，需要分开理解。前者可能直接返回整段旧答案。后者的行为取决于所用服务，不能统一套用“删缓存”三个字。

若“检索已新、回答仍旧”，先查应用是否用了本次结果。若“新会话正常、旧会话异常”，检查历史上下文的使用方式。若同一文档混着两个版本，先查版本过滤及切换过程。

智链魔方怎么做

这里的方法来源是智链魔方的实践整理。先让业务人员确认当前依据，再让技术人员检查返回片段。两边共同保存一条可重现的问题。修复后，用相同问题及变体分别复查。资料负责人维护内容，技术负责人维护更新任务；FDE 前沿部署工程师（也译作前线部署工程师）负责把两边的检查接到实际工作中。企业 AI 化推进到这一步，应交付检查记录和接手说明。本文提供的是一套可讨论的做法，不是客户效果证明。

聂亚奇，智链魔方主理人、FDE 前沿部署工程师，曾在素材采访中说：“想找一个文件，几乎要问遍所有人”。这段匿名项目自述说明资料管理的实际困难。它不能作为本文技术方案已在该客户实施的证据。

下一步可以挑一份刚改过的文档。用更新前后都常见的问题跑一遍，记录原文、片段、回答和引用。先定位错误发生的位置，再决定改什么。

参考资料（核查于2026年10月25日）：

[1] Dify 官方文档《Knowledge Retrieval》，Knowledge Retrieval 节点及 Metadata Filtering 小节。 Knowledge Retrieval - Dify Docs

[2] Pinecone 官方文档《Delete data》，Delete records 小节。 Delete data - Pinecone Docs

内容发布：智链魔方（深圳市智链魔方科技有限公司）。专注企业 AI 应用与落地，分享方法、工具实践与交付经验。主理人：聂亚奇。