CHIANGEL/Awesome-LLM-for-RecSys · 上手攻略

  • 仓库：CHIANGEL/Awesome-LLM-for-RecSys
  • 链接：https://github.com/CHIANGEL/Awesome-LLM-for-RecSys
  • 分类：ai
  • 作者：Tom
  • 更新：2026-10-27

§0 三证自检

项 状态 证据
GitHub URL 已 fetch ✅ README raw 全文（111,459 字节）已读取
顶会/期刊 anchor 已查证 ✅ 关联论文发表于 ACM TOIS，DOI 10.1145/3678004，标题 How Can Recommender Systems Benefit from Large Language Models: A Survey
README 子模块 anchor ✅ where-framework-1.png 框架图 + §1.1~§1.7 七个子表 + §2 数据集 + §3 相关仓库
最近提交 ✅ 06b2159c（2026-10-26），合并 PR #23 添加 PGPO (EMNLP 2026)
许可 / Stars ✅ MIT · 1,565 stars · 92 forks（GitHub API，2026-10-27 读取）

⚠️ 版本说明：本文基于 main 分支在 2026-10-26 的提交 06b2159c。该仓库为纯文档型（awesome list），没有版本号语义，后续提交可能增删条目。

这是什么

这是推荐系统（RecSys）与大语言模型（LLM）交叉方向的一份高质量论文索引库，不是代码库。仓库没有 requirements.txt、没有 setup.py、没有可运行脚本，全部内容就是一个 README.md（约 10 万字符、705 行表格数据）。

它的独特价值在于：作者不是简单地按时间倒序堆 arXiv 链接，而是给出了一套「LLM 在推荐系统流水线中被插入到哪个位置」的分类骨架。这张骨架来自作者自己被 TOIS 接收的综述论文，是这个仓库真正的骨架资产；仓库本身是那份综述的"活体索引"。

解决什么问题

推荐系统研究这几年的碎片化非常严重：同一篇论文有人说它属于"特征增强"，有人说它属于"排序模型"，新入场的学生几乎每次都要重新建立分类直觉。这个仓库把这个问题标准化了：

  • 统一坐标系：任何 LLM+RecSys 论文都能被塞进 §1.1~§1.5 五个位置之一，读者可按位置而非按关键词检索。
  • 暴露工程变量：每行表格固定给出 LLM Backbone (Largest)（如 PaLM 540B、LLaMA2 7B、T5-XL 3B）和 LLM Tuning Strategy（Frozen / Full Finetuning / LoRA / Prompt Tuning / Adapter）。这两列是判断"这篇能不能在我这个算力下复现"的硬信息，纯标题列表给不了。
  • 给出版本锚点：Publication 列区分 Arxiv 2023 / RecSys 2023 / WWW 2024 / EMNLP 2025 / NIPS 2023 等，读者能快速识别"已过顶会 vs 还是 preprint"。

快速安装

它是一个 markdown 资源，不需要 pip 安装。但"装"的方式决定了你日后检索的效率，有三种做法，按推荐度排序：

方式一：直接在线读（最快，零成本）

# 直接抓取 README 原文到本地，随时 grep
curl -sL https://raw.githubusercontent.com/CHIANGEL/Awesome-LLM-for-RecSys/main/README.md -o llm4recs.md

方式二：克隆成 git 仓库（想跟踪更新时用）

git clone https://github.com/CHIANGEL/Awesome-LLM-for-RecSys.git
cd Awesome-LLM-for-RecSys
# 只拉近一年的论文更新（日志量大，建议 shallow）
git log --oneline --since="2025-01-01" | head -50

方式三：配合结构化检索（本仓库最实用的用法）

README 是 markdown 表格，但表格列是固定的，可以直接当半结构化数据用：

# 抽出所有含 LoRA 的论文行
grep -n "LoRA" llm4recs.md

