Easysearch analysis-ik 多词典性能优化：从性能回退到分词性能提升 25%~30%

Easysearch 版 analysis-ik 相比开源 IK 有一个重要的增强：支持多词典。简单说就是不同字段可以挂不同词库，可以叠加默认词典，也可以只用自定义词典。这是开源单词典 IK 做不到的。

功能实现初期，主要精力放在把能力跑通上。但在后来的一次写入压测中，我们发现 Easysearch 的写入吞吐和 Elasticsearch 有明显差距，最终定位到问题出在多词典的实现方式上——字段最终该用哪套词典，本来应该在分词前就算好，结果代码里把这个选择丢进了分词的热路径，每次分词都要反复切词典、重复扫同一段文本。

这篇文章记录的就是我们怎么一步步把性能拉回来、最终反超基线的过程。

问题怎么冒出来的

4 月 20 号，我们跑了一轮系统级写入压测。数据、mapping、settings、并发和 bulk 参数都一样，Elasticsearch 8.19.5 和 Easysearch 2.1.2 的写入吞吐差距大得有点不对劲：

当时服务器上跑的就是早期多词典版本。后面修性能，追的就是这个版本和开源单词典 IK 基线之间的差距。

这一步还不能直接确定问题就在分词器。但差距摆在这儿了，得继续往下排。我们先排除了几个常见干扰因素：

• refresh_interval
• 动态同义词 HTTP 服务
• mapping / settings 不一致
• 网络层和 bulk 客户端本身

采样结果很快把范围收窄了。Elasticsearch 那边热点比较分散，Easysearch 这边呢，分词链路里出现了异常集中的开销——分词过程中反复做词典选择和字典查找。

瓶颈不在 Lucene 写入链路本身，就在 analysis-ik 的多词典实现上。

根因分析

第一类问题出在实现模型上。多词典想表达的是”这个字段最终用哪套词典”，这件事完全可以在分词前算好。但早期代码里，硬是把它变成了运行时的事：

• “字段用哪个词典”变成了”运行时多轮扫描”——同一段文本对着多套词典各来一遍。
• 全局字典切换的动作放进了每字符的热路径。
• 结果就是同一段文本的扫描和查找成本翻了好几倍。

所以问题不是多词典天然慢，是实现把本该提前算好的东西塞进了热路径反复做。

第二类问题是后续优化过程中留下的额外开销。后面加的跨边界、停用词、长文本等测试本身不是性能问题的来源，它们的作用是把正确性边界补齐，确保每次优化不会改变分词结果。

最后通过性能分析确认，残留开销主要来自两处：缓存命中前还在做不必要的数据复制；诊断逻辑在生产热路径上产生了额外开销。修完之后这两处热点都从火焰图上消失了，说明性能回退确实来自真实的代码路径成本，不是测试抖动。

修复过程

整个修复分四个阶段。

第一阶段：把多词典从”运行时分发”收敛为”最终有效词典视图”

多词典能力保留，但不再让分词器在热路径里反复切词典、重复扫文本。改成在分词前就把字段最终生效的词典算好，分词过程只面对一个已经收敛好的词典视图。

说白了就是把模型拉回正确方向——多词典管表达能力，热路径只管分词。

第二阶段：逐步打掉热路径上的常数开销

留下来的每一项优化，都经过正式性能测试和采样分析验证。原则就一条：不改分词语义，只减少热路径上反复发生的查找、分配和判断。

第三阶段：补齐正确性护栏

正确性测试必须先到位，不然吞吐提升没有意义——万一分词结果变了，跑得再快也白搭。

这一轮重点覆盖了这些容易出问题的场景：

• 真跨边界场景
• 数字和量词合并，如 1号
• 自定义词典里的含符号词
• 补充平面字符跨边界稳定性
• 停用词过滤后的偏移量
• 长文本样本的稳定性
• 正式性能测试数据集的分词结果对齐

后面所有的吞吐数字，前提都是分词结果一致，避免把分词行为的变化误当成性能提升。

