简介Resha 是一套用 Java 实现的土耳其语词干分析器主要面向需处理土耳其语文本的 Java 开发者与自然语言处理研究者旨在解决词形还原时常见的过度截断问题。其“低攻击性”策略依托基于词素 n-gram 统计语言模型生成的词干词典能够返回最可能的词干而非简单粗暴的规则截断因而适合信息检索、文本分类等非相邻词依赖场景。压缩包共 11 个文件以 5 个 Java 源码、2 个 dict 词典数据、1 个 XML 配置为主整体仅 3.57MB结构清晰便于查阅。已有 193 人学习/下载。资源内置超过 110 万个词干对借助 HashMap 实现高速查询同时采用枚举方式封装单例、线程安全与惰性初始化。读者可深入研读源码及词典构建思路掌握兼顾速度与精度的组件设计也可直接将其集成至土耳其语预处理流水线中。1. 在土耳其语搜索里低攻击性词干分析器比暴力截断更可靠土耳其语是高度粘着的语言一个词可以挂上复数、所有格、格等多层词缀例如 ev房子变成 evlerimizden从我们的那些房子里。如果沿用英语或俄语那种猛砍词尾的强词干思路很容易把词根一起吞掉搜索召回上去了排在前面的却是一堆语义无关的页面。resha-turkish-stemmer 走的路线正好相反只剥最外层、最常见的语法后缀保留词根以及派生结构同时用 Java 实现保证吞吐。这里要解决的问题很具体它是什么、和强词干及形态分析类工具差在哪、怎么在一条 Lucene 搜索链路里接上它、以及哪些坑会让土耳其语搜索项目上线当天翻车。适合正在维护 Java 技术栈、需要处理土耳其语文本的开发者尤其是跑过经典词干算法后又觉得结果不对味的人。2. 土耳其语粘着语结构为什么「少裁一刀」比全链剥壳更可靠2.1 一个词能拆出的词缀链先看清土耳其语到底难在哪土耳其语的构词靠「词根 一层层后缀」不断扩展。名词的常规链条大致是词根 复数 所有格 格后缀。拿 ev 举例ev → evler房子们→ evlerimiz我们的房子们→ evlerimizden从我们的那些房子里。每一步都遵循元音和谐比如 -ler/-lar 会根据词干最后一个元音是 e 还是 a 自动切换。更麻烦的是动词和名词之间的转换sev-爱→ sevgi爱情→ sevgisiz没有爱的→ sevgisizlik无爱状态词根 sev- 在这个过程里被改写了。这种结构带来两个后果。第一词干提取不是简单「去掉最后两个字符」因为同一个语法含义在不同元音环境下对应不同字符形态规则之间还有交叉。第二通用语言的分词器在土耳其语上不好用是因为它假设「词根 少量词缀」而土耳其语往往是「词根 一串词缀」一个不小心就把词根所在的头几个字母判成新词缀又剥一轮。面对这种数据少裁一刀往往比全链剥壳更安全。2.2 三条词干处理路线的取舍强词干、形态分析、轻度词干实际选型时线上 Java 项目常见的方案大致分三类强词干提取、形态分析、轻度词干提取。经典强词干算法例如 Snowball 里的土耳其语规则会把词尾反复剥掉速度快但攻击性很强形态分析工具Zemberek 这类框架会用词典和形态规则把词还原成词典词元精度最高但模型体积和计算开销都不小本标题要说的轻度词干分析器恰好卡在中间——只去掉高频语法后缀不追到词元速度接近强词干误裁率明显更低。路线典型产物速度精度适合场景强词干被反复截断的词根快召回高、精确率低召回优先的大而粗糙索引形态分析词典词元慢最准语法要求高的问答、翻译轻度词干去掉常见后缀的词形快召回与精确较均衡站内搜索、文本去重、舆情匹配我在做土耳其语站内搜索时选轻度词干理由很简单搜索系统最终需要的不是「语言学上正确」的词元而是让「查询词」和「文档词」能对得上。用户搜 evlerimizden 时文档里更可能写的是 evler两个表面形式差的是词缀而不是语义轻度词干把最后一两层后缀剥掉就足够建立对应关系。硬要还原到 ev反而会把 evler 和 eve 混进同一个桶排序列里出现一堆与「房子」无关的结果。2.3 本地跑通最小用例把 jar 装进本地仓库并调用常见的落地方式有两种拿到源码就在项目里本地构建或者直接把 jar 放到 lib 目录。我更推荐第一种因为你能同时拿到它依赖的其它库清单后续排查版本冲突也方便。下面是一个把构建产物装进本地 Maven 仓库的通用做法cd resha-turkish-stemmer mvn -DskipTests package mvn install:install-file \ -Dfiletarget/resha-turkish-stemmer.jar \ -DgroupIdtr.text \ -DartifactIdresha-stemmer \ -Dversion1.0.0 \ -Dpackagingjar第一行进入源码目录第二行跳过测试只打包首次构建建议先不跳测试确认本地 JDK 版本兼容。第三到第八行是 Maven 的 install-file 目标把 target 下的 jar 注册进本地仓库groupId、artifactId、version 是项目自己定的坐标之后 pom 里依赖就用这三个值。这里没有给出某个公开仓库地址因为最常见的情况是你从内部渠道拿到源码坐标按团队规范重新定义一遍更省心。装好依赖后核心调用其实很短。我习惯先写一个适配类把库的入口收敛到一个方法里将来换实现或加缓存都只动一处public class ReshaWordStemmer { // 核心类名以实际引入的 jar 导出为准先封装一层便于替换 private final TurkishStemmer delegate new TurkishStemmer(); public String stem(String raw) { if (raw null || raw.isEmpty()) { return raw; } // 如果上层没有做小写归一化这里需要按土耳其语规则处理 String token raw.toLowerCase(Locale.forLanguageTag(tr-TR)); return delegate.stem(token); } }这段代码最关键的是Locale.forLanguageTag(tr-TR)。土耳其语有 i 和 ı 两个小写形式用默认 Locale 处理会出现「I 变成 i、İ 变成带点 i」这类脏数据导致索引侧和查询侧词干对不上。delegate 封装库对外暴露的 stem 方法具体类名和包名取决于 jar 版本TurkishStemmer 只是占位。调用时注意三点实例要复用词干器通常不是线程安全的多个线程共用一个实例前要确认官方实现是否带锁入参应该是单个 token 而不是整句话小写归一化放在词干提取之前放后面等于没处理。为什么不自己写正则剥后缀我在早期也试过看起来 -ler/-lar、-in/-ın 就那几个组合写起来似乎不难。但实际跑一遍就发现问题kirlenmek 这种词词根本身就是 kir正则按「以 len 结尾就去掉」会把词根一起吃掉还有元音和谐导致的词干内部变形正则几乎没法穷举。用现成库省下的不只是代码量是那些你根本没预想到的边界。3. 接进 Lucene 搜索链路用自定义 TokenFilter 把词干器接上3.1 pipeline 位置词干提取既不是第一步也不是最后一步Lucene 分析器是一条过滤器链Tokenizer 负责把文本切成 token后面的各个 Filter 按顺序改写 token。土耳其语词干提取在这条链里的位置一般放在小写和语素归一化之后、索引写盘之前。原因很直接后缀匹配依赖准确的小写形式而词干提取会改掉 token 的字符序列之后再做什么大小写操作意义已经不大了。常见的链路是StandardTokenizer → TurkishLowerCaseFilter → ReshaStemFilter。TurkishLowerCaseFilter 处理 i/ı 的规则比通用的 LowerCaseFilter 更贴合土耳其语。如果你用的分词器不是 StandardTokenizer还要先确认它有没有把词缀截断例如把 evlerimizden 拆成 evler 和 imizden 两个 token词干器就永远看不到完整词形效果直接打折。这也是为什么词干提取必须放在分词之后、同时尽可能早参与的原因。3.2 写一个 TokenFilter 的完整代码与参数说明新版 Lucene 里自定义 TokenFilter 需要继承 TokenFilter 并重写 incrementToken。下面这个 ReshaStemFilter 是我在项目里用的版本去掉业务逻辑后基本就是最小骨架import org.apache.lucene.analysis.TokenFilter; import org.apache.lucene.analysis.TokenStream; import org.apache.lucene.analysis.tokenattributes.CharTermAttribute; public class ReshaStemFilter extends TokenFilter { private final ReshaWordStemmer stemmer new ReshaWordStemmer(); private final CharTermAttribute termAtt addAttribute(CharTermAttribute.class); protected ReshaStemFilter(TokenStream input) { super(input); } Override public boolean incrementToken() throws IOException { if (!input.incrementToken()) { return false; } String original termAtt.toString(); String stemmed stemmer.stem(original); if (!stemmed.equals(original)) { termAtt.setEmpty().append(stemmed); } return true; } }这段代码的逻辑分三步先让上游 tokenizer 或 filter 产出一个 token拿不到就返回 false 结束流然后把当前 term 取出来交给词干器最后只有当结果有变化时才改写 term否则保持原样省一次属性写入。termAtt 通过 addAttribute(CharTermAttribute.class) 取得这是 Lucene 分析器里所有 token 共享的字符通道直接改它就能实现「把 evlerimizden 改成 evler」这类替换。几个参数值得留意。第一stemmer 实例在 filter 构造时创建一次不在 incrementToken 里 new避免每来一个 token 都触发对象构造。第二这个 filter 没有处理 positionIncrement、type 和 keyword 属性也就是说遇到被标记为 keyword 的品牌名时词干器照样会动手如果需要保护专名得在进入 filter 前拦截。第三CharTermAttribute 的字符串在 Lucene 里是 char[]toString 会复制一份token 量大时有一点开销可以先用 termAtt.length() 和 termAtt.buffer() 做个长度判断明显是数字或缩写的 token 直接跳过。3.3 索引与查询同时生效自定义 Analyzer 的组装方式写好了 Filter还要把它组装进 Analyzer才能在索引和查询两侧同时生效。下面这个最小 Analyzer 就是干这件事的import org.apache.lucene.analysis.Analyzer; import org.apache.lucene.analysis.Tokenizer; import org.apache.lucene.analysis.standard.StandardTokenizer; public class ReshaTurkishAnalyzer extends Analyzer { Override protected TokenStreamComponents createComponents(String fieldName) { Tokenizer source new StandardTokenizer(); TokenStream filter new TurkishLowerCaseFilter(source); filter new ReshaStemFilter(filter); return new TokenStreamComponents(source, filter); } }createComponents 在 Lucene 里每次打开新 reader 或解析新查询时会被调用所以 filter 链每次重建但 ReshaStemFilter 内部的 stemmer 是成员变量新 filter 也会带新 stemmer 实例不存在跨线程共享问题。使用 Analyzer 时要注意索引用的 Analyzer 和查询用的 Analyzer 必须完全一致包括 filter 的顺序。如果索引侧加了 ReshaStemFilter 而查询侧只做小写那么查询词 evlerimizden 不会被改成 evler和文档里的词干 evler 匹配不上召回会明显变差。如果担心低攻击性也会带来误裁可以额外建一个 raw 字段把原文原样写入查询时短语查询走 raw、普通查询走 stemmed。这样等于给精确匹配留了一条后路但索引体积会多一点查询解析器也要按字段分流复杂度上去了不是所有场景都值得。4. 性能与攻击性调参先测每秒词数再动三个关键参数4.1 最小基准测试预热 JIT 再统计每秒词数「快速」是这个库的卖点但每个环境的 JDK、CPU 和对象分配策略都不一样不能拿文档里一个数字当定论。我自己一般先写一个最简单的计时器在应用代码里跑几百轮再取稳定值// 准备一份有代表性的词表混合短词、长词缀链和外来词 String[] words loadWords(); ReshaWordStemmer stemmer new ReshaWordStemmer(); // 预热跑 2 万次让 JIT 完成编译不然第一轮数据会虚低 for (int i 0; i 20_000; i) { stemmer.stem(words[i % words.length]); } long start System.nanoTime(); int n 200_000; for (int i 0; i n; i) { stemmer.stem(words[i % words.length]); } long costMs (System.nanoTime() - start) / 1_000_000; System.out.println(cost costMs ms, ops/sec (n * 1000.0 / costMs));预热这段容易被忽略。JIT 在第一次循环就把热点方法编译成本地码不预热的话第一次测量可能比稳态慢几倍于是得出「这库很慢」的错误结论。循环里用i % words.length是为了反复命中同一个词表子集避免数组越界也让词干器持续执行同类路径得到更接近真实查询分布的吞吐而不是单一长词的极端值。这个测试不适合线上直接跑但足够用来判断「一次查询要处理几千个词时会不会成为瓶颈」。如果单线程吞吐量低于每秒几万词就要先怀疑是不是每次调用都在重新分配内部对象这时去翻实现看 stem 方法里有没有在循环外缓存可复用的 StringBuilder。基准结束后记得把预热代码从线上路径里移除否则每次启动都多一段空转。4.2 三个真正影响结果的参数最小词干长度、词尾表、派生后缀开关词干分析器的「攻击性」在工程上通常不是单个开关而是一组可配置项。可以拆成三个最实用的参数理解这三个调参就不靠玄学。参数作用推荐初值调大后的代价最小词干长度词干短于指定长度时不继续剥2 或 3过裁事件显著减少但长词缀链可能留尾巴词尾表附加词列表控制哪些后缀算语法后缀默认名词后缀加动词后缀会提升动词召回误裁率也随之升高派生后缀开关是否处理 -lık/-lik/-sız 这类派生词尾关能聚合更多近义表达但词形差异变大时精确匹配受损最小词干长度的意义最直白。土耳其语很多词根本身就是两个字母比如 at马、su水。如果允许把词干裁到 1 个字符极端情况下词会被剥成 a 或 s和所有开头相同的词混到一个桶里。设成 2 或 3 之后词根短的词基本保住代价是 evlerimizden 可能停在 evler 而不是 ev但对搜索来说这反而是期望行为。提示调参前先存一份当前参数组合的基线输出否则改完连后悔药都没有。词尾表和派生后缀开关决定的是攻击性的上限。这类库的默认值通常是相对保守的正好与标题里「攻击性较低」对应我一般不会一上来就加动词词尾而是先在文档集上抽样看误裁率低于预期再加。加动词后缀是典型的收益风险并存动词词尾变化比名词丰富得多召回变好的同时okumak读和 okul学校这类同词干不同概念的词也可能被合并语义搜索场景里这就是翻车点。4.3 用两个指标量化攻击性词干一致率和过裁率调参不能靠「感觉更好了」要用数字说话。我常用两个指标配合评估词干一致率和过裁率。词干一致率回答「该合并的是否合并」即一组表面形式不同的词是否被映射到同一个词干过裁率回答「不该合并的是否被拆坏」即正常词是否被裁得面目全非。// 简化版本StemCase 记录一个表面词和期望词干 int consistent 0; int overCut 0; for (StemCase c : cases) { String actual stemmer.stem(c.surface); if (actual.equals(c.expected)) { consistent; } if (actual.length() c.expected.length()) { overCut; } } System.out.println(一致率 consistent * 100.0 / cases.size()); System.out.println(过裁率 overCut * 100.0 / cases.size());一致率针对召回过裁率针对精度。这里的关键是 expected 的定义它不是语言学词元而是「这组词在搜索场景下应该共享的形式」。比如 evlerimizden 的 expected 可以定成 evler而不是 ev因为把 evler 和 ev 合并对普通全文搜索意义不大反而增加噪音。当过裁率超过 3% 到 5% 时我倾向于把攻击性调回去即使一致率看上去很漂亮排序阶段每多一个错配词相关性分就会被拉低一次这是用精度换召回时最常见的隐性成本。5. 土耳其语词干器接生产前的四类踩坑记录现象、原因、解法5.1 大小写 Locale 不对索引和查询词干对不上现象同一条查询词索引侧能匹配的词干查询侧算出来不一样召回时多时少。原因土耳其语 i/ı/İ 的映射是 Locale 敏感的。默认 Locale 的 toLowerCase 会把 İ 转成带附加点的 i而土耳其语规则要求 İ 转成 i、I 转成 ı。索引侧和查询侧只要有一边用了默认 Locale词干就分叉。解决全链路统一用Locale.forLanguageTag(tr-TR)不要依赖 Lucene 默认的 LowerCaseFilter显式在 Analyzer 里用 TurkishLowerCaseFilter顺序放在词干器之前。改完之后用「İstanbul」和「istanbul」这类真实词对做一次索引-查询联调。5.2 超长词被整词丢弃长词缀链词召回为零现象evlerimizden 这类六七个音节的长词在索引里查不到分析器输出里没有 token。原因部分分词器和 filter 对超长 token 有保护策略超过阈值常见 32 或 64 字符的词会被跳过或截断。土耳其语词缀链很容易触到这个上限。解决先确认 Tokenizer 没有设置过小的 maxTokenLengthStandardTokenizer 默认上限通常是 255一般够用如果自己改了参数就把阈值放宽到 512。再不行打印分析器输出看长词是根本没进来还是进来后被词干器塞回空串。空串这条要特别查词干器对某些纯词缀组合可能返回空filter 里写入零长度字符串会让该 token 从索引里消失。5.3 直接拿词干结果做短语匹配短语全部失效现象加了词干器后带引号的精确短语搜索匹配率骤降原文里明明存在的短语就是搜不到。原因短语查询要求所有词按原顺序连续出现而索引侧的词已经被改成词干形式原文里的表层词在索引里不存在。解决把精确短语查询引到 raw 字段普通词查询继续走词干字段。这是常见的双字段方案。如果你的系统里有大量带引号的检索需求必须给词干字段单独留一个原文通道否则功能上线当天就会被用户投诉。我在第三章提过这个方案生产实践里这句话值得当真。5.4 性能测试第一次跑出「很慢」的假数据现象用 1 万条真实文档建索引词干器处理和纯小写相比慢了 10 倍换一个机型又快了 5 倍结论互相打架。原因没有区分 JIT 预热前后的差距、GC 停顿和对象分配。词干器在 Java 里主要开销在字符串创建和数组复制第一次跑和稳定跑相差很大如果用线上日志回放去测日志里的词分布不均匀长复合词会把平均时间拉高。解决统一用预热后的稳态吞吐来汇报至少跑 3 轮取中位数对比测试只比同一个 JVM、同一台机器上的相对差异不跨机型比绝对值。这条解决完「快速」的结论才有底气写进项目评审里。6. 进阶技巧用词干对照集锁住攻击性把调参变成回归测试参数可以调但每次调完都要能回答「攻击性是变强了还是变弱了」。我建议在项目里维护一份词干对照集格式每行一个表面词加一个期望词干用 Tab 分隔数量在 200 条左右。选词来源有四个线上搜索日志的高频词、土耳其语教材里的常用词缀链、品牌名和地名这类不该被裁的专名、以及你在线上踩过坑的真实词。专名必须进对照集因为词干器的误裁有一大半落在这些词上比如某个品牌名恰好以常见词尾结尾被削掉一个音节搜索就再也匹配不到。有了对照集调参就变成跑一趟回归。下面这个 shell 循环是java -cp方式逐词验证的最小做法适合在改完参数或换了库版本之后顺手跑一遍while IFS$\t read -r surface expected; do actual$(java -cp target/resha-turkish-stemmer.jar YourStemmerCli $surface) if [ $actual ! $expected ]; then echo FAIL: $surface - $actual, expected $expected fi done stem-gold.tsv这段脚本的核心逻辑是从对照集读入每一对词调用命令行入口拿到实际词干和期望值对比。任何不一致都打印出来方便直接定位是哪一个参数把某个词类带崩了。建议把它加进 CI每次改动库版本或调整词尾表时自动执行一次失败就阻断合并。这样调参不再是拍脑袋而是有数据兜底。我自己的教训是某次为了追召回把动词派生后缀开关打开结果一个地名被当成「从某地来的人」后缀给削掉线上搜索返回了完全错误的地域结果排查花了一整个下午。那之后我把专名词表写进对照集并规定过裁率超过 3% 的改动一律打回。调参可以大胆试但回归不能省这是做土耳其语文本处理绕不开的一课。希望帮到你。本文还有配套的精品资源点击获取