专业书籍精读 · Generative AI System Design Interview · 第 2 章
Generative AI System Design Interview · Ch 2 · Ali Aminian, Hao Sheng & Alex Xu · 2024
你在 Gmail 里敲邮件，打到一半，光标后面会浮出一行浅灰色的字，正好接着你想说的话——按一下 Tab 它就变成你的正文。这一章讲的就是这套「边打边猜」的系统怎么造出来。
把它想成一个站在你身后的助手：你写一个字，他就凑上来递半句话。他要有用，得同时做到三件事——猜得对、递得快、该闭嘴时闭嘴。三件里最难的不是第一件，是第二件。 你手指落下去到抬起来大概就是零点几秒，他要是想半天才开口，你早就自己打完了，他递得再漂亮也是废话。
老式的输入联想只盯着你正在打的那一个词，照着词典猜完它就收工——它根本不知道你在写什么事。所以它能帮你补完「明天」，但补不出「明天上午十点方便吗」。要想续得像人话，它得先读懂这封信的来龙去脉：标题写的什么、上一封信人家问了什么、你这半句已经说到哪了。可「读懂」是要花时间的，而这套系统最缺的就是时间。
三招。
第一，把背景先算好存着。 邮件标题和上一封来信在你打字的整个过程里根本没变，所以没必要每敲一个键就重读一遍——先读一次，把读完的「理解」暂存起来，后面每次只处理你新敲进去的那几个字。这一下就把大部分活儿省掉了。
第二，个子要小。 同样聪明程度下，大模型慢、小模型快；当快慢直接决定有没有用时，宁可选那个笨一点但来得及的。这和「模型越大越好」的直觉正好相反。
第三，只说最有把握的那几个词，而且宁可不说。 它不会试图替你写完整封信，只递三五个词；心里没底的时候干脆不出声。因为递错一次的代价，比不递高得多——你得停下来看一眼、判断、再划掉，思路就断了；而它没递，你顶多是没被帮上忙。
因为只在最有把握时出声，它多数时候是沉默的；而且它见过太多客套话，递给你的往往是最平均、最像模板的那一句——好用，但会把你的邮件慢慢磨得没有个人味道。
这类「边打边猜」的产品，真正的主角不是模型有多聪明，而是一条几十毫秒的时间线：它先决定了模型只能多大、能想多久、能说多少个词，剩下的空间才轮到质量去争。再加一条做产品的常识——当出错比沉默更烦人时，就该让系统学会闭嘴。
想进到具体机制、记号和示意图？ → 切到精读版
你以为智能撰写（Smart Compose）考的是「模型能不能猜对你下一句想说什么」，其实考的是「能不能赶在你敲下一个键之前把话递到」。这是全书十道真题的第一道，也是最干净的一道：延迟预算先动手，把模型规模、模型形态、解码宽度乃至「这次要不要出声」全部钉死，质量只能在剩下的空间里争。 它还示范了一条产品原则：当误建议的代价远高于不建议时，系统必须学会闭嘴。
N 个 token 就是 N 次前向计算。k 条候选往下扩，比每步只取最高分（贪心）质量好，但算力大致乘 k。N 个词与用户真正写下的前 N 个词逐字比对，全中才算命中。这是《Generative AI System Design Interview》（Aminian、Sheng 与 Xu，2024）Part II 十道真题的第一道，直接套用 Ch1 的七步框架，但把每一步都压在一条极窄的延迟预算上。它上承 Ch1「输出长度同时等于成本和延迟」那条硬约束，下启 Ch3 机器翻译——同样是序列生成，但翻译允许几百毫秒、能上大模型，两章对照正好量出「延迟预算」能把设计拉开多远。对应现实里的 Gmail 智能撰写、代码补全、输入法联想这一整类按键级实时生成产品。
写邮件有大量重复劳动：问候、约时间、致谢、告别，这些句子人人都在重写。老式自动补全只盯当前这一个词做词典匹配、不看语境，所以补得出「明天」，补不出「明天上午十点方便吗」。要续得像人话，就必须把整封信的背景读进来。
难点正在这里：背景要读，但没时间读。它是按键级触发的——每敲一个字符，上一条建议就作废、要重出一条。人的连续击键间隔常在 100–200 毫秒量级，留给「读背景 + 想 + 出词」的整段预算也就百毫秒上下。不解决会怎样？一个 300 毫秒才出结果的补全系统，在工程上完全正确，在产品上等于不存在——建议永远落在用户已经打完的字后面，只会变成闪烁的噪音。这一章的全部张力由此展开。
第一步不是选模型，是把「帮我写邮件」定义成输入输出都写死的预测任务。输入是几段背景拼成的一条上下文：邮件标题、同线程上一封来信、收件人与时间等元信息、已经打出的这半句。输出不是整封邮件，而是接着往下的几个词。
「只续几个词」是刻意的产品决策，不是能力不足：续得越长，成本与延迟按 token 数线性上涨，而猜对整段的概率随长度快速下滑——一条十五个词的建议中间错一个，用户就得全段删掉重来，净收益为负。短建议的好处是错了也便宜。
把背景喂进去有两条路。seq2seq（编码器–解码器）用一个编码器专门读背景、解码器再据此生成，两段计算各司其职，质量上限通常更高——机器翻译就是这么做的。单塔语言模型则把所有背景直接拼成一长串前缀，让同一个模型顺着往下续。
按纸面质量前者更漂亮，按延迟后者赢得干脆，原因是缓存：用户打字的整个过程里，标题和上一封来信一个字都没变。单塔前缀天然允许把已算过的部分留在 KV 缓存里，每次击键只为新增的几个 token 付钱；双塔结构则更难复用这份中间结果。一个能把九成输入变成「上次算过的」的架构，在这条预算上赢面远大于一个每次重算的更好架构。
解码的每个旋钮都直接换算成毫秒。束宽 k：同时扩展 k 条候选质量更稳，算力却大致乘 k——这条预算里 k 只能取很小的个位数，甚至退到贪心。最大长度写死，顺便杜绝跑飞。提前停：续到句号或一个自然短语就收，别硬凑长度。
一个容易漏掉的细节：用户常停在半个词中间。生成必须与已输入字符严格前缀相容——续写的第一个 token 要接得上那半个词，否则屏幕上会出现拼错的灰字；实现上通常在解码时按已输入前缀过滤候选。
这一章最值得带走的产品判据在这里。显示一条错建议和不显示，代价完全不对称。 错建议要用户停下来读一眼、判断、否决，还打断了正在组织的句子；不显示则只是「这次没帮上忙」，用户根本不会察觉。既然误报贵、漏报便宜，置信度阈值 τ 就该故意调高，宁可让覆盖率难看。
「模型分数高」和「用户会接受」还不是一回事，所以现实做法是在语言模型分数之上再挂一层触发判定，融合置信度、上下文类型（回复邮件比新写邮件好猜）、用户历史接受率等信号。只报接受率是可以作弊的：阈值拉到极高、一天只出十条建议，接受率能到九成以上，产品价值却近乎为零。
训练语料是真实用户的邮件，于是有了别章没有的约束：没有任何工程师可以逐条看数据。整条流水线只能在「看不见」的前提下工作——自动做语言、长度与质量过滤，剔除模板与机器邮件并去重，只用聚合统计做数据画像，错例分析只能落在合成数据或明确授权的语料上。
更硬的一条是记忆风险：模型会背下训练集里的高频串，而邮件里的高频串恰恰是电话、地址、验证码。所以数据侧要剔除敏感信息，输出侧还要再拦一道——绝不允许把疑似个人信息当作建议吐给另一个用户。个性化能明显提升接受率，但要为用户单独持有模型或适配器，隐私与成本都得重算。
离线用困惑度与 ExactMatch@N（建议的前 N 个词是否与用户真正写下的逐字相同）：便宜、可回归，把关上线前的质量够用；但它们只认「和真人写的一模一样」，同义改写判零分——而用户对同义表达是完全接受的。
线上才是真相：接受率、覆盖率、每次接受节省的字符数，外加必须盯的 p90 延迟。四个数要一起看：延迟一涨接受率就跌（建议来不及），阈值一动接受率与覆盖率就反向走——单看任何一个都会读出错误结论。
表 1 · 建模形态：同一份背景，三种喂法
| n-gram / 词典联想 | seq2seq 编码器–解码器 | 单塔语言模型（拼前缀） | |
|---|---|---|---|
| 看得到多少语境 | 只看当前词 | 完整背景，编码器专门优化 | 完整背景，全塞进前缀 |
| 每次击键的开销 | 近乎为零 | 两段计算全量重跑 | 只算新增 token，其余命中缓存 |
| 质量 | 只能补完单词 | 纸面上限最高 | 略逊，但差距可接受 |
| 代价 | 产品价值有限 | 难塞进百毫秒预算 | 前缀越长越贵，要主动裁剪背景 |
表 2 · 延迟从哪里省：四招的收益与代价
| 换更小的模型 | 换加速硬件 / 编译 | 缓存不变的前缀 | 压缩解码（小束宽 + 短长度） | |
|---|---|---|---|---|
| 省在哪 | 每次前向的算力 | 同样算力跑得更快 | 把大部分输入变成「算过的」 | 少算几步、少开几条分支 |
| 量级 | 可差数倍 | 可差一个量级 | 取决于背景占比，常是大头 | 大致按 k 与长度线性 |
| 代价 | 质量直接下降 | 成本高、可移植性变差 | 内存上升，要处理缓存失效 | 候选单一，放弃长建议 |
| 先用哪个 | 怎么调都超时才动 | 流量稳定、值得投入时 | 永远先做：不损质量 | 尾延迟不达标时的最后一刀 |
表 3 · 触发阈值往哪调
| 阈值调低（多出声） | 阈值调高（少出声） | |
|---|---|---|
| 覆盖率 | 高 | 低 |
| 接受率 | 被稀释、下滑 | 好看，但可能是沉默刷出来的 |
| 用户体感 | 灰字不断闪烁，打断写作 | 偶尔出现，几乎每次都对 |
| 适合 | 回复模板邮件等可预测场景 | 默认姿势，尤其是新写邮件 |
这一章给的是整个「实时补全」品类的通用解法：Gmail 智能撰写、Copilot 的行内补全、输入法联想，骨架完全一样——按键触发、去抖、缓存不变的上下文、小模型短生成、阈值决定出不出声、线上看接受率。
它在面试里还有个特别用处：这是少数能让你正当说出「我选一个更差的模型」的题目。把「因为预算是一百毫秒，所以我放弃质量更高的双塔结构」讲成一条完整推理链，比背任何架构名词都有说服力。
100ms 内以免用户察觉，报告的 p90 约 60ms；论文写明同等条件下 LSTM 的单次建议延迟明显低于 Transformer，并把推理搬上 TPU（配合 XLA 编译）——普通 CPU 上平均服务延迟是几百毫秒量级，不可接受。这是「延迟预算先动手」最直接的原始证据。（Chen 等，KDD 2019；arxiv.org 与 dl.acm.org 在本站运行环境被出口代理拦截，故只留文字出处）TTFT 降 35%、前缀缓存命中率从 35% 翻倍到 70%。印证了缓存与路由是「不损质量就能拿到的延迟」。Google Cloud Blog「Five techniques to reach the efficient frontier of LLM inference」↗① 这是十道真题的第一道，示范的是：延迟预算先动手，质量在剩下的空间里争。
② 按键级触发意味着上一条建议随时作废；整段预算（含网络往返）只有百毫秒量级，超预算的建议不是慢，是废品。
③ 任务定义：输入 = 标题 + 上一封来信 + 元信息 + 已打出的半句，输出 = 接着往下的三五个词——短建议错了也便宜。
④ seq2seq 质量上限更高，单塔 LM 却因前缀可缓存而赢：能把大部分输入变成「上次算过的」，比架构漂亮值钱。
⑤ 省延迟四招按优先级：缓存（不损质量）→ 换硬件 / 编译 → 压缩解码（小束宽、限长度）→ 最后才换小模型（直接损质量）。
⑥ 误报与漏报代价不对称：错建议打断写作，不出声用户无感——阈值天然偏保守，系统要学会闭嘴。
⑦ 前缀相容：用户常停在半个词中间，续写的第一个 token 必须接得上。
⑧ 离线指标（困惑度、ExactMatch@N）只认逐字相同，同义改写判零分；线上四个数——接受率、覆盖率、节省字符数、p90 延迟——必须成组看。
⑨ 训练数据是私人邮件：没人能逐条看，清洗与排障全靠自动化与聚合统计，还要防模型背下电话、地址这类高频敏感串。
⑩ 安全边界有时是「不做」而非「做对」——性别代词那类改不可靠的错误，正当处理是整类关掉。