第四阶段：清理最后的残留开销

到 4 月 28 号，最后一轮修复集中处理两个地方：

• 词典视图命中缓存时直接返回，不再多做一次数据复制
• 诊断逻辑默认关掉，不让线上请求为调试能力买单

这两处修完，Easysearch 版 IK 就不只是恢复到单词典版本附近了，在正式测试里已经明显领先。

用数据看恢复过程

为了不把系统级写入压测和分词器性能测试混在一起，下面只看几个关键节点。2026-04-20 的 docs/s 是系统级写入吞吐，后面的 tok/s 是单独的分词器吞吐。

这里说的”开源 IK 基线”就是开源 IK 的单词典实现对照版本。所有正式吞吐结论都建立在同一数据集、同一测试方法、分词结果一致的前提上。

整个过程就是：

• 先暴露出明显的性能退化
• 逐步缩小差距
• 追平，然后开始领先
• 最终在分词结果完全一致的前提下，正式反超

最早的本地复现数据很关键：服务器当时跑的多词典版本只有 613896.67 tok/s，单词典版本 1144843.77 tok/s。后面所有修复就是冲着这个差距去的。

三张图分别对应问题暴露、分词复现和修复结果：第一张展示服务器 bulk 写入吞吐的系统级差距；第二张展示多词典版本和单词典版本的本地分词差距；第三张展示分词结果对齐后，Easysearch 版 IK 怎么一步步追上来，最终实现 25%~30% 的分词性能提升。

为什么说 Easysearch 版 IK 现在更好

这次修复的价值不只是消灭了几个热点，更重要的是把多词典能力、分词正确性和性能测试体系一起补齐了。

1. 功能更强，性能代价可控

开源单词典 IK 模型简单，但表达能力也弱。Easysearch 的多词典能力要解决的是字段级词库隔离、自定义词典叠加这些实际需求。

关键问题是：能不能把这些能力的性能开销压到足够低。修复后的结果证明，可以。

2. 正确性护栏更完整

这轮补上的测试不只是几个短样例，覆盖了更容易翻车的边界条件：

• 真跨边界场景
• 长文本稳定性
• 自定义词典和符号词
• 数字量词合并
• 停用词过滤后的偏移量

这意味着以后再做性能优化，必须同时保证分词结果不变。想靠改分词行为换吞吐，测试会先拦住。

3. 性能测试体系更严格

这轮之后，Easysearch 对 analysis-ik 的正式性能结论统一按一套标准出：

• 同一数据集
• 同一测试方法
• smart 和 max_word 双模式
• 分词结果一致
• 有性能分析结果支撑

这套体系能避免两个常见坑：只看单轮吞吐波动就下结论，或者分词结果已经变了还在比性能。

小结

多词典能力在实现初期，主要精力放在功能补齐上——先把字段级词库隔离、自定义词典叠加这些能力跑通，性能优化是后面分阶段来的事，没办法一蹴而就。

这轮优化下来，核心思路其实就一条：把词典选择从分词热路径里挪出去，提前收敛好，让分词过程只面对最终的词典视图。再配合热点清理和正确性护栏，增强功能和更高性能完全可以兼得。

截至 2026 年 4 月 28 日，在本地 Mac 笔记本上的多轮 benchmark 中，Easysearch 版 IK 在 smart 模式大约领先开源单词典 IK 基线 25%~30%，max_word 模式大约领先 20% 左右，分词结果完全一致。具体数字每次跑会有波动，但趋势是稳定的。

这也是 Easysearch 版 IK 相对开源版更有价值的地方：不是多了几个配置项，而是在多词典能力、分词正确性和分词性能三个方面都给出了可验证的结果。

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网：https://easysearch.cn

作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。

相关文章：

• 开源 IK 分词器
• IK 字段级别词典的升级之路
• IK 字段级别词典升级：IK reload API
• Easysearch 新功能： IK 字段级别词典