不知道有多少人在项目里遇到过这种情况拿着一个分词组件就想把词库过滤一起搞定结果折腾半天效果却不尽如人意。我之前在做一个文本清洗模块时就踩了这个坑项目里用了 WordSegmenter 的分词功能搭配自有词库做过滤想法很直接——分词之后把命中的词条去掉就行。但实际跑下来结果差强人意准确率和召回率双双拉胯最后没办法反璞归真改用 JDK 自带的过滤功能反而效果稳了。今天就把这段真实的折腾过程整理一下包括最初为什么选 WordSegmenter、词库过滤在哪个环节翻车、为什么最后转向 JDK 自带方案、具体落地代码怎么写以及遇到的各种排查实录。整个思路其实适用于很多分词组件的场景不只是 WordSegmenter希望给还在分词过滤泥潭里的同行一个参考。1. 需求源头与分词选型复盘1.1 一上来就定方案为什么先选了 WordSegmenter先说背景。这个需求本身不难理解业务方给了一批文本数据需要把里面某些自定义词条产品型号、敏感名称、垃圾词等识别出来然后做过滤。听起来就是标准的词典匹配 删除问题。但难点在于文本不是干净的词条之间有分隔符、大小写不统一、中英文混排而且还有一部分词是分词后才会自然暴露出来的组合形式。我当时第一反应就是用现成的分词器。原因也很简单自己写匹配算法不仅容易挂一漏万还要考虑词边界、重叠匹配、性能等问题而分词器正好可以先把长文本切成一个个词语块后续只需要判断哪些块命中词库即可。这是一种很常见的工程思路但也正是这个思路后续埋了不少雷。选 WordSegmenter 是基于两个考虑一是它纯 Java 实现包体小项目里直接引入依赖就能跑不用额外搭服务二是它本身支持扩展词库和自定义词典官方文档里也写了可加载自有词库进行分词和过滤。这看起来特别匹配需求。当时我还简单对比了几个 Java 生态里常见的分词工具最典型的是以下几个分词组件语言依赖复杂度自定义词库过滤能力适用场景WordSegmenterJava低支持有但较弱轻量文本处理另一个国产分词器AJava中支持无内置过滤搜索引擎类场景另一个分词工具BJava低支持无内置过滤轻量级需求JDK 字符串处理Java无手动实现完全可控规则型过滤需求对比下来WordSegmenter 似乎是唯一一个分词 过滤都沾边的于是就直接进去了。现在回头看这个选型其实一开始就混淆了一个重要概念——分词器的过滤能力和词库过滤的需求压根不是一回事。这个后面细说。1.2 分词效果与词库过滤的边界划分先用一句话把分词和过滤的关系说清楚分词是把连续文本拆成有意义的词语序列过滤是把不需要的词语从文本中剔除。两者经常一起出现但本质上是两件独立的事。分词的好坏取决于分词器的模型和词典覆盖过滤的好坏取决于你给的规则是否精准。前者解决分得对不对后者解决删得准不准。WordSegmenter 这种轻量级分词器核心精力在分词上它的自有词库过滤功能本质上就是在分词结果里做一轮简单的集合匹配。听起来简单但问题也出在这个简单上。我当时的需求描述是使用自有词库实现过滤功能。这其实包含了两层期待第一词库里的词能精准地被分词器识别出来第二识别出来后能干净地被过滤掉。第一层靠词典第二层靠过滤逻辑。实操下来两层都有问题。分词器对自定义词库的匹配率不高而且即使分出来了遇到重叠词、词根变化、中英文空格等情况过滤结果也是五花八门。后来我悟了分词器和过滤规则之间应该有一条清晰的边界。分词器只负责把文本切分到可操作的粒度过滤规则必须独立实现、独立调优不能在分词组件里强行塞过滤逻辑。这条边界划分清楚之后选型思路一下就通透了——与其用一个分词器勉为其难地做两件事不如用分词器只做分词再用 JDK 自带的字符串匹配能力做过滤。这也是最后方案的核心逻辑。1.3 从目标方案到回归朴素的思维转变踩坑初期我心里一直有一种执念——既然选了分词组件就该物尽其用用它自带的过滤功能才是正统方案否则还要分词器干什么。这种想法其实很常见尤其在开发时间紧、不想引入额外框架的时候总觉得组件自带功能就是最优解。但实践下来发现所谓自带过滤只是提供了一种可能性并不代表它适配你的业务规则。举个很直观的类比好比买了一把多功能军刀上面有开瓶器功能但你的需求是开一千个不同规格的瓶子而军刀的开瓶器只适配某一种瓶盖。这时候硬要用开瓶器去撬所有瓶子不如老老实实拿一把最简单的手动开瓶工具。JDK 自带的字符串匹配能力就是那把最简单的手动开瓶工具。这个思维转变带来两个直接收益第一过滤逻辑完全由自己掌控词库怎么加载、匹配策略怎么定、命中后怎么处理都由代码说了算第二去掉了分词组件中不属于分词核心功能的那部分不可控逻辑整体稳定性反而提升了。后面我会详细展示这套回归朴素的实现。2. 自定义词库过滤为什么差强人意2.1 词库过滤的核心逻辑与局限WordSegmenter 的过滤功能追到源码层面核心逻辑大致是这样的加载自定义词典构建一个词集合分词的时候先把文本按自身算法切成若干候选词然后逐一判断候选词是否在集合中命中的就按预设策略跳过或替换。表面上看流程没问题但它有几个天然的局限。第一个局限它依赖分词结果恰好等于词典词条。如果分词器把一个词切碎了或者把两个词黏在一起词典匹配就算命中也达不到预期。典型的例子是某某型号Pro业务词库里只有某某型号但分词器把某某型号Pro当成了一个整体词那就完全匹配不上反过来的情况也常见词库里是某某型号Pro文本里是某某型号 pro分词器把空格单独切开词典匹配就失败了。第二个局限过滤粒度太粗缺少细粒度的位置控制和上下文判断。比如文本中出现非限定词这种带否定前缀的表达简单命中词库后直接过滤会把原本有语义价值的语料也删掉。这种一刀切在真实文本里非常致命。第三个局限性能不可控。当自定义词库规模上来之后集合匹配的复杂度虽然理论上不高但分词器内部的候选生成过程本身会变慢尤其是长文本场景。实际压测下来词库从几百条涨到几万条单条文本处理耗时明显上涨数据处理总时长直接翻倍。2.2 三种必须警惕的失败场景我把自己实验过程中遇到的失败场景整理成三类基本覆盖了大多数自带词库过滤不靠谱的情况。第一类词边界漂移。文本里词和词之间经常没有清晰的分隔分词器对边界的判断和你的词库假设不一致。比如大数据平台架构你词库里是大数据分词器切出来是大数据平台架构那词库过滤完全不失效。即使能切出大数据也要考虑后续平台架构怎么处理自带过滤功能在这个层次上是没有任何策略可言的。第二类词形变化与噪声干扰。英文大小写混排、中英文之间夹杂空格、标点符号占位等都会让词库内匹配变成词库内碰运气。我试过把词库里的词全部转成小写再把文本也转小写但遇到Pro这种简短词文本里一个大写就导致彻底失配词库里带空格的和不带空格的混在一起匹配逻辑就开始乱套。第三类组合词与歧义切分。中文里复合词特别多比如人工智能技术词库里既可以是人工智能也可以是智能技术分词器怎么切直接决定过滤哪个。自带过滤功能只是切完再查不会根据词库反向影响切分策略所以经常出现词库明明有这个组合分词结果却拆得七零八落的尴尬。这三种场景叠加在一起差强人意都是客气的说法生产环境根本不敢直接用。2.3 分词词典 vs 过滤词典一个容易混淆的边界这个坑我必须单独拿出来说因为它太隐蔽了。很多文档里提到自定义词典词库过滤的时候其实说的是两件不同的事分词词典是告诉分词器这些词要作为一个整体切分出来过滤词典是告诉系统这些词要丢弃。如果你把过滤词条直接塞进分词词典那会出现什么情况以垃圾词为例假如垃圾词在分词词典里分词器会优先把它切成一个完整词这没错但假设文本里还有垃圾词库垃圾词汇等扩展形式分词器反而不切了因为它优先匹配最长词条垃圾词库剩下垃圾词变成了一个孤立的切分结果。这时候你在过滤词典里加入的是垃圾词那垃圾词汇里的垃圾词就可能被误伤或者压根没过滤干净。更麻烦的是分词词典里的词条数量过大会拖慢训练和分词速度而过滤词典则不存在这个问题因为它只是匹配不参与切分决策。我当时就是没有区分这个边界把过滤词条一股脑加进了自定义词典导致切分行为被改得面目全非。后来把过滤词条从分词词典里摘出来单独走匹配逻辑情况才好转。这一点后面在 JDK 方案里会进一步体现——根本不需要往分词器里塞过滤逻辑自然也就绕开了这个坑。3. JDK 自带过滤功能接口解析与原理3.1 到底用的是什么String 的匹配三件套说我改用 JDK 自带的过滤功能听起来好像很玄其实用的就是 Java String 类以及标准库里的几个基础接口具体来说是三件套contains、indexOf、replace配合Pattern正则做高级匹配。没有引入任何第三方依赖也没有重量级框架。这三件套的分工很明确contains用于判断文本中是否存在某个词indexOf用于定位词出现的下标replace系列用于做替换删除。这三个方法是 JDK 里最基础的东西性能经过充分优化对大多数文本处理场景足够用了。可能有人会觉得用 JDK 自带功能做过滤是不是有点太原始了。其实恰恰相反基础 API 的稳定性和可控性在业务规则日益复杂的情况下反而更占优势。你不需要去理解分词器内部的过滤策略到底怎么走的也不用担心组件升级后行为变化所有的匹配逻辑都是你自己写的问题出现了随时能排查。3.2 为什么 JDK 自带的反而够用一个很关键的问题是既然 JDK 自带功能这么基础为什么它在分词后过滤场景里反而比 WordSegmenter 的自带过滤更好用原因有三点。第一过滤需求本质上是规则明确、匹配精确的场景不需要分词器模型去猜。你词库里的词就摆在那里要做的无非是出现在文本里就删掉这种需求用字符串匹配远比用分词器内部的候选词生成 词库比对更直接高效。第二JDK 自带匹配是面向全文扫描设计的不会因为分词粒度的问题导致词条漏匹配。它不关心词边界只要你配置好匹配策略该匹配的位置都能匹配到。第三可控性极强。我可以先分词、再过滤、再还原每一步操作自己掌控排查问题只要看中间步骤的输出即可不用在黑盒里猜。另外一个现实因素是My 业务场景的词库是固定的、量级可控的不需要模型级的分词语义分析。如果换成要求语义理解的场景比如问答系统里的意图识别那当然不能只用字符串匹配。但过滤这种纯粹、机械的任务杀鸡确实不用牛刀。3.3 过滤策略的两种实现模式用 JDK 实现过滤大体上有两种模式我在这里一并给出方便不同场景对号入座。第一种模式是逐条遍历匹配。流程很简单分词之后得到一个词语列表遍历每一个词语逐个与词库做匹配命中则标记为删除。代码上可以用List.contains配合HashSet词库存储做到 O(1) 查询非常快。但缺点是只能处理已经切分好的词语块无法感知词语前后的上下文。第二种模式是原文批量替换。流程是先把文本整体交给分词器拿到分词后的结果但在过滤阶段不完全依赖分词结果而是直接对原始文本或者说分词后的带分隔符文本做词库替换。这种方式靠replaceAll或者循环replace可以对词库内任意词条做全局替换适合词条不依赖于分词边界的情况。我最后采用的是分词 原文批量替换的混合模式先用分词器做一轮粗粒度拆分把明显不该粘在一起的长文本切分开然后在切分后的文本上用 JDK 的字符串替换能力做词库过滤。这样既利用了分词器对长文本的切分能力又避开了它过滤功能的短板最终效果稳定很多。4. 实操过程用 JDK 自带方案落地4.1 准备词库数据与加载方式词库数据一般有三种来源数据库表、配置文件、本地文件。项目里我选择的是本地文件方式因为词库更新频率低、量不算大用文件方式最直观也容易做版本管理。文件格式一行一个词UTF-8 编码避免 Windows 下 ANSI 编码导致的乱码。读取时用Files.readAllLines指定字符集然后装入HashSet。这里有一个细节HashSet的去重是基于equals和hashCode所以加载词库时最好统一做一遍标准化处理——比如去掉首尾空格、统一转小写如果需要、去掉空行。不然词库里混入几个带空格的全角字符词条匹配的时候谁也找不到谁。加载代码大致是这样Path dictPath Paths.get(conf/filter_words.txt); SetString filterWords new HashSet(); try (BufferedReader reader Files.newBufferedReader(dictPath, StandardCharsets.UTF_8)) { String line; while ((line reader.readLine()) ! null) { String word line.trim().toLowerCase(Locale.ROOT); if (!word.isEmpty()) { filterWords.add(word); } } }注意词库加载一定要做标准化不然很容易出现肉眼看着一模一样、实际匹配不上的情况。首尾空格、中文全角空格、大小写都是最常见的坑。4.2 核心过滤代码基于 JDK 的两种实现接着是过滤逻辑。我分别实现了基于词列表过滤和基于原文替换过滤两个版本测试后选择了第二个作为正式方案。第一个版本基于词列表过滤适合上游已经把文本切分成词语列表的场景。核心逻辑是遍历列表把不在词库中的词保留下来public ListString filterByWordList(ListString words, SetString filterWords) { ListString result new ArrayList(words.size()); for (String word : words) { if (!filterWords.contains(word.toLowerCase(Locale.ROOT))) { result.add(word); } } return result; }这个版本的问题在于它完全依赖上游分词结果的准确性。如果上游把词切碎了这个过滤就漏了。但它也有优点过滤不会影响词组顺序保留下来的词语列表可以直接用于后续的统计、索引等操作。第二个版本基于原文替换过滤是最终采用的关键版本。它不依赖分词结果的每一个叶子节点而是把原文 词库直接匹配替换public String filterByOriginalText(String originalText, SetString filterWords) { String normalized originalText.toLowerCase(Locale.ROOT); String filtered normalized; for (String word : filterWords) { filtered filtered.replace(word, ); } return filtered; }细看之下这个版本有个性能细节需要说明每替换一个词都会生成一个新的字符串词库量大时 GC 压力比较大。优化方式有两个一是用StringBuilder手写循环替换避免频繁生成新对象二是只对文本中确实包含词库词的情况才执行替换减少无谓操作。项目里最终用了第二种优化因为大部分文本并不包含过滤词提前判断过滤成本很低。优化后的版本public String filterByOriginalTextOptimized(String originalText, SetString filterWords) { String normalized originalText.toLowerCase(Locale.ROOT); boolean hit false; for (String word : filterWords) { if (normalized.contains(word)) { hit true; break; } } if (!hit) { return originalText; } String filtered normalized; for (String word : filterWords) { filtered filtered.replace(word, ); } return filtered; }4.3 与 WordSegmenter 分词的整合流程光有过滤逻辑还不够它必须和分词流程串起来。我的整合流程是这样的先对原始文本做预处理把一些明显的噪声字符清理掉然后用 WordSegmenter 做分词得到分词后的文本序列接着用上面的 JDK 替换过滤功能处理分词后的文本最后如果需要保留词语列表而不是纯文本可以再按空格或分隔标识把结果拆回来。具体整合代码public String processText(String rawText) { // 1. 分词 ListWord words WordSegmenter.seg(rawText); String segmentedText words.stream() .map(Word::getText) .collect(Collectors.joining( )); // 2. JDK过滤 String filteredText filterByOriginalTextOptimized(segmentedText, filterWords); // 3. 返回过滤后的文本 return filteredText; }这里把分词后的词语用空格连接起来再过滤是为了保留词语的切分信息同时又能用字符串替换的方式去处理词库词。比如文本里有一个词库词是废旧金属分词结果中它被切成了废旧和金属如果用基于词列表过滤根本无法命中但用原文替换过滤分词文本连接后变成了废旧 金属如果词库中是废旧金属依然匹配不上因为中间有空格。所以真正的完整方案是词库里的词要同时考虑两种形式——原始形式如废旧金属和分词后带空格形式如废旧 金属。在生成词库时增加一个预处理步骤把词库中的每个词都通过 WordSegmenter 分词一次然后把分词结果用空格连接后也加入词库这样不管上游怎么切分都能命中。我测试后这个方案的命中率从不到 60% 直接提升到了 95% 以上。4.4 性能与准确率验证最后是验证环节。我挑了一组 500 条真实业务文本包含正常段落、混合中英文文本、带标点噪声文本和不规则文本对比了三套方案纯 WordSegmenter 自带过滤、纯 JDK 替换过滤、分词 JDK 混合过滤。方案过滤准确率处理耗时500条漏过滤数误删正常词数WordSegmenter 自带过滤72%3.2s2812纯 JDK 替换过滤88%1.8s124分词 JDK 混合过滤96%2.1s42数据说明问题WordSegmenter 自带过滤不仅准确率最低耗时反而更长因为它在分词阶段额外做了过滤相关的判断。分词 JDK 混合过滤虽然比纯 JDK 多了分词步骤但准确率提升明显漏过滤和误删都降到很低整体可接受。项目上线后这套方案一直运行稳定后来词库又扩展了三千多条性能也没有明显劣化。5. 常见问题与排查技巧实录5.1 编码问题导致的过滤失效案例先说一个最容易踩的坑词库文件编码。我在第一次加载词库时直接用Files.readAllLines(path)默认编码读取在 Windows 环境下默认是 GBK而词库文件是 UTF-8 编码。结果就是词库里的中文全部变成乱码过滤完全失效连判断文本中是否包含都匹配不上。排查过程花了一个多小时因为当时日志打印出来看起来是正常的文本直到输出词库大小才发现异常词库里的词条数量明明一千多打印出来的词条却全是乱码。后来统一改成显式指定StandardCharsets.UTF_8问题立即消失。经验所有涉及文件的读写都要显式指定编码字符集绝不要依赖系统默认。Windows 用户尤其要小心。5.2 词库顺序对替换结果的影响第二个坑比较隐蔽JDK 的replace是按词条顺序逐个执行的如果词库里有重叠词条执行顺序会影响结果。举例说明词库里有废旧和废旧金属两个词文本是废旧金属回收。如果先替换废旧文本先变成金属回收再替换废旧金属就永远匹配不上如果先替换废旧金属文本变成回收后面再替换废旧也不会误伤。解决办法是在使用replace循环之前把词库按词条长度从长到短排序。这样保证长词条优先替换短词条只处理长词条处理后残留的部分最大程度避免误替换。这个排序逻辑看似简单但如果不注意线上数据中各种奇怪的结果都会冒出来。5.3 正则特殊字符导致的异常如果你需要在过滤中支持正则匹配那就直接绕进了另一个坑。词库里的词条可能是普通文本但如果你用replaceAll(regex, replacement)去替换那么词条中的$、(、)、[、]、.等字符都会被当作正则元字符解析轻则匹配不生效重则抛出PatternSyntaxException。比如词库里有旧这种带中文括号的问题不大但如果涉及半角括号或点号就会出事。解决方案有两种一是坚持用replace而不是replaceAll因为replace的 target 参数是普通字符串不会做正则解析二是如果必须用正则那就先用Pattern.quote(word)把词条包起来转成字面量。5.4 集合类误用导致的内存翻倍还有一个性能相关的坑无脑使用List.contains做词库匹配。如果词库是用ArrayList存的contains的时间复杂度是 O(n)词库五千条、文本一万条的情况下嵌套循环的代价相当可观。我一开始用HashSet存词库所以没踩这个坑但后来在排查一个同事写的代码时发现他用的是ArrayList单条长文本过滤竟然耗时 800ms。优化方案很简单换成HashSet在词库加载时就完成去重和哈希构建。这个改动把过滤时间从 800ms 降到了 4ms效果立竿见影。5.5 问题排查速查表最后整理一份速查表方便后续遇到类似问题时快速定位。现象可能原因解决方案词库加载后中文乱码文件编码与读取编码不一致统一用 UTF-8 显式读取分词后某些词无法过滤分词切分粒度与词库不一致词库预分词同时记录带空格形式替换后文本出现错误拆除词库中存在重叠词条按词条长度从长到短排序后执行替换替换失效或抛异常词条含正则特殊字符使用replace代替replaceAll或使用Pattern.quote过滤速度极慢使用了List.contains换成HashSet存储词库大小写导致匹配不到文本和词库大小写不一致统一转小写后匹配过滤后按需还原词库更新不生效加载了旧缓存词库检查词库加载逻辑是否在每次请求前重复加载6. 从这次踩坑中沉淀下来的选型心法经历完这个过程我个人对分词 过滤这类需求有了一个很明确的判断框架先问自己过滤是规则型还是语义型。规则型过滤比如敏感词、垃圾词、型号过滤本质上是精确匹配用 JDK 基础的字符串能力完全足够甚至更可控语义型过滤比如按话题屏蔽、按意图删除那才需要更重的模型或分词能力参与。WordSegmenter 本身是个不错的轻量级分词工具但它的自带过滤功能更像是一个附加的小能力而不是一个完整的过滤解决方案。用它可以但前提是你对词库规模、文本噪声、匹配精度要求都不高且愿意接受一定程度的黑盒行为。一旦业务规则复杂起来这个附加能力就会成为短板。我后来在新的项目里也沿用了分词 JDK 过滤的组合方式只不过分词组件换成了别的但过滤层始终是独立实现、独立维护的。事实证明把过滤逻辑独立出来不仅让分词组件的替换变得更容易也让排查问题时的定位范围缩小了很多——分词有问题就看分词结果过滤有问题就查过滤代码互不干扰。最后再分享一个我在实际使用中养成的小习惯每次上线前我都会准备一组固定的标准测试文本和预期输出生成后自动比对。这组用例不多但覆盖了词边界、大小写、重叠词、带空格形式等典型场景。每次调整词库或者过滤逻辑先跑一遍确认没有回归再上线。这个小习惯帮我避免了好几次因为词库更新导致线上过滤出问题的尴尬也推荐给你的项目用起来。