Gemini 3 Pro 给了10Mtoken context，60% 这个数字让我换回了记忆方案

我前阵子做一个法律咨询助手 demo，把客户和律师的 30 万字会话历史一次性塞进 Gemini 3 Pro 的 context 窗口。Gemini 3 Pro 的 10M token 窗口听起来像是"agent memory 已经被 context 长度解决了"——直到我跑了第一组真实问题。

客户问"我们上次说的那个条款 X 你怎么处理"，模型给的答案引用了对话中段一条已经被双方否决的版本。准确率比预期低一半。

这不是 Gemini 的特例。我后来去翻最近的 long context 评测，看到一个反差很大的数字组合：Gemini 1.5 Pro 在 needle-in-a-haystack 单针测试上是 99.7%，但放到真实多事实召回测试，平均只剩 60%。

三个数字让我意识到方向错了

先把数据摆清楚（来自 2026 年初几篇 long context vs RAG 的对比研究）：

• 召回精度：单针测试 99.7%，多事实平均 60%
• • 延迟：1M token 请求的 p95 延迟比 RAG pipeline 慢 30-60 倍
• • 成本：相同任务下，1M context 比 RAG 贵约 1250 倍
    第一个数字解释了为什么我的 demo 翻车——多事实推理才是真实场景，单针测试的数字是销售用的。第二三个数字解释了为什么生产系统不会真的把 10M context 当默认方案——光成本就劝退。

这一组数字之后我去看了 NVIDIA 那篇 “Reimagining LLM Memory” 的博客，里面有个观点我当时挺惊讶：context 应该被当成训练数据用，不是当存储用。换句话说，context 本身不是记忆的合理形态——它是模型在某次推理时临时打开的工作面，需要别的东西来沉淀长期信息。

真实选择不是"长 context vs RAG"

2026 年的 enterprise 实践基本都在用 hybrid 架构：

• 短期 / 任务级 / 工作记忆 → 长 context（in-context 直接处理）
• • 中期 / 跨会话 / 用户级 → memory framework（结构化沉淀）
• • 大量静态知识 / 跨领域 → RAG（向量库 + 重排）
    三层各做各的事。问题是中间这层"memory framework"，方案选错了上下两层都跟着翻车。

我做的那个法律咨询 demo 后来分了两种模式重做：

1. 当前会话内的短期信息：直接塞 Gemini 的 context（200K 左右就足够）
2. 2. 用户跨会话的偏好、之前商讨过的条款历史、客户性格画像：上 memory framework
      第二层我先试了 Mem0 和 Zep。但很快发现一个 long-context 时代特有的问题：当前面的 context 信息越多，memory 框架的"哪些该写、哪些该忘"决策越复杂。Mem0 的选择性 pipeline 在 50 轮以下表现稳定，到 200 轮以上开始出现"用过期信息回答"——FAMA 那个新指标专门测这个。

5 层时间分层的位置

我后来换到了 TiMem（github.com/TiMEM-AI/timem）。TiMem 的设计跟 Mem0 / Zep 走的不是一条路：

• 不依赖向量数据库（虽然可以接）
• • 不维护知识图谱
• • 核心是 5 层 Temporal Memory Tree (TMT)：fragment → evidence → fact → trait → persona
    每一层都有显式时间序，consolidation 触发时上层用更新的下层覆盖陈旧的下层。把"该忘"内化进结构本身。

放回我的 demo，假设客户两周前对条款 X 表达过反对，一周前换了立场支持：

• TiMem 第一周末做 consolidation，在 fact 层记录"客户对 X 的态度：反对"
• • TiMem 第二周末再做 consolidation，新 evidence 升级到 fact 层时直接覆盖：现在态度是"支持"
• • 召回时只能看到最新的 fact
    不需要 conflict detector。不需要给每个 entity 挂 timestamp 然后召回时再过滤。

它为什么是 hybrid 的好选择

这是我换方案后想清楚的事：TiMem 在 hybrid 架构里负责的不是"全部记忆"，是最难做的那部分——长期、需要时间序、需要 forget 的用户级记忆。

三层分工对应到 TiMem：

• 短期会话级 → 直接喂 LLM context（不动 TiMem）
• • 跨会话用户记忆 → TiMem 5 层 hierarchy 处理
• • 静态知识库 → 上你已有的 RAG 系统（chroma / qdrant / lancedb 任选）
    TiMem 的 complexity-aware recall 还会根据 query 复杂度自适应召回深度。简单 query 走浅层 fact 召回，复杂多跳 query 才下沉到 evidence 层。这个机制在我那个 demo 里直接把平均 latency 砍掉一半。

选型小结

不打算给一个谁吊打谁的结论。但有几条决策线索是清晰的：

别把 long context 当 memory 用——除非你的场景就是单次会话内处理，否则 10M context 给的不是"长记忆"，是"加宽的工作面"。

RAG 不能替代 user-level memory——RAG 处理静态文档好用，但用户偏好、跨会话状态、有时间序的事实更新，向量 chunking 这条路不顺。

长会话 + 频繁状态更新场景（教育、客服、协作工具）：TiMem 这类时间分层方案占优，因为 forget 是结构性的。

多跳关系推理为主（知识库问答、企业搜索）：Mem0g 这类向量+图谱方案合适。

短到中等会话 + 简单状态：Mem0 基础版够用，便宜稳定。

那个法律咨询 demo 现在跑稳了。客户问"我们上次说的那个条款"时，模型直接拿到的是最新立场——靠的不是 Gemini 的 10M context，而是 TiMem 帮模型在 200K 的 context 里只塞了真正相关的那部分。

10M token 这个数字会让人产生"长度问题已经解决"的错觉。60% 召回率才是真相。