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

问题描述

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

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

image

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

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

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

 

问题解答

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

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

1: standard.lucene 不处理英文词形

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

输入  token
brief  brief
briefs  briefs
auditing  auditing

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

 

2: en.microsoft 按语言规则做词形还原

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

例如:

briefs → brief
auditing → audit

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

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

 

3: 如何选择

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

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

 

4:修改 analyzer 

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

如下图所示(无法修改Analyzer)

image

添加新的索引字段并设置Analyzer步骤

1:添加新的查询字段

步骤如下:
  • 选中索引,进入Fields Tab页,点击添加字段。
  • 输入新的字段名, 如: content_ext
  • 勾选 Retrievable 和 Searchable 
  • 选择Analyzer为 English - Microsoft (* 重要)
  • 保存修改

image

2:把查询字段和文档的内容进行关联

步骤如下:
  • 进入对应的索引器,点击 Edit JSON案例
  • 在fieldMappings中,添加content / content_ext 的mapping关系后保存
添加内容:
   {
      "sourceFieldName": "content",
      "targetFieldName": "content_ext",
      "mappingFunction": null
    },
 
参考截图如下:

image

3:修改查询文档属性后,执行索引器,为新字段填充内容

运行索引器,把文档的content内容填充到index的content_ext字段中。
这一步需要注意,让blob的文档的最后修改时间发生变动后,在执行文档索引器的时候,才会加载这些变动的文档内容。
 
执行以上操作之后,对比验证使用默认Analyzer和en.microsoft的查询结果区别

image

 

参考资料

posted @ 2026-06-15 20:56  编码者卢布  阅读(18)  评论(0)    收藏  举报