> 9.3 把 `SCORE` 函数放进了正式构建。它作用于**单个全文函数**（比如 `match`），返回那个条件的分数。配合 `METADATA _score`，可以在一条查询里同时拿到整体分和子条件分——这在排查"为什么这条排这么靠前"时很有用。

## **说明**

本文描述问题及解决方法同样适用于 [腾讯云 Elasticsearch Service（ES）](https://cloud.tencent.com/document/product/845)。

## 官方条目

9.3 的 changelog 标为 feature（[9.3.0.yml 第 471–474 行 @ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/docs/release-notes/changelog-bundles/9.3.0.yml#L471-L474)）：

> summary: Enable score function in release builds
> area: ES|QL
> type: feature

**一行 summary，没 details**。但函数本身有文档，下面按文档核。

## 函数做什么

官方描述（[functions/description/score.md @ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/docs/reference/query-languages/esql/_snippets/functions/description/score.md)）：

> Scores an expression. Only full text functions will be scored. Returns scores for all the resulting docs.

三句拆开：

* **给一个表达式打分**——不是给整个查询打分；
* **只有全文函数会被打分**——`match`、`qstr` 这类；其它表达式没有分数概念；
* **返回所有结果文档的分数**。

官方示例（[functions/examples/score.md @ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/docs/reference/query-languages/esql/_snippets/functions/examples/score.md)）：

```esql
FROM books METADATA _score
| WHERE match(title, "Return") AND match(author, "Tolkien")
| EVAL first_score = score(match(title, "Return"))
```

这个例子信息量不小：

* `FROM books METADATA _score`——**要显式声明 `_score` 元数据**才能拿到整体分；
* `WHERE` 里有两个 `match` 条件；
* `EVAL first_score = score(match(title, "Return"))`——**只给其中一个条件打分**。

## `SCORE()` 和 `_score` 是两回事

这是我觉得最该说清楚的一点，两者容易混：

| | `_score` | `SCORE()` |
|---|---|---|
| 是什么 | 元数据列 | 函数 |
| 怎么拿到 | `FROM ... METADATA _score` | `EVAL x = SCORE(...)` |
| 表示什么 | **整个查询**的综合得分 | **某个全文函数**的得分 |

`_score` 是所有条件合起来的最终分；`SCORE()` 是拆开看——**某一个条件贡献了多少分**。

用上面那个例子说：

* `_score` = `match(title)` + `match(author)` 综合后的分；
* `first_score` = 只有 `match(title)` 这一项的分。

**这个区别决定了它们的用途不同**：`_score` 用来排序，`SCORE()` 用来分析。

## 它解决什么问题

我觉得最大的用途是**排查相关性**。

检索结果排序不符合预期时，常见的问题是："为什么这条排这么靠前／靠后？"要回答这个，就得知道**每个条件各贡献了多少分**。

以前在 ES|QL 里做不到——你只能看到最终的 `_score`，看不出它是怎么来的。`SCORE()` 让你能把组合条件拆开逐个看。

具体做法是把每个条件的分数都算出来：

```esql
FROM books METADATA _score
| WHERE match(title, "Return") AND match(author, "Tolkien")
| EVAL title_score = score(match(title, "Return"))
| EVAL author_score = score(match(author, "Tolkien"))
| KEEP title, author, _score, title_score, author_score
| SORT _score DESC
| LIMIT 10
```

这样能直接看出：**某条文档排第一，是因为标题匹配得分高，还是作者匹配得分高**。有了这个拆解，"为什么这条排在前面"就不再是猜测——能看到每个条件的具体贡献，调权重时也有依据。

我判断这个能力在**调优查询**时价值最大——比如你怀疑某个条件权重过大或者过小，用它能量化确认，而不是靠猜。

（说明：上面这段查询是按官方示例的写法扩展的，**我没有实测**。`SCORE()` 是否支持在 `EVAL` 里多次调用、多个 `SCORE()` 能否共存，建议先跑一次确认。）

## "只给全文函数打分"这个限制

描述里那句 `Only full text functions will be scored` 是硬限制，值得展开。

**能打分的**：`match`、`qstr` 这类**全文检索函数**。它们背后是 Lucene 的评分机制（TF-IDF / BM25 之类），本来就有分数概念。

**不能打分的**：其它表达式。比如：

* `WHERE status == "active"`——精确匹配，没有"相关度"这个概念；
* `WHERE price > 100`——范围过滤，同样没有分数；
* 非全文的字符串函数。

这个限制是合理的——**评分是全文检索特有的概念**。精确匹配要么匹配要么不匹配，谈不上"多相关"。

**但它带来一个使用上的注意点**：如果你的查询里既有 `match` 又有过滤条件，那 `SCORE()` 只能用在 `match` 那部分。想给过滤条件"打分"是没有意义的——它们不参与相关性计算，自然也没有分可拿。

从另一个角度说这也解释了为什么 `_score` 只受全文条件影响：**过滤条件只决定"在不在结果里"，不影响"排多前"**。理解这一点对看懂 `SCORE()` 的输出有帮助。

我在写这段时想到一个容易犯的错：**有人可能想用 `SCORE()` 给整个 `WHERE` 打分**，比如 `SCORE(match(...) AND status == "x")`。按描述里的限制，这应该不行——**它接受的是一个全文函数，不是任意表达式**。不过这点我没实测，不确定是报错还是只算 match 那部分。

## 一个我拿不准的用法边界

用 `SCORE()` 时我有个没确认的点：**它能否作用于没出现在 `WHERE` 里的全文函数**。

比如这样：

```esql
FROM books METADATA _score
| WHERE match(title, "Return")
| EVAL other = score(match(author, "Tolkien"))
```

这里 `match(author, "Tolkien")` 只出现在 `EVAL` 里，不参与过滤。

两种可能：

* **能算**——`SCORE()` 独立计算这个条件的分数，相当于"另外看看另一条如果不作为过滤条件会得多少分"；
* **不能**——要求被打分的函数必须已经在查询里参与了过滤。

我倾向于前者（函数描述没说要求参与过滤），但**没有实测**。这个用法如果能成立，价值不小——可以在不改变结果集的前提下评估"另一个条件的相关性如何"。

需要用的话先跑一次确认。这也是我写这类新函数时的习惯：**文档没写清的边界，用一次实测代替猜测**。

## 分数能比较吗

另一个值得想的问题：**不同 `SCORE()` 结果之间能直接比较吗？**

比如 `title_score` 是 2.3，`author_score` 是 1.8，能说"标题条件贡献更大"吗？

我判断**要谨慎**。原因是：

* 两个 `match` 作用在不同字段上，**字段本身的特性**（长度、词频分布）会影响分数绝对值；
* Lucene 的评分和字段的统计信息相关，不同字段的分数量级未必可比。

所以我的建议是：**在同一个查询里横向比较同一条件在不同文档上的分数**（这个是安全的），而**跨字段比较不同条件的分数要小心**。

后者更适合的做法是看**相对关系**——比如"这条文档的标题分明显高于其它文档"，而不是"标题分比作者分高"。

（说明：这段是我按 Lucene 评分机制的一般理解写的，**没有在文档里找到明确说明**。如果你要做精细的相关性调优，建议参考官方的相关性文档，别只靠我这段推断。）

## 和 Query DSL 的对应关系

如果你熟悉 Query DSL，`SCORE()` 的作用相当于 **`explain` 里每个子查询的分数**，或者 **`function_score` 里拆开看各部分的贡献**。

Query DSL 有 `_explain` API 能看到详细的评分拆解，那是排查相关性的标准工具。`SCORE()` 相当于在 ES|QL 里提供了一个轻量版的拆解能力——**不如 `_explain` 详细，但不用换查询语言，写在原查询里就行**。

我的判断是：**快速排查用 `SCORE()`，深入分析还是得 `_explain`**。前者胜在方便（同一条查询加一行就能看到拆解），后者胜在信息全（能给出更详细的评分依据）。两者不冲突，按需要的深度选。

## 一个实际的注意点：性能

`SCORE()` 需要对每个结果文档计算分数。相比只拿 `_score`，它多了计算量。

具体多多少，文档没说，我也没实测。但按机制推断：

* 如果 `WHERE` 里已经有同样的 `match`，那这个条件的分数**可能已经算过了**，`SCORE()` 只是把它取出来——开销小；
* 如果 `SCORE()` 里的是一个**新的**全文函数（没出现在 `WHERE` 里），那要额外计算——开销取决于数据量。

我在写这段时倾向于第一种情况居多（通常你是给已有的条件打分），但**这点我没有确认**。如果你关心性能，建议对比一下加 `SCORE()` 前后的查询耗时——拿自己的数据测一次，比看任何推断都准。

这个对比做法也适用于其它新函数：**加之前记一次耗时，加之后再记一次**，差值就是它的开销。数据量要够大才有意义，几十条数据看不出差别。

## 什么情况下不用它

说完用途，也说说我觉得**没必要用**的情况，免得过度使用。

**一，只用单一 `match` 的简单查询。** 只有一个条件时，`_score` 就是这个条件的分数，`SCORE()` 给不出额外信息。

**二，结果是按其它字段排序的。** 如果你 `SORT` 的是时间或者某个业务字段，压根不关心相关度，那分数没有意义。

**三，生产固定查询里长期保留。** `SCORE()` 是分析工具，不是查询逻辑的一部分。我倾向于**排查时临时加上，搞清楚之后去掉**——留在生产查询里会增加计算量，而那个分数通常没人看。

第三条是我想强调的：**分析性的东西不要变成常态**。查询里每多一个 `EVAL`，都要在每次执行时算一遍。排查完就把它们拿掉，保持生产查询干净。

## 写在最后

这个函数不大，用法也简单，但对**排查相关性问题**是个实用的补充。

**一，`SCORE()` 和 `_score` 不是一回事。** 前者是某个全文函数的分，后者是整个查询的综合分。要用 `_score` 得显式写 `METADATA _score`，不写就拿不到这一列。

**二，它只能给全文函数打分。** `match`、`qstr` 这类可以，精确匹配和范围过滤不行——后者没有"相关度"这个概念。

**三，主要用途是分析而非排序。** 排序用 `_score`；想知道"分是怎么来的"才用 `SCORE()` 把条件拆开看。查完记得把它从生产查询里去掉——分析性的 `EVAL` 不该长期留在那。

最后补一句：`SCORE()` 是在 `EVAL` 里用的，而它作用在**全文函数**上。用之前先确认你的查询里那个条件确实是全文函数，否则拿不到有意义的分数——这一步确认花不了几秒，但能避免"拿到了 null 还不知道为什么"的困惑。

## 参考

- [changelog 9.3.0：Enable score function in release builds（第 471–474 行）@ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/docs/release-notes/changelog-bundles/9.3.0.yml#L471-L474)
- [`functions/description/score.md`：函数说明（Only full text functions will be scored）@ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/docs/reference/query-languages/esql/_snippets/functions/description/score.md)
- [`functions/examples/score.md`：官方示例，含 `METADATA _score` 用法 @ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/docs/reference/query-languages/esql/_snippets/functions/examples/score.md)

> 本文对照 Elasticsearch `v9.4.2` 标签的 changelog 与函数文档核对，引文逐字取自原文。文中多条件拆解的查询示例按官方示例写法扩展，未实测；`SCORE()` 作用于非全文表达式或复合表达式时的行为、以及性能开销，本文均未确认，已在正文标注。撰写时未启动集群、未运行测试。


9.3 把 SCORE 函数放进了正式构建。它作用于单个全文函数（比如 match），返回那个条件的分数。配合 METADATA _score，可以在一条查询里同时拿到整体分和子条件分——这在排查"为什么这条排这么靠前"时很有用。

ES|QL 有了 `SCORE()`，能给单个条件单独打分了

9.3 把 SCORE 函数放进了正式构建。

官方产研

云计算

后端

大数据

SCORE()函数在ES|QL 9.3中正式发布，用于分解全文查询中各条件的得分贡献。与_score整体分不同，SCORE()可单独评估match等全文函数的分数，便于排查相关性排序问题。仅支持全文函数，配合METADATA_score使用，适合查询调优和权重分析。

代码解释

2026上云采购 | AI焕新·智启新局

bigdata-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

ES|QL 有了 `SCORE()`，能给单个条件单独打分了-腾讯云开发者社区-腾讯云

ES|QL 有了 `SCORE()`，能给单个条件单独打分了

ES|QL 有了 `SCORE()`，能给单个条件单独打分了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