企业官网建设流程全解析

1. 问题定义：一屏结果背后的优化难题

最近在系统整理列表推荐方向的论文时，LIRD 这篇给我留下的印象最深。原因很简单：它把“推荐一个列表”这个我们天天在做的事，真正等价成了一个深度强化学习问题，而不是停留在“用精排分数排序然后截断”的套路里。也许你和我一样，实际业务里早就发现：用户看到的永远是一个页面，不是一个 item；你精排模型打分再准，组合出来的列表仍然可能很糟糕。LIRD 想解决的就是这一层问题——从列表整体收益出发，用深度 RL 来生成一个完整的、有序的推荐列表。

这篇论文适合两类人读。一类是做推荐排序、重排的工程同学，尤其是正在被“精排分数高但业务指标没涨”困扰的；另一类是想理解深度强化学习到底怎么在推荐系统里落地、而不是停留在 CartPole 和 Atari 的算法同学。读 LIRD 不需要很强的 RL 基础，只要理解 MDP、Q 学习的基本概念就够了，但读完之后能带走的东西很具体。

什么叫做“列表推荐”和普通推荐不同？我的理解是，列表推荐的目标不是单独估计每个 item 的点击率，而是给定一个用户，直接选出 K 个 item 组成一整个有序列表，让这整个列表带来的总收益最大。这个目标的数学形式和单点排序完全不同：单点排序只需要回答“这个 item 在这个用户面前值多少分”，列表推荐要回答的是“这 K 个 item 放在同一个页面上、按这个顺序排列，整体能带来多少价值”。

这背后有三个实际因素在起作用。第一个是位置偏差，用户注意力天然递减，第一个位置和第五个位置的曝光价值差异巨大；第二个是列表内部的相互作用，比如三个相似款手机同时出现会让用户产生“怎么全是这些”的疲劳感，而手机加耳机加壳的组合更容易促成决策；第三个是用户行为是序列化的，用户会浏览、比较、点击、离开，整个过程中用户的兴趣状态也在改变。这三个因素决定了，单点独立打分再排序的做法，在结构上就有天花板。

1.1 单点打分为什么优化不了整个列表

我经常用一个例子来说明这个问题。假设精排模型给出的相关性分数是：手机A 0.95，手机B 0.93，手机C 0.90，耳机D 0.88，手机壳E 0.85。如果按精排分数截断，列表就是 A、B、C 三款手机。用户可能确实点击了 A，但看一眼 B 和 C 之后觉得重复度过高，没有再点，整体页面收益反而低。但如果列表是 A、D、E，用户可能会点 A 之后再点 D、E，虽然每个 item 的单点分数不是最高的，但页面总收益更高。

这就是 pointwise 和列表级优化的本质差异。pointwise 排序的最优解只是“每个位置独立放置最高分 item”的最优解，它假设每个位置上的收益是独立可加的。但真实用户行为不是这样的，位置与位置之间存在相关性，item 之间的相似度、对比关系、互补关系，都会影响整体收益。LIRD 这篇论文最大的出发点，就是不再回避这种相关性，而是把列表当成一个整体决策对象来处理。

1.2 列表推荐的组合爆炸问题

单点排序只需要给 N 个候选各打一个分，复杂度是 O(N)。列表推荐要选出一个有顺序的 K 长度列表，候选集就算只有 50 个，K 为 6，排列空间也是 P(50, 6)，这个量级是千万级别往上。传统的穷举或动态规划很难处理，因为价值函数本身不是简单可加的。

强化学习在这里的优势是天然处理多步决策。LIRD 的思路是把列表生成过程拆成 K 步：每一步只决定当前这个位置放哪个 item。这样的动作空间从“排列空间”降成了“每一层的候选选择空间”，复杂度是 K × N，而不是 P(N, K)。当然，这背后还需要解决一个关键问题：每一步的局部决策如何保证全局列表最优？这就引出了奖励分解和值函数设计。

1.3 列表推荐必须面对的三个难点

我把整篇论文读下来，归纳出作者们在解决的三件事，这也是列表推荐用 RL 落地时绕不开的三个坎。

