简介：面向C# .NET开发者与自然语言处理入门学习者的中文分词实践项目，聚焦中文文本预处理中的分词环节，可用于文本分析、搜索优化等场景的学习与二次开发。压缩包共45个文件、约180KB，包含7个cs源码、4个dll、4个exe，以及resources、config、resx、sln、csproj等工程与配置类文件，整体为可打开的Visual Studio解决方案，便于查看窗体程序、分词逻辑和资源组织方式。已有907人学习下载。项目围绕词典匹配、最大匹配、歧义与未登录词处理等常见思路展开，读者可结合源码理解中文编码、词典加载查询及分词流程，并在此基础上尝试算法替换、界面调整或集成到自己的.NET应用中，适合作为课程设计、毕业项目或NLP入门练手参考。
1. 分词效果差，搜索几乎没法用
搜索框里输入「南京市长江大桥」，返回结果里如果混进一个「市长」，用户不会告诉你哪里错了，只会默默关掉页面。C# .NET 中文分词这套源码要解决的就是这件事：把一串没有空格的中文，还原成有边界、有词性、能被倒排索引直接消费的 Token 序列。
它是一份纯托管实现，不依赖任何本地库，词典加载、切分算法、未登录词识别全部在源码里体现。适合手上已经有 .NET 后端，想在搜索、内容标签、日志归类里加一个分词能力，又不想为这点功能单独起一个 Python 服务的开发者。
下面按我拆包的顺序讲：先看架构怎么分层，再看算法怎么写，然后把它跑起来，最后说几个我踩过的坑和二次开发的入口。
2. 引擎架构拆解：一次 Cut 调用走过的四层链路
分词看起来就是个字符串切分，真读源码会发现它被拆成了职责很清楚的几层，每一层都能单独替换。我见过的实现里，只要把「词典」和「切分策略」拆干净，后面加词性标注、加停用词、加热更新都不会互相牵扯；而写成一团的版本，改一个停用词逻辑都要重新跑一遍全量回归。
2.1 目录结构与四层职责
一份结构清晰的分词工程，通常长这样：
| 目录/文件 | 职责 | 改动频率 |
|---|---|---|
src/Segment.Core/ | 核心库，无外部依赖，可单独打包 | 低 |
src/Segment.Core/Dict/TrieDictionary.cs | 词典层，Trie 构建与查询 | 低 |
src/Segment.Core/Algorithm/ | 切分层，最大匹配、DAG、HMM | 中 |
src/Segment.Core/PostProcess/ | 后处理，停用词、词性、合并规则 | 高 |
src/Segment.Cli/ | 命令行/控制台 Demo | 高 |
dict/main.dict | 主词典，几十万词条 | 按需 |
dict/custom.dict | 业务词典，线上热更新 | 高频 |
四层的边界是：词典层只回答「从位置 i 出发，长度为 L 的串是不是词、词频多少、词性是什么」，它不知道切分策略；切分层只依赖这个查询接口，负责把整句切成最优路径；未登录词层在切分结果上做补救；后处理层做业务收尾，比如过滤「的、了、是」这类停用词、把连续的数字合并成一个整体。
这种分层带来的好处很直接：换词典不用碰算法，换算法不用碰词典。我见过太多项目把 Trie 和最大匹配写在一个 800 行的类里，最后没人敢动。
2.2 词典层：Trie 节点的字段是有讲究的
词典是整个分词的性能瓶颈所在，几十万词条的加载速度和查询速度决定了服务能不能扛住。常见的做法是 Trie（前缀树），节点结构大致如下：
namespace Segment.Core.Dict; /// <summary>词典 Trie 节点，整棵树构建完成后视为只读</summary> internal sealed class TrieNode { // 子节点用 Dictionary 而不是 char[65536] 数组：分支稀疏，字典更省内存 public Dictionary<char, TrieNode> Children { get; } = new(4); // -1 表示从根走到这个节点不构成一个完整词 public int WordId { get; set; } = -1; // 存对数词频，动态规划里概率连乘会下溢，取对数就变成加法 public double LogFreq { get; set; } // 词性标注，词典没标时给个缺省值 "x" public string Tag { get; set; } = "x"; }几个参数值得单独说明。WordId不是必须的，但一旦要做倒排索引或者把分词结果喂给检索引擎，传 int 比传 string 省下大量 GC，所以我一般会保留它。LogFreq是关键，中文词频动辄几十万，直接算freq / total连乘十几个词之后 double 就下溢了，取对数后整条路径的分数就是简单累加，比较大小也不会失真。Tag字段决定了这份资源能不能直接拿去做词性标注，如果词典只存了词没存词性，那后处理层只能靠规则猜，效果会差一截。
节点的构建过程就是遍历词条字符，一路建子节点，最后一个字符的节点上打上WordId、LogFreq、Tag：
public void Load(IEnumerable<string> lines) { foreach (var raw in lines) { // 顺手干掉 UTF-8 BOM，否则第一条词条永远匹配不上 var line = raw.Trim().Trim('\uFEFF'); if (line.Length == 0 || line[0] == '#') continue; var parts = line.Split(' ', StringSplitOptions.RemoveEmptyEntries); var word = parts[0]; var freq = parts.Length > 1 && int.TryParse(parts[1], out var f) ? f : 1; var tag = parts.Length > 2 ? parts[2] : "x"; var node = _root; foreach (var ch in word) { if (!node.Children.TryGetValue(ch, out var next)) { next = new TrieNode(); node.Children[ch] = next; } node = next; } node.WordId = _id++; node.LogFreq = Math.Log(freq + 1); // +1 是平滑，避免词频为 0 时 log 变负无穷 node.Tag = tag; } }+1的平滑看起来不起眼，但词频字段在业务词典里经常被写成 0 或者干脆省略，没有平滑保护就会在动态规划里算出-Infinity，整条路径的分数全部失效，表现出来的现象是「某些句子切得莫名其妙」——这种 bug 极难从输出反推原因。
2.3 切分层与后处理层：谁决定边界
切分层拿到 Trie 的查询接口后，做两件事：先建图，再找最优路径。建图就是从左到右扫一遍，对每个起点枚举所有可能的词长，形成一个有向无环图（DAG）；找最优路径可以用最大匹配（贪心，快但不保证全局最优），也可以用动态规划求概率最大路径（略慢但效果好）。
后处理层是业务同学改得最多的地方。常见动作有三个：一是停用词过滤，把「的、了、呢」这类没有检索价值的单字词丢掉，能让倒排索引体积降一截；二是合并规则，比如把「2024」「年」合并成「2024年」，或者把英文缩写和中文分开处理；三是词性修正，把 HMM 猜出来的词性按业务规则覆盖掉。
提示：后处理层是整个分词库里最该做成插件的地方。我一般会留一个
IPostProcessor接口，业务方按需注册，而不是把规则硬编码进主流程。
这套架构真正跑起来的时候，一次Cut调用的顺序是：词典查询建 DAG → 动态规划选路 → 未登录词用 HMM 补齐 → 停用词与合并规则收尾 → 输出带位置和词性的 Token 列表。把这条链路记住，后面调参和排查问题都能定位到具体是哪一层出的错。
3. 算法内核：最大匹配够用，MMSEG 和 HMM 才能避免切错
分词算法这块，很多资源包只给一个正向最大匹配就完了，跑出来的结果在简单句子上还行，一碰到歧义就失效。中文分词真正的难点有两个：切分歧义（一句话有多种切法都合法）和未登录词（词典里根本没有的词，比如人名、新词、产品名）。这一章把三种典型实现摊开看。
3.1 正向最大匹配：二十行代码的基线
正向最大匹配（FMM）的思路是：从当前位置开始，取最长可能的长度去词典里查，查到就切下来，查不到就缩短长度，最后缩到 1 个字还没命中，就当单字输出。
public List<string> ForwardMaxMatch(string text, int maxWordLen = 8) { var result = new List<string>(text.Length / 2); int i = 0; while (i < text.Length) { // 从最长可能长度往回退，第一个命中的就是本次切分结果 int len = Math.Min(maxWordLen, text.Length - i); bool matched = false; for (; len > 1; len--) { var candidate = text.Substring(i, len); if (_trie.Contains(candidate)) { result.Add(candidate); i += len; matched = true; break; } } if (!matched) { // 词典里没有，退化成单字 result.Add(text[i].ToString()); i++; } } return result; }maxWordLen这个参数是性能开关，也是效果开关。设成 8 能覆盖绝大多数中文词，设得太大会让每个位置都做一次长串哈希，白白浪费；设得太小比如 4，遇到「中华人民共和国」这种长词就会被硬生生切开。我一般按主词典里最长词条的长度来定这个值，用awk '{print length($1)}' dict/main.dict | sort -n | tail -1扫一遍就知道。
FMM 的问题在于「贪心」。切「研究生命起源」，如果词典里既有「研究」也有「研究生」，FMM 会先命中更长的「研究生」，剩下「命/起源」，语义完全跑偏。这就是反向最大匹配（BMM）存在的理由——从右往左切，同样的句子会得到「研究/生命/起源」。实践中常见的做法是 FMM 和 BMM 各切一遍，词数不同的取词数少的那个，词数相同的取单字少的那个。
3.2 MMSEG 四规则：把「最大颗粒度」换成「最优路径」
MMSEG 是对最大匹配的改良，核心思想是维护一个滑动窗口，每次只决定窗口最左边的那一个词，但决定依据是往后看两到三个词构成的「块」（chunk）。它定义了四条消歧规则，按优先级依次尝试：
// 从位置 i 出发，枚举所有可能的三元块 private List<string[]> BuildChunks(string text, int i) { var chunks = new List<string[]>(); foreach (var len1 in _trie.MatchLengths(text, i, MaxWordLen)) { int p1 = i + len1; if (p1 >= text.Length) { chunks.Add(new[] { text.Substring(i, len1), "", "" }); continue; } foreach (var len2 in _trie.MatchLengths(text, p1, MaxWordLen)) { int p2 = p1 + len2; if (p2 >= text.Length) { chunks.Add(new[] { text.Substring(i, len1), text.Substring(p1, len2), "" }); continue; } foreach (var len3 in _trie.MatchLengths(text, p2, MaxWordLen)) chunks.Add(new[] { text.Substring(i, len1), text.Substring(p1, len2), text.Substring(p2, len3) }); } } return chunks; }拿到所有块之后，四条规则依次过滤：第一，取块中第一个词最长的那些块；第二，剩下的块里取平均词长最大的；第三，取词长方差最小的，因为方差大意味着长短词混杂，通常不是好切分；第四，取单字词最少的，如果还平就取词频对数之和最大的。
MatchLengths是 Trie 提供的接口，返回从位置 i 出发所有能构成词的长度列表，实现上就是一路往下走，每走到一个WordId >= 0的节点就记一笔。
这套规则在歧义句上的表现明显好于纯贪心，代价是计算量上去了：每个位置都要枚举三层。我的经验是，日常业务用「FMM + BMM 取优」就够了，只有在分词质量直接影响业务指标（比如搜索相关性、内容分类准确率）的场景，才值得上 MMSEG。
3.3 HMM + Viterbi：处理词典里没有的词
词典再大也有覆盖不到的词，人名、地名、新产品名、网络新词每天都在冒出来。这类词靠规则切不准，得用统计模型。主流做法是 HMM，把分词转成序列标注问题：每个字标注为 B（词首）、M（词中）、E（词尾）、S（单字成词）四种状态之一。
模型需要三组参数：初始状态概率、状态转移概率、发射概率（某个状态下出现某个字的概率）。这三组参数通常从标注语料里统计出来，随源码一起放在model/hmm_model.json之类的文件里。有了参数之后，解码用 Viterbi 算法求最可能的标注序列：
private static readonly char[] States = { 'B', 'M', 'E', 'S' }; public List<string> CutByHmm(string sentence) { int n = sentence.Length; var v = new double[n, 4]; // 对数概率矩阵 var path = new int[n, 4]; // 回溯指针 for (int s = 0; s < 4; s++) v[0, s] = Math.Log(_startProb[s] + 1e-8) + Math.Log(Emit(s, sentence[0]) + 1e-8); for (int t = 1; t < n; t++) for (int s = 0; s < 4; s++) { double best = double.NegativeInfinity; for (int prev = 0; prev < 4; prev++) { if (_transProb[prev, s] <= 0) continue; // B->M、M->E 这类合法迁移，其余为 0 直接跳过 double score = v[t - 1, prev] + Math.Log(_transProb[prev, s]); if (score > best) { best = score; path[t, s] = prev; } } v[t, s] = best + Math.Log(Emit(s, sentence[t]) + 1e-8); } // 合法句尾只能是 E 或 S，从这两个状态里挑概率大的 int last = v[n - 1, 2] >= v[n - 1, 3] ? 2 : 3; var tags = new char[n]; for (int t = n - 1; t >= 0; t--) { tags[t] = States[last]; last = t == 0 ? 0 : path[t, last]; } return RebuildWords(sentence, tags); }Emit(s, ch)里有个容易忽略的点：语料里没出现过的字，发射概率是 0，取对数就是负无穷。所以实现里必须有兜底，通常是给未登录字一个极小的正数（比如 1e-8），或者按字符类型回退（数字、字母、标点各自一组默认概率）。没有这个兜底，一个生僻字就能让整句话的 Viterbi 解码失败。
实际使用中，HMM 只处理「词典切不出来的连续单字片段」，不是全程跑 HMM。流程是：先用 DAG + 动态规划切一遍，把结果里连续的单字片段收集起来，再对这些片段跑 Viterbi。这样既保证常用词的切分准确，又让新词有机会被识别出来，性能也不会崩。
4. 跑通第一个 Demo：环境、词典格式与三行调用
源码下载下来之后，最怕的是文档说「直接运行」但跑起来一堆报错。这一章按我的实际操作顺序走一遍。
4.1 环境准备与工程结构
这份资源是标准的 .NET 解决方案，用dotnet --version确认装了 SDK。我一般用 .NET 6 或以上，Span<T>、ReadOnlyMemory<char>这些 API 都齐了，写零分配的切分逻辑会舒服很多。
# 进入解决方案目录 cd Segment.sln所在目录 # 还原依赖并编译，先确认能过 dotnet build -c Release # 如果分词质量是刚需，跑一遍自带的测试 dotnet test编译通过之后看目录，src/Segment.Core是核心库，src/Segment.Cli是控制台入口。有些资源包会把前端 Demo 也塞进来，但做后端集成的话Segment.Core就够了，直接dotnet add reference引进去。
4.2 词典文件格式与加载参数
词典格式通常很简单，一行一个词，空格分隔三个字段：
| 字段 | 含义 | 示例 | 是否必填 |
|---|---|---|---|
| 词条 | 词的文本 | 南京市 | 必填 |
| 词频 | 出现频次，影响 DP 选路 | 1200 | 建议填 |
| 词性 | 标注，用于后处理 | ns | 可选 |
加载参数一般通过配置对象传入，我习惯把它写进appsettings.json：
{ "Tokenizer": { "MainDictionaryPath": "dict/main.dict", "CustomDictionaryPaths": [ "dict/custom.dict" ], "MaxWordLength": 8, "UseHmm": true, "StopWordPath": "dict/stopwords.txt", "FilterSingleChar": false } }几个参数的含义和调法：MaxWordLength按主词典最长词定，8 覆盖 99% 的场景；UseHmm关掉能省 20% 到 30% 的时间，代价新词识别率下降，如果业务是固定领域（比如只做商品标题分词）可以关；StopWordPath留空表示不过滤停用词；FilterSingleChar设成 true 会把所有单字词丢掉，处理搜索索引时很香，但做文本分类千万别开，会把「不」「没」这类否定词一起丢掉，语义直接反了。
4.3 控制台 Demo：从字符串到 Token 流
这一部分代码都可以直接抄作业：
using Segment.Core; // 1. 加载词典，一次加载进程内复用，千万别在请求里 new var segmenter = new ChineseSegmenter(new SegmentOptions { MainDictionaryPath = "dict/main.dict", CustomDictionaryPaths = new[] { "dict/custom.dict" }, MaxWordLength = 8, UseHmm = true, }); // 2. 精确模式，输出词、词性、起止下标 foreach (var token in segmenter.Cut("研究生命起源")) Console.WriteLine($"{token.Word}\t{token.Tag}\t{token.Start}\t{token.End}"); // 3. 搜索引擎模式：长词再切一遍，提高召回 var indexWords = segmenter.CutForSearch("南京市长江大桥"); Console.WriteLine(string.Join(" / ", indexWords));精确模式的输出应该是：
研究 v 0 2 生命 n 2 4 起源 n 4 6能出这个结果，说明词典加载正常、DP 选路正常、词性标注也有数据。如果出来的是「研究生 / 命 / 起源」，那是最大匹配的贪心问题，把切分策略切到 DAG 模式就行。如果出来是「研 / 究 / 生 / 命 / 起 / 源」全是单字，基本可以断定词典根本没加载成功，先去看dict/main.dict的路径和编码。
CutForSearch是给检索场景用的，它对长词做二次切分：「长江大桥」会额外产出「长江」「大桥」，这样用户搜「长江」也能召回这条记录。代价是索引体积变大，一般线上会做候选词过滤，只对长度大于 3 的词做二次切分。
4.4 压测与批量处理
分词是高频调用的基础设施，性能必须自己量一遍。加个简单的计时：
var text = File.ReadAllText("sample.txt"); // 准备一份几十万字的真实文本 var sw = Stopwatch.StartNew(); long count = 0; foreach (var _ in segmenter.Cut(text)) count++; sw.Stop(); Console.WriteLine($"{text.Length / sw.Elapsed.TotalSeconds / 10000:F1} 万字/秒，Token 数 {count}");单线程跑纯中文文本，量级通常在每秒几十万到上百万字符之间，具体数取决于词典大小和是否开 HMM，以你自己机器跑出来的为准。如果发现明显低于这个量级，先排查三个地方：一是有没有在循环里new ChineseSegmenter；二是Cut内部是不是每切一个词就Substring，改成返回ReadOnlyMemory<char>再ToString能省一半分配；三是词典是不是每次请求都重新加载。
批量处理长文本还有个大坑：一次把 200 万字全喂进去，DAG 的数组会直接吃掉几百 MB。正确做法是按段落或按句号切块，逐块处理，块之间不共享状态。我一般按 8KB 到 16KB 切，这个粒度既不会因为频繁调用损失性能，也不会让内存抖动。
5. 避坑记录：五个让我加班到深夜的现场
这一章全是血泪经验，每一条都对应我真实遇到过的现象。
5.1 现象：词典第一行永远是废话，第一条词条怎么也切不出来
原因：主词典文件是用 Windows 记事本或者某些编辑器存的，带了 UTF-8 BOM，File.ReadAllLines读出来的第一行开头多了个\uFEFF。这个词条就变成了\uFEFF南京市，自然永远匹配不上，而第二行开始全部正常，所以很难发现。
解决：要么加载时统一line.Trim().Trim('\uFEFF')，要么用new StreamReader(path, Encoding.UTF8, detectEncodingFromByteOrderMarks: true)让运行时自动吃掉 BOM。我现在的习惯是加载器里直接清 BOM，不管文件有没有，多这一步不亏。
5.2 现象：切几百万字的日志文件，内存直接飙到 2G，GC 疯狂抖动
原因：切分过程中每个候选词都用Substring生成一个新字符串去 Trie 里查，一篇文章几十万次分配。这些临时字符串全是小对象，直接进 Gen0，GC 压力巨大。
解决：把 Trie 的查询接口从bool Contains(string)改成bool Contains(ReadOnlySpan<char>)，用text.AsSpan(i, len)传切片，零分配。输出阶段再统一转字符串。这个改动在我的场景里把 GC 次数降了一个数量级，是收益最高的一次优化。如果用的是老版本 .NET 没有 Span，至少也要做到「先查 Trie 再建字符串」，而不是先建再查。
5.3 现象：往 custom.dict 里加了业务词，重启服务后还是不生效
原因：两种情况。一是加载顺序问题，自定义词典先加载、主词典后加载，主词典里的同名词条把自定义的覆盖了；二是词频太低，虽然词典里有，但 DAG 动态规划算出来的最优路径把它淘汰了。
解决：先确认加载顺序，自定义词典必须最后加载，后面的覆盖前面的。如果是词频问题，把业务词的词频调高，我一般直接写成主词典里最高频次的量级（比如 100000），或者干脆在 Trie 建完之后，对业务词做一个强制标记，让 DP 阶段给它加权。热更新场景还要注意词典是构建成只读 Trie 的，加词必须重建 Trie 或者走增量插入，不能直接改原对象。
5.4 现象：并发压测时偶发结果错乱，同一句话两次切出来不一样
原因：词典内部的Dictionary<char, TrieNode>在服务运行期间被写入了，比如热更新逻辑直接往里插节点。Dictionary不是线程安全的，扩容时读写并发会导致结构损坏，表现就是查询结果随机出错，而且极难复现。
解决：定死一条规则——构建完成的 Trie 只读。热更新走「重建一棵新树 + 原子替换引用」的路子，读线程永远只读当前引用指向的那棵树。volatile修饰的引用字段配合Interlocked.Exchange就够了，不需要加锁。这个模式在配置热更新里很常见，代价是重建期间内存会短暂翻倍，词典几十 MB 的话完全可以接受。
5.5 现象：英文、数字、型号被切得稀碎，"iPhone15Pro" 变成一串单字符
原因：HMM 模型和主词典都是针对中文训练的，英文数字在词典里没有词条，HMM 的发射概率也对不上，最后全部走「单字兜底」分支。
解决：在分词之前做一次预处理，用正则把连续的非中文片段整体抽出来，作为一个 Token 直接透传，剩下的中文片段再交给分词器。规则大概是这样：
// 先把连续的字母、数字、常见连接符整体抠出来，避免被中文模型切碎 private static readonly Regex AsciiBlock = new(@"[A-Za-z0-9][A-Za-z0-9\.\-_/]*", RegexOptions.Compiled); public IEnumerable<Token> CutWithAsciiGuard(string text) { int last = 0; foreach (Match m in AsciiBlock.Matches(text)) { if (m.Index > last) foreach (var t in Cut(text.Substring(last, m.Index - last))) yield return t; yield return new Token(m.Value, "eng", m.Index, m.Index + m.Length); last = m.Index + m.Length; } if (last < text.Length) foreach (var t in Cut(text.Substring(last))) yield return t; }AsciiBlock这个正则别写太宽，把中文标点也纳进去会导致「iPhone。」这种边界判断出错。另外RegexOptions.Compiled在启动时有编译开销，常驻服务值得开，跑一次就退出的脚本反而更慢。
6. 二次开发入口：自定义词典热更新与效果验证
真正上线之后，改得最多的不是算法，是词典。产品名、活动名、新造词每周都在变，如果每次加词都要重启服务，运维同学会来找你麻烦。我的做法是把词典包成一个可以原子替换的组件：
public sealed class ReloadableSegmenter { private volatile ChineseSegmenter _current; private readonly FileSystemWatcher _watcher; private DateTime _lastReload = DateTime.MinValue; public ReloadableSegmenter(SegmentOptions options) { _current = new ChineseSegmenter(options); _watcher = new FileSystemWatcher(Path.GetDirectoryName(options.MainDictionaryPath)!) { Filter = "*.dict", NotifyFilter = NotifyFilters.LastWrite | NotifyFilters.Size, }; _watcher.Changed += OnDictChanged; _watcher.EnableRaisingEvents = true; } public IEnumerable<Token> Cut(string text) => _current.Cut(text); // 读路径无锁 private void OnDictChanged(object sender, FileSystemEventArgs e) { // 编辑器保存会连触发好几次，2 秒内只重建一次 if ((DateTime.UtcNow - _lastReload).TotalSeconds < 2) return; _lastReload = DateTime.UtcNow; var fresh = new ChineseSegmenter(_current.Options); // 在后台线程建新树 _current = fresh; // 引用替换，读线程立刻用上新词典 } }volatile修饰引用字段保证可见性，读路径完全无锁，写路径在后台线程重建，旧树等 GC 回收。唯一要注意的是重建期间内存会翻倍，主词典如果上百 MB，得挑内存宽裕的机器或者做成主词典常驻、只重建业务词典。
改完必须有验证手段，否则你永远不知道效果是变好了还是变差了。我一般准备一份几百句的人工标注集，每次改词典或换算法都跑一遍 P/R/F1：
int hit = 0, predTotal = 0, goldTotal = 0; foreach (var (text, goldWords) in corpus) { var result = segmenter.Cut(text).Select(t => t.Word).ToList(); predTotal += result.Count; goldTotal += goldWords.Count; // 词本身和起始位置都对上才算命中，避免重复词误算 hit += CountAlignedMatches(result, goldWords); } double p = (double)hit / predTotal, r = (double)hit / goldTotal; Console.WriteLine($"P={p:P2} R={r:P2} F1={2 * p * r / (p + r):P2}");这套指标跑下来，能立刻看出加词是不是把别的词挤掉了。我遇到过一次，为了把某个产品名切对，把它的词频调得极高，结果「华为手机」里的「华为」被拆成了新品词的一部分，F1 掉了两个点，靠这个脚本才发现的。
从那以后我每次改词典，都强制走一遍「小样本验证 → 全量指标对比 → 灰度上线」这三步，再也不靠肉眼看几个例子就拍板。希望帮到你。
本文还有配套的精品资源，点击获取
