300万封邮件、10次LLM调用、5个模型：Shortwave创始人的RAG工程课

Nathan Labenz用了20年Gmail。过去两周，他发现自己开始习惯性打开另一个邮件客户端。

这个客户端叫Shortwave。他本来只是抱着试用心态注册，结果用了两周后，肌肉记忆被改写了。更让他意外的是，这个产品背后没有什么秘密武器，就是5个模型、大约10次LLM调用，和一整套被拆得很细的检索流水线。

他把Shortwave创始人Andrew Lee请到了Cognitive Revolution，聊了一个多小时，把RAG架构从数据导入到最终生成拆了个底朝天。这期节目对正在做LLM应用的开发者来说，信息密度相当高。

从Firebase到Shortwave：两件事促使他做邮件

Andrew Lee不是第一次创业。上一家公司Firebase被Google收购，他在Google待了一段时间，后来赋闲在家。

2019年，他看到两件事，决定再做一家公司。

第一件事是香港的民主抗议。微信被用作控制工具，说了不该说的话，可能有人上门。他原本想，至少西方世界的通信平台是可信的。后来意识到未必。

第二件事更直接。Google关掉了Google Inbox。那是Google自己的下一代邮件产品。Andrew的反应是：如果Google有无限资源、有全球最大的邮件用户群，都不愿意继续投入去探索邮件的未来，那可能得有人来做这件事。

他从小跟父亲在自家地下室运营ISP，管过邮件服务器，对邮件这个联邦制协议有感情。于是他打电话给Firebase的老同事，2020年开始做Shortwave。

第一阶段并不顺利。他们想做协作邮件，帮团队在邮件里协作。推了一年多发现卖不动：想换邮件客户端的人不想同时换掉Slack，想换Slack的人也不想让全公司同时换邮件客户端。获客永远凑不齐两边。

他们掉头，专心做一个个人商务邮件客户端。又花了一年半，把显示、线程、搜索这些基础功能做扎实。这时候大语言模型开始变得可用。

Andrew说，此前每次玩LLM都觉得没到生产就绪的程度，这一次到了。他们做了一个demo，决定全力转向AI。

转过去之后，他们发现了一件事：邮件客户端诞生几十年，邮件里的数据对计算机来说一直是不可访问的。你可以搜索关键词，可以自己读，但你不能问邮件客户端一个问题然后让它回答。几GB的非结构化文本，一直只是占硬盘的东西。

这是Shortwave整个RAG架构的起点。

服务器存下所有邮件，这是地基也是天花板

Andrew承认，他们在这一点上运气不错。做协作邮件时，架构要求所有数据存在服务器端、实时同步。这个架构后来成了AI功能的基础设施。

大多数竞品是客户端架构，邮件只存在本地。Shortwave在用户注册时就把全部邮件拉到服务器，重新索引。这个过程按邮箱大小从几分钟到几天不等。Andrew说，有人邮箱里有300万到500万封邮件。

索引分两条路：Elastic做全文搜索，Instructor XL做嵌入，向量存进Pinecone。用户一注册，系统从最新邮件往回倒着拉取，用户能看到邮件一封封出现在收件箱里。

这是重活，也是竞争壁垒。Andrew说得很直白：这很贵，我们要存所有邮件的副本，要重新索引一切。但有了这份数据，后面做嵌入、做向量检索、跑GPU集群，都比从零开始的团队容易得多。

很多AI应用卡在第一步：拿不到高质量、结构化的历史数据。Shortwave为了协作功能提前三年把地基打好了，AI浪潮来的时候，直接在上面盖楼。

一条查询的七道工序

用户敲一句「帮我找一下我发给Nathan的那个链接」，Shortwave后台发生的事可以拆成七步。

第一步，工具选择。一次LLM调用，但prompt里塞了大量上下文：用户是谁、现在几点、当前打开的是哪封邮件、邮件前几段写了什么、收件箱里选中了什么。Andrew举了个例子：如果当前线程在聊超级碗，用户问「比赛几点」，系统能判断出问的是超级碗。脱离上下文，这个问题没法回答。

