拆解 “ES 已死“ 伪命题：Agentic RAG 时代搜索引擎的终极形态

作者：来自 Elastic 李捷

xxx：“ES已死，#¥%@#¥……¥”
我：？？？

最近，某厂商发了一堆公关文章，翻来覆去地炒作 “ES 已死”，“放弃 ES”。这哪是什么正经的技术文章，说白了就是一场算计好的认知陷阱，妥妥的恶意误导。除了把用户带偏，对开源社区来说，有点开创了社区恶意流的先河，吃相难看。咱也犯不着在这没意义的事儿上浪费时间争论，咱直接聚焦到关键问题上：现在 Agentic RAG 都在重塑人机交互模式了，那下一代智能引擎的理想标准到底是啥样？

观点直接抛出，在如今 AI 搜索，也就是 RAG 应用的时代，Elasticsearch 绝对是首选之一。为啥这么说呢？下面这几个原因，我觉得特别关键 。

• 查询手段丰富：集全文、稀疏向量、密集向量检索于一体，配备丰富查询 DSL。附录对比 [1]
• 语义处理强大：具备文本分析、实体提取等丰富语义理解和数据处理功能，契合 RAG 应用需求。
• 大模型对齐：互联网广泛存在的 ES 训练知识，使得大模型的均能写出高效准确的 ES 查询和聚合语句
• RAG 闭环完整：涵盖索引、检索等业务闭环，以及集成、测试等产研闭环。

而如果我们真正关注 RAG 的实际应用场景和业务痛点，那么 Agentic RAG 必然是 RAG 的发展趋势。传统 RAG 已无法满足用户期望，局限性显著。在许多所谓的 RAG 教程中，例子多是解决简单查询问题，再让大模型总结，比如 “鲁迅说没说”。其局限在于，文档片段中必须有答案。但当问题复杂些，如 “公司本年度财报中，营收最优的一个季度和最差一个季度的数据有哪些不同？” 即便数据库中有该公司所有季度财务报告，向量库也难以提取相关信息（因为最优和最差是计算和排序的结果，并非简单查询可得）。抽象来讲，这种局限性大概就是 Search 和 Query 的区别。搜索（search）更多是检索过程，只能从知识库中找相关片段作为上下文生成内容；而 Query 更多是提问过程，回答问题需要理解问题意图，拆分任务，不仅要检索，还需计算、推理。因此，在 Agentic RAG 的架构中，我们需要的是像 ES 这样强大的集检索、计算与处理于一体的工具集引擎，而非简单的向量数据库。

因此，本文将分别从传统 RAG 和 Agentic RAG 两个场景探讨，为何 ES 仍是你最优先的选择之一。

现在 ES 适合于传统 RAG 吗？

首先一个问题，现在 ES 适合于传统 RAG 吗？

答案是肯定的。大多数反对声音往往带有故意的误导、偏见，甚至恶意。

这种误导极为隐性。比如过分强调单次运算的延迟。实际上，RAG 是精细活，多数需要部署 RAG 应用的场景，无论是问答系统、客服聊天机器人，还是语义化的文档检索，都需要理解查询语境和意图。真正的核心指标是准确理解查询意图，找出最相关的上下文信息，再由大模型给出最合适的回答。

由于 token 生成速度限制，一次问答通常需几秒，甚至十几秒钟。这一延迟在大多数应用场景中是可接受的。相较于最终整体效果的优化，纠结过程中向量查询是 20ms 还是 5ms 的延迟毫无意义。同理，写入吞吐和单机成本方面，ES 一个节点通常能承载 2 - 4TB 的数据量，而在传统 RAG 场景中，知识库规模具有显著的长尾特征 —— 80%的企业知识库小于 1TB。

因此，向量查询引擎的单机成本和写入吞吐并非构建 RAG 系统的瓶颈，也不是需重点考量的指标。更不用说，最新版的 ES 提供了最先进的 HNSW 索引，以及目前业内唯一 BBQ 量化，BBQ（Better Binary Quantization） 是 Lucene 和 Elasticsearch 在向量量化方面的一次飞跃，它将 float32 维度缩减为位，在保持高排名质量的同时，内存使用量减少了约 95%。BBQ 在索引速度（量化时间缩短 20-30 倍）、查询速度（查询速度提高 2-5 倍）方面均优于产品量化 (PQ) 等传统方法，同时准确度没有额外损失，已大幅降低了 ES 向量查询对计算资源的消耗。

