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

最近，某厂商发了一堆公关文章，翻来覆去地炒作 “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. 1. 意图拆解：需识别“销售额暴跌”的时间范围、统计口径，“服务器宕机”的事件定位
  2. 2. 多模态检索：同时查询财报文档（文本）、运维日志（时序数据）、客服工单（非结构化对话）
  3. 3. 关联推理：通过 ES|QL 计算销售额与服务器可用性的时序相关性系数
  4. 4. 决策生成：结合企业风险管理手册生成应对方案

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

• • ChatBI：用自然语言完成多维分析（“对比华北/华南区域在故障期间的订单流失率”）
• • ChatETL：动态构建数据管道（“提取过去三个月所有提及‘延迟’的客服录音，按情绪值排序”）
• • 认知闭环：检索结果实时反馈至监控系统，触发自动化预案

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

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

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

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

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

1. 核心需求提取：

• • 时间范围：3天
• • 预算限制：5000元（需拆分交通、住宿、门票、餐饮）
• • 必去景点：迪士尼、外滩夜景
• • 附加条件：餐厅避开高人流时段

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

"agent_plan": {
  "tasks": [
    {"type": "景点门票查询", "keywords": ["上海迪士尼票价", "外滩观景台开放时间"]},
    {"type": "交通分析", "params": {"出发地": "用户定位", "目的地": "迪士尼+外滩"}},
    {"type": "餐厅推荐", "filters": ["评价>4分", "人均<200元", "排队时长<30分钟"]},
    {"type": "动态预算分配", "constraints": "总费用≤5000元"}
  ]
}

阶段二：多模态数据收割

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

ES 多任务查询示例：

// 景点与交通联动查询
FROM attractions  
| WHERE name == "迪士尼" OR name == "外滩"  
| STATS 
    avg_price = AVG(ticket_price),
    nearby_transport = COUNT(transport_hubs) 

// 实时餐厅动态过滤（每15分钟更新）
FROM restaurants  
| WHERE city: == "上海" 
    AND cuisine_type IN ("本帮菜", "西餐") 
    AND average_cost <= 200 
| EVAL crowd_risk = CASE(
    (current_time > "18:00" AND predicted_wait_time > 40),  "high", 
    "low"
  )  
| WHERE crowd_risk = "low"
| SORT rating DESC

（也可以用 DSL 查询）

阶段三：动态决策生成

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

**上海三日游方案**
1. **Day 1**  
   - 上午：迪士尼（门票 599元，地铁直达避开早高峰）  
   - 午餐：弄堂老馆子（人均80元，当前排队12分钟）  
   - 晚上：外滩游船（夜景观光票 220元，21:00场次余票充足）  

2. **Day 2**  
   - 上午：武康路历史街区（免费，8:00-10:00人流低谷）  
   - 午餐：静安寺素斋（人均150元，需提前1小时预约）  
   - 下午：豫园+城隍庙（联票 60元）  

3. **Day 3**  
   - 全天：朱家角古镇（地铁+公交 35元，特色餐厅人均70元）  

**费用实时监控**：  
- 当前总预算：4995元（剩余5元可用于应急）  
- 动态告警：若迪士尼排队超90分钟，自动触发备选方案（东方明珠观光）  

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

• • 传统方案：需串联旅游平台API+地图服务+餐饮点评数据库+Excel手动计算
• • ES 方案：单引擎完成语义理解→多点查询→动态计算，响应时间从分钟级压缩到秒级
• • 杀手锏功能：实现完整业务闭环，甚至是可视化图表，都可以通过 Kibana 零代码配置完成

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

总结

综上所述，无论是传统RAG场景，还是代表未来趋势的Agentic RAG场景，Elasticsearch凭借其丰富的功能、强大的处理能力以及完整的闭环体系，都将是技术选型时不容忽视的择优选项。那些宣扬“ES已死”的言论，纯粹就是瞎扯。其实开源社区真没必要天天想着怎么攻击别人，也别总想着用一些歪门邪道去误导用户。真想让这个行业进步，应该是一起把蛋糕做大，让更多的使用场景从传统的文本检索上进行迁移。 我真心希望以后能看到更多厉害的技术突破，大家一起把 AI search 技术往前推，给用户带来更方便、更智能的搜索和问答体验，也帮企业多赚点钱。技术这东西，本来就是要服务社会的，让咱们的生活和工作变得更好。

附录

引用链接

[1] 附录对比: ##附录 [2] 业界第一个稀疏向量的词扩展模型ELSER: https://cloud.tencent.com/developer/article/2303829