作者 ｜ Anthony Alford

译者 ｜ 平川

Elastic 开源了 Atlas。这是一个基于 Elasticsearch 构建的系统，可以为智能代理维护三类记忆。Atlas 通过 MCP 与智能代理集成，并保持用户记忆的相互隔离。在问答能力评估中，其 Recall@10 得分为 0.89。

标准的解决方法是将先前的上下文塞入上下文窗口。但这种方法在成本、延迟以及“中间遗忘”效应（有广泛的记录）等方面都存在缺陷，即模型会忽略远离提示词边缘的事实。100 万令牌的上下文窗口只是一个临时记事本，而非存储系统……真正缺失的是长期记忆：一种能够跨越会话终点、支持长达数年的交互，并允许按内容、时间和用户检索事实的持久化存储。

整合还会通过两种方式更新程序性记忆。首先，通过创建新的“操作指南”（即解决问题的一系列步骤）；其次，更新现有操作指南的成功与失败计数。这些计数可能会影响检索结果，提升成功率更高的操作指南的优先级。

智能代理通过单一混合查询访问所有这些索引，并在 BM25 词汇搜索和 Jina v5 语义搜索的基础上应用了“互逆排名融合”（RRF）技术；合并后的结果会通过跨编码器重排序器进行重新排序。文档级安全（DLS）机制可以确保查询仅搜索属于该用户的记忆文档。

在 Hacker News 上 关于 Atlas 的一场讨论 中，有一些用户质疑，将 Elasticsearch 用作存储是否“大材小用”，并建议使用其他支持向量处理的数据库，例如 SQLite。另一位用户回复道：

一旦需要脚本评分之类的功能，“任何其他向量数据库”就会开始力不从心……这时问题就变成：“为了性能，你是否需要[近似最近邻]？”…… 诚然，对于数量远超大多数人预期的向量而言，暴力搜索的性能表现确实不错，但如果你希望其延迟达到网页级水平，那么在数量远低于 100 万时，它肯定会遇到瓶颈。维护 Elasticsearch 固然需要成本，但选择一个性能不足的数据库，随后又不得不将其移植到合适的数据库上，同样会耗费大量的时间。

Atlas 的源代码 已经在 GitHub 上开源。