那可能有人要问，如果要构建一个 RAG 系统，在选择知识库检索引擎时，应主要从哪些方面考虑？核心指标当然是从最终用户的需求反推。有没有效果（即找出来的知识片段是否准确，提供给大模型的上下文是否是最相关的片段）是第一体验，大体可从以下几个方面考虑：

• 增强对用户意图的理解：目前普遍通过更多处理（而不仅是密集向量的 embedding）来理解用户意图，包括但不限于：查询重写、拼写校正、关键词提取、查询扩展和放宽、查询解析、查询管道化、实体提取和词性标注。多数引擎只能提供部分基础能力，如向量转换和基础分词，而 ES 提供了全部能力。我们可通过 ES 上各种定制化分词器、部署的 NLP 小模型，以及通过推理接口对接的大模型来实现这些处理。或许有人会问，对于 query 的处理，大部分逻辑可放在检索引擎之外，由其他模块实现。这点不反对，虽增加了系统复杂性和成本（一个具备同等能力的多系统拼接方案，其隐性成本（数据一致性维护、多团队协作开销）往往是直接成本的 3-5 倍），但也提升了灵活性。然而，目前观察到理解用户意图最有效的做法（不一定成本最优）是通过大模型做前置的用户意图理解，即通过大模型进行查询转换或者查询重写。此时，ES 的核心优势尽显，因为 ES 丰富的文档和大量的社区资源已作为训练知识对齐到大模型当中，使得 LLM 无需 fine tuning 就能将理解后的用户意图翻译为准确的、可用的 ES DSL 语句；其次，意图理解后的查询拆分可能很复杂，而 DSL 提供了功能丰富且强大的混合查询，甚至聚合计算选项，使得 ES 最能匹配复杂的查询场景乃至计算场景。因此，ES 是 Query Transformation & Expansion 的最优选择。

• 增强对知识库数据的整理，使其更符合 RAG 的应用场景：这不是简单的 embedding，而是需要对知识库数据进行更深层次的处理，包括但不限于:

  • 知识库的结构化（如 chunking）

  • 知识库的语义化 (分词，稀疏向量转化，密集向量转化)

  • 知识库的关联化（meta 数据丰富）

  • 知识库的扩展化（如大模型的总结）

  • 知识库的实体化

  • 知识库的标准化。

这些处理通常需要大量的 ETL 工作以及完善的知识库引擎才能承载。实际上ES提供了包括 NLP 处理在内的丰富的数据处理功能，自然也能满足这种场景的数据存储和治理需求。

这里有几个功能分享给大家：

• ES 提供了一个新的 semantic_text 字段类型，会对该字段的数据进行自动 chunk 和 embedding；

• ES 支持 nested vector search，以更好地适应返回整个文档的检索需求，而非仅返回 chunk 的片段；

• ES 领先其他厂商十几个月，在 2023 年就提供了业界第一个稀疏向量的词扩展模型 ELSER [2] ，使用 Elastic 的 ELSER 与 BM25 相结合的混合搜索优于SPLADE、ColBERT 和 OpenAI 提供的高端嵌入模型，并且即将支持多语言。

• ES 提供的推理 processor，可在数据写入过程中，通过绑定对应 processor 的 ingest pipeline 对数据进行处理，如实体提取、关键词提取、实体标注、词性标注等等。这些处理可在数据写入时完成，减少查询时的处理时间。

• 查询和排名优化：这是 ES 的强项，ES 提供了：

  • 最丰富的查询 DSL；

  • 统一数据结构内的混合查询选项；

  • 并且提供了大多数模型所不具备的多个 Rerank 选项，帮助优化大模型上下文的相关性：

    • 基于排名的多路融合的 RRF；

    • 基于大模型语义理解的 semantic rerank；

    • 基于用户反馈统计的 LTR rerank。

