在 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会被保留成两个 tokenin和brief都参与倒排索引匹配。因为in在几乎所有英文文档里都存在搜索结果会被大量无关文档拉宽——这不是 bug是默认 analyzer 本来的行为。换成en.microsoft后in会作为英文 stopword 被移除in brief的有效 token 只剩brief。结果通常会更聚焦但前提是这些 stopword 在业务语义里确实不重要。所以正确的问题不是Azure AI Search 是否支持 stopword而是当前字段用的是什么 analyzer它会不会移除 stopword3. 实验对比(使用Analyze Text API查看结果)调用Analyze Text API接口POST https://your AI Search name.search.azure.cn/indexes/index name/analyze?api-version2026-04-01Body:# 第一轮 { 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 不一样。结果对比图