从workflow到attention结构：全栈RL优化LLM的一个设想

一个有意思的设想：把强化学习（RL）不只是用在 LLM 参数优化上，而是贯穿从模型架构到应用层的全链路。

OpenAI o1 和 DeepSeek R1 已经证明了 post-training 阶段 RL 的价值。但作者认为 RL 的优化范围可以更广——从应用层的 workflow 到模型内部的 attention 结构，都可以纳入 RL 的优化目标。

应用层：workflow 也可以被 RL 优化

从 API 往应用层看，多步骤的 workflow 完全可以纳入 RL 过程，直接针对多轮交互后的业务 reward 进行学习。如果多个节点使用同一个 LLM，RL fine-tuning 时的显存占用会更小。

另一个实际问题是 context 长度。模型搜索到大量网页后，是不是所有网页内容都应该塞进 context？作者认为应该有一个独立的网页筛选组件，从搜索结果中召回相关内容放入 context。这个组件本身也可以被纳入 RL 过程优化——它是一个 tool，但这个 tool 的实现逻辑也需要被优化。

模型层：attention 结构也可以被 RL 优化

这是文章最有意思的部分。

目前各种稀疏注意力、线性注意力、混合注意力方案（DeepSeek 的 NSA、MiniMax、Moonshot 各有不同），在设计上多少有些"炼丹"的味道。作者提出：能不能把 attention 结构本身也纳入 RL 的优化过程？

具体方案针对 Long Context（>200k）+ MoE 架构：

核心观察：LLM 在 decode 过程中，依赖的 context 具有局部性——相邻的 token 大概使用相近的 context。DeepSeek NSA 中的粗粒度 context block 召回就利用了这个特性。

MoE 层面的局部性：目前 MoE 的 Expert 是基于 token 的，不是基于"完整语义单元"的。一段完整语义可能被拆分到多个 Expert。但从认知角度看，把同样能力聚合到少数 Expert 上更合理，而且可以增强 Expert 候选集在 token 生成过程中的局部性，减少 Expert 切换。

两层召回设计：

• 第一层：和现有方案相同，直接用于当前 decode token 的 context block 和 Expert 召回
• 第二层（新增）：训练目标是召回未来 W 个 token 需要的 context block 和 Expert。推理时两层都参与计算

关键机制：如果第二层候选元素的 score 超过阈值（说明序列生成正在脱离当前局部性环境），就在下一个 token 计算时重新触发更大范围的召回。

训练上有个巧妙的处理：计算每个 token 时不知道别的位置 token 的召回情况，所以在每次整个序列计算后增加一个汇总环节，把其他位置的 token 召回情况作为当前位置第二层召回的拟合目标。

分阶段实施

Pretrain 阶段用监督学习的方式训练两层召回组件（增加的过程开销可控）。Post-training 和 RFT 阶段，再对第一层召回选择组件、第二层召回选择组件、触发全局重新召回的判定组件等，针对目标 reward 进行 RL 学习。

这样就在 LLM 模型内部增加了可以被 RL 直接优化的部分，实现计算成本的优化。而且这种优化是单纯靠 LLM 参数优化做不到的——因为你需要的是"什么时候该换 context"的决策能力，而不是更多参数。