三百万封邮件、十次大语言模型（LLM）调用、六个模型：Shortwave 的检索增强生成（RAG）实战手册

Nathan Labenz 用 Gmail 差不多有二十年了。他试过其他客户端、各种“收件箱清零”的习惯和新界面，没有一个留得住。Shortwave 留住了。用了几周之后，他仍在打开它，而且早已超出好奇的阶段——他称之为一种真正的新习惯。考虑到 Gmail 的肌肉记忆有多根深蒂固，这并非小事。

让他动心的是 AI 助手：一个自然语言侧边栏，能搜索收件箱、查看日历，还能用他的口吻起草邮件。他说，光是搜索就足够了，但“以我的口吻写作”的效果，是他在任何应用里见过最好的。他很早就放弃了收件箱清零，如今只想要一个帮手，在塞满的邮箱里找到方向；有几次，他找到了一些自己知道存在、却没法用关键词搜出来的东西，让他觉得近乎魔法。

Andrew Lee 创办了 Firebase，后来把它卖给谷歌，之后又创办了 Shortwave。他对背后的技术栈格外坦率。没有什么秘密武器。这个助手由几个模型组成，每次提问大约调用十次大语言模型，另外还有一条被拆成许多小而可测试步骤的检索流水线。Labenz 请他做客《The Cognitive Revolution》，对这条流水线做了一次长时间的工程讲解，从第一次导入邮件，一直讲到最后一次 GPT-4 Turbo 调用。

Shortwave 创办时，路线图上原本没有 AI。Lee 卖掉 Firebase，在谷歌工作过，休息过一段时间，然后又有些坐不住。2019 年有两件事促使他再办一家公司。第一件是香港的民主抗议，以及微信被用作控制工具的方式：说错一句话，可能有人会找上门，或者消息根本发不出去。他曾告诉自己，至少西方的通讯平台是可信的，后来他连这一点也开始怀疑。

第二次刺激离他更近。谷歌关停了自家的下一代邮件产品 Google Inbox。Lee 的反应很直接：谷歌资源近乎无限，拥有全世界最大的邮件用户群，如果它都不愿投入去研究邮件的未来，那或许就该由他来做。他在 1990 年代和父亲在家里的地下室经营过一家互联网服务商（ISP），所以至今对邮件底层那套联邦式协议仍有好感。他给以前 Firebase 的老同事打了电话，2020 年初他们便开始动手。

第一款产品是协作式邮件，因为 Firebase 原本就是协作平台，他们知道怎样构建实时共享的系统。作为第一版，它毫无希望。想找邮件客户端的人，不会同时想离开 Slack；而想用 Slack 的人，也不会向全公司推荐一个新的邮件客户端。于是他们转向个人商务邮件客户端，接下来一年半都花在显示、会话串联和搜索上——也就是让邮件看起来正确的那些不起眼的工作。

在这次对话前大约一年半，客户端已经足够稳固。大语言模型此前他们玩过，始终没有真正达到可以上线的水平，突然之间就达到了。一位老联合创始人带来了一个演示。他们大力转向 AI。随之而来的那个认识，正是整个检索增强生成故事的开端：在邮件客户端的全部历史中，收件箱里的数据对计算机来说都是不可访问的。你可以搜索，你可以阅读，但没法提问，让客户端替你找出答案。原本只是占着磁盘空间的一堆非结构化文本，一下子变成了真正可能有价值的东西。

Lee 承认，他们在架构上是歪打正着。协作产品需要客户端和服务器，并且要有实时数据流——和 Firebase 的形态一样。转向大语言模型时，这个选择就成了基础设施。与几乎所有竞争对手不同，Shortwave 早已把用户的全部邮件存在服务器上。新用户注册意味着完整导入和重新索引，成本很高：他们存了每一封邮件的副本。有的收件箱里有三百万、四百万甚至五百万封邮件。这项工作可能只需几分钟，也可能要几天。随着爬取向后推进，用户会看到邮件按时间倒序逐条出现。

每封邮件会按两种方式建立索引。Elastic 负责全文检索。一个开源嵌入模型（embedding）Instructor XL（来自 Hugging Face）把向量写进 Pinecone。他们选 Instructor XL，是因为它便宜、快、够用，而且维度不要太高。邮件存了几百万封，查询却相对不频繁，向量数据库会主导成本，所以他们不要最大、最好的嵌入。中等维度的向量精度稍差，他们的办法是多返回一些近邻，并把更多结果塞进提示词（prompt）里。

