你给 Gemini 3.1 Pro 上传 200 页 PDF,问”总结第 3 章,带准确页码引用”,得到三种失败之一:完全没页码;给的 [page 5] 对不上真的第 5 页;凭空编出文档里根本不存在的页码。
最快修复: 先确认 PDF 有真正可选中的文字层(扫描件要先 OCR),然后让模型每个页码旁边都附一句原文引用。如果你需要能规模化信任的引用,别再用聊天 app,改用 API 的 File Search 工具 —— 它会给每个被引用的片段返回真实的 page_number。细节见下。
PDF 引用的准确度,是 Gemini 宣传的长上下文能力和研究者真实使用之间最大的鸿沟。模型能读出文字,丢的是”这句话在第几页”这个关联。
你属于哪一类?
| 症状 | 最可能的原因 | 跳转 |
|---|---|---|
| 完全没页码 | Prompt 没要求,或输出被截断 | 步骤 2 / 原因 4 |
| 页码差一个固定值(比如总是 +12) | 前言偏移(印的页码 vs PDF 索引) | 步骤 3 / 原因 2 |
| 页码乱、引用原文那页根本没有 | 文字层 OCR 差,或幻觉 | 步骤 1 / 原因 5 |
| 只在长篇多章请求时引用消失 | 输出预算太小,引用先被砍 | 步骤 4 / 原因 4 |
| API 能用,app 不行 | 消费版是最弱的面板 | 步骤 5 |
常见原因
按出现频率:
1. PDF 是扫描件,OCR 差(最常见)
扫描 PDF(复印件、手机扫描 app、老档案)通常没有文字层,或者文字层很糟。Gemini 用视觉能读页面图像,但它看到的是像素,不是”第 47 页 / 共 200 页”,所以页码归属就不稳。
如何判断: 用任意阅读器打开 PDF,用光标去选一句话。完全选不中 = 没文字层。能选中但复制出来全是错字 = OCR 层很差。
2. 印的页码和 PDF 索引页码对不上
一本书的 PDF 可能在”第 1 页”印出来之前,有 12 页未编号的前言。所以 Gemini 报的”第 47 页”可能是 PDF 物理第 47 页(在书里印成第 35 页),也可能反过来。这会产生一个固定偏移 —— 这反而是好消息,可以纠正。
如何判断: 用能显示索引(比如 47 / 200)的阅读器打开,和页面上印出来的页码对比。
3. Prompt 没要求引用
Gemini 默认总结不带引用。“总结第 3 章”给的是正文;“总结第 3 章,每个论断都给 PDF 页码和一句原文引用”才会有带证据的引用。
如何判断: 重写 prompt 明确要求引用(步骤 2),如果引用出现了,原因就是它。
4. 长文档 + 输出预算小 = 引用先被砍
输出上限紧的时候,模型会把页码和引用当成可砍的”额外内容”,保留正文。max_output_tokens 设小的多章总结,会悄悄丢掉引用。
5. 边界情况下捏造引用
Gemini 不确定某个论断来自哪一页时,有时会编一个看起来合理的页码。这是已知的长上下文失败模式 —— 这也正是为什么要引用原文而不只是页码:假的原文比假的页码好抓得多。
6. 面板选错 —— Gemini app 比 API 弱
gemini.google.com 的消费版跑的是更轻的检索流水线。你上传 PDF 时它会显示可点击的页面引用,但做引用级工作,它是三个面板里最弱的(app < AI Studio < API File Search)。
最短修复路径
步骤 1:给 PDF 一个真正的文字层(扫描件先 OCR)
如果原因 1 里选不中文字,上传前先 OCR。截至 2026 年 6 月:
- Adobe Acrobat(Pro):
工具 -> 扫描和 OCR -> 识别文本,选语言和页面,运行。质量最高,表格和多栏版式尤其稳。 - ABBYY FineReader: 复杂版式、密集学术排版最好。
- macOS 预览(内置): 打开扫描件,
文件 -> 导出...,勾选 “嵌入文本”(Embed Text) —— 这是苹果的 OCR,自 macOS Sonoma 起就有,Tahoe 仍保留。免费,干净的扫描件够用。 - Google Drive: 上传 PDF,右键
-> 打开方式 -> Google 文档。转换时 Drive 会自动 OCR,再导出回 PDF。 - Acrobat web(免费档): 不用装桌面版也能处理小文档。
验证 OCR: 打开新 PDF,选一段文字,高亮选中的应该和肉眼看到的完全一致,没有乱码。
步骤 2:显式要求带页码的原文引用
不要写”总结第 3 章”,要写:
总结第 3 章。
每一个论断都必须:
1. 标注准确的 PDF 页码(page X)。
2. 附上该页 5-15 个词的逐字原文引用(verbatim quote)。
3. 找不到原文支撑的论断,直接省略。
页码不确定就写 "page uncertain",不要猜。要求逐字原文,正是破解原因 5 那种幻觉的关键:原文要么在那一页要么不在,几秒就能确认。
步骤 3:抽查,并识别偏移规律
打开 PDF,抽 2-3 个随机引用和源文档对照。
- 如果每一页都差同一个量,那就是原因 2 的前言偏移。记下偏移(比如”PDF 索引 = 印的页码 + 12”),心算纠正,或者告诉 Gemini”用页面上印出来的页码,不要用 PDF 索引”。
- 如果页码随机错、或者引用原文在被引页上根本找不到,那要么 OCR 差,要么模型幻觉了。回到步骤 1,或转去步骤 5 的 File Search 路径。
步骤 4:长总结时调高输出预算
如果引用只在大请求时消失(原因 4),罪魁是输出上限。在 API 里把 max_output_tokens 设大(长章节用 32768 比较从容)。在 app 里则一次只要一节,让回复永远到不了上限。把 100+ 页的 PDF 切成一章一个请求,引用比让模型一口气分析整本书要精确得多。
步骤 5:引用级工作,用 API File Search 工具
这是本文初版以来最大的变化。Gemini API 现在内置了一个 RAG 工具 File Search,它会给每个被引用的片段返回真实、可核验的 page_number,而不是让模型凭记忆回想页码。这是截至 2026 年 6 月拿到可信引用最可靠的方式。
from google import genai
from google.genai import types
import time
client = genai.Client(api_key="YOUR_API_KEY")
# 1. 创建一个 File Search store
store = client.file_search_stores.create(
config={"display_name": "research-pdfs"}
)
# 2. 上传 PDF 并导入 store
uploaded = client.files.upload(file="paper.pdf")
op = client.file_search_stores.import_file(
file_search_store_name=store.name,
file_name=uploaded.name,
)
while not op.done:
time.sleep(5)
op = client.operations.get(op)
# 3. 基于 store 提问(已接地)
response = client.models.generate_content(
model="gemini-3.1-pro",
contents="对每个核心论点,给一句逐字原文引用。",
config=types.GenerateContentConfig(
tools=[types.Tool(
file_search=types.FileSearch(
file_search_store_names=[store.name]
)
)],
),
)
print(response.text)
# 4. 从接地元数据里读真实页码
meta = response.candidates[0].grounding_metadata
for chunk in meta.grounding_chunks:
ctx = chunk.retrieved_context
print(ctx.page_number, "-", ctx.title)页码来自 grounding_metadata.grounding_chunks[].retrieved_context.page_number,所以它绑定的是被索引的文档,而不是模型的猜测。如果你不需要 RAG、只想跑一次性的一遍,普通 generate_content 配内联 PDF 仍然可用(types.Part.from_bytes(data=pdf_bytes, mime_type="application/pdf")),但它的引用要靠提示词(步骤 2)。
几个值得知道的 API 事实(2026 年 6 月):
- 单个请求接受最多 1000 页 / 50 MB 的 PDF;超过就切分。
- PDF 里原生嵌入的文字会被提取、且不计费为 token —— 这又是一个理由,把扫描件 OCR 成真文字,而不是留成图像(图像页每页约 258 token)。
- 如果密集表格或小字被读错,在
generationConfig里设media_resolution;分辨率越高,页面 token 化越精细。
引用工作用 Gemini 3.1 Pro(gemini-3.1-pro)而不是 Flash 系列 —— 多出来的推理预算能同时减少”引用被丢”和”引用被编”。
步骤 6:对外引用前先交叉验证
研究 / 法律 / 学术用途,绝不要单方面相信模型的引用,哪怕来自 File Search。在 PDF 阅读器里打开被引页,确认原文逐字存在。每条引用约 30 秒,省一次撤回。
怎么确认已修好
三条都满足就算搞定:
- 你能在 PDF 里选中干净的文字(文字层没问题)。
- Gemini 回答里每个论断都带页码和原文引用,抽查 3 条都和源文档完全对上。
- 如果用了 File Search,
grounding_chunks[].retrieved_context.page_number有值且指向正确页面。
如果页码只是差一个固定偏移,那是无害的前言情况 —— 不算失败。
预防
- 任何扫描 PDF 在让 Gemini 看之前先 OCR,养成条件反射。
- 留一份”原文引用 + 页码”的标准 prompt 模板,所有引用工作复用。
- 长文档每轮处理一章,不要整本一起总结。
- 在把 Gemini 的引用对外引用之前,至少抽查 3 条随机引用。
- 经常做这类事的话,搭一套 File Search 工作流,不要和消费版较劲,引用质量差别很明显。
常见问题
为什么 Gemini 标”第 5 页”,真正的文字在第 17 页? 几乎都是前言偏移(原因 2)或文字层 OCR 差(原因 1)。如果各条引用的差值一致,就是偏移,让 Gemini 用印出来的页码即可;如果差值随机,就给 PDF 做 OCR 或改用 File Search。
gemini.google.com 上的 Gemini app 能给可靠页码引用吗? 它会显示可点击的 PDF 页面引用,日常阅读够用,但它跑的检索流水线比 API 轻。任何要对外引用的东西,用 API File Search 工具,并对源文档验证。
Gemini 既然能”看见”页面,OCR 还重要吗? 重要。视觉让 Gemini 读出文字,但真正的文字层给它稳定的页面结构、让原生文字免费(不计 token)、并大幅减少错页归属。纯图像 PDF 是糟糕引用的头号原因。
PDF 引用用哪个模型最好?
Gemini 3.1 Pro(gemini-3.1-pro),1M token 上下文。它单个请求就能吃下 1000 页 PDF,配 File Search 还能返回可核验的 page_number 元数据。Flash 系列更快更便宜,但丢引用、编引用的概率更高。
怎么彻底让 Gemini 别编页码? 要求每个论断都给逐字原文,并让它省略任何引不出原文的论断(步骤 2)。假原文一抽查就露馅,光假页码不行。要做到零猜测,就用 File Search,页码来自索引而非模型。