推荐系统（十二）—— 大语言模型与推荐系统

一个用户打开电影 App，输入：「想看类似《盗梦空间》的，但别太压抑。」传统推荐系统——协同过滤、双塔 DNN、甚至 DIN——在这句话里抓不到任何有用的信号。它没有点赞按钮可以计数，没有共看图谱可以遍历，也没有用户 ID 关联到历史记录。这句话必须先被翻译成 ID，系统才能开始工作。

大语言模型的问题恰好相反：它有过多的世界知识，却不知道「这个用户」是谁。它知道《盗梦空间》是诺兰拍的、采用非线性叙事、结尾留有希望但不明确；它理解电影语境下「压抑」的含义；它能立刻列出二十部相符的片子。但它无法分辨这二十部里哪些用户已经看过、给过差评、或者看到一半就退出。

2023 到 2026 年，推荐系统圈真正有意思的问题不是「LLM 还是传统模型」，而是怎么把它们组合起来。本文沿着三种已经在工业界跑通的组合模式展开，附上代码和那些绕不过去的取舍。

你将学到

• LLM 在推荐里的三种角色：增强器、预测器、智能体——以及哪些论文落在哪种角色
• 排序任务的 Prompt 解剖学（TallRec / P5 风格）以及为什么必须把温度压到 0.3 以下
• LLM 改写物品描述如何让 embedding 聚类显著变锐、解决冷启动
• 所有生产团队最终都会收敛到的混合管线：ANN → DNN 排序器 → LLM 重排
• ChatREC 风格的多轮对话流程：状态管理与工具调用
• 成本/质量帕累托前沿：什么时候微调的 7B 比 GPT-4 划算，甜点区在哪
• 可运行的 Python 代码：Prompt 排序、混合重排、对话状态管理

前置知识

• Embedding、排序、检索/排序两阶段架构（第 1 篇 、第 4 篇 ）
• 熟悉一个 LLM SDK 即可（OpenAI、Anthropic、vLLM），不需要懂微调
• 编码器示例需要一些 PyTorch 基础

LLM 在推荐系统中的三种角色

文献看起来很乱——P5、M6-Rec、KAR、TallRec、BIGRec、GenRec、LlamaRec、ChatREC——但每一篇都能精确地落到三种角色之一。角色一旦确定，延迟、成本、训练开销、以及 LLM 在系统里到底做什么，就全都定下来了。

角色一：增强器（离线特征生成）

LLM 永远不参与在线请求。离线阶段，它读取每个物品的标题、描述、评论，吐出更丰富的特征：结构化属性、稠密语义向量、扩写后的描述，或者伪标签。这些特征再喂给一个完全传统的 CTR / CF 系统。

这是最早一批严肃的「LLM + 推荐」工作的核心思路：P5（Geng et al., RecSys 2022）用统一的文本到文本 T5 把五种推荐任务整合在一起；M6-Rec（Cui et al., 2022）用阿里 M6 生成物品描述和行为提示；KAR（Xi et al., 2024）把 LLM 的推理结果蒸馏成可复用的特征向量。在线服务依然能保持 50ms 以内，因为 LLM 的成本被摊薄到了百万级请求上。

适用场景：你已经有一个跑得动的排序模型，但冷启动物品、稀疏文本、难以打标的类别正在拖累召回。

角色二：预测器（直接排序或生成）

LLM 就是排序器。你把用户历史和候选列表（甚至不给候选）交给它，让它输出 yes/no 判断、分数、或者直接生成下一个物品。

两个流派：判别式（TallRec、BIGRec——用 LoRA 在 (历史, 物品) → yes/no 上微调 Llama-2-7B）和生成式（GenRec——直接生成下一部电影的标题）。TallRec（Bao et al., RecSys 2023）有一个很惊艳的结果：用 LoRA 微调过的 7B 模型，在只有几百条训练样本的情况下，能击败大得多的零样本 LLM，并且追平强序列推荐 baseline。LlamaRec（Yue et al., 2023）更进一步，加了一个 verbalizer 头，让 LLM 一次前向就能对整个候选集排序，而不是 K 次单独调用。

