Write, Change, Recall, Forget: MongoDB's Pete Johnson on How Retrieval Drives Agent Performance

百万上下文，不如精准检索

Pete Johnson 是 MongoDB 的 Field CTO of AI，有 30 年技术从业经历。今年，他已在 7 个国家与约 100 家客户聊过企业 AI 落地：从数据库和检索，到 Agent memory，再到组织该先买什么、先建什么。他看到的变化很具体：企业一度把百万 token 上下文当成万能药，随后又被账单和错误率拉回现实；真正开始跑出结果的团队，反而在信息筛选、指标和权限边界这些“基础活”上花了更多时间。

这期回答了 7 个问题：

1. 为什么把百万 token 塞满上下文，可能同时拉高成本和错误率？
2. RAG 为什么经历了“已死”到重新成为企业优先事项的反转？
3. 文档切块到底该切多大，为什么更小的块反而可能检索更准？
4. Embedding 模型真的是可随意替换的商品吗？
5. 企业该如何挑选第一个 AI 项目，才能避开 POC 泥潭？
6. 为什么多数大企业先让 AI 辅助员工，而不是直接面向客户自主行动？
7. Agent 有了记忆后，为什么“遗忘”比“记住”更难？

被问到百万 token 上下文窗口出现后，企业为何又重新重视检索时，Pete 先讲了一个让人清醒的案例：Uber 曾在 13 周内耗尽其 2026 年的 token 预算。token 可以简单理解为模型处理文本时的基本计量单位，也是推理成本的主要计费单位。上下文窗口能装下一百万 token，不等于每次调用都该塞满；每一轮 Agent 的推理、工具调用和结果回写，都会重复产生这笔账单。

更麻烦的是，长上下文并非只带来钱的问题。Pete 援引学术研究称，模型最重视的往往是开头约 7K token 和结尾约 7K token；夹在中间的大量内容，可能让模型生成答案时反而混乱。于是企业开始从“每轮最大化塞入百万 token”，改为追求一次 Agent loop，也就是一次“取信息—推理—行动”的循环中，恰好够用的内容。Pete 的提问很直接："What if I could choose just the right 200,000 for this agentic loop?"（如果我能为这一次 Agent 循环选出恰好合适的 20 万 token 呢？）

这意味着，Agent 的竞争不再只是“谁的窗口更大”，而是谁能以更低成本，把当前任务真正相关的信息拿回来。检索错了，模型既会基于错误材料推理，也会为无关材料付费。RAG，也就是“检索增强生成”，因此没有因为长上下文而消失，反而重新成为控制质量与成本的工具。当然，不存在一个永远正确的上下文大小。Pete 把它描述成一个只能不断逼近、很难完美达到的目标。

被问到一本有章节、段落和句子的长文本该怎么切块并向量化时，Pete 指出了 RAG 工程里最常见的拉扯。所谓切块，就是把一份长文拆成多个可以被检索的小段，再将每段的语义编码为向量，也就是一串代表“意思”的数字。块切得太小，比如只留下单独一句话，这句话脱离前后文，模型可能不知道“它”到底指谁；块切得太大，比如一次塞进三页，存储成本会上升，检索时又难以命中真正关键的那一句。

传统做法没有捷径。开发者通常要换不同的 chunk size，跑三四轮测试，在块大小、成本和检索质量之间找平衡。Voyage 提出的 contextualized chunking，思路是把“要精确命中的细粒度句子”与“它所处的背景信息”分开传入，再返回一个融合两者含义的向量数组。Pete 对它的总结是："When you flip that script, it turns out you can get better retrieval quality with a smaller chunk size."（当你把这个逻辑翻转过来，会发现：用更小的切块反而能获得更好的检索质量。）

这意味着，问题不再只是预先规定一个“最佳块大小”。更重要的是，能否把语义单元和背景语境分别表达，再由模型把两者结合。过去开发者像调收音机一样，反复拧 chunk size 旋钮；现在，一部分调优被 embedding 模型吸收了。但这不等于切块设计从此消失。Pete 也承认，有些场景仍必须由开发者自己控制 chunk size，尤其当文档结构、合规边界或业务语义非常特殊时。

