1. 老司机是怎么在银行系统里把事件检测时间从45分钟缩减到5分钟的（需要梯子）
   https://medium.com/%40aliakram ... 0f7fb
   
   
2. 稀疏向量的上下文排序可解？可以的可以的老铁！（需要梯子）
   https://medium.com/adeo-tech/s ... 3eb69
   
   
3. 稀疏向量的上下文排序可解？可以的可以的老铁！（需要梯子）
   http://news.searchkit.cn/
   
   
4. 当红炸子PG在文本搜索能和ES掰腕子吗？（需要梯子）
   https://medium.com/%40rosgluk/ ... 29dc0
   
   
5. AWS OpenSearch TLS 升级生存指南（需要梯子）
   https://aws.plainenglish.io/su ... b5811
   
   
   编辑：斯蒂文
   更多资讯：http://news.searchkit.cn

1. Elasticsearch 从入门到精通系列（需要梯子）
   https://dogukanngumus.medium.c ... ba02e
   
2. Elasticsearch 从入门到精通系列（需要梯子）
   https://dogukanngumus.medium.c ... 1d620
   
3. Elasticsearch 从入门到精通系列（需要梯子）
   https://dogukanngumus.medium.c ... a527f
   
4. 不阻断PHP的前提下把TPS提高到1000你敢信？（需要梯子）
   https://awstip.com/scaling-tel ... 70521
   
5. 扔了那些没用的证书，证明你是个真正的猎手吧（需要梯子）
   https://medium.com/%40huntforw ... 8857a
   
   编辑：斯蒂文
   更多资讯：http://news.searchkit.cn

1、在 Elasticsearch 中，存储向量查询速度最高提升 3 倍
https://elasticstack.blog.csdn ... .5502

2、用于调试 LLM 延迟、成本和 GPU 饱和度的 ES|QL 查询
https://elasticstack.blog.csdn ... .5502

3、一个神级 PPT Skill，20 天 3600+ Star，背后藏着 AI 最新红利趋势
https://mp.weixin.qq.com/s/jKuNO3tNwDiOR9DyiEcUFQ

4、AI 团队协作案例：全链路研发提效实践分享
https://mp.weixin.qq.com/s/xfbYbbektVm_QcQ1M2NGkw

5、开源 Claude Code 本地代码知识图谱：code-review-graph 完整上手攻略
https://mp.weixin.qq.com/s/D2WBfa_FDfgz2n6sndLIVg

编辑：Muse
更多资讯：http://news.searchkit.cn

1、从 0 到 1 构建电商千人千面——基于 Easysearch 的个性化搜索与推荐系统实战
https://mp.weixin.qq.com/s/YkjONLHe7BIXRPHLiUwTbg

2、深入理解 Elasticsearch 写入与查询机制
https://mp.weixin.qq.com/s/YkjONLHe7BIXRPHLiUwTbg

3、Elasticsearch 6/7/8 到 Easysearch 2.x 迁移指南
https://infinilabs.cn/blog/202 ... uide/

编辑：Fred
更多资讯：http://news.searchkit.cn

1.基于 Harness + SDD + 多仓管理模式的 AI 全栈开发实践｜得物技术
https://mp.weixin.qq.com/s/ygQGSH5c7GHYDvkqWoQTXQ
2.Kubernetes 跑 AI Agent，缺的不只是算力——AgentCube 补上了什么
https://mp.weixin.qq.com/s/gwfSgeCGc9HaW6RcaGnzNw
3.AI Infra 其实没有多少新东西
https://mp.weixin.qq.com/s/Hg8uPMjTMX8Tk7slrVvfNA

编辑：Se7en
更多资讯：http://news.searchkit.cn

1.曾经红极一时的Hadoop，已经沦为二线平台？
https://mp.weixin.qq.com/s/cCpZv6vekrDLH7wEK3rk6Q


2.ElasticLens：让 Elasticsearch 集群巡检不再 “裸眼读日志”
https://elasticstack.blog.csdn ... 81746


3.在 Elasticsearch 中使用利润率与流行度加权来优化电商搜索
https://elasticstack.blog.csdn ... 66393




