向量库是RAG的必需品吗？深入探讨其定位、替代方案与未来演进

当前，我们可以将AI项目大致划分为三个主要类别：

第一类是工作流AI，这类以Agent平台（如Coze、Dify）为核心，并整合了AI表格、多维表格等工具，主要目标是构建服务于企业体系的、以实现降本增效为根本的AI解决方案。

第二类和第三类则都属于AI知识库的范畴。其中一类专注于单轮问答，不涉及复杂的意图识别或模型记忆机制；另一类则以支持多轮对话为核心，对底层数据的质量与工程架构的要求都更高，这也通常是普通开发者较少涉足的AI技术深水区。

每当提及AI知识库，人们往往会立即联想到一个与之紧密相连的技术概念——RAG（检索增强生成）。紧接着，向量数据库也会自然而然地进入大家的视野。然而，基于我个人的实际项目经验来看：RAG技术确实是必要的，但向量库或许并非必需，至少在我观察到的实际应用案例中，真正广泛使用它的公司并不算多。

至于背后的原因，让我们展开进一步的探讨。

RAG技术的必要性

我第一次在项目中应用RAG技术大约是在两年多以前。事实上，当时我并未明确知晓这项技术的名称，因为相关的公开资料还比较有限。我的关注点完全集中在产品目标上，需求非常明确：

在医疗问诊的具体场景中，当患者已经确诊某种疾病时，所提供的治疗建议绝不能直接依赖大模型的自由生成，而必须严格依据本地知识库中的权威数据。

这个需求实现起来反而相对简单，因为公司历史上已经积累了较为完善的药品数据库，药品说明书中包含了清晰的适应症映射关系。因此，我们只需要在最终生成治疗建议时，将检索到的相关药品数据嵌入到提示词（Prompt）中即可。例如使用这样的提示词模板：

你是一名专业的医疗顾问，必须严格根据提供的权威药品信息为患者提供建议。  
  
【患者确诊的疾病】  
{用户输入的疾病名称}  
  
【权威药品清单（必须严格遵守）】  
{从您知识库中检索到的相关药品信息，例如：  
- 药品A：用于治疗[疾病A]、[疾病B]。用法：一次一片，一日一次。禁忌：孕妇禁用。  
- 药品B：用于治疗[疾病A]、[疾病C]。用法：一次两粒，一日两次。禁忌：对本品过敏者禁用。  
}  
  
【你的任务】  
请基于且仅基于上方【权威药品清单】中的信息，为患者提供治疗建议。  
  
【你必须遵守的规则】  
1.  **禁止编造**：绝不能推荐清单之外的任何药品，也绝不能添加清单中未提及的功效或副作用。  
2.  **核心内容**：你的回答必须包含：  
    -   推荐哪几种药（必须来自清单）。  
    -   简要的用法用量（必须来自清单）。  
    -   最重要的禁忌或警告（必须来自清单）。  
3.  **安全兜底**：如果清单为空，你必须回答：“未在药品库中找到标准治疗方案，请立即咨询医生。”  
4.  **最终建议**：在结尾必须加上：“以上信息仅供参考，用药前请咨询医生并仔细阅读说明书。”  
  
现在，请开始你的回答：

大家可以清晰地看到，在上述实现方案中，完全没有用到向量数据库。唯一可能出现的问题是：用户输入的已确诊疾病名称，无法与我们知识库中的“适应症”字段精确匹配，导致检索不到数据，即系统的泛化能力不足。例如：

  1. “房颤” 与 “心房颤动”；
  2. “灰指甲” 与 “甲真菌病”、“皮肤癣菌所致甲感染”；
  3. ……

处理这类问题通常有两种思路：一是直接扩展原有知识库，为疾病增加别名、俗称等字段。另一种方案则是引入向量库，通过语义相似度来解决术语不一致的泛化问题。

然而，扩充别名的方案是确定性的、稳定的。而向量库的策略本质上是一种概率性匹配（相似度匹配），这自然会引入不确定性，并可能引发其他问题，例如过度泛化：“高血压”和“颅内高压”在通用语境下都包含“高压”这个概念，但在医学上是完全不同的疾病，若在此处匹配错误，后果将非常严重。