Pinecone 胜出，是因为它有一项其他一线向量数据库缺少的功能：命名空间（namespace），让大量用户能待在一起而不会有性能损失。PGVector 本来很方便，因为他们已经在用 Postgres，但对这类数据形态，它的过滤顺序不对：先找最近邻，再按用户过滤。如果把所有租户的向量都放进一张表，引擎要先筛过一座大山，才能找到你的邮件。给每个用户单独建表是一种变通办法，但会带来各自的运维麻烦。Lee 的建议是：先想清楚需要多少个命名空间——每个用户一个、每家公司一个，还是全局一个——并且对文档数量和文档大小要实事求是。大多数检索增强生成应用的文档量在几千到几十万之间，Shortwave 不属于这个范围。

因为他们用交叉编码器（cross-encoder）做重排序，向量检索就不必做到分毫不差。他们先撒下大网，再用问题给每份文档打分。这是在检索延迟与存储、嵌入成本之间做的权衡。Labenz 提到 OpenAI 较新的嵌入模型，其向量长度可变，能用较小尺寸保留大部分信号，并随着需要的增长逐步提高精度。Lee 认为这是正确的思路：不同的应用各有各的最佳平衡点。他还预计，向量数据库会把计算和存储拆开来卖，因为目前的打包定价对他们这种“重存储、轻查询”的负载不利。Pinecone 当时刚推出的托管选项，已经在他们的待选清单上了。

Lee 说，让人们惊讶的是，这个助手居然能跑起来。很多团队都有演示用的智能体（Agent）；但真正接入人们在用的产品里的，屈指可数。Shortwave 并没有做他会称为革命性的事情。“我们不是 AI 研究员，”他说。他们是应用开发者，把合适的部件硬凑到传统基础设施上。核心的洞见很早就出现了：多步规划达不到他们需要的质量。每一步都喂给下一步，每个模型都会出错，而错误会一路传递下去。于是他们把设计倒了过来：目标变成一个包含所有必要上下文的提示词，用一次大语言模型调用给出答案。所有精巧的工程，都在于往那个提示词里放什么。

它仍然很像一个智能体。首先是工具选择：一次大语言模型调用，塞满了世界状态——用户是谁、现在几点、他的设置、屏幕上的会话、前几段内容，以及收件箱里当前选中的任何东西。上下文很关键。如果打开的会话谈的是超级碗，而用户问比赛几点开始，系统能够理解；脱离上下文，它就做不到。这次调用会返回一个数据源数组，包括六到七种工具。有些很便宜：直接导出当前会话、注入设置，或为摘要加载额外的提示词指令。最贵的是历史邮件。界面上显示“搜索中”时，就是检索增强生成在起作用。

如果选择了检索增强生成，就进行查询改写：利用会话历史，把一个依赖上下文、满是代词的问题，改写成独立完整的问题——用名字代替代词，用绝对时间代替相对时间。然后，一个更小、更快的模型做特征提取（feature extraction），为传统的 Elastic 搜索抽取标签、联系人、时间范围和关键词。这些步骤与基于改写后查询在 Pinecone 中进行的 KNN（最近邻）查找并行运行。两组结果随后合并。最上层还有一层人工调校的启发式规则；Lee 举的例子是时效性偏好。如果有人问为什么他的航班延误了，那很可能指的是最近讨论过的那一班，因此更早的命中结果会被降权。

随后，一个跑在他们自有 GPU 上的交叉编码器给剩下的每封邮件打分：这份文档对回答这个问题能有多大帮助？再经过一轮启发式处理和排序，前三十到五十个会话被送回客户端。客户端调用 OpenAI，附上所有被选中的工具的数据——检索增强生成只是其中之一——还有格式说明，好让回答能被解析成富文本、会话链接和按钮。最后这次调用用的是 GPT-4 Turbo。前面的一切，都是为了确保提示词里没有遗漏任何重要内容。

Labenz 数出循环里有四次大语言模型调用。Lee 补上了 Labenz 漏掉的一类调用：特征提取。查询被改写之后，若干小模型分别抽取标签、关键词和其他过滤条件，每一项都是单独的一次调用。串行步骤有五个：工具选择、改写、特征提取、交叉编码和最终回答，其中特征提取内部还有大约五项并行执行。每次你向助手提问，Shortwave 大约会发起十次大语言模型调用。这还不包括注册时写入的数百万个嵌入。

生产环境中运行着六个模型。其中三个来自 OpenAI：GPT-4 负责助手的最终回答，GPT-3.5，以及一个经过微调的 GPT-3.5。在他们自己的基础设施上，运行着 Instructor XL、一个基于微软开源数据训练的交叉编码器，以及 Mistral。GPT-4、GPT-3.5、交叉编码器和 Instructor XL 都服务于检索。Mistral 负责写收件箱摘要，Lee 对它印象不错，可能会把它用到更多地方——它跑在他们自己的机器上，有利于成本和延迟。经过微调的 GPT-3.5 则留给 AI 自动补全，这是一种类似 Copilot 的内嵌式体验，之所以做它，是因为人们喜欢它的写作效果，却觉得侧边栏太慢。

