2026/9/12 5:15:11
FEATURED · 精选文章 
1. 项目背景与整体思路1.1 为什么我会单独聊 analysis-smartcn 这个分析器做搜索系统最头疼的从来不是倒排索引的构建也不是分布式节点怎么扩而是“内容进去了搜不出来”。尤其是中文场景用户拿手机随便敲几个字你就得把商品、文章、知识库文档给他捞出来这里面藏着分词这一道绕不过去的坎。TongSearch 是我们内部基于 Lucene 体系做的一套分布式检索服务整体架构不算复杂前面一层查询网关做语义理解和请求转发中间是若干索引分片节点底层完全依赖 Lucene 的 Analyzer 体系来处理文本分析。也正是因为这个底子我才能在 TSearch 里把 Lucene 的 analysis-smartcn 模块直接拖进来用一套集成下来中文智能分词、词性标注这些能力全部到位不用自己从零手写一个分词器。所以这篇东西其实不是产品说明书而是我在 TongSearch 上把 analysis-smartcn 从配置到调优、再到排查线上问题的一份实战记录。如果你正在搞类似的中文检索引擎或者你的项目里用了 Lucene、Solr、Elasticsearch 这套技术栈同样可以参考。1.2 smartcn 到底解决的是哪一类问题在接入 smartcn 之前我这边用过标准分词器 StandardAnalyzer也临时用过 IK 分词器。但线上数据一多就发现标准分词器对中文基本等于没分一句话被切得稀碎用户搜“北京大学”的时候索引里存的是“北”“京”“大”“学”四个孤立单字query 端也拆成单字去匹配结果就是召回了一堆不相关的内容相关度计算也跟着崩盘。analysis-smartcn 的词项切分逻辑和标准分词器完全不一样。它走的不是简单的字典最大匹配而是基于隐马尔可夫模型HMM的概率切分方案切词的同时还能给出词性标注。打一个比方传统词典分词是“把一句话按词典里已有的词切成一段段”smartcn 更像是“根据汉字之间的共现概率判断哪些字大概率属于同一个词”所以即便是词典里没出现过的词组它也能用概率推断出一个比较合理的切法。引入到 TongSearch 之后索引端和查询端的分析器统一使用 smartcn再配合词项归一化、词性过滤规则中文内容的召回率和排序质量提升非常明显。这个方案选型背后的逻辑就是在缺少高质量的垂直领域词典的情况下统计分词模型比纯字典方案更能覆盖开放域的中文文本。1.3 什么场景适合用 smartcn什么时候不建议强行上先说说我踩过的一个认知误区。很多同学一听到“中文分词”第一反应就是“我要搞一堆专业领域词库”然后死磕自定义词典。smartcn 的设计哲学恰恰相反它没有开放一个像 IK 那样的扩展词典维护入口因为它本身是概率模型驱动词库只是初切的一个辅助信号。适合用 smartcn 的场景我总结下来有三类内容来源杂、领域跨度大新闻、UGC、论坛帖子这种没法用一本固定词典覆盖。查询词比较口语化比如用户搜“怎么修漏水的水龙头”这种长尾 query 很考验概率模型对未知搭配的处理能力。对部署维护成本敏感不想周期性地维护一大堆词典文件。不太适合的场景也有如果业务是窄领域、专有名词密集的搜索比如医疗器械型号、法律条款编号、化工物质名称smartcn 切出来的词可能和人脑理解的术语边界对不上。这时候我更建议给 TongSearch 接入 IK 这类词典式分词器或者直接在 smartcn 前面加一层字段规整处理把专有名词先用标点或特殊符号保护起来再做常规分词。2. 方案选型与技术原理拆解2.1 为什么 TongSearch 能直接用 analysis-smartcnTongSearch 虽然对外暴露的是自己的查询网关和索引接口但底层索引引擎就是 Lucene。Lucene 的 contrib 里一直有一个 analysis-smartcn 模块提供 SmartChineseAnalyzer、SmartChineseTokenizer 以及 HMMChineseTokenizer 等一系列类官方定位就是“针对中文智能切分的分析器实现”。因为 TongSearch 的索引链路上完全复用 Lucene 的 Analyzer 抽象所以集成方式非常干净在索引配置里指定一个 analyzer 的 class 为 org.apache.lucene.analysis.cn.smart.SmartChineseAnalyzer复制对应 JAR 到 Lucene 的 lib 目录重新加载索引配置就生效了。对上层业务来说索引 API 完全没变唯一要改的是 mapping 里 text 字段的 analyzer 参数。这里有个细节很多人不知道analysis-smartcn 模块在早期 Lucene 版本里其实叫 SmartChineseAnalyzer分词采用 bigram 切分加 HMM 消歧后来的版本又新增了 HMMChineseTokenizer切分精度更高。我在集成时特意选了新一点的 Lucene 版本确保拿到的是 HMMChineseTokenizer 的实现而不是老的Bigram 粗切方案。如果你在 Solr 里只用默认的 solr.SmartChineseTokenizerFactory要确认一下它到底包装的是哪个 tokenizer不同版本差别很大。2.2 smartcn 的分词过程从 bigram 到 HMM我一开始也以为 smartcn 就是个简单的“二元语法 词表”分词器后来翻了源码才发现它内部比我想象中完整。整体流程大致是这样第一步文本经过字符归一化比如全角转半角、大小写转换这一步和 Lucene 的 CharTokenizer 体系是一致的可以保证后续切分的时候字符形态统一。第二步是获取候选词元。smartcn 内部会建立一个词元网络segmentation graph把文本切分成一个一个的候选单字和词。Bigram 方案是简单地把相邻的两个字当成一个候选节点HMM 方案则更聪明它会先通过字典切出可信度比较高的词再把字典覆盖不到的文字段交给统计模型去判断。第三步是路径选择。这里就是 HMM 发挥作用的环节模型会给每个候选切分路径打分目标是找到一个整体概率最大的切分结果。一句话里可能有多种切法比如“研究生命科学”可以切成“研究/生命/科学”也可以切成“研究生/命/科学”模型会结合上下文词语搭配概率选前者。第四步是词性标注。smartcn 会为每个切分出来的词标注一个词性比如名词、动词、人名、地名、机构名。这个能力一开始我没重视后来做 query 归一化和停用词过滤才发现非常有用。比如我可以把词性为人名或地名的词项单独提取出来提升实体识别类 query 的检索质量。2.3 smartcn 的停用词与词性过滤机制standard 分析器有一张英文停用词表smartcn 也有但它的停用词表是内置的一份针对中文的高频虚词列表比如“的”“了”“在”“是”这些。如果你不想删除这些词可以通过构造函数传入一篇自定义的停用词集合来覆盖默认行为。词性过滤在检索里用起来也很巧。比如电商搜索里用户输入“耐克鞋”这类 query如果查询分析器把“鞋”标注成名词保留没问题但有些场景里“的”“地”“得”这种结构助词被标注为虚词直接过滤掉能显著减少倒排索引里的高频词条节省存储空间同时避免这些虚词在打分阶段干扰排序。我在 TongSearch 里的做法是把 smartcn 的分析结果做成两路索引端保留全部词元但过滤掉停用词和纯标点查询端除了过滤停用词之外还会额外保留词性标注交给后面的查询理解模块做意图识别。这套双路设计面对“帮我找一下附近的火锅店”这类 query 非常有效“附近”和“火锅店”两个核心意图都能被识别出来。3. 核心实操在 TongSearch 里配置 analysis-smartcn3.1 环境准备与组件部署TongSearch 的部署结构是网关节点负责接收请求索引节点存储分片元数据节点管理索引配置。我建议你在动手配 smartcn 之前先把一套最小环境跑起来至少有一个网关节点和两个索引节点这样后面验证分词和查询效果的时候不会因为单节点问题误判。环境就绪之后确认 Lucene 的版本然后找到 analysis-smartcn 对应的 JAR。在 Linux 环境里我习惯把所有自定义 Analyzer 相关 JAR 统一放在一个扩展目录这样后续更新、回滚都方便。TongSearch 的扩展目录可以是 lucene/lib/ext也可以是搜索配置里显式指定的 classpath具体看你们的安装方式。还有一点要提醒smartcn 需要一份词典资源文件老版本用的是 smartcn 目录下的 hhmm 数据文件如果你使用的是从源码编译的 Lucene记得把 analysis/smartcn/src/resources 下面的词库文件也一并打包进去否则运行时会报词库加载失败。我遇到过不止一次这样的情况JAR 都在但少了 dict 文件启动日志里就能看到 SmartDictionary 相关的 WARN。3.2 配置 mapping把 analyzer 挂到中文字段上TongSearch 里创建索引的请求和 Elasticsearch 的风格很接近需要显式定义字段的 analyzer。我这里给一个完整的创建索引示例读者可以直接照抄改成自己的字段名。PUT /idx_article { settings: { number_of_shards: 5, number_of_replicas: 1, analysis: { analyzer: { ts_smartcn_analyzer: { type: custom, tokenizer: smartcn_tokenizer, filter: [ts_lowercase, ts_stop] } }, tokenizer: { smartcn_tokenizer: { type: smartcn_tokenizer } }, filter: { ts_stop: { type: stop, stopwords: [的, 了, 在, 是, 和] } } } }, mappings: { properties: { id: { type: keyword }, title: { type: text, analyzer: ts_smartcn_analyzer, search_analyzer: ts_smartcn_analyzer }, content: { type: text, analyzer: ts_smartcn_analyzer, search_analyzer: ts_smartcn_analyzer }, publish_time: { type: date } } } }上面的写法里有一个容易忽略的点索引端、查询端的 analyzer 我都设成了同一个自定义分析器。为什么这么刻意强调因为如果索引端用 smartcn查询端用标准分词器两边词项不一致用户搜“人工智能”的时候索引里有“人工智能”这个完整词条查询端却把它切成了“人工”和“智能”单独匹配召回结果会完全不搭。3.3 用分词接口验证效果索引建好之后千万不要急着导数据先调用 TongSearch 的分词测试接口确认 smartcn 出来的词项符合预期。POST /idx_article/_analyze { analyzer: ts_smartcn_analyzer, text: 东方云图智能科技公司发布了新款人工智能处理器 }正常情况下smartcn 会把这句文本切分为“东方/云图/智能/科技/公司/发布/新款/人工智能/处理器”这样一组词项每个词项后面还会带上词性标注信息比如“东方”标注为地名“公司”标注为名词。看到这个输出就说明 smartcn 已经生效并且 HMM 模型对“人工智能”这类复合词的识别也是正常的。如果你拿到的一堆输出全是单字比如“东”“方”“云”“图”那就说明 tokenizer 实际上退化成了单字切分大概率是词库没加载成功或者 Lucene 版本里 smartcn 实现不是你预期的那套。这时候优先检查词库资源文件然后检查自定义分析器配置里的 tokenizer name 是否和创建索引时的 tokenizer 名称一致。3.4 数据导入与查询验证分词确认没问题就可以把真实业务数据导进去了。TongSearch 支持批量写入我用的是普通 HTTP 批量接口一批 1000 条文档字段包括 id、title、content、publish_time。导入完成之后等几秒数据可见然后用 match query 做一轮验证。POST /idx_article/_search { query: { match: { content: 人工智能处理器 } }, highlight: { fields: { content: {} } } }如果一切正常返回的命中文档里高亮片段应该能精确命中“人工智能”和“处理器”这两个词而不是把半个句子都高亮出来。通过高亮结果可以直接看出来索引端切分到底做了哪些词这对后续调优非常有用。4. 查询效果调优与参数细节4.1 中文 query 的“粘合”问题smartcn 的分词在索引端做得还可以但查询端有一个天然问题用户输入的 query 通常很随意比如“北京的天气怎么样”smartcn 会切成“北京/的/天气/怎么样”其中“的”是虚词被停用词过滤掉之后真正参与匹配的只有“北京”“天气”“怎么样”。这里有个常见误区直接用 match query 把每个词都当成 OR 关系去匹配就会导致用户搜“北京天气”的时候匹配出大量只含“北京”或只含“天气”的文档排序还乱。更合理的做法是使用 operator 参数要求至少大部分词项都要命中POST /idx_article/_search { query: { match: { content: { query: 北京天气, operator: and } } } }当 query 里的词项确实要全部出现时用 and 能比 OR 显著提升精确率。但如果用户搜的是长句比如“北京周末适合带小朋友去玩的公园”强制全部词项命中会带来召回率下降这时候更适合用 minimum_should_match 参数按比例或固定数量控制最少命中的词项数。我常用的配置是minimum_should_match: 70%既能保证核心词项都参与匹配又不会太苛刻。4.2 用 match_phrase 保住词序有些查询场景不能拆得太碎。比如商品搜索里用户搜“纯棉长袖衬衫”如果只是匹配词项可能把“纯棉短袖衬衫”也带出来因为它们的词项完全一样只是顺序不同。如果业务上要求词序保持一致就要用 match_phrase query。和 match query 相比match_phrase 会额外检查词项在文档中的位置只有相邻位置恰好按 query 顺序排列的文档才会命中。在 TongSearch 的索引配置里text 字段默认会记录词项位置所以不需要额外设置直接用就行。但是要注意match_phrase 对 smartcn 切出来的停用词非常敏感。假设 query 是“人工智能的发展历程”smartcn 先切成“人工智能/的/发展/历程”停用词过滤后变成“人工智能/发展/历程”词与词之间的位置间隔变成了 1而不是紧密相邻。如果直接用 match_phrase很可能匹配不到任何文档。我的解决方案有两种一种是对查询串先做一次规整去掉停用词再传给 match_phrase另一种是使用 slop 参数允许词项之间有间隔slop 设成 2 一般就够了。4.3 词性标注在 query 改写里的应用smartcn 返回的词性标注信息本身是不参与倒排索引匹配的但可以把它暴露给 TongSearch 的查询预处理插件。我们内部有一个词项改写插件接收 smartcn 的输出结果如果识别到词性为人名nr的词就额外生成一个实体词条参与匹配识别到地名ns就把对应的行政区划层级展开。这相当于在 Lucene 分析器之上做了一层业务语义增强。拿“朝阳区美食”这句话举例smartcn 会把“朝阳区”标注为地名“美食”标注为名词。查询改写插件拿到这个结果后会尝试把“朝阳区”展开成“朝阳/朝阳区”两个词条这样检索时既能匹配到详细标注“朝阳区”的文档也能匹配到只写“朝阳”的文档。实测下来这类改写能把长尾 query 的召回率提升三到五个百分点效果非常明显。当然词性标注也不是百分百准确实体识别错误会导致改写后的词条进入倒排索引反而拉低精确率。我建议在改写插件里加一个白名单只对高频置信度高的地名、人名做展开其他词性一律保持原样。5. 性能优化与资源占用评估5.1 smartcn 分词会不会拖慢索引速度这是所有人在接入 smartcn 之前的第一个疑问。老实说smartcn 的 HMM 分词要比 standard analyzer 慢不少但是跟 IK 这类词典分词比起来差别并没有想象中那么大。我在 TongSearch 上做过一个对比相同的一批新闻语料standard 分析器索引速度是 100%smartcn 大约在 45% 到 55% 之间IK 大约是 40% 到 50%。也就是说smartcn 虽然慢但没有慢到不可接受。如果你的索引吞吐是瓶颈有几个优化手段。一是把分词放到数据接入管道里做离线预处理而不是在索引节点上实时分词二是在 TongSearch 的索引配置里调大线程池让多个分片并行构建三是如果只是部分字段需要智能分词其他字段继续用 standard analyzer没必要让全量字段都背上 HMM 的计算开销。5.2 堆内存与词典加载smartcn 在启动的时候会把内置词库加载进内存这个数据量通常不大几十 MB 级别但如果你在多个索引节点上都部署了同样的分析器内存占用就会乘以节点数。在容器化部署的时候要给 JVM 堆预留出这部分空间避免因为加载词库导致频繁 Full GC。还有一个坑TongSearch 如果开了索引预热节点启动时会同时加载分片数据和分析器词库内存峰值会非常明显。我的一般做法是分阶段启动先让分析器词库加载完成再加载分片数据或者干脆把节点分角色一部分节点优先处理索引写入一部分节点处理查询避免资源争抢。5.3 自定义停用词对性能的影响在自定义分析器里加一个 stop filter表面上只是过滤了几个词实际上它对性能的影响比很多人大。因为停用词往往是文本里高频出现的常见词过滤掉之后倒排索引里的 postings list 长度会显著下降查询时扫描的词项候选集合也就小了。尤其在长文档场景过滤一个“的”字可能就能减少上百万条 posting 的扫描量。我建议生成环境里不要照搬内置的默认停用词表而是分析自己的数据挑出真正的高频虚词。拿新闻类数据举例可能“了”“在”“是”出现频率特别高但垂直领域里“我们”“公司”“产品”这些词虽然也有词性却可能是业务核心词不应该过滤。停用词表的具体内容需要结合业务反复迭代。6. 实战中的踩坑记录与排查手册6.1 新词与专有名词切分错误smartcn 最典型的失败案例是切分人名和品牌名。“迪丽热巴”可能被切成“迪丽/热巴”“周杰伦”可能被切成“周杰/伦”。这种问题在词典式分词器里可以通过加词解决但 smartcn 没有公开的扩展词典接口所以处理方式要绕一下。我的方案是在 TongSearch 的查询网关里维护一份业务词汇表索引端不处理查询端在传给 analyzer 之前先把这些专有名词用空格或者特殊字符包起来变成独立的词项单元。比如把“周杰伦”改写成“周杰伦”再让 smartcn 处理切分出来就是一个完整词“周杰伦”。这是一个非常实用的 workaround代价是查询端多一次文本预处理换来的是稳定可控的专名识别。如果你允许动索引端也可以在写入文档前把文档里出现的专有名词提前替换成一个不会产生歧义的占位符分词完成之后再替换回来。但这种做法不够优雅除非你的数据格式非常规整否则我建议优先在查询端做。6.2 中英文混排的切分黑洞smartcn 面对“iPhone15 发布”这类中英文混排文本时有时候会把“iPhone15”切成“iPhone/15”有时候又切成“iphone15”整体词条行为不稳定。这个问题的根源是 smartcn 的字符模型对拉丁字母和数字的处理策略和中文完全不同。我建议在接入 smartcn 前先加一个前置过滤中文字符、英文字母串、数字串分别用分隔符保护起来。具体做法是在 char_filter 阶段把连续的英文字母或数字识别出来前后加上空格保证它们在之后的 tokenizer 里不会被意外合并或者切开。这样一个查询词只包含英文和数字时走 standard analyzer 反而更稳定中英文混合时才会调用 smartcn 做整体切分。6.3 索引端与查询端分析器不一致这个坑最隐蔽也最容易“莫名其妙”上线出问题。有时候你在 mapping 里设置了 analyzer但查询端走了 search_analyzer而 search_analyzer 没设Lucene 会回落到默认 standard analyzer导致查询词项和索引词项不一致。我线上排查过一次召回率骤降的问题最后定位到原因就是这个新同事改 mapping 时把一个字段的 search_analyzer 删掉了所有 match query 全部退化成了单字匹配。排查方法很简单用 _analyze 接口分别对同一个文本跑索引端分析器和查询端分析器对比输出词项列表。如果两边存在明显差异说明配置有遗漏。另外在 TongSearch 的查询日志里每条 query 会记录实际使用的 analyzer 名称通过日志比对也很容易发现问题。6.4 常见问题速查表现象可能原因解决方案分词结果全是单字词库文件没加载 / tokenizer 配置错误检查 smartcn 资源文件核对配置中的 tokenizer 名称查询召回率极低索引和查询分析器不一致统一设置 analyzer 与 search_analyzer专有名词被切碎词典覆盖不到查询端加入专名词表保护或改写中英混排行为不稳定字符模型冲突用 char_filter 对英文和数字做隔离索引速度下降明显HMM 计算开销离线预处理或仅对必要字段启用 smartcnmatch_phrase 查不到结果停用词导致位置间隔变大使用 slop 参数或查询前置去掉停用词7. 从单字段到多字段的检索架构演进7.1 不要把所有文本塞进一个 text 字段接入 smartcn 解决了分词问题之后下一步要考虑的是字段规划。很多初期的项目会把标题、正文、标签全部拼到一个大字段里这样写起来方便查询也方便但问题是不同字段对分词的敏感度完全不同。标题字段通常是短文本用户对标题命中比正文命中更敏感所以标题字段应该设置更高的权重正文是长文本分词后词项非常多直接参与打分很容易稀释标题的贡献。我的方案是建立一套多字段映射title 字段使用 smartcn 分词并加权content 字段使用 smartcn 分词但降低权重tags 字段使用 keyword 类型精确匹配另外再建一个 combining 字段把所有内容拼接在一起专门服务模糊检索和兜底召回。7.2 用 copy_to 实现字段级搜索权重TongSearch 支持 copy_to 指令可以把多个字段的值复制到一个目标字段里。我在文章类的索引里经常把 title、content、author 三个字段复制到一个名为 search_text 的字段query 默认只查 search_text。这样业务侧不用关心该搜哪个字段只需要针对 search_text 设置一套统一的分词规则。search_text 字段同样挂 smartcn 分析器并且因为我控制了复制字段的内容组合顺序分词效果会比直接拼出一个大杂烩更可控。这里的操作要点是title 内容在前、content 内容在后既保证标题词的词项位置靠前又能通过字段权重把标题相关度传递到最终排序里。8. 真实项目数据复盘8.1 评测数据从词项质量看 smartcn 的收益去年年底我们拿了一批 50 万篇的新闻语料做了评测。同样一套 TongSearch 集群索引配置从 standard 分析器切换到 smartcn 分析器前者的平均召回率只有 62%后者提升到 89%精确率从 58% 提升到 76%。核心原因就是标准分词器把中文句子切成了单字导致查询词项和索引词项对不上倒排索引失去了意义。这次评测也暴露了 smartcn 的短板在“精确短语匹配”类需求上它切出来的词项往往比人眼以为的粒度更粗比如“人工智能处理器”在 smartcn 里是一个整体词条而用户可能只记得“智能处理器”又会导致短语匹配失效。所以我提醒团队不要只依赖分析器本身来解决问题要给产品层提供一定的 query 改写能力。8.2 线上阈值调优的三板斧TongSearch 的查询参数里除了常规的 minimum_should_match还有查询体超时时间、分片请求并发数等参数这些参数直接决定用户体验。我的建议是先用默认参数跑一天观察查询延迟和召回率再根据业务场景做定向调整。短 query一到三个词建议 operator 设为 and确保高精确率。中长 query四到十个词建议 minimum_should_match 设为 70% 到 80%兼顾召回和精度。超长 query增加超时时间同时考虑对 query 做摘要提取只保留核心实体词参与检索。这“三板斧”听起来简单但在实际项目里每一个参数都经历过多次线上回归才确定下来。参数不是越大越好也不是越小越好要结合你自己的数据分布去测试。8.3 关于 smartcn 的未来替代方案老实说smartcn 在 Lucene 生态里已经是很成熟的方案了但它所在的位置还是比较底层的“通用智能分词”并没有针对特定领域的精调能力。如果项目发展到一定阶段需要更强的语义理解、实体识别、同义词召回我建议在 smartcn 之上再叠加一层语义向量模型走“召回 重排”的双阶段路线。TongSearch 目前已经在做这个方向的尝试先用 smartcn 做词项召回再用向量检索把语义相近的文档捞回来最后通过一个轻量级排序模型对两路结果做融合。这个方案短期内还替代不了 smartcn 的角色因为语义向量模型的训练和部署成本都不低而且对长尾新词的覆盖能力反而不如概率分词模型。我在实际运维这套环境时有个很深的体会中文分词没有银弹smartcn 也不是最优解但它是一个基线足够高、维护成本足够低的起点。先用它把检索系统跑起来再根据业务反馈一层层加语义能力这才是一条务实的技术演进路线。如果你正在给自己的搜索系统做中文分析器选型我建议你先把 smartcn 跑通再用自己的数据去做评测对比让数据告诉你下一步该往哪个方向走而不是在选型阶段就陷入各种工具的口水战里。
中文分词与检索实战：基于Lucene analysis-smartcn的TongSearch集成调优
1. 项目背景与整体思路1.1 为什么我会单独聊 analysis-smartcn 这个分析器做搜索系统最头疼的从来不是倒排索引的构建也不是分布式节点怎么扩而是“内容进去了搜不出来”。尤其是中文场景用户拿手机随便敲几个字你就得把商品、文章、知识库文档给他捞出来这里面藏着分词这一道绕不过去的坎。TongSearch 是我们内部基于 Lucene 体系做的一套分布式检索服务整体架构不算复杂前面一层查询网关做语义理解和请求转发中间是若干索引分片节点底层完全依赖 Lucene 的 Analyzer 体系来处理文本分析。也正是因为这个底子我才能在 TSearch 里把 Lucene 的 analysis-smartcn 模块直接拖进来用一套集成下来中文智能分词、词性标注这些能力全部到位不用自己从零手写一个分词器。所以这篇东西其实不是产品说明书而是我在 TongSearch 上把 analysis-smartcn 从配置到调优、再到排查线上问题的一份实战记录。如果你正在搞类似的中文检索引擎或者你的项目里用了 Lucene、Solr、Elasticsearch 这套技术栈同样可以参考。1.2 smartcn 到底解决的是哪一类问题在接入 smartcn 之前我这边用过标准分词器 StandardAnalyzer也临时用过 IK 分词器。但线上数据一多就发现标准分词器对中文基本等于没分一句话被切得稀碎用户搜“北京大学”的时候索引里存的是“北”“京”“大”“学”四个孤立单字query 端也拆成单字去匹配结果就是召回了一堆不相关的内容相关度计算也跟着崩盘。analysis-smartcn 的词项切分逻辑和标准分词器完全不一样。它走的不是简单的字典最大匹配而是基于隐马尔可夫模型HMM的概率切分方案切词的同时还能给出词性标注。打一个比方传统词典分词是“把一句话按词典里已有的词切成一段段”smartcn 更像是“根据汉字之间的共现概率判断哪些字大概率属于同一个词”所以即便是词典里没出现过的词组它也能用概率推断出一个比较合理的切法。引入到 TongSearch 之后索引端和查询端的分析器统一使用 smartcn再配合词项归一化、词性过滤规则中文内容的召回率和排序质量提升非常明显。这个方案选型背后的逻辑就是在缺少高质量的垂直领域词典的情况下统计分词模型比纯字典方案更能覆盖开放域的中文文本。1.3 什么场景适合用 smartcn什么时候不建议强行上先说说我踩过的一个认知误区。很多同学一听到“中文分词”第一反应就是“我要搞一堆专业领域词库”然后死磕自定义词典。smartcn 的设计哲学恰恰相反它没有开放一个像 IK 那样的扩展词典维护入口因为它本身是概率模型驱动词库只是初切的一个辅助信号。适合用 smartcn 的场景我总结下来有三类内容来源杂、领域跨度大新闻、UGC、论坛帖子这种没法用一本固定词典覆盖。查询词比较口语化比如用户搜“怎么修漏水的水龙头”这种长尾 query 很考验概率模型对未知搭配的处理能力。对部署维护成本敏感不想周期性地维护一大堆词典文件。不太适合的场景也有如果业务是窄领域、专有名词密集的搜索比如医疗器械型号、法律条款编号、化工物质名称smartcn 切出来的词可能和人脑理解的术语边界对不上。这时候我更建议给 TongSearch 接入 IK 这类词典式分词器或者直接在 smartcn 前面加一层字段规整处理把专有名词先用标点或特殊符号保护起来再做常规分词。2. 方案选型与技术原理拆解2.1 为什么 TongSearch 能直接用 analysis-smartcnTongSearch 虽然对外暴露的是自己的查询网关和索引接口但底层索引引擎就是 Lucene。Lucene 的 contrib 里一直有一个 analysis-smartcn 模块提供 SmartChineseAnalyzer、SmartChineseTokenizer 以及 HMMChineseTokenizer 等一系列类官方定位就是“针对中文智能切分的分析器实现”。因为 TongSearch 的索引链路上完全复用 Lucene 的 Analyzer 抽象所以集成方式非常干净在索引配置里指定一个 analyzer 的 class 为 org.apache.lucene.analysis.cn.smart.SmartChineseAnalyzer复制对应 JAR 到 Lucene 的 lib 目录重新加载索引配置就生效了。对上层业务来说索引 API 完全没变唯一要改的是 mapping 里 text 字段的 analyzer 参数。这里有个细节很多人不知道analysis-smartcn 模块在早期 Lucene 版本里其实叫 SmartChineseAnalyzer分词采用 bigram 切分加 HMM 消歧后来的版本又新增了 HMMChineseTokenizer切分精度更高。我在集成时特意选了新一点的 Lucene 版本确保拿到的是 HMMChineseTokenizer 的实现而不是老的Bigram 粗切方案。如果你在 Solr 里只用默认的 solr.SmartChineseTokenizerFactory要确认一下它到底包装的是哪个 tokenizer不同版本差别很大。2.2 smartcn 的分词过程从 bigram 到 HMM我一开始也以为 smartcn 就是个简单的“二元语法 词表”分词器后来翻了源码才发现它内部比我想象中完整。整体流程大致是这样第一步文本经过字符归一化比如全角转半角、大小写转换这一步和 Lucene 的 CharTokenizer 体系是一致的可以保证后续切分的时候字符形态统一。第二步是获取候选词元。smartcn 内部会建立一个词元网络segmentation graph把文本切分成一个一个的候选单字和词。Bigram 方案是简单地把相邻的两个字当成一个候选节点HMM 方案则更聪明它会先通过字典切出可信度比较高的词再把字典覆盖不到的文字段交给统计模型去判断。第三步是路径选择。这里就是 HMM 发挥作用的环节模型会给每个候选切分路径打分目标是找到一个整体概率最大的切分结果。一句话里可能有多种切法比如“研究生命科学”可以切成“研究/生命/科学”也可以切成“研究生/命/科学”模型会结合上下文词语搭配概率选前者。第四步是词性标注。smartcn 会为每个切分出来的词标注一个词性比如名词、动词、人名、地名、机构名。这个能力一开始我没重视后来做 query 归一化和停用词过滤才发现非常有用。比如我可以把词性为人名或地名的词项单独提取出来提升实体识别类 query 的检索质量。2.3 smartcn 的停用词与词性过滤机制standard 分析器有一张英文停用词表smartcn 也有但它的停用词表是内置的一份针对中文的高频虚词列表比如“的”“了”“在”“是”这些。如果你不想删除这些词可以通过构造函数传入一篇自定义的停用词集合来覆盖默认行为。词性过滤在检索里用起来也很巧。比如电商搜索里用户输入“耐克鞋”这类 query如果查询分析器把“鞋”标注成名词保留没问题但有些场景里“的”“地”“得”这种结构助词被标注为虚词直接过滤掉能显著减少倒排索引里的高频词条节省存储空间同时避免这些虚词在打分阶段干扰排序。我在 TongSearch 里的做法是把 smartcn 的分析结果做成两路索引端保留全部词元但过滤掉停用词和纯标点查询端除了过滤停用词之外还会额外保留词性标注交给后面的查询理解模块做意图识别。这套双路设计面对“帮我找一下附近的火锅店”这类 query 非常有效“附近”和“火锅店”两个核心意图都能被识别出来。3. 核心实操在 TongSearch 里配置 analysis-smartcn3.1 环境准备与组件部署TongSearch 的部署结构是网关节点负责接收请求索引节点存储分片元数据节点管理索引配置。我建议你在动手配 smartcn 之前先把一套最小环境跑起来至少有一个网关节点和两个索引节点这样后面验证分词和查询效果的时候不会因为单节点问题误判。环境就绪之后确认 Lucene 的版本然后找到 analysis-smartcn 对应的 JAR。在 Linux 环境里我习惯把所有自定义 Analyzer 相关 JAR 统一放在一个扩展目录这样后续更新、回滚都方便。TongSearch 的扩展目录可以是 lucene/lib/ext也可以是搜索配置里显式指定的 classpath具体看你们的安装方式。还有一点要提醒smartcn 需要一份词典资源文件老版本用的是 smartcn 目录下的 hhmm 数据文件如果你使用的是从源码编译的 Lucene记得把 analysis/smartcn/src/resources 下面的词库文件也一并打包进去否则运行时会报词库加载失败。我遇到过不止一次这样的情况JAR 都在但少了 dict 文件启动日志里就能看到 SmartDictionary 相关的 WARN。3.2 配置 mapping把 analyzer 挂到中文字段上TongSearch 里创建索引的请求和 Elasticsearch 的风格很接近需要显式定义字段的 analyzer。我这里给一个完整的创建索引示例读者可以直接照抄改成自己的字段名。PUT /idx_article { settings: { number_of_shards: 5, number_of_replicas: 1, analysis: { analyzer: { ts_smartcn_analyzer: { type: custom, tokenizer: smartcn_tokenizer, filter: [ts_lowercase, ts_stop] } }, tokenizer: { smartcn_tokenizer: { type: smartcn_tokenizer } }, filter: { ts_stop: { type: stop, stopwords: [的, 了, 在, 是, 和] } } } }, mappings: { properties: { id: { type: keyword }, title: { type: text, analyzer: ts_smartcn_analyzer, search_analyzer: ts_smartcn_analyzer }, content: { type: text, analyzer: ts_smartcn_analyzer, search_analyzer: ts_smartcn_analyzer }, publish_time: { type: date } } } }上面的写法里有一个容易忽略的点索引端、查询端的 analyzer 我都设成了同一个自定义分析器。为什么这么刻意强调因为如果索引端用 smartcn查询端用标准分词器两边词项不一致用户搜“人工智能”的时候索引里有“人工智能”这个完整词条查询端却把它切成了“人工”和“智能”单独匹配召回结果会完全不搭。3.3 用分词接口验证效果索引建好之后千万不要急着导数据先调用 TongSearch 的分词测试接口确认 smartcn 出来的词项符合预期。POST /idx_article/_analyze { analyzer: ts_smartcn_analyzer, text: 东方云图智能科技公司发布了新款人工智能处理器 }正常情况下smartcn 会把这句文本切分为“东方/云图/智能/科技/公司/发布/新款/人工智能/处理器”这样一组词项每个词项后面还会带上词性标注信息比如“东方”标注为地名“公司”标注为名词。看到这个输出就说明 smartcn 已经生效并且 HMM 模型对“人工智能”这类复合词的识别也是正常的。如果你拿到的一堆输出全是单字比如“东”“方”“云”“图”那就说明 tokenizer 实际上退化成了单字切分大概率是词库没加载成功或者 Lucene 版本里 smartcn 实现不是你预期的那套。这时候优先检查词库资源文件然后检查自定义分析器配置里的 tokenizer name 是否和创建索引时的 tokenizer 名称一致。3.4 数据导入与查询验证分词确认没问题就可以把真实业务数据导进去了。TongSearch 支持批量写入我用的是普通 HTTP 批量接口一批 1000 条文档字段包括 id、title、content、publish_time。导入完成之后等几秒数据可见然后用 match query 做一轮验证。POST /idx_article/_search { query: { match: { content: 人工智能处理器 } }, highlight: { fields: { content: {} } } }如果一切正常返回的命中文档里高亮片段应该能精确命中“人工智能”和“处理器”这两个词而不是把半个句子都高亮出来。通过高亮结果可以直接看出来索引端切分到底做了哪些词这对后续调优非常有用。4. 查询效果调优与参数细节4.1 中文 query 的“粘合”问题smartcn 的分词在索引端做得还可以但查询端有一个天然问题用户输入的 query 通常很随意比如“北京的天气怎么样”smartcn 会切成“北京/的/天气/怎么样”其中“的”是虚词被停用词过滤掉之后真正参与匹配的只有“北京”“天气”“怎么样”。这里有个常见误区直接用 match query 把每个词都当成 OR 关系去匹配就会导致用户搜“北京天气”的时候匹配出大量只含“北京”或只含“天气”的文档排序还乱。更合理的做法是使用 operator 参数要求至少大部分词项都要命中POST /idx_article/_search { query: { match: { content: { query: 北京天气, operator: and } } } }当 query 里的词项确实要全部出现时用 and 能比 OR 显著提升精确率。但如果用户搜的是长句比如“北京周末适合带小朋友去玩的公园”强制全部词项命中会带来召回率下降这时候更适合用 minimum_should_match 参数按比例或固定数量控制最少命中的词项数。我常用的配置是minimum_should_match: 70%既能保证核心词项都参与匹配又不会太苛刻。4.2 用 match_phrase 保住词序有些查询场景不能拆得太碎。比如商品搜索里用户搜“纯棉长袖衬衫”如果只是匹配词项可能把“纯棉短袖衬衫”也带出来因为它们的词项完全一样只是顺序不同。如果业务上要求词序保持一致就要用 match_phrase query。和 match query 相比match_phrase 会额外检查词项在文档中的位置只有相邻位置恰好按 query 顺序排列的文档才会命中。在 TongSearch 的索引配置里text 字段默认会记录词项位置所以不需要额外设置直接用就行。但是要注意match_phrase 对 smartcn 切出来的停用词非常敏感。假设 query 是“人工智能的发展历程”smartcn 先切成“人工智能/的/发展/历程”停用词过滤后变成“人工智能/发展/历程”词与词之间的位置间隔变成了 1而不是紧密相邻。如果直接用 match_phrase很可能匹配不到任何文档。我的解决方案有两种一种是对查询串先做一次规整去掉停用词再传给 match_phrase另一种是使用 slop 参数允许词项之间有间隔slop 设成 2 一般就够了。4.3 词性标注在 query 改写里的应用smartcn 返回的词性标注信息本身是不参与倒排索引匹配的但可以把它暴露给 TongSearch 的查询预处理插件。我们内部有一个词项改写插件接收 smartcn 的输出结果如果识别到词性为人名nr的词就额外生成一个实体词条参与匹配识别到地名ns就把对应的行政区划层级展开。这相当于在 Lucene 分析器之上做了一层业务语义增强。拿“朝阳区美食”这句话举例smartcn 会把“朝阳区”标注为地名“美食”标注为名词。查询改写插件拿到这个结果后会尝试把“朝阳区”展开成“朝阳/朝阳区”两个词条这样检索时既能匹配到详细标注“朝阳区”的文档也能匹配到只写“朝阳”的文档。实测下来这类改写能把长尾 query 的召回率提升三到五个百分点效果非常明显。当然词性标注也不是百分百准确实体识别错误会导致改写后的词条进入倒排索引反而拉低精确率。我建议在改写插件里加一个白名单只对高频置信度高的地名、人名做展开其他词性一律保持原样。5. 性能优化与资源占用评估5.1 smartcn 分词会不会拖慢索引速度这是所有人在接入 smartcn 之前的第一个疑问。老实说smartcn 的 HMM 分词要比 standard analyzer 慢不少但是跟 IK 这类词典分词比起来差别并没有想象中那么大。我在 TongSearch 上做过一个对比相同的一批新闻语料standard 分析器索引速度是 100%smartcn 大约在 45% 到 55% 之间IK 大约是 40% 到 50%。也就是说smartcn 虽然慢但没有慢到不可接受。如果你的索引吞吐是瓶颈有几个优化手段。一是把分词放到数据接入管道里做离线预处理而不是在索引节点上实时分词二是在 TongSearch 的索引配置里调大线程池让多个分片并行构建三是如果只是部分字段需要智能分词其他字段继续用 standard analyzer没必要让全量字段都背上 HMM 的计算开销。5.2 堆内存与词典加载smartcn 在启动的时候会把内置词库加载进内存这个数据量通常不大几十 MB 级别但如果你在多个索引节点上都部署了同样的分析器内存占用就会乘以节点数。在容器化部署的时候要给 JVM 堆预留出这部分空间避免因为加载词库导致频繁 Full GC。还有一个坑TongSearch 如果开了索引预热节点启动时会同时加载分片数据和分析器词库内存峰值会非常明显。我的一般做法是分阶段启动先让分析器词库加载完成再加载分片数据或者干脆把节点分角色一部分节点优先处理索引写入一部分节点处理查询避免资源争抢。5.3 自定义停用词对性能的影响在自定义分析器里加一个 stop filter表面上只是过滤了几个词实际上它对性能的影响比很多人大。因为停用词往往是文本里高频出现的常见词过滤掉之后倒排索引里的 postings list 长度会显著下降查询时扫描的词项候选集合也就小了。尤其在长文档场景过滤一个“的”字可能就能减少上百万条 posting 的扫描量。我建议生成环境里不要照搬内置的默认停用词表而是分析自己的数据挑出真正的高频虚词。拿新闻类数据举例可能“了”“在”“是”出现频率特别高但垂直领域里“我们”“公司”“产品”这些词虽然也有词性却可能是业务核心词不应该过滤。停用词表的具体内容需要结合业务反复迭代。6. 实战中的踩坑记录与排查手册6.1 新词与专有名词切分错误smartcn 最典型的失败案例是切分人名和品牌名。“迪丽热巴”可能被切成“迪丽/热巴”“周杰伦”可能被切成“周杰/伦”。这种问题在词典式分词器里可以通过加词解决但 smartcn 没有公开的扩展词典接口所以处理方式要绕一下。我的方案是在 TongSearch 的查询网关里维护一份业务词汇表索引端不处理查询端在传给 analyzer 之前先把这些专有名词用空格或者特殊字符包起来变成独立的词项单元。比如把“周杰伦”改写成“周杰伦”再让 smartcn 处理切分出来就是一个完整词“周杰伦”。这是一个非常实用的 workaround代价是查询端多一次文本预处理换来的是稳定可控的专名识别。如果你允许动索引端也可以在写入文档前把文档里出现的专有名词提前替换成一个不会产生歧义的占位符分词完成之后再替换回来。但这种做法不够优雅除非你的数据格式非常规整否则我建议优先在查询端做。6.2 中英文混排的切分黑洞smartcn 面对“iPhone15 发布”这类中英文混排文本时有时候会把“iPhone15”切成“iPhone/15”有时候又切成“iphone15”整体词条行为不稳定。这个问题的根源是 smartcn 的字符模型对拉丁字母和数字的处理策略和中文完全不同。我建议在接入 smartcn 前先加一个前置过滤中文字符、英文字母串、数字串分别用分隔符保护起来。具体做法是在 char_filter 阶段把连续的英文字母或数字识别出来前后加上空格保证它们在之后的 tokenizer 里不会被意外合并或者切开。这样一个查询词只包含英文和数字时走 standard analyzer 反而更稳定中英文混合时才会调用 smartcn 做整体切分。6.3 索引端与查询端分析器不一致这个坑最隐蔽也最容易“莫名其妙”上线出问题。有时候你在 mapping 里设置了 analyzer但查询端走了 search_analyzer而 search_analyzer 没设Lucene 会回落到默认 standard analyzer导致查询词项和索引词项不一致。我线上排查过一次召回率骤降的问题最后定位到原因就是这个新同事改 mapping 时把一个字段的 search_analyzer 删掉了所有 match query 全部退化成了单字匹配。排查方法很简单用 _analyze 接口分别对同一个文本跑索引端分析器和查询端分析器对比输出词项列表。如果两边存在明显差异说明配置有遗漏。另外在 TongSearch 的查询日志里每条 query 会记录实际使用的 analyzer 名称通过日志比对也很容易发现问题。6.4 常见问题速查表现象可能原因解决方案分词结果全是单字词库文件没加载 / tokenizer 配置错误检查 smartcn 资源文件核对配置中的 tokenizer 名称查询召回率极低索引和查询分析器不一致统一设置 analyzer 与 search_analyzer专有名词被切碎词典覆盖不到查询端加入专名词表保护或改写中英混排行为不稳定字符模型冲突用 char_filter 对英文和数字做隔离索引速度下降明显HMM 计算开销离线预处理或仅对必要字段启用 smartcnmatch_phrase 查不到结果停用词导致位置间隔变大使用 slop 参数或查询前置去掉停用词7. 从单字段到多字段的检索架构演进7.1 不要把所有文本塞进一个 text 字段接入 smartcn 解决了分词问题之后下一步要考虑的是字段规划。很多初期的项目会把标题、正文、标签全部拼到一个大字段里这样写起来方便查询也方便但问题是不同字段对分词的敏感度完全不同。标题字段通常是短文本用户对标题命中比正文命中更敏感所以标题字段应该设置更高的权重正文是长文本分词后词项非常多直接参与打分很容易稀释标题的贡献。我的方案是建立一套多字段映射title 字段使用 smartcn 分词并加权content 字段使用 smartcn 分词但降低权重tags 字段使用 keyword 类型精确匹配另外再建一个 combining 字段把所有内容拼接在一起专门服务模糊检索和兜底召回。7.2 用 copy_to 实现字段级搜索权重TongSearch 支持 copy_to 指令可以把多个字段的值复制到一个目标字段里。我在文章类的索引里经常把 title、content、author 三个字段复制到一个名为 search_text 的字段query 默认只查 search_text。这样业务侧不用关心该搜哪个字段只需要针对 search_text 设置一套统一的分词规则。search_text 字段同样挂 smartcn 分析器并且因为我控制了复制字段的内容组合顺序分词效果会比直接拼出一个大杂烩更可控。这里的操作要点是title 内容在前、content 内容在后既保证标题词的词项位置靠前又能通过字段权重把标题相关度传递到最终排序里。8. 真实项目数据复盘8.1 评测数据从词项质量看 smartcn 的收益去年年底我们拿了一批 50 万篇的新闻语料做了评测。同样一套 TongSearch 集群索引配置从 standard 分析器切换到 smartcn 分析器前者的平均召回率只有 62%后者提升到 89%精确率从 58% 提升到 76%。核心原因就是标准分词器把中文句子切成了单字导致查询词项和索引词项对不上倒排索引失去了意义。这次评测也暴露了 smartcn 的短板在“精确短语匹配”类需求上它切出来的词项往往比人眼以为的粒度更粗比如“人工智能处理器”在 smartcn 里是一个整体词条而用户可能只记得“智能处理器”又会导致短语匹配失效。所以我提醒团队不要只依赖分析器本身来解决问题要给产品层提供一定的 query 改写能力。8.2 线上阈值调优的三板斧TongSearch 的查询参数里除了常规的 minimum_should_match还有查询体超时时间、分片请求并发数等参数这些参数直接决定用户体验。我的建议是先用默认参数跑一天观察查询延迟和召回率再根据业务场景做定向调整。短 query一到三个词建议 operator 设为 and确保高精确率。中长 query四到十个词建议 minimum_should_match 设为 70% 到 80%兼顾召回和精度。超长 query增加超时时间同时考虑对 query 做摘要提取只保留核心实体词参与检索。这“三板斧”听起来简单但在实际项目里每一个参数都经历过多次线上回归才确定下来。参数不是越大越好也不是越小越好要结合你自己的数据分布去测试。8.3 关于 smartcn 的未来替代方案老实说smartcn 在 Lucene 生态里已经是很成熟的方案了但它所在的位置还是比较底层的“通用智能分词”并没有针对特定领域的精调能力。如果项目发展到一定阶段需要更强的语义理解、实体识别、同义词召回我建议在 smartcn 之上再叠加一层语义向量模型走“召回 重排”的双阶段路线。TongSearch 目前已经在做这个方向的尝试先用 smartcn 做词项召回再用向量检索把语义相近的文档捞回来最后通过一个轻量级排序模型对两路结果做融合。这个方案短期内还替代不了 smartcn 的角色因为语义向量模型的训练和部署成本都不低而且对长尾新词的覆盖能力反而不如概率分词模型。我在实际运维这套环境时有个很深的体会中文分词没有银弹smartcn 也不是最优解但它是一个基线足够高、维护成本足够低的起点。先用它把检索系统跑起来再根据业务反馈一层层加语义能力这才是一条务实的技术演进路线。如果你正在给自己的搜索系统做中文分析器选型我建议你先把 smartcn 跑通再用自己的数据去做评测对比让数据告诉你下一步该往哪个方向走而不是在选型阶段就陷入各种工具的口水战里。 
)