编辑：kin122    
更多资讯：http://news.searchkit.cn

1. 什么才是规划集群尺寸真正有价值的因子（需要梯子）
https://codeburst.io/sizing-yo ... bb9da
2. 我是怎么在重建Airbnb的搜索层的（需要梯子）
https://medium.com/%40royabhis ... c0960
 
3. 巅峰掰头 ES和PG 在全文搜索里的对决（需要梯子）
https://medium.com/%40suyash20 ... 50339
编辑：斯蒂文
更多资讯：http://news.searchkit.cn
 

1、Kubernetes 可观测性：用于更安全 EKS 故障排查的 MCP 专家 agents
https://elasticstack.blog.csdn ... 59663

2、通过项目标签和路由，在 Elasticsearch Serverless 中实现更快的跨项目搜索
https://elasticstack.blog.csdn ... 30581

3、重磅新鲜出炉：使用 Elasticsearch 插件将 ES|QL 引入你的 Grafana 仪表盘
https://elasticstack.blog.csdn ... 46123

4、重新定义Skill开发：保姆级教程&一站式开发助手发布
https://mp.weixin.qq.com/s/FgGVPw0BOZEu5sH1FdrVoQ

5、从零设计生产级 Multi-Agent Harness：架构、评估、记忆、成本与 MCP 工具接入全拆解
https://mp.weixin.qq.com/s/JPhcyDc4JwRmnMQ-76A-FQ

编辑：Muse
更多资讯：http://news.searchkit.cn

1、让搜索能力像 SQLite 一样无处不在
https://mp.weixin.qq.com/s/7Tn6CI899BZ1mPqCacNvUQ

2、留给内容平台搜索架构转型的时间不多了:从123RF图库放弃OpenSearch聊起
https://mp.weixin.qq.com/s/v3UW0cl_Ga8wfSGgynpSdw

3、如何衡量和提升 Elasticsearch 搜索召回率：通过 混合搜索 从 0.43 提升到 0.75
https://my.oschina.net/u/3343882/blog/19658268

4、不用 Logstash，如何实现 Elasticsearch 的增量数据同步？
https://my.oschina.net/u/5170379/blog/19577824

5、Easysearch analysis-ik 多词典性能优化：从性能回退到分词性能提升 25%~30%
https://mp.weixin.qq.com/s/C5EsDLsF0J0xh-0XX7-L5w

编辑：Fred    
更多资讯：http://news.searchkit.cn

1.从"猜病因"到"做化验"：AIOps 中 LLM 的正确打开方式
https://mp.weixin.qq.com/s/TI8wqs94Uzp7szQlsFj32Q

2.一个索引，所有媒体：介绍 jina-embeddings-v5-omni
https://blog.csdn.net/UbuntuTo ... 02005

3.AI Agent 记忆：使用 Elasticsearch 管理记忆，打造智能 Agent
https://cloud.tencent.com/deve ... 67232




编辑：kin122    
更多资讯：http://news.searchkit.cn

1. 多数据源的流式数据集处理（需要梯子）
https://medium.com/%40linjifan ... 969e2

2. Elasticsearch 从入门到精通系列—后面还好多连载的不贴了（需要梯子）
https://dogukanngumus.medium.c ... 42f72

https://dogukanngumus.medium.c ... ba02e

https://dogukanngumus.medium.c ... 1d620

https://dogukanngumus.medium.c ... a527f

3. 不阻断PHP的前提下把TPS提高到1000你敢信？（需要梯子）

https://awstip.com/scaling-tel ... 70521

编辑：斯蒂文
更多资讯：http://news.searchkit.cn

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

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

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

问题怎么冒出来的

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

| 时间 | 场景 | Elasticsearch | Easysearch | 说明 |
| :------------------------- | :----------------------------------------------------- | --------------: | -------------: | :---------------------------------------------------- |
| 2026-04-20 第 2 次有效重跑 | 29900 docs / bulk=250 / concurrency=3 端到端写入压测 | 129.44 docs/s | 31.21 docs/s | 这是整条写入链路的 docs/s，不是单独分词吞吐 |
| 2026-04-20 诊断样本 | 5000 docs / bulk=250 / concurrency=3 | 156.25 docs/s | 30.67 docs/s | Easysearch 的累计索引耗时约为 Elasticsearch 的 8.0x |


