企业官网建设流程全解析

简介：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 \ -Dfile=target/resha-turkish-stemmer.jar \ -DgroupId=tr.text \ -DartifactId=resha-stemmer \ -Dversion=1.0.0 \ -Dpackaging=jar

第一行进入源码目录，第二行跳过测试只打包；首次构建建议先不跳测试，确认本地 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 三个真正影响结果的参数：最小词干长度、词尾表、派生后缀开关

词干分析器的「攻击性」在工程上通常不是单个开关，而是一组可配置项。可以拆成三个最实用的参数，理解这三个，调参就不靠玄学。

最小词干长度的意义最直白。土耳其语很多词根本身就是两个字母，比如 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 没有设置过小的 maxTokenLength，StandardTokenizer 默认上限通常是 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% 的改动一律打回。调参可以大胆试，但回归不能省，这是做土耳其语文本处理绕不开的一课。希望帮到你。

本文还有配套的精品资源，点击获取