RAG 最棘手的错误，不是没搜到，而是旧的也搜到了。
在版本敏感的问题里，风险很直观。用户问“当前 API 的认证方式是什么”，向量库可能同时召回旧版接口文档和新版说明。两段文字都与问题高度相关，LLM 却未必知道谁已经失效。它一旦把两套规则拼在一起，答案看似完整，实际并不存在。这里把这种情况称为“陈旧幻觉”。
Meta Intelligence 对 RAG 的梳理提到，RAG 自 2020 年由 Lewis 等人提出，基本思路是在推理时从外部知识库检索内容，而不是把所有知识写进模型参数。外部知识库可以更新，不等于检索结果天然一致。只要新旧材料同时留在库里，冲突就仍会进入上下文。
向量库只判断像不像
Embedding 会把文本映射到向量空间，但 version_timestamp、生效状态和 SUPERSEDES 关系不会自动变成硬约束。旧版员工手册和新版员工手册往往措辞相近，从语义相似度看，两者都可能排在前面；从业务规则看，它们却不能同时作为当前依据。
Metadata 过滤能处理一部分问题。前提是每个 Chunk 都有准确、统一的版本字段，而且状态变化能够同步到所有相关片段。一旦产品、政策和接口文档相互引用，维护工作就不再是改一个日期，而是处理跨文档关系。漏改一个节点，旧资料仍可能被召回。
这也是Datawhale 的 KG-RAG 章节指出的限制：只依赖非结构化文本的向量检索，面对复杂查询时缺少关系层面的约束。
Milvus 或 Zilliz 不需要被替换。它们仍适合做快速粗筛。需要补上的，是一个能判断“这份资料现在是否有效”的图过滤层。
图谱只做一件事：把版本关系说清楚
混合架构可以拆成两条并行链路：
Document -> Chunk -> Vector
└-> Entity / Version -> Graph
向量保存语义，图谱保存业务关系。初期不必把图建得很大，先把三类关系做准：
VERSION_OF：片段或文档属于哪个版本。SUPERSEDES：哪个新版本取代了哪个旧版本。DEPENDS_ON：某个功能、产品或文档依赖哪些接口与规则。
节点还需要保留 status 和 version_timestamp。常见状态可以是 Active 与 Deprecated，但状态变更必须有依据，例如文档中的修订说明、发布记录或领域专家确认。不能只因为两份文件标题相似，就让模型自行判断替代关系。
入库时可以用 Nanbeige4-3B 这类 3B 级模型做实体识别和关系抽取，但模型输出应被视为候选关系，而不是业务事实。上线前仍要检查漏检、误连和版本归属，相关方法可参考《3B小模型进垂直业务：先测漏检，再谈平替》。
动态更新，不等于不断重建索引
“动态”的重点，不是图数据库会自己更新，而是新文档、修订和下线事件能够触发关系与状态变化。
新版本进入知识库后，系统先找到对应的产品、政策或 API 实体，再检查它与现有版本的关系。如果 SUPERSEDES 已被确认，新节点设为 Active，旧节点改为 Deprecated。旧文档可以继续保留，用于审计和历史查询，但不再进入回答“当前规则”的检索路径。
如果替代关系不明确，就不要自动废弃旧节点。更稳妥的做法是把冲突送入审核队列，并在回答中明确提示存在多个版本。让 LLM 自己挑一个“更像新版”的片段，等于把数据一致性问题推给了生成模型。
状态位也不能只躺在图数据库里。它必须接进检索 Pipeline，在上下文送入 LLM 之前生效。关于这一层的衔接，可参考《企业 RAG 反复引用旧资料，动态知识图谱怎么接》。
检索链路不必变得很花
升级后的流程仍然清楚：向量负责找候选，图谱负责删冲突，LLM 负责组织答案。
候选片段 = 向量召回（Top-20）
有效片段 = 图过滤（status、version_timestamp）
补充上下文 = 沿 DEPENDS_ON 扩展
最终上下文 = 重排、去冲突后交给 LLM
Top-20 只是示例参数，不是通用答案。真正影响结果的是后面的处理：
- 对“当前、最新、现行”类问题，过滤
Deprecated节点，并移除已被其他版本取代的片段。 - 对历史问题，按用户指定的时间或版本检索，不能把旧节点一律删除。
- 沿
DEPENDS_ON补充必要上下文，避免只拿到接口说明，却漏掉它依赖的认证规则。 - 只有在来源级别和更新时间已经明确定义时，才能把它们用于重排，不能让“权威度”变成一个无人解释的分数。
生成答案时，最好同时返回来源和版本。即使图过滤出现错误，使用者也能追查答案依据，而不是只看到一段语气确定的结论。
别只测向量命中率
验证这套改造，应该单独准备一组版本敏感问题，例如“当前 API 的认证方式”“现行产品条款”“目前生效的内部制度”。每道题都要标出有效版本和依据，否则无法判断系统到底召回了正确资料，还是碰巧生成了正确措辞。
至少需要观察四件事：
- 旧资料是否进入最终上下文。
- 相互冲突的版本是否同时出现。
- 回答能否给出对应版本和来源。
- 图遍历给端到端延迟增加了多少开销。
图检索会增加工作量，但不能预设一个固定延迟，也不能默认所有问题都值得走慢路径。新华三《数字化领航》AI 应用专刊强调，严肃业务场景看重准确性、安全性和可追溯性。对产品条款、政策和接口版本这类问题，先保证依据正确；普通定义查询则可以直接走向量路径。
建图输出先当草稿
完全自动建图的问题，不只是不够准，还可能把模型猜出的关系写成正式规则。更可靠的流程是：模型提出实体和关系，领域专家确认，系统再写入图谱。审核界面要展示原文证据，不能只给出一个 SUPERSEDES 标签。业务规则为什么仍要由人确认，可参考《把财务审计流搬上画布，最难的还是写清规则》。
选库先看查询，不看口号
Neo4j、NebulaGraph 可以作为图数据库候选，Milvus、Zilliz 继续承担向量检索。选型时应拿自己的关系结构和查询路径做测试，而不是只比较节点规模。若使用 Neo4j，还要关注 Cypher 查询、索引和全图扫描问题；图遍历写得不好，过滤层会成为新的延迟来源。
Agent 只能分流，不能替你定版本
Agentic RAG 适合做路径选择。问题中出现“当前”“最新”“是否仍然有效”等信息时，Agent 可以触发图检索；普通定义查询则走快速向量路径。这样能避免每个问题都执行完整图遍历。
但 Agent 没有权力凭空建立版本关系。图谱中没有可靠的 SUPERSEDES 证据时，它应该暴露冲突或请求确认，而不是替业务人员决定哪份文档有效。
不管是否把这种架构叫作 RAG 2.0，边界都要清楚：向量库负责找相似内容，图谱负责判断版本和依赖，LLM 负责组织答案。只要 VERSION_OF 和 SUPERSEDES 仍靠猜，多接一个图数据库也不会让旧资料自动消失。