被问到个人开发者何时该从“让 Agent 自己选数据库和 embedding”升级为严肃优化时，Pete 给出的判断标准是速度、规模和检索质量。Embedding 模型的作用，是把文字、图片或其他内容编码进向量空间，让系统可以按“意思接近”而不是仅按关键词匹配来找资料。许多人把这层当成随时可替换的水电管道：默认模型能用，换谁都差不多。Pete 的结论恰好相反："Most people think embedding models are commoditized, and that is not true."（大多数人以为 embedding 模型已经商品化了，但事实并非如此。）

他把约 100,000 个 vectors 视为规模开始真正成为问题的常见门槛，具体仍取决于 chunk size。到了这个量级，检索延迟、索引占用和召回质量都会放大。Pete 称，Voyage 的模型在相关 benchmark 上，相比部分其他 embedding 模型最高可有约 14% 的提升。这 14% 不是排行榜上的装饰：在某些任务里，恰恰可能是 Agent 找到正确证据，还是漏掉证据后开始幻觉之间的差别。

维度也会把这个问题变成成本问题。Embedding 常见维度至少为 256，最高可达 2048；维度越高，向量空间越丰富，通常越有利于区分细微语义，但磁盘、索引和内存占用也更高。这意味着企业不能只按 API 单价，或按云厂商默认选项来选 embedding。当数据规模扩大、答案出错会产生业务后果时，它会从一个可替换组件，变成决定 Agent 可靠性的架构选择。反过来，小型原型没必要一开始就堆最强模型；如果速度、规模和质量还没有构成压力，过早优化只会增加复杂度。

被问到企业在 AI 领域该买还是该建、哪些能力已足够成熟时，Pete 没有先谈模型选型，而是把客户分成三类。第一类企业买了一个工具，就以为 AI 战略已经完成；第二类做了若干 POC，也就是概念验证，或上线少量生产项目，但 ROI 时好时坏；第三类才开始处理更复杂的 memory system，研究如何让 Agent 写入、更新和调用记忆。Pete 认为，第二类企业长期卡在“POC purgatory”，即概念验证泥潭里，主要不是因为技术没跟上，而是起点就挑错了问题。

他的筛选框架很朴素：先列企业最重要的 10 到 15 个问题；再筛其中哪些拥有好数据；最后确认哪些问题原本就有衡量指标。呼叫中心是典型例子。企业原本知道每通电话的成本、每天的通话量，也有员工考核数据。AI 接入后，只要这些数字变化，就可以估算它带来了多少收益。Pete 的提醒是："If you don't already have metrics for how something is performing, you won't know if it got better."（如果你原本没有衡量一件事表现如何的指标，你就不会知道它是否变好了。）

这也解释了为什么“代码行数增长五倍”不是一个好故事。软件交付真正该看的，是从一个想法提出，到产品进入生产环境的速度；代码写得更多，可能只是返工更多。换句话说，AI 项目不该从“模型能做什么”出发，而应从“哪个已有数据、已有基线、可以归因的业务瓶颈最痛”出发。没有基线，项目即便看上去很聪明，也无法证明自己让业务变好了。

被问到呼叫中心等场景里，AI 已经走到辅助员工，还是直接替代客服这一步时，Pete 的观察并不激进。他接触的大多数《财富》500 强企业，当前优先部署的是面向员工的用例，而且保留 human in the loop，也就是让人保留审核、批准或接管的权力。原话是："Most the Fortune 500s that I talked to are doing employee facing use cases with human in the loop."（我交谈过的大多数《财富》500 强企业，都在做面向员工、并保留人工参与的应用。）

这条路径首先有一笔更容易算清的 ROI 账。员工岗位原本就有 KPI，即关键绩效指标：客服处理速度、保险理赔员的处理量、制造一线的返工率，都可以成为观察点。AI 进入工作流后，如果 KPI 改善，企业较容易把变化归因于工具本身。相比之下，直接把 AI 放到客户端，即使节省了人工，也很难忽视风险敞口。

Pete 举了一个很有层级感的例子：同一家公司里，一名员工意外看到另一名员工的薪资，已经是严重问题；但若两位客户之间发生数据泄露，事故就会升级到需要副总裁出面承担责任。这里的差别不只是隐私内容本身，而是权限边界、法律责任和品牌损失的总和。这意味着，企业 AI 的下一轮扩张，未必先表现为“无人客服全面接管”，更可能先是有清晰职责、明确绩效、权限范围可控的员工增强工具。Pete 也强调，这只是当前主流路径，不是绝对规律；客户面向的自主 Agent 仍会有例外，只是它必须先承担更高的安全证明责任。

