引言
检索增强生成(Retrieval-Augmented Generation, RAG)已成为为大语言模型(LLM)提供外部知识、减少幻觉的标准方法。标准的 RAG 工作流严重依赖于 Embeddings(文本的数字向量表示)和向量数据库(Vector Database)以实现语义搜索。
其基本流程是:将文档分割成块(chunks),将这些块通过 embedding 模型转换为高维向量,并存储在向量数据库中。当用户提问时,通过近邻搜索(nearest-neighbor search)检索相关上下文,并将其提供给 LLM 用于生成回答。这种方式使得模型能基于语义相似性来查找信息。
然而,“向量数据库 + Embeddings”的模式在成本、复杂性和性能方面带来了显著的开销。鉴于这些挑战,业界对探索基于 Embedding 的 RAG 替代方案的兴趣日益浓厚。研究人员已经开始开发无需 Embedding 的 RAG 方法和系统,以期绕过向量搜索的瓶颈。本文将深入探讨无 Embedding RAG 的概念,分析其兴起的原因,并将其与传统的向量数据库方法进行比较。
核心观点:
- 传统 RAG 系统 依赖 Embeddings 和向量数据库。文档被分块、向量化,并索引在向量数据库中,通过近邻搜索为 LLM 提供语义上下文。
- 向量搜索的局限性 包括语义鸿沟、检索准确率下降和缺乏可解释性。在对精度要求高的领域,Embeddings 可能会检索到主题相似但并非答案的段落。
- 基于 Embedding 的 RAG 面临着基础设施复杂性和高昂成本。生成 Embeddings、维护向量数据库以及数据更新后的重新索引都需要大量的计算和存储资源。
- 无 Embedding RAG 采用替代方案,如基于关键字的搜索(如 BM25)、LLM 驱动的迭代检索(如 ELITE)、基于知识图谱的方法(如 GraphRAG)和基于提示的检索(如 Prompt-RAG),以解决语义和操作上的限制。
- 无 Embedding RAG 的优势 包括更好的可解释性、更低的延迟、更少的存储需求和更强的领域适应性。这使其在医疗、法律、金融等专业领域以及需要透明度或跨文档推理的场景中极具价值。
传统的 RAG 与向量数据库
在传统的 RAG 架构中,“Embeddings + 向量搜索”构成了“检索”环节的核心。
-
离线索引阶段:源文档被切分成块,每个块通过 Embedding 模型生成一个向量表示。随后,这些向量被存储在一个为快速近邻搜索而优化的向量数据库中。
-
在线查询阶段:当接收到用户查询时,系统将查询同样转换为向量,并在向量数据库中查找与查询向量最相似的 Top-K 个文档块向量。这些检索到的文本块作为上下文,连同原始查询一起被送入 LLM,以辅助生成最终答案。

该流程的关键优势在于向量嵌入能够捕捉语义相似性,即使问题的措辞与文档中的段落不同,只要含义相近,就能成功匹配。同时,向量数据库能够高效处理高维相似性搜索,确保即使在语料库扩展到数百万个文档块时,检索延迟仍在可控范围内。
Embedding 与向量搜索的局限性
尽管广受欢迎,但基于向量的 RAG 方法存在一些显著的缺点:
语义鸿沟
Embeddings 和向量搜索中普遍存在语义鸿沟。这是因为密集的向量相似性可能只捕捉到主题上的相关性,而未必是答案的精准匹配。它们可能返回语义上相似但实际上无关的段落,尤其是在答案的精确性(如具体的数字、日期或否定词)至关重要时。此外,Embeddings 在处理领域特定术语、稀有实体或需要连接多个文档进行推理的多跳(multi-hop)问题时也常常表现不佳。
检索准确性
上述问题可能导致在实际的 RAG 应用中检索准确率不理想。当 Embedding 模型无法捕捉问题与答案之间的确切关系时,排名靠前的向量命中结果可能并不包含答案。有报告指出,即使在优化了“分块 + Embedding + 向量存储”的流程后,检索到正确文本块的准确率通常也低于 60%。不相关的上下文可能导致 RAG 系统提供错误或不完整的答案。
缺乏可解释性与控制力
使用向量嵌入时,我们很难解释为什么会错过一个答案或检索到一个错误的段落,因为向量本身是一个“黑盒”,我们无法轻易解读其“思考”过程。这使得调整检索行为(例如,强调某些关键字或数据字段)变得非常困难。
基础设施复杂性与成本
这套架构涉及离线成本(为成千上万的文档生成 Embeddings 所需的时间和计算资源,通常需要使用 GPU)和在线成本(运行向量数据库服务,这可能是内存密集型的)。对于没有专业基础设施的团队来说,这可能非常昂贵。此外,还有索引本身的维护成本,即当数据更新时需要重新计算 Embeddings。
传统的基于向量数据库的 RAG 推动了 LLM 语义搜索的发展,但其局限性也激励着研究人员探索超越向量数据库的检索增强新范式。
什么是无需 Embedding 的 RAG?
无 Embedding RAG(RAG without embeddings)指的是任何不以向量嵌入作为主要检索手段的 RAG 架构。它省略了“向量化查询和文档,然后进行向量近邻搜索”这一经典步骤。
那么,没有了 Embedding,我们如何检索相关信息呢?以下是一些新兴的方法:
词法或关键字检索
一种最直接的“无 Embedding” RAG 实现方式是回归到词法关键字搜索(或称稀疏检索)。系统不再比较连续的向量,而是通过 BM25 等算法搜索查询与文档之间共享的重叠关键字/词元。实际上,这种“老派”的稀疏关键字方法在许多情况下表现出与先进的向量方法相当的竞争力。
例如,一项 XetHub 的基准测试显示,BM25 的性能与顶级的 OpenAI Embeddings 相比“差不了多少”。要实现 85% 的相关文档召回率,向量搜索可能需要返回 7 个结果,而经典的关键字方法则需要 8 个。考虑到维护向量数据库和 Embedding 服务的成本,这种微小的准确性差异可能无足轻重。
换句话说,一个调优良好的关键字搜索系统或许就能满足大部分需求,且无需承担运行向量数据库的巨大开销。

