传统推荐系统（协同过滤、序列模型等）主要处理结构化、数值化的数据（如用户ID、物品ID、评分、点击时间）。它们像是优秀的“模式识别器”，但不理解数据背后的语义。

传统推荐系统主要利用用户和物品的ID、数值特征、类别特征等，而LLM-based推荐系统则利用LLM对文本信息的强大理解能力，将用户历史行为（如点击、购买等）和物品的文本信息（如标题、描述）作为输入，通过LLM来理解用户偏好和物品特性，从而进行推荐。

LLM在推荐系统中的优势：

1. 丰富的语义理解：LLM可以理解物品标题、描述中的语义信息，从而捕捉更细粒度的用户兴趣。

2. 零样本/少样本学习能力：预训练的LLM已经包含了大量世界知识，可以在没有或只有少量用户数据的情况下进行推荐。

3. 多任务能力：LLM可以同时处理推荐、解释生成、对话等多种任务。

一. LLM 在推荐系统中的位置

    生成式vs判别式

• 生成式（Generative / GLLM4Rec）：把推荐任务看作“自然语言生成”任务——给模型 prompt，模型生成推荐（标题、query、解释或排序列表）。

• 1. 设计提示（Prompt）： 我们会精心构造一段文字（即Prompt）给LLM。例如：“用户最近购买了《三体》和《流浪地球》。请为他生成5本他可能喜欢的科幻小说书名。”
• 2. 模型生成： LLM根据这个提示，理解用户的兴趣（喜欢科幻），然后直接生成一个文本序列作为回答，例如：“1. 《球状闪电》 2. 《全频带阻塞干扰》 3. 《沙丘》 4. 《安德的游戏》 5. 《你一生的故事》”

• 代表模型/思路：

  • P5: 它将用户行为（点击、购买）、商品信息、评分等统统转换成文本序列，然后让模型执行多种任务，如“评分预测”、“排序生成”、“解释生成”等。它的输出就是一段段文字。

  • GPT4Rec: 顾名思义，利用像GPT这样的模型，通过提示工程直接生成推荐列表或推荐理由。

• 优点：

  • 非常灵活： 不仅可以推荐物品，还能同时生成推荐理由、总结用户画像等。

  • 适合冷启动： 可以利用LLM强大的知识库来推荐训练数据中不存在的新物品。

• 缺点：

  • 难以控制： 生成的列表可能格式不对、包含不存在或重复的物品。

  • 评估困难： 如何衡量生成文本的推荐质量，比衡量一个排序列表更复杂。

• 判别式 / 利用 LLM 作为打分器（Discriminative / DLLM4Rec）：把 LLM 用作理解器/打分器 —— 给出历史与候选列表，LLM 输出对候选的选择/概率或 logits（可以用 verbalizer 把 token logits 转为候选分数）。

• 1. 准备候选集： 系统先通过传统方法（如协同过滤）召回一个候选物品列表（比如100个）。

• 2. 构造判别Prompt： 为每一个候选物品构造一个Prompt，让LLM进行判别。例如：“用户历史：购买了《三体》，浏览了《基地》。候选商品：《沙丘》。问题：用户会对《沙丘》感兴趣吗？选项：A. 是 B. 否”
• 3. LLM输出分数：

  1. 方法A（概率）： 让LLM输出“是”或“否”的概率。选择“是”的概率（如0.95）就作为这个商品（《沙丘》）的得分。

  2. 方法B（Verbalizer）： 这是一个关键技巧。我们定义一个映射（Verbalizer），比如把输出token [是] 的logits值（模型原始输出）映射为分数。这个分数就代表了匹配度。

• 4. 排序： 对所有候选物品重复步骤2和3，得到每个物品的分数，然后按分数从高到低排序，得到最终推荐列表。

• 代表模型：

  • LlamaRec： 是这种范式的典型。它不改变LLaMA模型的结构，就是通过上述方式，利用LLM的理解能力来对候选物品进行重新排序（Re-Rank）。

• 优点：

  • 结果稳定可靠： 输出是一个可排序的分数，易于评估和集成到现有系统中。

  • 充分利用LLM的理解能力： 能深刻理解用户历史和商品描述的复杂语义，做出精准的匹配判断。

• 缺点：

  • 效率较低： 如果候选集很大，需要对每个物品都调用一次LLM，计算成本高。

  • 依赖候选集质量： 如果初步召回的候选集里没有好东西，LLM也无法“无中生有”。

二、LLM推荐系统三种工程常见架构

1. 单阶段（Single-stage, 直接用 LLM）：直接 prompt → 生成/打分（适合研究、解释型应用、小规模）。P5、GPT4Rec 属此类/近似此类。

