https://www.codabench.org/competitions/15786/?utm_...

下面是我按“规则约束 → 评测目标 → 可落地高分系统”读完后的建议。Codabench 页面本身抓取到的公开文本主要是比赛标题，具体规则、数据、baseline/evaluator 分散在官方 RecSys Challenge 页面、Music-CRS 网站、Terms、Hugging Face 数据集、baseline/evaluator 仓库里；下面以这些官方材料为准。

1. 这个比赛本质上不是“LLM 聊天”，而是“多阶段检索排序 + 可解释回复生成”

比赛要求系统基于多轮对话历史和用户上下文，输出 Top-20 track_id 排名列表，同时生成一段自然语言回复；推荐排序质量是主轴，回复质量、多样性是辅助但也计入最终评价。官方任务写明要理解显式请求和隐含偏好，例如情绪、风格、流派细节等，并输出前 20 首歌；回复要解释推荐并保持对话连贯。(RecSys Challenge)

评估上，官方页面列出 nDCG@20、Catalog Diversity、Lexical Diversity，以及 blind set 上由 Gemini 系列模型做 LLM-as-a-Judge，评估 Personalization 和 Explanation Quality；本地 evaluator 主要支持 devset 上的 nDCG@1/10/20、catalog diversity、Distinct-2 lexical diversity。(RecSys Challenge)

结论：不要把重点放在“换一个更大的聊天模型”。真正应使用的是：多路候选召回 + 学习排序/重排 + 最后用中等规模 LLM 写解释。 排名模型决定 nDCG，LLM 主要负责解释与个性化文案。

---

2. 关键规则与约束：这些会直接影响建模方案

提交 JSON 必须包含 session_id、user_id、turn_number、predicted_track_ids、predicted_response；每个 session × turn 都要预测，predicted_track_ids 最多 20 个、不可重复、顺序代表相关性、track_id 必须来自 Track Metadata。(GitHub)

官方 baseline 特别强调：推理时必须从 entire track catalog / all_tracks 检索候选，不能用 track_split_types 或其他机制过滤、裁剪候选集合；否则评估可能无效。(GitHub)

训练/验证数据里每个 session 平均 8 turn；evaluator 的 ground truth 生成逻辑是对每个 target_turn_number 提取该 turn 的推荐音乐 track_id 作为 gold，因此建模时应严格按“当前 turn 的用户请求 + 之前历史”做预测，不要偷看未来 turn。(Hugging Face)

数据资源包括 Conversation Dataset、Track Metadata、User Metadata、User Embeddings、Track Embeddings；官方页面说明数据有多轮对话、音乐元数据、用户画像和预抽取多模态/协同过滤 embedding。Hugging Face 预览里，Conversation Dataset 是 16.2k 行、train 15.2k + test 1k；Track Metadata 当前预览为 54.5k 行，字段包括 track_id、ISRC、track/artist/album、tag_list、popularity、release_date、duration、artist_id、album_id。(RecSys Challenge)

一个小提醒：官方 challenge 页面文字写“over 1 million tracks”，但当前公开 Hugging Face Track Metadata 页面显示 54.5k 行，其中 all_tracks 47.1k、test_tracks 7.41k；实际实现时要以你下载到的比赛包和 Codabench 校验为准，提交时遵守 baseline 的 all_tracks 要求。(RecSys Challenge)

---

3. 推荐的总体架构：工业界可落地的 6 层链路

我建议采用下面这条主线：

对话理解 / query rewriting → 多路召回 → 候选融合 → Learning-to-Rank + 神经重排 → Top-20 后处理 → LLM 生成解释。

这比“BM25/BERT + Llama-1B”强得多。官方 baseline 只有两阶段：RecSys 检索候选、LLM 生成回复；核心组件是 Llama-3.2-1B-Instruct、BM25 或 BERT 检索、用户/音乐数据库。官方 dev baseline 里 LLaMA-1B + BM25 的 nDCG@20 只有 0.0815，说明 baseline 很基础，提升空间主要在检索与排序。(GitHub)