实现上,可以从用户提示中生成一个优化的搜索查询(可能借助 LLM 提取关键术语),然后对一个全文搜索引擎(如 Elasticsearch 或 SQL 的全文索引)执行查询。LLM 随后可以将检索到的文本作为上下文。这种方法利用了词法匹配的高精度信号,有时比密集向量检索的结果更具相关性。
基于 LLM 的迭代式搜索(将推理作为检索)
另一种无 Embedding RAG 的方法是利用 LLM 本身通过推理和推断来进行检索。系统不再是对向量相似度分数进行排序,而是“询问 LLM”以找出答案可能所在的位置。例如,可以向一个 LLM 代理提供文档标题或摘要列表,让它推理哪个文档最有可能包含答案,然后去获取该文档内容。
这就是基于 Agent 的 RAG 背后的理念——一个 LLM Agent “使用”工具,在进行详细分析之前,先按标题/元数据搜索文档目录。
同样,研究框架 ELITE(Embedding-Less Retrieval with Iterative Text Exploration)也赋予了 LLM 迭代式缩小相关文本范围的能力。它使用一种自定义的重要性度量来引导搜索过程。

上图展示了一个无 Embedding 的 RAG 循环。用户查询被发送给 LLM,后者生成从语料库中检索片段的线索。该片段随后由一个重要性度量进行评分,以决定下一步应关注哪个窗口。这个新的、更具针对性的焦点被反馈给 LLM,循环迭代直至满足停止条件,系统最终返回答案。这种方法让模型通过其原生的语言理解和逻辑推理能力来执行检索,而不是将检索任务“委托”给一个 Embedding 索引。
结构化知识与图检索
这种方法不是将知识库作为非结构化的文本块添加到向量索引中,而是将数据结构化为一个知识图谱(Knowledge Graph)或其他符号数据结构。
在基于图的 RAG 中,从源文本或数据库中提取的实体(如人物、地点或概念)被表示为节点,关系被表示为边。为响应用户查询,系统检索相关节点并沿着边遍历,收集一组事实或相关信息,然后将其传递给 LLM。
微软最近发布的 GraphRAG 就是一个很好的例子,它“保留了 RAG 的优点,但在索引器和检索器之间加入了一个知识图谱”。

在 GraphRAG 中,系统不再仅仅返回与查询“看起来相似”的文本块,而是返回一个包含相关实体和关系的子图。这为 LLM 提供了一个结构化的“记忆宫殿”,展示了事实之间是如何连接的。这对于需要多跳推理或事实连接的复杂查询(例如,识别出做过 X 的人物 A 与别处提到的人物 B 有关联)尤其有价值。
基于 Prompt 的检索(Embedding-Free Prompt RAG)
最近的另一项研究探索了是否可以利用 LLM 的 Prompt 能力来执行文本检索,而无需显式的向量。Prompt-RAG 就是这样一种方法,它在一个 2024 年的论文中被提出,并应用于韩国医学这一特定领域。
Prompt-RAG 不使用向量索引,而是从文档中构建一个结构化的目录(Table-of-Contents, ToC)。然后,它通过 Prompt 指示 LLM 选择与查询相关的章节(标题)。

