Scribd, Inc. 在过去一年中，使用 Gemini 的原生 PDF 理解能力和 Gemini Enterprise 批量预测功能，对其整个用户生成内容库进行了信任与安全分类。据 Google Cloud 博客披露，此次处理覆盖了 Scribd 和 Slideshare 平台上超过 4 亿份用户上传文档、总计逾 120 亿页的文本与图像，并在数月内完成了全库回填。
原生 PDF 输入取代传统预处理
Scribd, Inc. 是 Scribd、Slideshare、Everand 和 Fable 四款产品的母公司。在 Scribd 和 Slideshare 上，数亿份用户上传的 PDF、演示文稿和文档需要接受合规审查。传统的分类方式要求针对每个政策领域开发专门的检测模型，或者依赖无法适应 4 亿级文档规模的第三方方案。
Scribd 高级工程经理 Sachin Sebastian 表示，团队评估了多款现成的审核工具和开源模型，但均未在所需规模下达到质量要求。Gemini 的优势在于将 PDF 作为一等输入格式，直接读取每一页的文本和图像，无需构建 OCR、页面渲染或截图管线。这使得超过 99% 的内容库可以按原始状态直接处理。由于每页 PDF 以固定且可预测的 token 数量进行处理，成本能够线性扩展。
在模型选择上，团队经过基准测试后采用 Gemini 2.5 Flash Lite 作为分类主力模型，并使用 Gemini 2.5 Pro 作为 LLM 评判者，对全库输出进行第二轮一致性校验。在多模态理解评估中，Gemini 捕捉到了纯文本审核端点通常会遗漏的视觉策略信号。
批量预测与成本控制
执行流程被设计为尽可能简单：文档暂存于 Cloud Storage，提交至 Gemini Enterprise 批量预测，结果回流至数据平台供下游分析。整个过程无需维护服务基础设施、编写速率限制逻辑或管理 GPU 容量。
Gemini Enterprise 的批量预测定价比交互式定价低 50%，这使大语言模型分类在整个内容库规模上具备经济可行性。团队随后启用了隐式前缀缓存，通过重构提示词让静态策略文本命中缓存，在不损失分类质量的前提下进一步提升了效率。
吞吐量协作与后续应用
处理 4 亿份文档本质上是一个吞吐量问题。Scribd 团队直接与 Google Cloud 的工程和产品团队协作，规划回填计划、制定区域策略并提前准备算力。随着回填任务加速，批量作业的完成速度远超预期，在大部分运行时间里，瓶颈出现在 Scribd 自身的上游管线而非 Gemini Enterprise。
此次全库回填现已成为持续性项目的基础：新上传的内容将通过同一套 Gemini 分类管线进行处理，使内容库保持持续评估而非周期性清理。基于“Cloud Storage 存放 PDF、Gemini 批量预测、结果进入 lakehouse”这一模式在运维上的简洁性，团队正将其应用于各平台日益增多的内容理解工作负载。
Sachin Sebastian 称，该项目改变了团队的路线图规划方式，原本被归类为跨团队多年期工程的任务，现在可以通过一个提示词、一条批量管线和数周运行时间来完成。