内存工作台
每一款人工智能记忆产品告诉你同样的故事：“我们存储你的对话，并在需要时检索它们。”它们都是在撒谎。它们存储摘要。摘录的事实。压缩表示。最初的背景，真正重要的东西，被抛弃了。
这是一个根本性的错误。当你告诉你的人工智能助手“我上周试过深色烤肉和浅色烤肉，说实话，深色烤肉要好得多”时，mem0商店 User prefers dark roast coffee比较已经不复存在了。时机已经过去了。信念消失了。你失去了信号，保留了标签。
我们构建MemoryBench是为了证明这一点很重要，并构建更好的东西。
数字
500个问题。115k+会话历史令牌。六种问题类型旨在打破记忆系统：事实回忆、偏好理解、时间推理、知识更新、多会话综合和辅助回忆。一位法学硕士法官给出了真实答案。没有共鸣。只是一个分数。
| 提供者 | 准确性 | 备注 |
|---|---|---|
| 超级内存 | 85.9% | 专有API |
| RAG v1.7（我们的） | 82.8% | 开源，本地运行 |
| mem0 | 72.1% | 云API |
| OpenClaw QMD | 58.3% | |
| 文件系统 | 54.2% | 原始基线 |
按类别细分（v1.7）
| 问题类型 | 准确性 | 测试内容 |
|---|---|---|
| 单次会话用户事实 | 97.1% | “我捕获了多少低音？” |
| 单次会话助理回忆 | 94.6% | “你建议的食谱是什么？” |
| 知识更新 | 83.3% | “我现在在哪里工作？”（换了工作） |
| 多会话综合 | 78.2% | 跨对话连接信息 |
| 时间推理 | 69.2% | “我什么时候开始跑步的？” |
| 偏好 | 63.3% | “我最喜欢的咖啡是什么？” |
检索质量为97.2%Hit@KMRR为0.912。几乎总是能找到正确的信息。其余的错误是推理失败，而不是检索失败。这是一个根本不同的问题。
为什么存在
内存市场充满了在同一维度上竞争的产品：更好的嵌入、更好的分块、更好的总结。他们都在玩同一个游戏。游戏是错误的。
真正的问题不是“我们如何更有效地存储记忆？”而是“我们如何保存使记忆有用的上下文？”
当我从对话中提取原子事实时，我得到了完美的关键字匹配。当我把整个对话块放在这些事实旁边时，我就会理解。这种差异出现在偏好问题上（63%对早期版本的90%），因为偏好需要细微差别，而单行事实无法捕捉到。
v1.7两者都有。精确匹配的事实，上下文的父块。事实找到了针；那块石头给了你周围的干草堆。
体系结构
Query → Rewrite (gpt-5-nano) → Embed (text-embedding-3-large)
↓
┌───────────────────────────────────────┐
│ Parallel Search │
│ BM25 keywords + Vector similarity │
│ Atomic fact matching │
│ Entity graph (2-hop BFS) │
└───────────────────┬───────────────────┘
↓
Fact → Parent Chunk Injection
↓
Session Boost (+0.1 for fact-matched sessions)
↓
LLM Rerank (gpt-5-nano, query-type aware)
↓
Entity + Relationship context
↓
User Profile injection
↓
Answer (GPT-5, reasoning)六个检索信号融合在一起：
- BM25 （0.3权重）：姓名、日期、特定术语的精确关键字匹配
- 向量相似性 （0.7权重）：释义查询的语义匹配
- 原子事实：行级精度与父块检索匹配
- 实体图：用于多跳关系问题的2跳BFS遍历
- 用户配置文件：总是注入持久的传记事实
- LLM重新登录：查询类型感知评分（时间、偏好、事实、多跳）
一切都在本地运行。唯一的外部调用是对OpenAI进行嵌入和LLM推理。没有内存API订阅。除了模型提供商，没有数据离开您的机器。
快速开始
bun install
cp .env.example .env.local # Add OPENAI_API_KEY
bun run src/index.ts run -p rag -b longmemeval -j gpt-4o -r my-runMCP服务器（克劳德代码集成）
RAG系统作为MCP服务器发货。Claude Code通过每个repo隔离跨会话获取长期内存。
# Start the RAG server
bun run src/rag-server.ts
# MCP server registers as rag-memory in Claude Code settings
# Tools: memory_search, memory_store, memory_use_repo, memory_profile, memory_list_repos两个存储层：
- 个人 (
jinstronda)：用户简介、偏好、意见、关系。总是搜索。 - 每次回购 (
repo-)：项目特定的决策、架构、调试结果。按项目隔离。
搜索查询两者。每个会话都从加载上下文开始。突破会自动存储。上下文在压缩中幸存下来。
配置
OPENAI_API_KEY= # Required (embeddings + LLM)
DATABASE_URL= # Optional (PostgreSQL + pgvector for production)
RAG_PORT=3847 # Optional (server port)
RAG_CACHE_DIR= # Optional (defaults to ./data/cache/rag)命令
| 命令 | 描述 |
|---|---|
run | 完整流程：摄取、索引、搜索、回答、评估、报告 |
compare | 在多个提供商之间并行运行相同的基准测试 |
test | 测试一个问题 |
show-failures | 调试失败的问题 |
serve | 启动web UI |
接下来是什么
63.3%的偏好是差距。原子事实分解消除了偏好问题所需的对话细微差别。v1.7中的父块注入部分地解决了这个问题，但真正的解决方案是教重新排序器对偏好内容赋予更高的权重，并在事实提取中保留比较语言。
将问题日期连接到答案提示后，69.2%的时间推理得到了改善（在v1.6中，它们被默默地缺失了）。日期修复的全面评估尚未完成。
这种建筑的天花板可能是88-90%。要超越Supermemory的85.9%，需要解决偏好和时间问题。检索已经在那里了。理由并非如此。
许可证
麻省理工学院