Uber 13周烧光全年token预算，MongoDB Field CTO：Agent的胜负手在检索

2026年刚开始三个多月，Uber就把全年token预算烧完了。原因说来简单：百万token的上下文窗口出来之后，他们选择每次调用都往里塞满，这套打法还有个专门的名字，token maxing。这个概念3月初刚被提起，4月就已经没人当回事了。

这期Cognitive Revolution的主持人Nathan Labenz是创业者和AI投资人，嘉宾Pete Johnson是MongoDB的Field CTO of AI，工作内容就是满世界跑客户，今年已经去过七个国家，和大约100家企业聊AI进展。他给这轮过山车做了个注脚：早期上下文窗口太小，所有人被迫搭RAG管线；窗口扩到百万token，有人喊“RAG已死”；Uber的账单给token maxing画上句号；如今数据越攒越多、调用量越滚越大、每次塞满窗口要花好几美元，RAG重新回到优先级列表顶部，检索质量成了Agent性能的核心变量。

一段60年的数据库史，解释今天的每个选择

Pete喜欢从历史讲起。1970年6月，IBM研究员E.F. Codd发表了那篇催生SQL的论文。同年2月Pete出生，他爱开玩笑说自己和SQL同岁。

那个年代的应用长什么样？一家公司有一台计算机就不错了，用的人在同一栋楼里，朝九晚五，周末停机没人在意。三大硬件资源里，存储最贵。所以数据库设计的第一原则是规范化：同样的地址只存一次，人放一张表，地址放一张表，再用第三张表关联。教科书里的第一范式、第三范式，本质都是在省磁盘。

到2007年10月，MongoDB写下第一行代码，中间隔着47年摩尔定律。互联网、云计算、iPhone都在那前后爆发，应用要全天候在线，用户散布全球，稀缺资源从存储变成了时间。

于是设计逻辑整个倒过来。还是那个地址的例子：以前拆三张表省磁盘，现在把姓名和地址写进同一个JSON文档，地址重复存一份，换来的是一次磁盘读取搞定，以前要读三次。约束变了，最优解就跟着变。

顺带纠正一个流传很广的误解：MongoDB其实有schema，只是schema灵活。同一个集合里可以放不同形状的文档，加字段不用像SQL那样在生产环境动一张表、牵连一片。

今天的MongoDB，财富500强里75%在用，2026财年收入25亿美元。听着不小，其实只占1000到1100亿美元数据库市场的3%。企业选它的理由集中在三件事：速度、规模，以及越来越重要的检索质量。

从客户自架Lucene，到2.2亿美元买下Voyage

MongoDB做搜索的起点有点意外。2020年他们发现，大量客户在MongoDB集群旁边自己架Apache Lucene服务器，就为了对文档里的文本字段做关键词检索。于是当年推出Atlas Search，把词法搜索直接做进托管服务。

下一步顺理成章：向量搜索。Pete的解释很朴素，向量说到底就是一串浮点数，把文本、图片、音频、视频丢给嵌入模型，拿回来的就是浮点数组。在MongoDB的文档模型里，这只是给文档多加一个属性，再在这个属性上建索引。复制、分片、加密这些底层能力全是现成的，向量搜索直接继承。

词法搜索加向量搜索，再加个前置过滤，比如只查2000年后出版的书，混合搜索就成了。2025年，MongoDB以2.2亿美元买下嵌入模型公司Voyage AI。Nathan算了笔账，这笔钱不到MongoDB市值的1%。

为什么买模型公司而不买向量数据库公司？Pete的逻辑是：向量搜索自己能做，文档模型天然适配；但市场把嵌入模型当成大宗商品，他看到Voyage明显跑出来了，团队里甚至有人在斯坦福教学生怎么造大模型。Hugging Face上的RTEB检索基准，Voyage的模型常年在顶部，比常见的大厂嵌入模型最多高出14%。嵌入模型远没有商品化，选错模型，检索质量可能差出幻觉和正确答案之间的距离。Anthropic自己不出嵌入模型，官方推荐的就是Voyage。