因此，在实际的严肃应用场景中，向量库的角色反而显得有些尴尬。它似乎并非与RAG技术强制绑定的必需品？

向量库在RAG中的真实定位

RAG技术本身未必一定要依赖向量库。它的核心是 “检索”与“生成” 的结合，而检索的方式可以多种多样：

  1. 关键词检索：像传统搜索引擎一样使用BM25等算法进行词项匹配。
  2. 语义检索：使用向量数据库进行嵌入向量的相似性搜索，这也是当前的主流做法。
  3. 混合检索：结合关键词检索和语义检索，取长补短。
  4. 基于知识图谱或规则的检索：利用结构化的关系网络进行精准查询。

毫无疑问，向量库和向量搜索技术正是搭乘了RAG这辆技术快车，从一个相对小众的领域，一跃成为AI基础设施中的明星组件。它的出现，有效解决了传统关键词检索无法理解查询语义的痛点。例如，搜索“苹果”时，理想情况下应能同时返回关于“Apple Inc.”和“水果苹果”的相关信息。

不过，向量库能成为“明星”，或许与以下厂商的大力推动密不可分：例如 Milvus（开源向量数据库）和 Zilliz Cloud（其全托管云服务）。他们投入了大量资源进行市场教育（包括技术布道、文档编写、社区活动等），极大地普及了向量数据库的概念。最终的结果是，只要提到RAG，就常常会附带提及向量库；而深入探讨向量库，又很难绕过Milvus。

除此之外，腾讯云的VectorDB、阿里云的OpenSearch、华为云的GaussDB等产品也都集成了向量检索能力；国外市场的选择则更为多元。总而言之，我认为：RAG的广泛需求催热了向量库市场，而各大向量库厂商之间的激烈竞争与技术推广，又反过来让RAG的实现变得更强大、更易用，共同推动了这场AI应用开发的变革。

只不过，对于构建AI知识库而言，RAG虽属必备，但向量库实际上更像一个“锦上添花”的选项，在多数严谨场景下可能并不需要。那么，问题随之而来：究竟什么样的场景才会真正用到向量库呢？

向量数据库的适用场景分析

就我目前的观察，使用向量库的场景，多半是团队希望寻求一种更“省力”的方案。他们不愿意投入精力进行细致的数据清洗与结构化工作，或者只愿意利用AI对数据进行简单的预处理，例如：将大量原始的非结构化文档（如技术手册、客服历史问答记录等）直接“倾倒”进向量库，然后期待当用户提问时，系统能自动检索出最相关的有效信息。

这里的逻辑看似简单直接：传统的关键词检索容易遗漏那些语义相似但用词不同的内容，而向量检索能更好地从语义层面解决这一问题。

然而，实际情况往往并非如此理想。可以说：在绝大多数对准确性和可靠性要求极高的生产环境中，直接丢弃原始、未经清洗和结构化的文档，仅依赖向量库的语义相似性检索，其最终效果常常令人失望，甚至可能引发严重问题。

原因如前文所述，向量搜索返回的是在嵌入空间中最“语义相似”的文本片段（chunks），而非最“相关”或最“准确”的答案。一次查询可能会返回十几个在局部语义上相关，但整体上下文无关甚至矛盾的文本块，这需要后方的大语言模型（LLM）耗费大量计算资源去费力地甄别、筛选和总结，反而极大地增加了产生“幻觉”（即编造信息）的风险。

例如：查询“某产品的定价策略”，向量库可能返回包含“定价”、“策略”等词语的董事会纪要片段、过时的市场报告、某位员工的个人建议邮件等，而不是官方的、最新的定价政策文档。

这些问题在项目初期选择“偷懒”方案时便已埋下种子。使用AI自动切割文档，很容易破坏原文的连贯性，导致重要信息被割裂在不同的片段中。

因此，要想用好向量库，“偷懒”几乎是不可能的。每次检索初筛后，往往还需要叠加各种后处理策略（如元数据过滤、重排序等）来进行精炼。而为了实施这些过滤策略，在最初处理数据时就需要进行大量的额外标注工作（例如为文档片段打上类别、来源、重要性等标签）。既然已经在进行标注和结构化了，那么为何不从一开始就采用更精确的检索方式（如基于标签或关键词的检索），反而要引入向量库带来的不确定性呢？

