拆解 “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 通过向量搜刮 + 大模型总结即可实现。
  
• 但面临 “隐性事实推理”（如 “分析本季销售额暴跌是否与服务器宕机事件相关”），题目会触发复杂的认知链条：
  
  
  
  • 意图拆解：需识别 “销售额暴跌” 的时间范围、统计口径，“服务器宕机” 的事件定位
    
  • 多模态检索：同时查询财报文档（文本）、运维日志（时序数据）、客服工单（非结构化对话）
    
  • 关联推理：通过 ES|QL 盘算销售额与服务器可用性的时序相关性系数
    
  • 决定天生：结合企业风险管理手册天生应对方案
    
  
  

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

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

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

能力维度	技能实现	场景案例
多模态融合	原生支持文本/向量/数值/地理/日志等20+数据类型，支持嵌套文档和跨索引关联	在一次查询中同时分析产物手册（文本）、用户行为埋点（JSON）、服务器监控指标（时序数据）
认知盘算	ESQL 提供类自然语言的混合盘算能力（FROM logs | STATS avg=AVG(latency) BY region | EVAL risk=CASE(...)）	自动推导“季度营收异常”与“广告投放时段”的空间相关性
生态扩展	无缝集成 LogsDB（分析PB级日志）、MetricDB（实时指标聚合）、APM（应用性能数据）	安全分析场景： 1. 检索美国IP访问日志 2. 关联历史攻击特征库 3. 调用风险评分模型 4. 自动阻断高危IP

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

• 超越向量：带 Agents 的智能混合搜刮
  
• Agentic RAG 详解 - 从头开始​​构建你自己的智能体系统
  

真实 Agentic RAG 场景（更易明白的日常多任务题目）

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

---

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

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

• 核心需求提取：
  
  
  
  • 时间范围：3天
    
  • 预算限制：5000元（需拆分交通、住宿、门票、餐饮）
    
  • 必去景点：迪士尼、外滩夜景
    
  • 附加条件：餐厅避开高人流时段
    
  
  
• 天生结构化查询计划：
  

阶段二：多模态数据收割

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

数据类型	索引类型	检索计谋示例
景点信息	文本+向量	混合搜刮 ：迪士尼门票价格（关键词）+ "恰当家庭游玩"（语义向量）
交通路线	地理+时序	geo_shape  查询地铁线路 + date_histogram 分析早高峰拥堵时段
餐厅评价	嵌套文档	嵌套聚合：统计“列队时长”中位数 + 过滤“网红”标签（terms_exclude）
旅店价格	数值+文本	range  过滤价格区间 + match_phrase 匹配“免费接送迪士尼”

ES 多任务查询示例：

（也可以用 DSL 查询）

阶段三：动态决定天生

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

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

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

详细 ES 实现 Agentic RAG 的用例，可以参考下面的视频：
     Elastic AI 助手先容
  

总结

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

功能描述	Elasticsearch	大多数其他引擎
Full Text Search (全文搜刮)	✔（全文搜刮，文本匹配）	x
ANN Search (近似近来邻搜刮)	✔（HNSW，int8/4、BBQ 量化）	✔（ANN，基于向量的相似度）
kNN Search (k近邻搜刮)	✔（kNN暴力搜刮）	✔（ANN 向量检索）
Text Analysis (文本分析)	✔（内置文本分析器，分词器）	x
Semantic Search (语义搜刮)	✔（基于文本和希罕向量的语义搜刮）	?（基础支持，缺少复杂语义分析）
Querying (查询功能)	✔ 超过 30 种查询（查询DSL，支持复杂查询构造、多个匹配模式、嵌套查询、组合字段查询、含糊匹配、加权查询、高亮显示）	✔ 均匀3 种 （简单查询，支持根本运算）
Filtering (过滤功能)	✔（多种过滤方式）	✔（基于属性和向量过滤）
Aggregations (聚合分析)	✔ 超过 20 种聚合算子（聚合查询，数据统计）	x
Range Search (范围查询)	✔（范围查询）	✔（支持向量范围查询）
Sorting (排序)	✔（排序功能）	?
Retrieval Augmented Generation (RAG)	✔（支持RAG，检索加强天生）	x
Reranking (重排名)	✔（基于语义和统计的重排序）	x
Search with Synonyms (同义词搜刮)	✔（同义词支持）	x
Query Templates (查询模板)	✔（支持查询模板）	x
SQL-like Queries (SQL查询)	✔（支持ESQL和SQL查询）	x
Cross-cluster Search (跨集群搜刮)	✔（支持跨集群搜刮）	x
Geospatial Analysis (地理空间分析)	✔（地理空间查询和聚合）	x
Retrieving Selected Fields (字段选择)	✔（指定字段检索）	✔（返回指定向量）
Search Analytics (搜刮分析)	✔（搜刮统计与分析）	x
Scripting (脚本支持)	✔（支持自界说脚本）	x

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。