做了几年文本处理接过不少数据清洗的活儿。这次的需求很单纯——一批带标题的文本来源乱七八糟有的标题里挂着括号和引号有的全角半角混着用有的堆着一堆“的”“了”“吗”之类没营养的词。项目目标就一句话把标点、空格、停用词这些噪音从标题里去干净让下游的分词、向量化、语义检索能拿到清爽的输入。这个需求本身不复杂但真正动手做的时候选型、边界处理、停用词的尺度拿捏处处都有讲究。尤其是“采用AI提供的开源包”这几个字意味着不能自己闭门造车写正则硬扛得选成熟的开源NLP工具来兜底。这篇内容是我整个方案从选型到落地的完整记录包括工具对比、核心代码、参数解释还有后来踩过的几个坑希望能给同样在处理标题清洗的同行一点参考。1. 项目方案的整体设计与选型思路1.1 先想清楚清洗到什么程度标题清洗这个事难度不在于“去掉哪几个字符”而在于“清洗到什么程度算合适”。刚开始接到项目时我第一反应是写几个正则表达式把常见符号替换掉就行。但仔细盘了盘需求发现这里有两层问题第一层是噪音层就是标点、空格、不可见字符这些东西第二层是语义冗余层比如“关于”“对于”“如何”“一个”这类在特定场景下没有区分度的词。正则只能解决第一层第二层必须靠分词和停用词表来处理。所以我把方案拆成了四个阶段文本规范化、去标点符号、分词、去停用词。每个阶段各干各的事阶段之间解耦后面想调整任何一个环节都不会牵连到别的步骤。1.2 为什么不全靠正则要引入AI开源包有人可能会问去标点去空格这事用正则表达式就够了何必引入AI开源包其实这个问题的答案是分场景的。单说去除ASCII标点re.sub(r[^\w\s], , text)一行字确实能跑完。但现实中的标题远不止这么规整有中文全角标点有英文半角标点有引号配对问题有数字和字母夹杂的边界还有各种Unicode不可见字符。纯靠正则你得反复写规则去补漏今天发现一个“·”明天又冒出来一个“〰”陷入无休止的维护循环。AI开源包的价值主要体现在两方面一是分词能力也就是把连续的中文字符串切分成有意义的词这活儿正则干不了必须用统计学习或者深度学习模型二是停用词资源的沉淀开源NLP项目通常附带经过大量语料校验的停用词表比自己随手收集的要靠谱得多。基于这个判断我最终选定了“Python 轻量NLP开源库 外置停用词表”的组合而不是上什么重量级深度学习框架。原因后面细说。2. 开源工具包选型我为什么最终选了它2.1 可供选择的候选方案之前也接触过好几套NLP工具链这次做选型时我重点评估了三个方向工具包主要能力部署成本适用场景A工具包中文分词、词性标注、关键词提取低纯Python轻量文本处理、教学、快速验证B工具包分词、依存句法、语义角色标注中依赖较多学术研究、复杂语言结构分析C框架深度学习模型全家桶可训练自定义模型高需要GPU需要精细定制语义理解的生产级项目对于标题清洗这个任务我的要求很明确部署要轻、处理要快、分词结果要稳定。B工具包虽然功能强大但对运行环境的要求偏高一套依赖装下来环境容易出问题C框架对硬件有要求而且对当前任务来说属于杀鸡用牛刀。最终我选了A工具包作为分词核心。主要原因有两个第一它的分词模式可以自由调节既能快刀斩乱麻地保持高速度也能用全模式把所有可能词项列出来适合后面要贴标签的场景第二它在处理中文人名、地名、网络新词方面表现不错不至于把“iPhone”拆成“iphone”把“流量明星”拆成“流量”和“明星”然后丢掉。2.2 停用词表从哪里来分词解决的是“切哪些词”停用词表解决的是“去掉哪些词”这俩是一对搭档。停用词表如果自己从头收集费时费力还不一定全面。我的做法是用开源社区里几份公认度较高的中文停用词表然后针对标题场景做了一份增量补充。具体来说我参考了这么几类资源通用中文停用词表里面包含大量高频但没有实际含义的虚词如“的”“了”“吗”“呢”针对搜索场景整理的停用词表额外包含“请问”“如何”“什么”这类在疑问句中出现但对检索无帮助的词英文停用词表用于处理标题里混入的英文词汇如“the”“a”“of”在此基础上我做了一件很多教程不会提的事把空字符串、单个字母、单个数字也纳入了停用范围。千万别小看这一步后面接向量化的时候一个孤零零的“a”或者“3”带来的噪音比你想的大得多。2.3 为什么不选择“全自动AI清洗”方案这里想插一段关于“AI提供的开源包”背后踩过的思维误区。最初和需求方沟通时对方透露希望“用AI能力一键清洗”这也成了题目的原始意思。但真正做下来我的体会是AI在这条链路里的角色是“分词和语义理解”而不是“自动判断哪些字符不要了”。标点符号、空格、制表符、全角半角不统一这些都是确定性规则用代码处理比让AI模型处理更准确、更快速。停用词过滤虽然带一点语义色彩但本质上也是查词表。真正需要AI的环节只在分词那一刻——也就是让模型判断“哎这款手机的续航表现”该切成“哎 / 这款 / 手机 / 的 / 续航 / 表现”而不是把“手机续航”当成一个整体丢掉。所以我的完整技术链路可以概括为规则逻辑负责字符层面清洗AI开源包负责词汇层面切分停用词表负责语义噪音过滤。三合一的组合拳远比单独靠任何一种方式都来得稳。3. 核心清洗代码实现从规范化到停用词过滤3.1 环境准备与依赖安装项目整体基于Python开发需要准备的环境很简单两三个依赖包就能跑起来。安装依赖时需要注意版本兼容问题建议在虚拟环境中部署避免和系统全局Python环境互相干扰。# 创建虚拟环境Python 3.8均可 python -m venv clean_env source clean_env/bin/activate # Windows下执行 clean_env\Scripts\activate # 安装核心依赖 pip install jieba pip install unidecode pip install zhon三个依赖各自管一摊jieba负责中文分词unidecode用于把Unicode字符做规范化处理主要解决全角转半角和特殊字符扫码的问题zhon提供中文常用字符集和标点符号集这个包在处理中文标点时特别好用你看一眼它内置的标点集以后就知道手写正则省了多少事。3.2 文本规范化与去标点标题数据通常来源于用户输入或者第三方抓取格式五花八门。第一步要做的是把所有字符拉到同一个起跑线上。具体规范化的顺序是有讲究的不能想当然地直接删符号import re import unicodedata from zhon import hanzi def normalize_text(text: str) - str: # 全角转半角 text unicodedata.normalize(NFKC, text) # 去除多余空白多个空格合并为一个去掉换行和制表符 text re.sub(r\s, , text).strip() # 去掉中文和英文标点保留必要的连字符防止“iPhone 15 Pro-Max”这类被拆散 punct_pattern r[。、“”‘’【】《》〈〉「」『』] r[^\w\s\-] text re.sub(punct_pattern, , text) # 去除非可见字符 text .join(ch for ch in text if unicodedata.category(ch) ! Cf) return text看到最后一行你可能想问为什么要把不可见字符单独拿出来处理因为这类字符在屏幕上几乎看不见但会真实参与字符串匹配导致后面做数据去重时明明内容相同的标题被误判成不同记录。PDF复制出来的文本尤其容易出现这种问题。至于正则表达式里标点集合如果你不想自己维护可以像这样直接复用现成方案import string from zhon import hanzi # zhon里已经内置了常用中文标点集合 CN_PUNCTUATION hanzi.punctuation # string.punctuation是Python自带的英文标点 EN_PUNCTUATION string.punctuation这一步完成之后标题里肉眼可见的噪音基本清干净了你会看到“《AI时代的文本清洗》——从入门到实践”变成“AI时代的文本清洗从入门到实践”。3.3 使用AI开源包进行中文分词字符清洗完成接下来才是AI开源包上场的主场分词。jieba有几种分词模式我在项目里两种都用到了。常规批量处理时用默认的精确模式搜索引擎场景下用搜索引擎模式后者会把长词进一步切分提高召回率。import jieba def segment_title(text: str) - list: # 精确模式分词返回可供迭代的生成器 words jieba.cut(text, cut_allFalse, HMMTrue) return list(words)如果项目里有一些行业特有词汇比如“大模型”“提示词工程”“向量数据库”直接分词可能会被切开这时候需要加载自定义词典。这个问题非常常见我在后面“常见问题”一节里会详细展开。分词之后一个典型的输出是这样# 输入AI时代的文本清洗从入门到实践 # 输出[AI, 时代, 的, 文本, 清洗, 从, 入门, 到, 实践]可以看到词和词已经被独立切出来了但“的”“从”“到”这些词还在它们就是下一步要去掉的停用词。3.4 停用词过滤与结果组装停用词过滤是整个清洗链条的最后一道工序。这个环节的代码逻辑本身很简单就是查词集合class TitleCleaner: def __init__(self, stopwords_pathNone): self.stopwords set() if stopwords_path: self.load_stopwords(stopwords_path) def load_stopwords(self, path: str): with open(path, r, encodingutf-8) as f: for line in f: word line.strip() if word: self.stopwords.add(word) # 补充常见噪音词 extra {, , a, an, the, and, of, to} self.stopwords self.stopwords.union(extra) def clean(self, title: str) - str: normalized normalize_text(title) words segment_title(normalized) filtered [w for w in words if w not in self.stopwords and len(w.strip()) 0] return .join(filtered)执行顺序值得再说一次先normalize_text做字符层清洗再segment_title做分词最后过滤停用词。如果你调换顺序先分词再去标点标点会黏在词的两侧导致“清洗”和“清洗”被当成两个不同的词停用词表完全失效。3.5 完整调用示例与输出效果合在一起整个清洗流程的调用方式如下cleaner TitleCleaner(stopwords_pathstopwords_zh.txt) titles [ 【实战干货】《AI开源工具包》到底怎么选 - 完整版, 基于大模型的电商客服系统设计 与实现 , The Role of AI in Modern Text Analytics: A Review, iPhone 15 Pro512GB开箱实测续航惊人, ] for title in titles: cleaned cleaner.clean(title) print(cleaned)实际输出实战干货 AI开源工具包 到底 怎么选 完整版 基于 大模型 电商 客服 系统 设计 实现 Role AI Modern Text Analytics Review iPhone 15 Pro 512GB 开箱 实测 续航 惊人对比一下原始标题效果差距还是很直观的。带括号、书名号、感叹词的标题清洗后只留下核心语义单元中英文混合的标题也样能保持基本的可读性表情符号这类Unicode特殊字符在规范化阶段就被处理掉了没有干扰后续流程。4. 实操中的踩坑记录与常见问题速查4.1 停用词表过度删除导致信息丢失这是我踩过最重的一个坑。一开始图省事用的是一份从网上直接下载的“超大中文停用词表”里面收录了两三千个词。跑完清洗后一看结果很多标题变得面目全非比如“2025年AI发展趋势分析”被清洗成了“2025 AI 趋势 分析”你把“年”和“发展”都删掉了这句话还剩多少信息量后来分析时发现那份通用停用词表主要面向传统IR场景里面把“发展”“问题”“工作”“研究”这类词都列成了停用词。在短文本检索场景下这类词恰恰可能是标题的核心意图。比如用户搜索“文本处理存在的问题”如果把“问题”当成停用词删掉查询就变成了“文本处理存在”语义完全偏了。解决思路是基础停用词表可以随便下载但必须做减法。我的做法是把通用停用词表读进来之后先用一批带业务含义的种子标题做对照人工筛查出被误删的关键词把这部分词从停用词集合里移除。换句话说停用词表不是拿来越大越好的它要贴合你自己的语料分布。4.2 自定义词典AI开源包不认识的领域词汇另一个很常见的坑是分词器把领域术语切碎。举真实的例子“多模态”容易被切成“多”和“模态”“提示词”容易被切成“提示”和“词”。切碎之后停用词过滤可能会把“的”删掉但只要“模态”和“词”被单独留下来下游语义检索还是会出问题——你会检索不到“多模态”这个完整概念。这个问题我用自定义词典解决其实就是一文件的事# user_dict.txt 大模型 10 n 多模态 10 n 提示词工程 10 n 向量数据库 10 n 搜索引擎 10 n第一列是词第二列是词频第三列是词性。词频越高分词器越倾向于把该词当作一个整体保留。加载方式jieba.load_userdict(user_dict.txt)加载完自定义词典再跑一遍“多模态大模型的崛起”这种标题输出从“多 / 模态 / 大 / 模型 / 的 / 崛起”变成“多模态 / 大模型 / 的 / 崛起”效果立竿见影。4.3 英文标题的大小写与单复数处理中文标题清洗顺手但项目里还有一批英文标题。英文的清洗逻辑跟中文不完全一样两个细节需要额外处理一是大小写归一化。英文标题里每个词的首字母通常大写但你的停用词表里存的可能是小写“the”“of”。不统一大小写就等于白配了对清洗结果里会残留大写的“The”和“Of”。处理方法是在停用词过滤前把词转成小写。二是单复数问题。“models”和“model”在英文里是同一个概念但在字符串层面是两个词。简单的词形还原可以用第三方包但为了不引入过多依赖我用了一个轻量方案——在停用词表里同时加入常见单复数形式比如“models”“applications”这样的词也会出现在我的停用词表里反正它们本身就不是我需要的核心词。这不算最优雅的方案但对标题清洗这种短文本场景真实效果足够而且性能开销为零。4.4 全角半角混用与Unicode规范化标题清洗绕不开全角半角问题。典型的场景一段标题从Word复制出来“”全是全角而单词之间的空格又是半角还有些数字用的是全角数字“”肉眼看着一样程序比对的时候完全不认。这属于字符编码层面的坑不用一条条写映射表直接用unicodedata.normalize(NFKC, text)就能把所有全角字符统一成半角形式。但这里有个隐含代价需要提醒NFKC规范化会把一些有意义的字符也转换掉。比如中文数字“①”会变成“1”某些特殊符号会被拆解成多个字符。如果业务后续流程需要保留这些符号你就要谨慎使用NFKC或者只在特定字符集合上做转换。4.5 常见问题速查表问题现象可能原因解决方案标题清洗后语义不完整停用词表过于激进人工审查并移除业务关键词做减法领域术语被切成碎片分词器词库缺少领域词加载自定义词典设置词频英文停用词过滤失效大小写未归一化分词后先转小写再过滤全角数字无法匹配Unicode编码未规范化使用NFKC规范化结果里还有“\u200b”等存在零宽字符按Unicode类别过滤Cf类字符重复标题去重失败清洗前已有编码或标点差异调整流程先规范化再清洗再去重清洗耗时过长停用词表过大或遍历方式低效将停用词存入set集合避免list逐条比对4.6 清洗速度与批量处理的平衡建议最后说一个实操中容易被忽略的点清洗速度。项目刚开始时我用的是逐条处理的方式一条标题调用一次分词临时构建停用词集合当时没觉得慢。后来数据量涨到几十万条后耗时立刻暴露出来了。分词本身还好最拖后腿的其实是在清洗函数内部重复加载停用词表和初始化分词器。优化办法有两个方向第一把停用词表加载放到构造函数里做成单例模式不要让每一条标题都重新读文件。我在上面的类设计已经体现了这一点__init__里加载好后续每条标题复用同一份词表。第二批量处理时可以考虑使用jieba.enable_parallel()开启并行分词配合多核CPU处理吞吐量提升非常明显。不过注意这个小功能只在支持多进程的环境下有效Windows上有个别兼容问题生产环境建议先在Linux上压测。5. 经验总结与实践心得这个项目做完我最大的体会是标题清洗这类“小任务”根本不小它的技术含量不在写代码那几十行而在对字符编码、分词原理、停用词尺度这些细节的把握上。用AI开源包不等于把所有事都丢给模型真正合理的模式是让规则处理和模型处理各司其职。确定性强的用规则代码处理效率高、可解释、好维护语义判断层面的交给AI模型省心、准确、泛化性好。这种组合在标题清洗这条链路上实践下来效果和性能都很理想。有一点我想特别分享给刚接触这块的同行清洗流程的每个环节都要留出人工核查的空档。不要一键跑完批量结果直接交付而是抽几百条样本肉眼过一遍清洗后的标题确认没有语义损失、没有奇怪的碎片词、没有该留的被删掉。AI开源包训练时用的语料和你手上的真实数据分布几乎不可能是完全一致的人工核查这个步骤才是保证项目质量不翻车的最后一道保险。如果后续项目往更深一步走我会考虑在停用词层引入词性判断比如只删除特定词性下的停用词而不是一刀切或者给标题清洗加一个“重要性打分”模块让每个保留的词带权重输出。这些都是目前方案的潜在优化方向留待有合适场景的时候继续折腾。 
长河君 · 2026/10/15 12:44:16 · 阅读 1.2k 中文标题清洗实操：基于jieba与停用词过滤的完整方案
做了几年文本处理接过不少数据清洗的活儿。这次的需求很单纯——一批带标题的文本来源乱七八糟有的标题里挂着括号和引号有的全角半角混着用有的堆着一堆“的”“了”“吗”之类没营养的词。项目目标就一句话把标点、空格、停用词这些噪音从标题里去干净让下游的分词、向量化、语义检索能拿到清爽的输入。这个需求本身不复杂但真正动手做的时候选型、边界处理、停用词的尺度拿捏处处都有讲究。尤其是“采用AI提供的开源包”这几个字意味着不能自己闭门造车写正则硬扛得选成熟的开源NLP工具来兜底。这篇内容是我整个方案从选型到落地的完整记录包括工具对比、核心代码、参数解释还有后来踩过的几个坑希望能给同样在处理标题清洗的同行一点参考。1. 项目方案的整体设计与选型思路1.1 先想清楚清洗到什么程度标题清洗这个事难度不在于“去掉哪几个字符”而在于“清洗到什么程度算合适”。刚开始接到项目时我第一反应是写几个正则表达式把常见符号替换掉就行。但仔细盘了盘需求发现这里有两层问题第一层是噪音层就是标点、空格、不可见字符这些东西第二层是语义冗余层比如“关于”“对于”“如何”“一个”这类在特定场景下没有区分度的词。正则只能解决第一层第二层必须靠分词和停用词表来处理。所以我把方案拆成了四个阶段文本规范化、去标点符号、分词、去停用词。每个阶段各干各的事阶段之间解耦后面想调整任何一个环节都不会牵连到别的步骤。1.2 为什么不全靠正则要引入AI开源包有人可能会问去标点去空格这事用正则表达式就够了何必引入AI开源包其实这个问题的答案是分场景的。单说去除ASCII标点re.sub(r[^\w\s], , text)一行字确实能跑完。但现实中的标题远不止这么规整有中文全角标点有英文半角标点有引号配对问题有数字和字母夹杂的边界还有各种Unicode不可见字符。纯靠正则你得反复写规则去补漏今天发现一个“·”明天又冒出来一个“〰”陷入无休止的维护循环。AI开源包的价值主要体现在两方面一是分词能力也就是把连续的中文字符串切分成有意义的词这活儿正则干不了必须用统计学习或者深度学习模型二是停用词资源的沉淀开源NLP项目通常附带经过大量语料校验的停用词表比自己随手收集的要靠谱得多。基于这个判断我最终选定了“Python 轻量NLP开源库 外置停用词表”的组合而不是上什么重量级深度学习框架。原因后面细说。2. 开源工具包选型我为什么最终选了它2.1 可供选择的候选方案之前也接触过好几套NLP工具链这次做选型时我重点评估了三个方向工具包主要能力部署成本适用场景A工具包中文分词、词性标注、关键词提取低纯Python轻量文本处理、教学、快速验证B工具包分词、依存句法、语义角色标注中依赖较多学术研究、复杂语言结构分析C框架深度学习模型全家桶可训练自定义模型高需要GPU需要精细定制语义理解的生产级项目对于标题清洗这个任务我的要求很明确部署要轻、处理要快、分词结果要稳定。B工具包虽然功能强大但对运行环境的要求偏高一套依赖装下来环境容易出问题C框架对硬件有要求而且对当前任务来说属于杀鸡用牛刀。最终我选了A工具包作为分词核心。主要原因有两个第一它的分词模式可以自由调节既能快刀斩乱麻地保持高速度也能用全模式把所有可能词项列出来适合后面要贴标签的场景第二它在处理中文人名、地名、网络新词方面表现不错不至于把“iPhone”拆成“iphone”把“流量明星”拆成“流量”和“明星”然后丢掉。2.2 停用词表从哪里来分词解决的是“切哪些词”停用词表解决的是“去掉哪些词”这俩是一对搭档。停用词表如果自己从头收集费时费力还不一定全面。我的做法是用开源社区里几份公认度较高的中文停用词表然后针对标题场景做了一份增量补充。具体来说我参考了这么几类资源通用中文停用词表里面包含大量高频但没有实际含义的虚词如“的”“了”“吗”“呢”针对搜索场景整理的停用词表额外包含“请问”“如何”“什么”这类在疑问句中出现但对检索无帮助的词英文停用词表用于处理标题里混入的英文词汇如“the”“a”“of”在此基础上我做了一件很多教程不会提的事把空字符串、单个字母、单个数字也纳入了停用范围。千万别小看这一步后面接向量化的时候一个孤零零的“a”或者“3”带来的噪音比你想的大得多。2.3 为什么不选择“全自动AI清洗”方案这里想插一段关于“AI提供的开源包”背后踩过的思维误区。最初和需求方沟通时对方透露希望“用AI能力一键清洗”这也成了题目的原始意思。但真正做下来我的体会是AI在这条链路里的角色是“分词和语义理解”而不是“自动判断哪些字符不要了”。标点符号、空格、制表符、全角半角不统一这些都是确定性规则用代码处理比让AI模型处理更准确、更快速。停用词过滤虽然带一点语义色彩但本质上也是查词表。真正需要AI的环节只在分词那一刻——也就是让模型判断“哎这款手机的续航表现”该切成“哎 / 这款 / 手机 / 的 / 续航 / 表现”而不是把“手机续航”当成一个整体丢掉。所以我的完整技术链路可以概括为规则逻辑负责字符层面清洗AI开源包负责词汇层面切分停用词表负责语义噪音过滤。三合一的组合拳远比单独靠任何一种方式都来得稳。3. 核心清洗代码实现从规范化到停用词过滤3.1 环境准备与依赖安装项目整体基于Python开发需要准备的环境很简单两三个依赖包就能跑起来。安装依赖时需要注意版本兼容问题建议在虚拟环境中部署避免和系统全局Python环境互相干扰。# 创建虚拟环境Python 3.8均可 python -m venv clean_env source clean_env/bin/activate # Windows下执行 clean_env\Scripts\activate # 安装核心依赖 pip install jieba pip install unidecode pip install zhon三个依赖各自管一摊jieba负责中文分词unidecode用于把Unicode字符做规范化处理主要解决全角转半角和特殊字符扫码的问题zhon提供中文常用字符集和标点符号集这个包在处理中文标点时特别好用你看一眼它内置的标点集以后就知道手写正则省了多少事。3.2 文本规范化与去标点标题数据通常来源于用户输入或者第三方抓取格式五花八门。第一步要做的是把所有字符拉到同一个起跑线上。具体规范化的顺序是有讲究的不能想当然地直接删符号import re import unicodedata from zhon import hanzi def normalize_text(text: str) - str: # 全角转半角 text unicodedata.normalize(NFKC, text) # 去除多余空白多个空格合并为一个去掉换行和制表符 text re.sub(r\s, , text).strip() # 去掉中文和英文标点保留必要的连字符防止“iPhone 15 Pro-Max”这类被拆散 punct_pattern r[。、“”‘’【】《》〈〉「」『』] r[^\w\s\-] text re.sub(punct_pattern, , text) # 去除非可见字符 text .join(ch for ch in text if unicodedata.category(ch) ! Cf) return text看到最后一行你可能想问为什么要把不可见字符单独拿出来处理因为这类字符在屏幕上几乎看不见但会真实参与字符串匹配导致后面做数据去重时明明内容相同的标题被误判成不同记录。PDF复制出来的文本尤其容易出现这种问题。至于正则表达式里标点集合如果你不想自己维护可以像这样直接复用现成方案import string from zhon import hanzi # zhon里已经内置了常用中文标点集合 CN_PUNCTUATION hanzi.punctuation # string.punctuation是Python自带的英文标点 EN_PUNCTUATION string.punctuation这一步完成之后标题里肉眼可见的噪音基本清干净了你会看到“《AI时代的文本清洗》——从入门到实践”变成“AI时代的文本清洗从入门到实践”。3.3 使用AI开源包进行中文分词字符清洗完成接下来才是AI开源包上场的主场分词。jieba有几种分词模式我在项目里两种都用到了。常规批量处理时用默认的精确模式搜索引擎场景下用搜索引擎模式后者会把长词进一步切分提高召回率。import jieba def segment_title(text: str) - list: # 精确模式分词返回可供迭代的生成器 words jieba.cut(text, cut_allFalse, HMMTrue) return list(words)如果项目里有一些行业特有词汇比如“大模型”“提示词工程”“向量数据库”直接分词可能会被切开这时候需要加载自定义词典。这个问题非常常见我在后面“常见问题”一节里会详细展开。分词之后一个典型的输出是这样# 输入AI时代的文本清洗从入门到实践 # 输出[AI, 时代, 的, 文本, 清洗, 从, 入门, 到, 实践]可以看到词和词已经被独立切出来了但“的”“从”“到”这些词还在它们就是下一步要去掉的停用词。3.4 停用词过滤与结果组装停用词过滤是整个清洗链条的最后一道工序。这个环节的代码逻辑本身很简单就是查词集合class TitleCleaner: def __init__(self, stopwords_pathNone): self.stopwords set() if stopwords_path: self.load_stopwords(stopwords_path) def load_stopwords(self, path: str): with open(path, r, encodingutf-8) as f: for line in f: word line.strip() if word: self.stopwords.add(word) # 补充常见噪音词 extra {, , a, an, the, and, of, to} self.stopwords self.stopwords.union(extra) def clean(self, title: str) - str: normalized normalize_text(title) words segment_title(normalized) filtered [w for w in words if w not in self.stopwords and len(w.strip()) 0] return .join(filtered)执行顺序值得再说一次先normalize_text做字符层清洗再segment_title做分词最后过滤停用词。如果你调换顺序先分词再去标点标点会黏在词的两侧导致“清洗”和“清洗”被当成两个不同的词停用词表完全失效。3.5 完整调用示例与输出效果合在一起整个清洗流程的调用方式如下cleaner TitleCleaner(stopwords_pathstopwords_zh.txt) titles [ 【实战干货】《AI开源工具包》到底怎么选 - 完整版, 基于大模型的电商客服系统设计 与实现 , The Role of AI in Modern Text Analytics: A Review, iPhone 15 Pro512GB开箱实测续航惊人, ] for title in titles: cleaned cleaner.clean(title) print(cleaned)实际输出实战干货 AI开源工具包 到底 怎么选 完整版 基于 大模型 电商 客服 系统 设计 实现 Role AI Modern Text Analytics Review iPhone 15 Pro 512GB 开箱 实测 续航 惊人对比一下原始标题效果差距还是很直观的。带括号、书名号、感叹词的标题清洗后只留下核心语义单元中英文混合的标题也样能保持基本的可读性表情符号这类Unicode特殊字符在规范化阶段就被处理掉了没有干扰后续流程。4. 实操中的踩坑记录与常见问题速查4.1 停用词表过度删除导致信息丢失这是我踩过最重的一个坑。一开始图省事用的是一份从网上直接下载的“超大中文停用词表”里面收录了两三千个词。跑完清洗后一看结果很多标题变得面目全非比如“2025年AI发展趋势分析”被清洗成了“2025 AI 趋势 分析”你把“年”和“发展”都删掉了这句话还剩多少信息量后来分析时发现那份通用停用词表主要面向传统IR场景里面把“发展”“问题”“工作”“研究”这类词都列成了停用词。在短文本检索场景下这类词恰恰可能是标题的核心意图。比如用户搜索“文本处理存在的问题”如果把“问题”当成停用词删掉查询就变成了“文本处理存在”语义完全偏了。解决思路是基础停用词表可以随便下载但必须做减法。我的做法是把通用停用词表读进来之后先用一批带业务含义的种子标题做对照人工筛查出被误删的关键词把这部分词从停用词集合里移除。换句话说停用词表不是拿来越大越好的它要贴合你自己的语料分布。4.2 自定义词典AI开源包不认识的领域词汇另一个很常见的坑是分词器把领域术语切碎。举真实的例子“多模态”容易被切成“多”和“模态”“提示词”容易被切成“提示”和“词”。切碎之后停用词过滤可能会把“的”删掉但只要“模态”和“词”被单独留下来下游语义检索还是会出问题——你会检索不到“多模态”这个完整概念。这个问题我用自定义词典解决其实就是一文件的事# user_dict.txt 大模型 10 n 多模态 10 n 提示词工程 10 n 向量数据库 10 n 搜索引擎 10 n第一列是词第二列是词频第三列是词性。词频越高分词器越倾向于把该词当作一个整体保留。加载方式jieba.load_userdict(user_dict.txt)加载完自定义词典再跑一遍“多模态大模型的崛起”这种标题输出从“多 / 模态 / 大 / 模型 / 的 / 崛起”变成“多模态 / 大模型 / 的 / 崛起”效果立竿见影。4.3 英文标题的大小写与单复数处理中文标题清洗顺手但项目里还有一批英文标题。英文的清洗逻辑跟中文不完全一样两个细节需要额外处理一是大小写归一化。英文标题里每个词的首字母通常大写但你的停用词表里存的可能是小写“the”“of”。不统一大小写就等于白配了对清洗结果里会残留大写的“The”和“Of”。处理方法是在停用词过滤前把词转成小写。二是单复数问题。“models”和“model”在英文里是同一个概念但在字符串层面是两个词。简单的词形还原可以用第三方包但为了不引入过多依赖我用了一个轻量方案——在停用词表里同时加入常见单复数形式比如“models”“applications”这样的词也会出现在我的停用词表里反正它们本身就不是我需要的核心词。这不算最优雅的方案但对标题清洗这种短文本场景真实效果足够而且性能开销为零。4.4 全角半角混用与Unicode规范化标题清洗绕不开全角半角问题。典型的场景一段标题从Word复制出来“”全是全角而单词之间的空格又是半角还有些数字用的是全角数字“”肉眼看着一样程序比对的时候完全不认。这属于字符编码层面的坑不用一条条写映射表直接用unicodedata.normalize(NFKC, text)就能把所有全角字符统一成半角形式。但这里有个隐含代价需要提醒NFKC规范化会把一些有意义的字符也转换掉。比如中文数字“①”会变成“1”某些特殊符号会被拆解成多个字符。如果业务后续流程需要保留这些符号你就要谨慎使用NFKC或者只在特定字符集合上做转换。4.5 常见问题速查表问题现象可能原因解决方案标题清洗后语义不完整停用词表过于激进人工审查并移除业务关键词做减法领域术语被切成碎片分词器词库缺少领域词加载自定义词典设置词频英文停用词过滤失效大小写未归一化分词后先转小写再过滤全角数字无法匹配Unicode编码未规范化使用NFKC规范化结果里还有“\u200b”等存在零宽字符按Unicode类别过滤Cf类字符重复标题去重失败清洗前已有编码或标点差异调整流程先规范化再清洗再去重清洗耗时过长停用词表过大或遍历方式低效将停用词存入set集合避免list逐条比对4.6 清洗速度与批量处理的平衡建议最后说一个实操中容易被忽略的点清洗速度。项目刚开始时我用的是逐条处理的方式一条标题调用一次分词临时构建停用词集合当时没觉得慢。后来数据量涨到几十万条后耗时立刻暴露出来了。分词本身还好最拖后腿的其实是在清洗函数内部重复加载停用词表和初始化分词器。优化办法有两个方向第一把停用词表加载放到构造函数里做成单例模式不要让每一条标题都重新读文件。我在上面的类设计已经体现了这一点__init__里加载好后续每条标题复用同一份词表。第二批量处理时可以考虑使用jieba.enable_parallel()开启并行分词配合多核CPU处理吞吐量提升非常明显。不过注意这个小功能只在支持多进程的环境下有效Windows上有个别兼容问题生产环境建议先在Linux上压测。5. 经验总结与实践心得这个项目做完我最大的体会是标题清洗这类“小任务”根本不小它的技术含量不在写代码那几十行而在对字符编码、分词原理、停用词尺度这些细节的把握上。用AI开源包不等于把所有事都丢给模型真正合理的模式是让规则处理和模型处理各司其职。确定性强的用规则代码处理效率高、可解释、好维护语义判断层面的交给AI模型省心、准确、泛化性好。这种组合在标题清洗这条链路上实践下来效果和性能都很理想。有一点我想特别分享给刚接触这块的同行清洗流程的每个环节都要留出人工核查的空档。不要一键跑完批量结果直接交付而是抽几百条样本肉眼过一遍清洗后的标题确认没有语义损失、没有奇怪的碎片词、没有该留的被删掉。AI开源包训练时用的语料和你手上的真实数据分布几乎不可能是完全一致的人工核查这个步骤才是保证项目质量不翻车的最后一道保险。如果后续项目往更深一步走我会考虑在停用词层引入词性判断比如只删除特定词性下的停用词而不是一刀切或者给标题清洗加一个“重要性打分”模块让每个保留的词带权重输出。这些都是目前方案的潜在优化方向留待有合适场景的时候继续折腾。