在系统开发中，模糊匹配一直是个令人头疼的问题。用户输入"receive"时误打成"recieve"，或者将"张三丰"写成"张三峯"，系统究竟该不该识别？如果全部允许，误召回率会急剧上升；如果严格死板匹配，用户体验又会彻底崩塌。

LongCat AI 的解决方案其实非常务实——它并不依赖黑盒语义向量去"猜测"用户意图，而是采用一套可配置、可解释、可随时验证的编辑距离机制，将模糊匹配量化、参数化，并落到工程可控的层面。

直接支持 Levenshtein 距离驱动的模糊查询

首先要解决的核心问题是：究竟怎样才算"近似"？LongCat 选择了 Levenshtein 编辑距离——每次插入、删除或替换计为一次编辑操作。例如用户搜索"recieve"，系统计算后与"receive"仅差一次替换操作，于是将其归入候选结果。这种判断逻辑完全透明，阈值设定、允许编辑次数都由你掌控。这与 Elasticsearch 的 fuzziness: AUTO 参数本质一致，LongCat 已在检索层内置适配，会根据词长动态允许 0 到 2 次编辑，既不会因阈值过严而排除正确结果，也不会宽松到把"苹果"匹配成"屁股"。

对于业务规则敏感的场景——如客户 ID、商品编码、内部系统名称——这种透明可解释的容错机制，远比丢给一个向量模型、却无法追溯结果来源要可靠得多。

中文场景强化：拼音 + 编辑距离双重校准

纯字符距离在英文环境中够用，但放到中文语境下就力不从心了。"张三丰"和"张三峯"外观相近，编辑距离可能只有 2，但如果不做预处理，系统可能因缺字或形似字直接判定不匹配。LongCat 的做法是默认启用拼音转换预处理——将"张三丰"转为拼音"zhangsanfeng"，"张三峯"同样转为"zhangsanfeng"，再基于拼音计算编辑距离。这样，生僻字、异体字、输入法误打带来的模糊问题大体上都能覆盖。想验证此功能是否生效很简单：检查日志中是否有 fuzzy_matching initialized with pypinyin 这条提示即可。

前缀锁定与扩展控制，兼顾精度与性能

模糊并不等于无限制容错。LongCat 默认启用 prefix_length: 1–2，意味着首一或两个字必须精确匹配。例如搜索"支付"，系统不会把"支援""支配"纳入结果，因为前缀不匹配——这个设计有效防止了模糊匹配蜕变为"瞎匹配"。同时，max_expansions 参数控制每个错误词最多扩展多少个候选词，避免单个拼写错误引发上千个候选，拖慢响应速度。这两个参数可在 Dify 或自定义 API 请求中直接指定，无需改代码，纯属配置层面的操作。

可插拔同义词映射，覆盖业务专有名词

标准算法还有一个硬伤：无法处理缩写与全称之间的匹配。例如"CRM"和"客户管理系统"，编辑距离相差数十，Levenshtein 算法不可能将其等价处理。LongCat 允许加载 CSV 格式的自定义词表（比如 custom_fuzzy.csv），格式为"标准词,模糊变体"，一行对应一组映射，重启服务即生效。对于企业知识库而言，这一功能几乎是刚需——将"美团骑手App""Meituan Rider""MRider"统一指向同一份文档条目，比反复调整模型参数要直接得多。

不复杂，却非常实用。这才是可落地的技术选择。