做了几年NLP相关项目我的经验是文本处理基本方法中的分词永远是第一个绕不过去的坎。无论是做舆情分析、智能客服、知识图谱还是大模型微调前的语料准备第一步几乎都是对原始文本做预处理而预处理的核心环节必然包含分词。很多新手拿到一篇新闻或一段对话第一反应就是直接调一个分词工具库结果跑出来的结果却碎得没法看或者词语切分得“不合群”严重影响后面TF-IDF、Word2Vec、BERT等模型的效果。这篇文章把我在实际项目里从零搭建中文NLP预处理流程时对分词的完整理解写下来包括概念、选型、实操、踩坑尽量讲透。整理的这套文本处理基本方法适合正在做NLP实战项目的学生、刚入行的算法工程师以及需要自己做数据预处理的数据分析师。1. 分词在NLP全流程中的真实位置为什么它不是一道“开胃菜”先说一个我观察到的现象。市面上很多NLP教程把分词当成一种开胃菜简单调个函数就过去了紧接着就进入向量化、模型训练。但在实际工程中分词质量直接决定了下游任务的上限。有个做新闻分类的案例我印象很深刚开始直接使用默认词典的jieba分词导致“自然语言处理”被拆成“自然/语言/处理”在关键词提取和文本相似度计算环节效果很差。后来调整了用户词典和分词模式整个分类准确率提升了近8个百分点。这就是文本处理基本方法在实际项目里的价值体现。1.1 预处理链条里分词处于什么位置NLP项目的第一个模块几乎都是“数据预处理”而数据预处理的下游通常连接着文本清洗、标准化、去停用词、实体抽取、文本表示这些环节。分词在整个链条中的位置大概是这样原始文本 → 数据清洗 → 分段/分句 → 分词 → 去停用词 → 特征提取/向量化 → 模型训练以典型的中文新闻数据处理为例爬来的数据通常包含大量HTML标签、特殊符号、全角半角混杂甚至是乱码。先做的是清洗去掉标签和无关符号然后把整篇新闻按标点切成句子再对每个句子做分词。如果在这个阶段出现问题后续无论用什么向量化策略信息都会存在损耗。1.2 分词影响哪些下游任务关键词提取分词粒度不对核心关键词会被拆散。例如“人工智能”拆成“人工”和“智能”后关键词权重下降“人工”“智能”两个词又会干扰其他文本的相似度计算。文本分类特征词表基于分词结果构建词边界错误会直接污染词表。像“南京市长江大桥”这种歧义句如果切分成“南京/市长/江大桥”语义会发生极大偏移。搜索引擎/召回倒排索引里的词典项就是分词结果。分词质量不佳用户搜索“深度学习框架”时会召回一堆完全无关的文本。情感分析分词结果影响情感词匹配比如“不太高兴”如果拆成“不太/高兴”还可以理解如果拆成“不高/兴”情感极性就直接丢失了。机器翻译和对话系统都是基于词的序列建模词边界错误无法通过模型层面的注意力机制完全修正。1.3 中文分词为什么比英文分词难英文分词简单因为英文天然有空格作为词边界最多做一下词形还原或词干提取。而中文文本以汉字为单位连续书写词与词之间没有显式的分隔符同一个句子在不同语境下、不同应用需求下合法切分方式有很多种。“武汉市长江大桥”这个例子在NLP圈子里广为流传既能切成“武汉市/长江大桥”也能切成“武汉/市长/江大桥”。两种切分在语法层面都成立但语义大相径庭。正是这种歧义性让中文分词成了文本处理基本方法中技术含量最高的环节之一。分词算法需要同时解决三个问题词语切分歧义消解、未登录词识别、分词粒度选择。这三个问题几乎贯穿了所有中文分词工具的设计。2. 分词算法的主流流派与底层逻辑别只会调包很多教程一上来就让你pip install jieba把分词当成了一个黑盒。如果只是做个简单demo这样确实够用。但一旦遇到特殊语料或者效果不佳的场景不了解底层算法就只能干瞪眼。我把主流的几种中文分词算法思路梳理一遍你会发现它们其实很好理解。2.1 规则分词早期是主流词典最大匹配最早的中文分词主要依赖词典。基本思路是先准备一个尽量大的词表然后按照某种匹配策略把文本切分成词。最常见的两种策略是正向最大匹配和逆向最大匹配。正向最大匹配的逻辑是从左到右扫描句子每次取当前指针位置开始、长度与词典中最长词长度相同的子串去词典里查找。如果查不到就把子串最右边的一个字去掉继续匹配直到匹配成功或子串只剩一个字。举个例子假设词典最大词长是5“我们在野生动物园玩”从左开始取“我们在野生”查词典没命中就去掉“生”变成“我们在野”再查不断缩小直到命中“我们”然后指针移到“在”继续重复。逆向最大匹配则反过来从句子末尾开始切分。这两种规则方法实现很简单、速度快对大规模文本处理效率很高当年很多搜索引擎的早期版本就是靠这种方式做粗粒度的词索引。缺点也很突出完全依赖词典质量遇到词典里没有的词就束手无策而且“最大匹配”的贪心策略经常切出错分。比如正向最大匹配很容易把“研究生命起源”切成“研究生/命/起源”。2.2 统计分词从概率角度解决歧义现代分词工具基本不再单独依赖规则而是引入了统计语言模型。核心思想是一个句子可能有多种候选切分方式究竟哪种切分最合理看哪种切分方式在真实语料中出现的概率更大。专业一点说就是基于大规模语料统计词与词之间的共现频率然后用动态规划典型的是维特比算法找到整句话概率最大的切分路径。这里一个基础模型是n-gram二元语法模型。假设分词结果是“我/爱/自然语言处理”这个切分的概率可以近似看作P(我) × P(爱|我) × P(自然语言处理|爱)的连乘。分词过程就是遍历所有可能的切分方案选择乘积最大的那个。词典用于提供候选词集合但切分决策由概率决定而不是由最大匹配决定。这也解释了为什么同一条新闻用不同的分词工具会得到不同的结果——词典不同语料统计出的转移概率分布也不同。统计分词的优点是比纯规则方法更灵活可以处理一部分歧义问题。但它的前提是需要海量语料来训练模型参数并且对未登录词的召回能力仍然有限。于是出现了基于序列标注的识别方法典型的是把分词建模为BEMS词首、词中、词尾、单字成词标签预测任务再配合隐马尔可夫模型或条件随机场来解决。这时分词本质上变成了一个监督学习问题。2.3 如今的深度学习分词特征自动化深度学习普及后分词模型也逐渐走向神经网络化。核心思路不再手动设计特征而是把分词作为一个序列标注任务用BiLSTM-CRF或者BERTCRF这类模型来学习字与字之间的组合规律。输入的每个字经过编码器得到上下文相关的向量表示CRF层负责在输出层学习标签之间的转移约束。这类模型最大的优势是可以结合上下文语境动态判断一个词在不同句子里的切分方式歧义消解能力比n-gram统计模型更强。举个直观的对比。统计词法模型看到“在东方明珠塔下合影”时如果在训练语料中“东方明珠”这个词出现频次高它容易偏向于把“东方明珠塔”切成“东方明珠/塔”。但BERT这类模型结合了“塔下”的语境可以更大概率切出“东方明珠塔”这个整体。在实际项目里我建议先在分词速度和模型部署成本之间做评估。某些模型分词效果确实好但推理速度比jieba慢一两个数量级在实时性要求高的搜索场景下未必合适。2.4 未登录词识别为什么最考验分词工具未登录词也叫新词、OOV指的是词典和训练语料中都没有出现过的词比如人名“李狗蛋”、新造词“内卷”、专业领域缩略语“RPA”、商品名“螺蛳粉”等。一个分词工具好不好用很大程度上就看它对未登录词的识别能力。传统规则和词典方法对未登录词几乎无解。统计语言模型依赖词表遇到新词也只能拆成单字。基于序列标注的方法相对好一些因为它是从字的组合规律去预测标签对没见过的人名、地名有一定的泛化能力。很多工业级系统比如HanLP、LTP的内部实现都会额外挂载人名库、地名库、机构名库甚至通过旁路模块先做命名实体识别再把识别出的实体整体锁定为词再执行主分词流程。实际处理中新词识别建议用词典分词工具结合仍然无法覆盖的领域术语可以通过统计字的互信息和左右熵来挖掘候选新词人工审核后加入词表。这部分我后面会再展开。3. 主流分词工具选型常用方案对比几个真实细节选分词工具不是越新、越“高级”越好关键是结合文本类型、性能需求、部署环境来定。我从实际用过的工具中挑几个有代表性的做一个横向梳理方便不同场景的读者快速做判断。3.1 我对几个常用工具的实测印象工具核心原理优点不足适用场景jieba前缀词典动态规划HMM新词发现轻量、易用、中文社区资料多歧义处理一般领域定制需要手工加词典原型验证、中小规模预处理的文本处理HanLP感知机/CRF等多种模型支持训练自定义模型功能全面分词、词性标注、依存句法等支持Java和Python完整版模型体积大部署比jieba重需要做词性标注、句法分析的生产项目也常被集成到Spring Boot服务中pkuseg基于北京大学标注语料训练在新闻、混合领域文本上准确率较高刚开始使用时需要注意领域模型切换配置比jieba稍复杂学术研究、对切分准确率要求较高的场景LTP哈工大基于感知机/深度学习中文处理任务覆盖全生态完善安装配置相对复杂需要一整套中文处理能力的项目百度LAC基于深度学习BiLSTM/ERNIE分词和词性标注联合输出效果均衡环境依赖较重离线部署稍费劲有GPU或容器的工业场景拿典型的英文分词工具做对比spaCy在英文任务上几乎是工业级标配但对中文的支持只能算“能用”。它适合在统一的技术栈里做多语言NLP的情况基于纯中文项目去做分词时未必是最优解。3.2 jieba的三种分词模式怎么选对于初次做中文分词的同学大概率会遇到jieba里的三种模式选择。这里一定要结合场景来并不是“全模式”能切出更多词就更好。精确模式默认模式把句子最合理地切开适合文本分析和信息抽取。全模式扫描出句子中所有可以成词的词语速度快但会有大量冗余词不适合直接用于下游。搜索引擎模式是在精确模式基础上对长词再次切分适合搜索引擎分词召回率更高。举个例子“我们中出了一位叛徒”这句话。精确模式输出“我们/中出/了/一位/叛徒”全模式会额外把“我们中”、“出一”之类的中文里的子串都切出来搜索模式则会在“中出”这种长词内部再做细分。所以文本分类、情感分析这些常用精确模式即可搜索引擎接口才优先考虑搜索引擎模式。实际项目中我的经验是先精确模式看到分词太粗或太碎后再调整词典和模式不要一上来就“全模式大法”。全模式输出大量无意义词片段虽然召回高但引入噪声也很多在需要关键词去重和权重计算的场景里反而会增加清洗工作量。3.3 词典问题自定义词典和停用词怎么配合很多实际项目的语料都有强烈的领域属性。比如做医疗文本处理时“靶向药”、“免疫组化”这些词在通用词典里没有做游戏用户评论分析时“氪金”、“抽卡”、“开黑”这类词通用工具也束手无策。这种情况必须让分词工具认识它们。jieba里加载自定义词典比较简单。词典文件格式是每行一个词可以带词频可以带词性用空格隔开靶向药 1000 n 免疫组化 800 n 氪金 600 v 开黑 500 v加载词典的方法是jieba.load_userdict(userdict.txt)。这里有个细节加载自定义词典必须在第一次分词之前执行如果在分词之后再加载词典不生效。而且自定义词典的优先级高于默认词典所以你可以通过调大词频来强制分词器把某些词组当作一个整体不至于被拆开。还有一个容易被忽略的点有些“词”其实不需要进入用户词典而是要通过停用词表过滤。停用词处理通常发生在分词之后比如“的”、“了”、“吗”、“在”、“以及”这类功能词对语义贡献很小在文本分类和关键词提取任务里应当过滤掉。很多中文NLP工具包都附送了通用停用词表但对新语料最好自己统计高频功能词再补充维护比如“哈哈哈”、“emmm”这类网络语料里出现频率很高的非实义词需要根据任务来判断是否过滤。4. 从零做中文分词预处理一个新闻语料的完整实操讲完了原理和选型接下来是一套完整的实操流程。我会以“构建一个小型新闻语料的预处理流程”为例从环境准备到最终输出把每一步的意图和参数说明讲透。4.1 环境准备与数据源判断我用Python来演示需要安装的核心库是jieba。另外建议安装pandas因为后续做数据分析时需要用DataFrame来统计词频比纯字典操作方便得多。如果文本来源是word文档还要装python-docx来解析如果是txt文件就直接用open读取如果是PDF则可以用pdfplumber。这里有一个网络热词里频繁出现的疑问txt文件和word文件到底按什么规则加载并做文档切片通俗讲文档加载的目标是把非结构化的文档内容变成干净、按逻辑单位切好的文本片段。以典型的word文档为例先读段落按标题层级或空行切块把连续的小段落合并成语义块再按句子切分最后传给分词器。不应一次性把整篇文档灌给分词器一方面容易给内存造成压力另一方面分句信息也会丢失。这个“切块”逻辑在大模型知识库场景里成了关键一步。4.2 先把数据清洗做在前面分词器拿到原始文本之前必须先过一遍清洗管道。实操里我习惯写一个正则清洗函数它负责以下内容import re def clean_text(text): # 统一全角字符为半角具体函数可以自行实现 text full_to_half(text) # 去掉URL text re.sub(rhttp[s]?://(?:[a-zA-Z]|[0-9]|[$-_.]|[!*\\(\\),]|(?:%[0-9a-fA-F][0-9a-fA-F])), , text) # 去掉HTML标签 text re.sub(r[^], , text) # 去掉多余空白字符 text re.sub(r\s, , text).strip() # 去掉特殊符号保留中文、英文、数字等基本字符 text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9\s。、“”‘’《》], , text) return text要说明的是不要把所有特殊符号都删光。逗号、句号、问号是天然的分句边界删掉它们会让后续分句和成词信息变得困难。实际操作中要对标点做保留处理。新闻类语料一般比较规范清洗重点放在URL、作者信息、来源、标签等噪声上如果是爬虫数据HTML标签、脚本代码、样式内容要优先去掉。这里提到的数据清洗逻辑同样适用于构建高质量中文NLP语料库的过程数据源的干净程度直接影响后面所有模型步骤的效果。4.3 分词主流程与参数细节数据清洗完毕后进入正式的分词流程。以jieba为例一个基础的最小实现是import jieba text 武汉市长江大桥是新中国成立后在长江上修建的第一座公铁两用桥 words jieba.lcut(text) print(words)这里jieba.lcut返回list比jieba.cut返回生成器更直观。实际输出里如果词典里没有“武汉市”而只有“武汉”可能得到“武汉/市长/江大桥”这类歧义结果。解决的办法有两个维度一是加载自定义词典并加入“武汉市”“长江大桥”二是先把整句分词再把识别出来的人名地名合并。真实项目里我习惯把分词语料处理封装成一个类管理词典、停用词和清洗函数而不是每次调一小段脚本。一个相对完整的分词函数框架如下import jieba import pandas as pd class TextSegmenter: def __init__(self, user_dict_pathNone, stopwords_pathNone): if user_dict_path: jieba.load_userdict(user_dict_path) self.stopwords set() if stopwords_path: with open(stopwords_path, encodingutf-8) as f: self.stopwords {line.strip() for line in f if line.strip()} def clear_stopwords(self, word_list): return [w for w in word_list if w not in self.stopwords] def segment(self, text): text clean_text(text) words jieba.lcut(text, cut_allFalse) words self.clear_stopwords(words) return words def build_df(self, raw_text_list): result [] for idx, text in enumerate(raw_text_list): for word in self.segment(text): result.append({doc_id: idx, word: word}) return pd.DataFrame(result)实际数据量一旦大到几十万篇新闻时纯Python循环速度会很慢。生产环境我会用multiprocessing或concurrent.futures做多进程并行分词。为什么用多进程而不是多线程因为jieba分词是CPU密集型操作Python的多线程受GIL锁限制在CPU密集任务里很难加速而多进程能做到真正的多核并行。如果是Spark环境直接用pandas_udf来做批处理分词效率更高。4.4 词频统计和基本检查分词跑完之后我习惯马上做一轮简单的词频统计这不是为了出报表而是为了校验分词质量。实践中如果某类明显的复合词被拆得稀碎或者出现大量单字“词”就要怀疑是清洗流程出了问题还是用户词典不够。word_series df[word].value_counts() print(word_series.head(20))比如“武汉市”“长江大桥”这类专有名词如果能排到前列说明用户词典生效了。如果top20里出现大量“的”“了”“在”这些功能词最好检查清停用词的逻辑如果出现大量“”或“。”这类符号说明清洗阶段对符号的处理不够细致。4.5 中文NLP语料库构建视角里的分词细节有些读者的目的是构建高质量中文NLP语料库。除了给单个文本分词整个语料库建设还有几个细节。首先是统一编码txt和word文件保存的编码可能是GBK或UTF-8读取前最好统一转码否则分词时经常出现乱码导致结果异常。第二个是语料去重网页爬来的新闻数据高度重复标题相同但正文来自转载先用MinHash或SimHash做文本去重再去分词能节省大量计算资源也能避免模型被重复样本带偏。最后才是分句切片到分词的完整流程将清洗后文本按句号、问号、感叹号切分成句再对每句分词后续做句子级语料统计就方便。这套逻辑其实不只在新闻领域写文档切片工具、知识库问答系统做离线索引时完全可以复用。5. 常见问题与避开这些事故分词环节的调试经验5.1 歧义切分错误典型事故事例一个做法律文本处理的同事语料里出现“中华人民共和国刑事诉讼法”结果分词器切成“中华人民共和国/刑事诉讼法”他能接受但另一句“犯罪嫌疑人王某某在公安机关立案侦查后主动投案”却被切成了“犯罪/嫌疑人/王/某某/在/公安/机关/立案/侦查/后/主动/投案”。问题出在人名“王某某”被拆散。常用处理方法是把整句先跑一遍命名实体识别识别到“王某某”是人名后做整体保护再分其他部分或者直接把人名加入用户词典。比较轻量的方案是在用户词典里把“王某某”作为一个词加入并给予极高词频让分词器基本不可能拆开它。5.2 自定义词典加载了但没生效这类问题排查顺序一般是先确认load_userdict是否在第一次分词前调用然后确认词典文件编码是UTF-8Windows下记事本另存的txt文件可能是带BOM头的UTF-8会对第一个词造成干扰再检查词频设置如果词频过低而默认词典里单字的概率很高词典可能仍然竞争不过默认切分。最保险的做法是给新词设置一个明显高于默认的高词频值比如1000以上。5.3 分词粒度不一致同一批文本里“人工智能”有时切成一个词有时被拆成“人工/智能”。这对下游训练是致命的因为同一语义的文本在不同的样本里词表ID不同会干扰模型学习。一个现实做法是自己维护一份固定词表词表内出现的多字词一律强制保护词表外的保持默认行为。还有一种做法是改用pkuseg这类在特定领域上经过训练的模型其分词一致性会更好但对自定义领域的适应不一定优于手动维护词典的jieba。5.4 分词性能优化与长文本处理当文本很长时比如一条文本10万字在某些文档解析场景确实会出现分词会很慢甚至内存紧张。建议先分句再分批处理单批文本控制在几千字以内同时把清洗、分句、分词、去停用词全流程写成管道避免不必要的中间层拷贝。对于需要处理海量文本的场景可以尝试用多进程并行加速。如果使用HanLP并在Spring Boot里集成分词服务需要把它做成独立微服务不要让Java应用每次请求都重新初始化模型。HanLP等Java集成时通常会把分词器做成spring容器管理的单例Bean预热后再对外提供服务。分词模型实例的初始化耗时往往很高第一次网络调用的耗时可能比后续请求慢很多这属于正常现象。5.5 分词后还需要做哪些事分词只是预处理的一个中间环节实际项目里后续通常会继续做去停用词、词性标注、数量词合并、时间词归一化、实体链接。分词阶段的处理策略会直接影响词性标注的结果如果分词阶段把“研究”切为“研/究”两个单字词词性标注器就完全没法判断这是动词还是名词所以分词质量永远是上游基础。5.6 分词结果可视化与快速人工校验工程上我还习惯用一个小脚本来抽样检查分词结果随机从语料里抽20条文本把分词结果输出成可读日志每次改动词典后都跑一遍抽样来快速对比。这个习惯帮我省了很多力比直接跑完整评估指标快许多。如果想让结果更直观可以把分词结果导出成以空格分隔的文本然后投到在线词云工具或本地的pyecharts里用词云形状视觉化审查哪些不合适的词被切分了一目了然。with open(seg_sample.txt, w, encodingutf-8) as f: for text in sampled_texts: f.write( .join(segmenter.segment(text)) \n)5.7 几个问题的速查表问题表现检查点解决方案专有名词被拆散“东方明珠”切成了“东方/明珠”是否使用默认词典而未加载用户词典维护用户词典加入专有名词并设置较高词频新词识别不出“yyds”“绝绝子”被拆成单字词典太旧定期从新语料中挖掘候选词审核后入库标点符号混入分词结果“。”等标点出现在词表中清洗阶段没去符号或分句逻辑没处理好分词前先按规则分句或过滤符号分词结果杂乱出现大量无意义组合词使用全模式或未去停用词切换精确模式并在分词后去停用词运行速度慢百万级文档跑了很久单进程处理大语料改用多进程、精简清洗逻辑、分批分句处理加载词典报错文件不存在或格式错误路径是否写错编码是否为UTF-8检查路径与编码词频和词性字段之间用空格分隔把分词这个环节做扎实后续无论是做传统机器学习模型还是微调语言模型都会省心不少。再补充一点个人建议分词器更新迭代很快不要迷信某一个工具在所有场景里都最优核心是建立一套可替换、可评估的预处理流程让分词器作为其中一个模块存在。换词典、换模型都不需要把整个数据管道重写。这才是提高NLP项目迭代效率的关键。
