对搜索结果进行精排

数据源与日志要求

您需要收集并整合以下三类日志信息：

构造训练标签（Pointwise）

将问题简化为一个二分类任务，预测一个被曝光的文档是否会被有效点击。

• 正样本（isClick = 1）：定义为有效点击。建议设置一个简单的过滤规则，例如：用户点击了该文档，并且停留时间超过5秒。

• 负样本（isClick = 0）：定义为曝光但未点击的文档。对于点击后迅速离开的（如停留时间<3秒），也可视为弱负样本。

设计特征体系（Feature Engineering）

特征是模型的原材料，其质量直接决定模型效果。以下是搜索排序场景中常用的特征类别，您可以根据业务实际情况选择和构建：

参考实例

1. 将上述处理好的数据整合到PolarDB集群的一张表中，例如train_data。

   CREATE TABLE train_data (
       id INT AUTO_INCREMENT PRIMARY KEY,
       -- 特征列
       query_len INT,
       query_term_count INT,
       doc_category VARCHAR(50),
       doc_score FLOAT,
       doc_during_time INT,
       exp_count BIGINT,
       click_count BIGINT,
       click_rate FLOAT,
       es_score FLOAT,
       word_overlap FLOAT,
       emb_cos_score FLOAT,
       jaccard_score FLOAT,
       editdistance_score FLOAT,
       -- 标签列
       isClick INT
   );

2. 插入示例数据。

   INSERT INTO train_data (query_len, query_term_count, doc_category, doc_score, doc_during_time, exp_count, click_count, click_rate, es_score, word_overlap, emb_cos_score, jaccard_score, editdistance_score, isClick) VALUES
   (10, 2, 'tech', 0.9, 15, 1000, 100, 0.1, 60.5, 0.8, 0.95, 0.7, 0.2, 1),
   (10, 2, 'news', 0.7, 300, 5000, 200, 0.04, 55.1, 0.6, 0.7, 0.5, 0.4, 0),
   (15, 3, 'tech', 0.95, 20, 500, 80, 0.16, 75.0, 0.9, 0.98, 0.8, 0.1, 1),
   (15, 3, 'sports', 0.8, 400, 10000, 150, 0.015, 40.3, 0.3, 0.4, 0.2, 0.8, 0);

模型选择

在开始编码前，需先选择一个适合的模型。对于搜索排序这类拥有丰富结构化特征（表格数据）的场景，梯度提升决策树算法（GBDT）通常是首选。

• 强大的拟合能力：能有效捕捉特征间的复杂非线性关系（例如，“只有当doc_category是‘科技’时，较高的word_overlap才对点击率有强正向影响”）。

• 对特征无需归一化：对数值大小不敏感，简化了数据预处理步骤。

• 容错性好：对异常值和缺失值有较好的容忍度。

• 易于解释：可以分析特征重要性，帮助理解哪些因素对用户点击行为影响最大。

PolarDB for AI内置的aliboost算法就是基于GBDT实现的。因此，在下面的代码中，可通过model_class = 'aliboost'和boosting_type = 'gbdt' 来指定使用它。

训练流程与代码实现

整个训练流程在数据库内部自动完成，PolarDB for AI会读取您指定的train_data表，根据您设置的参数，聚合样本、生成标签，并应用aliboost算法进行迭代学习，最终将训练好的模型元数据持久化存储。

/*polar4ai*/CREATE MODEL rerank_model WITH
(
  model_class = 'aliboost',
  x_cols = 'query_len,query_term_count,doc_category,doc_score,doc_during_time,exp_count,click_count,click_rate,es_score,word_overlap,emb_cos_score,jaccard_score,editdistance_score',
  y_cols = 'isClick',
  model_parameter = (
    boosting_type = 'gbdt',
    n_estimators = 20,
    loss = 'binary'
  )
)AS (SELECT * FROM train_data);

训练细节与参数调优

model_parameter中的参数是模型效果的关键，理解它们有助于您进行精细化调优：

• loss = 'binary'：损失函数。它定义了模型的优化目标。binary (即binary_logloss) 是专门为二分类问题设计的，其目标是让模型输出的预测概率尽可能地接近真实标签（0或1）。在本次任务中，这是一个固定选项。

• n_estimators = 20：决策树的数量。这是模型复杂度的核心参数。一个较大的值能让模型学习得更充分，但也可能导致过拟合（模型在训练集上表现很好，但在新数据上表现差）。您需要通过后续的评估来寻找最佳值。

• 其他关键超参数：除了示例中的参数，aliboost还支持更多用于控制模型行为的参数，例如：

  • max_depth：每棵树的最大深度，控制单棵树的复杂度。

  • learning_rate：学习率，控制每棵树对最终结果的贡献权重。较小的学习率通常需要搭配更多的n_estimators。

  • min_data_in_leaf：每个叶子节点最少的样本数，用于防止过拟合。

参考建议

• 数据划分：在生产环境中，严格按时间划分训练集和测试集（例如，用上周的数据训练，用昨天的数据测试）至关重要，这能最真实地模拟线上环境。

