向量RAG的天花板：为什么它答不出"为什么"？

向量检索的隐藏短板

在构建RAG（检索增强生成）系统时，一个常被忽视的问题浮出水面：向量搜索能召回一个相似度得分很高的文本块，但它无法解释答案背后的推理逻辑，更无法在结构上把散落在不同文档里的事实连接起来——无论你的重排序（reranking）做得多好。

这个观察重新定义了业界流行的"再狠狠调优检索"这类建议。很多时候，问题的根源根本不在检索质量，而在于向量搜索这套机制从设计之初就不是为了表达关系和**多跳推理（multi-hop reasoning）**而存在的。

为什么"调优检索"治标不治本

向量搜索的工作原理是把文本嵌入到高维空间，通过相似度衡量来找出与查询最接近的片段。这套机制擅长回答"哪段内容最相关"，却回答不了"为什么相关"以及"这些相关内容之间是什么关系"。

举个典型场景：当一个问题的答案需要跨越三份不同文档、经过两三步逻辑串联才能得出时，向量检索会分别召回若干看似相关的片段，但它无法把这些片段之间的因果、从属或引用关系显式地表达出来。你可以不断加大重排序的力度、优化切分（chunking）策略，但这些手段都无法弥补底层数据结构的缺失。

相似度 ≠ 推理

这里的核心区别在于：相似度是一种统计上的"看起来接近"，而推理是一种结构上的"逻辑可追溯"。前者告诉你结果，后者告诉你路径。对于需要审计、需要解释、需要问责的应用场景（如金融、医疗、法律、合规），仅有"看起来接近"是远远不够的。

知识图谱作为解法

针对这一架构层面的缺陷，原帖提到了一场定于9月19日举办的实操工作坊，主张从架构层面而非调参层面解决问题。其核心思路是引入知识图谱：

• 使用 Neo4j 构建知识图谱，作为唯一可信数据源（single source of truth）
• 采用 agentic retrieval（智能体式检索），让检索过程具备主动的推理能力
• 通过 Cypher 查询语言在图上进行结构化查询
• 最终产出可解释、可审计的答案

这场工作坊由 GraphAware 首席科学家 Dr. Alessandro Negro 主讲。其价值主张很明确：当答案的推理路径能够在图结构中被显式追踪时，"为什么是这个答案"就不再是黑盒。

知识图谱补上了什么

知识图谱天然以"实体—关系—实体"的形式存储信息，这恰好是向量空间缺失的那一层。当事实以节点和边的形式被显式建模时，多跳推理就变成了图上的路径遍历，跨文档的连接也变成了图中天然存在的边。答案不再仅仅是"召回了一段文字"，而是"沿着一条可追溯的推理链得出的结论"。

GraphRAG 的现实意义

这种"向量+图"的组合思路，正是近年来 GraphRAG 方向兴起的核心动因。纯向量方案在处理开放式、语义相近的问答时表现出色，但在需要精确关系推理、需要跨源整合、需要可解释性的场景里，图结构提供了向量无法替代的能力。

对于正在踩坑的 RAG 开发者来说，这个提醒很有价值：在盲目加大检索调优投入之前，不妨先判断你的问题究竟是"召回不准"还是"结构缺失"。如果是后者，再多的重排序也救不了，答案在于架构的重新设计。

需要说明的是，本文观点来自单一 Reddit 帖子（内容带有工作坊推广性质），相关技术主张值得参考，但具体效果仍需结合自身场景验证。