摘要工具实测：一篇13600字的长文，十句摘要里没有一句定义

十句摘要，第一句主语就丢了，中间夹着维基编辑按钮的残片，整篇没有一句定义。定义句在抽取时被信息框粘成 47 个词的怪句子，而算法只挑长句。

💡 你将学到

十句摘要，第一句主语就丢了，中间夹着维基编辑按钮的残片，整篇没有一句定义。定义句在抽取时被信息框粘成 47 个词的怪句子，而算法只挑长句。

📜 目录

• 一、这次测试的跑法
• 二、同一篇文档，四种算法的耗时与数字保留
• 三、定义句为什么没被选中
• 四、删掉 41.6% 的参考文献，输出一个字没变
• 五、改成三段分别摘要，数字从 11 个到 22 个
• 六、复现要过的三个坑
• 七、PDF 那条路，以及该不该换 LLM
• 相关内容

十句话的摘要，第一句是「[66] These are trained to generate step-by-step analysis before producing final answers」。主语丢了。中间夹着一句从 because 开头的残句，还有「Stereotyping [edit]」这种维基编辑按钮的残片。整篇十句，没有一句说明大语言模型是什么。

东西没装错，是输入就带着坑：条目第一条定义句在抽取时被信息框粘住，成了一段 47 个词、中间夹着竖线的怪句子；LSA 这类算法按句子长度和词频打分，被挑中的十句全部在 23 到 29 个词之间，而这 1,296 句里中位数只有 8 个词。

一、这次测试的跑法

文档用英文维基百科 Large language model 条目，2026 年 11 月 2 日抓的 HTML，1,033 KB。机器是 2 核 Intel Xeon Platinum、1 GB 内存，Python 3.11.6，trafilatura 2.3.1、sumy 0.13.0、pypdf 6.21.4、numpy 2.4.6、nltk 3.10.4。

抽取走 trafilatura.extract 默认参数，切句用 sumy 自带的 nltk 分词器，每个算法统一输出 10 句。这套组合不联网、不要 API Key、不花钱，也是多数人搜 summary tool 时真正能落地的东西。

实测抽取：93,521 字符、13,601 词、1,296 句，耗时 0.49 到 0.73 秒（两次运行）。把 include_tables 关掉只少 153 个字符，说明这一页的表格本来就没进正文。

二、同一篇文档，四种算法的耗时与数字保留

数字保留率 = 摘要里的数字个数 / 全文 1,681 个，四种都没过 1%。规模也测了：100 句时 LSA 0.16 秒、LexRank 0.12 秒、TextRank 0.07 秒；300 句时 0.52、1.44、0.93 秒。到 1,296 句，LexRank 的 13.97 秒是 100 句时的 116 倍，而句子数只涨了 13 倍，增长不成比例。

三、定义句为什么没被选中

抽取结果里那条定义长这样：「Large language model | Part of a series on | Machine learning and data mining | A large language model (LLM) is a machine learning model ... trained on a vast amount of text」。信息框的标题和导航被拼进了同一句，47 个词，被竖线切成几段。

十句全部落在 p90 以上，算法就是照长句挑的。定义句被信息框污染后失去了句子形态，也失去了被选中的机会。这一步在抽取阶段就发生了，摘要算法接手时已经没法挽回。

四、删掉 41.6% 的参考文献，输出一个字没变

全文 93,521 字符里，第 54,604 个字符之后是 References，长 38,917 字符，占 41.6%；1,681 个数字有 1,283 个在这一段，正文只剩 398 个。按常识应先切掉再摘要，于是切掉重跑：

快了 4.6 倍，结果一模一样。引用列表既没被选中，也没拖累选句，删它只省时间，不动质量。这一点值得记下来：网上一堆教程教你「先清洗参考文献再摘要」，在这篇文档上，清洗对输出的影响是零。

五、改成三段分别摘要，数字从 11 个到 22 个

整篇一次出 10 句：1,834 字符、11 个数字。切成 3 段、每段 432 句、每段出 4 句，合计 2.2 秒：1,863 字符、22 个数字。字符几乎一样，覆盖翻了一倍。这是整个测试里唯一挪动了结果的开关。代价是分段处上下文会断，合并后得人工删重复句，第三段的尾巴还带出了引用模板的残留。

六、复现要过的三个坑

命令三行：
pip install trafilatura sumy pypdf numpy
python -c "import nltk; nltk.download('punkt_tab')"

报错原文照抄，遇到直接对：

1. 不装 numpy 跑 LSA：ValueError: LSA summarizer requires NumPy. Please, install it by command 'pip install numpy'.
2. 缺分词数据：LookupError: Resource 'punkt_tab' not found.，sumy 随后提示 python -c "import nltk; nltk.download('punkt_tab')"。
3. 中文文档：ValueError: Chinese tokenizer requires jieba. Please, install it by command 'pip install jieba'.

第二个坑卡了一轮：nltk.download 在这台机器上连 GitHub 挂了七分钟没动静，最后从 jsdelivr 拉 punkt_tab.zip，解压进 /root/nltk_data/tokenizers 才通。国内机器装这套，这一步基本都得绕开官方源。

七、PDF 那条路，以及该不该换 LLM

拿 arXiv 2307.06435 试 PDF：1.81 MB、47 页，pypdf 提取 277,262 字符、42,704 词、5,335 个数字，2.92 秒，没有一页低于 100 字符。数字多是假象，PDF 表格抽出来是空格和换行交错的行，喂给摘要算法只剩一串没标签的数值。文档里表格多，先转 Markdown 再摘要，比调算法有用。

取舍摆在这里：抽句式摘要不改写，十句里 8 句能按前 60 字符在原文直接搜到，可核验，也不会编数字，代价是漏。要跨段归纳、要人话，它做不到，只能上 LLM，而 LLM 的代价是会编数字。稳的顺序是先跑抽句式拿到可核验的骨架，再让 LLM 在骨架上改写，改完的数字逐个回原文对。几十页的文档，KL 这类 O(n²) 的算法直接排除，1 GB 内存的机器上 LSA 是唯一能秒级返回的。

相关内容

PDF 转 Markdown 的抽取方案对比：Docling、Marker 与 MinerU 实测
分块与检索管线的搭法：LangChain 1.x 之后重建 RAG 管线
整本书的摘要工具横评：AI 书籍摘要生成器
会议录音的摘要流程：Zoom 会议摘要的本地方案