压缩 PDF 体积的权衡取舍

 

{
"name": "deep-research",
"args": "PDF 提交给多模态大模型（如 Gemini）做内容分析（例如合规审核/OCR/内容理解）之前，业界有哪些\"压缩\"或体积/token优化的最佳实践？具体针对场景：Spring Boot 后端服务，把 PDF 原始字节（Part.fromBytes, mimeType=application/pdf）整份直接喂给 Google Gemini API 做多模态理解（不是纯文本提取，需要保留图文版式/图片内容用于视觉违规检测）。现状：PDF 文件较大（示例文件约 9MB），直接全量上传。\n\n需要研究并给出结论的问题：\n1. Gemini File API / inline data 对 PDF 输入本身有没有官方的大小限制、页数限制、以及计费方式（token 计算是按页還是按字节）？大文件是否官方推荐用 Files API 而非 inline bytes？\n2. \"压缩 PDF\" 在这个场景下具体可以指哪几种不同层面的优化，各自的利弊：\n a) 传输层面的通用文件压缩（gzip/zip 整个 PDF 再解压后依然是原始 PDF 给模型，对模型侧 token 消耗没有帮助，只省网络传输）\n b) PDF 内部图像重采样/降低分辨率/转换重新编码（用 Ghostscript/pdftoppm/PDFBox/pikepdf/qpdf 等工具在服务端预处理，减小文件体积，同时可能保留足够的视觉细节供大模型识别违规内容）\n c) 页面拆分/裁剪/只提交子集页面（比如只提交需要审核的页面范围，通过页数或关键词预筛选）\n d) 将 PDF 转成图片序列（每页转 PNG/JPEG）分别按图片理解 API 提交，而非整份 PDF 走 document understanding 通道——是否有该图片序列相较于原生 PDF 通道在 token 消耗、坐标定位能力（box_2d）、保真度上的实际差异？\n e) 分辨率/DPI 折衷点：大模型（尤其 Gemini）官方文档对图片/文档输入建议的分辨率上限是多少？超过这个分辨率再大也不会提升识别效果，等于浪费 token。\n3. Java 生态（Spring Boot 后端）中实现上述 b/c/d 压缩最成熟、维护活跃的开源库有哪些（如 Apache PDFBox、PDF-Renderer、pdf2image 等价物），给出推荐及基本用法方向。\n4. 是否有已知的业界案例/技术博客/官方文档，专门讲\"大模型文档理解前的预处理/压缩管线\"最佳实践（不局限于 Gemini，也可以是 GPT-4V/Claude 的经验，只要有代表性）。\n5. 针对本项目场景（PDF 里既有可摘录文字也有需要视觉检测的图片/版式违规，需要保留 box_2d 坐标定位能力），给出一个具体可执行的推荐方案（是否压缩、如何压缩、压缩到什么程度、用什么库/工具、大致的 Java 伪代码或库调用方式），并说明这个推荐相对于\"不压缩，直接全量上传\"当前现状的实际收益（token/成本/延迟）与风险（可能损失的识别准确率）。\n\n请提供有引用来源的结论，重点关注 Gemini 官方文档、Google AI 开发者社区最佳实践、以及成熟开源工具的官方文档。"
}

 

核心结论：不需要"压缩 PDF 体积"，需要压缩的是"送审页数"和"分辨率档位"

1. Gemini 官方硬限制（ai.google.dev/gemini-api/docs/document-processing）：

• PDF 上限 50MB 或 1000 页，inline bytes（当前项目 Part.fromBytes 的用法）与 Files API 共享同一限制——Files API 不提供更大配额，只在总请求体 > 100MB（PDF 专项 > 50MB）时才建议切换，纯粹是为了绕开 Base64 编码开销、支持文件复用，跟 token 计价无关。
• 当前项目 9MB 的 PDF 远低于阈值，继续用 inline bytes 完全没问题，换 Files API 不会带来任何收益。

2. 关键认知纠正：文件体积 ≠ token 消耗

• Gemini 3 之前的模型：每页固定 258 tokens，与页面分辨率、内容密度、文件字节数完全无关。
• Gemini 内部会强制把页面统一缩放：大于 3072×3072 降采样，小于 768×768 升采样——你上传的原始分辨率超过 3072×3072 对识别效果没有任何提升，只会拖慢上传和编码时间。
• Gemini 3 系列引入 media_resolution 参数分级计费（low=280 / medium=560 / high=1120 tokens/页），官方明确建议 PDF 场景用 medium，并写明"提高到 high 对标准文档 OCR 效果提升甚微"。

结论：Ghostscript/pikepdf/qpdf 式的"通用 PDF 压缩"（重采样图片、降 DPI、去冗余）对 Gemini 侧的 token 成本没有直接帮助——那些工具优化的是文件传输体积，而 Gemini 计费单位是"页"不是"字节"。唯一真正影响成本/延迟的杠杆是：

杠杆	效果
只送审需要审核的页面子集（裁剪/拆分）	直接减少页数 → 直接减少 token（线性）
控制 media_resolution=medium（若用 Gemini 3 系列）	页 token 从 1120→560，且官方说 OCR 效果几乎不降
降低原始上传分辨率到 ~1536-2048 区间	减少上传延迟/带宽，不影响识别效果（模型侧无论如何都会重采样）

3. 本项目场景（需要保留 box_2d 坐标定位）的风险点： 研究没有找到"PDF 转图片序列走 image understanding 通道" vs "PDF 原生走 document understanding 通道"在 box_2d 坐标精度上的实测对比数据——这是开放问题，不建议凭空假设图片序列方案更好或更差。当前项目已经用原生 PDF 通道 + 仅对图片类物料信任 box_2d 的策略（fileType != IMAGE → bboxValid=0）是审慎且有官方依据的路线，不建议为了"省 token"改造成图片序列通道，那样反而会引入未经验证的坐标定位风险。

4. Java 生态现状：Apache PDFBox 的 CompressParameters 只做无损对象流压缩（不降图片质量）；真正的图像重采样需要手写 PDImageXObject + JPEGFactory 重编码逻辑（参考 ShrinkPDF 开源实现的模式）。但鉴于第 2 点的结论，这类图像重压缩对 Gemini 侧没有 token 收益，除非你的瓶颈是网络上传带宽/延迟而非 API 成本。

具体建议

对当前 9MB 级别的 PDF：不需要做任何压缩改造。当前 MaterialReviewAgentRunner 直接整份字节喂给 Gemini 的做法已经是最佳实践路径。如果未来遇到明显更大（接近 50MB 或数百页）的物料，优先做页面范围裁剪（只送审有效页），而不是做图像质量压缩；如果切到 Gemini 3 系列模型，可以加一个 media_resolution: medium 的显式配置项。

需要我检查项目当前用的 Gemini SDK/模型版本（确认是走 pre-Gemini-3 固定计费还是 Gemini 3 的 media_resolution 分级计费），以判断 medium 档位建议是否适用吗？