问题描述
在 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
这类词不是“永远没有意义”，而是在大多数全文检索场景里区分度较低。
几乎每篇文档都可能含有 in、the、of，用它们做关键词既不能帮助筛选相关内容，也容易把大量无关文档带进结果。
因此在传统全文检索里，stopword 通常会在索引阶段和查询阶段一起被移除，让搜索结果更聚焦于真正有区分度的词。
2. stopword 是否被移除，由 analyzer 决定
Azure AI Search 里，stopword 不是全局开关，而是 analyzer 行为的一部分。
字段建索引时，文本会先被 analyzer 拆成 token，查询时，搜索词也会经过 analyzer。只有两边生成的 token 能对上，才可能命中。
- 对默认
standard.lucene来说，英文 stopword 不会像语言 analyzer 那样被自动移除。in brief会被保留成两个 token：in和brief，都参与倒排索引匹配。因为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