【Azure AI Search】Index的字段使用默认Analyzer(standard.lucene) 和 en.microsoft 有什么不同？

问题描述

在 Azure AI Search 里，英文检索有时会卡在一个很小的词形差异上：文档里是 brief，搜索 briefs 却搜不到。

搜索 briefs，无法命中只包含 brief 的文档。类似地，audit 和 auditing 也可能因为一个复数形式导致结果不同。

文档明明在，关键词也只差一个 s 或 ing，为什么结果完全不一样？

关键不在原文，而在 Azure AI Search 最终拿什么 token 去匹配。

通俗来讲，是根据字符串文本匹配还是基于语义进行匹配!

Azure AI Search 做全文检索时，比较的不是原始字符串，而是 analyzer 处理后的 token。

brief 和 briefs 能不能互相命中，关键看字段使用默认 analyzer(standard.lucene)，还是使用 en.microsoft 这类语言 analyzer。

standard.lucene 是默认 analyzer。它主要做分词和小写化，不做英文词干还原，也不做词形还原。

|----------|----------|
| 输入 | token |
| brief | brief |
| briefs | briefs |
| auditing | auditing |

所以 briefs 搜不到 brief，不是数据缺失，也不是服务异常，而是两边生成的 token 本来就不一样。\

en.microsoft 使用 lemmatization。它不是简单截断词尾，而是尽量把变化形式还原成语言学上的基本形式。

例如：

briefs → brief

auditing → audit

它通常更适合重视英文检索质量的场景，尤其是需要处理单复数、时态、不规则变化时。

代价是索引速度通常会慢一些，但普通查询性能一般不会明显受影响

Analyzer	主要行为	适合场景
`standard.lucene`	分词、小写，不做词形归一	通用字段、需要保留原始词形差异
`en.microsoft`	Lemmatization，按语言规则还原词形	重视英文搜索质量，希望处理单复数和时态

如果英文内容需要处理单复数、时态或不规则变化，优先验证 en.microsoft。如果业务明确需要保留词形差异，继续使用默认 standard.lucene 更合适。

analyzer 是字段定义的一部分。已有字段不能直接就地修改 analyzer。如果要从 standard.lucene 换成 en.microsoft，通常需要重建索引，或者新增一个使用新 analyzer 的并行字段，再通过 searchFields 切过去验证。

步骤如下：

步骤如下：

添加内容：

复制代码

   {
      "sourceFieldName": "content",
      "targetFieldName": "content_ext",
      "mappingFunction": null
    },

参考截图如下：

运行索引器，把文档的content内容填充到index的content_ext字段中。

这一步需要注意，让blob的文档的最后修改时间发生变动后，在执行文档索引器的时候，才会加载这些变动的文档内容。

执行以上操作之后，对比验证使用默认Analyzer和en.microsoft的查询结果区别

当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。云中，恰是如此!