2. 两阶段（Retrieval + Rerank）：先用轻量检索/召回（ANN/embedding/小模型）取 top-K，再用 LLM 做精排（排序/解读）。LlamaRec、PALR 等典型采用两阶段以平衡效率与精度。

3. 混合/代理式（Agent / RAG / Multi-agent）：LLM 同时作为“决策/规划/解释”引擎，结合检索、知识图谱、外部工具（RAG 模式），用于增强可解释性与知识性推荐。

1. 单阶段（Single-stage，直接用 LLM）

概念：把用户历史、上下文、物品信息全部或部分以自然语言（或结构化 prompt）喂给 LLM，LLM 直接生成推荐项、排序或评分（generation / scoring）。适用于研究原型、解释性强的场景、小规模服务或对实时性要求不高的场景。

（1）数据流与模块

1. 输入序列化（Prompt builder）：把 user profile / history / context / item-catalog 转成 prompt（文本或 json-like tokens）。可以包含约束（数量、时长、语言）、偏好指示、过滤规则（年龄限制、库存）等。

2. LLM 推理：Single pass：直接生成 Top-N 列表 或 对一组 candidate 打分（将 item 列表嵌入 prompt，要求模型打分或排序）。两种常见用法：（1）打分式：把候选列表作为输入，要求模型基于理由对每个 candidate 输出得分。（2）生成式：模型直接输出 item 名称或 id（free-form）。

3. 后处理：解析 LLM 输出（名称到 id 映射、去重、格式校验）。规则过滤（库存、合规、商业约束）。

4. 反馈回环：收集点击/转化信号用于微调或 prompt 调整。

# 生成式 prompt
User: male, 28, 最近看过: [三体, 流浪地球]. 偏好: 科幻, 节奏快.
请基于以上偏好，推荐 5 部可在中国区立即购买的科幻小说。每一项返回：书名 — 推荐理由（1句） — 相关相似项（1个）。

# 打分式 prompt
给定用户历史和下列候选书目 [A, B, C, D, E]，请为每本书输出 0-1 的相似度评分并附 1 条理由。    
格式: id|score|reason

（2）优点

• 简洁：实现快，研究友好。

• 强解释能力：可直接生成自然语言推荐理由，提升可解释性与用户信任。

• 灵活：少量 prompt 变化即可支持多任务（排序、筛选、解释、对话）。

（3）缺点 / 工程挑战

• 成本高：每次请求都调用大模型，推理成本与延迟高（尤其在线服务）。

• 可控性差：生成可能出错（hallucination），难以保证候选集合的覆盖性与约束满足。

• 规模受限：当候选库很大时，无法把全库放进 prompt；需要借助外部检索，否则覆盖率差。

• 一致性/稳定性：不同推理输出可能差异较大，影响在线 AB 测试的稳定性。

---

2.两阶段（Retrieval + Rerank）（工程中最常见）

概念：把系统拆成“召回（Recall）”和“精排（Rerank）”两层。召回用轻量/高吞吐的模型或向量检索从大库取出 top-K；精排用更复杂/昂贵的方法（通常是 LLM 或专用深度排序模型）对这 K 个进行排序与解释。该结构在工业界最常见，兼顾效率与效果。

（1）系统总体架构（数据流）

1. 离线/在线索引构建：对物品做 embedding（文本 embedding、图像 embedding、多模态 embedding），存入向量数据库（FAISS、Milvus、Pinecone）。构建倒排索引 / 元数据索引（category、availability）。

2. 召回层（Recall）：用户向量检索（用户 embedding 与 item embedding 相似度）、基于最近行为的启发式（co-occurrence、item-to-item）、Session-based、协同过滤、CTR 预测粗排（lightweight model）。输出：top-K candidates（K 常见值 50–200）。

3. 特征拼接/候选序列化：将 top-K 的 item meta 与 user context 序列化（可选择只传 id 或传 id + short text）。

4. 精排层（Reranker）：用 LLM（或更小的 transformer 微调模型）对 top-K 做排序、评分或 re-scoring；可在此阶段生成推荐理由。有两种常见精排实现：

   • 逐项打分：对每个 candidate 输出 score，然后按 score 排序（可并行）。

   • 直接生成排序：把 candidates 放进 prompt，让 LLM 按优先级输出排序。

5. 后处理与融合：业务规则、ABP（广告）、去重、多样化重排（re-ranking to increase diversity）。

6. 日志与在线学习：记录 user feedback，定期更新召回器/精排模型。

（2）召回技术细节（常见方法）

• ANN / Vector DB：FAISS / Milvus / HNSW / ScaNN。

• Embedding 源：

  • 文本 embedding（Sentence-BERT、OpenAI embeddings）。

  • 行为模型生成的 embedding（SASRec、BERT4Rec）。

  • Item metadata + knowledge graph embedding。

