Scribd 旗下拥有 Scribd、Slideshare、Everand、Fable 四个产品，平台上有超过 4 亿份用户上传的 PDF、演示文稿和文档，总页数超过 120 亿页。过去一年，Scribd 用 Gemini 的原生 PDF 理解能力和 Gemini Enterprise 批量预测，对整个用户生成内容语料完成了信任与安全分类，覆盖平台全部文档，耗时数月。

这项工作原本极难规模化。理解一份文档必须同时读文本和图片，且分类要适配所有语言、所有上下文。传统做法是每个政策领域单独训练一个检测模型，意味着要么投入多年的内部工程，要么采购无法匹配 4 亿文档回填成本效益的供应商方案。团队评估了多种现成审核工具和开源模型，但没有一个能在这种规模下达到所需质量。Scribd 高级工程经理 Sachin Sebastian 的表述很直接：每个内容类别的行为都不一样，历史上一类就要一个专门方案，而 Gemini 把这一切压缩成了一个模型、一个提示词、一条流水线。

关键转折在于 Gemini 把 PDF 当作一等输入。它原生接受 PDF，把每页同时当作文本和图像读取，因此一个多模态模型就能同时处理密集文本和图像型演示文稿，完全不需要 OCR、页面渲染或截图基础设施。又因为每页 PDF 都按固定、可预测的 token 数计算，成本随页数线性增长，即使在 120 亿页的规模下也保持可控。Scribd 最终选定 Gemini 2.5 Flash Lite 作为主力分类模型，再用 Gemini 2.5 Pro 作为 LLM 裁判，对整个语料做第二遍一致性验证。团队评估显示，Gemini 的多模态理解能捕捉到纯文本审核接口经常漏掉的视觉政策信号。超过 99% 的语料按原样直接进入模型，没有任何预处理。

执行架构刻意保持简单：文档先放到 Cloud Storage，提交给 Gemini Enterprise 批量预测，结果流回数据平台做下游分析。没有需要运维的推理服务，没有要写的限流逻辑，也没有要管理的 GPU 容量。批量预测价格比交互式定价低 50%，这让 4 亿文档规模的 LLM 分类在经济上变得可行。团队后来又用上了 Gemini Enterprise 的隐式前缀缓存，把静态政策文本放在缓存命中区，在分类质量不变的前提下进一步提升了效率。

处理 4 亿文档本质上是一个吞吐问题。Scribd 直接对接 Google Cloud 工程和产品团队，提前规划回填、区域策略和容量。随着回填推进，Google Cloud 持续把批量吞吐扩展到项目要求，批量任务完成速度远快于预期，大部分时间里 Gemini Enterprise 都不是瓶颈，Scribd 自己的上游管道反而成了瓶颈。Scribd 工程师说，Google Cloud 不是在回工单，而是在共同推进回填，有一段时期 Gemini Enterprise 完成任务的速度超过了 Scribd 自身的产出速度。

这次回填已经变成一个持续项目的基础：新上传内容会走同一条 Gemini 分类管道，语料从定期清理变成持续评估。由于 Cloud Storage + Gemini 批量预测 + 结果入湖仓这套模式在操作上极其简单，Scribd 正把它应用到平台上越来越多的内容理解工作负载。团队的判断是，原本被划为多年、多团队协作的项目，现在只需要一个提示词、一条批量管道和几周运行时间。