幽冥大陆修行日志更新到第九十七回，东方仙盟的练气期弟子们终于开始炼制自己的第一件法器——分词服务。在许多人的认知里，分词这事儿无非是拿个现成库调个接口，跑出结果就完事了。可真正上手之后才会发现，一个能从语料里训练出生词、生成定制词典（dic）的分词服务，和只会拿通用词表硬切的服务，差距就像练气期修士和完全没有气感的凡人一样明显。这篇内容想说的，就是我从头到尾做"分词服务训练源码 + dic 生成"这套链路的完整思路，从语料清洗、候选词统计、阈值过滤，到最终把词典加载进在线分词服务，每一步踩过的坑和调参心得都摊开讲。
这套东西适合谁？适合所有还在"练气期"阶段、刚接触中文分词的朋友，也适合已经在做搜索、推荐、后台文本处理但老觉得固有分词器不懂本领域黑话的工程师。只要你能拿到一批带领域属性的文本，这篇文章就能帮你把属于自己的词典炼出来。
1. 明确目标：练气期弟子先学会"养词典"
1.1 词典在分词链路里到底卡在哪一环
分词服务看起来简单，输入一段话，输出一串词，可它内部往往同时跑着好几层逻辑：先有最基础的词典匹配，再做基于统计概率的动态规划选最优路径，最后可能还要接一层新词发现乃至命名实体识别。词典在这个链路里不是可有可无的配置文件，它直接决定了初始候选集长什么样。候选集如果缺词，后面任何高深的算法都无能为力，因为你连"这个组合原本是个整体"都不知道。
我见过不少团队，分词效果一不好就急着换分词器，从 jieba 换到 HanLP，再换到自研模型，结果问题根本不在算法上，而是通用词典里压根没有他们领域的词。比如你在幽冥大陆世界观下做文本检索，"幽冥大陆""东方仙盟""练气期"这些词如果不在词典里，就会被切得七零八落，下游的标签抽取和向量检索自然全乱套。
所以对练气期阶段的工程师来说，最值得投资的第一件事不是研究模型结构，而是把数据养好、把词典养起来。词典就是分词的丹田，丹田不稳，再花哨的招式都发挥不出来。
1.2 通用词表不够用，领域词典从哪来
通用词典当然不差，覆盖了日常语言里绝大多数通用词，但领域词是它的盲区。每个领域都有自己的黑话、人名、地名、特殊概念，这些词要么是长尾词，要么是跨词组合，通用词表不可能收录完整。更麻烦的是，同一个词在不同领域的切分方式可能完全不同。
从这部分开始，就要引入"训练语料"的概念。我理解的分词服务训练，并不是一定要跑一个多么高深的神经网络，而是用朴素但有效的统计方法，从你在真实业务场景里收集的大批量文本中，挖掘出高频且有独立性的字符串组合，再经过阈值过滤、词性标注和人工抽检，生成一份属于你自己业务的用户词典，也就是 dic 文件。
通用词典和自建词典的定位不一样：通用词典负责兜住日常用语，自建词典负责抓住领域内的自定义表达。两套配合起来，分词服务才真正算得上"练气大成"。接下来的每一节，都是围绕"怎么从语料到 dic"这个核心流程展开的。
2. 语料清洗与预处理：词典的原料车间
2.1 语料按这个标准来收
很多人第一步就栽在语料上，要么数据量太少，要么脏数据太多。做词典生成，语料就是原材料，原材料不干净，后面统计出来的候选词自然一堆噪声。我自己的经验是，领域语料起码要有 100 万字起步，低于这个量级，很多低频但真实存在的领域词根本冒不出来。
语料来源按场景分三档：如果你做小说或内容平台，直接拿站内正文就行；如果是问答社区或客服场景，就导用户问题、标准答案、知识库条目；如果是搜索场景，那就把用户搜索词沉淀日志拿出来，这类数据尤其宝贵，因为搜索词本身高度精炼，几乎是天然的短语候选集。我见过有些团队嫌日志脏，不愿意处理，实际上搜索日志经过清洗后，对词典生成的贡献远大于随便爬来的所谓"同类文章"。
有一个容易被忽略的标准：语料要尽量贴近线上真实输入分布。什么意思？如果线上用户输入的是口语化、碎片化文本，就不要只用规范书面语去训练词典，否则生成出来的词在真实文本里依然识别不准。
2.2 清洗脚本与分句逻辑
拿到原始语料之后，第一步永远是清洗。我习惯把清洗和分句放在一起做，因为后续统计 n-gram 时依赖的是干净的句子序列，而不是整段长文本。清洗分四步走：
第一，去标签。原始文本里常有 HTML 标签、Markdown 标记、特殊符号，这些对分词训练没有任何帮助，全部直接剔掉。
第二，统一编码。强烈建议一步到位统一成 UTF-8，省得后面乱码问题。我在处理老数据时遇到过 GBK 编码的文本，不转码直接跑统计，出来的候选词全是乱码，排查半天才发现是编码问题。
第三，去噪声字符。保留中文字符、数字、英文字母和常用中文标点，其余的控制字符、表情符号、特殊符号一律清除。注意：这里不是把英文和数字删掉，而是把它们保留下来作为候选词的组成部分，比如"练气期第97回"这种文本，"第97回"本身值得成为一个词典条目。
第四，按标点切分句子。中文分句通常以句号、感叹号、问号、逗号、分号作为边界，切完句子之后，太短的片段，比如长度小于 2 的，直接丢弃。
我给一段可以直接用的 Python 清洗代码：
import re from collections import Counter, defaultdict def clean_and_split(raw_text): # 去标签 text = re.sub(r'<[^>]+>', '', raw_text) # 保留中英文、数字和常用标点 text = re.sub(r'[^\u4e00-\u9fa5a-zA-Z0-9，。！？、；：“”‘’\n]', '', text) # 按中文标点做分句 sentences = re.split(r'[，。！？、；]|\n', text) result = [] for sent in sentences: sent = sent.strip() if len(sent) >= 2: result.append(sent) return result这套代码简单粗暴，但胜在够用。如果你语料里本身有大量英文缩写，比如产品名、API 名，建议保留字母和数字之间的边界规则，避免把"DBSCAN聚类"这种混合词错误合并或错误拆散。
清洗做完之后，我建议顺手按句子量做个分布统计。假如发现某一段文本反复出现相同的长句子，可能是模板内容或广告噪声，可以在预处理阶段直接按相似度去重，避免这些重复句子把候选词的频次拉高。
3. 训练源码核心：候选词发现与 dic 生成
3.1 判断"这是不是一个词"的两把尺子
从语料里挖候选词，本质上是回答一个问题：一段连续的字符组合，凭什么说它是个独立的词？我的判断标准通常看两把尺子：内部凝聚度和边界自由度。
内部凝聚度，用互信息来衡量。简单说，如果"幽冥大陆"这四个字总是作为一个整体出现，而"幽冥""大陆"各自单独出现的场景也很稳定，那这四个字符绑在一起的额外信息量就很高，说明它们内部足够"抱团"，不应该随便切开。真正起作用的指标是最小点式互信息，也就是把任意一个切分点切开后，计算整个组合出现概率相对于两个子串独立出现概率的增益，取所有切分点里最小的那个值。这个值越高，说明整个字符串被任何位置切开都会"受伤"，也就越像是一个完整词。
边界自由度，用左右熵衡量。左邻字集合越丰富，右邻字集合越丰富，说明这个字符串能出现在各种不同的语境里，边界非常自由，是独立词的概率就越大。比如"练气期"前面可以接"进入""突破""渡过""漫长的"，后面可以接"的""修士""阶段""弟子"，左邻右邻五花八门，这种词就非常干净；反过来，如果一个组合只出现在固定搭配里，比如"如获至"后面永远只有"宝"，那它就更可能是短语碎片而不是独立词。
两把尺子缺一不可。只看互信息，会把那些永远绑定出现但只是句法固定搭配的垃圾串选进来；只看左右熵，又会把那些单独使用很频繁但内部结构松散的并列短语放进来。我的经验是，先按最小点式互信息过滤掉一批抱团不够紧的候选，再按左右熵的最小值过滤掉边界僵化的候选，剩下的质量就很稳了。
3.2 可复用的候选词统计源码
接下来是实际训练源码的核心部分。为了兼顾灵活性和易读性，我用 Python 直接实现一个基于 n-gram 统计的候选挖掘脚本，流程分为三步：统计所有 bigram 和 trigram 的频次、计算每个候选的互信息和左右熵、按阈值筛选并输出 dic。
import math from collections import defaultdict, Counter def build_ngram_counter(sentences, max_n=3): ngram_counter = Counter() for sent in sentences: length = len(sent) for n in range(2, max_n + 1): for i in range(length - n + 1): gram = sent[i:i+n] ngram_counter[gram] += 1 return ngram_counter def calc_pmi(gram, ngram_counter, total_ngrams): p_gram = ngram_counter[gram] / total_ngrams min_pmi = float('inf') for split in range(1, len(gram)): left = gram[:split] right = gram[split:] p_left = ngram_counter.get(left, 0) / total_ngrams p_right = ngram_counter.get(right, 0) / total_ngrams if p_left == 0 or p_right == 0: return 0.0 pmi = math.log2(p_gram / (p_left * p_right)) min_pmi = min(min_pmi, pmi) return min_pmi def calc_entropies(gram, sentences, ngram_counter): left_ctx = Counter() right_ctx = Counter() for sent in sentences: idx = 0 while True: pos = sent.find(gram, idx) if pos == -1: break if pos > 0: left_ctx[sent[pos-1]] += 1 if pos + len(gram) < len(sent): right_ctx[sent[pos+len(gram)]] += 1 idx = pos + 1 def entropy(counter): total = sum(counter.values()) if total == 0: return 0.0 e = 0.0 for count in counter.values(): p = count / total e -= p * math.log2(p) return e return entropy(left_ctx), entropy(right_ctx)这个实现不是为了在大数据量下追求极致性能，而是把逻辑讲透。如果你拿到的语料在千万字级别以上，建议用字典累加代替字符串 find 扫描，或者直接上多进程按分片统计再合并 Counter。我在处理千万级语料时，就是按 1 万行一个分片做并行统计，最后再合并频次，速度能提升好几十倍。
注意，p_left 和 p_right 在 bigram 统计里可以直接查表，但在 trigram 计算时，子串可能不在同一个 n-gram Counter 里，比如计算"幽冥大陆"这种四字词时，需要同时统计过 bigram 和 trigram。上面的代码里 build_ngram_counter 已经同时灌入了 2-gram 和 3-gram，所以子串一般在表里能查到。如果查不到，直接按 0 处理，也就是直接跳过，这样能避免除零问题。
3.3 阈值怎么定，dic 文件怎么落盘
算出指标之后，真正决定词典质量的反而是阈值怎么定。我的默认起点是：
- 词频下限：至少出现 5 次，设定太低会把偶然拼接的噪声放进来；
- 最小点式互信息：大于 3.0，这是一个经过多领域验证比较稳妥的起点；
- 左右熵最小值：大于 1.5，如果语料偏小，可以放宽到 1.0，但会漏掉一些边界不丰富的领域词。
阈值不是死的。语料越干净、体量越大，这些阈值可以适当提高；语料越口语化、噪声越多，阈值反而要比理论值更严格。我常给的建议是，第一次先按默认阈值跑一遍，把结果按频次从高到低扫一遍，看看排在前面的候选到底是真正的领域词多，还是明显无意义的噪声多，然后决定是上调还是下调。
筛选完成后，就是落盘生成 dic 文件。格式上我沿用最通用的"词语 频次 词性"三列结构，中间用空格分隔，UTF-8 编码，每行一个词。关于词性，刚起步时可以直接统一标 nz（专有名词），如果后续需要做命名实体识别，再按规则细化为 nr（人名）、ns（地名）、nt（机构名）。比如"幽冥大陆"可以标 ns，"东方仙盟"标 nt，但这些规则需要额外的词表支撑，一开始不必追求精细。
def generate_dic(candidates, output_path="custom_dic.txt"): with open(output_path, "w", encoding="utf-8") as fout: for gram, freq, min_pmi, min_entropy, pos in candidates: fout.write(f"{gram} {freq} {pos}\n")落盘这一步看起来简单，却是我踩过坑最多的地方。最典型的问题是 Windows 环境默认会往文件里写 BOM 头，加载分词器时第一个词会带一个不可见字符，导致词典里的第一个词永远匹配不上。解决方法是写文件时指定 encoding="utf-8-sig"，或者写完之后用命令行工具去掉 BOM。还有换行符问题，分词器加载词典时一般按行读取，行尾不要有额外空格，否则词条会被拆出空格导致匹配失败。
4. 让分词服务真正吃上这份 dic
4.1 dic 格式约定与词性处理
一个合格的 dic 文件，除了内容有效，格式还要能让分词器直接识别。通用分词器对自定义词典的格式约定大同小异，都是文本文件，一行一个词条，列之间用空格或 Tab 分隔。第一列是词语本身，第二列是词频，第三列是词性。第三列在部分分词器里是可选字段，但我建议不要省，因为词性不光影响词性标注结果，还会影响后续命名实体识别和句法分析。
词频这一列，直接理解成"这个词在当前领域里的出现频次"。分词器加载词典后，会用这个频次去参与后续的最优路径计算。如果你给的频次太大，比如直接写成训练语料里的几万次，分词器就可能把包含这个词的句子路径全部倾向到这个词上，导致"东方仙盟"虽然被正确切出来了，但"东方"绝对不再单独出现，当文本里出现"东方"这个地名时就会被强行合并成"东方仙盟"的一部分。所以我在实际项目里会把频次做一个归一化处理，设定一个上限，比如超过 1000 的按 1000 写入，低于 5 的不要。这样一个平衡，既能保证领域词被正确识别，又不会破坏分词器原本的统计概率结构。
4.2 加载方式与词频对切分路径的影响
以 jieba 为例，加载自定义词典非常简单：
import jieba jieba.load_userdict("custom_dic.txt") text = "幽冥大陆上一段尘缘，东方仙盟弟子正在修炼练气期心法。" print(jieba.lcut(text))执行之后，分词器会优先把"幽冥大陆""东方仙盟""练气期"这些词识别出来。但如果你的自定义词典词频写得过大，这段文本可能会被切得过于"膨胀"：举个例子，如果"幽冥大陆"词频是 1000，它和"上一段"的边界就不太稳定，分词器可能把"幽冥大陆上"切在一起。这种问题不在少数，我调试过很多次，最后发现把每个词条的频次都压到和通用词典同一量级，反而效果最稳定。
另一种常用加载方式是把自定义词典追加到默认词典数据里。这需要你在服务启动时读取 dic 文件，用 add_word 接口逐词添加。和 load_userdict 相比，add_word 更灵活，可以动态调整词频和词性，还能在加载时统一做归一化。两种方式没有绝对的优劣，看你的工程约束。如果词典文件在训练流水线里频繁重新生成，就用 load_userdict 保持简单；如果需要在内存里做更多定制，就在初始化时逐词 add_word。
4.3 在线服务热更新的工程姿势
分词服务一旦上线，词典不可能永远不变。领域术语更新很快，比如幽冥大陆剧情推进，新增了地名、功法名、人物名，如果每次都要重启服务才能生效，线上体验就很差。我常用的热更新方案是：后台一个定时任务，每隔几分钟检查 dic 文件的最新修改时间，如果发现文件有变化，就在子线程里重新调 load_userdict，然后切换新旧词典引用。
但这里有一个并发问题：分词器在加载词典的过程中，如果主线程正好在分词，可能出现短暂的不一致。大多数时候 jieba 这种实现因为加载过程只是更新内存字典，速度很快，影响不明显。为了稳妥，我习惯在热更新时加一个读写锁，让正在切词的请求用旧词典快速结束，切词请求排队量很小，几乎无感。这样既保证了词典更新时效性，又不会让线上分词的 QPS 抖掉一个尖峰。
另外提醒一句：热更新只适用于处理量不大、对一致性要求不那么极端的场景。如果你做的是高并发毫秒级接口，词典更新就不能每五分钟一次，而应该走灰度发布流程，先在预发环境加载新词典，对比分词语料效果之后再平滑上线。词典这个东西属于"一次升级、全局影响"的类型，越是看似不起眼的小改动，越要在更新流程上稳一点。
5. 实操排坑与调优心法
5.1 常见问题速查表
我把实践过程中最常遇到的几个问题整理成一个速查表，按"现象、原因、解法"三列直接对照，省得大家在同一条路上反复折腾。
| 常见问题 | 现象 | 原因 | 解法 |
|---|---|---|---|
| 自定义词典不生效 | 加载后分词结果没有任何变化 | dic 文件带 BOM 头或编码不是 UTF-8 | 用 utf-8-sig 重新生成文件；检查首个词条是否有不可见字符 |
| 词被错误合并 | "东方仙盟"被切成"东方仙盟"没问题，但"东方"单独出现时永远被并进去 | dic 中词频远大于通用词典词频，干扰了最优路径计算 | 对频次设上限，统一压到 1000 以内；或改用 add_word 并动态归一化 |
| 词典里全是噪声词 | 候选词列表里大量无意义组合，比如"的了""是我" | 清洗不彻底，或者阈值太低 | 提高最小词频到 10 以上；提高左右熵阈值到 2.0；对候选词做抽检过滤 |
| 生成候选词漏掉真实领域词 | "练气期"没有出现在候选词里 | 语料量不够，或频率低于 min_freq 而被滤掉 | 扩大语料；单独把低频但用户反馈明确的词写成人工补充表合入 dic |
| 多音字词性标注全错 | 同一个词在不同语境词性不同，dic 里却只有一个词性 | 词性标注规则过于粗暴 | 词典只负责候选和频次，词性交给上线前的 NER 模型或规则层二次修正 |
第 1 行的 BOM 问题，真的可以称得上是新手村第一杀手。排查方法很直接：用十六进制编辑器看一眼 dic 文件开头三个字节，如果是 EF BB BF，就是 BOM，直接去掉重存。我写过不下十次类似的坑，现在已经条件反射了，凡是词典加载不生效，第一个查看项永远是编码和 BOM。
5.2 三条亲测有效的调优经验
第一条经验：跟通用词表做个交集去重。生成候选词之后，先把候选和通用词典比对一遍，把通用词典里已经收录的词删掉。留存下来的这部分才是真正属于领域的新词增量。这个步骤看似多此一举，却能显著减少 dic 体积，让它只解决通用分词解决不了的问题，避免两套词表在加载时打架。
第二条经验：对拿不准的词，用词频低一点写入。我自己筛选候选词时会分三类：非常肯定是领域词的高置信候选、看起来像是但不太确定的低置信候选、明显是噪声的垃圾候选。高置信候选保留高词频，低置信候选写入低词频，垃圾候选直接丢弃。这样即使低置信候选偶尔切错，对整体分词结果的影响也小，方便后期通过线上抽样来决定要不要删掉。
第三条经验：每次生成新 dic，都要做一轮回归对比。流程是准备固定数量的测试句子，用旧词典切一遍，再用新词典切一遍，把切分结果逐条对比，重点关注那些被强制合并的词。我一般会随机抽 100 条线上真实输入文本，统计合并词数量的变化。如果某些词的合并反而破坏了语义，说明词典里的词频还是设置得太激进，需要回调。
这三条经验的核心逻辑其实很简单：词典生成不是一锤子买卖，它是一个持续迭代的过程。每次更新词典，都要把它当成一次上线变更来对待，有测试、有对比、有灰度，才算真正掌握了一套可以长期运行的分词服务训练链路。
走到这一步，"语料清洗、候选统计、阈值过滤、dic 落盘、服务加载、热更新、回归对比"这条完整链路就串起来了。我个人在实际操作中的体会是，分词服务的修炼之路，练气期真正要练的不是多复杂的算法，而是对数据和细节的掌控力。一个新词从语料里被发现，到最终稳定地切分正确，背后是无数细微的工程决策在起作用。建议你也找一份自己领域内的语料，先按这套流程跑通一遍，再把阈值和词频调到自己的业务节奏上。等你亲眼看着"幽冥大陆""东方仙盟"这些词被自己的分词服务稳稳切对的时候，就会明白这一趟练气期的功课没有白做。
