40 页 PDF 让 AI 总结，只说了其中几段？一次附件问答漏答的走查复盘
结论：附件问答漏掉大半内容，先检查「检索」提供了哪些片段，再核对解析是否完整。 每次提问，系统会用你这句话去文件里找最相关的几段，只把这几段交给模型。问「总结全文」，模型看到的就只是和「总结全文」这几个字最像的那几段。改法是把问题问具体、按章节分开问；真要全文总结，就分段粘贴原文。
下面是这次走查的完整过程，依据是 2026 年 10 月 7 日我们核对的服务端实现。实现以后可能调整，具体以页面表现为准。
现象
「上传一份 40 页的 PDF，让 DeepSeek 总结全文，它只讲了其中几段，后面的章节完全没提」——这是文件问答里常见的一类疑问。界面上文件显示解析完成，回答也很流畅，就是不全。
第一个假设：模型上下文不够长？先核对输入范围
不能仅凭回答漏项，就断定是模型上下文不够，也不能凭没有报错排除所有输入截断。先核对材料实际送入了多少：附件解析完成，不代表全文进入模型上下文；PDF 页数也不能直接换算成模型可接收的 token 数。
可以自己做个对照：把同一份文件的前两章直接粘贴进对话让它总结，如果粘贴的两章都能覆盖，可以把排查重点放到附件解析和检索范围；这仍不能证明整份文件都能完整处理。
第二个假设：文件没解析出来？检查是否部分缺失
解析失败有明确提示：全是图片、提取不出文字时，会提示「该文件可能内容格式（比如全部为图片）不兼容，未解析出有效内容」；文字超过 50 万字会提示「文档内容太大」。没有这两种提示、回答里出现文件原话，只能说明至少有部分文字被提取，不能证明每页都解析完整。需要抽查开头、中间、结尾以及表格中的关键句。
走查实现：一个问题从提问到回答经过了什么
按服务端代码逐步看，附件问答分四步：
- 上传时切段。 文件提取成文字后，按约 1000 字一段切开，存起来。一份 40 页的报告，通常会切成几十段。
- 提问时检索。 每次提问，系统拿你这一句问题去所有段里找最相似的，取 3 段。
- 只把这 3 段交给模型。 加上一句「按相关性回答，不知道就说不知道」的说明，和你的问题一起送给模型。
- 只认最近一次上传的附件，附件之前的聊天不带上。 同一个对话里传了两份文件，检索只在最新那份里找；上传之前聊过的背景，附件问答时不会一起送给模型。
从实现可以定位一个明确的覆盖限制：文件可能切成几十段，每问最多检索 3 段，每段约 1000 字符。 「总结全文」这个问题和哪一段都不特别相关，检索挑出来的 3 段带有偶然性，模型只能按这 3 段来写，于是就成了「只说了其中几段」。
这个设计不是缺陷，它让附件问答的检索本身不扣豆，送给模型的输入也很少，问具体问题时又快又省。只是它天生不适合「通读全文」这类任务。
改法
1. 把问题问具体，带上原文里会出现的词
检索按你的问题去匹配，问题里出现的词越接近原文，越容易找对段落。
- 差：这份报告讲了什么？
- 好：第三章「风险因素」里列了哪几类风险？
- 好：报告里 2025 年的营收和同比增长是多少？
2. 全文任务拆成按章节问
先让它列目录（目录本身也可能不完整，自己对照 PDF 核一遍），再一章一问：「总结第二章《市场分析》的要点」。章节名能帮助缩小检索范围，但每问仍最多返回 3 段，不能保证整章覆盖。每章另挑几个已知事实复核。
3. 真要通读全文，改用分段粘贴
总结、逐条对比、找遗漏，这些任务需要模型看到全部原文。把文字分几段粘贴进对话（每段标好章节名），比附件检索稳得多。长材料可以用 Kimi K3 这类长上下文版本，贴得多问得短的任务，K3 的花费也不高。
4. 先传附件，再交代背景
因为附件之前的聊天不会一起送给模型，「我是采购方，重点关注付款条件」这类背景，要在上传文件之后、和问题写在同一句里。
5. 两份文件对比，不要指望同时检索
只认最近一次上传的附件，第一份就不在检索范围里了。对比两份文件时，把两边要对照的段落都粘贴到同一条消息里，标好「A 版」「B 版」。
怎么复测改法有没有用
- 从 PDF 里挑 3 个你自己知道答案的事实，分散在开头、中间、结尾三处。
- 用「总结全文」问一次，看 3 个事实被提到几个。
- 换成三个具体问题分别问，再数一次。
- 再把那三段原文粘贴进去问一次。
三种问法的差别一眼就能看出来。重要结论仍然要回到原文核对，回答里的页码和章节名也可能出错。
相关阅读
- 文件读不了、一直转圈的排查：DeepSeek 上传文件读不了？PDF、Word、Excel 排查步骤
- 回答缺项时怎样定位是哪一步漏的：AI 回答漏了文件里的内容，怎样排查
- 长文档怎么核对证据：Kimi 长文档问答：选段核查与遗漏检查
现在可以试什么
打开 DeepSeek 页面，用你手头的一份 PDF 按上面的复测方法问三遍，确认哪种问法适合这份文件，再开始正式提问。