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

简介: Azure AI Search英文检索因词形差异(如brief/briefs)无法匹配,根源在于analyzer选择:默认standard.lucene不处理词形还原,而en.microsoft支持lemmatization,可将变体还原为基本形式。需通过新增字段并配置en.microsoft analyzer解决,兼顾检索质量与业务需求。

问题描述

在 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。

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)

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

1:添加新的查询字段

步骤如下:

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

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

步骤如下:

  • 进入对应的索引器,点击 Edit JSON案例
  • 在fieldMappings中,添加content / content_ext 的mapping关系后保存

添加内容:


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

参考截图如下:

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

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

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

 

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

 

参考资料

用于 Azure AI 搜索的文本处理分析器:https://learn.microsoft.com/zh-cn/azure/search/search-analyzers

向 Azure AI 搜索索引中的字符串字段添加语言分析器: https://learn.microsoft.com/zh-cn/azure/search/index-add-language-analyzers

更新或重新生成索引 :https://learn.microsoft.com/zh-cn/azure/search/search-howto-reindex?tabs=sdk-python%2Cportal

Indexes - Analyze - REST API (Azure Search Service) : https://learn.microsoft.com/zh-cn/rest/api/searchservice/indexes/analyze?view=rest-searchservice-2026-04-01&tabs=HTTP




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

相关文章
|
3月前
|
人工智能 自然语言处理 API
【Azure AI Search】 stopword 是什么,为什么它会影响搜索结果?
本文解析 Azure AI Search 中搜索 "in brief" 返回结果过多的问题,指出根源在于 analyzer 对停用词(如 "in")的处理差异:默认 `standard.lucene` 保留停用词导致泛匹配,而 `en.microsoft` 会过滤停用词,使结果更精准。关键在于根据业务语义选择合适 analyzer。
264 121
|
2月前
|
弹性计算 监控 测试技术
一张图看懂:阿里云ECS按量付费全解析,云服务器新手使用手册
阿里云ECS按量付费为后付费模式,按秒/流量计费,支持随时释放,适用于临时测试、突发业务等场景。涵盖实例、云盘、镜像、带宽、快照等计费项,灵活可控,成本透明。阿里云服务器ECS官网:https://t.aliyun.com/U/AZBUsA
341 119
|
2月前
|
弹性计算 缓存 负载均衡
可用架构实践:阿里云支撑跑腿平台稳定运行,分账链解决交易结算核心痛点
同城跑腿、即时代办、即时配送属于典型的高并发、短时效、强交易、高波动业务场景:节假日、午晚高峰、暴雨暴雪天气会瞬间触发流量峰值,订单秒级涌入;同时每一笔订单都涉及用户、平台、入驻商户、跑腿个人师傅四方交易分润,业务链路复杂。 对于开发者而言,跑腿平台上线运营核心要解决两大问题:业务层高可用稳定承载 + 交易层合规自动化分账。 绝大多数成熟跑腿平台,均基于阿里云云原生架构实现业务稳定、弹性扩容、故障自愈,保障全时段服务可用;而针对行业专属的多方分账、高分润、逆向退款、合规清算难题,行业通用最优解是垂直场景专用系统——分账链。 本文从阿里云架构落地、业务痛点拆解、交易分账解决方案三个维度,完整复盘
441 122
|
3月前
|
SQL 存储 运维
日志能不能改?SLS LogStore 原生支持更新和删除了
随着日志承载的业务语义越来越多,数据订正、回填、清理等需求变得越来越常见。SLS 现已为 LogStore 提供原生 update/delete 能力——支持按 RowID 精确修改,按查询条件批量操作,类似计费调账、标签刷新、反馈回填等场景都可以直接在 LogStore 内完成闭环。
463 144
|
3月前
|
Web App开发 iOS开发
苹果自带浏览器展示不了钉钉二维码
使用window.DTFrameLogin函数,在safari不展示二维码
323 122
|
3月前
|
消息中间件 存储 Kafka
Kafka 原生消息入湖能力上线!一键打通实时流与数据湖
阿里云消息队列 Kafka 版正式上线原生消息入湖能力。
575 139
|
3月前
|
消息中间件 人工智能 数据挖掘
企业AI调用资产化:从"谁用谁知道"到"组织可复用"的技术路径
企业AI调用产生的Prompt、工作流、上下文配置正在成为新的知识资产,但散落在个人账号中无法沉淀。本文从工程角度拆解一条完整的"收口→采集→提纯→入库→蒸馏"链路,探讨技术实现中的关键设计决策。
445 123
|
3月前
|
数据采集 人工智能 安全
别再提“白帽GEO”了——为什么“合规GEO”才是对抗AI投毒的真正底线
本文批判滥用“白帽/黑帽”等过时SEO术语描述生成式引擎优化(GEO)乱象,指出AI投毒、虚假榜单等已逾越技术作弊范畴,触及法律与伦理红线。倡导以“合规GEO”取代理论失焦的旧话术,强调技术、平台、法律三层硬性底线——用对词,方能认清危险;守合规,才是真优化。(239字)
425 120
|
安全
SD卡与TF卡的区别
SD卡与TF卡的区别
1188 117
|
缓存 运维 Kubernetes
与阿里云容器服务 ACK 发行版的深度对话第一弹:如何借助 sealer 实现快速构建 & 部署
本文将以ACK 发行版的口吻为大家详细讲解阿里巴巴的开源集群镜像技术 sealer,以及如何借助它来实现阿里云 ACK 服务的快速稳定交付。
1196 117
与阿里云容器服务 ACK 发行版的深度对话第一弹:如何借助 sealer 实现快速构建 & 部署