适用场景：物品文本信息丰富、数据量小（冷启动领域、新业务线），或者需要排序结果自带解释。

角色三：智能体（带工具的编排者）

LLM 不只做排序——它做规划。它维护对话状态，决定何时调用检索、何时反问澄清、何时按年份/价格过滤、何时把任务交给下游模型。ChatREC（Gao et al., 2023）是这个范式的开山之作；RecAgent（Wang et al., 2023）和 InteRecAgent 进一步引入模拟用户做评测。

适用场景：对话式产品（聊天机器人、语音助手、带追问的搜索），或者用户确实没法一句话说清自己想要什么。

成本排序大致是：增强器 ≪ 预测器 ≪ 智能体。灵活性的排序也是这样。多数生产系统都是从增强器起步，再升级为预测器（接在传统排序后面做重排），只在特定产品形态上才用智能体。

基于 Prompt 的排序

基于 Prompt 的推荐是入门方案：不需要训练，一个 API key 加一个写得好的 Prompt 就够了。模板有五个部分，顺序很重要。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

def build_recommendation_prompt(history, target, examples=None):
    """TallRec / P5 风格的排序 Prompt。"""
    # 1. 角色 + 任务：把 LLM 锁定到一个窄行为里
    role = (
        "You are a movie recommender. Given the user's viewing history, "
        "predict whether they will like the target movie."
    )

    # 2. 用户历史（按时间顺序，带信号）
    hist_lines = "\n".join(
        f"  - {item['title']} ({'liked' if item['liked'] else 'disliked'})"
        for item in history[-20:]   # 截断以适应上下文
    )

    # 3. 候选物品（带属性）
    target_line = (
        f'Target movie: "{target["title"]}" '
        f'({target["genre"]}, {target["year"]}, dir. {target["director"]})'
    )

    # 4. 输出格式（强约束——能用单 token 就用单 token）
    output_spec = 'Answer with exactly one token: "Yes" or "No".'

    # 5. Few-shot 示例（可选；除了输出格式外最大的精度杠杆）
    fewshot = ""
    if examples:
        fewshot = "\n".join(
            f"[Example {i+1}]\nHistory: {ex['history']}\n"
            f"Target: {ex['target']}\nAnswer: {ex['answer']}\n"
            for i, ex in enumerate(examples)
        )

    return f"""{role}

{fewshot}
History:
{hist_lines}

{target_line}

{output_spec}"""

有三条工程规则听起来像废话，实际上每一条都救过命：

1. 逐 token 约束输出。单个 Yes/No 可以解析；「我觉得用户可能会喜欢，因为……」没法解析。对 K 个物品排序时，让模型输出 [3, 1, 5, 2, 4]——不要自由文本。SDK 支持的话，用 logit bias 或语法约束解码。
2. 温度压到 0.3 以下。推荐不是创意写作。高温度会让同样的输入产生不同的排序——调试时会让你怀疑人生。
3. 截断历史。LLM 处理超过 50 条历史时质量会下降，而且成本与 prompt token 数线性相关。最近的优先，太老的可以摘要。

零样本 vs 少样本 vs 微调

TallRec 的结果非常有说服力：用 256 条微调样本，LoRA 微调过的 Llama-7B 就能在推荐任务上追平甚至超过零样本 GPT-4，单次成本只有 GPT-4 的零头。只要你手上有一点带标签的交互数据，就该微调。

LLM 作为增强器：让 Embedding 更锐利、冷启动更稳

把 LLM 接入生产系统最便宜、风险最低的方式：离线用它把单薄的物品文本扩写成丰富描述，再用现有的句向量编码器重新编码。

电影标题 "Tenet" 对句向量编码器几乎没有信号。让 GPT-4 把它扩写成：