• 类别不平衡：搜索场景中，未点击的负样本数量远多于点击的正样本。如果类别比例失衡严重，可以考虑在构造train_data时对负样本进行降采样（down-sampling），以帮助模型更好地学习正样本的特征。

评估指标：AUC与Precision@K

对于排序任务，通常关注以下离线评估指标：

• AUC（Area Under the Curve）：衡量模型整体的排序能力。它反映的是模型将正样本排在负样本前面的概率。AUC值在0.5到1之间，越接近1，说明模型区分会点击和不会点击的文档的能力越强。它是一个宏观的，与具体排序位置无关的诊断性指标。

• Precision@K（前K个结果的准确率）：更贴近业务场景的指标。它计算的是在模型排序得分最高的K个结果中，真正被用户点击的（正样本）占了多少比例。例如，Precision@10衡量了用户在搜索结果第一页所看到的内容的质量。

评估代码实现

使用EVALUATE语句可以方便地计算这些指标。下面的例子演示了如何计算AUC：

/*polar4ai*/SELECT * FROM EVALUATE(
  MODEL rerank_model,
  SELECT * FROM test_data
) WITH (
  x_cols = 'query_len,query_term_count,doc_category,doc_score,doc_during_time,exp_count,click_count,click_rate,es_score,word_overlap,emb_cos_score,jaccard_score,editdistance_score',
  y_cols = 'isClick',
  metrics = 'auc'
);

执行上述语句后，您会得到一个AUC值。一般来说，AUC达到0.75以上，模型就具有了不错的区分能力。达到0.85以上，则表示模型效果非常优秀。您可以将这个值与基线模型（如仅使用es_score排序）的AUC进行对比，以量化新模型的提升。

参考建议

• 多维度评估：不要只看总体的AUC。将测试集按不同维度（如查询的头部/腰部/长尾、不同客户端、不同内容类目）进行切分，分别计算AUC，这能帮助您发现模型在哪些细分场景下表现不佳，从而进行针对性优化。

• 特征重要性分析：训练完成后，您还可以分析模型的特征重要性，了解哪些特征对预测贡献最大。这不仅能帮助您理解模型，还能指导未来的特征工程方向。

在线服务流程

一个典型的在线排序服务流程如下，它需要您的应用后端与PolarDB集群紧密协作：

1. 召回候选集（Recall）：您的应用后端接收到用户查询后，首先请求召回引擎（如Elasticsearch），获取一个初步排序的候选文档列表（例如Top 400），并取回文档ID、ES分数等基础特征。

2. 准备预测数据：针对这400个候选文档，应用后端需要实时地准备好模型所需的所有特征。

   • 离线特征：如文档的历史点击率、质量分等，通常从高速缓存（如Redis）或特征库中批量拉取。

   • 在线特征：如查询与每个文档的语义相似度，需要实时计算。为提高效率，文档的向量表示（Embedding）应提前算好并存储，在线只需计算一次查询的向量，然后与400个文档向量进行点积运算。

3. 写入预测表：将整合好的特征数据批量写入PolarDB的一张预测专用表（例如recall_table）中。

4. 执行模型预测（Predict）：应用后端执行PREDICT语句，调用之前训练好的rerank_model为表中的每一行数据（每一个候选文档）打分。

   /*polar4ai*/SELECT * FROM PREDICT(
     MODEL rerank_model,
     SELECT * FROM recall_table
   ) WITH (
     x_cols = 'querylen,query_term_count,doc_category,doc_score,doc_during_time,exp_count,click_count,click_rate,es_score,word_overlap,emb_cos_score,jaccard_score,editdistance_score'
   );

5. 业务逻辑后处理：您的应用程序获取带有预测分的文档列表后，不要直接返回，通常还需要进行一系列业务规则处理：

   • 多样性：避免首页出现过多相同类目或来自同一作者的内容。可以对连续出现的同类目/同作者内容进行降分惩罚。

   • 新鲜度：对新发布的高质量内容进行适当提权。

   • 业务规则：强制置顶或过滤某些特定内容。

6. 返回结果并记录日志：将经过后处理的最终排序列表返回给前端展示给用户。同时，建议完整地记录此次请求的详细日志（包括查询、返回的文档列表、它们的顺序、模型得分等），这些日志同于持续训练模型。

参考建议

• 性能与延迟：在线服务的延迟是核心用户体验指标。您需要设定一个严格的端到端时延预算（例如，P95延迟<100ms）。这个预算反过来会限制您可以召回的候选集大小（K值）以及特征的复杂度。

• 缓存策略：缓存是降低延迟的利器。对高频查询的最终排序结果、热门文档的特征、查询的向量表示等都可以进行缓存。

• 高可用与安全：

  • 灰度发布（A/B测试）：新模型上线应采用A/B测试，切分一小部分流量给新模型，验证其线上真实效果。

  • 熔断与降级：为防止模型服务或其依赖（如特征库）出现问题影响整体可用性，应设置熔断机制。当排序服务超时或失败时，能自动降级到旧的排序策略（例如，直接使用ES的召回排序结果），保证用户总能看到内容。