这一步返回一个数据源数组。可能是当前线程全文，可能是用户设置，可能是历史邮件。大约有六七种工具可选。

第二步，查询重构。如果选了历史邮件检索，系统会把你那句带代词、带相对时间的话，改写成一句独立完整的问题。代词换成具体人名，相对时间换成绝对时间。

第三步，特征提取。一个小而快的模型从重构后的查询里抽取搜索线索：提到了哪个标签、哪个联系人、哪个时间范围、哪些关键词。这几个抽取是并行跑的。

第四步，并行检索。传统Elastic搜索跑关键词、标签、时间范围，Pinecone跑KNN向量搜索。两边同时进行。

第五步，启发式排序。把两堆结果合在一起，加一层经验规则。比如新鲜度偏差：问「我的航班怎么延误了」，大概率是最近讨论过的那次航班，老邮件会被降权。

第六步，重排序。用一个交叉编码器给每封邮件打分，判断这封邮件对回答这个问题有多大帮助。Andrew说，因为有了这个重排序模型，前面的向量检索不需要太精确，可以故意多召回，把网撒大，让交叉编码器来筛。

第七步，最终生成。取分数最高的30到50封邮件，连同所有其他工具的数据，一次性发给GPT-4 Turbo，让它给出答案。

Andrew强调了一个设计决策：他们试过多步规划的agent，每一步的输出喂给下一步。模型在每一步犯的错会沿着链条累积，质量达不到要求。所以他们换了个思路，目标是最终组装出一个包含所有必要信息的prompt，然后只调一次GPT-4。

所有复杂的工程，都花在「怎么确定这个prompt里该放什么」上。这一步看起来像agent，实际上是为了单次生成服务的。

六个模型各干各的活

一次AI助手查询，串行5次LLM调用，特征提取还有5个并行调用，加起来大约10次。这还不算用户注册时预先做好的几百万封邮件嵌入。

生产环境跑6个模型：

• GPT-4 Turbo：AI助手最终回答
• GPT-3.5：自动补全
• 微调GPT-3.5：自动补全的格式和事实复制
• Mistral：邮件摘要，跑在自己的基础设施上
• Instructor XL：嵌入模型，开源
• 交叉编码器：重排序，基于微软开源数据训练

Andrew对Mistral评价很高，说可能会用在更多地方，因为能跑在自己的机器上，成本和延迟都可控。

微调GPT-3.5：删掉一段，让模型学会补全

自动补全这个功能值得单独说。用户在写邮件时，光标停在输入框，系统自动给出续写建议。

最初他们用GPT-4，质量好但太慢。换成GPT-3.5，速度够了但不够聪明，格式经常出错：该给一句话的时候给两段，该空格的地方不空格，有时候把用户写的内容重复一遍再续写。

他们决定微调GPT-3.5。数据集来自创始人自己的邮件，没有用任何客户数据。做法很巧妙：拿一封真实发出去的邮件，删掉其中一段，让模型学着补全被删掉的那段。

这样模型学到的是格式、长度、语气，还有一件更微妙的事，怎么从上下文里复制事实。

Andrew举了个例子：他们公司的WiFi密码写在某封邮件里，人在写邮件时提到「密码是」，模型应该能从上下文里把密码抄过来。微调之前，GPT-3.5做不到这一点。微调之后学会了。

他们还往训练集里塞了一些人工构造的案例，专门纠正模型表现不好的场景。

Andrew说，让他意外的是泛化能力。他担心模型会照抄训练邮件，实际没有发生。模型学到了任务本身，运行时结合RAG检索到的用户真实邮件，能生成符合用户风格的内容。

Nathan分享了Waymark的经验：在微调数据里加入思维链推理，让模型学会「怎么想」，效果大幅提升。Andrew说他们没这么做，但值得一试。