第一是状态表示。列表是逐步生成的，所以状态不但要包含用户信息和候选集合，还要包含“已经选了哪些 item”。如果不把已选列表放进状态，模型就无法感知重复度、覆盖度这些列表级特征，本质上还是在单点打分。

第二是奖励建模。真实用户反馈发生在完整列表展示之后，而且是很稀疏的点击和购买。如果只拿最终整体收益当作奖励，每一步选 item 时根本不知道这个 item 到底对整体收益贡献了多少。LIRD 做了奖励分解，把整体反馈分解到每个位置，让每一步都有可学习的监督信号。

第三是训练稳定性。深度 RL 本身训练就容易波动，加上推荐系统中的 action 空间大、反馈噪声大，如果奖励尺度不一致、目标网络更新太快，训练基本会崩。这个在后面的实操部分会重点展开。

这三个难点并不是 LIRD 独有的，但 LIRD 给出的解法组合比较有代表性：状态里带已选列表，动作逐位置生成，奖励按位置分解，用深度值网络学习。整篇论文围绕这套框架展开，读的时候如果抓住这三条线，后面会顺很多。

2. LIRD 核心方法拆解：把列表生成改成 MDP

LIRD 的方法框架，我用自己的话概括是这样：把生成一个 K 长度列表的过程，建模成一个 K 步马尔可夫决策过程。在第 k 步，智能体看到当前状态——用户画像、候选集合、以及已经选好的前 k-1 个 item——然后从候选集合里选一个 item 放到第 k 位。等完整列表生成之后，用户对列表产生反馈，把反馈分解成每个位置的奖励，再拿这些奖励更新模型。

2.1 状态设计：用户、候选和已选列表三者缺一不可

状态表示是整个模型里最容易做错的地方。我见过不少列表推荐模型，状态里只放了用户 embedding 和候选 item embedding，没有放“已经推荐的列表”。这在数学上等于假设每个位置的选择互相独立，那 RL 就退化成了逐点贪心。

LIRD 的状态设计里，已选列表是核心组成部分。具体怎么编码已选列表，论文里的做法可以理解成对已有 item 的 embedding 做聚合，比如取平均、最大池化或者用一个小型 attention。我在工程上更推荐用 attention 或者带位置编码的 transformer encoder 来对已选列表做编码，因为前几个位置的 item 对当前决策的影响肯定比后面位置的 item 更大，平均池化会丢失这种顺序信息。

用户侧的编码就是常规操作，把用户历史行为序列、静态属性、上下文特征 embedding 到一起。候选集合的处理通常不会把全部候选塞进状态，因为状态维度会爆炸。实际常用的是对候选集合做一个初步粗排，截断到几百个，然后在这个范围内做列表优化。

2.2 动作空间：逐位置选择，而不是一次性输出整个列表

LIRD 的动作设计是逐位置选择的。给定状态 s_k，动作 a_k 就是从候选集合中选择一个尚未被选中的 item。这一步其实非常符合人做推荐的直觉：填第 3 个位置的时候，你已经知道前 2 个位置放的是什么，所以可以避开重复、考虑多样性。

这个设计对强化学习来说有一个巨大好处：避免了输出整个排列带来的组合爆炸。如果让模型直接生成整个列表，动作空间的维度是 K × N，而且存在大量顺序等价的冗余；逐位置选择让动作空间变成 N，配合状态里的已选列表信息，模型可以用 Q 网络给每个候选 item 算一个值，然后取 top-1 或者 top-k。

值得注意的是，逐位置选择并不等于贪婪。因为每一层选择只考虑当前位置的 Q 值最大化，但 Q 值本身是通过贝尔曼方程学习到的，它已经包含了未来位置的信息。所以我实际看论文时的一个体会是：Q 网络如果训得好，每一步的 argmax 就已经隐式考虑了剩余位置的收益，不需要额外做一个序列规划模块。

2.3 奖励分解：列表级反馈如何变成逐位置监督

这是 LIRD 最有借鉴价值的一部分。真实场景里，用户看完一个长度为 6 的列表后，可能点了第 1 个和第 4 个，买了第 4 个。如果我们把“点击 + 1，购买 + 3”的总收益作为整个列表的奖励，然后给所有 6 步共享同一个 reward，那第 2、3、5、6 个位置的选择就完全没有局部监督，模型的 credit assignment 会非常困难，训练基本训不动。