第一层：对话理解与结构化意图抽取

这里用 Qwen3-4B / Qwen3-8B / Llama-3.1-8B-Instruct 这类中等模型就够，目标不是直接推荐，而是把输入转成结构化 JSON：

json
{
  "intent_type": "exact_song | artist_deep_cut | genre_mood | era | cover_art | audio_description | playlist_discovery",
  "positive_entities": ["artist", "album", "genre", "mood", "era"],
  "negative_constraints": ["too slow", "not pop"],
  "time_constraints": {"decade": "early 2000s"},
  "liked_track_ids_from_history": [],
  "rejected_track_ids_from_history": [],
  "query_variants": [
    "raw user utterance",
    "short search query",
    "metadata-focused query",
    "mood/genre query"
  ]
}

比赛数据里的用户画像含年龄、国家、性别、preferred language/culture 等字段；盲集样例也能看到 conversation_goal、goal_progress_assessments、历史推荐 track_id 等字段。可以使用当前 turn 之前的这些信息作为特征，但不要使用未来 turn 的文本或未来反馈。(Hugging Face)

这一层非常关键，因为很多 query 不是“推荐 hip-hop”，而是“找某个 2009 年被称为 best track 的 Peter Doherty 歌”“找封面里有滑板的 Fu Manchu 专辑”“找像 Stranger Things 的 80s sci-fi synth soundtrack”。这类题必须把实体、年代、封面/歌词/情绪线索拆出来。(Hugging Face)

---

第二层：多路候选召回，不要只用一个 BM25 或一个 embedding

推荐至少做 6 路召回，每路取 top 100–500，合并后去重，候选池约 800–3000 首：

召回源	推荐模型/方法	作用
词法召回	BM25 / OpenSearch BM25 / learned sparse，例如 SPLADE 或 BGE-M3 sparse	处理歌名、艺人、专辑、年代、精确实体；BM25 对 exact match 很重要。
强文本 dense 召回	Qwen3-Embedding-0.6B/4B/8B 或 BAAI/bge-m3	处理 mood、场景、抽象偏好、跨语言表达。Qwen3 Embedding 系列包含 0.6B/4B/8B embedding 和 reranker；BGE-M3 同时支持 dense、sparse、multi-vector 检索。(GitHub)
官方预抽取 embedding 召回	Track Embeddings 里的 metadata-qwen3_embedding_0.6b、lyrics-qwen3_embedding_0.6b、attributes-qwen3_embedding_0.6b	利用官方已经给出的文本/歌词/属性向量，不必从零抽特征。Track Embedding 数据包含 audio-laion_clap、image-siglip2、cf-bpr、attributes/lyrics/metadata Qwen3 embedding。(Hugging Face)
多模态召回	CLAP text→audio、SigLIP/Qwen3-VL text→image	对“听起来像……”“音频片段描述”“封面描述”特别有用；CLAP 把音频与文本投到同一 latent space，用点积算相似度。(Hugging Face)
协同过滤召回	官方 cf-bpr user/track embedding 点积、BPR/LightGCN/item2vec	对 warm user 和历史偏好有效；User Embedding 数据有 128 维 cf-bpr。(Hugging Face)
会话/反馈召回	基于之前 music turn 的 accepted/rejected track，做 artist/album/tag 邻居扩展	多轮对话里，用户对上一首歌是否接近目标很重要；可以把 “MOVES_TOWARD_GOAL” 当弱正反馈，把 “DOES_NOT_MOVE_TOWARD_GOAL” 当弱负反馈。(Hugging Face)

实现上，Track Metadata 字段应该被扩充成多份索引文本，而不是只拼 track_name + artist_name + album_name。至少包括：

text
track_name
artist_name
album_name
tag_list
release_date / decade
popularity
duration bucket
artist_id / album_id aliases
ISRC
LLM-generated normalized genre/mood/era descriptors