自动补全的检索也分两路：一路找用户以前回复类似线程时写的邮件，一路把用户正在写的草稿嵌入，找相似的历史邮件。两路结果一起放进prompt，让微调后的模型自然续写。

为什么不用思维链，为什么选Pinecone

Nathan问，这么多步骤，为什么体验还这么快。

Andrew给了几条原则：能并行就并行；能流水线就流水线，交叉编码在数据库出结果的同时就开始跑，不等全部结果到齐；能用快模型就用快模型；摘要在GPU上跑；输出保持简短。

还有一个反直觉的选择：大部分场景不用思维链。思维链在答案之前生成，用户要等它吐完才能看到答案。性能损失比推理收益更值钱。他们只在少数场景用。

向量数据库选了Pinecone，关键功能是命名空间。Shortwave有大量用户，每个用户的邮件是一个独立集合。Pinecone可以在不给性能惩罚的情况下做多租户隔离。

PGVector的问题在实现顺序。一次查询先跑KNN找到近邻，再按用户ID过滤。所有用户的向量混在一张表里，要先扫过大量向量才能筛出目标用户的数据，速度会掉。变通办法是给每个用户建一张表，但数据库管理会变得很麻烦。

Andrew的建议：选向量数据库前先想清楚要多少个命名空间，一个用户一个、一个公司一个、还是全局一个；再想清楚文档数量和单文档大小。大多数做RAG的团队文档量在几千到几十万级别，PGVector可能够用。Shortwave这种单用户几百万封邮件的场景才需要专门方案。

嵌入模型选了Instructor XL，开源、便宜、快、向量维度中等。这里有一个成本权衡：向量越大越精确，但存储和嵌入成本越高。Shortwave存了几百万封邮件，查询频率相对低，所以他们选了中等维度。精度损失靠「多召回+重排序」补回来。

Nathan提到OpenAI新出的嵌入模型支持可变长度向量，小尺寸捕获大部分信息，大尺寸增加分辨率。Andrew说这个思路很聪明，因为不同应用的最优平衡点不一样。

Andrew还提到向量数据库行业的一个趋势：计算和存储分离。现在的产品把两者绑得很死，如果用户是存储多、计算少，或者计算多、存储少，成本结构不理想。Pinecone刚推出托管服务，在往这个方向走。

明天就能用的五条结论

第一，先做通用助手，观察真实使用，再收窄优化。Shortwave一开始就做了一个ChatGPT式的侧边栏，什么都能问，UX不精致，但拿到了用户行为的真实数据，知道该往哪优化。他们后来做的AI自动补全，就是观察出来的高频场景。

第二，把工程预算花在「往prompt里放什么」，少花在多步agent编排上。多步链条的错误会累积，单次大prompt加高质量检索更稳。如果你的应用还在纠结要不要做复杂agent，先试试把所有信息塞进一个prompt，看效果够不够。不够再拆。

第三，嵌入向量选中等维度，靠召回数量和重排序补精度。算清楚存储成本、嵌入成本和查询成本哪个占大头。存几百万文档、查得不频繁，就选小向量；查得频繁、精度要求高，就选大向量。没有统一答案。

第四，微调的数据可以从团队自己的真实工作里造。删一段让模型补全，这个办法不需要标注团队，不需要客户数据，就能教会模型格式、语气和事实复制。Andrew用创始人自己的邮件就做出了生产可用的微调模型。

第五，延迟优化按优先级排：并行、流水线、换快模型、砍思维链。用户感知的是首字延迟，不是总计算量。能提前跑的就提前跑，能同时跑的就同时跑，能不用思维链就不用。省下来的时间比多出来的推理更重要。

「我们不是AI研究员，我们是软件工程师。把正确的组件用胶带粘在一起，接上传统基础设施，做成一个真正能用的产品。」

Andrew这句话大概概括了Shortwave的全部方法论。模型是别人的，架构是自己搭的。在LLM应用层，工程能力比模型能力更稀缺。