综上所述，我们不妨回归本质来思考：RAG的核心目标是确保大模型生成的答案牢牢锚定在可信、权威的知识源上。

向量库是一种高级的检索工具，它旨在解决RAG中“检索”环节遇到的语义泛化问题（即用户提问与知识库表述不一致）。但在引入这种强大的泛化能力以解决“术语不匹配”的同时，它也带来了结果的不确定性。因此，必须结合其他技术手段（如元数据过滤、重排序、混合搜索等）来约束和引导这种不确定性。

而许多人设想的“直接丢弃杂乱无章的原始文档，指望向量库和LLM的组合能自动创造奇迹”，这本质上属于一种愿望式编程。其结果必然是不稳定、不可靠的。

正因为上述这些原因，向量库在实际中的使用体验并不总是尽如人意。许多团队事实上并未采用它，甚至一些已经采用的团队也因为感觉复杂和效果未达预期而逐渐放弃。

那么，是否存在有效的替代技术呢？答案是肯定的。例如，一种名为 PageIndex 的新兴方案。

PageIndex：一种基于推理的RAG新范式

PageIndex是一款基于推理的RAG系统。它创新性地模拟了人类专家在查阅长文档时的思维过程：通过树状搜索逐步定位和提取所需知识。这使得大语言模型能够通过主动思考与推理，导航到最相关的文档章节，而非依赖简单的相似度匹配。其检索过程主要分为两大步骤：

  1. 为文档生成结构化的目录树状索引；
  2. 基于生成的树状索引，执行推理驱动的树搜索。

并且它是开源的，尽管目前知晓它的人还相对较少。

Image

其核心理念在于：检索不应是一次性的、机械的匹配动作，而应是一个由模型推理能力驱动的、渐进式的探索过程。它的标准工作流程（SOP）如下：

  1. PageIndex OCR：将PDF等文档转换为保留原有层级结构（如标题、章节）的Markdown格式。
  2. 生成树形索引：基于OCR结果，自动生成一个类似目录（ToC）的轻量级JSON树状结构。
  3. 基于树搜索的检索：提供两种模式（基于LLM推理或基于规则值），在树状索引上进行搜索，返回最相关的节点、精确的页码以及完整的检索路径轨迹，避免了传统向量检索中“拍脑袋”决定返回前K个结果（top-k）的武断性。

相对于向量库RAG的“相似度近邻”搜索逻辑，PageIndex采用了一种“逐层缩小范围”的漏斗式逻辑，依靠推理在树状结构上从粗到细地定位目标。为了更清晰地说明，我们以一个实际案例来演示：

Image

假设我们手中有一份某公司的《2024年年度报告》，大约120页。PageIndex的处理流程如下：

第一步：文档层级化解析

PageIndex OCR会将PDF识别成对大语言模型友好的、保留了标题/小节/表格/列表等层级信息的Markdown。你可以选择按页、按节点或按需拼接来获取结果。例如，报告中的一个片段可能被解析为：

# 7 经营情况讨论与分析（MD&A）  
## 7.2 收入与成本  
### 7.2.1 毛利及毛利率  
... 2024 财年，公司毛利率为 **38.4%**（见合并利润表注释 3）...

第二步：构建树状索引

对OCR生成的Markdown进行“树生成”操作，形成一个轻量的JSON结构。每个节点都包含标题、node_id、page_index（页码）和简要摘要，天然形成了一个“可导航”的智能目录：

{  
  "title": "Management’s Discussion and Analysis",  
  "node_id": "0004",  
  "page_index": 35,  
  "nodes": [  
    {  
      "title": "Results of Operations",  
      "node_id": "0005",  
      "page_index": 40,  
      "nodes": [  
        {  
          "title": "Gross Margin",  
          "node_id": "0006",  
          "page_index": 45,  
          "summary": "2024 年毛利率及同比变动，影响因素为产品结构与成本控制..."  
        }  
      ]  
    }  
  ]  
}

这个过程无需向量库，也无需对文档进行生硬的切片（chunking）。每个节点都附带精确的页码和摘要，专为财报、法律文书、技术手册等长文档优化设计。

第三步：执行树搜索