当时服务器上跑的就是早期多词典版本。后面修性能，追的就是这个版本和开源单词典 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 的单词典实现对照版本。所有正式吞吐结论都建立在同一数据集、同一测试方法、分词结果一致的前提上。
  
  | 时间 | 口径 | 关键结果 | 说明 |
  | :------------------------------- | :------------- | :-------------------------------------------------------------- | :---------------------------------------- |
  | 2026-04-23 17:02 CST | 初期本地复现 | 服务器多词典版本 61.39 万 tok/s，单词典版本 114.48 万 tok/s | 单词典版本快 86.49%，性能差距被明确复现 |
  | 2026-04-24 09:51:12~09:55:15 CST | 第一次正式追平 | smart 相对开源单词典基线 +7.26% | 从明显落后追到略微领先 |
  | 2026-04-25 04:14~04:16 CST | 双模式阶段复核 | smart +16.88%，max_word +20.09% | 领先优势开始扩大 |
  | 2026-04-28 12:30:56 CST | 最新正式复核 | smart +30.96%，max_word +21.31% | 当前最新结果 |
  
  整个过程就是：
  
  

• 先暴露出明显的性能退化
  
• 逐步缩小差距
  
• 追平，然后开始领先
  
• 最终在分词结果完全一致的前提下，正式反超
  
  最早的本地复现数据很关键：服务器当时跑的多词典版本只有 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 分词器](https://github.com/infinilabs/analysis-ik)
  
• [IK 字段级别词典的升级之路](https://infinilabs.cn/blog/202 ... rys-3/)
  
• [IK 字段级别词典升级：IK reload API](https://infinilabs.cn/blog/202 ... rys-2/)
  
• [Easysearch 新功能： IK 字段级别词典](https://infinilabs.cn/blog/202 ... narys/)

1、AI Coding 入门指南 - 如何更好地让 AI 真正帮你干活
https://my.oschina.net/u/4939618/blog/19654121

2、Elasticsearch 实战 | CPU 在摸鱼，查询在搬砖：一行配置性能暴涨 6 倍
https://mp.weixin.qq.com/s/2HNbW22Zyoe8llWcYiy5Uw

3、告别命令行！Easysearch 全新图形化部署体验实战详解
https://mp.weixin.qq.com/s/9i7HrtAq7CphRLvsvcrt4Q
 
4、如何衡量和提升 Elasticsearch 搜索召回率：通过 混合搜索 从 0.43 提升到 0.75
https://elasticstack.blog.csdn ... 85695

5、Elasticsearch ES|QL 视图：一个查询统领十二个仪表板
https://elasticstack.blog.csdn ... 08168

编辑：Fred    
更多资讯：http://news.searchkit.cn

1.Elastic Ramen：一个用于 SRE 调查与修复的 CLI 工具框架
https://blog.csdn.net/UbuntuTo ... 79297


2.手把手教你使 AWS OpenSearch 适用于语义搜索（搭梯）
https://medium.com/%40itsprate ... 73ce5


3.DeepSeek V4：一百万个 token，三种思考模式，以及首批真实上手报告（搭梯）
https://medium.com/ai-advances ... cc096



编辑：kin122    
更多资讯：http://news.searchkit.cn

1. 扔了那些没用的证书，证明你是个真正的猎手吧（需要梯子）

https://medium.com/%40huntforw ... 8857a

2. 老司机是怎么在银行系统里把事件检测时间从45分钟缩减到5分钟的（需要梯子）

https://medium.com/%40aliakram ... 0f7fb

3. 稀疏向量的上下文排序可解？可以的可以的老铁！（需要梯子）

https://medium.com/adeo-tech/s ... 3eb69

编辑：斯蒂文
更多资讯：[http://news.searchkit.cn](http://news.searchkit.cn/)