问题描述

在 Azure AI Search 里搜 in brief 这个词组，结果数量往往比预期的要多出一大截。仔细翻一下返回的文本就会发现，某些文档跟 brief 的关系实在有点牵强，反而是因为命中了 in 这种高频词才被捞出来。

这既不是什么数据异常，也不是 Azure AI Search 藏了什么 bug。真正的根源藏在一个特别容易被忽略的地方：in 这类词，在索引和查询阶段，到底有没有被当作普通的 token 来对待。

问题解答

1. stopword 是什么

stopword（停用词）指的是自然语言里出现频率极高、但对文档区分贡献很小的那一类词。英文里常见的停用词包括：

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

当然，不是说这些词“永远都没用”，但在大多数全文检索场景下，它们的区分度确实太低了。几乎每篇文档里都藏着 in、the、of，拿它们当关键词，既不好筛选相关内容，还容易把一堆无关文档拉进来。所以，传统的全文检索一般会在索引阶段和查询阶段一起把这些词移除，让结果更聚焦于那些真正有区分力的词汇。

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

Azure AI Search 里的停用词不是全局开关，而是 analyzer 行为的一部分。字段建索引时，文本会先经过 analyzer 拆成 token；查询时，搜索词也会走同样的流程。只有两边生成的 token 能对上，才能命中。

• 默认的 standard.lucene 不会像语言 analyzer 那样自动移除英文停用词。in brief 进去之后，会被保留成两个 token：in 和 brief，全都参与倒排索引匹配。因为 in 在几乎所有英文文档里都存在，结果范围被大量无关文档拉宽了——这不是 bug，就是默认 analyzer 本来的行为。
• 换成 en.microsoft 后，in 会被当作英文停用词移除，in brief 最终只剩下 brief。结果自然更聚焦，前提是这些停用词在业务语义里确实不重要。

所以，真正的问题不是“Azure AI Search 是否支持 stopword”，而是：

3. 实验对比（使用 Analyze Text API 查看结果）

调用 Analyze Text API 接口，来看一组实验：

POST https://.search.azure.cn/indexes//analyze?api-version=2026-04-01

# 第一轮

{

"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