奖励分解的思路是：把列表级的总反馈，按照每个位置的实际反馈拆开。比如用户点了第 1 个 item，那么第 1 个位置获得点击奖励；第 4 个 item 被购买，第 4 个位置获得购买奖励；未被点击的位置奖励为 0 或者一个小的惩罚。这样每个位置的决策都能直接从用户反馈里拿到对应的监督。

不过这里有个容易误解的地方。奖励分解不等于把列表优化问题拆成 K 个独立的单点优化问题。单点优化只看当前位置的即时奖励，而 LIRD 的 Q 函数仍然是一个多步累积回报，当前位置的动作会影响后续状态，后续状态又会影响未来所有位置的奖励。分解的是 reward，不是 return。整条轨迹的折扣累积回报依然把每个位置关联在一起，这才是 RL 的意义所在。

我在自己的列表重排项目里实际实现时，采用的奖励设计是：

• 曝光但未点击：0
• 点击：+1.0
• 加入购物车或收藏：+0.5，可叠加
• 购买：+3.0
• 位置折扣系数 gamma 取 0.9 左右

这样设计的好处是奖励尺度可控，不会因为购买事件太稀疏导致训练信号完全被点击主导，也不会因为购买权重太高让模型只盯着少数高价值 item。

2.4 价值网络与训练目标：DQN 框架下的操作

LIRD 的价值网络本质上是一个 Q 网络。输入是状态编码（用户 + 候选集合 + 已选列表），输出是每个候选 item 对应的 Q 值。训练目标就是常见的贝尔曼误差：

对于每一步生成的 (状态, 动作, 奖励, 下一状态) 元组，目标值等于即时奖励加上折扣后的下一状态最大 Q 值。这里下一状态是把当前选中的 item 加入已选列表之后的状态。因为逐位置生成时，每一步动作都会改变状态，所以天然构成了一个完整的 MDP 轨迹。

实现上的几个要点我总结一下，论文里不一定面面俱到，但这是我复现这类模型时确认过有必要的配置：

• 使用 Double DQN 而不是普通 DQN，缓解 Q 值过估计。推荐系统里动作价值普遍偏高，不用 Double DQN 的话列表质量会明显下降。
• 目标网络更新频率放慢，比如每 1000 步同步一次，或者用软更新 tau=0.01，训练稳定性会好很多。
• 经验回放一定要按整条轨迹存，而不是按单步存。因为推荐列表的每个位置是在同一个用户、同一个候选集合下生成的，拆散之后状态分布会被破坏。

我简化一下训练伪代码，帮助想要动手复现的同学理解整体流程：

# 列表生成阶段：逐位置选择 def generate_list(q_net, user_state, candidates, top_k, epsilon): prefix = [] for k in range(top_k): state = encode(user_state, candidates, prefix) # 状态包含已选列表 q_values = q_net(state, candidates) # 每个候选一个 Q 值 action = epsilon_greedy(q_values, epsilon) # 探索或利用 prefix.append(action) return prefix

# 训练阶段：奖励分解 + 贝尔曼更新 for state, action, reward, next_state in replay_buffer.sample(batch_size): target = reward + gamma * max_a q_target(next_state, a) loss = mse(q_online(state, action), target.detach()) optimizer.zero_grad() loss.backward() optimizer.step()

这段代码省略了候选 mask、Double DQN 的 argmax 选择等细节，但核心骨架就是这样。理解了这个骨架之后，读论文里的网络结构细节会轻松很多。

3. 用户模拟器：RL 训练里绕不开的组件

读列表推荐方向的 RL 论文，你很快会发现一个共同点：几乎所有方法都依赖一个用户模拟器。LIRD 也不例外。原因很简单，真实系统不可能让一个刚初始化的 RL 策略在线试错几万次，成本太高，用户体验也扛不住。模拟器的作用是给定一个用户状态和一个推荐列表，生成用户的点击、购买、跳过等反馈，以及更新后的用户状态。

3.1 为什么模拟器决定了 RL 项目的成败

