尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

强化学习与控制理论:从序列决策到工程落地的系统对照

强化学习与控制理论:从序列决策到工程落地的系统对照 我先把观点放在前面强化学习Reinforcement Learning本质上是一种数据驱动的最优控制方法控制理论则可以给强化学习提供分析工具。很多人觉得 RL 就是黑箱控制就是个正在被取代的旧学科这个判断我不同意。做控制的人看到 RL第一反应往往会问“被控对象是什么模型方程在哪”做 RL 的人看到控制论文第一反应往往是“这个算法能不能直接跑我的环境”。这种对话很容易变成两个领域各说各话。如果把两个框架平铺开来看会发现它们解决的问题在结构上非常一致。控制理论关心的是面对一个动态系统如何按照某个目标在有限或无限时域内生成一组控制序列。强化学习关心的是Agent 如何在一个动态环境里通过观察状态、执行动作、接收奖励逐步学到让累积回报最大化的策略。本质上都是在动态系统上做序列决策只是假设条件、求解路径和工程习惯很不一样。这篇文章会绕开“谁替代谁”的争论重点拆三件事RL 和控制理论到底对应在哪些地方、经典控制方法如何理解 RL、以及真正把 RL 用到实际系统时应该按什么顺序推进。适合正在做机器人、自动驾驶、工业过程控制或者刚接触深度强化学习的读者。如果只记一个结论我建议记这个先想清楚自己在求解哪个优化问题再决定用哪个工具箱。1. 先看清底层问题RL 和控制都在求解同一个“序列决策问题”1.1 从动态系统到马尔可夫决策过程控制理论的标准出发点是状态空间模型。系统状态记作 (x_{k})控制输入记作 (u_k)系统转移关系写成[x_{k1}f(x_k,u_k)]你的任务是设计一个控制律让系统在满足约束的前提下从某个初始状态出发把长期代价降到最低。RL 的标准出发点是马尔可夫决策过程也就是 MDP。它通常写成五元组状态、动作、转移概率、奖励、折扣因子。Agent 每一步观察状态选择动作环境返回下一个状态和奖励目标是把累积折扣奖励最大化。从结构上看两者对应关系非常明显状态 (s_t) 对应系统状态 (x_k)动作 (a_t) 对应控制输入 (u_k)状态转移概率 (P(s_{t1}|s_t,a_t)) 对应系统方程 (f)奖励 (r(s_t,a_t)) 对应“负的代价”策略 (\pi(a|s)) 对应控制律 (uKx)。所以做控制的人学 RL第一步不需要背新概念而是先做平移。状态转移矩阵、可控性、可观性在 MDP 里都有对应物只是表达方式不同。真正需要额外补充的是随机策略、价值函数逼近、策略梯度、经验回放这些围绕“数据采样函数逼近”建立起来的工具。1.2 真正的差异在假设和求解路径框架虽然相似但 RL 和控制理论在几个关键假设上分道扬镳。第一模型可知性。经典控制通常假设系统方程已知至少有一个足够准的标称模型。你可以用模型做预测、做滚动优化、做稳定性分析。RL 很多时候直接跳过模型从交互数据里学策略。好处是能在难以建模的对象上工作代价是样本效率低、训练不稳定、很难给出可靠的性能保证。第二约束处理方式。控制理论里的约束是硬约束执行器饱和、状态限幅、安全边界一般直接写进优化问题。RL 里约束通常只能折算成奖励惩罚项碰了边界给负奖励让它少走危险路。这样不够可靠因为奖励惩罚是软约束训练时满足不代表部署时满足。第三求解工具。控制理论依赖凸优化、动态规划、黎卡提方程这类结构化方法结果可复现、可分析。深度 RL 依赖采样、梯度下降和函数逼近训练过程随机性大超参数敏感。两者各有边界不是谁简单替代谁的问题。2. 从控制理论进入 RL四个最容易对应错的概念2.1 状态、动作和观测不是完全一样的东西教科书通常把 RL 的状态 (s_t) 和控制的系统状态 (x_k) 对应方向没有错但实际工程里容易踩坑。控制理论里的状态往往是物理量位置、速度、电流、温度。这些量有明确单位能放进状态方程里做预测。RL 里的状态很多时候是观测值图像、点云、编码后的特征。系统内部状态可能无法直接测量你拿到的只是传感器读数。这个时候问题就从 MDP 变成了部分可观测马尔可夫决策过程也就是 POMDP。很多做控制的同学入门时没意识到这一点把当前时刻的传感器读数当成全部状态策略学出来很毛糙。更稳的做法是把历史信息、状态估计器输出一起拼进观测。比如用卡尔曼滤波或状态观测器估计内部状态再把它作为 RL 输入的一部分。动作和控制输入也有偏差。控制律一般是确定性映射给定状态输出一个明确控制量。RL 策略可以是随机策略输出一个动作分布然后从分布里采样。训练时随机性很重要它保证探索部署时通常再把随机性去点或者只保留很小噪声。2.2 奖励函数就是“倒了符号”的代价函数控制理论里的代价函数有清晰物理含义跟踪误差积分、控制能量、超调量。RL 里的奖励函数则更像“设计者拍出来的反馈信号”。我见过很多 RL 入门者犯同一个错误把奖励当成绩分随意填一个数值结果训练曲线不收敛也不知道该调什么。更稳的转换思路是先用控制语言定义清楚目标误差多小、能耗多低、超调多少。把目标拆成几个可计算的项。每一项乘一个系数再把整体取负号变成奖励。奖励的尺度和项与项之间的相对权重直接决定优化方向。这和控制律参数整定很像。差别在于控制器的参数变化影响稳定裕度奖励权重变化影响的是价值函数梯度和策略收敛方向更难以直觉判断。2.3 价值函数、策略与控制律的对照贝尔曼方程描述的是当前状态的价值等于当前奖励加折扣后的下一步价值。很多人把它看成动态规划在随机系统里的形式。控制理论里也有类似递推关系最优控制的 HJB 方程就是连续时间版本的贝尔曼方程。当你在 RL 论文里看到 (V(s)) 和 (Q(s,a))不要觉得陌生。(V) 表示从这个状态出发能拿多少累计回报(Q) 表示在这个状态执行这个动作能拿多少累计回报。策略就是控制律确定性策略相当于状态反馈随机策略相当于带探索的平滑状态反馈。在无限时域最优控制里值函数也常被用作李雅普诺夫函数候选。这一点在后面谈稳定性时会特别有用。2.4 概念对照表RL 术语控制理论对应概念备注状态 (s_t)系统状态 (x_k)RL 中常为观测或部分观测动作 (a_t)控制输入 (u_k)RL 可输出动作分布策略 (\pi(as))控制律 (uKx)奖励 (r(s,a))负代价函数 (-L(x,u))奖励设计是难点折扣因子 (\gamma)无限时域折扣代价影响远期目标权重价值函数 (V/Q)最优值函数常可作为稳定性候选状态转移 (P)系统方程 (f)有模型 / 无模型选择每次训练不收敛的时候可以按这张表逐行检查状态有没有拿全动作输出范围对不对奖励是否和任务目标一致折扣因子推得够不够远。大部分训练问题都能落到其中某一项。3. 从 RL 回头看控制MPC 为什么像滚动规划的 model-based RL3.1 滚动优化和在线规划MPC 的基本流程是每个控制周期基于当前状态和系统模型求解一个有限时域最优控制问题得到一段控制序列然后只执行第一步。下一个周期把优化窗口往前推重新求解一遍。这个流程放到 RL 语境里其实就是“有模型 在线规划”。当前状态作为输入转移模型预测未来轨迹优化器选择使累积代价最低的动作序列执行后重新规划。差别只在求解时用的是数学规划器还是学习到的策略网络。机器人控制里很多基于模型的 RL 方法就是这条路用数据学一个局部动态模型采样出多条轨迹用 MPC 或采样优化挑一条代价最小的执行再更新模型。这套组合天然比纯无模型 RL 稳因为它在每步决策时真的知道未来大概会发生什么。3.2 模型误差是所有基于模型方法共同的坎MPC 的优势是能显式处理约束硬约束下的可靠性较高。代价是依赖模型准确度。模型一旦因为摩擦、负载变化、环境干扰而偏离真实系统预测就会偏离闭环表现就会恶化。基于模型的 RL 同样受这个问题困扰。学习出来的模型通常会带来两类误差一是训练数据分布和部署数据分布不一致时的外推误差二是把复杂非线性近似成神经网络后不可避免的拟合误差。MPC 遇到模型误差可以靠反馈校正和鲁棒控制思路缓解基于模型的 RL 则需要引入模型集成、不确定性估计、在线更新等手段。这也是为什么很多工程团队最终选择“MPC 做底层RL 做上层”底层用 MPC 把系统稳定住并满足安全约束上层用 RL 决策参考轨迹或优化模式切换。混合方案比单独用任何一个都更容易落地。3.3 怎么选先建模再决定要不要 RL任何实际问题都建议先回答三件事系统能不能建立可用模型如果能建且精度还能接受优先考虑 MPC 或传统最优控制。约束是不是硬约束比如不能碰到安全边界不能超过执行器极限。如果是RL 不能裸奔必须有约束保护。有没有充足的数据或在线交互条件没有的话深度 RL 很难有效离线 RL 或系统建模可能是更现实的路。如果系统完全无法建模、交互成本又低、任务目标复杂比如像素输入、复杂决策那 RL 的优势就体现出来了。反过来如果已经有了一个很准的机理模型直接套 RL 属于自找麻烦。4. 控制理论能给 RL 补上的三块短板稳定性、约束、可解释性4.1 稳定性分析训练曲线不应该是唯一的证据深度 RL 训练结束后很多人只看测试集平均收益数值高就开心数值低就调参。工程部署时这个判断标准远远不够。控制理论里的李雅普诺夫方法提供了一种分析思路找正定函数验证沿系统轨迹是否单调下降从而给出策略稳定性的结论。深度策略是复杂映射直接找解析李雅普诺夫函数很难但现在已经有越来越多工作在研究“学习李雅普诺夫候选函数同时约束策略使得该函数下降”。这类方法在安全关键系统上很有价值。即使不做严格证明也可以做一些更接近稳定性的实验把系统随机初始化固定几个有代表性的工况观察策略在持续扰动下的表现。再对比加入控制理论中的状态反馈整定逻辑后的表现。这些实验比单纯看训练曲线可信得多。4.2 约束设计光靠奖励惩罚不够RL 最常用的约束方式是碰了边界给大负奖励。但这种方式有三个问题。第一奖励稀疏。危险状态出现频率低惩罚项更新非常慢策略会反复踩雷。第二约束满足是概率性的。训练时满足不代表部署时满足尤其是仿真和真实环境存在分布偏移时。第三多约束冲突。想让机器人不跌倒、不超速、不撞人三个约束加进奖励后权重调起来非常痛苦。控制理论处理约束更系统。受约束最优控制、控制障碍函数、鲁棒 MPC 等方法会把安全集合设计成前向不变集。也就是说只要系统在集合内控制律就能保证它不会离开集合。和 RL 结合时通常有两种做法一种是把控制障碍函数作为投影层保证动作不违反安全条件另一种是把安全验证嵌入 RL 训练流程的每个阶段。4.3 可解释性从黑盒策略到可审计控制律传统控制器的好懂在于每一部分都有物理含义积分项消除稳态误差前馈项补偿已知扰动。RL 策略表现为深层网络的权重出了问题很难从权重看出原因。要增加可解释性我的经验是把它当工程问题处理先对策略做敏感性分析看哪些状态维度对动作影响最大再在仿真里故意改动某个状态观察策略输出如何变化最后把策略输出和控制律解做对比看它学习到的行为是否有物理规律还是只是在过拟合训练集。这些步骤不会让策略完全可解释但足以帮你在汇报、评审、排错时说明这条策略到底做了什么、为什么这样做。5. 实操建议先从最小样例跑起再谈高级算法5.1 跑通最小样例而不是一上来就上真实系统建议从经典强化学习环境开始比如 CartPole、Pendulum、HalfCheetah 这类先把一个标准算法跑通。离散控制可以先跑 DQN连续控制可以跑 DDPG、PPO、SAC 这些常见算法。第一步只做一件事让训练曲线从随机水平开始上升。不要改网络结构不要加花哨技巧就用公开示例里的默认超参数。需要记录的内容包括每 1000 步的平均奖励单条 episode 的长度环境每次 reset 时的初始状态分布动作是否被 clip奖励是否出现 NaN。这些记录就是对照基线。后面任何调整都基于它而不是凭感觉改参数。5.2 把奖励设计当作控制器整定来做能稳定复现一个算法后可以换一个自己更熟悉的被控对象比如简单的双积分系统或小车模型然后在仿真里试 RL。先用控制语言写任务想让位置误差趋近 0控制能量尽量小不给超调。再把三个指标转成多项式形式取负号后作为 RL 奖励权重先按“误差项比能量项大一个数量级”去试。跑完一组实验后对比两条曲线一条是纯 PID 或 LQR 的累计代价一条是 RL 训练后的累计代价。这个对比的意义不是分高下而是帮你建立直觉RL 策略到底在优化什么目标奖励权重变化会带来什么样的行为改变。如果只调奖励不收敛不要急着换算法。先检查状态是否做归一化动作尺度是否在环境期望范围内奖励数值是否跨了几个数量级环境步长和算法更新频率是否匹配。我见过很多训练失败案例最后都卡在奖励尺度上而不是算法网络结构。5.3 批量训练和对比实验的工程习惯RL 实验和深度学习实验一样强烈依赖随机种子。同一套超参数换一个随机种子结果可能有很大波动。建议固定一组随机种子比如 0、1、2每个配置至少跑三个种子训练曲线保存为 numpy 文件或 CSV不要只截图每个配置单独一个输出目录里面放超参数 JSON、日志、曲线数据先跑单条任务能稳定复现后再开小规模参数扫描。这个流程对应实际生产里的“单任务验证 → 批量实验 → 结果审计”。不要觉得 RL 是样本密集型任务就直接开几十个并行环境。并行环境越多调试越难问题会分散在代码、环境、参数之间很难定位。5.4 从仿真到部署前加一层控制理论检查最后一步在把策略搬到真实系统前按顺序过一遍清单策略输出是否超出执行器饱和限幅状态观测是否有延迟延迟大概多少拍真实系统是否存在模型和仿真不一致比如摩擦力、惯量、通信噪声如果策略在某个状态突然输出异常有没有保护性回退方案如果这些问题都回答不清楚就继续留在仿真里。真实系统上一条训练良好的 RL 策略能不能安全运行很多时候不取决于训练得分而取决于这几项检查有没有做好。6. 新视角未来值得关注的三类融合方向6.1 基于模型的强化学习让 RL 学会“先预测再决策”基于模型的 RL 一直处在 RL 和控制理论的交叉点上。它学习一个环境模型然后用采样、MPC 或轨迹优化来生成动作再用真实交互数据修正模型。相比无模型 RL模型一旦学到一定精度样本效率可以提升很多而且天然更容易加入约束。这个方向的工程价值在于如果系统已经有了一个先验机理模型没必要扔掉。可以把机理模型作为初始模型再用神经网络去拟合残差。这样既保留物理规律又能吸收数据里的修正信息。6.2 离线强化学习与数据驱动控制很多工业场景不允许在真实系统上不断试错数据只能来自历史日志。离线 RL 的目标就是只从固定数据集里学出一个策略不依赖在线交互。它和传统控制系统辨识加控制器设计很相似但难点在于数据分布和策略分布不一致时价值函数会被高估。如果你手上有大量控制日志离线 RL 可以提供一条新路线从已有数据里提取策略而不是重新去环境里探索。目前稳定性还不够高但作为未来方向很值得跟踪。6.3 安全强化学习与鲁棒控制真正要落地上机器人、自动驾驶这些系统安全这一关绕不开。安全 RL 研究的是如何在训练和部署过程中保证系统始终处于安全约束范围内同时还能学到高性能策略。一部分工作直接把控制理论里的约束处理机制嵌入 RL比如控制障碍函数、鲁棒 MPC另一部分工作则把安全验证模块放进训练循环每一轮更新后都检查策略是否违反约束。从工程视角看这类方法短期内比通用 RL 更接近生产环境也是我认为最值得投入时间的方向。这些方向不需要全部追先补好基础再根据自己面对的系统类型选一个深入研究。7. 收尾时给自己留一份检查清单7.1 一份可以直接复制的检查清单这篇文章的核心不是想证明 RL 和控制理论谁更高明而是做一次系统性的思维迁移从控制理论出发理解 RL再从 RL 的需求回看控制工具最后形成一套自己的判断标准。我平时每接一个新任务都会按顺序过一遍这份清单我有没有先把状态、动作、目标函数写清楚写不清楚后面全白搭。系统模型是否已知已知到什么程度是直接建模、残差建模还是完全无模型有哪些约束是硬约束这些约束目前在奖励项里还是在优化问题里能不能先跑一个最小样例单条任务稳定了再考虑批量和复杂环境。奖励尺度和权重是否处于同一数量级有没有记录每个分量的曲线训练失败时是先去调策略网络结构还是先看状态、动作、奖励、日志部署前有没有做状态延迟、执行器饱和、模型失配的检查这些问题有些来自控制理论有些来自 RL 实践但它们合在一起才构成完整的落地闭环。7.2 不同背景最常见的落地卡点从控制背景过来的人最容易卡在奖励设计和随机策略理解上。总想用确定性映射一锤定音忘了探索是训练的必要条件。从纯机器学习背景过来的人最容易忽略约束、稳定性和模型失配。把训练好的策略当成固定分类器直接部署没有回退方案风险很大。做研究验证的人可能更关注新算法但真正影响复现的是环境版本、随机种子和超参数记录。最好每次实验都保存 git commit、配置文件和输出目录。做产品落地的人要接受 RL 不一定是最优解。如果传统控制已经满足要求不要强行上 RL如果必须上 RL也要保留安全层和人工接管机制。很多卡了很久的问题最后都不是算法不够新而是从一开始就没搞清楚自己在求解哪个优化问题以及有哪些边界条件。先把这一点想清楚再决定用 MPC、PID、还是 PPO答案会自然清晰。
返回列表