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 RAG2026 年的 enterprise 实践基本都在用 hybrid 架构短期 / 任务级 / 工作记忆 → 长 contextin-context 直接处理中期 / 跨会话 / 用户级 → memory framework结构化沉淀大量静态知识 / 跨领域 → RAG向量库 重排三层各做各的事。问题是中间这层memory framework方案选错了上下两层都跟着翻车。我做的那个法律咨询 demo 后来分了两种模式重做当前会话内的短期信息直接塞 Gemini 的 context200K 左右就足够用户跨会话的偏好、之前商讨过的条款历史、客户性格画像上 memory framework第二层我先试了 Mem0 和 Zep。但很快发现一个 long-context 时代特有的问题当前面的 context 信息越多memory 框架的哪些该写、哪些该忘决策越复杂。Mem0 的选择性 pipeline 在 50 轮以下表现稳定到 200 轮以上开始出现用过期信息回答——FAMA 那个新指标专门测这个。5 层时间分层的位置我后来换到了 TiMemgithub.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% 召回率才是真相。