这句话我强调多少遍都不过分。RL 智能体是在和模拟器的交互中学习策略的，模拟器的准确度直接决定了学出来的策略在真实环境里的表现。我见过一个项目，模拟器用简单的独立点击模型，结果训练出来的策略疯狂推荐冷门 item——因为模拟器里冷门 item 的点击概率被建模得太高了。上线之后效果崩得非常彻底。

LIRD 这一类论文在实验里使用模拟器，通常会把模拟器抽象成两部分：一个是点击模型，根据用户和 item 的特征预测曝光后点击的概率；一个是反馈模型，在点击发生后预测购买、加购等后续行为的概率。这两部分不会只是简单的逻辑回归，大概率会包含用户历史行为序列的建模，用来模拟用户兴趣的动态变化。

实际做工程的时候，我建议模拟器的精度不要追求绝对准确，而是要尽量保留“相对序”的正确性。什么意思？模拟器里 item A 点击率大于 B，这个相对关系要大致符合真实数据；具体到某个用户身上点击率是 0.31 还是 0.34，并不那么重要。相对序正确，RL 学到的策略排序才可信。

3.2 用历史日志构建反馈模型

如果把 LIRD 的方法落地到自己的推荐系统里，最现实的路径是从历史日志训练模拟器。具体做法分三步。

第一步，采样曝光日志。日志里有用户、候选 item、展示位置、是否点击、是否购买。注意这种日志是旧的推荐策略产生的，存在严重的曝光偏差——没有被推荐过的 item 根本没有机会被用户看到，也就没有反馈记录。

第二步，修正曝光偏差。如果直接拿日志训练点击模型，位置靠前的 item 点击率会被系统性高估。常用方法是加位置特征，让模型学会区分“因为位置好所以被点击”和“因为内容相关所以被点击”。更严谨一点可以做逆倾向得分加权，但工程上先加位置特征通常就能解决大部分问题。

第三步，训练点击和购买预测模型。这个模型不是最终推荐模型，而是模拟环境的反馈函数。可以用梯度提升树或者深度模型，输出点击概率和购买概率。在使用的时候，根据概率采样一次，作为用户的反馈。

我在自己的模拟器里还会加一个多样性因子：如果当前候选 item 和已展示的前几个 item 相似度很高，点击概率会被调低。这个机制不是为了模拟器更像真实世界，而是为了让 RL 训练出的策略不会疯狂刷相似 item。没有这个机制，策略很容易钻空子。

3.3 模拟器和智能体的交互流程

LIRD 的训练流程可以理解成一个闭环：环境重置一个用户，智能体逐位置生成列表，模拟器返回每个位置的反馈，反馈分解成奖励，智能体更新，然后重置下一个用户。这个流程看起来简单，实操中有几个细节容易被忽视。

第一个细节是，模拟器和智能体不能同步频繁更新。模拟器应该在一段时间内保持冻结，比如每训练 1000 步才重新校准一次，否则模拟器参数一动，智能体面对的奖励函数就变了，之前学到的东西全部作废，训练会产生剧烈震荡。

第二个细节是，模拟器的随机种子要可控。同一个策略在相同种子下重复评估，结果应该一致；不同种子下的方差要记录。这样才能在调参的时候区分“策略变好了”和“这次随机种子运气好”。

第三个细节是，探索策略要在训练后期取消。训练初期 epsilon 可以设到 0.3，让智能体多尝试不同的 item；后期应该降到 0.05 以下，让训练数据尽量集中在当前最优策略附近，否则最终评估的列表质量会被随机探索拉低。

4. 离线评估与实验观察：怎么证明 LIRD 真的有效

读 RL 方向的推荐论文，最需要带着批判眼光看的就是评估部分。因为离线日志来自旧策略，你无法直接拿新策略去重新曝光给用户获取反馈，所以离线评估天然存在偏差。LIRD 这类论文通常采用模拟器评估加离线指标两部分，要理解它的有效性，需要看几个维度。

4.1 列表级指标 vs 单点级指标

传统排序指标比如 AUC 是针对单点预测质量的，它衡量的是“模型预测点击率排名和真实点击是否一致”。但 LIRD 优化的是列表整体收益，单一位置的预测准确率不是核心目标。论文实验部分通常会更关注 nDCG、Recall@K、MRR 这类列表级指标，以及模拟的累积奖励。

