你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 认知搜索中的相关性和评分

项目
04/19/2023

本文介绍用于计算 Azure 认知搜索中搜索分数的相关性和评分算法。为在全文搜索中找到的每个匹配项计算一个相关性分数，其中最强的匹配项将分配更高的搜索分数。

相关性仅适用于全文搜索。筛选器查询、自动完成和建议的查询、通配符搜索或模糊搜索查询不会进行相关性评分或排名。

在 Azure 认知搜索中，可以通过以下机制优化搜索相关性，提升搜索分数：

评分算法配置
语义排名（预览版，如此文所述）
为配置文件评分
通过 featuresMode 参数启用的自定义评分逻辑

注意

匹配项的评分和排名按从高到低的顺序。分数作为“@search.score”返回。默认情况下会在响应中返回前 50 个结果，但你可以使用 $top 参数返回更少或更多的项（单个响应中最多可以包含 1000 个项），并可以使用 $skip 获取下一个结果集。

搜索中的评分算法

Azure 认知搜索提供以下评分算法：

算法	使用情况	范围
BM25Similarity	修复了 2020 年 7 月之后创建的所有搜索服务上的算法。可以配置此算法，但不能切换到较旧的算法 (经典) 。	无限。
ClassicSimilarity	在较旧的搜索服务上显示。可以选择加入 BM25 ，并按索引选择算法。	0 < 1.00

BM25 和 Classic 都是类似于 TF-IDF 的检索函数，它们使用字词频率 (TF) 和逆向文档频率 (IDF) 作为变量来计算每个文档-查询对的相关性评分，然后使用这些评分来获得排名结果。虽然在概念上与 Classic 类似，但 BM25 立足于概率信息检索来生成更直观的匹配项（通过用户研究进行度量）。

BM25 提供高级自定义选项，例如，允许用户确定如何根据匹配字词的字词频率调整相关性评分。有关详细信息，请参阅配置评分算法。

注意

如果你使用的是在 2020 年 7 月之前创建的搜索服务，则评分算法很可能是以前的默认设置 ClassicSimilarity，该算法可以根据索引进行升级。有关详细信息，请参阅在较旧的服务上启用 BM25 评分。

以下视频段快进到了 Azure 认知搜索中使用的正式版排名算法的说明。你可以观看完整视频以了解更多背景知识。

分数变体

搜索评分表达了对相关性的总体认知，反映了相对于同一结果集中的其他文档的匹配强度。但是，评分在不同的查询之间并非始终一致，因此，在处理查询时，你可能会注意到搜索文档的排序方式存在细微差别。下面对发生这种情况的可能原因给出了几条解释。

原因	说明
数据易变性	添加、修改或删除文档时，索引内容会发生变化。在处理索引更新的过程中，字词频率会发生变化，从而影响了匹配文档的搜索评分。
多个副本	对于使用多个副本的服务，将并行针对每个副本发出查询。用于计算搜索评分的索引统计信息是根据每个副本计算的，结果将在查询响应中合并和排序。副本基本上是彼此的镜像，但由于状态存在细微差别，因此统计信息可能有所不同。例如，一个副本可能删除了对统计信息有影响的文档，这些统计信息由其他副本合并而来。通常，按副本的统计信息的差异在较小索引中更明显。有关此条件的详细信息，请参阅容量计划文档中的概念：搜索单位、副本、分区、分片。
相同的评分	如果多个文档具有相同的评分，其中的任何一个文档都可能会首先出现。

评分统计信息和粘滞会话

为了实现可伸缩性，Azure 认知搜索会通过分片过程横向分布每个索引，这意味着，索引的某些部分在物理上是独立的。

默认情况下，文档的评分是根据分片中数据的统计属性计算的。此方法对于大型数据集而言通常不会造成问题，与基于所有分片中的信息计算评分相比，此方法可提供更好的性能。也就是说，使用这种性能优化可能会导致两个非常相似的文档（甚至相同的文档）最终可能出现不同的相关性评分（如果这些文档出现在不同的分片中）。

如果你偏向于基于所有分片中的统计属性计算评分，可以添加 scoringStatistics=global 作为查询参数（或者添加 "scoringStatistics": "global" 作为查询请求的正文参数）来执行此操作。

POST https://[service name].search.windows.net/indexes/hotels/docs/search?api-version=2020-06-30
{
    "search": "<query string>",
    "scoringStatistics": "global"
}

使用 scoringStatistics 可确保同一副本中的所有分片提供相同的结果。也就是说，不同的副本相互之间可能略有不同，因为它们始终会随着索引的最新更改而更新。在某些情况下，你可能希望用户在“查询会话”期间获得更一致的结果。在这种情况下，可以提供 sessionId 作为查询的一部分。 sessionId 是你创建的用于引用唯一用户会话的唯一字符串。

POST https://[service name].search.windows.net/indexes/hotels/docs/search?api-version=2020-06-30
{
    "search": "<query string>",
    "sessionId": "<string>"
}

只要使用相同的 sessionId，就会尽力而为地以同一副本为目标，从而提高用户看到的结果的一致性。

注意

反复使用相同的 sessionId 值可能会干扰跨副本对请求进行负载均衡，并对搜索服务的性能产生负面影响。用作 sessionId 的值不能以“_”字符开头。

为配置文件评分

可以通过定义“计分概要文件”来自定义不同字段的排名方式。计分概要文件提供了基于内容特征提高匹配搜索分数的标准。例如，你可能想要根据创收能力提升匹配项、提升新项或提升库存时间太长的项。

计分概要文件属于索引定义的一部分，由加权字段、函数和参数组成。有关定义计分概要文件的详细信息，请参阅计分概要文件。

featuresMode 参数（预览版）

搜索文档请求有一个新的 featuresMode 参数，该参数可以在字段级别提供有关相关性的其他详细信息。尽管 @searchScore 是针对整个文档计算的（该文档在此查询的上下文中的相关性如何），但你可以通过 featuresMode 获取有关各个字段的信息，以 @search.features 结构表示。该结构包含查询中使用的所有字段（查询中通过 searchFields 指定的特定字段，或索引中属性为“可搜索”的所有字段）。对于每个字段，可获得以下值：

在字段中找到的唯一标记数
相似性得分，即字段内容相对于查询项的相似程度的度量
字词频率，即在字段中找到查询项的次数

对于以“description”和“title”字段为目标的查询，包含 @search.features 的响应可能如下所示：

"value": [
 {
    "@search.score": 5.1958685,
    "@search.features": {
        "description": {
            "uniqueTokenMatches": 1.0,
            "similarityScore": 0.29541412,
            "termFrequency" : 2
        },
        "title": {
            "uniqueTokenMatches": 3.0,
            "similarityScore": 1.75451557,
            "termFrequency" : 6
        }

可以使用自定义评分解决方案中的这些数据点或使用相关信息来调试搜索相关性问题。