向量库刚被捧上神坛，就被最新一代大模型一脚踹下。原因很简单：当模型上下文一口气拉到百万 token，召回和排序一次搞定，传统 RAG 架构里的向量检索瞬间成了“多余的中间商”。本文用实测数据告诉你，向量延迟、精度天花板和成本是如何被原生长上下文碾压的——以及，在“模型即检索”的新范式里，开发者该如何重写知识库代码。当前，我们可以将AI项目分为三类：第一类是工作流AI，以Agent平台如Coze、Dify，外加AI表格、多维表格套装为主，着眼于公司体系的降本增效的AI体系；第二、三类都是AI知识库，一类是以单轮问答为主，不涉及意图识别及模型记忆、一类是以多轮问答为主，对数据及工程架构的要求较高，也是一般人根本接触不到的AI深水区了。而只要一提到AI知识库，大家第一时间就会想到一个孪生产物RAG，紧接着向量库也会映入各位眼帘，只不过这里从我这边实际实践的结果来说：RAG是需要的，而向量库或许不太需要，至少我实际看到在使用的公司并不多…至于原因，我们来做进一步讨论：RAG的必要性我第一次使用RAG技术是两年多之前，事实上当时我并不知道这是RAG，因为那时候市面上的文档是比较少的，我的眼里只有我的产品目标，需求很简单：在医疗问诊场景下，当患者已经确认疾病的情况下，给予的治疗建议不能直接使用大模型的，必须使用本地知识库的数据。这种实现起来也很简单，因为公司历史上就已经有比较完善的药品库，药品说明书里面有完整的适应症映射关系，所以我们只需要在最终给治疗方案的时候将数据放入提示词即可：你是一名专业的医疗顾问，必须严格根据提供的权威药品信息为患者提供建议。【患者确诊的疾病】{用户输入的疾病名称}【权威药品清单（必须严格遵守）】{从您知识库中检索到的相关药品信息，例如：– 药品A：用于治疗[疾病A]、[疾病B]。用法：一次一片，一日一次。禁忌：孕妇禁用。– 药品B：用于治疗[疾病A]、[疾病C]。用法：一次两粒，一日两次。禁忌：对本品过敏者禁用。}【你的任务】请基于且仅基于上方【权威药品清单】中的信息，为患者提供治疗建议。【你必须遵守的规则】1. **禁止编造**：绝不能推荐清单之外的任何药品，也绝不能添加清单中未提及的功效或副作用。2. **核心内容**：你的回答必须包含： – 推荐哪几种药（必须来自清单）。 – 简要的用法用量（必须来自清单）。 – 最重要的禁忌或警告（必须来自清单）。3. **安全兜底**：如果清单为空，你必须回答：“未在药品库中找到标准治疗方案，请立即咨询医生。”4. **最终建议**：在结尾必须加上：“以上信息仅供参考，用药前请咨询医生并仔细阅读说明书。”现在，请开始你的回答：大家可以清晰的看到，在上述场景中其实完全没有用到向量库的地方，唯一一个可能出问题的是：用户确诊的疾病跟这里的适应症映射不了，没办法查出来数据，也就是泛化能力不足，比如：“房颤” 和 “心房颤动”；“灰指甲” 和 “甲真菌病” 、“皮肤癣菌所致甲感染”；…这种东西要处理就有两种做法，直接扩展原有知识库，增加别名、类似名字段即可。不然的话也可以引入向量库来解决泛化问题。只不过别名的方案是稳定的，而向量库的策略是一种概率性匹配（相似度匹配）这自然会带来不确定性，他可能导致一些其他问题，比如过于泛化：“高血压”和“颅内高压”在通用语境下都包含“高压”这个概念，但在医学上是完全不同的疾病，这里如果搞错了会很麻烦…于是真实情况下，向量库的角色反而有些尴尬了，他似乎与RAG并不是绑定的关系？向量库的位置RAG技术其实未必会用到向量库，他的核心是检索 + 生成，而检索的方式可以多种多样：关键词检索：像传统搜索引擎一样使用BM25等算法；语义检索：使用向量库进行相似性搜索，这是当前的主流；混合检索：结合关键词和语义检索，取长补短；甚至基于知识图谱或规则的检索；毫无疑问，向量库和向量搜索技术正是搭乘RAG这辆快车，从相对小众的领域一跃成为AI基础设施的明星。它的出现解决了传统关键词检索无法理解语义的痛点，例如，搜索“苹果”应该同时返回“Apple Inc.”和“水果”的相关信息。只不过他实际成为“明星”可能与以下厂商脱不了关系：比如 Milvus（开源向量数据库）和 Zilliz Cloud（全托管云服务）。他们投入了大量资源进行市场教育（技术布道、文档、社区活动），极大地推动了向量数据库概念的普及，最后的结果是只要提到RAG就会附带向量库，只要深入向量库就不得提到Milvus。除此之外，腾讯云的VectorDB、阿里云的OpenSearch、华为云的GaussDB都集成了向量检索能力；国外市场更为多元，这里就不一一列举了，总而言之，我认为：RAG的需求催热了向量库，而向量库厂商们的激烈竞争和技术推广，又反过来让RAG的能力变得更强大、更易用，共同推动了这场AI应用开发的革命。只不过，RAG对于AI知识库确实必备，但向量库其实只是添头，多数时候用不到，那么问题也就来了：什么场景会用到向量库。向量库的场景当前就我看见使用向量库的场景多半都是团队有些懒的，他们不愿意做数据清洗，或者只愿意用AI进行简单的数据处理，比如：将大量非结构化文档（如技术文档、客服问答）丢进去，然后其期待有效信息自己就被检索出来了…这里的逻辑很简单：关键词检索容易遗漏语义相似但用词不同的内容，而向量检索能更好地解决这一问题。只不过真实情况如何呢？只能说：在绝大多数严肃的生产环境中，直接丢弃原始、未经清洗和结构化的文档，仅依赖向量库的语义检索，其效果往往令人失望，甚至是一场灾难。原因之前也说过，向量搜索返回的是最“语义相似”的文本块（chunks），而不是最“相关”或最“准确”的答案。一个查询可能返回十几个包含相关语义但上下文无关的文本片段，需要LLM费力地去甄别、筛选和总结，极大增加了幻觉风险。比如：查询“某产品的定价策略”，可能返回包含“定价”、“策略”词语的董事会纪要、市场报告、某员工的个人建议邮件等，而不是官方的、最新的定价文档。这些问题在最初你想要偷懒的时候就会存在，因为使用AI去清理数据，很容易导致文档被切割，重要信息不连贯。所以，向量库要用得好，想偷懒是不可能的，每次初筛后还需要各种策略去过滤，而因为要过滤就需要各种条件，那么在最初数据处理的时候就需要很多额外的标注，而如果已经在做标注了、做结构化了，那么就还不如不用向量库了…综上，我们开始回归，RAG的本质是确保答案来源于可信的知识源；向量库是高级工具，它用来解决RAG中“检索”环节的语义泛化问题，但在解决泛化问题时，同时也引入了不确定性，所以必须用其他技术（元数据、重排、混合搜索）来约束这种不确定性。而多数人以为的直接丢弃杂乱无章的原始文档，指望向量库和LLM创造奇迹，这属于愿望式编程，其结果必然是不稳定、不可靠的。也就是因为这些原因，事实上向量库用得并不好，很多团队事实上根本不用他、甚至用了的团队觉得麻烦也在逐渐抛弃。那么有没有什么替代技术呢，答案是肯定的，比如PageIndex：PageIndexPageIndex是一款基于推理的RAG系统，它模拟了人类专家通过树搜索在长文档中进行搜索和知识提取的过程，使大语言模型能够通过思考与推理定位到最相关的文档章节。其检索过程分为两个步骤：生成文档的目录树状结构索引；通过树搜索实现基于推理的检索；并且他是开源的，只不过当前知道的人还很少：点击跳转其核心理念是：检索并非一次性动作，而是一个由推理驱动的过程。他的工作SOP为：PageIndex OCR：把 PDF 转成保留层级结构的 markdown；生成树形索引（类似 ToC 的 JSON）；基于树搜索的检索（含 LLM-based 与 value-based 两种），返回相关节点、页码与完整检索轨迹，避免拍脑袋的 top-k；相对于向量库的RAG，这里是个逐渐缩小的逻辑，靠推理在树上逐层缩小范围，而不是相似度近邻，这里有点晦涩需要举个案例，以他的案例来说：本身的文档是很大的，他解析出来变成了这样：这样看起来依旧有些晦涩，我们再进一步，比如我手里有一份某公司《XXX 2024年 年度报告》，大概120页，他会经历以下流程：第一步，层级化PageIndex OCR 会把 PDF 识别成 LLM 友好的 Markdown，并尽量保留标题/小节/表格/列表等层级信息；可按页、按节点或拼接拿结果。比如这里的一个片段：# 7 经营情况讨论与分析（MD&A）## 7.2 收入与成本### 7.2.1 毛利及毛利率… 2024 财年，公司毛利率为 **38.4%**（见合并利润表注释 3）…第二步，建立树索引对 OCR 产物做“树生成”，形成轻量 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 年毛利率及同比变动，影响因素为产品结构与成本控制…” } ] } ]}树生成不需要向量库/不需要切块；每个节点附带页码与摘要，专为长文档（财报、法律/技术手册）优化而生。第三步，树搜索实际使用时，用户向 PageIndex 提交查询：“公司 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-based 与 value-based 两种树搜索；返回透明的节点轨迹、精准页码；不需要手调 top-k。当前 SDK 暂时仅支持单文档检索。最后，拼接把检索结果当作证据段送入回答模型，要求只基于证据作答并带引用，下面这种可溯源的方式，其实很受欢迎：系统：你是严谨的财报助手。只允许依据“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%。依据见年报“Gross Margin”小节与合并报表注释。证据页： 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并不直接使用用户的原始提问去检索，而是利用LLM强大的推理和理解能力，将用户的意图“翻译”成知识库更“听得懂”的语言，这增强了对多样化、模糊化用户提问的泛化能力。紧接着，是第二个问题：PageIndex检索到的内容就一定相关吗？如何处理不相关的内容？PageIndex的核心是循环流程。在“响应”阶段，解答器的一个重要任务是评估已检索到的信息是否相关且足以回答问题。如果解答器发现最新检索到的片段与问题无关，或者质量很差，它会“告诉”推理器：“刚才找的东西没用，我们需要换一个思路。”紧接着是第二个任务重排序，其实就是要通过结果去查询跟问题的相关性，如果不行还得再循环查询，直到完全满足条件…说时候挺好的，跟我们做数据工程的思路挺类似的，只不过嘛PageIndex有些费Token，成本更高…结语得益于模型基础能力的发展，尤其是上下文长度一块的扩展，历史上很多技术可能会逐渐退出历史舞台，比如与RAG几乎成绑定关系的向量库。当然，我也并不是要否定向量库存在的价值，只不过是想打破一种技术惯性思维，不要别人说要用什么，就真的以为技术路径就是那么回事，因为所有的失败都是试错成本，白花花的银子…向量库凭借其解决语义泛化的能力与厂商的强力推广成为市场热点，几乎成为与RAG绑定的技术，但这常常让我们忽略了最本质的问题：我们的知识究竟以何种形态存在？ 是高度结构化的数据库，还是杂乱无章的非结构化文档？不同的数据形态，理应匹配不同的检索方案。向量库是出色的工具，但它更像是一把“瑞士军刀”，擅长处理泛化的、非结构化的语义搜索，却未必是擅长“结构化数据”这块的处理。盲目选用，只会为系统引入不必要的复杂度。而像 PageIndex 这类推理即检索的新范式，其实也并不是什么新东西，在一年多之前我们做数据工程时候就已经在这样做了，所以他也不是什么革命性的产物。PageIndex核心点在于跳出了嵌入-匹配的框架，尝试用大模型本身的推理能力去模拟人类查阅文档的逻辑过程。它昭示着一个新趋势：未来的RAG系统，其智能性将不再仅仅依赖于生成环节的LLM，更将前置并深度融合到检索本身的推理过程中。最后，技术的选型是一场权衡。在向量库的概率性匹配与PageIndex的高成本推理之间，并无绝对的优劣，事实上我们两者都在用，用规则处理确定性的部分，用向量泛化模糊的需求，再用推理解决复杂的多步查询…还是那句话：实践出真知，只要是否适合你的，那就是好的，解决问题才是王道，用了什么不太重要。回归本源，RAG的核心使命从未改变：坚定不移地将答案锚定在最权威、最准确的知识源上，希望本文对大家有用本文由人人都是产品经理作者【叶小钗】，微信公众号：【叶小钗】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。题图来自Unsplash，基于 CC0 协议。