OceanBase PowerMem 为何而生?其性能如何?它有哪些玩法?本文带你一探究竟。
在人工智能技术飞速发展的今天,大语言模型(LLM)已成为各类智能应用的核心引擎。然而,一个问题始终困扰着开发者和用户:AI 如何真正“记住”与用户的互动历史、偏好和上下文信息?这个问题看似简单,却直接决定了 AI 应用的实用性和用户体验。
当用户与 AI 对话时,我们期望 AI 能够记住”上次你提到喜欢咖啡”,而不是每次对话都从头开始。但现实是,大多数 AI 应用都缺乏这种持久化的记忆能力。更糟糕的是,当我们试图通过简单地将所有历史对话存储在上下文中来实现记忆时,会遇到性能、成本及准确度的多重瓶颈。
这就是 OceanBase PowerMem 的诞生背景——一个基于Apache2.0开源,旨在解决 AI 应用中记忆问题的轻量级组件。在本文中,我们将深入探讨 AI 记忆的挑战, 剖析 OceanBase 的 PowerMem 的设计以及它如何充分结合 OceanBase 的 seekdb 为 AI 应用赋能的。
AI 应用为什么需要“持久化记忆”?
想象一下,你每天与 AI 助手对话,告诉它你的偏好、工作习惯、重要信息。第二天再聊,它却像第一次见面,需要你重复说明。这种“金鱼记忆”的体验在 AI 应用中很常见。
大语言模型(LLM)在单次对话中表现良好,但缺乏持久记忆。每次对话都是独立的,无法记住历史信息、用户偏好和上下文。这限制了 AI 应用的实用价值。
既然大语言模型(LLM)已成为各类智能应用的核心引擎,那么我们看AI应用的痛点,就先回归到 LLM 模型本身。
近期 AI 圈正在流行一个新的概念——Context Engineering(上下文工程),它被 AI 专家安德烈·卡帕西称为“在上下文窗口中填充下一步所需的恰到好处的信息的精细艺术与科学”。
上下文为什么很重要?因为上下文就是大模型的“记忆”。记忆与智能本就一体两面,上下文窗口越大,模型一次能记住的内容就越多,也就越聪明、越连贯。大模型的发展史,本身也是上下文窗口的扩展史。大语言模型的上下文窗口(Context Window)是其处理信息的上限。主流大模型的上下文窗口大小通常在 128k token 左右,但具体长度因模型而异,一些模型可达 200k token 或更高,而早期的模型可能只有 4k 或 8k。
这个窗口决定了模型一次可以处理和“记住”的文本量,较大的上下文窗口能处理更长的文档或对话。 既然如此,那有朋友就会反问:“我们无限扩大 LLM 本身的上下文不就能解决 AI 应用记忆问题了吗?”
其实不然,上下文窗口的拓展并非没有代价,这与 LLM Transformer 架构的原生限制有关系。由于 Transformer 的自注意力机制需要计算序列中任意两个位置之间的相关性,其计算和内存复杂度与序列长度呈二次关系(O(n²))。也就是说,当上下文窗口从 4k 增加到 128k(32倍)时,理论上的计算量和内存需求的增长不是 32 倍,而是 1024 倍,这为 GPU 的计算能力和显存带来了巨大的挑战。
再说性能方面,处理更长上下文自然更慢。OpenAI 在 GPT-4.1 系列评测中报告:在优化后的推理系统下,用 128k tokens 上下文时,大约需要 15 秒能输出第一个 token,而同样处理 1M tokens 时则接近 60 秒。也就是说,在同样硬件下,从 128k 增加到百万级上下文,响应时间约增长 4 倍以上。
至此,大家应该明白,在现有 LLM 的机制下,上下文并不是越大越好,也不可能无限扩展。
回过头来再看基于 LLM 的 AI 应用,为了解决 AI 记忆问题,许多开发者选择“全上下文”方法:将所有历史对话存储在上下文中。这种方法是最简单的,一定程度上也解决了一些问题,但同时也带来了严重问题:
- 性能及成本问题:随着对话历史增长,模型推理速度急剧下降。同时 Token用量呈线性增长,导致成本大幅上升。
- 效果问题:大型语言模型(LLM)处理长上下文(如数千甚至数万 token 的文本)时,推理质量并非均匀分布。研究表明,模型对输入的开头和结尾部分理解更准确,而中间部分易出现信息遗漏或逻辑偏差。这种现象被称为“边缘优势(Edge Bias)”或“中心衰减(Central Decay)”,其本质是模型架构、训练机制与人类认知模式共同作用的结果。
OceanBase PowerMem + seekdb 的 AI 记忆解决方案
早期在记忆组件尚未独立和成熟之时,不少开发者都尝试过使用传统知识库 RAG 系统来作为聊天记忆的组件,即通过语义划分,将不同的聊天片段视为单独的文档,召回时根据当前聊天的上下文将过去相关的聊天全文检索出来并作为上下文输入模型。
这种方式简单直接,但聊天记忆与知识库检索的两个根本区别导致了这种方案的上限较低,很快就碰到了瓶颈:
第一是知识库是高度凝练的事实数据,具有信息密度高,结构化程度高的特点。而多轮聊天的内容则形式上较为随意,信息密度较低,内容噪点多,将聊天历史信息全文索引并带入上下文反而会导致生成效果下降;
第二是知识库一般是静态文档输入,更新频率较低,一般也不会出现事实错误。而多轮聊天的内容则是持续更新的过程,不仅需要动态进行知识更新,并且聊天过程中甚至可能出现前后的事实矛盾等复杂情况需要处理。
以 Mem0、Zep、Letta 等为代表的记忆系统在解决 LLM 无状态问题上做出了重要贡献。它们通过向量数据库和知识图谱技术,实现了对话历史的持久化存储和语义检索,我们感谢这些开源的方案。PowerMem 作为一款新出的开源AI 记忆组件,也是吸取了前人的经验和教训的。
OceanBase PowerMem 建立在这样一个原则之上:AI 系统应该能够像人类一样随着时间积累知识和经验。这一理念驱动了 OceanBase PowerMem 设计和实施的每个方面:
- 智能提取和保留:OceanBase PowerMem 通过 LLM 模型进行记忆的提取,根据重要性和相关性确定哪些信息值得记住。
- 上下文理解:OceanBase PowerMem 维护跨交互的上下文以实现有意义的个性化体验。
- 持续学习:OceanBase PowerMem 使 AI 系统能够从每次交互中学习并随着时间的推移而改进。
- 自适应遗忘:像人类记忆一样,OceanBase PowerMem 实现了自适应遗忘机制以防止信息过载。
OceanBase powermem 的核心特性包括:
1.开发者友好
- 轻量级接入方式:提供简洁的 Python SDK MCP 支持,让开发者快速集成到现有项目中
2.智能记忆管理
- 记忆的智能提取:通过 LLM 自动从对话中提取关键事实,智能检测重复、更新冲突信息并合并相关记忆,确保记忆库的准确性和一致性
- 艾宾浩斯遗忘曲线:基于认知科学的记忆遗忘规律,自动计算记忆保留率并实现时间衰减加权,优先返回最近且相关的记忆,让 AI 系统像人类一样自然“遗忘”过时信息
-
智能体共享/隔离记忆:为每个智能体提供独立的记忆空间,支持跨智能体记忆共享和协作,通过作用域控制实现灵活的权限管理
-
文本、图像、语音记忆:自动将图像和音频转换为文本描述并存储,支持多模态混合内容(文本+图像+音频)的检索,让 AI 系统理解更丰富的上下文信息
-
支持子存储(Sub Stores):通过子存储实现数据的分区管理,支持自动路由查询,显著提升超大规模数据的查询性能和资源利用率 -
混合检索:融合向量检索、全文搜索和图检索的多路召回能力,通过 LLM 构建知识图谱并支持多跳图遍历,精准检索复杂的记忆关联关系
OceanBase seekdb 是 OceanBase 打造的一款开发者友好的 AI 原生数据库产品,专注于为 AI 应用提供高效的混合搜索能力,支持向量、文本、结构化与半结构化数据的统一存储与检索,并通过内置 AI Functions 支持数据嵌入、重排与库内实时推理。
seekdb 在继承 OceanBase 原核心引擎高性能优势与 MySQL 全面兼容特性的基础上,通过深度优化数据搜索架构,为开发者提供更符合 AI 应用数据处理需求的解决方案。
OceanBase PowerMem 的架构旨在模块化、可扩展,其架构图如下图所示,包括 APIS 层、记忆引擎(core)、模型层以及存储层。
虽然 OceanBase PowerMem 支持多种存储后端(如 SQLite、PostgreSQL 等),但只有与 OceanBase seekdb 深度结合,才能真正发挥出 OceanBase PowerMem 的全部潜力。这种“1+1>2”的效果源于以下几个关键因素:
1.原生混合搜索能力,突破单一检索瓶颈
AI 记忆检索面临的核心挑战是:语义相似性(向量搜索)和精确匹配(全文搜索)往往需要同时满足。例如,用户查询“头痛”时,既需要找到语义相关的“偏头痛”“头部不适”等记忆,也需要精确匹配包含“头痛”关键词的记录。
OceanBase PowerMem 与 OceanBase seekdb 的深度集成实现了真正的记忆混合搜索:
- 智能融合算法:采用 RRF(Reciprocal Rank Fusion)算法,将两种检索结果进行智能融合,既保留语义相关性,又确保关键词精确匹配的优先级,召回准确率提升 10% 以上。
- 库内重排序:OceanBase seekdb 内置 AI Functions 支持库内实时重排序,无需额外调用外部服务,即可对候选结果进行精准排序,进一步优化检索质量。
2.统一存储架构,简化数据管理复杂度
AI 记忆系统需要存储多种类型的数据:结构化元数据(用户 ID、时间戳、标签等)、非结构化文本(记忆内容)、向量嵌入(Embedding)、知识图谱(记忆关联关系)。传统方案往往需要多个存储系统(关系数据库 + 向量数据库 + 图数据库),导致数据同步复杂、查询性能下降、运维成本激增。seekdb 的统一存储架构完美解决了这一问题:
- 多模态数据统一存储:向量、文本、结构化数据、半结构化数据(JSON)在同一张表中统一存储,无需跨库查询,大幅简化数据管理。
- 联合查询能力:支持在单次查询中同时使用向量相似度、全文匹配、结构化过滤(如 user_id、agent_id)等多种条件,实现“一次查询,多维检索”。
总结而言,OceanBase PowerMem + seekdb 的组合不仅仅是“记忆组件 + 数据库”的简单叠加,而是通过深度集成实现了架构级优化:从单一向量检索升级为混合检索,从多系统集成升级为统一存储。这种深度结合使得 OceanBase PowerMem 能够在生产环境中真正发挥出“更准、更快、更省”的优势,为 AI 应用提供企业级的记忆能力。
OceanBase PowerMem 小试牛刀
pip install powermem
# This configuration uses OceanBase for production environments# Database ConfigurationDATABASE_PROVIDER=oceanbaseDATABASE_HOST={需要填写}DATABASE_PORT={需要填写}DATABASE_USER={需要填写}DATABASE_PASSWORD={需要填写}DATABASE_NAME={需要填写}# LLM ConfigurationLLM_PROVIDER={需要填写}LLM_API_KEY={需要填写}LLM_MODEL={需要填写}LLM_BASE_URL={需要填写}LLM_TEMPERATURE=0.7LLM_MAX_TOKENS=2000LLM_TOP_P=0.8LLM_TOP_K=50LLM_ENABLE_SEARCH=false# Embedding ConfigurationEMBEDDING_PROVIDER={需要填写}EMBEDDING_API_KEY={需要填写}EMBEDDING_MODEL={需要填写}EMBEDDING_DIMS=1536EMBEDDING_BASE_URL={需要填写}
.env文件读取配置自动创建记忆!
from powermem import Memory, auto_config# Load configuration(auto-loads from .env)config = auto_config()# Create memory instancememory = Memory(config=config)# Add memorymemory.add("User likes coffee", user_id="user123")# Search memoriesresults = memory.search("user preferences", user_id="user123")for result in results.get('results', []):print(f"✓ Found: {result.get('memory')}")
运行结果:
✓ Found user preferences: Likes coffee
4.添加多个记忆
# basic_usage_example.pyfrom powermem import Memory, auto_config# Load configuration(auto-loads from .env)config = auto_config()# Create memory instancememory = Memory(config=config)user_id = "user123"# Add multiple memoriesmemories = ["User likes Python programming","User prefers email support over phone calls","User works as a software engineer","User favorite color is blue"]for mem in memories:result = memory.add(messages=mem, user_id=user_id)print(f"✓ Added: {mem}")
运行结果
python basic_usage_example.py✓ Added: User likes Python programming✓ Added: User prefers email support over phone calls✓ Added: User works as a software engineer✓ Added: User favorite color is blue
5.多智能体场景
# multi_agent_example.pyfrom powermem import Memory, auto_configconfig = auto_config()customer_id = "customer_12345"# Create agentssupport_agent = Memory(config=config, agent_id="support_agent")sales_agent = Memory(config=config, agent_id="sales_agent")tech_agent = Memory(config=config, agent_id="tech_agent")# Add memoriessupport_agent.add("Customer prefers email support",user_id=customer_id)sales_agent.add("Customer interested in AI features",user_id=customer_id)# Support agent searches their memoriesprint("Support Agent Search:")support_results = support_agent.search(query="customer preferences",user_id=customer_id,agent_id="support_agent")for result in support_results.get('results', []):print(f" - {result['memory']}")# Sales agent searches their memoriesprint("\nSales Agent Search:")sales_results = sales_agent.search(query="customer interests",user_id=customer_id,agent_id="sales_agent")for result in sales_results.get('results', []):print(f" - {result['memory']}")
运行结果
python multi_agent_example.pySupport Agent Search:- Customer prefers email supportSales Agent Search:- Customer interested in AI features
OceanBase PowerMem 集成玩法
PowerMem 支持通过 MCP 或者 Python SDK 的形式集成到主流的 AI 框架中去,简单易用。
举个例子:结合 PowerMem 和 LangChain 的医疗支持机器人示例,展示如何构建具备持久记忆的对话系统。
┌─────────────────────────────────────────────────────────┐│ Healthcare Support Bot │├─────────────────────────────────────────────────────────┤│ ││ ┌──────────────┐ ┌──────────────┐ ││ │ LangChain │ │ PowerMem │ ││ │ (对话处理) │◄────►│ (智能记忆) │ ││ └──────────────┘ └──────────────┘ ││ │ │ ││ │ │ ││ ▼ ▼ ││ ┌──────────────┐ ┌──────────────┐ ││ │ LLM API │ │ seekdb │ ││ │ (Qwen/OpenAI)│ │ (数据库) │ ││ └──────────────┘ └──────────────┘ ││ │└─────────────────────────────────────────────────────────┘
做法是通过继承 ConversationBufferMemory
。
ConversationBufferMemory 是 LangChain 库中一个非常基础且常用的组件,它的核心作用是以最简单直接的方式存储和管理对话的完整历史记录。你可以把它想象成一个“对话笔记本”,它会把用户和 AI 助手之间说过的每一句话都原封不动地、按顺序地记下来。
流程变成了如下:
用户输入│▼┌────────────────---─┐│ ConversationChain ││ (LangChain) │└────────────────---─┘│├─> load_memory_variables()│ └─> PowerMem.search() # 检索相关记忆│├─> LLM.generate() # 生成回复│└─> save_context() # 保存对话└─> PowerMem.add() # 持久化 + 事实提取
数据流程变成了:
Turn 1: "我是张三,最近几天头痛"│├─> LangChain: 处理对话├─> PowerMem: 保存 + 提取事实│ └─> 记忆: "患者 张三 最近几天头痛"└─> 回复: "你好 张三,关于你的头痛..."Turn 2: "头痛通常在下午,中等强度"│├─> PowerMem.search(): 检索 Turn 1 的记忆├─> 上下文: "患者 张三 最近几天头痛"├─> LangChain: 基于上下文生成回复├─> PowerMem: 保存新信息│ └─> 记忆: "头痛在下午,中等强度"└─> 回复: "下午的头痛可能与..."Turn 3: "我在吃布洛芬 200mg,每天两次"│├─> PowerMem.search(): 检索所有相关记忆│ └─> "张三 头痛" + "下午头痛"├─> 完整上下文注入 prompt└─> 个性化回复
上述完整的代码实现参见:https://github.com/oceanbase/powermem/examples/langchain
OceanBase PowerMem 压测结果
在LOCOMO基准测试中,我们惊喜地发现:
- 更准(Smart):OceanBase PowerMem 的整体的 LLM 评分相比全量上下文实现了 48.77% 的相对提升(78.70% VS. 52.9%),凸显了其在事实准确性和连贯性方面的卓越表现。
- 更快(Speed):OceanBase PowerMem 的对记忆的精准抽取记忆事实而非重新处理整个聊天历史,将 p95 的查询延迟降低了 91.83%(1.44 秒 VS. 17.12 秒)。
- 更省(Save):相比于全量上下文,OceanBase PowerMem 对记忆的精简还将 token 消耗量减少了 96.53%,平均每次对话仅需约 0.9K 个 token,而全上下文模式则需要 26K 个 token。
这些结果共同表明,OceanBase PowerMem 在准确性、实时响应和成本效率之间取得了显著的效果,从而使得大规模的长期对话记忆变得切实可行。
总结与展望
通过本文的探讨,我们清晰地看到:AI 应用的记忆问题不是简单的存储问题,而是一个涉及智能提取、高效检索的系统性工程。Memory 正在覆盖越来越多的场景,同时也在覆盖越来越多的记忆类型。Memory 将从对话记忆扩展到任务执行、决策支持、个性化服务等多个场景,覆盖的记忆类型也更加全面。
正如文章开头所言:“没有记忆的 AI 应用缺少灵魂,有记忆的 AI 应用才能成为伙伴”。OceanBase PowerMem + seekdb 的组合,不仅解决了 AI 应用的记忆问题,更重要的是为 AI 应用的智能化升级提供了坚实的数据底座。
现在开始使用 OceanBase PowerMem,让你的 AI 应用拥有“记忆的灵魂”!
项目地址:https://github.com/oceanbase/powermem
想了解更多行业资讯
扫码关注👇

了解更多考试相关
扫码添加上智启元官方客服微信👇

17认证网