• 混合召回：并行使用 item-based co-occurrence、category filter、CTR-based candidate generation，再合并去重。

（3）精排（使用 LLM）的实现细节

• 输入设计：传入用户 summary + top-K items (id + short text + metadata) + 排序目标（最大化 CTR、点击概率或用户满意度）。

• 打分策略：可把排序任务转为得分任务：对每个 candidate 要求 LLM 给出 0–100 的符合度分数，并附上 1–2 条简短理由，便于解释与审核。

• 并行化：对 K 个 candidate 并行发起子请求（批量化）或一次 prompt 列出所有 candidate 要求模型逐一评分（要注意 token 上限）。

• 温度与确定性：精排多采用低温度（或 temperature=0）保证输出稳定；或使用 deterministic decoding（greedy）。

（4）优点

• 高效可扩展：召回层通过 ANN 提供高吞吐；精排层只处理 top-K，控制成本。

• 效果好：召回保证覆盖，精排用强模型提高排序质量与解释性。

• 更易控制：业务约束可以放在召回或后处理阶段强制执行。

（5）缺点 / 工程挑战

• 系统复杂度高：需要维护 embedding pipeline、向量 DB、召回逻辑、精排模型、日志系统。

• 延迟管理：精排（LLM）是瓶颈，需做异步化或近似化处理。

• 一致性问题：召回与精排使用不同模型时，可能产生分布不一致（domain shift）。

• 候选缺失风险：如果召回层丢掉好候选，精排再强也无法弥补（召回覆盖是关键）。

---

3. 混合 / 代理式（Agent / RAG / Multi-agent）

概念：把 LLM 当作“决策者 / 协调者 /解释器”，与检索、知识图谱、外部工具（数据库、搜索、业务 API、计费系统等）多方协作。RAG（检索增强生成）是最常见的模式：LLM 生成 query → 向量检索/知识库返回 evidence → LLM 基于 evidence 生成回答/推荐。Agent 或 Multi-agent 更进一步，把不同能力拆成多个 agent（retriever agent、planner agent、filter agent、explain agent），由一个 controller/manager 协调。

（1）架构与模块（Controller + Agents）

1. Planner / Orchestrator（规划器）根据请求类型决定执行流程（哪个 agent 参与、是否需要外部工具）。例如：判断是否需要走知识图谱、是否需要实时库存检查、是否生成解释等。

2. Retriever Agent（检索器）：对接向量 DB、知识图谱、文档库、业务 API，返回可供推理的 evidence（文本片段、facts、item ids）。

3. Reasoning / LLM Agent（推理器）：基于 evidence 和上下文进行推理、生成推荐或生成查询给其他 agent。

4. Filter / Constraint Agent：实时应用商业或合规约束（年龄、版权、地域、促销优先级）。

5. Explain / Dialogue Agent：生成用户可读的解释、对话回应、多轮交互维护 session state。

6. Tooling Layer：日志、监控、审计（记录每一步用到的 evidence，便于可解释性与合规审查）。

（2）RAG 的典型数据流

1. 用户请求 → Planner 判断：需要 RAG（因为需要显式 evidence）。

2. LLM（或 planner）生成检索 query → Retriever 从向量 DB / 文档库检索 top-M evidence。

3. 把 evidence 拼接进 prompt（few-shot / chain-of-thought style），传给 LLM → 生成推荐 + 支持证据 + 排序。

4. Filter agent 应用实时约束，返回最终列表与可视化解释证据。

（3）Multi-agent 特点

• 职责分离：不同 agent 专攻不同能力（检索、规划、合规、会话）。

• 可组合性：新能力通过新增 agent 非侵入式集成（如加入商品可用性检查 agent）。

• 审计与可解释：每个 agent 的输出可以记录，便于回溯「为什么被推荐」。

（4）优点

• 高可控与可解释：RAG 提供的 evidence 可用于支持解释，agent 日志便于审计。

• 能力强：能够同时利用大规模知识库、业务数据与 LLM 的推理能力。

• 灵活性：可以调用外部工具（实时库存、价格、预测服务），解决 LLM 存在的「时效性」和「知识过期」问题。

（5）缺点 / 工程挑战

• 系统复杂度极高：多个 agent、跨服务调用、状态管理、事务一致性问题。

• 调度与延迟问题：多个步骤（检索→推理→检索→推理）会增加延迟，需做并行化与超时控制。

• 一致性与错误传播：一个 agent 的错误（如检索返回错证据）会影响最终输出，需健壮的证据校验。

• 成本控制更难：多次调用 LLM 或多个 LLM/工具混合使用会增加费用。