Voyage有几个别家没有的设计，全冲着降低学习曲线去：

• 上下文化分块：把要检索的那句话和它的上下文分成两段一起送去嵌入，返回一个向量。传统做法里块太小丢上下文、块太大稀释重点，开发者只能反复试错找平衡。这个设计直接把曲线掰弯了，小块也能有高质量检索。去年夏天出v3，六周前刚出v4。
• Matryoshka嵌套结构：像俄罗斯套娃，先用1024维嵌入整个语料库，想试512维，直接砍掉后512个浮点数就能测，不用把全部数据重跑一遍。
• 共享嵌入空间：今年1月发布的v4文本模型，从large到开源免费的Nano，四个版本共享同一个嵌入空间，向量互相兼容。开发阶段可以用Nano在笔记本上跑查询，token成本直接归零，上线再换大模型。
• 自动嵌入：指定集合、字段、模型和维度，文档一变，向量自动重算、索引自动更新。

查询侧也在简化。新出的rank fusion和score fusion把词法搜索和向量搜索合成一次API调用，后台跑完按排名或分数合并结果；新近发布的$rerank同理，重排序一次调用搞定。光加一个重排序器，检索质量就能提升5%到10%。

什么时候该认真优化？Pete给了个粗略刻度：做demo和POC，Postgres加pgvector加云厂商自带的嵌入模型完全够用；规模来到10万向量上下，或者检索质量直接决定答案对错，就该换工具了。他还有个玩笑：世上有两种开发者，一种爱MongoDB，一种还没试过。

写入、更改、回忆、遗忘：记忆系统的完整闭环

Nathan问了一个所有人都关心的问题：好的Agent记忆系统今天长什么样？

Pete先讲演进。2022年底ChatGPT刚出来，架构简单到极点：查询进上下文窗口，模型处理，吐结果。模型只学过公开数据，想注入私有数据，就有了RAG。2025年，知识截止日期的问题靠工具和MCP解决，你问MongoDB股价，Agent自己调工具去搜。再往后是循环，上一轮的输出变成下一轮的输入，上下文窗口本身每次都从头来，记忆系统就成了必需品。

早期的记忆很粗暴：短期记忆把本次会话全塞进上下文，长期记忆把最近三天的所有会话也塞进去。两个副作用随之而来。一个是钱，Uber就是极端案例。另一个更隐蔽，有几项学术研究显示，上下文里最重要的是最前面和最后面各7000 token左右的内容，中间那一大段不但帮不上忙，还会干扰模型找答案。

所以思路变了：与其每次塞100万token，能不能为这一轮循环挑出刚好的20万？企业里开始出现更细的记忆类型，比如分类记忆：一个行业或一家公司有100个内部术语，这一轮循环只挑出相关的5个放进去，下一轮再重新挑。

Pete的同事前几天写给他一句话，他当场引用：write, change, recall, forget。写入、更改、回忆、遗忘。

我们这个行业建数据库建了60年，建Agent才18个月，老兄。没人手里有全部答案，大家都在一起摸索。

遗忘是最难的部分。记忆有半衰期，上周的事比三个月前的重要。Nathan自己的记忆系统就吃过亏：他把五年来的邮件、Slack、私信、播客逐字稿攒了大约1GB，按月汇总、按年汇总，上面再盖一层实体互相链接的wiki。结果模型把他一个试了试就放弃的项目，当成进行中的线索挂了好几个月。他干脆把遗忘当成一种美德。

Pete观察到，成熟的记忆系统把两个责任交还给应用作者：一是调用记忆时给个token预算，比如“给我最好的50条”，让系统自己去各类记忆里混着挑；二是拿到答案后要把结果送回记忆系统，由它筛选、整理后写入，写入时还要带上权限控制，同岗位的人可以共享记忆，你踩过的坑我能直接复用。

架构上，数据量特别大的场景可以用混合方案：图结构走两到六层，多的到十几层，到叶子节点再做向量检索。零售客户按商品类目建层级，类目内部做向量搜索，就是这个路数。因为底层是JSON，图、文档、向量、嵌入、重排序可以放在一个平台里，省去拼接多个工具的维护成本。