自动补全需要 GPT-3.5 的速度，承受不了 GPT-4 的延迟。原版 GPT-3.5 对补全中的细微之处不够聪明：需要一句话时它会甩出两段，把空格和换行弄乱，写得不像邮件，或者把已经输入的内容又重复一遍。微调弥补了这一差距。数据集用的是创始人自己的邮件，没有任何客户数据。做法简单又巧妙：取一封真实的已发送邮件，删掉其中一段，再训练模型生成被删掉的那部分。这教会了它格式、常见长度，以及一项更微妙的能力：从上下文中照抄事实。

Lee 最喜欢的演示是：“our Wi-Fi password is:”——模型应当从更早的一封邮件里把密码粘贴过来。没有微调的 GPT-3.5 即使事实就在上面，也看不到。微调之后，它就能看到了。训练时，一个脚本遍历他们的收件箱，组装出当时情境下会构建的完整检索增强生成提示词，随机删掉半句话，并以真实发出的邮件作为标准答案。他们还会为模型表现不佳的情形加入人为构造的示例。让他感到意外的是泛化能力。他担心它会开始改写用户的旧邮件，结果并没有。它学会了这项任务，运行时则会尊重每个用户检索到的上下文。

自动补全在运行时的检索是两次查询。光标落在输入框时，Shortwave 会找出与相似会话有关、用户已经发出的邮件——以前收到过这样的邮件时，用户是怎么回复的？另外，它还会对已写好的草稿做嵌入，找出相似的已发送邮件，这样像“my address is:”这样的句子就能把地址拉出来。两组结果都放进提示词里。助手的技术栈与此接近，但有所不同：它用 GPT-4 Turbo，因为人们愿意等待；而且它能执行任意检索，不只限于你发出过的邮件。这也是 Labenz 觉得侧边栏草稿质量略高一筹的原因。Labenz 还分享了他在 Waymark 得来的一个经验：在他们的脚本撰写器里，微调数据中加入思维链，是关键突破。Lee 此前没有试过，他说他们应该试试。

就这套机制而言，Labenz 惊讶于产品依然感觉很快。Lee 的经验法则很直接。能并行的全部并行化。能流水线化的全部做成流水线：交叉编码在结果一离开数据库时就开始，无须等整组结果到齐。能用快模型时就用快模型——GPT-3.5、微调模型、Mistral。摘要要放在昂贵的 GPU 上，因为它必须即时出现。让输出保持简短。思维链对他们也有帮助，但只在少数情况下使用。推理 Token 会在答案之前输出，用户就得等。在性能很重要的时候，他们宁可承担推理上的代价，也不愿承担延迟上的代价。

前一年十月的一篇博客文章把这套技术栈称为前沿。到录制这期节目时，Lee 已经说这一整套都过时了。每一个环节都可能被替换，即便整体框架依然成立。起初没法微调的工具选择，现在可能会为了成本和速度转向 Mistral。查询改写和特征提取，可能会合并成一个更聪明的提示词。更好的嵌入模型已经出现；向量存储上的计算与存储分离，也许能让他们使用更宽的向量，而不致账单暴涨。重排序是最不确定的部分。传统的基础设施工作（过滤、管道）依然有改进空间。目标是一个每次都真正能依靠的助手，它不该只在部分查询上神奇，其余时候却一无所获。

Labenz 喜欢现有的界面：生成内容会引用它所用到的会话，并用一条线把“用过的”和“只是检索到的”区分开，用户还可以手动重新排序，再次生成。他希望更早展示这些会话，并且希望语音输入成为一等功能，即便是坐在桌前，因为把想法组织成语言比打字更快。Lee 说他们可能很快就会做语音。直到录制前两周，移动端都还没有助手；在手机上，他自己主要做两件事：快速找到东西，以及把含糊的听写整理成一封听起来像他本人的邮件。iPhone 自带的听写功能，和 Whisper 并不相同。桌面端没那么紧迫，因为键盘就在手边。

Shortwave 每个客户都在亏损。面向零售的 SaaS 定价，覆盖不了导入、副本、嵌入以及大量模型调用的成本。这并非偶然。对于一家顺着潮流前进的创业公司，Lee 的规则是：在功能看似可行之前就发布。所谓不可行，可能是技术还不成熟、产品行为尚未解决，或者经济账算不过来。如果你相信成本曲线，就用风险投资去填补差距，直到它兑现。YouTube 是他举的例子：它在带宽、存储和重新编码上大把烧钱，然后单位经济效益才到来。他希望 Shortwave 在其他市场都认定这是个好主意的时候，已经经过实战锤炼、拥有了客户。