我们在此不一一赘述 ES 的功能，但如果你希望武器库里有更多选择（无论选择全文检索、向量搜索还是混合搜索），那么 ES 仍然是你最优先的选择。

Agentic RAG 需要一个什么样的引擎？

从上述分析不难看出，要突破传统 RAG 的局限，我们需要的是一个具备认知能力的智能引擎，而非简单的检索工具。这种引擎需要支持 “隐性意图理解” 甚至 “推理意图拆解”，而不仅仅是显性的关键词匹配。

• 若需求停留在 “直接检索显性事实”（如从产品文档中查找 “设备重置按钮位置”），传统 RAG 通过向量搜索 + 大模型总结即可实现。

• 但面对 “隐性事实推理”（如 “分析本季销售额暴跌是否与服务器宕机事件相关”），问题会触发复杂的认知链条：

  1. 意图拆解：需识别 “销售额暴跌” 的时间范围、统计口径，“服务器宕机” 的事件定位

  2. 多模态检索：同时查询财报文档（文本）、运维日志（时序数据）、客服工单（非结构化对话）

  3. 关联推理：通过 ES|QL 计算销售额与服务器可用性的时序相关性系数

  4. 决策生成：结合企业风险管理手册生成应对方案

这正是 Agentic RAG 的革命性之处——它将传统 RAG 进化为 “认知增强框架”，融合了：

• ChatBI：用自然语言完成多维分析（“对比华北/华南区域在故障期间的订单流失率”）

• ChatETL：动态构建数据管道（“提取过去三个月所有提及 ‘延迟’ 的客服录音，按情绪值排序”）

• 认知闭环：检索结果实时反馈至监控系统，触发自动化预案

而 Elasticsearch 之所以能成为 Agentic RAG 的终极引擎，关键在于其 “三位一体” 架构：

有关 Agentic RAG 的更多阅读，请参阅：

• 超越向量：带 Agents 的智能混合搜索

• Agentic RAG 详解 - 从头开始​​构建你自己的智能体系统

真实 Agentic RAG 场景（更易理解的日常多任务问题）

用户提问：
“帮我规划一个上海三日游，预算 5000元，要包含迪士尼、外滩夜景，还要避开人多的网红餐厅。”

阶段一：意图解析与任务拆解

LLM 将原始查询拆解为以下可执行任务：

1. 核心需求提取：

   • 时间范围：3天

   • 预算限制：5000元（需拆分交通、住宿、门票、餐饮）

   • 必去景点：迪士尼、外滩夜景

   • 附加条件：餐厅避开高人流时段

2. 生成结构化查询计划：

阶段二：多模态数据收割

ES 同步检索以下数据源，无需跨系统跳转：

ES 多任务查询示例：

（也可以用 DSL 查询）

阶段三：动态决策生成

LLM 根据 ES 多种任务的查询与计算结果，自动输出结构化方案并实时验证预算：

为什么选择 ES 而非传统方案？

• 传统方案：需串联旅游平台 API + 地图服务 + 餐饮点评数据库 + Excel 手动计算

• ES 方案：单引擎完成语义理解 → 多点查询 → 动态计算，响应时间从分钟级压缩到秒级

• 杀手锏功能：实现完整业务闭环，甚至是可视化图表，都可以通过 Kibana 零代码配置完成

具体 ES 实现 Agentic RAG 的用例，可以参考下面的视频：

总结

综上所述，无论是传统 RAG 场景，还是代表未来趋势的 Agentic RAG 场景，Elasticsearch 凭借其丰富的功能、强大的处理能力以及完整的闭环体系，都将是技术选型时不容忽视的择优选项。那些宣扬 “ES已死” 的言论，纯粹就是瞎扯。其实开源社区真没必要天天想着怎么攻击别人，也别总想着用一些歪门邪道去误导用户。真想让这个行业进步，应该是一起把蛋糕做大，让更多的使用场景从传统的文本检索上进行迁移。

我真心希望以后能看到更多厉害的技术突破，大家一起把 AI Search 技术往前推，给用户带来更方便、更智能的搜索和问答体验，也帮企业多赚点钱。技术这东西，本来就是要服务社会的，让咱们的生活和工作变得更好。

附录