# 抽出所有 EMNLP / RecSys 等已过会的论文（排除纯 Arxiv）
grep -E "\| (EMNLP|RecSys|WWW|KDD|SIGIR|AAAI|NIPS|ICLR|ACL|CIKM|ICDE|TACL|TNNLS|IEEE Access) " llm4recs.md

# 列出全部数据集与 benchmark
sed -n '/## 2. Datasets & Benchmarks/,/## 3. Related Repositories/p' llm4recs.md

核心用法

用法 1：按"LLM 插入位置"选方向

仓库的 §1 分支是这样的（这是它最有价值的部分）：

  • §1.1 LLM for Feature Engineering：LLM 用来造特征、造数据。分 1.1.1 用户/物品级特征增强（LLM4KGC、TagGPT、KAR、PIE、RLMRec、Llama4Rec 等），1.1.2 实例级样本生成（GReaT、ONCE、DPLLM、Agent4Rec、RecPrompt 等）。
  • §1.2 LLM as Feature Encoder：LLM 当编码器。分 1.2.1 表示增强（U-BERT、UNBERT、TIGER、SSNA、CollabContext 等），1.2.2 统一跨域推荐（UniSRec、VQ-Rec、TCF、S&R Foundation、PMMRec 等）。
  • §1.3 LLM as Scoring/Ranking Function：LLM 直接打分排序。分 1.3.1 打分任务（TALLRec、PromptRec、RecFormer、TabLLM 等）、1.3.2 生成任务、1.3.3 混合任务。
  • §1.4 LLM for User Interaction：任务型与开放式交互推荐。
  • §1.5 LLM for RS Pipeline Controller：LLM 当编排控制器（Chat-REC、RecMind、InteRecAgent、CORE、LLMCRS）。
  • §1.6 Related Survey Papers：32 篇相关综述，用于交叉定位。
  • §1.7 Newest Research Work List：综述定稿（2024-07-09 v6）后的增量跟踪区。

典型动作：如果你要做"用 LLM 做跨域推荐"，直接跳 §1.2.2 对照 backbone 尺寸和微调策略；要做"LLM 做 agent 编排"，看 §1.5 和 §1.7。

用法 2：选数据集与 benchmark

§2 明确列出了数据集（RecSysLLMsP、AmazonQAC、NineRec、MicroLens、Amazon-Review 2023、Reddit-Movie、MovieLens、GoodReads、PixelRec、Netflix 等）和 benchmark（InfoDeepSeek、RecBench、RecBench+、Shopping MMLU、OpenP5、TABLET、LLMRec 等）。

作者在 §2 开头写了一条筛选原则，值得原样记住：

"The datasets & benchmarks for LLM-related RS topics should maintain the original semantic/textual features, instead of anonymous feature IDs."

意思是：用于 LLM+RecSys 研究的数据集必须保留原始语义/文本特征，不能只给匿名 ID。因为 LLM 这条路线的全部前提就是"文本里有信息"，用纯 ID 的 MovieLens 变体会让整个方法论失效。

用法 3：横向对比同方向论文

因为表格列对齐了，可以横向扫一行做决策。例如在 §1.2.1 里对比 TIGER（Sentence-T5-base 223M，Frozen，NIPS 2023）与 LLM2BERT4Rec（text-embedding-ada-002，Frozen，RecSys 2023）：前者是"生成式检索"，用语义 ID 把推荐变成序列生成；后者是"LLM 蒸馏出来的 embedding 服务召回"。两者 backbone 都是冻结的、都在百 MB 到 GB 量级，落地成本接近，但任务形态完全不同。

典型适用场景

  1. 开题/综述阶段：写 related work，需要按分类而不是按时间铺开文献。
  2. 选 baseline：需要确认"我这个方向上最常被拿来对比的方法"是谁。仓库的表格给了 backbone 和微调策略，比论文正文更容易横向比。
  3. 找数据集：确定用哪个 benchmark 时，这里能同时给出数据集链接、benchmark 论文链接和代码链接（部分行带 [Code]）。
  4. 评估 LLM 方案的可行性：扫一眼 LLM Backbone (Largest) 列，如果某方法必须 540B PaLM 才能复现，那你的选题在落地上大概率要换小模型变体。