他们对外推销这个助手时，把它定位为人们原本要花钱请行政助理才能做的那部分事情的廉价版。Labenz 在这一领域有一家公司担任顾问，他认为，眼下的互补关系是真实的，尽管 AI 取代人力是更长远的走向。一位真人行政助理一旦走进二十年积累下来、杂乱不堪的收件箱，并不认识其中的联系人；Shortwave 的搜索能帮她打开局面，但替代不了她。Lee 同意，这个产品做不到真人能做的所有事，而且他们收到了不少需求，希望有一个正经的委托收件箱功能，让助理能在不共享登录凭据的情况下工作。如今把 Shortwave 当作助理来用的人，通常是把它叠加在真人助理之上，或者是因为请不起真人而用它。

Labenz 很乐意删掉自己大约九成的邮件，既为了应付 Gmail 超出的存储空间，也为了检索质量。Lee 很想帮这个忙。用户提得最多的功能需求是 AI 分拣：如今 Shortwave 能写邮件、能搜索，还能对多选的邮件排序，但它不会主动进来把大部分邮件扔掉。他们先推出更安全、风险更低的功能。会批量删除邮件的智能体，需要很高的把握。嵌入也为聚类打开了一条路径：拉取收件箱后，可以用类似 Tinder 的卡片，呈现粗略的个人分类——下周的播客、营销网站的垃圾邮件、通讯订阅——每张卡片上附带一个推荐操作，这样就不用面对一整面会话墙了。用户在现有界面里会注意到一点：AI 实际上什么都做不了。它只能推荐，并在你面前放上按钮。发送、删除和归档都需要你点一下。这是有意为之。Lee 希望人们可以放心地问任何问题，并且知道在他们点头之前，什么都不会离开。

从长远看，他想换一个框架来看待这件事。收件箱是一堆待办事项，却感觉不出它有什么价值。借助大语言模型，它可以变成一个知识库：生意上正在发生的一切、你曾经交谈过的每一个人、SaaS 通知、各种邀请。录制这期节目之前，这款产品原则上本可以告诉你 Labenz 是谁，以及你们已经聊过什么。一旦这套语料能帮到你，它也能帮到一位队友。如果 Labenz 之后给 Lee 的某位联合创始人发了一封邮件，那位联合创始人的助理，或许会和 Lee 的助理商量哪些内容可以分享。隐私是其中最难的部分。那个古怪却很酷的版本，是一个公司级的模型，它了解所有个人助理所了解的一切。

Labenz 追问这种新的均衡：如果每个人都能以 100 倍或 1000 倍的规模发出个性化的推广邮件，收件箱就会被高质量的垃圾邮件填满，你那套大规模定制的模型，就会与对方那套大规模过滤的模型对话，数量大到没有人类能跟得上。一个常见的玩笑是：如果我的 AI 写邮件，你的 AI 把它总结一遍，那为什么不直接发要点？Lee 目前的经验恰恰相反。生成能力越强，邮件就越像用户本来就会写的样子——长度相当，错误更少，速度更快。数量问题是真实存在的。他认为，社交关系图（social graph）会承担更多的过滤作用：谁把你引荐过来，你与这家公司之前是否有关系。内容越来越容易做出来，关系却做不出来。

被问到谷歌会怎么做时，Lee 以前谷歌员工的身份作答。他团队里曾有 Inbox 的人，Shortwave 创办时，他还向那个团队做过复盘。他尊重这家公司。他也认为，一款背负着 Gmail 历史包袱、用户数庞大、内部目标又相互冲突的产品，很难高质量地快速创新，原因更多在组织层面，技术层面反倒次要。他说，Gmail 在谷歌最重要的任务，是让你登录，好让搜索能与你关联起来；帮你完成工作反倒排在后面。Workspace 只是次要的支柱。在他看来，AI 功能像是上面压下来的指令：接入点什么，完成 OKR 指标。为二十五亿用户的邮件做嵌入会是一笔巨额开销，而想押注这种赌局的人，宁可在 Gemini 上做，也不愿去改造 Gmail 这艘超级油轮。谷歌目前已经有两次对 AI 邮件搜索的尝试，但都不完整：一个是 Duet AI 预览版，他问到的时候还没准备好；另一个是 Bard/Gemini 集成，显然出自 Bard 团队，Gmail 团队并没有参与。