不上传就能总结 PDF：本地文档 AI 是怎么工作的

收件箱里躺着一个 PDF：六十页的研究论文、两百页的合同、明天要用的董事会材料。 你需要的是要点，不是全部。最直觉的做法——丢给一个聊天机器人——意味着上传。 对已发表的论文那是有点失礼；对合同、病历或任何带保密义务的文件，那是根本 不被允许的。

在本地跑完全可行，而且它的工作方式比看上去更有意思。三个阶段，各有各的失败 模式；知道是哪一阶段失败了，就能把「AI 给了我一份胡说八道」变成两分钟修好 的问题。

第一阶段：抽取——决定一切的一步

文档在你的浏览器里用 pdf.js 逐页解析，也就是 Firefox 使用的那个开源渲染器。 它读取的是 PDF 的文本层：文件里真正嵌入的字符数据。

下面这个失败模式，占了「返回空白」报告的大多数：扫描版 PDF 没有文本层。对 pdf.js 来说，它就是一叠图片。 没有东西可抽取，于是抽取返回空，总结也就无从下手。模型没坏，文件也没坏—— 它是一张图。

解决方法是两步流水线：先让页面过一遍 OCR 产生文本，再总结。如果你的文档来自 扫描仪、传真或手机翻拍，请从这里开始。文字处理软件和 LaTeX 几乎总会嵌入真正的文本层，扫描仪几乎从来不会。

第二阶段：分块——为什么按 8000 字符切分

语言模型一次只能考虑固定窗口的文本。这条流水线使用的分块大小是 8000 个字符，大约两千个 token——刻意选在远低于模型上下文 窗口的位置，而不是去试探它的极限。

有意思的是在哪里切。朴素的做法是数到 8000 字符就下刀，这经常正好 切在句子中间、甚至论点中间。这里的做法是按段落边界切，把 每块填到上限为止，因此一块几乎总是在作者结束一个想法的地方结束。仅这一个 细节就显著提升了摘要质量：在句子中间断开的块，会生成一段关于一个并不存在的 句子的、错乱的摘要。

工具会在你投入推理之前把这个阶段的结果显示出来——页数、字符数，以及文档被 切成多少块。一篇四十页的论文通常是几块；一份两百页的合同是几十块。如果块的 数量明显不对，你就在花任何推理时间之前找到问题了。

第三阶段：map-reduce——先总结各块，再总结这些总结

短文档装得进一块时，流水线走单次生成，并边生成边流式输出。长文档则运行 map-reduce：

• Map（映射）。每一块被独立总结成简明要点，生成上限为 380 个 token。每一块都有机会——不会因为文档长就悄悄丢掉任何部分。
• Reduce（归约）。把这些分块摘要拼接起来，再蒸馏成一份 答案，最终综合阶段的预算更大，为 900 个 token。

这就是本地工具能处理远超其上下文窗口的文档的原因。另一种做法——截断到前 N 页然后碰运气——正是你会拿到一份自信满满、却完全漏掉第 180 页责任条款的合同摘要的原因。map-reduce 计算成本更高，但它也是唯一真正读完了 整份文档的做法。

你可以看着它进行：界面会报告当前处理到第几块，所以长任务显示的是真实进度， 而不是一个转不完的圈。

改为提问：「NOTHING RELEVANT」的技巧

总结是默认动作，提问往往更有用。在提问模式下，每一块不是被总结，而是被 盘问：模型被要求只提取与你的问题相关的内容，尽可能引用关键短语， 并且——这才是巧妙之处——如果该块没有相关内容，就精确回复 NOTHING RELEVANT。

这些明确的空结果会在最终综合之前被丢弃。效果是一个廉价而有效的相关性过滤器： 与其让一个小模型在脑子里装着两百页去找那一条关键条款，不如问它四十个窄问题， 留下答得上的三个。这和研究助理逐节阅读、而不是抱着整本文件夹快速翻一遍的 道理是一样的。

你拿回的答案扎根于文档的特定部分，而不是从模型的通用知识里生成出来的——当 答案有后果时，这正是你想要的。

模型本身：4 位权重与一次约 1 GB 的加载

语言模型是一个 15 亿–17 亿参数级别的紧凑指令微调网络（依档位不同为 SmolLM2 1.7B / Qwen2.5 1.5B），通过 Transformers.js 以 4 位量化加载。在 WebGPU 上它加载为q4f16——4 位权重配 16 位激活，下载量约 1 GB；在 WebAssembly 回退路径上使用 q4。

两个需要诚实面对的后果。第一，这个下载是真实存在的，而且只发生一次；之后 浏览器缓存会让后续文档立即加载。第二，WASM 回退路径在生成阶段确实慢—— 工具会直接警告你，而不是假装没事。如果你在等，原因几乎总是你跑在 CPU 路径上。带现代 GPU 的机器上的 Chrome 或 Edge，就是喝杯咖啡和几秒钟的差别。

实用配方

六十页的研究论文

先总结，拿到论证的骨架。然后对你关心的部分切换到提问模式：样本量是多少？ 作者声明了哪些局限？ 作者没能控制什么变量？对着方法部分提问，正是这套工作流胜过把摘要 读两遍的地方。

合同审查

不要问「总结一下」。要有针对性地问：终止条件是什么？ 数据丢失的责任由谁承担？ 付款条件与期限是什么？然后去读它引用的那些段落。输出是一份阅读 指南，不是法律意见——但它把两百页变成了你真正需要细读的四页。

文献筛选

逐篇总结一批论文，保留要点。十五分钟处理十篇，就能告诉你哪两篇值得全文 精读，而且你从未把自己的研究方向上传到任何地方。

扫描件

先 OCR，再总结。这是两个工具而不是一个，也是唯一可行的路线——而且因为两者 都在本地运行，中间产生的文本文件同样不会离开你的机器。

信任输出之前，值得知道的局限

• 表格和图表基本不可见。文本抽取拿到的是散文；锁在图表里的 含义通常取不回来。
• 跨距很远的章节之间的推理能力有限。map-reduce 读完了全部，但每一块是孤立地读的。需要同时读第 4 页和第 190 页才能得出的结论，可能不会浮现。
• 数字必须核对。把摘要给出的每个数字都当作一条需要对照 原文页面验证的声明。
• 加密或受权限保护的 PDF 在没有密码的情况下无法解析， 这是设计使然。

为什么这件事应该在你的机器上完成

人们需要总结的文档，恰恰大多是绝不能上传的文档：正在谈判的合同、病历、 人事档案、未发表的研究、任何受 NDA 或数据处理协议约束的材料。云端的同类 任务会在别人的服务器上留下一份副本，受别人的留存策略管辖。

本地方案里不存在这份副本。文件在浏览器内存中被解析，模型在你的硬件上运行， 然后答案出现。用PDF 摘要工具试一篇你已经读过的文档，这样你就能用已有的知识来判断摘要的质量。这是校准 「该信它多少」最快的方法。