## 背景
在搜索领域，BM25 一直是文本相关性打分的默认选择。它简单、稳定、可解释，用 ES 做搜索的团队基本都在用。但只要业务跑得久一点，几乎都会碰到同一个尴尬的问题：搜出来的十条结果一眼看过去都还算相关，可用户心里真正想要的那一条，偏偏卡在第二页第三条。

所以说，"最相关的" 和 "用户最想要的"，根本就不是一回事。

Learning to Rank（以下简称 LTR）解决的就是这"最后一公里"。它从 Elastic Stack 8.15 起作为正式特性发布，到 9.1 版本已经非常成熟。腾讯云 Elasticsearch 在 9.1.3 上完整支持了 LTR rescorer。本文以一个电影搜索场景为例，基于 **腾讯云 Elasticsearch 9.1.3**，把整条链路完整跑一遍：从特征定义、特征抽取、XGBoost 模型训练，到模型推送至集群作为 rescorer 使用。

> 环境前提：腾讯云 Elasticsearch 9.1.3 版本集群（白金版或 AI 增强版均包含 ML 能力），客户端使用对应的 `elasticsearch-py` 9.x 与 `eland` 9.x。

## 一、整体思路

LTR 的工作模式可以拆成两段。

第一段是粗筛，行内的叫法是"召回"——用 BM25 或者向量检索，从千万级文档里先捞几十到几百条候选出来。这一步要的是快、要的是别漏。

第二段是细排，行内的叫法是"精排"——拿一个训练好的模型，结合更多信号（BM25 分数、字段是不是命中、文档本身热不热门、新不新等等）给这几百条候选重新打一遍分。这一步要的是准。

训练这个模型，要喂两样东西进去：**判定列表（judgment list）** 和 **特征**。判定列表说白了就是人工打的标签——某条 query 下，某条文档算不算用户想要的那个；特征是 query 和文档之间一切能被量化的信号，BM25 分数、字段是不是命中、文档热度都算。两边拼到一起，就是喂给 XGBoost 的训练数据。