被问到如何维护持续增长的个人或企业 Agent memory，避免过期项目、错误关系和旧判断长期残留时，Pete 把完整循环概括为四件事：写入、改变、回忆、遗忘。多数团队目前最擅长的，恰恰只是第一步——不断把聊天记录、文档、任务结果和用户偏好塞进记忆库。可信息有半衰期：今天的项目状态、上周的决策和几个月前的联系人关系，重要性并不相同。旧信息不被修正，之后每一次检索都可能把它重新带回模型上下文。

Pete 认为，复杂 memory system 会把应用作者的职责变成两段。第一段是按 token budget 检索：不是把所有记忆搬出来，而是要求系统针对本轮任务给出最相关的 50K 或 100K token。第二段更容易被忽略：Agent 生成答案后，还要把答案送回记忆系统，让系统整理、写回、更新，必要时也支持同岗位的人共享有用记忆。Pete 对难点没有粉饰："This is the hardest problem with agents right now, I think."（我认为，这是当前 Agent 最难的问题。）

这意味着，Agent memory 不是一个越堆越大的知识库，而是一套持续更新、纠错、共享和淘汰的信息治理系统。没有遗忘机制的记忆，最后会像堆满旧文件的房间：东西都还在，却越来越难找到真正需要的那一份。Pete 提醒，整个行业已经构建数据库约 60 年，构建 Agent 却只有约 18 个月。现在还不存在成熟的标准答案；谁声称已经解决了记忆治理，通常只解决了写入或召回中的一部分。

被问到今年走访多国后，美国受众忽略了哪些全球 AI 变化时，Pete 给出的答案带着一点反直觉。他今年去了 7 个国家，在多伦多、班加罗尔、墨西哥城和圣保罗等地与客户交流；他见到的两个最成熟案例，不在美国，而在墨西哥城和圣保罗。用他自己的话说："the two coolest things I've seen this year were in Mexico City and in Sa Paulo."（我今年见到最酷的两个案例，分别在墨西哥城和圣保罗。）

过去的技术浪潮里，地域确实是硬门槛。云计算刚兴起时，如果本国没有大型云服务商的数据中心，企业很难获得足够稳定的算力和服务；移动互联网早期，如果没有网络基础设施，智能手机也无法真正发挥作用。但 Pete 认为，今天多数国家至少已有一个 hyperscaler 数据中心，也就是超大规模云服务商的本地基础设施。模型、向量数据库、embedding 和 reranker 的可获得性，已经比云和移动互联网早期好得多。

这意味着，AI 应用竞争的决定因素正在从“公司坐落在哪里”，转为“有没有可用数据、明确问题和落地意愿”。美国公司并不天然拥有最早、最好的试验场，其他国家的企业也不必先等待本土出现一家模型巨头。Pete 并没有把这个现象解释为美国企业更保守，而是强调全球基础设施普及降低了进入门槛。地域差距没有完全消失，但它已不再是过去那种先天性的技术鸿沟。

把这 7 条放在一起看，主线并不是“企业应该买哪一个模型”，而是企业该如何管理信息。第 1 条“上下文越长，Agent 反而可能越贵、越糊涂”，说的是信息输入不能无差别堆积；第 6 条“Agent 记忆的难题不是写入，而是知道何时遗忘”，说的是信息存下来之后，也不能无差别保留。它们指向同一件事：Agent 的性能上限，不只由模型大小决定，更由它能否在正确时间拿到正确材料、避开错误材料决定。

第 4 条关于选题的判断，和第 5 条关于人工参与的判断，也是一条逻辑的两面。先选已有数据、已有指标的流程，企业才知道 AI 有没有改善结果；先让 AI 在权限清晰、可由人接管的岗位中辅助员工，企业才能在收益和风险之间建立真实的边界。所谓“上线一个 Agent”，从来不只是接一个模型接口，而是重新安排数据、指标、权限与责任。

如果你的团队正在搭知识库、做客服 Agent，或准备把内部文档交给模型，先别急着追逐更长的上下文窗口。先问四个更具体的问题：这次任务到底需要哪些信息？哪些信息已经过期或未经证实？原本用什么指标衡量这项工作？如果 Agent 越权或答错，谁能在什么节点接住它？这些答案，才是模型之外真正决定系统能否进入生产环境的部分。