当用户提交查询时，例如：“公司2024年的毛利率是多少？” 系统会在构建好的树状索引上启动推理过程，逐层定位最相关的节点，自动收集所有相关段落，并返回附带精确页码和完整检索轨迹的结果：

{  
  "query": "What is the gross margin for FY2024?",  
  "retrieved_nodes": [  
    {  
      "title": "Gross Margin",  
      "node_id": "0006",  
      "relevant_contents": [  
        { "page_index": 46,  
          "relevant_content": "For fiscal year 2024, the Company’s gross margin was **38.4%** ..." }  
      ]  
    },  
    {  
      "title": "Consolidated Statements - Notes",  
      "node_id": "0012",  
      "relevant_contents": [  
        { "page_index": 102,  
          "relevant_content": "Note 3: ... gross margin of **38.4%** for FY2024 ..." }  
      ]  
    }  
  ],  
  "trajectory": [  
    {"from": "root", "to": "Management’s Discussion and Analysis", "reason": "与经营指标相关"},  
    {"from": "Management’s Discussion and Analysis", "to": "Results of Operations", "reason": "涉及经营结果"},  
    {"from": "Results of Operations", "to": "Gross Margin", "reason": "直接回答毛利率"}  
  ]  
}

该框架支持基于LLM推理和基于规则值的两种树搜索模式，返回透明的节点导航轨迹和精准页码，无需手动调整top-k参数。

最后：证据拼接与回答生成

将检索到的、带有精确引用的证据段落，作为上下文输入给回答模型，并严格要求模型仅基于提供的证据进行回答。这种可溯源、高可信度的方式在实践中很受欢迎：

系统指令：你是一名严谨的财报分析助手。必须严格依据下方提供的“evidence”进行作答；如果证据之间存在冲突或信息缺失，请明确说明。  
用户问题：{query}  
证据(evidence):  
- {page_index: 46, content: "... gross margin was 38.4% ..."}  
- {page_index: 102, content: "... gross margin of 38.4% for FY2024 ..."}  
输出要求：answer（使用中文），citations（按页码列出引用来源）

模型回答示例：

公司的2024财年毛利率为38.4%。依据见年报“毛利及毛利率”小节与合并报表相关注释。 引用页码：p.46, p.102。

可以看到，PageIndex的逻辑非常清晰，更贴近人类的查询习惯，因此很容易被理解和接受。但新的问题也随之浮现！

数据整理与查询泛化的核心挑战依旧存在

首先，用户的提问方式千变万化（即查询泛化问题）。传统RAG的一个痛点在于，其检索效果严重依赖于用户提问的具体“措辞”。如果用户提问的方式不够精准或与知识库表述差异较大，检索就可能失败。这也是人们引入向量库试图解决的问题，但向量库只解决了一部分（语义相似），也留下了一部分（无关相似和准确性）。

PageIndex并不完全相信用户的原始提问是发起检索的最佳形式。其核心组件之一——推理器（Reasoner）——的一项重要工作，就是对原始查询进行重写、分解和优化。

这背后的逻辑，相当于将原本希望由向量库通过“静态嵌入相似度”来解决的泛化任务，移交给了大模型，通过“动态推理驱动的查询规划”来完成。 相当于 将查询泛化从依赖“静态的嵌入向量相似度匹配”，转变为依赖“动态的、推理驱动的查询意图解析与规划”。

这里有一个推理器工作的简单案例：

  • 用户原始提问：“苹果那个最牛的手机芯片咋样了？”
  • 推理器优化后：“Apple A17 Pro芯片性能评测”、“iPhone 15 Pro Max芯片规格与特性”

它主要解决了用户提问措辞口语化、不专业的问题，将其标准化为知识库中更可能存在的规范术语和表述方式。

此外，它还涉及对复杂问题的拆解，例如：

  • 用户原始提问：“对比一下iPhone 15 Pro和三星Galaxy S24 Ultra的摄像头传感器尺寸。”
  • 推理器分解：
    • 子查询1：“iPhone 15 Pro主摄像头传感器尺寸”
    • 子查询2：“Samsung Galaxy S24 Ultra主摄像头传感器尺寸”