他还提醒了一个反模式：别靠多跑几遍大模型来给语料分类和瘦身，那是在烧token。分类和压缩这种活，交给便宜的嵌入模型和重排序器。他们最大的客户ElevenLabs走的是微Agent路线，每个客户配多个小Agent，做音频编辑的各种转换，记忆架构就没走这条弯路。

企业AI的坑，几乎都不在模型上

Pete把今年聊过的100家企业分成三类。第一类，买了个工具的license就宣布AI战略完成，这通常远远不够。第二类，做过POC和少量生产部署，ROI算不平。他的判断很直接：卡在POC泥潭里的团队，差别往往出在选题，出在技术应用之前。

他给企业的选题方法很具体：列出业务上最头疼的10到15个问题，筛出数据质量过关的，再筛出已经有度量指标的。最后一条最容易被跳过，没有基线指标，你根本不知道AI有没有让它变好。

呼叫中心是经典案例，因为每通电话的成本、话务量本来就挂在绩效上，AI一上，数字变化立刻能归因。软件开发则相反，年初一堆人晒“代码量翻了五倍”，Pete毫不客气：代码行数是衡量开发效率的最差指标之一，该看的是从想法到上线的速度。

至于买还是建，他的结论是这个行业还没有Agent时代的LAMP栈，没有React和Angular，大家都在摸。能买的基础设施就买，把时间留给业务逻辑。

安全是另一条红线。财富500强目前大多在做员工侧、有人工兜底的用例，原因很实际：两个员工之间泄露工资条，尴尬但不致命；两个客户之间互相看到数据，副总裁就得出来背锅。坏数据质量和坏安全姿势，AI解决不了，只会放大。连单店小生意都开始接AI客服了，Nathan上周五晚在底特律社区披萨店Greg's Pizza订餐，接电话的就是Agent，正常点单全程顺畅，他故意问背后是哪家技术公司，Agent以为他要给公司订披萨。

连文档都在为Agent改写。MongoDB现在提供MCP服务器和一组Agent skills，把数据建模、运维优化这些原本躺在文档里的打法，做成markdown文件直接喂给Agent。

最先进的客户，在墨西哥城和圣保罗

Pete今年先去了阿姆斯特丹和伦敦，又跑了多伦多、班加罗尔、墨西哥城、圣保罗。他聊过的两家最先进的客户，一家在墨西哥城，一家在圣保罗。这两家公司开场都默认美国同行比自己跑得快，事实恰好相反。

他的解释是，这跟美国公司保守不保守没关系。云计算和移动互联网那两波，地理壁垒是真实存在的，超大规模云厂商没在你国家建数据中心，你就没戏。现在几乎每个国家都有至少一个数据中心，模型、向量数据库、嵌入、重排序，接入的门槛被抹平了。上一波技术革命要很多年才能铺开的基建，这一波已经提前就位，领先权第一次和地理位置解绑。

Pete在结尾提醒，节奏只会更快：MCP在2024年感恩节前的周一发布，到次年3月所有竞品都宣布支持；token maxing今年3月初被提起，4月就没人聊了。

明天就能用的五件事

• 给上下文窗口做预算，别再无脑塞满。记住前后各7000 token最要紧的规律，每一轮Agent循环只放真正相关的内容，中间的填充物既烧钱又降智。
• 检查你的嵌入模型。它没有商品化，换一个更好的模型最多能拿14%的检索质量提升，再加个重排序器还有5%到10%。如果你的Agent还在胡编，先查检索，再怀疑模型。
• 用“写入、更改、回忆、遗忘”四件事给记忆系统做体检。多数系统的短板是遗忘：给记忆加半衰期，把过期的项目线索主动清掉。
• 选AI项目先看三样东西：问题够不够痛、数据够不够好、有没有现成的度量基线。三样缺一样，先补课再开工，不然ROI永远算不清。
• 定期做一次Nathan说的“苦涩的教训”清理：把系统里那些为旧模型打的手工补丁翻出来，模型变强了，有些胶水代码可以直接删。