7 篇博文 含有标签「knowledge-graphs」

向量索引即便有约 10% 的误差，也没人会惊慌。但知识图谱如果缺失了一条边，就可能导致有人向监管机构提交一份错误的答案。从数据工程组织的架构图来看，这两种故障模式如出一辙——都被归类为“索引陈旧”——并且它们共用同一个变更数据捕获（CDC）流水线，具有相同的延迟容忍度。流水线的规格是根据向量负载确定的，因为向量是更“大声”的消费者。图谱默默地继承了这些默认设置，而这种沉默本身就是 bug。

向量检索和图谱检索在数据陈旧时的失败表现截然不同。将它们视为同一种延迟问题，会导致你构建出的系统虽然在 RAG 基准测试中得分很高，但在多跳查询中却会产生隐蔽的错误——当然，这种“隐蔽错误”往往是用户最后才会察觉到的。解决方案不是更快的流水线，而是要认识到“陈旧”具有两种不同的含义，为每种边类别设计新鲜度分层，并在监管机构发现之前，通过评估机制捕捉到这种差异。

向量搜索已成为 RAG 系统的默认检索原语。嵌入你的文档，嵌入查询，查找最近邻 —— 这一过程简单、快速，且对于大多数问题效果惊人。但在生产环境部署中，开发者往往会遇到同样的瓶颈：某些查询尽管相似度得分很高，返回的却是垃圾结果；某些多文档推理任务会无声无息地失败；随着复杂度的增加，某些实体密集型查询会退化为随机噪声。

问题不在于嵌入质量或索引大小，而在于语义相似性对于一大部分检索问题来说是错误的抽象方式。知识图谱并不是向量搜索的替代品 —— 它们解决的是结构完全不同的问题。理解哪些问题属于哪种工具，是区分脆弱的 RAG 流水线与能在生产环境中稳健运行的系统的关键。

你的企业刚刚部署了一个 RAG 系统。你索引了每个 Confluence 页面、每份运行手册（runbook）、每篇架构文档。六个月后，一位高级工程师离职了——就是那个知道为什么支付服务会有那种不寻常的重试模式、为什么你们从不把缓存扩容超过 80%，以及周五绝对不要给哪家供应商打电话的人。这些知识从未被记录下来。你的 RAG 系统根本不知道它的存在。

这就是隐性知识（tacit knowledge）问题。这也是为什么大多数企业 AI 系统表现不佳的原因——不是因为检索质量或幻觉，而是因为它们所需的知识从一开始就没被捕获。60% 的员工表示，很难甚至几乎不可能从同事那里获取关键信息。90% 的组织表示，员工离职会导致严重的知识流失。你的 RAG 能索引的文档只是冰山一角。

大多数团队在构建 RAG 流水线时都会选择向量嵌入（vector embeddings）。这是一个显而易见的默认选择：嵌入文档、嵌入查询、寻找最近邻，然后将结果输入给 LLM。在演示（demo）中它的表现还不错。但当部署到合规团队或科学文献语料库时，准确率就会断崖式下跌。不是逐渐下降，而是突然暴跌。在涉及五个或更多实体的查询中，向量 RAG 在企业分析基准测试中的准确率降至零。不是 50%，也不是 20%，而是零。

这不仅是一个配置问题，而是架构上的不匹配。向量检索将文档视为语义空间中的点。知识图谱（knowledge graphs）则将它们视为关系结构中的节点。当你的查询需要遍历关系——而不仅仅是寻找相似内容时，检索架构的拓扑结构（topology）决定了你是否能得到正确答案。

Most RAG 的实现都以同样的方式失败：向量搜索检索到了看起来合理但并非用户真正需要的内容，LLM 用自信的辞令对其进行包装，最终用户得到一个大体正确但细节错误的答案。令人沮丧的是，这种失败模式是隐形的 —— 余弦相似度分数看起来很正常，检索到的片段也提到了正确的主题，但答案仍然是错的，因为问题需要跨关系进行推理，而不仅仅是语义上的接近。

向量嵌入 (Vector embeddings) 擅长一件事：找到听起来 像 你查询内容的文本。这是一种强大的能力，涵盖了极广的生产用例。但当问题取决于实体之间如何 连接（而非它们的描述有多匹配）时，这种方式就会出现可预见的失效。对于这类查询，知识图谱 —— 一种你可以通过 Cypher 或 SPARQL 遍历的属性图 —— 不仅仅是一种优化。它是一种从根本上不同的检索方式，解决的是另一类问题。

你的 RAG 管道在回答单一事实问题时表现出色。问它"我们的退款政策是什么？"它每次都能准确回答。但如果问"哪些企业版客户在合同续签后 30 天内提交了关于计费 API 的工单？"它就无能为力了。答案确实存在于你的数据中——分散在三种不同的文档类型中，通过余弦相似度无法捕捉的关系连接在一起。

这就是多跳推理问题，也是越来越多的生产级 RAG 团队在向量检索管道上嫁接知识图谱的原因。不是因为图谱又流行了，而是因为他们遇到了一个具体的准确率天花板——无论怎么调整分块大小或重新排序都无法突破。

一个客户服务智能体知道用户偏好在早晨送货。它还知道用户的主要地址在西雅图。但它无法理解的是，西雅图的地址是一个仅在工作日使用的办公地址，而且由于用户三个月前提到的一项大楼限制，早晨送货窗口期在周一并不适用。每个事实都可以被单独检索，但它们之间的关系却不能。

这就是在基于扁平向量库（flat vector stores）运行的生产级智能体中常见的故障模式。每一条信息都像是一个漂浮在高维空间中的嵌入（embedding）。相似性搜索检索与查询匹配的事实，但它无法恢复事实之间的结构化连接——即在组合中赋予它们意义的“边”（edges）。

大多数智能体记忆架构是围绕向量数据库构建的，因为它们速度快、设置简单，且适用于大多数检索任务。这些失败案例非常微妙，以至于在有人注意到这种模式之前，它们往往已经出现在生产环境中了。