官方 tips 也明确建议“Improve Item Representation”，把 genre tags、mood labels、release year、popularity、audio features 加进去，并用更强 embedding 模型替换基础 BM25/BERT。(GitHub)

---

第三层：候选融合，用 RRF + 分数归一化

多路召回不要直接拼接后按某一路排序。建议先做：

text
score_rrf(item) =
  Σ_source weight_source / (k + rank_source(item))

然后补充 normalized similarity score，例如 BM25 分、dense cosine、CF dot product、CLAP/SigLIP 相似度、exact entity match flag。

RRF 的好处是鲁棒：BM25 抓精确实体，dense 抓语义，CF 抓个人偏好，多模态抓封面/音频线索；某一路失效不会拖垮整体。候选池中要保留每个 source 的 rank 和 score，给下一层 LTR 用。

---

第四层：真正提分的核心——Learning-to-Rank + 神经 reranker

这是整套系统最该投入的部分。

推荐主排序器用 LightGBM LGBMRanker / LambdaMART 或 CatBoost YetiRank。LightGBM 的 LGBMRanker 默认 ranking objective 是 lambdarank，非常适合这种“每个 session-turn 一组候选、目标是把 gold track 排到前面”的问题。(LightGBM Documentation)

训练数据构造：

text
query group = (session_id, turn_number)
positive = ground_truth_track_id
negatives = 多路召回候选里非 gold 的 track
label = 1 for gold, 0 for negatives
objective = lambdarank / rank_xendcg / YetiRank
eval metric = nDCG@20

推荐特征：

text
1. 各召回源 rank：bm25_rank, qwen_dense_rank, bge_rank, cf_rank, clap_rank, siglip_rank
2. 各召回源 score：bm25_score, dense_cosine, cf_dot, audio_sim, image_sim
3. exact match：artist_exact, album_exact, title_fuzzy, tag_overlap, decade_match
4. 用户特征：age_group, country, preferred_musical_culture, user cf embedding score
5. 会话特征：last_liked_artist, last_liked_tag_overlap, rejected_artist_flag
6. 音乐特征：popularity, release_year, duration, artist popularity prior
7. query 类型：exact-song / broad-discovery / mood / cover-art / era / artist-specific
8. diversity-aware features：same_artist_count_in_top20, same_album_count, global catalog usage

在 LTR 后，再加一个 神经 reranker 处理 top 100–300。推荐用 Qwen3-Reranker-4B/8B；Qwen3 Embedding 系列官方就同时提供 embedding 与 reranking 模型，尺寸覆盖 0.6B、4B、8B。(GitHub)

实际落地时我会这样做：

text
候选 2000
→ RRF 初排到 500
→ LightGBM/CatBoost ranker 排到 100
→ Qwen3-Reranker-4B 对 top 100 打 query-track relevance
→ 最终融合：
   final_score =
     0.50 * LTR_score
   + 0.25 * neural_reranker_score
   + 0.10 * exact_constraint_score
   + 0.10 * cf_personalization_score
   + 0.05 * calibrated_popularity_or_diversity_score

官方 tips 也建议在初始 retrieval 后加二阶段 reranker，可以用 embedding reranking、用户 embedding 个性化、多信号 cross-modal reranking，或 LLM-based reranking。(GitHub)

---

第五层：会话序列模型作为加分项，不要替代检索排序

可以训练一个 SASRec / Transformer4Rec / GRU4Rec / LightGCN 辅助模型，用历史 music turn、用户听歌历史、用户 embedding、item co-occurrence 预测下一首可能相关的 track。NVIDIA Merlin Transformers4Rec 是面向 sequential/session-based recommendation 的库，适合利用短期交互序列做下一 item 预测。(GitHub)

但这类模型在本比赛里应作为 召回源或 rerank feature，不要单独做最终排序。原因是很多题是语义线索驱动，例如封面、年代、歌词、情绪、特定艺人，而不是纯“下一个 item”。最佳用法是：

