Elasticsearch实现带Levenshtein距离阈值的Fuzzy collapse咨询

1. 原生能力支持情况 #

Elasticsearch 不原生支持基于莱文斯坦距离的模糊折叠能力。
现有collapse折叠功能的核心逻辑是基于字段的精确等值匹配完成分组，仅支持对keyword、数值等可精确匹配的字段做折叠，同组文档必须保证折叠字段值完全一致。目前Elasticsearch内置的fuzzy模糊匹配能力仅作用于查询召回阶段，不会介入折叠阶段的分组判定逻辑，别指望靠fuzzy查询绕路实现效果，fuzzy只管哪些文档能被召回，管不了召回后的文档按什么规则归组折叠。

2. 官方功能需求提交渠道 #

你可以通过两个渠道提交需求：

• 直接在Elasticsearch官方代码仓库的Issues板块提交功能申请，提交时建议附上你实测的效果提升数据、具体业务场景、性能要求，有明确落地价值、普适性强的需求会被官方优先排期评估
• 如果你是Elastic商业订阅用户，可以通过官方付费支持通道直接提交功能需求，这类需求的处理优先级会高于普通社区提交的issue

3. 低额外耗时的替代方案 #

以下方案都不会带来明显的查询耗时上涨，可根据你的业务场景选择：

• 预计算聚类前置方案（最推荐）：把莱文斯坦距离的匹配逻辑从查询阶段前移到数据写入/预处理阶段，写入文档时就基于设定的编辑距离阈值做相似ID聚类，给同一类的文档打上统一的归一化clusterID，存为独立的keyword类型字段。查询时直接按这个预计算好的字段做常规collapse即可，查询阶段零额外计算开销，时间复杂度保持你现有的O(n)水平，性能和当前精确折叠方案完全一致，同时能达到你测试的百倍效果提升。如果担心预处理压力，可以给聚类逻辑加增量更新规则，新写入文档仅和已有簇的中心ID计算编辑距离，不需要全量重算所有数据，写入侧开销可控。
• 粗折叠+小范围重算方案：如果不想改造写入链路，可以在查询时做两层处理：第一层先按你现有的精确clusterID做粗折叠，拉取TopN规模的粗分结果组；第二层仅对这些粗分组的中心ID计算莱文斯坦距离，把距离低于阈值的分组合并成最终结果。因为粗折叠后的分组规模远小于全量命中的文档总数，这部分计算量极低，几乎不会增加查询耗时。注意不要在全量命中文档上做编辑距离计算，否则会带来明显的性能损耗。
• 字段归一化补充方案：给用于折叠的ID字段配置自定义分析器，在索引阶段就把常见的字符差异（比如大小写、无意义特殊字符、固定格式的偏差）做归一化处理，折叠时基于归一化后的字段做精确匹配，可以覆盖大部分编辑距离为1-2的常见模糊场景，全程没有额外查询开销，缺点是能覆盖的模糊场景有限，适合作为前两个方案的补充。

内容的提问来源于stack exchange，提问作者CM42