这里面我要提醒一个问题：nDCG 本身有一个隐藏假设，它假设每个文档的相关性是独立的，相关性越高排越前就越好。但真实列表推荐中，两个 item 单独看都相关，放在一起可能互相挤占点击，整体收益反而不如一个相关一个互补的组合。所以 nDCG 提升并不完全等于列表收益提升。看论文的实验结果时，我更关心模拟器里的累积奖励，以及消融实验的结果。

4.2 消融实验是最值得读的部分

一篇 RL 推荐论文如果只报最终指标，没有消融，我基本会怀疑它的可信度。LIRD 的方法有三个核心组件：逐位置动作分解、状态里带已选列表、奖励分解。理想情况下，作者应该分别去掉这三个组件做对照。

我判断的标准是这样：

• 去掉奖励分解，只保留列表级总奖励，模型还能不能训出来？如果训不出来，说明 reward decomposition 起到的是训练稳定器的作用。
• 去掉状态里的已选列表，模型是不是退化成了贪婪的单点选择？如果指标没有明显下降，说明列表级状态没有真正生效，方法本质上是伪列表优化。
• 把逐位置选择换成一次性生成整个列表，训练和评估的结果是否更差？这会验证动作分解的必要性。

读论文的时候如果这些对照都存在，方法可信度就高很多。如果没有，只能说明作者还没有完全证明各组件的必要性，后续自己复现时要多加验证。

4.3 在线 A/B 视角的补充

论文里通常不会详细讨论在线 A/B 的问题，因为 RL 策略的在线评估确实难做。但如果你打算把 LIRD 的方法落地，在线 A/B 实验的设计要先想清楚。

建议的做法是：不要一次性把线上精排换成 RL 生成，而是把 LIRD 作为一个重排模块，在精排结果的基础上做小规模列表优化。这样即使 RL 策略出现问题，影响范围也控制在最后几步，可以被业务规则兜底。同时，A/B 实验要设置足够的观察期，RL 策略有一定的探索成本，头几天指标可能不升反降，需要给探索衰减留出时间。

我个人的经验是，RL 推荐策略的线上评估周期至少是一到两个完整用户生命周期。比如说用户平均 7 天会再次回访，A/B 至少要跑 14 天以上，才能看到 RL 策略在“长期用户满意度”上的效果，而不是只看首屏点击率。

5. 从论文到工程：落地 LIRD 的经验与避坑指南

论文读完，关键问题永远是：这方法我能用吗？怎么用？我在这部分会讲一些我在实际列表优化项目里的落地经验，不一定和 LIRD 的论文细节一一对应，但思路是通用的。

5.1 哪些组件可以直接抄，哪些要改造

LIRD 里最可以直接拿走的组件是奖励分解的思路。不管你最终用不用 RL，把列表整体反馈分解成每个位置的奖励，这个思维本身就很有价值。它迫使你把“这个 item 对这个位置贡献了什么价值”这个问题想清楚，而不是笼统地用列表整体指标做优化。

逐位置动作分解也值得借鉴，但代价较高，因为这意味着你要维护一个多步决策的状态表示。如果团队资源有限，一个务实的过渡方案是：状态里只拼接已选 item 的 embedding 均值，价值网络用一个小型 MLP，不做复杂 attention。先用最简单的方式把 RL 链路跑通，再逐步升级状态编码。

候选集合的处理建议直接改造。真实系统不可能像论文实验那样面对很小的候选集。我的做法是：先让精排模型输出 top 50 的候选，LIRD 只在这 50 个里面选 6 个。这样动作空间被大幅缩小，训练稳定性和推理速度都可控。

5.2 一个可落地的训练流程

如果你打算在真实业务里复现 LIRD，我建议按下面这个顺序推进，每一步都验证可行后再进下一步。

第一步，离线模拟器建设。用历史日志的点击购买样本训练模拟器。这一步先不要急着训练 RL，先用一段随机策略采集模拟器的交互数据，看看模拟器产生的点击率分布和真实日志是否接近。

第二步，规则策略基线。在模拟器里跑几个基线，比如精排截断、MMR 多样性重排、DPP 重排。记录它们的列表级收益。这一步很重要，因为后面 RL 策略的效果要跟这些基线比，如果连基线都打不过，说明问题不在算法，而在奖赏设计或者状态表示。