text
seq_model_score = P(track | previous recommended/accepted tracks, user_id)
作为 LTR 特征之一

对于 warm user 和 later turns，它可能贡献明显；对 cold user、turn 1、精确知识型 query，它通常不如 BM25+dense+reranker。

---

第六层：回复生成模型只负责“解释”，别让它决定 track_id

回复模型推荐用 Qwen3-4B / Qwen3-8B / Qwen3-14B-Instruct。官方 baseline 的自定义配置示例已经把 LLM 替换成 Qwen/Qwen3-4B，并建议使用 flash attention。(GitHub)

回复生成输入应只包含最终 top 1–5 首歌的 metadata、用户画像、当前 query、关键匹配理由。输出目标：

text
1. 个性化：点出用户说过的偏好，比如 “你想要 early 2000s alternative rock”
2. 可解释：说明为何 top 推荐符合 mood/genre/artist/era
3. 简洁自然：不要长篇大论
4. 多样表达：避免所有回复都以 “Here are some songs...” 开头
5. 不编造：只能基于 metadata / tags / release_date / known fields

因为 blind set 会有 Gemini judge 评估 Personalization 和 Explanation Quality，而 dev evaluator 还会算 Distinct-2，文案模板不能太死板。(RecSys Challenge)

---

4. 我会优先选择的模型组合

最推荐的“强但可落地”版本

text
Query understanding:
  Qwen3-4B-Instruct 或 Qwen3-8B-Instruct

Sparse retrieval:
  BM25 / OpenSearch BM25
  + BGE-M3 sparse 或 SPLADE

Dense retrieval:
  Qwen3-Embedding-4B
  + BGE-M3
  + 官方 metadata/lyrics/attributes Qwen3 embeddings

Multimodal retrieval:
  CLAP text→audio over audio-laion_clap
  SigLIP/Qwen3-VL text→image over image-siglip2

CF / personalization:
  官方 cf-bpr user-track dot product
  + item2vec/LightGCN co-occurrence
  + session feedback features

Fusion:
  Weighted RRF + score calibration

Main ranker:
  LightGBM LGBMRanker / LambdaMART
  备选 CatBoost YetiRank

Neural reranker:
  Qwen3-Reranker-4B
  资源充足时 Qwen3-Reranker-8B

Response:
  Qwen3-4B-Instruct for speed
  Qwen3-8B/14B-Instruct for better judge score

这个组合比“只换成大 LLM”更稳，因为它覆盖了 exact match、语义、歌词/属性、多模态、协同过滤、会话反馈、个性化、最终解释。

资源有限版本

text
BM25 enriched corpus
+ Qwen3-Embedding-0.6B 或 BGE-M3 dense
+ 官方 cf-bpr dot product
+ RRF
+ LightGBM Ranker
+ Qwen3-4B 生成回复

这套单卡也能跑，工程复杂度适中。Qwen3-Embedding-0.6B 比大 embedding 更省显存；BGE-M3 的优势是一个模型同时覆盖 dense/sparse/multi-vector，适合快速迭代。(GitHub)

资源充足版本

text
Qwen3-Embedding-4B/8B LoRA 微调 bi-encoder
+ BGE-M3 hybrid
+ CLAP/SigLIP/Qwen3-VL multimodal retrieval
+ LightGCN / Transformer4Rec sequence model
+ LightGBM LambdaMART
+ Qwen3-Reranker-8B top100 rerank
+ Qwen3-14B/32B response generation

其中最值得花钱的是 fine-tuned bi-encoder + LTR + reranker，不是 response LLM。

---

5. 训练与验证方案

先复现官方 baseline，确保 JSON 格式、dev evaluator、all_tracks、无重复、每 turn 预测都正确。官方 evaluator 会从 exp/inference/devset/<tid>.json 读预测，计算每个 session-turn 的 nDCG，再按 turn 和 session 做 macro average，同时算 catalog/lexical diversity。(GitHub)

