Gemini PDF 引用页码丢失或对不上

让 Gemini 给 PDF 标页码引用,结果要么没页码,要么页码对不上。多半是 OCR 或提示不够强势 — 修复办法在这里。

你给 Gemini 2.5 Pro 上传 200 页 PDF,问”总结第 3 章,带准确页码引用”,得到三种失败之一:完全没页码;给的 “[page 5]” 对不上真的第 5 页;凭空捏造文档里根本不存在的页码。

PDF 引用的准确度,是 Gemini 宣传的长上下文能力和研究者真实使用之间最大的鸿沟。修复几乎永远是:改善 OCR 质量、引用要求更强硬、用引用原文而不是单靠页码来验证。

常见原因

按出现频率:

1. PDF 是扫描件,OCR 差(最常见)

扫描 PDF(复印件、手机扫描 app、老档案)通常没有文字层,或者文字层很糟。Gemini 用视觉能读页面,但丢失了页码语境 — 模型看到的是图,不是”第 47 页 / 共 200 页”。

如何判断:在 PDF 阅读器里选文字。选不到 = 没文字层。能选但全是错字 = OCR 差。

2. PDF 印的页码和 PDF 索引页码对不上

一本书的 PDF 可能在”第 1 页”印出来之前,有 12 页未编号的前言。Gemini 报的”第 47 页”可能是物理第 47 页(= 书自己编号的第 35 页),反之亦然。

如何判断:用阅读器打开 PDF,看印出来的页码和 PDF 页索引是否一致。

3. Prompt 没要求引用

Gemini 默认总结不带引用。问”总结第 3 章”得到摘要;问”总结第 3 章,每个论断都标准确页码和一句原文引用”才会有引用。

如何判断:重新写 prompt 明确要求引用后就有了。

4. 长文档 + 输出预算小 = 引用先被砍

输出上限紧的时候,模型会把引用当”额外”先砍掉,保留正文。所以默认 8K 输出时,多章总结的页码会丢。

5. 边界情况下捏造引用

Gemini 不确定某个论断来自哪一页时,有时会编一个看起来合理的页码。这是已知的长上下文失败模式。

6. 面板选错 — gemini.google.com 不如 API 可靠

消费版的检索流水线比 AI Studio / API 弱。做引用级工作,消费版是最弱的面板。

最短修复路径

步骤 1:上传前先 OCR

PDF 是扫描件的话,先做 OCR。推荐:

  • Adobe Acrobat:工具 → 扫描和 OCR → 识别文本 → 此文件内。质量最高,表格尤其稳。
  • ABBYY FineReader:复杂版式、多栏最好。
  • macOS 预览(快速操作里的 OCR):免费,干净的扫描件够用。
  • Google Drive:上传 PDF,右键 → 用 Google Docs 打开(自动 OCR)。
  • Adobe Acrobat web 免费档能处理小文档。

验证:打开 OCR 后的 PDF,选一段文字,选中的应该和肉眼看到的一致。

步骤 2:显式要求带页码和原文引用

不要写”总结第 3 章”,要写:

总结第 3 章。

每一个论断都必须:
1. 标注准确的 PDF 页码(page X)
2. 引用该页 5-15 个词的原文
3. 找不到原文支撑的论断,直接省略

页码不确定就写 "page uncertain",不要猜。

这个模板强制模型挂证据,杜绝最糟的幻觉(凭空编数字)。

步骤 3:抽查验证

拿到引用后,打开 PDF 抽 2-3 个随机检查。如果页码差一个固定偏移,那是前言偏移(见原因 2),心算就能纠正。如果页码乱七八糟,要么 OCR 差,要么模型幻觉了 — 回到步骤 1。

步骤 4:引用级工作,用 API

from google import genai
from google.genai import types

client = genai.Client(api_key="YOUR_API_KEY")
with open("paper.pdf", "rb") as f:
    pdf_bytes = f.read()

response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents=[
        types.Part.from_bytes(data=pdf_bytes, mime_type="application/pdf"),
        "对每个核心论点,标准确 PDF 页码,并附一段原文引用。"
    ],
    config=types.GenerateContentConfig(max_output_tokens=32768),
)

API + Gemini 2.5 Pro 是引用工作最高质量的面板。

步骤 5:超长文档先切段

PDF 超过 100 页,一章一章处理比让模型一口气分析整本书,引用更精确。每章一个 API 调用,再拼起来。

步骤 6:对源文档交叉验证

研究 / 法律 / 学术用途,绝对不要单方面相信模型的引用。打开 PDF 那一页确认原文存在。每条引用 30 秒,省一次尴尬。

预防

  • 任何扫描 PDF 在让 Gemini 看之前先 OCR — 养成习惯
  • 留一份”原文引用 + 页码”的标准 prompt 模板,引用工作复用
  • 多章文档每轮处理一章,不要整本一起总结 — 引用更准
  • 在把 Gemini 的引用对外引用之前,至少抽查 3 条
  • 经常做这类事的话,搭一套 API 工作流,不要和消费版较劲 — 引用质量差别明显

相关

标签: #Gemini #排查 #PDF