整条链路放在一张图里，是这样：
![Clipboard_Screenshot_1780392977.png](https://developer.qcloudimg.com/http-save/yehe-7348459/985526f3e09f572cebe8ac11cf436720.png)

左边是离线训练，跑一次得到一个模型；右边是线上每次搜索都要走的两步。我们这篇文章的主线，就是从左到右把它跑通一遍。

## 二、专业术语解释：特征定义、特征抽取、模型训练

这三个词，等下文章里会反复出现，这里用通俗的例子简单描述一下。

其实就是媒婆给你介绍女朋友那一套。

> 媒婆手上有十几份资料，得挑几个推给你。她不会瞎挑，他会看妹子的身高、长相、工作、和你的性格合不合、离家远不远。重点看哪几条，她也有自己的标准。

LTR 里管这个叫**特征定义**。判断一条文档配不配得上用户这次搜的 query，到底该看哪几样？BM25 打多少分算一样，标题命中没命中算一样，片子热不热门、新不新，都算。把要看的这些列出来、说清楚每条怎么算出来，定义就完事了。

> 光列出来没用，得真把数据整理出来。她翻小张的资料：165、长得清秀、老师、温和、家就在隔壁区；翻小李的：160、一般、互联网、外向、在外地。一份资料填一行，十几份就是十几行。

LTR 里这步叫**特征抽取**。每一条"query + 文档"组合，按前面定的那几样挨个算出数，凑成一行。一万条样本，一万行。模型后面要看的，就是这堆。

> 媒婆做了几年这行，手里攒了不少案例，哪些人推过去你处下来了，哪些人见一面你就没下文了。这些事在她脑子里来回过，过着过着就过出感觉了：身高其实没那么要紧，性格合不合最关键，工作过得去就行，离得近不近看人。下回再来新资料，她不用想，扫一眼就知道该不该推给你。

LTR 里这步叫 **XGBoost 模型训练**。把"历史样本 + 每行的特征值 + 这条到底算不算用户想要的"丢给 XGBoost，它自己会从里头学出一套打分逻辑。线上来了新候选，套这套逻辑打分，分高的排前面。

三件事是有先后的：先定看哪几样，再把每个候选的那几样填出来，最后从历史数据里学出一套打分逻辑。

## 三、准备工作

客户端版本要和服务端大版本对齐，9.1.3 集群对应 9.x 系列的 SDK：

```bash
pip install -U "elasticsearch>=9.0,<10" "eland>=9.0,<10" "eland[scikit-learn]" xgboost tqdm
```

连接腾讯云 ES 集群。实例创建好之后，控制台会给一个内网访问地址和初始账号 `elastic`，密码自己设置。

```python
from getpass import getpass
from elasticsearch import Elasticsearch

# 腾讯云 ES 控制台「实例详情 - 基本信息」中的访问地址
ES_ENDPOINT = "http://10.10.10.10:9200"
ES_USERNAME = "elastic"
ES_PASSWORD = getpass("Elasticsearch Password: ")

es_client = Elasticsearch(
    hosts=[ES_ENDPOINT],
    basic_auth=(ES_USERNAME, ES_PASSWORD),
    request_timeout=60,
)

# 连通性确认
print(es_client.info()["version"]["number"])  # 期望输出 9.1.3
```

如果集群开了 HTTPS，把地址换成 `https://...`，并按需配置 `verify_certs` 与 `ca_certs`。生产环境建议优先走内网 VPC 地址，公网链路抖动会直接拖慢后面的特征抽取。

## 四、数据集介绍

示例数据来自 [MSRD（Movie Search Ranking Dataset）](https://github.com/metarank/msrd/tree/master)，由 Elastic 整理后放在了 elasticsearch-labs 仓库下，包含三份文件：

- `movies-corpus.jsonl.gz`：电影正排数据，待索引；
- `movies-judgments.tsv.gz`：判定列表；
- `movies-index-settings.json`：索引 settings 与 mapping。

```python
from urllib.parse import urljoin

DATASET_BASE_URL = "https://raw.githubusercontent.com/elastic/elasticsearch-labs/main/notebooks/search/sample_data/learning-to-rank/"

CORPUS_URL = urljoin(DATASET_BASE_URL, "movies-corpus.jsonl.gz")
JUDGEMENTS_FILE_URL = urljoin(DATASET_BASE_URL, "movies-judgments.tsv.gz")
INDEX_SETTINGS_URL = urljoin(DATASET_BASE_URL, "movies-index-settings.json")
```

电影文档的字段长这样：

| 字段名       | 含义                       |
| ------------ | -------------------------- |
| `id`         | 文档 ID                    |
| `title`      | 电影名                     |
| `overview`   | 剧情简介                   |
| `actors`     | 演员列表                   |
| `director`   | 导演                       |
| `characters` | 角色列表                   |
| `genres`     | 类型                       |
| `year`       | 上映年份                   |
| `budget`     | 预算（美元）               |
| `votes`      | 投票数                     |
| `rating`     | 平均评分                   |
| `popularity` | 热度                       |
| `tags`       | 标签                       |

## 五、写入语料

先建索引，再用 bulk 把语料灌进去。

```python
import json
import elasticsearch.helpers as es_helpers
import pandas as pd
from urllib.request import urlopen

MOVIE_INDEX = "movies"

es_client.options(ignore_status=[400, 404]).indices.delete(index=MOVIE_INDEX)

index_settings = json.load(urlopen(INDEX_SETTINGS_URL))
es_client.indices.create(index=MOVIE_INDEX, **index_settings)

corpus_df = pd.read_json(CORPUS_URL, lines=True)

bulk_result = es_helpers.bulk(
    es_client,
    actions=[
        {"_id": movie["id"], "_index": MOVIE_INDEX, **movie}
        for movie in corpus_df.to_dict("records")
    ],
)
print(f"Indexed {bulk_result[0]} documents into {MOVIE_INDEX}")
```

## 六、判定列表

判定列表就是告诉模型对错的那份数据：对于某条 query，哪条文档是好结果、哪条不是。每行四列：

| 列名       | 含义                                                  |
| ---------- | ----------------------------------------------------- |
| `query_id` | 同一条 query 的样本归到一组，按 query 分组训练         |
| `query`    | 实际查询文本                                          |
| `doc_id`   | 文档 ID                                               |
| `grade`    | 这条文档对这条 query 来说，相关度有多高                |

这里的 `grade` 只分相关和不相关两档。在真实业务里，更常见的是 0~4 这种分级标注，给模型的信息量更多一些。

```python
judgments_df = pd.read_csv(JUDGEMENTS_FILE_URL, delimiter="\t")
judgments_df
```

## 七、定义特征

LTR 这套机制里，特征不是直接写成一个 numpy 数组喂给模型的，而是写成一段 ES 自己的查询语句——训练时算特征用这段查询，线上跑的时候也是这段查询。

eland 给了 `LTRModelConfig` 和 `QueryFeatureExtractor` 这两个工具类，用来描述特征长什么样：

```python
from eland.ml.ltr import LTRModelConfig, QueryFeatureExtractor

ltr_config = LTRModelConfig(
    feature_extractors=[
        # title 字段的 BM25 分数
        QueryFeatureExtractor(
            feature_name="title_bm25",
            query={"match": {"title": "{{query}}"}}
        ),
        # actors 字段的 BM25 分数
        QueryFeatureExtractor(
            feature_name="actors_bm25",
            query={"match": {"actors": "{{query}}"}}
        ),
        # 更严格的匹配：所有 term 都必须命中
        QueryFeatureExtractor(
            feature_name="title_all_terms_bm25",
            query={
                "match": {
                    "title": {"query": "{{query}}", "minimum_should_match": "100%"}
                }
            },
        ),
        QueryFeatureExtractor(
            feature_name="actors_all_terms_bm25",
            query={
                "match": {
                    "actors": {"query": "{{query}}", "minimum_should_match": "100%"}
                }
            },
        ),
        # 用 script_score 直接读字段值，把热度作为特征
        QueryFeatureExtractor(
            feature_name="popularity",
            query={
                "script_score": {
                    "query": {"exists": {"field": "popularity"}},
                    "script": {"source": "return doc['popularity'].value;"},
                }
            },
        ),
    ]
)
```

特征设计是 LTR 项目里最值得反复打磨的部分。BM25 的全字段命中、title 是否完全匹配、热度、时效性、点击率统计……这些信号都可以以同样的形式塞进 `feature_extractors`。

## 八、构造训练样本

特征定义好之后，需要把判定列表里的每个 `<query, doc_id>` 对扩展成"原始标注 + 一行特征向量"。eland 的 `FeatureLogger` 就是干这件事的——按 query 分组，把这一组涉及到的文档 ID 一次性丢给 ES，让 ES 算出每个文档在每个特征下的分数。

整个过程画出来是这样：
![Clipboard_Screenshot_1780393151.png](https://developer.qcloudimg.com/http-save/yehe-7348459/530c201aa3971a3d9efc4bf75b9ac03b.png)

说白了就是：**人标的对错 + ES 算的分数 = 能喂给 XGBoost 的数据**。

```python
import numpy
from eland.ml.ltr import FeatureLogger

feature_logger = FeatureLogger(es_client, MOVIE_INDEX, ltr_config)


def _extract_query_features(query_judgements_group):
    doc_ids = query_judgements_group["doc_id"].astype("str").to_list()
    query_params = {"query": query_judgements_group["query"].iloc[0]}

    doc_features = feature_logger.extract_features(query_params, doc_ids)

    for feature_index, feature_name in enumerate(ltr_config.feature_names):
        query_judgements_group[feature_name] = numpy.array(
            [doc_features[doc_id][feature_index] for doc_id in doc_ids]
        )

    return query_judgements_group


judgments_with_features = judgments_df.groupby(
    "query_id", group_keys=False
).progress_apply(_extract_query_features)
```

这一步的耗时和网络很有关系。如果网络没问题，示例数据集基本上 2 分钟内就跑完了。

## 九、训练 XGBoost 模型

ES 的 LTR rescorer 只认 XGBRanker 训出来的模型。训练目标用 NDCG（一种常见的排序质量打分方式，分越高排得越像我们想要的样子），评估指标用 NDCG@10，再加个早停（效果连续几轮不提升就自动停下来）。

```python
from xgboost import XGBRanker
from sklearn.model_selection import GroupShuffleSplit

ranker = XGBRanker(
    objective="rank:ndcg",
    eval_metric=["ndcg@10"],
    early_stopping_rounds=20,
)

X = judgments_with_features[ltr_config.feature_names]
y = judgments_with_features["grade"]
groups = judgments_with_features["query_id"]

# 按 query_id 分组划分训练/验证集，避免同一 query 的样本被切到两边
group_preserving_splitter = GroupShuffleSplit(n_splits=1, train_size=0.7).split(
    X, y, groups
)
train_idx, eval_idx = next(group_preserving_splitter)

train_features, eval_features = X.loc[train_idx], X.loc[eval_idx]
train_target, eval_target = y.loc[train_idx], y.loc[eval_idx]
train_query_groups, eval_query_groups = groups.loc[train_idx], groups.loc[eval_idx]

ranker.fit(
    X=train_features,
    y=train_target,
    group=train_query_groups.value_counts().sort_index().values,
    eval_set=[(eval_features, eval_target)],
    eval_group=[eval_query_groups.value_counts().sort_index().values],
    verbose=True,
)
```

训练完成后可以画一下特征重要度，对模型有个直观判断：

```python
from xgboost import plot_importance

plot_importance(ranker, importance_type="weight")
```
![Clipboard_Screenshot_1780393244.png](https://developer.qcloudimg.com/http-save/yehe-7348459/43dc47b744be69e513c9d0d1ccc5fc0c.png)

图基本都长一个样：`title_bm25` 和 `popularity` 这两根柱子明显比别的长。其实也不奇怪——搜电影的时候，标题命中的、大家都在看的，本来就该排前面。模型只是把这些我们平时凭感觉做的判断，给量化出来了。

## 十、把模型推到 ES

eland 的 `MLModel.import_ltr_model` 一行代码搞定。注意 `ltr_model_config` 一定要带上，因为 ES 在线推理时也要按这份配置去算特征。

```python
from eland.ml import MLModel

LEARNING_TO_RANK_MODEL_ID = "ltr-model-xgboost"

MLModel.import_ltr_model(
    es_client=es_client,
    model=ranker,
    model_id=LEARNING_TO_RANK_MODEL_ID,
    ltr_model_config=ltr_config,
    es_if_exists="replace",
)
```

## 十一、把模型当 rescorer 用

模型上线后，调用方式和普通的 rescore 完全一致——`_search` 接口里加一段 `rescore` 即可。`window_size` 控制需要被精排的候选条数，一般取 50~200，越大越准但代价越高。

```json
GET /movies/_search
{
  "query": {
    "multi_match": {
      "query": "star wars",
      "fields": ["title", "overview", "actors", "director", "tags", "characters"]
    }
  },
  "rescore": {
    "window_size": 50,
    "learning_to_rank": {
      "model_id": "ltr-model-xgboost",
      "params": {
        "query": "star wars"
      }
    }
  }
}
```

## 十二、效果对比

用同一条 query `star wars` 做对比。先看纯 BM25 的结果：

```python
query = "star wars"
search_fields = ["title", "overview", "actors", "director", "tags", "characters"]
bm25_query = {"multi_match": {"query": query, "fields": search_fields}}

bm25_search_response = es_client.search(index=MOVIE_INDEX, query=bm25_query)

[
    (movie["_source"]["title"], movie["_score"], movie["_id"])
    for movie in bm25_search_response["hits"]["hits"]
]
```

再看叠加 LTR rescorer 之后的结果：

```python
ltr_rescorer = {
    "learning_to_rank": {
        "model_id": LEARNING_TO_RANK_MODEL_ID,
        "params": {"query": query},
    },
    "window_size": 100,
}

rescored_search_response = es_client.search(
    index=MOVIE_INDEX, query=bm25_query, rescore=ltr_rescorer
)

[
    (movie["_source"]["title"], movie["_score"], movie["_id"])
    for movie in rescored_search_response["hits"]["hits"]
]
```

两份结果摆在一起就很直观了：
![Clipboard_Screenshot_1780393286.png](https://developer.qcloudimg.com/http-save/yehe-7348459/bf9e59598e4414f366a08180e63497a4.png)

> 上面是示意性结果，实际名次以跑出来的为准。


---

## 小结
LTR 业内折腾好些年了，只是早些年要自己搭一套训练、部署、线上调用的链路，有一定门槛。现在 Elastic 把它接进 `_search` 的 rescore 之后，整件事就轻了很多：训练交给 XGBoost，部署一行 eland，线上调用还是普通的 search 请求。再加上腾讯云 ES 9.1.3 这种托管形态，ML 节点、Kibana、模型管理这些都是现成的，自己什么也不用搭。

对已经在用 Elasticsearch 做搜索的团队来说，这条路投入不大，效果也很容易看见。如果你手头的搜索业务正好卡在那种「BM25 已经调到不能再调」的阶段，不妨找个空闲的下午，拿自己的数据跑一遍——说不定那个一直排不上去的结果，这次真就上来了。

在搜索领域，BM25 一直是文本相关性打分的默认选择。它简单、稳定、可解释，用 ES 做搜索的团队基本都在用。但只要业务跑得久一点，几乎都会碰到同一个尴尬的问题：搜出来的十条结果一眼看过去都还算相关，可用户心里真正想要的那一条，偏偏卡在第二页第三条。

Elasticsearch 实战 | 陪了搜索十几年的 BM25，也该有个伴了

媒婆是怎么学会推人的？XGBoost 是怎么学会排序的？一份电影数据集，带你在腾讯云 ES 9.1.3 上跑通 LTR 全流程。

官方产研

人工智能

后端

大数据

BM25算法在搜索领域长期占据主导地位，但存在相关性排序与用户需求不匹配的问题。Learning to Rank(LTR)技术通过机器学习模型重新排序搜索结果，有效解决这一痛点。本文以电影搜索为例，详细讲解如何在腾讯云Elasticsearch 9.1.3上实现LTR全流程，包括特征定义、XGBoost模型训练到线上部署，帮助提升搜索结果的精准度。

Elasticsearch 

ES特惠专场，新客首购1折起！


2026年中大促 | AI 领航 智绘未来

bigdata-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

BM25算法在搜索领域长期占据主导地位，但存在相关性排序与用户需求不匹配的问题。Learning to Rank(LTR)技术通过机器学习模型重新排序搜索结果，有效解决这一痛点。本文以电影搜索为例，详细讲解如何在腾讯云Elasticsearch 9.1.3上实现LTR全流程，包括特征定义、XGBoost模型训练到线上部...

Elasticsearch 实战 | 陪了搜索十几年的 BM25，也该有个伴了-腾讯云开发者社区-腾讯云

Elasticsearch 实战 | 陪了搜索十几年的 BM25，也该有个伴了

Elasticsearch 实战 | 陪了搜索十几年的 BM25，也该有个伴了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