企业官网建设流程全解析

作者：来自 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