经一把聚合 key 上传 PDF：哪些后端读得到文本层、哪些只看第一页

为什么 PDF 在不同后端表现不同

PDF 是一种容器格式，内部可能包含文本层（可直接提取的文字）、矢量图形、位图扫描件等多种元素。不同 LLM 后端处理 PDF 的方式存在差异：有的直接解析文本层，有的将页面渲染为图片再进行多模态理解。因此，同一份文件在不同后端上的解析结果可能大相径庭。

测试方法

我们使用一份包含多页文本、表格和扫描页的合同 PDF，通过聚合 API 分别发送给各后端。测试关注三个维度：

• 文本层读取：能否提取出 PDF 中已有的文字内容。
• 表格解析：表格结构是否被正确识别为行列关系。
• 扫描文字处理：对于纯图片扫描页，是否通过 OCR 或多模态能力识别文字。

同时记录各后端返回的 token 用量，分析文件大小与 token 消耗的关系。

各后端解析能力对比

Claude 系列

Claude 后端通常能读取 PDF 的文本层，并支持多页处理。对于表格，能保留基本结构但复杂合并单元格可能丢失。扫描页依赖多模态识别，准确率受图片质量影响。文件按页数或 token 计费，具体取决于 API 实现。

GPT 系列

GPT 后端对文本层解析良好，表格识别较准确，但同样受限于 PDF 内部结构。扫描文字通过视觉能力处理，对清晰印刷体效果较好。token 计算通常基于提取的文本长度或图像分块。

DeepSeek 系列

DeepSeek 后端侧重文本处理，对纯文本 PDF 解析完整，但表格和扫描页支持有限，可能仅读取第一页或忽略非文本内容。token 消耗主要来自文本提取。

Qwen 系列

Qwen 后端具备多模态能力，能处理扫描页和表格，但不同版本差异明显。文本层读取完整，表格结构还原度中等。token 计算可能包含图像编码开销。

GLM 系列

GLM 后端对中文 PDF 支持较好，文本层提取准确，表格识别尚可。扫描文字依赖 OCR 模块，对简单版面有效。token 用量与文本长度相关。

Kimi 系列

Kimi 后端擅长长文档处理，能读取多页文本层，表格解析基本可用。扫描页通过多模态理解，但对低质量图片可能遗漏。token 计算基于实际处理内容。

文件如何计入 token

不同后端的 token 计算方式不同：

• 文本提取型：仅计算提取出的文本 token，文件大小不影响计费。
• 图像分块型：将每页渲染为图像，按图像分辨率或分块数量计算 token，页数越多消耗越大。
• 混合型：文本层与图像结合，token 为两者之和。

用户需注意，同一文件在不同后端上的 token 消耗可能相差数倍，选择时需结合解析需求与成本。

实践建议

• 若 PDF 以文本为主，优先选择文本解析能力强的后端。
• 若包含大量表格或扫描件，选择多模态支持好的后端，并确保图片清晰。
• 关注各后端的 token 计费方式，避免因页数多或图像分块导致成本激增。
• 通过聚合 API 可方便切换后端，对比实际解析效果后再做决定。

总结

PDF 解析效果取决于后端实现，没有 universal 的最佳选择。理解各后端在文本层、表格和扫描文字上的差异，并结合 token 计费方式，才能高效利用聚合 API 处理文档。