2026年初，业内开始流行一个叫“PageIndex”的概念，主打“Vectorless, Reasoning First”。这听起来像是在否定向量数据库的地位，但真相更务实：向量数据库依然是RAG（检索增强生成）的关键底座，但它绝不是唯一的关键。在那些真正跑通了的生产系统中，决定效果的不是你换了一个更强的向量库，而是你是否把检索链路的设计对了。
很多团队还在陷入一种误区：认为只要把文档切片扔进Milvus或Pinecone，再配上一个Embedding模型，就能解决大模型的幻觉问题。事实上，只要是大模型从业者，开口闭口都是RAG，因为它是解决LLM“金鱼记忆”和“一本正经胡说八道”的标准配置[53AI]。但这种配置在2026年的企业场景里，往往显得捉襟见肘。
向量检索的硬伤：语义相近，意图相悖
向量检索擅长处理“语义相似度”，比如用户搜“苹果”，它能找到关于水果或科技公司的相关段落。但在企业知识库中，这种模糊性往往是灾难性的。当用户询问“Q3财报中未包含的项目”时，向量库很难直接定位到“否定”或“排除”的逻辑，它更倾向于召回包含“Q3财报”的高分片段，哪怕这些片段恰恰是用户想排除的内容。
这就是为什么BM25算法在2026年并没有死，反而在混合检索（Hybrid Search）中重新成为标配。BM25基于关键词匹配，对专有名词、编号、特定代码段的召回准确率远高于向量模型。一个成熟的企业级RAG系统，通常是向量检索与BM25加权融合的结果。据新华三在《数字化领航》AI应用专刊中的实践总结，政企场景对准确性的要求极高，单一的向量检索无法提供足够的可追溯性和精确度，必须通过多路召回和重排序（Rerank）来弥补[3]。
Graph RAG：从“找文档”到“找关系”
如果说BM25解决了精确匹配的问题，那么Graph RAG（基于知识图谱的RAG）则试图解决复杂推理的问题。向量库里的文档切片是孤立的碎片，而知识图谱能将碎片串联起来。例如，在医疗或法律领域，用户的问题可能涉及多个实体间的复杂关系：“张三和李四在2024年签署的合同，依据哪条法规被判无效？”
在这种场景下，简单的向量检索很难跨越多个文档切片找到答案。Graph RAG通过构建实体关系网络，能够沿着边进行遍历，直接定位到相关的法律条款和合同细节。当然，正如我们在《Graph RAG进知识库，别先急着建大图》中所分析的，图谱清洗、查询开销和证据链展示是企业级落地的真实痛点[11]。但在处理高度结构化、关系紧密的数据时，Graph RAG的优势是向量库无法替代的。
被忽视的最后一道防线：权限与过滤
无论检索链路多么花哨，如果返回的结果包含了不该看到的信息，整个系统就是失败的。2026年的RAG系统，权限过滤（Permission Filtering）不再是事后补救，而是前置条件。
在企业环境中，数据往往带有复杂的属性标签：部门、职级、密级、时间范围等。如果在检索阶段不进行严格的元数据过滤，向量模型可能会“幻觉”出一个看似合理但属于其他部门的数据。IBM指出，RAG矢量数据库结合了AI与高级搜索技术，使LLM能够实时检索相关信息[4]。这里的“高级搜索”不仅指语义搜索，更包括基于属性的结构化过滤。一个健壮的RAG链路，必须在Embedding之前或之后，通过元数据过滤器将无关数据屏蔽，确保只有具备相应权限的数据才能进入候选集。
2026年的RAG 3.0：工程大于算法
我们不妨看看其他领域的进展。在《B200与昇腾910C，账要算到集群层》中提到，算力的取舍不能只看单卡参数，还要考虑迁移、调优和运维成本[3]。RAG系统的优化也是如此。与其不断更换更强的向量模型，不如优化整个检索链路的工程细节：
- 混合检索策略：结合向量语义搜索和BM25关键词搜索，利用Rerank模型进行二次精排。
- 动态切片：根据文档类型（如表格、代码、长文本）采用不同的切片策略，避免信息割裂。
- 知识图谱辅助：对于高关系密度的领域，引入轻量级Graph RAG，提升多跳推理能力。
- 严格的权限控制：在检索源头嵌入元数据过滤，确保数据安全。
正如《RPA接上Agent，先别急着全自动》中所述，最稳的做法不是端到端放手，而是让不同组件各司其职[7]。RAG也是如此，向量库负责语义广度，BM25负责精确深度，图谱负责关系推理，权限过滤负责安全边界。只有把这些环节设计好，RAG才能真正从“玩具”变成“工具”。
别再迷信向量数据库能解决一切问题。在2026年，RAG的竞争焦点已经从单一的模型能力，转向了对检索链路整体设计的把控。谁能把BM25、图谱和权限过滤有机地整合在一起，谁才能在企业级应用中真正站稳脚跟。