这些标题下的内容随后被组合成上下文。LLM 被直接用来解析查询和文档结构,并做出检索决策,完全不需要 Embedding 向量。实验证明,在该特定领域,Prompt-RAG 的表现优于传统的基于 Embedding 的 RAG。这表明,当 Embedding 无法很好地捕捉领域语义时,基于 Prompt 的检索可以成为一个很好的替代方案。
总而言之,无 Embedding RAG 用经典的信息检索技术或由 LLM 驱动的逻辑取代了向量搜索步骤。这在某种程度上是对过去几年趋势的一种逆转:我们正在“回归”使用符号和文本进行检索,但这一次,我们拥有了大型 LLM 增强的推理能力。
无 Embedding RAG 的优势
为什么要考虑这些替代方案?无 Embedding RAG 具有一些切实的潜在优势,能够解决我们之前提到的许多局限性:
| 优势 | 含义 |
|---|---|
| 提升检索精度 | 由于不完全依赖向量相似性,无 Embedding 方法可以发现被向量忽略的信息。通过精确的关键字匹配或 LLM 推理,可以找到措辞与查询不同但意义相关的答案。 |
| 降低延迟与索引开销 | 无需计算和存储庞大的 Embedding 索引,也无需执行高维相似性搜索,从而实现更轻量级的检索。 |
| 减少存储与成本 | 无需或最小化向量存储,减少了内存占用和持续的基础设施成本;可以转向按次付费的使用模式。 |
| 更好的可解释性与适应性 | 关键字匹配、知识图谱遍历或 Agent 的选择过程比不透明的向量相似性更易于解释和微调。 |
| 领域专业化 | 在数据稀疏或专业领域,通过利用文档结构(目录、本体、知识图谱)和领域线索,其性能可以超越通用 Embedding。 |
值得注意的是,这些优势并非“免费午餐”。替代方案通常会引入新的挑战,例如多次 LLM 调用的计算成本,或构建知识图谱的工程复杂性。然而,摆脱对向量数据库的依赖可以消除当前 RAG 系统的许多痛点。
应用场景与对比
我们应该在何时考虑使用无 Embedding RAG 架构,而不是经典的向量数据库方法?这取决于你的任务、数据、约束条件等多种因素。以下是一些用例以及两种方法的对比:
| 场景 | 传统向量 RAG 的挑战 | 无 Embedding / 图 / Agent 方案的优势 | 推荐策略 |
|---|---|---|---|
| 复杂的多跳问题 (如“X 和 Y 有什么联系?”) | 分别检索关于 X 和 Y 的块,但不知道它们必须被连接起来;生成步骤可能会幻化出联系。 | 图可以明确地展示出路径 (X → … → Y)。以推理为中心的检索为 LLM 提供了一条可遵循的事实链。 | GraphRAG(实体/关系遍历)或能够规划多跳查询的 Agentic 检索器。 |
| 严格的事实/合规性需求 (法律、金融、医疗) | 语义上的“差之毫厘”是不可接受的;如果措辞不同,权威条款/案例可能会被错过。 | 关键字/词法信号和领域知识图谱可以实现精确匹配和可审计的追溯;很容易展示为什么检索到了某个片段。 | 关键字/BM25 过滤 → 可选的 LLM 重排;或领域图谱(如引用、法规)。如果使用向量,也应先进行混合检索。 |
| 专业领域 / 小数据量 (生物医学、法律、小众技术文档) | 通用 Embedding 难以处理专业术语/符号;可能会错误排序或遗漏关键段落。 | 利用文档结构(标题/目录)、本体和领域图谱;基于 Prompt 的章节选择性能可能优于向量。 | 基于 Prompt 的检索(感知目录/标题)、本体/图谱查询,或词法检索 → LLM 重排。 |
| 低查询量、海量语料库 (档案馆、研究资料库) | 当查询稀少时,维护一个大型向量索引的成本很高;数据更新时的重新 Embedding 增加了运维开销。 | 按需的 Agentic 检索避免了闲置基础设施;成本仅在查询到达时产生。 | 基于 Agent 的检索,通过目录/元数据进行有针对性的阅读;可选择小型词法索引代替向量数据库。 |
提示: 许多团队正在走向混合模式——先执行快速的词法过滤,然后是向量搜索,最后由 LLM 进行重排;对于复杂、多跳或受监管的查询,则回退到图或 Agent 检索。
RAG 架构的未来展望
这些无 Embedding 方法会超越或取代向量数据库在 RAG 中的地位吗?我们认为,更可能的情景是共存与互补。以下是一些未来趋势的预测:
| 趋势 | 核心洞见 | 无 Embedding vs. 向量方案的优势场景 |
|---|---|---|
| 混合与自适应流水线 | 未来的系统不会只选择一种方法,而是会混合搭配:对常见查询首先进行快速向量搜索,当需要推理时则回退到图/Agent 检索。像微软的 AutoGen 这样的项目可以协调多个检索器。 | 当需要推理或多跳查询时,无 Embedding 方案是理想选择。向量方案则在大规模快速语义相似性搜索方面表现出色。 |
| 知识图谱 RAG | GraphRAG 和 Neo4j 等项目展示了巨大潜力:将非结构化文本转换为图谱。图谱既可以作为 Embedding 的输入,也可以独立使用。混合图谱+向量存储正在兴起。 | 无 Embedding 方案在结构化、关系密集的领域(生物医学、情报、金融)表现优异。当没有明确结构时,向量方案适用于广泛的覆盖范围。 |
| 更大的上下文窗口 | 更大的上下文模型(10万+ token)正在重塑检索方式:可以无需分块加载整个文档。像 ELITE 这样的迭代式阅读策略变得更加强大。推测 LLM 可能会在内部执行上下文内检索。 | 当模型可以直接在长上下文中“阅读和推理”时,无 Embedding 方案表现良好。向量方案在降低上下文成本和高效缩小焦点方面仍具优势。 |
| 评估与基准 | 越来越多的并排基准测试正在涌现:ELITE、Prompt-RAG、RAPTOR 等显示出效率提升。评估任务包括长文档问答、多跳问答和特定领域问答。可解释性(如图路径、引用)可能会增强用户信任。 | 当重视可解释性和效率时,无 Embedding 方案更有效。当基准测试要求在海量语料库中实现速度和覆盖率时,向量方案是最佳选择。 |
向量数据库在处理大规模语义相似性方面表现强大,而无 Embedding 方法在推理、结构化和可解释性方面更胜一筹。未来在于能够根据具体情况灵活运用各自优势的混合、自适应系统。
常见问题解答 (FAQ)
为什么传统 RAG 依赖于 Embeddings 和向量数据库?
传统 RAG 通过将文本块嵌入到向量空间并存储在向量数据库中来工作。当回答查询时,模型将用户查询嵌入到同一向量空间并执行近邻搜索,然后使用检索到的段落的 Embeddings 作为上下文来回答查询。这样,即使措辞不同,RAG 也能检索到与查询意义一致的段落。
Embeddings 和向量搜索在 RAG 中的主要局限性是什么?
Embeddings 和向量搜索存在语义鸿沟,检索到的段落中可能只有一小部分是真正包含答案的,而许多只是主题相似。这会降低检索准确性,尤其是在对精度敏感的领域(如法律、医疗)。此外,向量搜索是一个“黑盒”,很难推断为什么会检索到某个段落。存储和维护 Embeddings 和向量数据库还带来了显著的基础设施成本和复杂性(例如,每次文档更改都需要重新索引)。
无 Embedding RAG 是如何工作的?它有什么好处?
无 Embedding RAG 方法使用向量搜索以外的方式进行检索,包括基于关键字的检索、LLM 引导的迭代搜索以及基于图或 Prompt 的检索。它们可以提高检索精度,减少索引开销,降低计算成本,并增强可解释性。无 Embedding RAG 在专业或数据稀疏的领域(如医疗、金融、法律)特别有前途,因为在这些领域,通用 Embeddings 往往无法捕捉特定领域的语义。
结论
无 Embedding RAG 正作为经典向量数据库方法的一个重要替代方案兴起。虽然在许多情况下,Embeddings 和向量搜索仍然是进行大规模语义检索的最佳选择,但它们也带来了复杂性、成本和准确性的挑战。
另一方面,关键字搜索、知识图谱以及基于 LLM 的推理和解释等无 Embedding RAG 技术,提供了更简单、更快、更可解释的解决方案。
向量数据库在快速语义相似性搜索方面表现出色,但在处理重推理和特定领域问题时则显得力不从心,而这正是无 Embedding RAG 的优势所在。未来的混合系统将结合两种方法的优点,创建出能够提供更高准确性、更低延迟和更强信任度的自适应流水线。
关于
关注我获取更多资讯