「2020 年由克里斯托弗·诺兰执导的科幻动作惊悚片。以熵的逆转作为核心剧情装置，探讨自由意志与命定论的主题。基调偏冷峻、氛围感强，配以精心设计的实拍动作场面。受众：喜欢《盗梦空间》《星际穿越》或其他烧脑结构片的观众。节奏紧凑，情感内核是友谊与牺牲。」

——产生的 embedding 就会显著靠近它真正的语义邻居。在 MovieLens 这类数据上的离线测试中，按类型聚类的轮廓系数（silhouette）通常会从 ~0.2（原始标题）跳到 ~0.65（LLM 增强后），P5 和 KAR 的论文都报告过类似效果。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

from openai import OpenAI

client = OpenAI()


def enhance_item(item):
    """离线：把稀疏的物品文本扩写成丰富的语义描述。"""
    prompt = f"""Write an 80-word description of this item for a
recommendation system. Cover: themes, tone, mood, target audience,
similar items, what kind of user would love it.

Title: {item['title']}
Existing tags: {', '.join(item.get('tags', []))}
Year: {item.get('year', 'unknown')}

Description:"""
    return client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.4,
        max_tokens=200,
    ).choices[0].message.content


def build_enhanced_index(items, encoder):
    """每个物品跑一次；缓存到物品本身变更为止。"""
    enhanced_texts = [enhance_item(it) for it in items]
    return encoder.encode(enhanced_texts, batch_size=64)

经济账之所以划算，是因为增强是离线的、一次性的。一百万物品的目录，每次调用 $0.0002，总共 $200，付一次。对比一下在每次在线请求都用 LLM、单次成本相同的话：每百万次查询 $200，持续累计。

「只能离线」这个约束在哪里会疼

LLM 增强只能生成稳定的、物品侧的特征。它做不到：

• 对一个新物品第一小时的交互做出反应
• 捕捉用户专属信号（口味、当下心情、本次会话意图）
• 反映正在发生的趋势（「最近大家都在看 X，因为 Y」）

这些场景就需要在线 LLM 调用——更现实地说，需要混合管线。

混合管线（你最终一定会落到这个架构）

每一个把 LLM 推到生产环境的团队，最后都会收敛到同一个形状：

1. 物品池（10⁶–10⁸）
2. ANN 检索 Faiss/HNSW，10ms，$0，缩到 ~1000 候选
3. CF 或深度排序（DIN、DCN-V2、双塔），30ms，$0，缩到 ~50
4. LLM 重排（GPT-4o 或微调的 7B），1-2s，$0.005-0.01，挑出 Top-10
5. 用户看到 Top-10 + LLM 生成的解释

漏斗比例是关键：在那个昂贵的 LLM 调用之前，已经做了 5-7 个数量级的剪枝。LLM 永远只看 ~50 个物品，不会看到百万级目录。正是这一个架构选择，让 LLM 推荐变得可行。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

class HybridRecommender:
    """ANN -> DNN -> LLM。所有团队最后都会落到这个形状。"""

    def __init__(self, ann_index, dnn_ranker, llm_reranker):
        self.ann = ann_index            # Faiss / HNSW
        self.ranker = dnn_ranker        # DIN / DCN-V2 / 双塔
        self.llm = llm_reranker         # GPT-4o 或微调 7B

    def recommend(self, user_id, query_embedding, k=10):
        # Stage 1: ANN —— 百万 -> ~1000，约 10ms
        cand_ids = self.ann.search(query_embedding, top_k=1000)

        # Stage 2: DNN 排序 —— 1000 -> ~50，约 30ms
        scored = self.ranker.score_batch(user_id, cand_ids)
        top50 = sorted(scored, key=lambda x: -x['score'])[:50]

        # Stage 3: LLM 重排 —— 50 -> Top-10，约 1.5s
        # 关键：prompt 装得下，成本有上界
        return self.llm.rerank(user_id, top50, k=k)

中间这个 DNN 排序阶段是新接触 LLM 的人最容易低估的。你不能从 ANN 直接跳到 LLM 重排：ANN 的 1000 候选噪声仍然太大（爆款但不相关的物品会主导），把 1000 个物品塞进 prompt 要么爆上下文、要么把信号埋了。DNN 给你的是一个干净的 Top-50，并且带着 LLM 没有的学到的交互模式。

