为什么 Elasticsearch 平台是你的 AI 技术栈中缺失的一环
TL;DR · AI 摘要
企业AI开发的难点在于数据基础设施而非模型本身。Elasticsearch通过整合情景、语义、程序和工作流四种记忆类型，替代了Redis、Pinecone等独立系统，成为统一的后端引擎，显著降低了运维复杂度。
核心要点
- ElasticGPT和AgentEngine仅用Elasticsearch替代了Redis、Pinecone、Postgres等四个独立系统。
- 生产级AI系统需具备跨会话记忆、混合检索、工作流恢复和自学习能力。
- 统一平台利用ILM管理会话数据生命周期，无需编写手动保留脚本。
结构提纲
按章节快速跳转。
模型开发相对容易，真正的难点在于构建记忆、检索和状态管理等数据基础设施。
ElasticGPT和AgentEngine通过单一引擎处理所有数据需求，避免了多系统集成的复杂性。
架构包含情景记忆、语义记忆、程序记忆和工作流状态，分别对应不同的数据存储需求。
- ›情景记忆
利用ILM自动管理会话历史，实现热数据存储与冷数据压缩，替代Redis。
- ›语义记忆
通过本地嵌入合并相关事实，积累长期知识，替代专用向量数据库。
- ›程序记忆
记录工具使用成功率，形成学习循环，替代传统分析日志系统。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- Elasticsearch AI Stack
- 核心挑战
- 数据基础设施复杂性
- 统一解决方案
- 情景记忆 (ILM)
- 语义记忆 (向量)
- 程序记忆 (学习)
- 工作流状态 (快照)
金句 / Highlights
值得收藏与分享的关键句。
模型是容易的部分，难的部分在于围绕它的一切——记忆、检索、状态管理。
这意味着要操作四个系统，调试四种故障模式，管理四份供应商合同。
AgentEngine 的后端建立在 Elasticsearch 平台之上，具有四种独特的记忆功能。
最近的轮次存储在快速存储中，30天后压缩，90天后自动删除——无需定时任务。
为什么 Elasticsearch 平台是你 AI 技术栈中缺失的关键拼图
企业级 AI 有一个鲜为人知的秘密：模型是最简单的部分。困难的部分在于围绕它的一切——记忆、检索、状态管理，以及将 聊天机器人 转变为人们在工作中真正依赖的工具所需的连接纽带。
大多数团队通过拼凑一个用于嵌入的 向量数据库、一个用于上下文的文档存储、一个用于会话的缓存层，以及可能还有一个用于遥测的时序数据库来解决这个问题。这意味着要运维四个系统、调试四种故障模式、管理四份供应商合同，以及处理四个可能导致数据无声丢失或过时的集成接口。
Elastic 团队现在已经发布了两个使用 Elasticsearch Platform 作为唯一数据后端的 AI 系统：ElasticGPT（一个拥有 2,000+ 用户、125,000+ 次聊天和 400,000+ 次交互的内部聊天机器人）和 AgentEngine（一个 API 驱动的自主代理框架）。我们在技术栈上下的注每次都是一样的：用一个引擎来处理记忆、检索和状态。不需要 Redis。不需要 Pinecone。不需要 Postgres sidecar。只需要 Elasticsearch Platform。
问题所在：AI 记忆比 AI 推理更难
当团队构建 ElasticGPT 时，模型选择大约花了一周时间。而检索架构则花了几个月。当我们后来构建 AgentEngine 时，同样的模式依然存在：难题都在数据基础设施上。
原因如下。一个生产级 AI 系统需要：
- 跨会话记住上下文： 回忆几周前的相关历史，而不仅仅是最近 10 条消息。
- 智能搜索自身知识： 匹配错误代码和工具名称等精确术语，检索语义上相似的概念，并合并这两个结果集，而不让其中一个淹没另一个。
- 恢复中断的工作流： 在用户中途合上笔记本电脑稍后返回时，准确地从上次离开的地方继续。
- 从自身行为中学习： 追踪哪些工具链对特定任务类型有效，并随时间推移进行改进。
这些不是模型问题，而是数据基础设施问题。它们直接对应 Elasticsearch Platform 多年来发布的功能，只是应用到了一个新的用例上。
架构：4 种记忆类型，1 个引擎
AgentEngine 的后端构建在 Elasticsearch Platform 之上，具有四种独特的记忆功能。每一种传统上都需要一个独立的系统。
- 情景记忆： 以数据流形式存储的会话范围对话历史，并带有索引生命周期管理 (ILM)。最近的轮次存储在快速存储中，30 天后压缩，90 天后自动删除——无需 cron 作业和手动保留脚本。这取代了像 Redis 这样的会话存储。
- 语义记忆： 从对话中提取和蒸馏的长期事实，每条都按重要性评分。代理随时间积累知识，后台合并过程使用本地嵌入合并相关事实。这取代了专用的向量数据库。
- 程序记忆： 关于代理使用了哪些工具、针对什么任务类型、是否成功以及任何更正说明的记录。这为代理提供了一个学习循环；下次面对类似任务时，它会回忆起什么有效。这取代了具有结构化查询功能的分析或日志系统。
- 工作流状态： 来自 PydanticAI 图形 API 的序列化执行快照。当代理到达检查点时，完整的图形状态会持久化到 Elasticsearch。用户断开连接并重新连接；代理从确切的步骤恢复。这取代了像 Postgres 或 DynamoDB 这样的状态后端。
为什么一个统一平台行之有效
将搜索和 AI 数据整合到一个单一平台中是一个战略优势，可以降低总拥有成本 (TCO) 并加速上市时间。
消除基础设施开销
在传统设置中，为公司数据准备 AI 需要复杂、脆弱的管道和独立的数据库，仅仅是为了将文本转换为 AI 可以理解的格式。统一的平台消除了这种技术债务。它自动处理转换——你的团队只需输入标准文本，平台会原生地为其准备 AI 处理。没有外部管道需要管理，也没有断开连接的系统之间不断的同步。
开箱即用的更智能检索
当用户或 AI 代理查找信息时，访问模式本质上是混合的。有时你需要精确关键词匹配的精确度（“查找项目 X 的第三季度预算报告”），有时你需要概念理解（“我们常见的数据管道故障是什么？”）。
在大多数情况下，你需要两者兼备。统一平台无缝地将传统关键词搜索与现代 AI 的上下文理解结合起来。它在后台智能地权衡并融合这些结果，确保您的 AI 应用程序始终提供准确、相关的答案，而无需工程师不断手动调优搜索算法。
运维层面的变化
关于整合的讨论，不仅仅是为了每月在基础设施上节省几千美元——尽管这也是实实在在的收益。更重要的是关于运维覆盖面。
AI 技术栈中的每一个系统都需要监控、告警、安全审查、备份/恢复程序、升级周期，以及至少一个深入了解它的人。四个系统意味着四倍的所有这些工作，加上它们之间的集成层。
当 AgentEngine 出现内存问题时，我们只需要关注一个系统。一套索引。一种查询语言。一个安全模型。一个了解其工作原理的团队。在凌晨 3 点出现故障时，这就是 15 分钟解决问题和多团队事故之间的区别。
作为背景参考，我们管理着每年 130 万美元的云支出，涉及三家云服务提供商。我们能从技术栈中消除的每一个系统，不仅降低了成本，还减轻了工程团队的认知负担。
混合搜索的优势
我交谈过的大多数正在评估向量数据库的团队都在解决错误的问题。他们在问“我们应该使用哪个向量数据库来存储嵌入？”，而真正的问题是“我们真的需要一个独立的向量数据库吗？”
关键词搜索会遗漏上下文（例如，无法将“ETL 崩溃”与“管道故障”联系起来），而纯 AI 搜索经常会遗漏产品代码等确切的关键细节。统一平台同时运行这两种搜索。它会自动权衡并呈现最相关、最新的信息，以便您的 AI 始终拥有正确的上下文。
不间断的业务连续性
分散的系统是脆弱的；如果外部 AI 管道发生故障，您的应用程序就会崩溃。整合的平台通过内置的弹性防止这种情况发生。如果 AI 模型暂时降级，系统会立即回退到标准搜索。您的应用程序保持在线，您的工作流也不会受阻。
这对您的 AI 技术栈意味着什么
如果您的组织已经在使用 Elasticsearch 平台——许多科技公司这样做是为了日志记录、可观测性或产品搜索——您可能正拥有一个 AI 就绪的平台而不自知。处理应用程序日志的同一个集群，通过正确的索引设计和推理端点，可以作为代理 AI 系统的记忆骨干。
推出 AI 最快的公司不会是那些拥有最复杂模型管道的公司。而是那些拥有最简单、最可靠的数据基础设施作为底座的公司。
查看我们如何努力成为 AI 优先的企业（在我们的内部手册中）。
_本文中描述的任何功能或特性的发布和时间安排均由 Elastic 全权决定。目前不可用的任何功能或特性可能无法按时交付或根本无法交付。_
_在这篇博文中，我们可能使用或提到了第三方生成式 AI 工具，这些工具由其各自的所有者拥有和运营。Elastic 无法控制第三方工具，我们对其内容、运营或使用不承担任何责任或义务，也不对您使用此类工具可能产生的任何损失或损害承担责任。在使用涉及个人、敏感或机密信息的 AI 工具时，请务必谨慎。您提交的任何数据都可能被用于 AI 训练或其他目的。无法保证您提供的信息将得到安全或机密的保存。在使用任何生成式 AI 工具之前，您应熟悉其隐私惯例和使用条款。_
_Elastic、Elasticsearch 及相关标志是 elasticsearch B.V. 在美国和其他国家的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。_