【Azure AI Search】 stopword 是什么,为什么它会影响搜索结果?

在线体验各类最新模型,更有模型 免费Token 额度领取!
立即体验
简介: 本文解析 Azure AI Search 中搜索 "in brief" 返回结果过多的问题,指出根源在于 analyzer 对停用词(如 "in")的处理差异:默认 `standard.lucene` 保留停用词导致泛匹配,而 `en.microsoft` 会过滤停用词,使结果更精准。关键在于根据业务语义选择合适 analyzer。

问题描述

在 Azure AI Search 中搜索 in brief 时,结果数量有时会比预期多很多。仔细查看返回结果文本,会发现有些文档和 brief 的关系很弱,反而只是命中了 in 这类高频词。

这不是数据问题,也不是 Azure AI Search 的 bug。关键在于一个很容易被忽略的地方:in 这类词在索引和查询时,到底有没有被当作普通 token 处理。

 

问题解答

1. stopword 是什么

stopword(停用词)是在自然语言中高频出现、但对区分文档贡献较低的词。

英文里常见的 stopword 包括:

a  an  the  in  of  and  to  is  for  with  on  at

这类词不是“永远没有意义”,而是在大多数全文检索场景里区分度较低。

几乎每篇文档都可能含有 intheof,用它们做关键词既不能帮助筛选相关内容,也容易把大量无关文档带进结果。

因此在传统全文检索里,stopword 通常会在索引阶段和查询阶段一起被移除,让搜索结果更聚焦于真正有区分度的词。

 

2. stopword 是否被移除,由 analyzer 决定

Azure AI Search 里,stopword 不是全局开关,而是 analyzer 行为的一部分。

字段建索引时,文本会先被 analyzer 拆成 token,查询时,搜索词也会经过 analyzer。只有两边生成的 token 能对上,才可能命中。

  • 对默认 standard.lucene 来说,英文 stopword 不会像语言 analyzer 那样被自动移除。in brief 会被保留成两个 token:inbrief,都参与倒排索引匹配。因为 in 在几乎所有英文文档里都存在,搜索结果会被大量无关文档拉宽——这不是 bug,是默认 analyzer 本来的行为。
  • 换成 en.microsoft 后,in 会作为英文 stopword 被移除,in brief 的有效 token 只剩 brief。结果通常会更聚焦,但前提是这些 stopword 在业务语义里确实不重要。

所以正确的问题不是"Azure AI Search 是否支持 stopword",而是:当前字段用的是什么 analyzer,它会不会移除 stopword?

 

3. 实验对比(使用Analyze Text API查看结果)

调用Analyze Text API接口:

POST https://<your AI Search name>.search.azure.cn/indexes/<index name>/analyze?api-version=2026-04-01

Body:

# 第一轮

{

 "text": "in brief",

 "analyzer": "standard.lucene"

}


# 结果 -- in 没有被过滤

{

 "@odata.context": "https://xxxxxxx.search.azure.cn/$metadata#Microsoft.Azure.Search.V2026_04_01.AnalyzeResult",

 "tokens": [

   {

     "token": "in",

     "startOffset": 0,

     "endOffset": 2,

     "position": 0

   },

   {

     "token": "brief",

     "startOffset": 3,

     "endOffset": 8,

     "position": 1

   }

 ]

}


# 第二轮

{

 "text": "in brief",

 "analyzer": "en.microsoft"

}


#结果 -- in 被当作英文 stopword 移除

{

 "@odata.context": "https://xxxxxxx.search.azure.cn/$metadata#Microsoft.Azure.Search.V2026_04_01.AnalyzeResult",

 "tokens": [

   {

     "token": "brief",

     "startOffset": 3,

     "endOffset": 8,

     "position": 1

   }

 ]

}

这个对比能直接说明两种 analyzer 下搜索结果数量不同的原因:最终参与匹配的 token 不一样。

结果对比图:

参考资料

停用词:https://learn.microsoft.com/zh-cn/azure/search/reference-stopwords#english-enmicrosoft

Index Analyze : https://learn.microsoft.com/zh-cn/rest/api/searchservice/indexes/analyze?view=rest-searchservice-2026-04-01&tabs=HTTP#searchserviceindexanalyze

 



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

相关文章
|
29天前
|
人工智能 自然语言处理 API
【Azure AI Search】Index的字段使用默认Analyzer(standard.lucene) 和 en.microsoft 有什么不同?
Azure AI Search英文检索因词形差异(如brief/briefs)无法匹配,根源在于analyzer选择:默认standard.lucene不处理词形还原,而en.microsoft支持lemmatization,可将变体还原为基本形式。需通过新增字段并配置en.microsoft analyzer解决,兼顾检索质量与业务需求。
262 124
|
27天前
|
人工智能 运维 安全
阿里云 Agent Infra 上长出的约束基建
Harness = 定义约束 + 校验输出 + 建立反馈回路。
327 127
|
22天前
|
数据采集 人工智能 搜索推荐
企业智能体的下半场,如何让智能体越用越聪明?
AgentLoop 正在邀测期,点击申请邀测资格。
347 129
|
14天前
|
消息中间件 存储 Kafka
Kafka 原生消息入湖能力上线!一键打通实时流与数据湖
阿里云消息队列 Kafka 版正式上线原生消息入湖能力。
330 125
|
21天前
|
人工智能 监控 前端开发
Electron 监控:让桌面 Agent 监控触手可及
一行代码实现Electron桌面端全景监控,自动还原崩溃现场、预警内存泄漏、全链路追踪、 SSE流式响应与交互埋点,让 AI 助手运行状态清晰可见,助力快速恢复稳定与流畅。
347 126
|
21天前
|
消息中间件 人工智能 Kafka
AI 时代,实时入湖正在告别 ETL:从 Kafka 到 Iceberg 的架构减法
本文围绕“零 ETL”这一趋势,讨论流数据入湖为什么需要做架构减法,并结合 Kafka × Table Bucket 的实践,分析一种将通用入湖能力前移到消息与表存储链路中的方案,如何在降低复杂度的同时,兼顾实时性、一致性、Schema 演进、CDC 语义与开放生态兼容。
316 130
|
14天前
|
人工智能 运维 自然语言处理
「Agent 友好」的可观测:阿里云发布观测与智能运维 Skills
开发者只需在 Qoder 等 Agent 客户端中发出一句自然语言指令。借助云监控与STAROps Skill,Agent 即可自主完成数据接入、告警配置、根因诊断,并联动研发工具链完成代码修复与发布。
414 126
|
14天前
|
人工智能 安全 Cloud Native
Higress 新发布:AI Gateway 能力增强,Gateway API 及其推理扩展持续打磨
增强 AI 网关能力,持续打磨 Gateway API 及其推理扩展。
472 128
|
29天前
|
消息中间件 人工智能 数据挖掘
企业AI调用资产化:从"谁用谁知道"到"组织可复用"的技术路径
企业AI调用产生的Prompt、工作流、上下文配置正在成为新的知识资产,但散落在个人账号中无法沉淀。本文从工程角度拆解一条完整的"收口→采集→提纯→入库→蒸馏"链路,探讨技术实现中的关键设计决策。
282 123
|
1月前
|
Web App开发 iOS开发
苹果自带浏览器展示不了钉钉二维码
使用window.DTFrameLogin函数,在safari不展示二维码
254 122