冷启动：LLM 真正胜出的战场

「LLM 还是 CF」这个问题，画一张精度对用户历史长度的曲线就有非常清晰的答案：

• 0-5 次交互（冷）：LLM 零样本以 4-7 倍优势胜出。CF 没有任何素材；LLM 的世界知识就是仅有的信号。
• 10-50 次交互（升温中）：差距快速缩小。CF 开始抓到真正的协同信号。
• 100+ 次交互（热）：CF 在纯排序精度上反超。LLM 的世界知识相对于用户实际暴露出的偏好，反而成了噪声。

推论是：按用户状态分流。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

def route_recommend(user_id, query, cf_model, llm_model):
    """根据这个用户的数据密度，选择最合适的模型。"""
    n_interactions = cf_model.interaction_count(user_id)

    if n_interactions < 5:
        # 冷：LLM 仅靠 query 调用世界知识
        return llm_model.recommend(query)
    elif n_interactions < 50:
        # 升温中：混合
        cf_recs = cf_model.recommend(user_id, k=50)
        return llm_model.rerank(query, cf_recs, k=10)
    else:
        # 热：CF 严格更优；LLM 只用来生成解释
        return cf_model.recommend(user_id, k=10)

这也解释了为什么「我们试过 LLM，没打过我们的 DCN」是一个常见的假阴性结论：那个团队几乎可以肯定是在热用户上做的测试，而热用户场景 CF 本来就稳赢。

对话式推荐：ChatREC 风格

对话式推荐器在本质上是另一种东西：它是规划器，不是一次性的排序器。LLM 维护对话状态，决定何时检索、何时澄清、何时给出推荐。推荐这一步本身经常会再委托回检索 + DNN 排序栈。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

class ChatREC:
    """LLM 是规划器；检索和排序是它调用的工具。"""

    def __init__(self, llm, retriever, ranker):
        self.llm = llm
        self.retriever = retriever      # ANN 检索
        self.ranker = ranker            # DNN
        self.state = {
            "history": [],              # 消息日志
            "preferences": {},          # 累积的偏好
            "candidates": [],           # 当前候选短列表
        }

    def turn(self, user_message):
        self.state["history"].append({"role": "user", "content": user_message})

        # LLM 决定下一步动作：澄清 / 检索 / 推荐 / 解释
        plan = self.llm.plan(
            history=self.state["history"],
            current_prefs=self.state["preferences"],
            current_candidates=self.state["candidates"],
        )

        if plan.action == "extract_preference":
            self.state["preferences"].update(plan.extracted_prefs)
            return self.llm.acknowledge(plan.extracted_prefs)

        if plan.action == "retrieve":
            query = self.llm.build_query(self.state["preferences"])
            cand = self.retriever.search(query, top_k=200)
            self.state["candidates"] = self.ranker.rank(cand, top_k=20)
            return self.llm.present(self.state["candidates"][:5])

        if plan.action == "filter":
            self.state["candidates"] = [
                c for c in self.state["candidates"]
                if plan.filter_fn(c)
            ]
            return self.llm.present(self.state["candidates"][:5])

        if plan.action == "explain":
            return self.llm.explain(plan.target_item, self.state["preferences"])

        return self.llm.respond(self.state["history"])  # 兜底

真正难的部分不在这段代码里——难在规划器 prompt（暴露哪些动作、怎么防止 LLM 推荐 candidates 之外的虚构物品）和状态管理（用户改主意时何时丢弃旧偏好、过滤后何时刷新候选）。

成本/质量帕累托前沿

把已发表的方法都映射到（每千次请求成本，相对 CF baseline 的 NDCG 提升），三件事会变得很清楚：

