Scribd 于 2026 年 9 月 24 日公开复盘：用 Gemini 原生 PDF 输入与批量推理，在数月内完成 4 亿份文档的信任与安全分类。 这一段落在企业级 AI 与数据系统在真实客户环境里的落地交付：前置部署 Forward Deployed Engineer（FDE）在客户现场真正要解决的，不是模型能不能分类，而是存量语料怎么在不建 OCR 管道、不运维推理服务的前提下批量重跑一遍，并且跑完之后还能持续跑。这篇复盘要解决的问题，是 Scribd 的「信任与安全」（trust and safety）分类。 这篇复盘由 Google Cloud 客户经理 Travis Martin 与 Scribd 高级工程经理 Sachin Sebastian 联合署名。页面上方署名日期写 2026 年 9 月 25 日，页面内 JSON-LD 的 datePublished 字段写的是 2026-09-24，正文只笼统说整个回填发生在过去一年之内。Scribd, Inc. 旗下有四个产品：Scribd、Slideshare、Everand 与 Fable，本次回填覆盖其中前两个。 一、旧做法是每类政策各建一个专用模型，代价是多年工程与不匹配的单位经济 前置部署 Forward Deployed Engineer（FDE）接到这类需求时，第一个要回答的问题是：给每一类政策各建一个检测模型，还是找一个能覆盖全部政策的模型。Scribd 的描述是，每一类内容的行为都不一样，历史上每一类都需要自己的专门方案，而理解一份文档要同时读它的文字与图像、要覆盖所有语言与语境，没有单点方案能干净地平移过来。 旧做法的两条路都被否掉了。自研路线要投入多年工程；厂商路线的问题是专用方案的单位经济与 4 亿份文档级的「全量回填」不匹配。团队评测过多个现成的内容审核工具与开源模型，结论是它们在所需规模上达不到要的质量。 前置部署 Forward Deployed Engineer（FDE）在这类项目上最常见的失败模式，是把问题定义成一次选型问题：只要模型选对，回填就自动成立。Scribd 的复盘反过来说明，选型只占整件事的一小部分，真正的成本在把语料喂进去的那一段管道，以及跑完之后怎么持续跑。 二、转折点是把语料按它实际存在的样子喂进去 旧路线的前提是先把文档变成模型能读的东西：抽文本、渲染页面、必要时截图。新路线的起点是承认 Gemini 把 Scribd 的语料当作 PDF 处理——原生接受 PDF 输入，把每一页同时当作文本与图像读，于是一条多模态（multimodal）模型就能同时评估密集文本文档与图片型演示文稿，中间不需要 OCR、也不需要「分页渲染」（page rendering），更不需要单独的截图（screenshotting）基础设施。这也是 FDE 在现场最容易踩空的一段：多数团队的存量语料并不是干净的 PDF。 量化收益是超过 99% 的语料按站上原始形态直接送入，没有经过任何预处理。成本可控的机制是模型把每个 PDF 页处理成固定且可预测的 token 数（fixed, predictable token count），成本因此随页数线性增长（costs scale linearly），即使总量到 120 亿页也保持在低位。 必须点明适用边界：99% 这个比例是 Scribd 这个以 PDF 与演示文稿为主的语料的性质，不是普适数字。语料里扫描件、图片型扫描文档占比高的团队，OCR 与分页渲染这一层省不掉，这条配方不成立。 三、执行模型被刻意做简单：对象存储加「批量推理 batch prediction」加数据平台 具体流程是三步：文档先暂存在 Cloud Storage，提交给 Gemini Enterprise 的批量推理（batch prediction），结果回流到团队的数据平台做下游分析。这套打法在原文里被称为对全语料的一次 corpus-wide backfill，中文可以译成全量回填。这样做的直接收益是不需要运维任何推理服务、不需要写限流逻辑、不需要管理 GPU 容量。对 FDE 来说，这一步省掉的是最容易被低估的那部分运维面。 经济性来自批量定价：批量推理相对交互式定价低 50%，Scribd 的说法是这个折扣才让 4 亿份文档规模的大模型分类在经济上成立。但文章只给了相对折扣，没有给绝对单价，也没有给这次回填的总花费金额。用这条配方做预算时必须回自己账号的批量定价页取数，不能拿 50% 直接推总额。 还有一条容易被忽略的收益：分类结果回流到数据平台之后，就落进了团队已有的治理与访问控制边界。把语料导出到外部 AI 工具的路线会复制一份数据、破坏新鲜度，并且把数据带出治理范围。 四、两段式模型分工：便宜模型做工作马，强模型做全量第二次校验 在基准测试了多个模型家族与版本之后，团队选定 Gemini 2.5 Flash Lite 作为分类工作马（classification workhorse），再用 Gemini 2.5 Pro 充当 LLM judge，对整个语料做完整的第二次「一致性校验 consistency pass」，用来验证输出质量。团队称在他们的评测里，多模态理解抓到了纯文本内容审核端点习惯性漏掉的视觉政策信号，这是选型的主要理由。FDE 在这里要多问一句：judge 这一段的预算由谁出，能不能单独设上限。 两段式不是免费午餐：judge 这一段会在全量语料上再跑一遍推理，推理次数翻倍，而文章没有给出两段式相对单段式的成本倍数，也没有公布多模态端点与纯文本端点在同一个测试集上的分项对比数字。 五、回填跑起来之后再叠一层「前缀缓存 implicit prefix caching」 团队改造了提示词结构，让固定不变的政策文本落在能被缓存命中的位置，在分类质量不变的前提下进一步提高效率。这一层的适用条件很窄：只有当提示词里有一段所有请求都相同、且位置足够靠前的静态文本时才有收益；逐请求变化的内容一旦放进前半段，缓存命中率就会掉下来。FDE 落地时最常见的错误，就是把动态内容放在提示词开头，缓存因此从不命中。 六、文章承认的真正瓶颈不在模型侧，在上游管道的「分页渲染」与 OCR 那一段 前置部署 Forward Deployed Engineer（FDE）读这一段时，要把它当成排障顺序而不是平台宣传：瓶颈被搬走了，但没有被消除。 这篇复盘里比较少见的结论是吞吐归属：批量作业开始后完成速度远快于项目预期，在运行的大部分时间里 Gemini Enterprise 根本不是瓶颈，Scribd 自己的上游管道才是。 这句话的价值不在于夸平台快，而在于给出排障顺序。做同类回填之前，先量自家上游的产出速率——把语料从存储取出、必要时做 OCR 或分页渲染、再组装成批量请求这一段，往往比模型推理慢。FDE 做容量规划时，第一件该量的就是这个数，而不是先量模型。 另一个前提是容量不是自助获得的：Scribd 团队直接对接 Google Cloud 的工程与产品团队，提前规划了区域策略并让上线前所需吞吐到位。没有这条对接渠道的团队，不应假设能拿到同样形状的吞吐曲线。 七、回填完成不等于项目结束，增量被接回同一条管道 新上传的内容会走同一条 Gemini 分类管道，语料因此从「周期性清洗」变成「持续被评估」。团队还把「对象存储里的 PDF 加批量推理加结果落数据平台」这个模式复用到其他内容理解类负载上，理由是它在运维上足够简单。FDE 应当把这条增量管道写进交付范围，而不是留成售后的口头承诺。 团队对整件事的总结是一句可以直接引用的对比：过去被归类为多年、多团队的工作，现在是「一段提示词、一条批量管道和几周的运行时间」。 八、可核实的数字集中列一次 语料规模为 400M+ 用户上传文档、12B+ 页文本与图像；全量回填周期为「数月」；原生格式直入比例为超过 99%；批量价相对交互价低 50%；两段式模型为 Gemini 2.5 Flash Lite 加 Gemini 2.5 Pro；推理服务的运维量为零。文章没有公布分类准确率、精确率、召回率或人工抽检通过率，也没有公布总成本金额、团队人数与单页单价。FDE 引用这组数字时，要把口径一起引，不能只引 4 亿份文档这一个规模数。 九、局限：文章自己承认的一条与我方补充的八条 文章自己承认的一条是瓶颈归属：Gemini Enterprise 在大部分运行时间里不是瓶颈，上游管道才是。也就是说这条配方把瓶颈从模型侧搬到了数据准备侧，并没有消除瓶颈。 我方补充的第一条是质量没有被量化：全篇没有分类准确率、精确率或召回率，质量结论建立在团队自己的评测之上，测试集构成、样本量与判定口径都没有公布。 我方补充的第二条是成本口径不完整：只给了批量价相对交互价低 50% 这个相对值，既没有绝对单价，也没有这次全量回填的总花费，做预算时不能直接外推。 我方补充的第三条是时间口径不精确：「数月」与「几周」都是量级说法，不是可复算工期。 我方补充的第四条是两段式的成本外溢：第二次「一致性校验」在全量语料上再跑一遍推理，文章没有给出这部分增量成本。 我方补充的第五条是格式覆盖有限：99% 这个「原样送入」读数来自 Scribd 以 PDF 与演示文稿为主的语料，扫描件、图片型扫描文档与音视频语料都不在覆盖范围内。 我方补充的第六条是厂商协作前提：区域策略与容量是 Google Cloud 与 Scribd 共同规划的，不是纯自助流程，小团队照搬时这一段最容易落空。 我方补充的第七条是模型版本没有锁：文章点名 Gemini 2.5 Flash Lite 与 Gemini 2.5 Pro，但没有给出版本固定、灰度与升级回退的做法。 我方补充的第八条是发布时间口径不一致：页面署名日期写 2026 年 9 月 25 日，页面内 JSON-LD 的 datePublished 写 2026-09-24。引用时应以 24 日为口径，并注明两处不一致，避免不同稿件互相打架。 十、实用结论：谁该行动、六步怎么做、什么时候别照做、怎么回滚 前置部署 Forward Deployed Engineer（FDE）可以把这篇复盘当作一份存量语料的批量重跑配方。该行动的是三类人：手上有千万份级以上存量文档、需要全量重跑一次审核或分类的交付团队；正在为「每类政策各建一个专用模型」编预算的团队；把内容审核成本按人工工时定价的平台方。 可以照着做的六步。第一步，先算自家语料的原生格式直入率：把语料按原始格式喂给多模态模型，统计不需要 OCR 与分页渲染的比例。Scribd 的读数是超过 99%；如果自家比例明显更低，先补 OCR 管道，别指望模型替掉这一层。第二步，把执行模型从在线接口换成批量推理：文档落对象存储、批量提交、结果回流数据平台，换掉推理服务运维、限流逻辑与 GPU 容量管理；代价是只能异步，不适合实时接口。第三步，做两段式分工：便宜模型做分类工作马，强模型做 LLM judge 的「一致性校验」，并先给第二段单独设预算上限。第四步，把政策文本这类固定前缀挪到提示词最前面，启用前缀缓存，让静态部分命中缓存。第五步，上线前先量自家上游产出速率，并提前与云厂商对齐区域与容量计划。第六步，回填一结束就把增量接进同一条管道，让它从周期性清洗变成持续评估。 适用条件要写清楚：语料以模型原生支持的格式为主；分类或审核标准能写成一段所有请求都相同的静态文本；业务能接受批量作业的异步延迟；已有对象存储与数据平台。这三条里有一条不成立，配方就要改造后再用。 回滚与退出方式分三层。批量推理本身是无状态的一次性作业，回滚靠保留上一版分类结果的落库快照，用同一批文档重跑新提示词做比对，不一致就切回旧结果。前缀缓存只改提示词结构，回滚是把静态文本从提示词头部移回原位即可。如果两段式的总成本超出预算，先砍掉 judge 那一段，用抽样人工复核替代，保留第一段分类不动。 最后一条判断规则：这篇复盘里的 50% 是相对折扣，不是绝对价格，也不是节省总额。把它当报价依据之前，先拿自己账号的批量定价乘上自己语料的页数，实算一遍。如果算出来的每页单价高于自己做人工抽检的单价，这条配方就不该上。 原始来源： - https://cloud.google.com/blog/topics/customers/scribd-inc-classifies-millions-of-documents-on-gemini-enterprise/ - https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/capabilities/batch-inference - https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/context-cache/context-cache-overview