四种无向量RAG方法

你向AI助手询问一份200页合同的问题。它自信地回答。答案是错的。它从正确的主题中提取了文本但却是错误的条款而且模型完全没有注意到这个区别。我经常遇到这种情况。LLM并没有编造内容。它只是忠实地综合了检索器提供的信息那些在语义上与问题接近但与实际答案无关的文本片段。高置信度分数。看起来正确。实际上是错的。**这在演示中不会出现。但在生产环境中占据主导。而在2026年这就是为什么团队分裂为两个阵营**基于向量的RAG vs 无向量RAG。1、基于向量的RAG实际是如何工作的基于向量的RAG核心只有三个步骤分割将你的文档分割成更小的块通常是256-1024个token转换使用嵌入模型将每个块转换为向量存储和搜索将这些向量存储在向量数据库中如FAISS、Pinecone等以找到最接近的匹配当用户提出问题时查询也被转换为向量向量数据库使用最近邻搜索找到最相似的块这些块被传递给LLM生成最终答案2、现在的RAG是什么样子旧的块→嵌入→检索循环只是一个起点。 2026年的生产系统看起来非常不同而且正在发生转变。三个重要转变**检索是多阶段的。**不再是一次搜索。系统生成候选结果重新排序并在传递给模型之前仔细组装上下文。**检索是智能体化的。**LLM不只是回答。它决定如何搜索检查结果并在需要时重试。**检索是混合的。**高性能系统不依赖单一方法。它们结合向量搜索、关键词搜索和其他信号然后融合结果。关键的转变在于RAG不再只是检索然后生成。它正在成为一个检索编排问题多个信号竞争系统决定信任什么。如果你还在问 “我应该使用哪个向量数据库”你解决的是错误的问题。3、检索的真正问题检索以两种方式失败。大多数团队只测量其中一种。召回失败。是系统根本找不到正确的文档。这会在评估中被发现。你可以通过更好的分块、更多数据或混合搜索来修复它。精确度失败更加隐蔽。系统找到了看起来合理的错误文档而LLM将它们视为事实依据。这更难发现更危险直接与你的检索器如何表示含义相关。我花了一段时间才内化的东西向量搜索优化的是相似性而不是真实性。当你问Q3收入增长的原因是什么时它提取了每个提到收入的块。而不是那些实际解释它的块。分块使问题更严重含义被分割在边界之间定义在一个块中依赖在另一个块中交叉引用中断模型最终只能猜测因为上下文不完整当它失败时你是盲目的。你得到的是相似性分数而不是推理。没有解释为什么检索到了某个内容。在金融或法律领域这不是不便。这是责任。4、无向量RAG实际是如何工作的无向量RAG用不同的东西取代了整个嵌入-搜索-块管道。不是将你的文档转换为向量并搜索最接近的匹配而是让语言模型阅读文档的结构化地图并决定打开哪个部分。这样想。你给一位研究分析师一份200页的年度报告并问一个问题。分析师不会阅读每一页。他们查看目录识别最可能包含答案的部分翻到该页阅读它然后回答。无向量RAG正是这样做的只是分析师是LLM目录是从文档生成的结构化表示。5、四种无向量检索方法不是将文本转换为数学向量并搜索相似的含义这些方法使用其他信号——关键词、关系、结构或推理——来找到正确的信息。4.1 BM25 词法检索关键词匹配器一种经典的搜索算法根据确切的单词匹配以及这些词出现的频率对文档进行排名。工作原理将你的查询分解为单词/短语例如“错误代码E-4012”找到包含这些确切术语的文档通过词频逆文档频率对它们进行排名像the这样的常用词权重较低罕见、特定的词权重较高最适合确切标识符产品代码、错误编号、条款引用、API路径正确答案必须包含特定关键词的查询当你知道要找什么时的快速、低成本检索注意同义词或改写“OOM错误不会匹配内存不足崩溃”模糊问题告诉我关于我们的退款政策返回嘈杂的结果不理解含义——只是匹配token4.2 知识图谱遍历GraphRAG关系导航器将你的文档转换为由连接事实组成的网络实体关系然后遍历该图谱以找到答案。工作原理解析文档以提取实体人、产品、日期和关系“供应商X提供组件Y给制造商Z”将其存储为图谱节点实体边关系要回答查询系统遍历边“找到所有与制造商A相连的供应商→在2024年第三季度有质量标记的”最适合需要跨文档连接点的多跳问题结构化领域供应链、法律合同、临床试验当你需要解释答案是如何得出的通过图谱的路径注意需要干净、可提取的结构——杂乱的PDF或自由格式文本会破坏图谱构建和维护图谱增加了前期工程工作量难以处理开放式、语义问题“X的风险是什么”4.3 基于推理的树搜索文档管理员PageIndex不是将文档砍成扁平的块而是保留其自然层次结构章节→节→小节让LLM浏览这个目录以找到正确的页面。这项技术很新像PageIndex这样的工具被用于实现它。工作原理构建树将每个文档解析为嵌套结构其中每个节点都有标题唯一ID页码范围开始/结束该部分的简短LLM生成摘要指向子小节的链接导航当问题到达时LLM只阅读标题和摘要不是全文并进行推理“问题询问的是结论→节点0019的标题是’结论、局限性、未来工作’→这是最佳查找位置。”检索获取所选节点们的全文并生成答案。最适合结构化文档法律合同、年度报告、技术手册、学术论文当你需要可审计性时你可以看到确切选择了哪个部分以及为什么避免向量常见的错误但相似的检索错误注意增加延迟在答案生成之前需要额外的LLM调用进行导航依赖文档质量格式不佳的PDF或扁平文本会产生弱树对跨文档搜索效果较差最好在知道要查询哪个文档时使用示例节点结构{ title: 金融稳定, node_id: 0006, pages: 21-22, summary: 美联储监控金融脆弱性..., children: [ { title: 监控金融脆弱性, node_id: 0007, pages: 22-28 } ] }4.4 智能体搜索自主研究者是什么LLM充当自己的检索器——阅读元数据、发出子查询、检查结果并循环直到有足够的证据来回答。工作原理不需要预构建的索引虽然可以使用一个LLM接收一个问题并计划如何找到答案“首先检查目录以获取相关部分”“然后搜索提及’Q3收入’的文档”“如果结果很少尝试关于’财务表现’的更广泛查询”它评估中间结果并决定是继续搜索还是生成答案最适合需要迭代调查的复杂、多步骤问题动态或快速变化的数据维护索引成本高昂你希望检索过程本身透明且可调整的场景注意最高延迟每次查询多次LLM调用可能将响应时间推到秒级最高成本你为每个推理步骤付费而不仅仅是最终答案需要强大的推理模型较弱的LLM可能无限循环或选择糟糕的搜索策略5、这实际上移除了什么以及添加了什么不需要选择、托管和维护嵌入模型不需要运行和查询向量数据库不需要调整分块策略没有静默检索失败即错误的块带着高置信度分数返回答案可以追溯到特定的页面和部分。如果错了你确切知道错误是在哪里进入的你可以检查树搜索推理看到选择了哪个部分并理解为什么。总共两次LLM调用。一次用于导航一次用于答案生成。像PageIndex这样的工具将这个模式实现为开源库。你给它一个PDF它构建树。你给它一个问题它对树进行推理并在约50行Python代码中返回基于事实的答案。但这个模式本身适用于任何LLM和任何树生成方法。6、它们真正分化的位置忘记功能列表。 这就是选择真正开始重要的地方。6.1 含义 vs 结构向量RAG → 理解含义。它可以处理模糊问题即使没有关键词重叠也能找到相关内容。 但它难以区分相似主题但相反结论的文档。无向量RAG → 理解结构。它知道部分如何关联、矛盾或相互依赖。 但它只有在你的数据具有清晰、机器可读的结构时才有效。6.2 调试分数 vs 推理**向量搜索 → 给你一个分数。**相似性分数如0.87告诉你有多接近而不是为什么。 如果它检索到错误的块你真的无法调试这个决定。**无向量检索 → 给你一个推理路径。**它显示为什么选择了一个部分。 你可以追踪决定验证它并修复它。在受监管的系统中这个差异是巨大的。 这是*“系统说的和这是推理过程”*之间的差距。6.3 查询复杂度向量RAG → 对简单查询效果很好一个问题 → 一次检索 → 一个答案。无向量图谱/智能体→ 处理复杂查询需要跨文档连接信息的多步骤问题。6.4 嵌入的局限性嵌入将含义压缩成单个向量。 这种压缩有局限性。**在某个时刻**不同的文档即使不应该相似也开始看起来相似。如果你的系统不断混淆相似但不同的内容 你不是面临调整问题。 你正在遇到表示限制。6.5 保持数据更新**向量RAG。**当数据变化时需要重新嵌入和重新索引 → 对快速变化的数据维护成本更高无向量方法BM25 → 容易更新图谱 → 需要关系提取树 → 需要结构解析不同的成本但不同的权衡。7、向量RAG在哪里失效RAG不是因为LLM而失败。它是因为检索而失败。向量搜索在这些情况下可预测地失效确切标识符。产品代码、错误编号、法律条款引用、API端点路径。嵌入将它们模糊到语义邻域中而不是匹配确切的token。否定。不允许退款的策略和允许退款的策略产生几乎相同的嵌入。向量空间不编码逻辑。跨文档推理。当答案需要结合来自具有不同上下文的多份文档的信息时单向量检索失去了区分能力。专业词汇。通用嵌入模型在临床试验命名法或半导体术语上表现不佳除非经过微调而微调需要你可能没有的标记数据。伪装成文本的结构化数据。如果你的文档实际上是具有可过滤属性的数据库行向量搜索是错误的工具。8、无向量RAG在哪里失效这不是免费升级。你在用一组盲点换取另一组。模糊问题。告诉我关于我们的云迁移挑战没有关键词锚点、没有图谱路径、没有结构目标。BM25返回噪音图谱遍历需要一个起始实体。只有语义搜索能处理这个。扁平、非结构化数据。聊天记录、论坛线程、自由格式笔记。如果你的数据没有固有结构树和图谱方法就无所作为。延迟。基于树的推理在答案生成调用之前每次查询至少增加一次额外的LLM调用。对于用户期望近乎即时响应的对话产品这个差距是明显的。如果你需要p99低于500ms基于推理的检索就脱离热路径。规模成本。一旦索引构建完成向量相似性搜索每次查询的边际成本几乎为零。树搜索每次查询都调用LLM。在任何有意义的规模下这成为真正的成本项目。多语言。BM25是特定于语言的。图谱模式通常也是。多语言嵌入无需额外工作即可处理这个问题。多文档搜索。基于树的方法对单文档问答很强。对于你不知道哪个文档有答案的大型集合每文档的树开销增长很快。这是像PageIndex这样的工具正在积极解决的已知限制。模型质量是上限。导航决定只与做出它的LLM一样好。如果你想用一个小模型完全在本地运行这个在将其用于生产之前仔细测试。文档格式很重要。格式不佳的PDF、没有OCR的扫描文档以及作为PDF导出的演示文稿产生扁平的树摘要弱检索更差。当文档具有真实层次结构时这种方法效果最好清晰的标题、逻辑嵌套以及类似于目录的东西。9、每种方法何时获胜选择向量RAG当你的集合有数千份文档查询跨越所有文档问题是宽泛和语义的“找到关于X的一切或我们对Y了解什么”你需要在大规模下低于200ms的延迟你的语料库跨越多种语言文档格式不佳或缺乏清晰结构选择无向量RAG当你的文档具有清晰的结构10-K报告、法律合同、学术论文和技术手册准确性是优先事项错误答案有实际后果你需要可追踪的审计跟踪检索的部分、页面以及选择背后的推理你在处理特定文档而不是跨大型集合搜索你的数据经常变化重新嵌入成本高昂选择混合当你有混合查询类型一些模糊一些精确没有单一检索信号足够可靠你的失效分析显示召回和精确度都有差距老实说我看到的大多数生产系统最终都是混合的。实用测试从你的实际用例中选取20到30个真实问题运行两种方法比较准确性。一天的评估胜过数月的架构争论。10、决策框架以下是我为新系统实际思考这个问题的方式。从数据开始。如果是非结构化和扁平的向量是你最好的首选。如果它有真实结构你可以解析的部分、实体关系、层次结构选择无向量或混合。大多数真实语料库是混合的这通常意味着混合。然后看查询。自然语言、开放式的东西需要向量搜索。没有其他东西能很好地处理告诉我关于…的查询。特定实体查找和代码引用需要词法搜索。多跳推理需要图谱或智能体。约束进一步缩小范围。严格的低于500ms延迟排除了热路径上基于推理的检索。合规需求推动你走向可追踪的检索。快速变化的数据意味着重新索引成本很重要而向量是那里昂贵的选择。但实际上最有用的是看看什么已经在失效检索到错误但相似的文档向量是瓶颈。添加词法或结构信号。完全遗漏相关文档召回是问题。添加向量搜索。复杂查询返回垃圾你可能需要一个重新排序器或智能体层。不要试图在第一天就构建混合管道。我看到团队花数月时间连接每种检索方法然后才有足够的查询数据知道哪些是重要的。从匹配你主导查询类型的方法开始。检测它。看看它在哪里失效。然后添加下一个信号。11、查询复杂度如何改变事物单跳事实问题向量搜索加重新排序器就足够了多实体查询添加元数据过滤或结构化检索多跳推理你需要图谱遍历或智能体分解分析/聚合查询RAG是错误的模式使用text-to-SQL12、2026年具体有什么不同三件事今年改变了计算。12.1 推理模型现在可以规划检索像o3、Gemini 2.5 Pro和具有扩展思考的Claude这样的模型足够好可以充当检索规划器。不是静态管道模型分解问题规划检索步骤检查中间结果并自我纠正。这就是使基于树的无向量RAG实际可行的原因。选择要阅读哪个文档部分的推理步骤需要一个能够思考决定而不仅仅是预测下一个token的模型。两年前导航质量还不够可靠。现在是了。12.2 混合检索是基本要求业界大多已经确定了密集向量搜索与BM25结合使用倒数排名融合然后是重新排序器。这不是一个新想法了。它是基线。如果你在2026年开始一个RAG系统而没有混合检索你就是在放弃精确度。12.3 嵌入已被证明有数学限制符号秩瓶颈研究表明单向量嵌入对于某些文档组合在检索准确性上有硬性上限。不是模型质量问题。是表示问题。ColBERT v2和ColPali用于多模态使用多向量表示部分解决这个问题但以10-50倍的存储成本。当精确度足够重要时这是值得的。13、结束语没有一种获胜。两者都在不同的输入上失效。向量RAG给你覆盖范围。它处理真实用户实际输入的混乱、不可预测的查询。对于大多数团队来说它仍然是正确的第一步。无向量RAG给你精确度和可追踪性。对于结构化专业文档准确性很重要且错误答案有后果构建树并对其推理更适合这些文档的组织方式。现在交付最佳检索系统的团队不是在它们之间选择。他们两者都在运行向量用于语义召回BM25用于关键词精确度重新排序器用于细化基于推理的检索用于问题足够困难以证明延迟合理时。问题从来不是哪种获胜。它一直是每种在哪里失效什么能捕获失效测量你的检索在哪里失效。失效模式告诉你接下来要添加什么。原文链接四种无向量RAG方法 - 汇智网