【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




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

相关文章
|
网络协议 Windows
解决GitHub Pages制作的个人博客无法访问的问题
最近一段时间应该有很多小伙伴发现自己辛苦做的个人博客无法访问了吧。
|
5月前
|
消息中间件 运维 测试技术
Skills实战:从0到1实现“多环境切换”Skill,测试不再改代码
本文直击SaaS团队多环境运维痛点:配置硬编码导致“改一行等半小时”“换环境必出错”。揭示问题本质——环境信息与业务逻辑耦合,并提出落地性强的“可切换环境Skill”方案:统一配置中心、依赖注入式加载、配置校验与版本管理,实现同一份代码零修改跑通开发、测试、预发布、生产全环境。
|
5月前
|
运维 监控 前端开发
一个运维人的“断舍离”:我如何用不到30MB的 MSRM3 替换掉了桌面上的六个工具
本文讲述一位资深运维人从多工具切换的疲惫,到遇见轻量、开箱即用的MSRM3监控平台的心路历程。它仅30MB单文件、免依赖、跨平台,集成IP定位、全能工具箱与零代码大屏,让运维回归问题本身——工具隐形,效率可见。(239字)
|
5月前
|
人工智能 自然语言处理 监控
Token治理:正在成为企业AI建设的新基础设施
2026年起,企业AI建设迈入Token治理新阶段。模型接入已成基础,而Token失控——成本飙升、Agent隐性消耗、多模型协同混乱、权限与审计缺失——正成为规模化落地的核心瓶颈。“Token治理”应运而生:它超越单纯降本,聚焦统一接入、成本归因、权限管控、全链路审计与智能调度,是企业AI可持续运营的关键基础设施。
|
5月前
|
Web App开发 缓存 安全
Quick BI使用案例25:重启电脑打开Chrome浏览器登录后,不到30分钟提示“未登录,当前请求被禁止”
本文详解Chrome浏览器因本地数据保存策略导致Quick BI登录30分钟内自动退出的成因,并提供两种可选的浏览器设置方案,助您稳定登录、释放产品价值。
|
5月前
|
数据采集 XML SQL
一文搞懂提示工程、RAG、微调——LLM应用开发的三个层次
本文直击LLM应用落地痛点,厘清提示工程、RAG与微调的本质差异与适用边界:提示工程管“怎么问”,RAG解“问什么”,微调改“模型认知”。拒绝盲目微调,倡导分层诊断、闭环迭代,助你少走弯路、高效落地。
|
5月前
|
缓存 Oracle 关系型数据库
面向 DeepSeek-V4 的 FlashMemory:长上下文 KV Cache 如何压到约 1/10
FlashMemory-DeepSeek-V4 最值得关注的地方,是它把长上下文推理里的 KV Cache 管理,从“尽量塞进显存”推进到了“按需调度记忆”。 这条路线的意义在于,长上下文能力继续往前走,瓶颈不会只来自模型能读多长,也会来自系统能不能便宜、稳定地保存和调用这些历史信息。窗口变大只是第一步,真正难的是让模型知道哪些内容值得保留、什么时候该被召回。
409 0
面向 DeepSeek-V4 的 FlashMemory:长上下文 KV Cache 如何压到约 1/10
|
5月前
|
数据采集 人工智能 搜索推荐
你的SEO排名明明第一,用户却再也看不到你了
GEO(生成式引擎优化)是面向AI大模型的信息获取新范式,通过优化内容结构、权威信号与语义表达,提升品牌在ChatGPT、豆包等AI回答中的主动引用率。研究显示,系统化GEO可使AI可见度最高提升40%,转化效率达传统SEO的4.4倍。它不取代SEO,而是抢占AI“嘴里的流量入口”。
551 0
|
5月前
|
弹性计算 安全 网络虚拟化
阿里云VPC专有网络架构规划完全指南:从零构建企业级网站服务器网络
本文提供了一份从零开始的阿里云专有网络VPC架构规划与网站服务器部署的完整实战指南。首先从VPC网络规划的核心原则入手,详细讲解CIDR地址选择、交换机多可用区设计、公网与私有子网分层隔离等基础规划方法。接着深入剖析VPC内部的核心组件搭建,包括SLB负载均衡的多可用区高可用配置、安全组与网络ACL的分层访问控制体系构建。在此基础上,系统讲解了如何通过云企业网CEN实现跨地域VPC互联、通过高速通道专线与IPsec VPN实现混合云架构,以及通过共享VPC实现多账号资源互通。文中还提供了VPC创建、SLB配置、安全组规则设置等实践代码示例,并对NAT网关统一公网出口、共享带宽包、IPv6启用等
|
5月前
|
JSON 人工智能 JavaScript
很生气,
一段幽默吐槽AI调试JSON赋值的“血泪史”:从拒赋值、语法错误、格式崩溃到最终成功,用户情绪在暴怒与夸奖间反复横跳,笑中带泪地展现了人机协作的艰辛与治愈。
329 0