近似匹配在索引层容忍字符差异，不必改写用户看到的查询词
别名: 模糊匹配 · fuzzy retrieval · 索引容错
概念解释
索引层近似匹配（approximate string matching at retrieval time）让文档里差几个字符的词仍然能被命中，查询框里的字符串保持原样。用户键入 reciept，框里仍是 reciept，结果里出现 receipt——匹配发生在倒排表或 n-gram 索引上，不经过「把查询改写成正确拼写」这一步。Lucene 的模糊查询、三元组索引查近邻，都属于这一层。
它和拼写纠错的界面不是同一件事。纠错会改写或提议改写用户看见的那句话，并需要告知与还原。近似匹配可以完全不碰那句话，只扩大召回。两者可以同时存在，但机制和责任不同：一个改的是查询，一个改的是匹配规则。
机制
倒排索引默认要求词项完全一致。打字误差、OCR 噪声、大小写与连字符会让同一对象从精确索引里消失。近似匹配在索引侧为每个词项准备一个邻域——编辑操作、字符 n-gram、或折叠后的规范化形式——查询词落入某文档词项的邻域即算命中。用户看见的查询是意图的外部记录，不必为了召回而被系统改口；改口会打断「我搜的就是这个」的检查，也会把专有形式（故意的拼法、代号）当成错误。
保留原串还有归因价值：结果是对这句话的回答。若界面先把查询换成词典词再检索，人无法分辨「库里本来就有我的串」还是「系统替我换了词」。索引层容忍把这项分辨留给排序和摘要，而不是先改写输入。
怎么研究
把「改查询」和「扩匹配」拆开测召回与意识。
- 范式：同一批含拼写变体的查询，三种条件——精确匹配、索引层模糊、先改写查询再精确匹配。记录命中、以及用户是否认为查询被改过。信息检索评测集上的拼写变体查询（如带噪声的 TREC 查询）可用来算召回，实验室任务用来算意识。
- 自变量：是否改写框内字符串、模糊是否仅在索引侧启用、有无「已替你更正」提示。
- 因变量：目标文档召回、用户对「我搜的词」的报告是否与框内一致、专有名词被改写的次数。
- 方法论注意点：若评测只看 nDCG，改写查询往往看起来更好，因为它把匹配集中到规范形式上。那测的是检索质量，不是「原词是否还在」。要把「框内字符串是否被改」单列为一份用户侧指标。
边界
零结果且查询明显非法时，只做静默模糊可能留下一页似是而非的命中，人不知道该不该改口；这时需要的是纠错提议，不是更大的索引邻域。超短串（两三个字符）的邻域会吞掉半个词表，索引层模糊应关掉或只走精确。法律、药名、库存 SKU 上「看起来像」造成的错命中代价高于漏召回，默认应精确，近似作为可开关的召回策略。
怎么落地
- 默认把字符容错放在检索侧：原查询留在框里和结果标题上，命中靠模糊或 n-gram 索引。
- 不要为了召回而静默替换输入；若同时做纠错，必须是另一条可见的改写，且可还原。
- 摘要里同时显示查询词与命中词的差异（高亮不对齐的字符），让人看到容忍发生在哪。
- 验证：输入一个确定的拼写变体。框内应仍是变体，目标对象应能出现。若框被改成词典形，或对象只在改写后出现，容错被做成了改查询，而不是索引层匹配。