总而言之，PageIndex并不直接使用用户的原始提问进行“盲搜”，而是利用大语言模型强大的语义理解和推理能力，将用户的潜在意图“翻译”或“重构”成更贴合知识库内容结构和语言习惯的查询语句，从而增强了对多样化、模糊化用户提问的泛化能力。

紧接着，是第二个核心问题：PageIndex检索到的内容就一定完全相关且足够吗？它如何处理不相关或信息不足的情况？

PageIndex的设计包含一个循环迭代流程。在“响应”阶段，负责生成答案的解答器有一个重要任务：评估已检索到的信息是否真正相关、质量是否合格、以及是否足以完整回答问题。

如果解答器判断最新检索到的片段与问题无关，或者信息质量较差、不足以支撑回答，它会生成反馈“告诉”推理器：“刚才找到的内容不太有用，我们需要调整搜索策略，尝试另一条路径。”

另一个关键任务是对检索结果进行重排序和相关性评估。这本质上是通过对初步结果的审视，来判断其与问题的真实关联度。如果评估不通过，系统会启动新一轮的、更有针对性的检索，直到收集到满足质量与相关性要求的信息集合。

不得不说，这种设计思路非常巧妙，与我们构建稳健数据工程时的“迭代优化”思维高度吻合。当然，这也带来了一个显而易见的代价：PageIndex的流程通常更“费Token”，运行成本相比简单的向量检索会更高。

总结与展望

得益于大语言模型基础能力的飞速发展，尤其是上下文窗口长度的极大扩展，历史上许多为解决特定限制（如模型记忆短、知识陈旧）而诞生的技术，可能会逐渐调整其角色或退出中心舞台，例如曾一度与RAG几乎形成“绑定”关系的向量数据库。

当然，我并非要全盘否定向量库的价值。我的核心目的是打破一种技术路径依赖惯性，提醒大家不要因为某种技术被广泛讨论，就认为它是解决特定问题的唯一或最佳方案。所有的技术选型失误，最终都会转化为真实的项目试错成本。

向量库凭借其在解决语义泛化问题上的独特能力，以及厂商们不遗余力的市场推广，成为了RAG领域的热门话题，几乎形成了“言RAG必称向量库”的印象。但这常常让我们忽略了最根本的问题：

我们的知识究竟以何种形态存在？是高度结构化、标签清晰的数据库，还是原始、杂乱的非结构化文档？不同的数据形态，理应匹配和选择不同的、最适宜的检索增强方案。

向量库是一把出色的“瑞士军刀”，尤其擅长处理语义泛化要求高、数据结构相对松散的非结构化内容检索。但对于那些本身已经具备良好结构或可通过简单规则处理的数据而言，盲目选用向量库，可能只会为系统引入不必要的复杂性和不确定性。

而像PageIndex这类 “推理即检索”（Retrieval as Reasoning） 的新范式，其实在理念上并非横空出世的全新革命。早在一年多前，许多前沿的数据工程项目中，就已经在实践类似“通过模型推理引导精准定位”的思路。因此，它更像是一种现有优秀工程思想的系统化、产品化封装。

PageIndex的核心突破在于，它跳出了传统的 “嵌入-匹配” 框架，尝试直接利用大模型本身的强大推理能力，去模拟人类专家在查阅复杂文档时的逻辑导航过程。它揭示了一个重要趋势：未来的RAG系统，其智能性将不再仅仅局限于后端的“生成”环节，而是会深度前置并融合到“检索”这个更前端的、决定答案质量上限的过程中。

最后，技术选型永远是一场关于成本、收益、复杂度和可靠性的综合权衡。在向量库带来的概率性匹配泛化能力与PageIndex式推理检索带来的高精度与高成本之间，并不存在绝对的优势方。事实上，最优秀的工程实践往往是混合的：用确定性规则处理明确的需求，用向量检索泛化模糊的语义，再用推理模型解决复杂的、多步的深度查询问题……

重申那句老话：实践是检验真理的唯一标准。能够高效、可靠、低成本地解决实际业务问题的技术，就是好技术。我们应当时刻牢记，技术只是工具，解决问题才是最终目的。回归本源，RAG的核心使命从未改变：坚定不移地将大模型的输出，锚定在最权威、最准确、最可信的知识源之上。