1. 从一份PDF到一张关键词地图这个项目到底在解决什么问题手里有一堆PDF想快速知道每份文件到底在讲什么、哪些词是这份文件区别于其他文件的“指纹词”——这个需求在文档管理、竞品分析、学术文献综述、合同归档等场景里反复出现。我最早接触这类需求是在做一批技术白皮书的归档整理几十份PDF混在一起人工翻目录效率极低于是就想用Python把这件事自动化读取PDF文本做分词算TF-IDF把每份文档权重最高的词拎出来形成一张“关键词地图”。这个项目的核心链路其实就四步PDF文本提取 → 中文分词 → TF-IDF计算 → 结果排序与输出。标题里提到的“plumer”大概率是“plumber”的拼写变体在PDF处理语境下它指的是一类负责“管道式”抽取PDF内容的工具或思路——把PDF当作数据源通过一条处理管道把文本、表格、元数据逐层抽出来。不管具体用哪个库底层逻辑是一致的先把非结构化的PDF变成结构化文本再交给统计模型去算权重。适合谁来参考这篇内容如果你有Python基础能看懂列表和字典操作但没怎么碰过PDF解析和文本挖掘那这篇正好。如果你已经用过pdfplumber或PyPDF2但算出来的TF-IDF结果总是不理想关键词里混着一堆“的”“了”“我们”那这篇里的分词和停用词处理部分能帮你省不少调试时间。整篇内容我会按真实项目推进的顺序来讲从选型、踩坑、参数计算到结果验证尽量把每个“为什么这么选”说清楚。2. 整体方案设计与工具选型为什么是这套组合2.1 核心思路拆解把PDF当成一条数据流水线很多人一上来就纠结“用哪个库读PDF最好”但更该先想清楚整条流水线的形状。我的做法是把项目拆成三个独立阶段每个阶段只负责一件事抽取阶段只负责把PDF里的文字原样拿出来不做任何清洗和判断输出纯文本。加工阶段负责分词、去停用词、归一化把文本变成词列表。统计阶段负责构建词频矩阵、计算TF-IDF、排序输出。这样拆的好处是任何一段出问题都能单独定位。比如关键词里混进了页眉页脚那问题一定在抽取阶段如果关键词全是“系统”“功能”这种通用词那问题在加工阶段的停用词表。我见过不少人把三步揉在一个函数里结果调参时改一处崩三处非常痛苦。2.2 工具选型对比pdfplumber、PyPDF2、pdfminer到底怎么选PDF解析库的选择直接决定抽取质量。我实测过几个主流方案整理成下面这张表方便你按自己的文档类型对号入座。工具文本抽取质量表格支持中文支持安装依赖适用场景pdfplumber高保留布局信息强可提取表格好依赖pdfminer.six复杂排版、含表格的文档PyPDF2中纯文本为主弱一般轻量结构简单的纯文本PDFpdfminer.six高底层控制细中好稍重需要精细控制抽取逻辑pymupdf很高速度快中好需编译大批量、追求速度我最终选的是pdfplumber原因有三点。第一它对中文PDF的字符编码处理比较稳不会出现乱码方块第二它能拿到每个字符的坐标后续如果想过滤页眉页脚可以根据y坐标做裁剪第三它的表格抽取能力在同类里属于第一梯队万一后续要扩展成“PDF表格转Excel”不用换库。PyPDF2虽然轻但遇到扫描版或复杂排版的PDF经常抽出一堆空行调试成本反而更高。提示如果你的PDF是扫描件图片型上面这些库都抽不出文字需要先做OCR。判断方法很简单用pdfplumber打开后看page.chars是否为空为空基本就是扫描件。2.3 分词与TF-IDF方案为什么不用sklearn一把梭TF-IDF的计算scikit-learn的TfidfVectorizer确实能一行搞定但我这个项目里没有直接用它而是选择了jieba分词 手写TF-IDF的组合。原因在于中文分词的粒度控制。sklearn的向量化默认按空格切词对中文完全不适用必须先分词再喂进去。而jieba支持自定义词典和停用词表能针对不同领域的PDF做定制。TF-IDF的公式本身不复杂但理解它才能调好参数TF词频某个词在单篇文档中出现的次数。常见变体是除以文档总词数做归一化避免长文档天然占优。IDF逆文档频率log(总文档数 / 包含该词的文档数)。一个词在越多文档里出现说明它越通用IDF越低。TF-IDF两者相乘。既要在本篇里出现得多又要在其他篇里出现得少才能拿高分。我手写实现而不是调库主要是为了能灵活调整IDF的平滑项和TF的归一化方式。比如当文档总数很少时IDF容易出现除零需要加平滑当某篇文档特别长时纯词频会让它霸榜需要做长度归一化。这些细节在库函数里是黑盒自己写一遍反而心里有数。3. 核心细节解析与实操要点每一步的坑在哪3.1 PDF文本抽取页眉页脚是关键词污染的头号元凶用pdfplumber抽取文本最基础的写法是遍历每一页调extract_text()。但直接这么干你会发现每页的页眉比如公司名、文档标题和页脚页码、保密声明会被重复抽进来。这些词在每页都出现IDF极低按理说不会成为关键词但如果页眉里恰好有某个业务词它就会污染结果。我的处理办法是利用pdfplumber的坐标信息做裁剪。每一页的字符都有top和bottom坐标页眉通常在页面顶部固定高度内页脚在底部固定高度内。可以先抽一页看看页眉页脚的坐标范围然后在抽取时过滤掉这些区域的字符。import pdfplumber def extract_text_without_header_footer(pdf_path, header_height50, footer_height50): full_text [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: height page.height # 只保留中间区域的字符 chars [c for c in page.chars if header_height c[top] height - footer_height] # 按行重组文本 text .join(c[text] for c in chars) full_text.append(text) return \n.join(full_text)这段代码的关键是header_height和footer_height两个参数需要根据实际PDF调整。我一般先抽一页打印出所有字符的top值观察页眉页脚的分布再定阈值。如果PDF排版不统一可以按比例设置比如页眉占页面高度的8%。注意有些PDF的页眉页脚是作为独立对象嵌入的坐标可能和正文重叠这种情况坐标过滤会误伤正文。稳妥做法是先抽全文再用正则匹配“第X页”“Page X of Y”这类模式做二次清洗。3.2 中文分词自定义词典决定关键词质量的上限jieba的默认词典覆盖了通用词汇但每个行业都有自己的专有名词。比如做医疗PDF默认词典可能把“心肌梗死”切成“心肌”和“梗死”做法律PDF“不可抗力”可能被切碎。这些被切碎的词TF-IDF算出来权重再高也没意义因为语义已经丢了。解决办法是加载自定义词典。我通常从两个来源构建一是项目相关的术语表二是先用jieba跑一遍把高频的、被切错的词人工整理出来加进去。import jieba # 加载自定义词典每行一个词可带词频和词性 jieba.load_userdict(custom_dict.txt) # 加载停用词表 def load_stopwords(path): with open(path, r, encodingutf-8) as f: return set(line.strip() for line in f) stopwords load_stopwords(stopwords.txt) def segment(text): words jieba.lcut(text) # 过滤停用词、单字、纯数字和标点 return [w for w in words if w not in stopwords and len(w) 1 and not w.isdigit()]这里有几个细节值得说。第一len(w) 1过滤单字因为中文单字大多没有独立语义像“的”“了”“和”都是单字过滤掉能大幅降噪。第二not w.isdigit()过滤纯数字页码、年份这类数字对关键词没贡献。第三停用词表要持续迭代我一般会先跑一遍把结果里明显不该出现的词追加进去跑个三四轮就收敛了。3.3 TF-IDF参数计算平滑项和归一化的取舍手写TF-IDF时有两个参数需要仔细定IDF的平滑项和TF的归一化方式。IDF的标准公式是log(N / df)其中N是文档总数df是包含该词的文档数。当某个词在所有文档都出现时df等于Nlog(1)0这个词的IDF就是0直接出局。但更常见的问题是df可能为0理论上不会但代码里要防以及N很小时IDF波动大。所以我加了平滑import math def compute_idf(docs_words): N len(docs_words) # 统计每个词出现在多少篇文档中 df {} for words in docs_words: for w in set(words): df[w] df.get(w, 0) 1 # 加平滑项避免除零和极端值 idf {w: math.log((N 1) / (df[w] 1)) 1 for w in df} return idf这里的1平滑是常见做法保证IDF永远为正且当df接近N时不会直接归零。TF部分我用的是词频除以文档总词数def compute_tf(words): tf {} total len(words) for w in words: tf[w] tf.get(w, 0) 1 return {w: c / total for w, c in tf.items()}归一化的好处是消除文档长度差异。一篇一万字的文档和一篇一千字的文档同一个词出现10次前者TF是0.001后者是0.01后者更能代表这篇文档的主题。如果不归一化长文档会系统性地霸占关键词榜。3.4 结果排序与输出怎么判断关键词“好不好”算出TF-IDF后按分值降序取Top N。但分值高不代表词好我一般会做两轮人工校验。第一轮看Top 20里有没有明显的噪声词停用词漏网、页眉残留有就补进停用词表重跑。第二轮看Top 20是否覆盖了文档的核心主题如果一份讲“供应链金融”的PDFTop词里没有“供应链”“融资”“应收账款”这类词说明分词或词典有问题。输出格式我习惯用CSV每行是“文档名, 关键词, TF-IDF分值”方便后续用Excel做透视或筛选。如果文档量大还会额外输出一个“全局词云数据”把所有文档的Top词合并统计看整个语料的主题分布。4. 完整实操流程从零跑通一个可复现的版本4.1 环境准备与依赖安装先把环境搭起来。我用的Python版本是3.9以上依赖库不多一条命令搞定pip install pdfplumber jiebapdfplumber会自动带上pdfminer.six作为底层依赖。jieba是纯Python实现安装很快。如果你后续想画词云再加wordcloud和matplotlib但核心功能不需要它们。目录结构我建议这样组织方便管理project/ ├── pdfs/ # 存放待处理的PDF ├── output/ # 输出结果 ├── custom_dict.txt # 自定义词典 ├── stopwords.txt # 停用词表 └── main.py # 主程序停用词表可以从网上找一份通用的中文停用词表打底然后根据你的领域往里加。我一般会加“本文”“研究”“分析”“方法”这类学术套话以及“公司”“部门”这类在特定语料里高频但无区分度的词。4.2 主程序编写把四个阶段串起来主程序按“抽取→分词→统计→输出”的顺序组织。先遍历pdfs目录对每个PDF抽文本、分词把所有文档的词列表收集到一个大列表里然后统一算IDF再逐篇算TF-IDF。import os import csv import pdfplumber import jieba def load_stopwords(path): with open(path, r, encodingutf-8) as f: return set(line.strip() for line in f) def extract_text(pdf_path): text [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: t page.extract_text() if t: text.append(t) return \n.join(text) def segment(text, stopwords): words jieba.lcut(text) return [w for w in words if w not in stopwords and len(w) 1 and not w.isdigit()] def main(): jieba.load_userdict(custom_dict.txt) stopwords load_stopwords(stopwords.txt) pdf_dir pdfs docs [] # 每篇文档的词列表 names [] for fname in os.listdir(pdf_dir): if not fname.endswith(.pdf): continue path os.path.join(pdf_dir, fname) text extract_text(path) words segment(text, stopwords) docs.append(words) names.append(fname) print(f{fname}: 抽取{len(words)}个有效词) # 计算IDF N len(docs) df {} for words in docs: for w in set(words): df[w] df.get(w, 0) 1 idf {w: math.log((N 1) / (df[w] 1)) 1 for w in df} # 逐篇计算TF-IDF并输出 os.makedirs(output, exist_okTrue) with open(output/keywords.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([文档, 关键词, TF-IDF分值]) for name, words in zip(names, docs): tf {} for w in words: tf[w] tf.get(w, 0) 1 total len(words) scores {w: (c / total) * idf.get(w, 0) for w, c in tf.items()} top sorted(scores.items(), keylambda x: x[1], reverseTrue)[:15] for w, s in top: writer.writerow([name, w, round(s, 6)]) print(处理完成结果已写入 output/keywords.csv) if __name__ __main__: main()这段代码可以直接跑前提是pdfs目录里有PDF文件custom_dict.txt和stopwords.txt存在。输出用utf-8-sig编码是为了Excel打开CSV不乱码这个细节很多人会忽略导致中文显示成乱码。4.3 参数调优实录一次真实的关键词优化过程我拿一批技术文档跑第一遍时Top关键词里出现了“系统”“功能”“支持”“使用”这类词。这些词在每篇文档都出现IDF很低按理说不该上榜但它们TF太高硬是把分值拉起来了。这说明停用词表不够需要把这些通用词加进去。第二遍跑完“系统”“功能”没了但出现了“本文”“介绍”“如下”。这是典型的文档结构词继续加停用词。第三遍关键词开始有业务含义了但发现“数据”这个词在好几篇里都排第一区分度不够。查了一下这批文档确实都涉及数据但每篇的侧重点不同。这时候单纯靠停用词解决不了需要调整IDF的平滑策略或者引入“词性过滤”只保留名词和动词。我最终的做法是加了一层词性过滤用jieba的posseg模块只保留名词n开头、动词v开头和英文eng。这样“数据”如果被标为名词还是会保留但“如下”“介绍”这类会被过滤掉。词性过滤的代价是速度慢一些但关键词质量提升明显。优化轮次主要问题处理手段效果第一轮通用词霸榜补充停用词通用词减少第二轮结构词残留继续补停用词结构词清除第三轮区分度不足词性过滤关键词更聚焦第四轮专有名词被切碎自定义词典语义完整4.4 结果验证怎么确认算出来的关键词是对的验证分两步。第一步是抽样人工核对随机挑三篇文档看Top 10关键词是否和文档主题吻合。如果一篇讲“容器编排”的文档Top词里有“容器”“集群”“调度”“镜像”那基本没问题如果出现“我们”“可以”“进行”说明清洗不到位。第二步是跨文档对比看同一个词在不同文档里的分值差异。如果某个词在所有文档里分值都差不多说明它区分度低可以考虑从结果里剔除。我一般会算一个“分值方差”方差小的词直接过滤掉只保留那些在某些文档里特别突出的词。提示TF-IDF本质是统计方法它不知道词义。同义词如“电脑”和“计算机”会被当成两个词分别计算导致分值分散。如果语料里同义词多可以考虑做同义词合并或者用词向量做语义聚类但那是另一个量级的工程了。5. 常见问题与排查技巧实录5.1 抽取阶段的高频问题问题一抽出来的文本全是乱码或方块。这通常是PDF的字体编码问题pdfplumber对某些嵌入字体的支持不完善。排查方法是换pymupdf试一下如果pymupdf能正常抽说明是库的兼容性问题。解决手段有限可以尝试指定laparams参数调整pdfminer的解析策略或者对PDF做一次“打印为PDF”的预处理重新生成标准编码的副本。问题二文本顺序错乱段落被拆得七零八落。多栏排版的PDF容易出现这个问题pdfplumber按坐标顺序抽字符多栏时可能左栏右栏交错。解决办法是用page.extract_text(layoutTrue)保留布局或者按x坐标把页面分成左右两栏分别抽取。我遇到多栏文档时一般先抽一页看字符的x坐标分布找到栏与栏之间的空隙坐标然后按这个坐标切分。问题三表格内容混进正文变成一堆无意义的数字。pdfplumber的extract_text()会把表格里的文字也抽出来但顺序可能错乱。如果表格内容对关键词分析是噪声可以在抽取前用page.find_tables()定位表格区域把这些区域的字符排除掉。5.2 分词与统计阶段的典型故障故障一关键词里出现大量单字。检查len(w) 1的过滤是否生效。如果生效了还有单字可能是jieba把某个词切成了单字比如“的”被单独切出来。这时候要看自定义词典是否覆盖了这些词或者停用词表是否遗漏。故障二某篇文档的关键词全是另一篇文档的词。这通常是因为两篇文档内容高度相似IDF区分不开。解决办法是引入文档聚类的预处理把相似文档合并或标记避免它们互相干扰。或者改用TF-ISF等变体但那是更复杂的方案。故障三程序跑得特别慢。瓶颈通常在PDF抽取尤其是页数多、排版复杂的文档。优化手段有三个一是用多进程并行处理不同PDF二是先用pymupdf快速抽一遍只对抽不出文字的PDF用pdfplumber精细处理三是缓存抽取结果避免重复跑。5.3 常见问题速查表现象可能原因排查方法解决手段文本乱码字体编码问题换pymupdf对比预处理PDF或换库段落错乱多栏排版查看字符x坐标按栏切分抽取表格混入未排除表格区用find_tables定位排除表格区域字符单字残留过滤未生效打印分词结果检查过滤条件关键词雷同文档相似度高算文档相似度聚类或合并处理运行缓慢PDF抽取耗时计时各阶段并行或缓存5.4 几条踩坑换来的经验第一不要等到最后才验证抽取质量。我一开始图快直接跑完整流程结果关键词一塌糊涂回头查发现是抽取阶段就把页眉页脚混进去了。后来改成每抽一篇就打印前200字看看问题当场就能发现。第二停用词表要按语料定制。通用停用词表只能解决“的”“了”这类但每个领域的套话不同。技术文档有“系统”“功能”法律文档有“甲方”“乙方”学术文档有“研究”“分析”。我现在的做法是每接一批新语料先跑一遍把Top 50里的非业务词全部加进停用词表再跑第二遍。第三TF-IDF不是万能的。它擅长找“区分词”不擅长找“主题词”。如果一份文档的核心主题词在其他文档也频繁出现它的TF-IDF分值会被压低。这种情况下可以结合词频TF一起看或者用TextRank等基于图的方法做补充。我一般会把TF-IDF和纯词频的结果都输出交叉对比。第四中文分词的效果高度依赖词典。jieba的默认词典对通用文本够用但专业领域一定要加自定义词典。我做过一个对比实验同一批医疗PDF不加自定义词典时Top关键词里有“患者”“治疗”这类通用词加了“心肌梗死”“冠状动脉”等专有词后关键词的专业度明显提升。6. 扩展方向这套流程还能怎么用跑通基础版本后这套流程可以往几个方向扩展。第一个方向是批量文档的主题聚类把每篇文档的TF-IDF向量作为特征用KMeans或层次聚类分组自动把相似文档归到一起。第二个方向是关键词随时间的变化分析如果PDF有日期信息可以按时间切片看哪些词在某个时间段突然变热。第三个方向是结合词向量做语义搜索把关键词映射到向量空间支持“找和这份文档主题相似的其他文档”这类需求。我自己最常用的扩展是输出词云数据。把每篇文档的Top词和分值导出后用wordcloud库画一张图分值越高的词字号越大。这张图放在报告开头比一堆表格直观得多。画词云时注意中文字体要指定否则会显示成方块font_path参数指向系统里的中文字体文件即可。另外如果PDF数量很大上千份单机跑会吃力可以考虑把抽取和分词阶段拆成独立任务用消息队列分发多台机器并行处理。但这是工程化的范畴了对于几十到几百份文档的日常需求单机脚本完全够用。我处理过最大的一批是三百多份PDF单机跑完抽取加统计大概十几分钟瓶颈在PDF抽取分词和统计反而很快。
1. 从一份PDF到一张关键词地图这个项目到底在解决什么问题手里有一堆PDF想快速知道每份文件到底在讲什么、哪些词是这份文件区别于其他文件的“指纹词”——这个需求在文档管理、竞品分析、学术文献综述、合同归档等场景里反复出现。我最早接触这类需求是在做一批技术白皮书的归档整理几十份PDF混在一起人工翻目录效率极低于是就想用Python把这件事自动化读取PDF文本做分词算TF-IDF把每份文档权重最高的词拎出来形成一张“关键词地图”。这个项目的核心链路其实就四步PDF文本提取 → 中文分词 → TF-IDF计算 → 结果排序与输出。标题里提到的“plumer”大概率是“plumber”的拼写变体在PDF处理语境下它指的是一类负责“管道式”抽取PDF内容的工具或思路——把PDF当作数据源通过一条处理管道把文本、表格、元数据逐层抽出来。不管具体用哪个库底层逻辑是一致的先把非结构化的PDF变成结构化文本再交给统计模型去算权重。适合谁来参考这篇内容如果你有Python基础能看懂列表和字典操作但没怎么碰过PDF解析和文本挖掘那这篇正好。如果你已经用过pdfplumber或PyPDF2但算出来的TF-IDF结果总是不理想关键词里混着一堆“的”“了”“我们”那这篇里的分词和停用词处理部分能帮你省不少调试时间。整篇内容我会按真实项目推进的顺序来讲从选型、踩坑、参数计算到结果验证尽量把每个“为什么这么选”说清楚。2. 整体方案设计与工具选型为什么是这套组合2.1 核心思路拆解把PDF当成一条数据流水线很多人一上来就纠结“用哪个库读PDF最好”但更该先想清楚整条流水线的形状。我的做法是把项目拆成三个独立阶段每个阶段只负责一件事抽取阶段只负责把PDF里的文字原样拿出来不做任何清洗和判断输出纯文本。加工阶段负责分词、去停用词、归一化把文本变成词列表。统计阶段负责构建词频矩阵、计算TF-IDF、排序输出。这样拆的好处是任何一段出问题都能单独定位。比如关键词里混进了页眉页脚那问题一定在抽取阶段如果关键词全是“系统”“功能”这种通用词那问题在加工阶段的停用词表。我见过不少人把三步揉在一个函数里结果调参时改一处崩三处非常痛苦。2.2 工具选型对比pdfplumber、PyPDF2、pdfminer到底怎么选PDF解析库的选择直接决定抽取质量。我实测过几个主流方案整理成下面这张表方便你按自己的文档类型对号入座。工具文本抽取质量表格支持中文支持安装依赖适用场景pdfplumber高保留布局信息强可提取表格好依赖pdfminer.six复杂排版、含表格的文档PyPDF2中纯文本为主弱一般轻量结构简单的纯文本PDFpdfminer.six高底层控制细中好稍重需要精细控制抽取逻辑pymupdf很高速度快中好需编译大批量、追求速度我最终选的是pdfplumber原因有三点。第一它对中文PDF的字符编码处理比较稳不会出现乱码方块第二它能拿到每个字符的坐标后续如果想过滤页眉页脚可以根据y坐标做裁剪第三它的表格抽取能力在同类里属于第一梯队万一后续要扩展成“PDF表格转Excel”不用换库。PyPDF2虽然轻但遇到扫描版或复杂排版的PDF经常抽出一堆空行调试成本反而更高。提示如果你的PDF是扫描件图片型上面这些库都抽不出文字需要先做OCR。判断方法很简单用pdfplumber打开后看page.chars是否为空为空基本就是扫描件。2.3 分词与TF-IDF方案为什么不用sklearn一把梭TF-IDF的计算scikit-learn的TfidfVectorizer确实能一行搞定但我这个项目里没有直接用它而是选择了jieba分词 手写TF-IDF的组合。原因在于中文分词的粒度控制。sklearn的向量化默认按空格切词对中文完全不适用必须先分词再喂进去。而jieba支持自定义词典和停用词表能针对不同领域的PDF做定制。TF-IDF的公式本身不复杂但理解它才能调好参数TF词频某个词在单篇文档中出现的次数。常见变体是除以文档总词数做归一化避免长文档天然占优。IDF逆文档频率log(总文档数 / 包含该词的文档数)。一个词在越多文档里出现说明它越通用IDF越低。TF-IDF两者相乘。既要在本篇里出现得多又要在其他篇里出现得少才能拿高分。我手写实现而不是调库主要是为了能灵活调整IDF的平滑项和TF的归一化方式。比如当文档总数很少时IDF容易出现除零需要加平滑当某篇文档特别长时纯词频会让它霸榜需要做长度归一化。这些细节在库函数里是黑盒自己写一遍反而心里有数。3. 核心细节解析与实操要点每一步的坑在哪3.1 PDF文本抽取页眉页脚是关键词污染的头号元凶用pdfplumber抽取文本最基础的写法是遍历每一页调extract_text()。但直接这么干你会发现每页的页眉比如公司名、文档标题和页脚页码、保密声明会被重复抽进来。这些词在每页都出现IDF极低按理说不会成为关键词但如果页眉里恰好有某个业务词它就会污染结果。我的处理办法是利用pdfplumber的坐标信息做裁剪。每一页的字符都有top和bottom坐标页眉通常在页面顶部固定高度内页脚在底部固定高度内。可以先抽一页看看页眉页脚的坐标范围然后在抽取时过滤掉这些区域的字符。import pdfplumber def extract_text_without_header_footer(pdf_path, header_height50, footer_height50): full_text [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: height page.height # 只保留中间区域的字符 chars [c for c in page.chars if header_height c[top] height - footer_height] # 按行重组文本 text .join(c[text] for c in chars) full_text.append(text) return \n.join(full_text)这段代码的关键是header_height和footer_height两个参数需要根据实际PDF调整。我一般先抽一页打印出所有字符的top值观察页眉页脚的分布再定阈值。如果PDF排版不统一可以按比例设置比如页眉占页面高度的8%。注意有些PDF的页眉页脚是作为独立对象嵌入的坐标可能和正文重叠这种情况坐标过滤会误伤正文。稳妥做法是先抽全文再用正则匹配“第X页”“Page X of Y”这类模式做二次清洗。3.2 中文分词自定义词典决定关键词质量的上限jieba的默认词典覆盖了通用词汇但每个行业都有自己的专有名词。比如做医疗PDF默认词典可能把“心肌梗死”切成“心肌”和“梗死”做法律PDF“不可抗力”可能被切碎。这些被切碎的词TF-IDF算出来权重再高也没意义因为语义已经丢了。解决办法是加载自定义词典。我通常从两个来源构建一是项目相关的术语表二是先用jieba跑一遍把高频的、被切错的词人工整理出来加进去。import jieba # 加载自定义词典每行一个词可带词频和词性 jieba.load_userdict(custom_dict.txt) # 加载停用词表 def load_stopwords(path): with open(path, r, encodingutf-8) as f: return set(line.strip() for line in f) stopwords load_stopwords(stopwords.txt) def segment(text): words jieba.lcut(text) # 过滤停用词、单字、纯数字和标点 return [w for w in words if w not in stopwords and len(w) 1 and not w.isdigit()]这里有几个细节值得说。第一len(w) 1过滤单字因为中文单字大多没有独立语义像“的”“了”“和”都是单字过滤掉能大幅降噪。第二not w.isdigit()过滤纯数字页码、年份这类数字对关键词没贡献。第三停用词表要持续迭代我一般会先跑一遍把结果里明显不该出现的词追加进去跑个三四轮就收敛了。3.3 TF-IDF参数计算平滑项和归一化的取舍手写TF-IDF时有两个参数需要仔细定IDF的平滑项和TF的归一化方式。IDF的标准公式是log(N / df)其中N是文档总数df是包含该词的文档数。当某个词在所有文档都出现时df等于Nlog(1)0这个词的IDF就是0直接出局。但更常见的问题是df可能为0理论上不会但代码里要防以及N很小时IDF波动大。所以我加了平滑import math def compute_idf(docs_words): N len(docs_words) # 统计每个词出现在多少篇文档中 df {} for words in docs_words: for w in set(words): df[w] df.get(w, 0) 1 # 加平滑项避免除零和极端值 idf {w: math.log((N 1) / (df[w] 1)) 1 for w in df} return idf这里的1平滑是常见做法保证IDF永远为正且当df接近N时不会直接归零。TF部分我用的是词频除以文档总词数def compute_tf(words): tf {} total len(words) for w in words: tf[w] tf.get(w, 0) 1 return {w: c / total for w, c in tf.items()}归一化的好处是消除文档长度差异。一篇一万字的文档和一篇一千字的文档同一个词出现10次前者TF是0.001后者是0.01后者更能代表这篇文档的主题。如果不归一化长文档会系统性地霸占关键词榜。3.4 结果排序与输出怎么判断关键词“好不好”算出TF-IDF后按分值降序取Top N。但分值高不代表词好我一般会做两轮人工校验。第一轮看Top 20里有没有明显的噪声词停用词漏网、页眉残留有就补进停用词表重跑。第二轮看Top 20是否覆盖了文档的核心主题如果一份讲“供应链金融”的PDFTop词里没有“供应链”“融资”“应收账款”这类词说明分词或词典有问题。输出格式我习惯用CSV每行是“文档名, 关键词, TF-IDF分值”方便后续用Excel做透视或筛选。如果文档量大还会额外输出一个“全局词云数据”把所有文档的Top词合并统计看整个语料的主题分布。4. 完整实操流程从零跑通一个可复现的版本4.1 环境准备与依赖安装先把环境搭起来。我用的Python版本是3.9以上依赖库不多一条命令搞定pip install pdfplumber jiebapdfplumber会自动带上pdfminer.six作为底层依赖。jieba是纯Python实现安装很快。如果你后续想画词云再加wordcloud和matplotlib但核心功能不需要它们。目录结构我建议这样组织方便管理project/ ├── pdfs/ # 存放待处理的PDF ├── output/ # 输出结果 ├── custom_dict.txt # 自定义词典 ├── stopwords.txt # 停用词表 └── main.py # 主程序停用词表可以从网上找一份通用的中文停用词表打底然后根据你的领域往里加。我一般会加“本文”“研究”“分析”“方法”这类学术套话以及“公司”“部门”这类在特定语料里高频但无区分度的词。4.2 主程序编写把四个阶段串起来主程序按“抽取→分词→统计→输出”的顺序组织。先遍历pdfs目录对每个PDF抽文本、分词把所有文档的词列表收集到一个大列表里然后统一算IDF再逐篇算TF-IDF。import os import csv import pdfplumber import jieba def load_stopwords(path): with open(path, r, encodingutf-8) as f: return set(line.strip() for line in f) def extract_text(pdf_path): text [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: t page.extract_text() if t: text.append(t) return \n.join(text) def segment(text, stopwords): words jieba.lcut(text) return [w for w in words if w not in stopwords and len(w) 1 and not w.isdigit()] def main(): jieba.load_userdict(custom_dict.txt) stopwords load_stopwords(stopwords.txt) pdf_dir pdfs docs [] # 每篇文档的词列表 names [] for fname in os.listdir(pdf_dir): if not fname.endswith(.pdf): continue path os.path.join(pdf_dir, fname) text extract_text(path) words segment(text, stopwords) docs.append(words) names.append(fname) print(f{fname}: 抽取{len(words)}个有效词) # 计算IDF N len(docs) df {} for words in docs: for w in set(words): df[w] df.get(w, 0) 1 idf {w: math.log((N 1) / (df[w] 1)) 1 for w in df} # 逐篇计算TF-IDF并输出 os.makedirs(output, exist_okTrue) with open(output/keywords.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([文档, 关键词, TF-IDF分值]) for name, words in zip(names, docs): tf {} for w in words: tf[w] tf.get(w, 0) 1 total len(words) scores {w: (c / total) * idf.get(w, 0) for w, c in tf.items()} top sorted(scores.items(), keylambda x: x[1], reverseTrue)[:15] for w, s in top: writer.writerow([name, w, round(s, 6)]) print(处理完成结果已写入 output/keywords.csv) if __name__ __main__: main()这段代码可以直接跑前提是pdfs目录里有PDF文件custom_dict.txt和stopwords.txt存在。输出用utf-8-sig编码是为了Excel打开CSV不乱码这个细节很多人会忽略导致中文显示成乱码。4.3 参数调优实录一次真实的关键词优化过程我拿一批技术文档跑第一遍时Top关键词里出现了“系统”“功能”“支持”“使用”这类词。这些词在每篇文档都出现IDF很低按理说不该上榜但它们TF太高硬是把分值拉起来了。这说明停用词表不够需要把这些通用词加进去。第二遍跑完“系统”“功能”没了但出现了“本文”“介绍”“如下”。这是典型的文档结构词继续加停用词。第三遍关键词开始有业务含义了但发现“数据”这个词在好几篇里都排第一区分度不够。查了一下这批文档确实都涉及数据但每篇的侧重点不同。这时候单纯靠停用词解决不了需要调整IDF的平滑策略或者引入“词性过滤”只保留名词和动词。我最终的做法是加了一层词性过滤用jieba的posseg模块只保留名词n开头、动词v开头和英文eng。这样“数据”如果被标为名词还是会保留但“如下”“介绍”这类会被过滤掉。词性过滤的代价是速度慢一些但关键词质量提升明显。优化轮次主要问题处理手段效果第一轮通用词霸榜补充停用词通用词减少第二轮结构词残留继续补停用词结构词清除第三轮区分度不足词性过滤关键词更聚焦第四轮专有名词被切碎自定义词典语义完整4.4 结果验证怎么确认算出来的关键词是对的验证分两步。第一步是抽样人工核对随机挑三篇文档看Top 10关键词是否和文档主题吻合。如果一篇讲“容器编排”的文档Top词里有“容器”“集群”“调度”“镜像”那基本没问题如果出现“我们”“可以”“进行”说明清洗不到位。第二步是跨文档对比看同一个词在不同文档里的分值差异。如果某个词在所有文档里分值都差不多说明它区分度低可以考虑从结果里剔除。我一般会算一个“分值方差”方差小的词直接过滤掉只保留那些在某些文档里特别突出的词。提示TF-IDF本质是统计方法它不知道词义。同义词如“电脑”和“计算机”会被当成两个词分别计算导致分值分散。如果语料里同义词多可以考虑做同义词合并或者用词向量做语义聚类但那是另一个量级的工程了。5. 常见问题与排查技巧实录5.1 抽取阶段的高频问题问题一抽出来的文本全是乱码或方块。这通常是PDF的字体编码问题pdfplumber对某些嵌入字体的支持不完善。排查方法是换pymupdf试一下如果pymupdf能正常抽说明是库的兼容性问题。解决手段有限可以尝试指定laparams参数调整pdfminer的解析策略或者对PDF做一次“打印为PDF”的预处理重新生成标准编码的副本。问题二文本顺序错乱段落被拆得七零八落。多栏排版的PDF容易出现这个问题pdfplumber按坐标顺序抽字符多栏时可能左栏右栏交错。解决办法是用page.extract_text(layoutTrue)保留布局或者按x坐标把页面分成左右两栏分别抽取。我遇到多栏文档时一般先抽一页看字符的x坐标分布找到栏与栏之间的空隙坐标然后按这个坐标切分。问题三表格内容混进正文变成一堆无意义的数字。pdfplumber的extract_text()会把表格里的文字也抽出来但顺序可能错乱。如果表格内容对关键词分析是噪声可以在抽取前用page.find_tables()定位表格区域把这些区域的字符排除掉。5.2 分词与统计阶段的典型故障故障一关键词里出现大量单字。检查len(w) 1的过滤是否生效。如果生效了还有单字可能是jieba把某个词切成了单字比如“的”被单独切出来。这时候要看自定义词典是否覆盖了这些词或者停用词表是否遗漏。故障二某篇文档的关键词全是另一篇文档的词。这通常是因为两篇文档内容高度相似IDF区分不开。解决办法是引入文档聚类的预处理把相似文档合并或标记避免它们互相干扰。或者改用TF-ISF等变体但那是更复杂的方案。故障三程序跑得特别慢。瓶颈通常在PDF抽取尤其是页数多、排版复杂的文档。优化手段有三个一是用多进程并行处理不同PDF二是先用pymupdf快速抽一遍只对抽不出文字的PDF用pdfplumber精细处理三是缓存抽取结果避免重复跑。5.3 常见问题速查表现象可能原因排查方法解决手段文本乱码字体编码问题换pymupdf对比预处理PDF或换库段落错乱多栏排版查看字符x坐标按栏切分抽取表格混入未排除表格区用find_tables定位排除表格区域字符单字残留过滤未生效打印分词结果检查过滤条件关键词雷同文档相似度高算文档相似度聚类或合并处理运行缓慢PDF抽取耗时计时各阶段并行或缓存5.4 几条踩坑换来的经验第一不要等到最后才验证抽取质量。我一开始图快直接跑完整流程结果关键词一塌糊涂回头查发现是抽取阶段就把页眉页脚混进去了。后来改成每抽一篇就打印前200字看看问题当场就能发现。第二停用词表要按语料定制。通用停用词表只能解决“的”“了”这类但每个领域的套话不同。技术文档有“系统”“功能”法律文档有“甲方”“乙方”学术文档有“研究”“分析”。我现在的做法是每接一批新语料先跑一遍把Top 50里的非业务词全部加进停用词表再跑第二遍。第三TF-IDF不是万能的。它擅长找“区分词”不擅长找“主题词”。如果一份文档的核心主题词在其他文档也频繁出现它的TF-IDF分值会被压低。这种情况下可以结合词频TF一起看或者用TextRank等基于图的方法做补充。我一般会把TF-IDF和纯词频的结果都输出交叉对比。第四中文分词的效果高度依赖词典。jieba的默认词典对通用文本够用但专业领域一定要加自定义词典。我做过一个对比实验同一批医疗PDF不加自定义词典时Top关键词里有“患者”“治疗”这类通用词加了“心肌梗死”“冠状动脉”等专有词后关键词的专业度明显提升。6. 扩展方向这套流程还能怎么用跑通基础版本后这套流程可以往几个方向扩展。第一个方向是批量文档的主题聚类把每篇文档的TF-IDF向量作为特征用KMeans或层次聚类分组自动把相似文档归到一起。第二个方向是关键词随时间的变化分析如果PDF有日期信息可以按时间切片看哪些词在某个时间段突然变热。第三个方向是结合词向量做语义搜索把关键词映射到向量空间支持“找和这份文档主题相似的其他文档”这类需求。我自己最常用的扩展是输出词云数据。把每篇文档的Top词和分值导出后用wordcloud库画一张图分值越高的词字号越大。这张图放在报告开头比一堆表格直观得多。画词云时注意中文字体要指定否则会显示成方块font_path参数指向系统里的中文字体文件即可。另外如果PDF数量很大上千份单机跑会吃力可以考虑把抽取和分词阶段拆成独立任务用消息队列分发多台机器并行处理。但这是工程化的范畴了对于几十到几百份文档的日常需求单机脚本完全够用。我处理过最大的一批是三百多份PDF单机跑完抽取加统计大概十几分钟瓶颈在PDF抽取分词和统计反而很快。