第三步，训练 LIRD。按照前面说的 DQN 加奖励分解的框架训练。训练中密切关注 Q 值分布：如果 Q 值整体漂移严重，检查奖励尺度；如果 loss 不降，检查奖励是否太稀疏。

第四步，离线批量评估。用训练好的策略在模拟器的固定测试集上生成列表，计算 nDCG 和累积奖励。和基线对比，确认提升幅度再说上线。

第五步，小流量上线。用精排加 LIRD 重排的方式做 A/B 实验，观察点击率、转化率和用户回访。

这个流程我在多个推荐场景里验证过，核心思想是：先确保环境模拟可信，再确保基线对比清晰，最后再谈 RL 上线。

5.3 常见问题速查表

我把实际踩过的坑和排查思路整理成了一张表，方便你对照自查：

这里我想特别展开讲一下“模拟器过拟合”的问题，因为这是最容易踩、也最致命的坑。训练中如果发现 RL 策略在模拟器上的累积奖励一直在涨，但你心里清楚这个策略在真实场景里不可能成立——比如它疯狂推荐模拟器中点击概率最高的几个 item，甚至不顾业务规则——那就是典型的模拟器过拟合。对策有两个：一是降低模拟器的确定性，给反馈函数加噪声；二是定期人工审核策略在真实日志上的行为分布，如果和日志分布差异过大，立即冻结训练。

5.4 从 LIRD 到自己的推荐架构

最后说一点架构层面的想法。LIRD 这类方法不适合替换召回和粗排，最适合的位置是精排之后的重排环节。原因是召回和粗排主要解决“从千万级候选里找几百个相关 item”的问题，这种开放域动作空间对 RL 来说成本太高；而重排面对的是已经筛选过的、规模可控的候选集合，动作空间小，列表目标清晰，正是 RL 能发挥优势的场景。

我通常会把系统的最后一段设计成：精排输出 top 50，用业务规则过滤掉硬性不推的 item，然后 LIRD 在这 50 个候选中选出 6 个有序列表。这样做的好处是，即使 RL 策略在某次更新中出了问题，最坏的情况也只是最后 6 个结果顺序异常，不会导致整个推荐链路崩溃。

状态表示上，除了论文里的用户和已选列表，我强烈建议把“当前列表已经用了多少个品类”“已经推了多少个相似 item”这类统计特征加进去。这些特征看似手工，实际能大幅加速收敛，因为在列表生成的早期，模型就知道不能连续选同一品类的 item，不需要通过大量试错去学这件事。

6. 最后聊聊我读完这篇论文的实际体会

LIRD 这篇论文给我最重要的启发，不是某个网络结构，而是“把列表生成当序列决策，再把序列奖励分解到每一步”这个建模视角。实际推荐系统里，我们太习惯把排序看成一次打分，把结果截断成列表，但用户的交互本质上是多步的：看第一个位置，决定要不要往下滑；看到第二个位置，和第一个位置比较；看到第三个位置，可能已经形成了对整个页面的印象。这种序列交互，用 pointwise 模型确实很难刻画，而 RL 提供了一个自然贴合的框架。

在我自己动手实现类似方案的过程中，感受最深的一点是：奖励分解和模拟器建设的功夫，远比网络结构本身重要。网络结构选 DQN 还是别的，其实差别没有想象中那么大；但奖励尺度设计不好，模拟器反馈有偏，训练出来的策略就是废的。如果你准备尝试论文里的方法，我建议先从这两个地方入手，先把模型训练稳定，再谈效果优化。

另外还有一个细节，就是不要一开始就把目标设成“替换整个排序链路”。LIRD 这类方法最务实的用法，是在精排之后做小规模重排优化，让 RL 去处理最需要序列决策的那一小段。这样风险小、见效快，也能让团队逐步积累 RL 的训练和评估经验。

如果你也想在自己的列表推荐场景里尝试 LIRD，我个人建议的第一步是：先拿过去一周的曝光日志，训练一个简单的点击模拟器，然后把当前线上策略作为基线，在模拟器里跑一遍列表级收益。先看清楚效率和问题，再决定要不要上深度 RL。很多时候，这个诊断过程本身就能帮你找到不少优化空间。