然后按以下顺序做 ablation：

text
A0: 官方 BM25 + Llama1B baseline
A1: BM25 corpus 加 tag_list/release_date/popularity
A2: query rewriting + 多 query BM25
A3: Qwen3/BGE dense retrieval
A4: 官方 Qwen3 track embeddings + cf-bpr
A5: RRF fusion
A6: LightGBM/CatBoost LTR
A7: Qwen3-Reranker top100
A8: 多模态 CLAP/SigLIP
A9: response prompt + 个性化解释优化

每一步都记录：

text
nDCG@1
nDCG@10
nDCG@20
turn-wise nDCG
query_type-wise nDCG
catalog_diversity
lexical_diversity
invalid_id_count
duplicate_count

特别要分 turn 评估：turn 1 更依赖 query/entity/mood，后续 turn 更依赖 session feedback 和上一次推荐的 track metadata。官方 evaluator 明确按 8 个 conversation turns 评估 retrieval metrics。(GitHub)

---

6. 最容易被忽略但会显著影响成绩的细节

第一，充分利用 conversation_goal 和 goal_progress_assessments，但只用当前 turn 之前可见的信息。这些字段在 HF 预览里存在，对理解用户真实目标很有价值；但对每个 target turn，不能看未来 turn 的用户反应，否则属于不合理的信息泄漏。(Hugging Face)

第二，对精确实体 query 要走特殊通道。例如用户提到具体 artist、album、年代、封面描述时，BM25/fuzzy/entity matching 的权重应高于抽象 embedding。Embedding 很容易把“类似风格”排上来，但 nDCG gold 可能是某一首具体歌。

第三，不要为了 catalog diversity 牺牲前几名。nDCG@20 是核心，Top 1/Top 5 的相关性远比“全局多推荐一些不同歌”重要。可以在第 10–20 位做轻微 MMR/diversity，但前 5 位应完全按相关性。

第四，response 不要空，也不要模板过死。本地 lexical diversity 计算 Distinct-2，blind set 还有 Gemini judge。可以用 20–50 个高质量模板 + LLM 改写，但必须保留事实和推荐理由。(GitHub)

第五，严格校验提交文件。无重复、最多 20、valid track IDs、每个 session-turn 都有预测。官方 evaluator 的 compute_metrics 会对重复预测报错，README 也强调 no duplicates、order matters、valid track IDs。(GitHub)

---

7. 不建议作为主线的方案

不建议只用 GPT/Qwen/Llama 直接生成 track_id。track_id 是 UUID，LLM 很容易幻觉；除非你做了 constrained decoding 或 semantic ID generative retrieval。官方 tips 也把 Generative Retrieval 放在 advanced 方向，需要先给 tracks 分配 hierarchical semantic IDs，再 fine-tune LLM 生成这些 IDs。(GitHub)

不建议只换 baseline 的 Llama-1B 到一个大模型。官方 baseline 的 LLM 只生成 response，推荐列表来自 retrieval；如果 retrieval/rerank 不变，nDCG 提升有限。(GitHub)

不建议只用 popularity。官方 dev baseline 里 Popularity nDCG@20 只有 0.0024，几乎没用。(GitHub)

---

8. 一句话结论

最应该使用的不是单一模型，而是：Qwen3/BGE-M3/CLAP/SigLIP/CF 多路召回 + LightGBM/CatBoost 学习排序 + Qwen3-Reranker 重排 + Qwen3-Instruct 生成解释。

其中最可能带来大幅提升的优先级是：

text
1. enriched metadata + query rewriting
2. Qwen3/BGE-M3 dense + BM25 hybrid retrieval
3. cf-bpr / session feedback / co-occurrence personalization
4. LightGBM LambdaMART ranking
5. Qwen3-Reranker top100 rerank
6. response prompt / personalization / lexical diversity polish

这条链路既符合比赛规则，又接近工业推荐系统的真实做法：召回要广，排序要准，解释要稳，提交要严格。