坑与注意

  1. 论文表格不是安装指南（现象：这个仓库全部是论文索引，没有任何可运行代码。影响：照着它做项目时，会误以为"仓库里有实现"。修复：需要代码时顺着论文的 GitHub 链接走，别在仓库里找）。
  2. Backbone 列是"最大型号"，不是"你们会用的型号"（现象：LLM4KGC 标注 PaLM (540B)/ChatGPT。影响：误判复现成本。修复：该列是上限参考，实际复现多数论文换成了 7B/13B 开源模型，须回原论文正文核对）。
  3. Publication 列里 "Arxiv 2023/2024" 不等于已发表（现象：大量条目标 Arxiv。影响：把预印本当顶会引用，审稿会被质疑。修复：只引用带 RecSys/WWW/SIGIR/KDD/EMNLP 等会议名或 TOIS/TKDE/TACL 等刊名的条目，其余视为预印本）。
  4. §1.7 是无序追加列表，会出现重复行（现象：实测 A Multi-Agent Conversational Recommender System 在 §1.7 中出现两次。影响：统计论文数量时虚高。修复：去重后再引用数量）。
  5. §1.7 有列错位（现象：部分行多了 Falcon (40B) | Frozen 两列，说明是手工追加时未对齐。影响：解析表格时字段错位。修复：解析时不要假设列数固定，要按 | 分隔后按位置容错解析）。
  6. 分类边界本身有争议（现象：同一论文可能既能算 feature engineering 也能算 scoring。影响：读者在不同小节看到同一批论文，怀疑仓库质量。修复：把它当作检索入口而非权威归属，最终判断以原论文自述的任务设定为准）。
  7. 综述本体已定稿，不再更新（现象：README 写明 "Since our survey paper is archived, we will update the latest research works at 1.7"。影响：把 2024-07 之前的认知当作最新。修复：2024 年后的进展要靠 §1.6 的新综述 + §1.7 增量条目交叉验证）。
  8. 作者已不在维护第一手内容（现象：作者另开了微信"周论文笔记"，说明主力维护转移到了仓库外。影响：更新节奏不可预期。修复：不要把它当实时订阅源，用 §1.6 的多篇新综述（2025 年的 GR-LLMs、Agentic RecSys 综述等）补全）。
  9. 相邻仓库存在重叠（现象：§3 Related Repositories 列了 rs-llm-paper-list、Awesome-LLM4RS-Papers、LLM4Rec、LLM4IR-Survey 等 5 个近亲仓库。影响：同时订阅会重复推送。修复：只留一个主源，其余用于交叉验证）。

与同类对比

维度 本仓库 rs-llm-paper-list Awesome-LLM4RS-Papers
组织方式 按 LLM 插入位置分类 待核实（未逐条抓取） 待核实（未逐条抓取）
是否给 backbone 型号 ✅ 每一行都给 待核实 待核实
是否给微调策略 ✅ Frozen/FFT/LoRA/Prompt 待核实 待核实
是否给数据集/benchmark ✅ §2 独立成节 待核实 待核实
与综述论文绑定 ✅ TOIS 已发表，骨架同源 独立维护 独立维护

⚠️ 诚实标注：表格右侧两列的对比项未逐一抓取核实，它们只是 §3 里给出的仓库名，本文的差异判断主要基于本仓库自身的结构特征，不构成对另两个库的实测结论。

同类还有 LLM4IR-Survey（信息检索方向）和 awesome-recommend-system-pretraining-papers（预训练推荐方向）。如果你的问题偏 IR 或偏预训练而非 LLM，这两本更对口。

一句话推荐

做 LLM+推荐系统研究，这本索引进场即用、分类骨架清晰、还附数据集和 benchmark，是性价比极高的一份"领域地图"；但它是一张静态地图不是指南针——2024 年之后的方向要自己用 §1.6 的新综述补齐，引用时务必区分会议论文与预印本。