1. **每千请求 $1 以上，收益急剧递减**。从微调 7B（~$0.4）跳到 GPT-4 生成式（~$25），只换来 ~2.4 个 NDCG 点。从 CF baseline 跳到微调 7B，能换来 ~8.6 点，单次延迟成本不到 100 倍。
2. 微调 7B 是生产甜点区。TallRec / LlamaRec 的精度逼近 GPT-4，单次成本却只有 GPT-4 的 1%。如果能一次性付得起 4 张 A100 几小时的 LoRA 训练，全年的推理账单都能省下来。
3. 对话式智能体在另一条曲线上，不是同一曲线的另一个点。它贵不是因为模型本身贵，而是每个 session 都是多轮的——同样一次推荐结果，你付了 5-10 次的请求量。要为它付费，就要因为对话 UX 本身有价值，而不是因为某个排序指标的提升。

实用的成本杠杆

最大的杠杆，没有之一，是上一节讲的按用户状态分流。一个典型平台 70% 以上的请求来自热用户，而热用户场景 CF 严格更优；把他们从 LLM 路径上分流出去，等于免费省下真金白银。

评测：到底要测什么

标准排序指标依然适用（NDCG@K、Recall@K、MRR），但 LLM 系统需要额外的维度：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

import numpy as np


def evaluate_llm_recommender(predictions, ground_truth, llm_calls, latencies):
    """标准指标 + LLM 专属的运营指标。"""
    # --- 质量 ---
    k = 10
    hits = [set(p[:k]) & set(gt) for p, gt in zip(predictions, ground_truth)]
    precision = np.mean([len(h) / k for h in hits])
    recall = np.mean([len(h) / max(len(gt), 1) for h, gt in zip(hits, ground_truth)])

    def ndcg(pred, gt, k=10):
        gt_set = set(gt)
        dcg = sum(1 / np.log2(i + 2) for i, p in enumerate(pred[:k]) if p in gt_set)
        idcg = sum(1 / np.log2(i + 2) for i in range(min(k, len(gt_set))))
        return dcg / idcg if idcg > 0 else 0.0

    ndcg_score = np.mean([ndcg(p, gt) for p, gt in zip(predictions, ground_truth)])

    # --- 运营 ---
    p50_latency = float(np.percentile(latencies, 50))
    p99_latency = float(np.percentile(latencies, 99))
    cost_per_request = float(np.mean(llm_calls)) * 0.005   # 单次成本粗估

    return {
        "precision@10": precision,
        "recall@10": recall,
        "ndcg@10": ndcg_score,
        "p50_latency_s": p50_latency,
        "p99_latency_s": p99_latency,
        "cost_per_request_usd": cost_per_request,
    }

运营指标的重要性远超大多数人的预期。一个 NDCG 涨 2 点但 p50 延迟多 1.5 秒的模型，在多数 C 端产品里都是净亏损——用户流失的速度比排序质量提升的速度快得多。

对话式系统还要额外跟踪：

• 达成满意的轮数：用户接受推荐前要聊几轮
• 每个 session 的推荐多样性：会不会每次对话都收敛到同样那五个物品
• 幻觉率：LLM 多大比例会推荐不在候选集里的物品

常见问题

我到底什么时候才该用 LLM？

至少满足以下一条：(a) 物品文本信息丰富，(b) 有严重的冷启动问题，(c) 需要给用户看的解释，(d) 在做对话式产品。如果一条都不沾，调好的 DCN-V2 或 DIN 在更低成本下能赢任何 LLM。

用 GPT-4 还是微调 7B？

几乎总是该微调。TallRec 和 LlamaRec 都证明，LoRA 微调过的 7B 在推荐任务上能追平或超过 GPT-4 零样本，推理成本只有 GPT-4 的 1%。继续用 GPT-4 的唯一理由是：你完全没有训练数据，或者你的领域漂移得比你能重新微调的速度还快。

怎么避免 LLM 幻觉出不存在的物品？

两层防护：(1) 把 LLM 的输出约束为候选集的索引（[3, 1, 5, 2, 4]，不是标题），(2) 返回前对照候选列表硬校验。如果 LLM 吐出了未知索引，回退到 DNN 排序的顺序。

传给 LLM 的候选集要多大？

