阿里云宣称在AI记忆性能上以9.27倍击败一家匿名对手

基准测试由MemOS Cloud执行，其披露的条件正是受控测试应有的样子：相同的机器配置、相同的数据集、相同的负载。在每秒10至40次查询的五个负载点上，PolarDB for PostgreSQL每次的P99延迟都低于对照数据库。报告中的差距区间为1.79倍至9.27倍，这五个点的中位数为2.71倍，平均为3.96倍。

两家公司都没有点名对手。这一省略很关键，因为在负载曲线顶端取得的9.27倍优势，既说明了PolarDB的情况，也说明了对手的情况。针对一个未具名系统的基准测试，无法在这两家公司之外复现，读者也无从核实该图数据库是否按生产用户的实际运行方式进行了规格配置、调优或设置。

为什么记忆不再只是聊天记录

阿里云ApsaraDB团队与MemTensor的论点是，上下文窗口是个障眼法。消息源认为，窗口有限以及会话之间信息丢失只是表层症状。更难的问题在于，随着用户规模增长，如何在共享基础设施上写入、检索和扩展记忆, , 这使一件看似模型功能的事情，变成了分布式系统的工程课题。

当智能体从单轮问答转向长时运行任务，记忆的用途也随之改变。一次说出的偏好，必须在数月、数十次会话、乃至为同一用户服务的多个智能体之间存续下来。消息源列举了这在生产环境中所要求的条件：高并发访问、多租户隔离、故障恢复、动态扩缩容，以及决定一条已存储事实何时应被更新或删除的生命周期治理。

一个数据库，而非三个

一套记忆栈通常意味着三个部署。用户ID、时间戳、标签和权限范围等结构化数据进关系型数据库。诸如偏好低饱和色调或莫兰迪色系的语义数据进向量存储。实体关系与多跳路径进图存储。三者的同步则落到应用层身上。

PolarDB for PostgreSQL把它们折叠进一个系统。优化后的PGVector扩展负责语义搜索，PolarAGE图引擎负责实体关系，原生PostgreSQL覆盖结构化数据。阿里云称，PolarAGE在千亿节点规模下可达到每秒数万次查询、响应低于100毫秒，并支持多跳遍历与因果链推理。

把多个存储合并，消除了一类同步工作。这也意味着要接受某一家厂商对三种不同负载的实现版本。需要专用向量索引、或为特定遍历模式而构建的图引擎的团队，就此放弃了插入专用系统的选项。

写入路径内部

对话内容必须先经过处理，才能成为记忆。PolarDB提供三种模型算子：LLM算子，负责抽取长期事实、偏好和实体三元组；嵌入算子，负责把内容转换为向量；以及重排序算子，负责对召回结果重新排序，使更少的无关材料进入模型的上下文。

模型调用优先走阿里云的模型服务Model Studio，高负载时由库内算子作为回退。回退是一项稳定性措施，并不等于宣称两条路径表现一致，消息源也没有对两者进行比较。

召回分三个阶段运行。L1以属性过滤和标签匹配进行向量初筛，所称延迟通常低于50毫秒。L2沿图从候选节点扩展到相关记忆，核心路径P95保持在10毫秒量级。L3对候选重排序，并由LLM判定因果、冲突和条件关系，剔除重复与无关内容。

租户隔离与成本账

隔离映射到数据库原语上。PolarDB集群是物理边界，数据库区分业务线，schema承载一个MemCube，表和图表存储节点、向量与边。在单个MemCube内部，PolarDB按UserID对子图分区，消息源称这在同等规模下将召回效率提升超过50%，并支持为数千万用户提供各自独立的记忆空间。

成本方面的论据仍停留在定性层面。两家公司称，集成周期从数周缩短至数天；存储蒸馏后的记忆节点而非原始对话记录，可减少发送给模型的token；存储与计算分离使基础设施可按实际用量而非预留容量来跟进。这三项说法均未附带任何数字。

消息源未言明之处

在这些数字真正有分量之前，有几个问题需要答案。消息源将基准测试归于MemOS Cloud，且未提供独立验证，因此在第三方复现之前，这些延迟数据仍属厂商说法。

对照数据库的身份、其配置，以及所测试的PolarDB版本，均未披露。缺少这些信息，9.27倍只是一个说法，而非任何人都能审计的测量结果。

还有一个谁从中受益的问题。这是阿里云的一篇页面，宣布PolarDB与MemOS记忆管理系统已上线、MemOS已开源，并提供控制台、REST API和客户端SDK。它读起来既是技术报告，也是产品发布。这并不意味着该架构有错，它所针对的问题, , 为运行数月的智能体提供持久记忆, , 也是真实存在的。但这确实意味着，在企业围绕这些数字重建记忆栈之前，最强的那些数字值得再做一次独立的测试。