作者来自 Elastic Matthew Skinner企业 AI 有一个不为人知的秘密模型是最容易的部分。真正困难的是围绕模型的一切——记忆、检索、状态管理以及将一个 聊天机器人 转变为人们在工作中真正依赖的系统所需的连接层。大多数团队通过拼接多个组件来解决这个问题使用一个 向量数据库 存储 embedding使用文档存储保存上下文使用缓存层管理会话也许还需要一个时间序列数据库保存遥测数据。这意味着需要运营四个系统调试四类故障管理四份供应商合同以及维护四个数据连接点而这些连接点可能导致数据悄悄丢失或过期。Elastic 团队目前已经交付了两个使用 Elasticsearch Platform 作为唯一数据后端的 AI 系统ElasticGPT一个拥有 2,000 多名用户、125,000 多次聊天和 400,000 多次交互的内部聊天机器人以及 AgentEngine一个由 API 驱动的自主 agent 框架。我们每次对技术栈做出的选择都是相同的使用一个引擎处理记忆、检索和状态。不需要 Redis。不需要 Pinecone。不需要 Postgres 辅助服务。只有 Elasticsearch Platform。问题AI 记忆比 AI 推理更困难当团队构建 ElasticGPT 时模型选择大约花费了一周时间。而检索架构花费了数月时间。之后当我们构建 AgentEngine 时同样的模式再次出现困难的问题全部集中在数据基础设施上。原因如下。一个生产级 AI 系统需要跨会话记住上下文回忆几周前的相关历史而不仅仅是最近 10 条消息。智能搜索自身知识匹配错误代码和工具名称等精确术语发现语义相似的概念并合并两类结果同时避免其中一类结果淹没另一类。恢复中断的工作流用户在任务中途关闭笔记本电脑之后再次回来时能够准确从离开的地方继续执行。从自身行为中学习追踪哪些工具链适用于特定任务类型并随着时间推移不断改进。这些并不是模型问题它们是数据基础设施问题。而且它们直接对应 Elasticsearch Platform 多年来已经提供的能力只是现在被应用到了新的使用场景中。架构4 种记忆类型1 个引擎AgentEngine 的后端构建在 Elasticsearch Platform 之上提供四种不同的记忆功能。传统上每一种功能都需要一个独立的系统。情景记忆Episodic memory使用数据流存储的、以会话范围为单位的对话历史并通过索引生命周期管理ILM进行管理。最近的对话轮次存储在高速存储中30 天后进行压缩90 天后自动删除 —— 不需要 cron 任务也不需要手动编写保留策略脚本。这替代了类似 Redis 的会话存储。语义记忆Semantic memory从多个对话中提取并提炼长期事实并为每个事实评估重要性。agent 会随着时间积累知识后台整合过程使用本地 embedding 合并相关事实。这替代了专用向量数据库。程序记忆Procedural memory记录 agent 使用了哪些工具、用于什么任务类型、是否成功以及任何修正说明。这为 agent 提供了学习循环当下次面对类似任务时它可以回忆哪些方法有效。这替代了需要结构化查询的分析或日志系统。工作流状态Workflow state来自 PydanticAI 图 API 的序列化执行快照。当 agent 到达检查点时完整的图状态会持久化到 Elasticsearch。用户断开连接后重新连接agent 可以从准确的步骤继续执行。这替代了类似 Postgres 或 DynamoDB 的状态后端。为什么一个统一平台能够发挥作用将搜索和 AI 数据整合到单一平台中是一种战略优势可以降低总体拥有成本total cost of ownership - TCO并加快产品上市速度。消除基础设施开销在传统架构中为 AI 准备企业数据需要复杂且脆弱的数据管道以及多个独立数据库仅仅为了将文本转换为 AI 可以理解的格式。统一平台消除了这种技术债务。它会自动处理转换过程 —— 你的团队只需要输入标准文本平台就会原生地为 AI 做好准备。不需要管理外部数据管道也不需要在相互隔离的系统之间持续同步数据。开箱即用的更智能检索当用户或 AI agent 查找信息时访问模式本质上是混合的。有时你需要精确关键词匹配的准确性“查找 Project X 的第三季度预算报告”有时你需要概念理解能力“我们常见的数据管道故障有哪些”。大多数情况下你两者都需要。统一平台能够无缝结合传统关键词搜索和现代 AI 的上下文理解能力。它会在后台智能地对这些结果进行权衡和合并确保你的 AI 应用持续提供准确且相关的答案而无需工程师不断手动调整搜索算法。运营层面的变化整合的论点并不只是为了每个月节省几千美元的基础设施成本尽管这确实是真实存在的收益。它关注的是运营范围。AI 技术栈中的每一个系统都需要监控、告警、安全审查、备份/恢复流程、升级周期以及至少一名深入了解该系统的人员。四个系统意味着需要维护四套这样的能力另外还要维护它们之间的集成层。当 AgentEngine 出现记忆问题时我们只需要查看一个系统。一组索引。一种查询语言。一套安全模型。一个了解其工作方式的团队。在凌晨 3 点出现故障时这就是 15 分钟修复和多团队事件响应之间的区别。作为背景信息我们每年通过三个云服务提供商管理 130 万美元的云支出。技术栈中每减少一个系统不仅可以降低成本还可以减少工程团队的认知负担。混合搜索优势我接触过的大多数正在评估向量数据库的团队其实都在解决错误的问题。他们问的是 “我们应该为 embedding 使用哪个向量数据库” 而真正应该问的问题是“我们是否真的需要一个独立的向量数据库”关键词搜索会遗漏上下文例如无法将 “ETL crash” 与 “pipeline failure” 联系起来而纯 AI 搜索通常会遗漏产品代码等精确的重要细节。统一平台可以同时运行两者。它会自动权衡并呈现最相关、最新的信息从而确保你的 AI 始终拥有正确的上下文。不间断的业务连续性分散的系统非常脆弱如果外部 AI 管道失败你的应用程序也会中断。整合后的平台通过内置弹性能力避免这种情况。如果 AI 模型暂时降级系统会立即回退到标准搜索。你的应用程序保持在线工作流也不会被阻塞。这对你的 AI 技术栈意味着什么如果你的组织已经在使用 Elasticsearch Platform——许多技术公司都使用它进行日志记录、可观测性或产品搜索——那么你可能已经拥有一个支持 AI 的平台只是自己还没有意识到。通过正确的索引设计和推理端点同一个处理应用日志的集群可以作为 agentic AI 系统的记忆基础。最快交付 AI 的公司不会是拥有最复杂模型管道的公司。而会是那些拥有最简单、最可靠底层数据基础设施的公司。了解我们如何通过内部实践指南成为 AI 优先企业。本文中描述的任何功能或特性的发布和时间安排完全由 Elastic 自行决定。任何当前尚未提供的功能或特性可能不会按时交付甚至可能不会交付。在本文中我们可能使用或引用了由第三方提供的生成式 AI 工具这些工具由其各自所有者拥有和运营。Elastic 无法控制这些第三方工具并且我们不对其内容、运行或使用承担任何责任或义务也不对因你使用这些工具而可能产生的任何损失或损害负责。使用 AI 工具处理个人、敏感或机密信息时请谨慎操作。你提交的任何数据都可能被用于 AI 训练或其他用途。无法保证你提供的信息一定会被安全或保密地保存。在使用任何生成式 AI 工具之前你应该了解其隐私实践和使用条款。Elastic、Elasticsearch 以及相关标识是 elasticsearch B.V. 在美国和其他国家/地区的商标、标志或注册商标。所有其他公司和产品名称均为其各自所有者的商标、标志或注册商标。原文Why the Elasticsearch Platform is the missing piece in your AI stack | Elastic Blog