经验值是 20-50。低于 20，重排没什么腾挪空间；高于 50，prompt 又长又慢又贵，模型还会丢失中间位置的物品（“lost in the middle” 现象）。

推荐需要 RAG 吗？

有时候需要。当 LLM 需要 prompt 之外的事实性知识时（发售日期、规格参数、当前可用性），RAG 能帮上忙。如果只是从已知目录里做排序，目录本身放进 prompt 就是检索，不需要单独的向量库。

实时 feed 流场景延迟怎么办？

实时 feed（TikTok 那种无限下滑、新闻流）通常承担不起每次曝光一次同步 LLM 调用。可行的模式：(a) 离线高峰外预先算好 LLM 重排结果，缓存起来；(b) 只在第一页用 LLM，后续页用 DNN；(c) 把 LLM 放到离线批处理路径上，给次日推荐用。

多语言目录怎么处理？

LLM 天然能处理——翻译和跨语言推理都内置在里面。陷阱在于：纯英文交互数据上微调，多语言能力会塌掉。要么微调数据里掺一些非英文样本，要么直接微调多语言基座（Qwen、Llama-3 多语言版、mT5）。

总结

LLM 不是在替代推荐系统——它在填补上一代填不上的具体缺口。三种角色干净对应三种缺口：

• 增强器填内容理解的缺口。离线跑、永久缓存，得到更干净的 embedding 和更稳的冷启动。
• 预测器填冷启动和小数据的缺口。微调一个 7B，用它给传统管线产出的 Top-20-50 做重排。
• 智能体填交互的缺口。只在真正的对话式产品上用，并且清楚地知道自己在为延迟买单。

所有生产团队最终都会收敛到的架构是混合管线：ANN 检索 → DNN 排序 → LLM 重排 → 可选的解释生成。它跑得通是因为 LLM 永远只看 Top-50，永远不会看到全量目录。成本有上界，质量拿到 LLM 的语义增益。

从这里开始。第一天就把运营指标和排序指标一起测。把热用户从 LLM 路径上分流出去，让账单不爆炸。一旦攒到几百条带标签的样本，立刻微调。

参考文献

1. Geng, S., Liu, S., Fu, Z., Ge, Y., & Zhang, Y. (2022). Recommendation as Language Processing (RLP): A Unified Pretrain, Personalized Prompt & Predict Paradigm (P5) ↗ . RecSys 2022.
2. Cui, Z., Ma, J., Zhou, C., Zhou, J., & Yang, H. (2022). M6-Rec: Generative Pretrained Language Models are Open-Ended Recommender Systems ↗ . arXiv:2205.08084.
3. Bao, K., Zhang, J., Zhang, Y., Wang, W., Feng, F., & He, X. (2023). TallRec: An Effective and Efficient Tuning Framework to Align Large Language Model with Recommendation ↗ . RecSys 2023.
4. Ji, J., Li, Z., Xu, S., Hua, W., Ge, Y., Tan, J., & Zhang, Y. (2024). GenRec: Large Language Model for Generative Recommendation ↗ . ECIR 2024.
5. Yue, Z., Rabhi, S., Moreira, G. de S. P., Wang, D., & Oldridge, E. (2023). LlamaRec: Two-Stage Recommendation using Large Language Models for Ranking ↗ . arXiv:2311.02089.
6. Gao, Y., Sheng, T., Xiang, Y., Xiong, Y., Wang, H., & Zhang, J. (2023). Chat-REC: Towards Interactive and Explainable LLMs-Augmented Recommender System ↗ . arXiv:2303.14524.
7. Xi, Y., Liu, W., Lin, J., Zhu, J., Chen, B., Tang, R., Zhang, W., Zhang, R., & Yu, Y. (2024). Towards Open-World Recommendation with Knowledge Augmentation from Large Language Models (KAR) ↗ . RecSys 2024.
8. Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2024). Lost in the Middle: How Language Models Use Long Contexts ↗ . TACL.

系列导航

本文是 16 篇推荐系统系列的第 12 篇。