没有向量也能做RAG？我是这样构建检索系统的

本文深入探讨了向量相似度检索在RAG系统中的局限性提出了基于推理的Vectorless RAG新范式。传统RAG依赖向量嵌入和相似度搜索存在检索浅层、上下文碎片化等问题。而Vectorless RAG通过构建文档结构树并利用LLM进行推理式导航逐步收窄搜索范围提供更聚焦、连贯的上下文。该方法在结构化文档上表现优异但成本更高、延迟更大。文章通过Google Bigtable论文的实例详细阐述了Vectorless RAG的构建过程包括文档树生成、树导航检索和答案生成并分析了实际应用中的关键考量如结构质量、节点粒度、遍历深度、Prompt设计等。最终强调检索不必仅依赖相似度结构化导航与推理同样重要两种RAG范式可互补共存。从“vector similarity ≠ relevance”的反思出发打造真正理解文档的 reasoning-based RAG含代码Photo by Becca Tapert on UnsplashIntroductionRetrieval-Augmented Generation (RAG) 已经成为在私有数据之上构建问答类 AI 系统的基础范式。传统的 RAG 依赖于 vector embeddings 来检索相关文本块然后将它们传给语言模型进行生成。但随着系统规模扩大、场景更为复杂一种新的范式正在浮现Vectorless RAG也被称为 reasoning-based retrieval。与其依赖 embeddings 与 similarity searchVectorless RAG 更像人类那样“导航信息”——遵循结构、逐步推理、并动态决定下一步该去哪里找。本文将探讨什么是 Vectorless RAG它与传统 RAG 的对比它的优势与权衡何时应该或不应该使用它Traditional RAG: The Baseline传统 RAG 的核心流程包括三步Chunking将文档切分为小块Embedding将每个文本块转为向量Retrieval使用 similarity search例如 cosine similarity检索相关文本块随后取 top-k 文本块传给 LLMLLM 生成答案示例流程Query → Embedding → Vector DB → Top-k Chunks → LLM → AnswerRAG 有多种变体比如 ReRanking、Agentic RAG、Hybrid RAG 等。传统 RAG 也在不断演化出现了多种改进来缓解其在检索质量、推理深度与上下文相关性方面的不足。Re-ranking RAG通过第二阶段由 LLM 对初检结果进行重排从而提升检索精度。系统不再盲信相似度分数而是追问“这些结果中哪些实际最相关”Hybrid RAG结合多种检索策略——通常是 dense vector search 与基于关键词的 BM25。这样可以弥补 embeddings 的关键弱点对精确匹配如 ID、姓名或罕见术语容易遗漏而仅靠关键词又缺乏语义理解。Agentic RAG在流程中引入迭代推理。系统不再只检索一次而是可以将问题拆解为子问题执行多步检索动态决定下一步要取什么信息这开始模糊检索与推理的界线让系统更灵活但也更复杂。Limitations of Traditional RAG更细致的视角传统 RAG 在很多场景里非常有效特别是在规模化地检索语义相似内容时。它的局限常被误解。与其说它“本质上坏了”不如说大多数问题来自“如何执行检索、以及它优化的目标是什么”。Traditional RAG (Image by Author)1. Shallow Retrieval核心限制最根本的限制是传统 RAG 的检索依据是语义相似度而非任务相关性或推理。向量搜索回答的问题是“哪段文本看起来跟查询相似”但许多真实问题需要因果理解多步推理跨章节的信息综合因此系统可能检索到“话题相关”但“对答案并不真正有用”的文本。这属于基于 embedding 的检索的内在限制单靠更好的 chunking 或索引并不能彻底解决。2. Context Fragmentation可缓解文档通常在 embedding 之前被切分为 chunks这可能导致关键信息分散在多个块中取回的块缺乏足够的上下文章节间的关系丢失不过这主要是工程问题而不是本质限制。比如overlapping chunkssliding windowsre-rankingmulti-hop retrieval都能显著降低碎片化。3. Loss of Structure取决于实现在朴素实现中文档被“拍扁”为独立块原始结构章、节、小节丢失。然而现代 RAG 常通过以下方式保留结构metadata如标题与层级hierarchical chunkingparent-child retrieval 策略只要实现得当传统 RAG 仍能保留大量结构信息。因此这不是内在限制更多是简化流水线的副作用。4. Preprocessing Overhead架构权衡传统 RAG 需要生成 embeddings存储到 vector database建索引与维护这些会带来前期成本与系统复杂度但也换来快速检索低时延查询可扩展性能这更像是“成本分布的权衡”前期成本较高单次查询成本更低而不是严格意义上的限制。Key Takeaway在常见问题中唯一的根本限制是传统 RAG 基于相似度检索而非推理。其他如结构、碎片化、成本等都可以通过更好的系统设计来解决。这一点在比较传统 RAG 与 Vectorlessreasoning-based检索时尤为重要——后者试图将“检索”从相似度问题转变为决策过程。Vectorless RAG: The Core Idea如果传统 RAG 的主要限制是“检索缺乏推理”那自然的问题是如果“检索”本身也能推理会怎样想想一个人类分析师如何读文档他们不会横扫上千个 chunks 或者只靠相似度。他们会看目录table of contents理解文档结构推理“要找 X 的信息可能在 Y 章节里”直接跳到目标章节读完整上下文进行综合这个过程是“结构化、带意图、且迭代”的。检索并非一锤子买卖而是每一步都有推理引导。Vectorless RAG 正是基于这个思路。它不再按相似度检索而是把检索视为“决策过程”。系统学会解读文档结构决定下一步往哪儿导航逐步收窄搜索范围只在上下文足够时才取内容换句话说它把检索从“看起来相似的是什么”转变为“我下一步该去哪儿”这就是 Vectorless RAG 的根本转变。Vectorless RAG (Image by Author)How It Works in PracticeVectorless RAG 用一个结构化、以推理为驱动的过程替代了基于相似度的检索。实践上它包含两个阶段一次性的文档转换以及查询时的推理式检索循环。Step 1构建 Document Tree一次性准备在处理任何查询前先把文档转换为层级化结构。类似一本书的组织方式标题章节小节子小节通过预处理如 PageIndex 或下文自建方法把文档解析为树每个节点包含标题简短摘要页码范围可选的完整文本得到类似这样的结构{ title: Google Bigtable Paper,node_id: 0001,summary: Introduction to Bigtable architecture,nodes: [ { title: Data Model, node_id: 0002, summary: Rows, columns, timestamps, nodes: [...] }, { title: Architecture, node_id: 0003, summary: Master, tablet servers, Chubby, nodes: [...] } ]}这棵树是文档的“紧凑结构化表示”可在不扫描全文的前提下导航。Step 2在结构上进行推理查询时系统不会立刻取原文而是先在文档结构上推理。流程如下把以下信息提供给 LLM查询树结构仅标题与摘要让模型判断 “哪些部分最可能包含答案”模型基于以下进行选择对查询的语义理解文档的高层结构章节之间的关系例如问到 Bigtable 里的 Chubby模型可能选择“Architecture”“Consistency Synchronization”这一步用“显式决策”取代了“向量相似度”。Step 3取回完整上下文一旦锁定相关章节系统取回这些节点的完整文本可选地纳入子章节保证完整性把它们整合为结构化上下文这样检索是在“章节级”进行而不是在任意 chunks 上。Step 4生成答案最后把取回的上下文交给 LLM 生成答案。模型被指示仅使用提供的上下文跨章节综合信息可选地给出引用这一步与传统 RAG 类似——关键差异在于上下文的选取方式。Comparison with Vector RAG实用视角用一个问题来说明差异“Bigtable 如何在副本间处理一致性”传统 RAG基于“consistency”“replication”等词的相似度检索 chunks可能返回部分相关的文本块需要模型在生成时自行滤噪Vectorless RAG先定位“相关章节”如 “Consistency Synchronization”取回整节内容提供更连贯、更聚焦的上下文Where This Helps —— and Where It Doesn’tVectorless RAG 更有优势的情境文档结构清晰问题需要在章节间导航上下文分散于相邻子节但它并非在所有地方都更好。Trade-offs更高延迟每次查询涉及多次 LLM 调用单次查询成本高于向量检索依赖结构质量结构弱或噪声大效果下降不太适合大规模、强非结构化的语料Cost and Performance ConsiderationsComparison of Traditional RAG vs Vectorless RAGKey TakeawayVectorless RAG 并不是替代传统 RAG而是改变检索策略传统 RAG高效、相似度驱动、可扩展Vectorless RAG结构化、推理驱动、更有选择性如何选择取决于问题本身大规模搜索 → Vector RAG结构化文档上的推理 → Vectorless RAGImplementation下面我们构建一个基础的 Vectorless RAG 系统从文档结构化到检索。 完整端到端代码见https://github.com/alphaiterations/agentic-ai-usecases/tree/main/advanced/vectorless-rag输入文档使用 Google 发表的 Bigtable 论文https://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdfSetup:创建并激活虚拟环境macOS/Linux:python3 -m venv .venvsource .venv/bin/activateWindows命令行:python -m venv .venv.venv\Scripts\activate从 requirements.txt 安装依赖# Core LLM and Agentic Frameworkopenai2.30.0 # OpenAI API clientlanggraph1.1.4 # LangGraph for building state graphs and agentspydantic2.12.5 # Data validation# PDF ProcessingPyMuPDF1.27.2.2 # PDF parsing/manipulation (fitz)pymupdf4llm # Layout-aware PDF to markdown conversion# Utilitiespython-dotenv1.2.2 # Environment variable management (.env files)创建 .env 文件并设置 OPENAI_API_KEY继续往下。Step 1Tree GenerationVectorless 检索的第一步是把文档转换成“可导航的结构化表示”。我们不再把它当作平铺的文本而是构建一棵反映逻辑组织的“分层树”。为此我们使用 pymupdf4llm基于 PyMuPDF 的轻量库。它支持保留版面信息的 PDF 解析并能在保留标题结构的同时优雅地导出 markdown。也可以用现成方案如 PageIndex 来直接生成结构化表示。但在此实现中我们自建树结构以便完全掌控解析、层级与元数据。核心思路我们构建一棵树其中每个节点代表一个章节章、节、小节等节点来自 markdown 标题#、##、###……父子关系反映文档结构每个节点映射到页码范围与内容解析策略实现包含三步Extract structured markdown使用 pymupdf4llm.to_markdown() 保留版式与标题。Build hierarchy from headers解析 markdown 标题层级用栈式方法构建树。Align content with pages借助 page-level chunks 精准校正页码范围使每个节点与原文页码对应。此外标题会做类型分类编号、罗马、无编号等高层节点会生成摘要叶子节点保留最细致的内容最终得到 DocumentTree一种可遍历、可查询、可推理的 PDF 结构化表示。tree.py-------Parses a PDF into a hierarchical DocumentTree using PyMuPDF4LLM.Uses layout-aware PDF parsing without vector embeddings.Strategy:1. Extract markdown with layout preservation using PyMuPDF4LLM2. Parse markdown headers into tree hierarchy3. Use page_chunks for accurate page boundary detectionInstall: pip install PyMuPDF pymupdf4llm...代码保持不变Step 2RetrievalTree Navigation有了结构化的 DocumentTree接下来进行检索。我们不做“一步到位”的查询而是“逐步导航这棵树”让模型决定下一步是在当前节点取内容还是下钻到它的子节点核心思路把检索视为“在树上的一系列决策”从根开始在每个节点评估与查询的相关性要么停止并抽取内容或进入更相关的子节直到触发停止条件置信度低、达到最大深度或抵达叶子。实现组件检索流水线由四个主要阶段组成使用 langgraph 构建AnalyzeLLM 决策输入Query、当前节点标题、摘要、内容预览、子节点列表输出置信度、是否下钻、下一个子节点、简要理由Descend树遍历进入选定的子节点重复分析Retrieve内容抽取当停止下钻时从当前节点抽取完整内容与页码元数据Generate答案生成把取回的章节交给模型生成有依据的答案并可带引用执行流程Question ↓[Step 1] Analyze Node ← LLM evaluates relevance and decides next action ↓[Step 2] Route Decision ← Descend into children, retrieve content, or backtrack ↓[Step 3] Retrieve Content ← Extract full text from relevant nodes ↓[Step 4] Generate Answer ← LLM synthesizes final answer with sources ↓Answer Path Confidence Sources我们会记录每一步包括遍历路径每个节点的决策置信度最终使用的来源相比黑盒检索这让流程完全透明、便于调试。关键特性检索是迭代的而非一锤子买卖决策是显式且可检查的导航依赖“结构 推理”系统自然把注意力集中在“相关子节”而非宽泛的 chunks下面的完整实现展示如何通过有状态的图与受控的 LLM 调用来组织这次遍历。retriever.py------------Agent-based retrieval that navigates a DocumentTree to answer a query,with detailed logging of every LLM call and decision....代码保持不变接下来定义 main.py把两部分串起来。main.py-------Vectorless RAG - LangGraph Agent PDF Tree (no PageIndex)......代码保持不变在终端运行((.venv)) python main.py脚本首先用 pymupdf4llm 从 PDF 抽取文本并创建树形结构。以下是数据样例{ document_name: bigtable-osdi06, root: { id: root, title: bigtable-osdi06.pdf, ...}随后会在仓库的 results 目录生成 langgraph 流程图。Vectorless RAG Flow以下是终端输出片段包含某个问题的最终答案((.venv) ) (base) userAS-MAC- vectorless-rag % python main.py...Done: 1/1 questions answered successfully完整端到端代码请见 GitHub 仓库。Practical Aspects of Vectorless RAG从上述实现与执行轨迹可以看到构建 Vectorless 检索系统有一些务实考量1. 结构质量很关键一切取决于文档是否被良好地解析为树标题干净 → 更好导航PDF 噪声大 → 决策更弱缺少层级 → 检索趋于扁平、效果打折实际中投入在“高质量解析版面 标题”上的精力会直接反映在检索质量上。2. 节点粒度的权衡如何定义节点会影响准确性与性能过粗章节太大 → 答案不够精确过细切得太碎 → 遍历更深LLM 调用更多通常采用平衡的层级节 → 小节 → 叶子效果最佳。3. 遍历深度 vs. 延迟例如运行结果Total LLM calls : 4 (3 navigate 1 answer)Total latency : 15.60s每次导航都会增加时延。在真实系统中你需要限制最大深度调整停止阈值置信度避免不必要的探索4. Prompt 设计影响行为遍历的质量高度依赖“导航 prompt”指令清晰 → 决策更佳含糊其辞 → 导航随机哪怕是对 “should_descend” 这类定义的细小变化都会显著影响效果。5. Logging 必不可少此方法的优势之一是可观测性你能看到系统“到底去了哪里”你能调试“为什么这么决策”你能基于真实轨迹去调参如果没有类似Decision : ↓ descendReasoning : The Introduction section directly addresses the query这样的日志系统改进会很困难。6. 最适合结构化文档这种方法在以下情形表现最佳文档有清晰的章节论文、报告、文档信息组织有逻辑不适合内容高度非结构化日志、聊天、杂乱文本没有可跟随的层级7. 仍需高质量内容听起来显然但在这里更重要如果正确的信息不在明确的章节里系统就没有“语义兜底”因此内容组织本身也是系统设计的一部分。Vectorless RAG 把重心从“到处搜”转向“聪明地导航”。ConclusionVectorless RAG 把检索重新表述为“有引导的过程”而非“一次性查找”。通过保留文档结构并逐步导航系统在“去哪、何时停、取什么”的每个环节都进行显式决策。结果是在结构化数据上不仅更有效而且更透明、可解释。在实践中这不是“二选一”于传统 RAG 与 Vectorless RAG。它们是不同的架构选择可能互补甚至在同一系统中并存。此方法要强调的是检索不必仅依赖相似度也可以从结构、导航与受控推理中涌现。AI行业迎来前所未有的爆发式增长从DeepSeek百万年薪招聘AI研究员到百度、阿里、腾讯等大厂疯狂布局AI Agent再到国家政策大力扶持数字经济和AI人才培养所有信号都在告诉我们AI的黄金十年真的来了在行业火爆之下AI人才争夺战也日趋白热化其就业前景一片蓝海我给大家准备了一份全套的《AI大模型零基础入门进阶学习资源包》包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。有需要的小伙伴可以V扫描下方二维码免费领取人才缺口巨大人力资源社会保障部有关报告显示据测算当前****我国人工智能人才缺口超过500万****供求比例达1∶10。脉脉最新数据也显示AI新发岗位量较去年初暴增29倍超1000家AI企业释放7.2万岗位……单拿今年的秋招来说各互联网大厂释放出来的招聘信息中我们就能感受到AI浪潮比如百度90%的技术岗都与AI相关就业薪资超高在旺盛的市场需求下AI岗位不仅招聘量大薪资待遇更是“一骑绝尘”。企业为抢AI核心人才薪资给的非常慷慨过去一年懂AI的人才普遍涨薪40%脉脉高聘发布的《2025年度人才迁徙报告》显示在2025年1月-10月的高薪岗位Top20排行中AI相关岗位占了绝大多数并且平均薪资月薪都超过6w在去年的秋招中小红书给算法相关岗位的薪资为50k起字节开出228万元的超高年薪据《2025年秋季校园招聘白皮书》AI算法类平均年薪达36.9万遥遥领先其他行业总结来说当前人工智能岗位需求多薪资高前景好。在职场里选对赛道就能赢在起跑线。抓住AI风口轻松实现高薪就业但现实却是仍有很多同学不知道如何抓住AI机遇会遇到很多就业难题比如❌ 技术过时只会CRUD的开发者在AI浪潮中沦为“职场裸奔者”❌ 薪资停滞初级岗位内卷到白菜价传统开发3年经验薪资涨幅不足15%❌ 转型无门想学AI却找不到系统路径83%自学党中途放弃。他们的就业难题解决问题的关键在于不仅要选对赛道更要跟对老师我给大家准备了一份全套的《AI大模型零基础入门进阶学习资源包》包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。有需要的小伙伴可以V扫描下方二维码免费领取