企业官网建设流程全解析

1. 从一次高速匝道惊魂说起：决策算法到底在解决什么问题

去年冬天我跟着一个做量产智驾的朋友跑测试，在一条车流不算密集的高速匝道上，前车突然因为错过出口急刹变道。那一刻我坐在副驾，眼看着系统在“跟刹”和“向左避让”之间犹豫了大概零点几秒，最后选了一个相对保守的急减速。事后我们复盘，感知层其实早就看到了那台车的异常轨迹，真正卡住的是决策层——它要在极短时间内判断对方意图、评估本车周围空间、权衡不同动作的风险，然后给出一个既安全又不至于被后车追尾的指令。

这件事让我重新认真思考了自动驾驶里的决策算法。很多人聊自动驾驶，第一反应是激光雷达、摄像头、BEV、端到端这些感知和模型层面的热词，但真正决定一台车“像不像老司机”的，往往是决策这一层。感知告诉你世界是什么样，决策告诉你接下来该怎么做。它要处理的是不确定性、多主体博弈、连续与离散混合的动作空间，还要满足安全、舒适、合规这些常常互相打架的约束。

这篇文章我想把决策算法这条线捋清楚：从最基础的MDP建模，到处理部分可观测的POMDP，再到Bayesian方法怎么用来做意图推断和风险估计，最后落到工程上到底怎么选、怎么调、怎么排坑。适合正在做智驾决策模块的工程师、准备入门这个方向的学生，以及想搞清楚“自动驾驶数据集里那些决策标注到底怎么用”的从业者。我不打算写成教科书，而是按一个实际做过项目的人的视角，把踩过的坑和想明白的道理讲出来。

2. 决策算法的整体设计思路与方案选型

2.1 为什么决策层不能简单套用规则

早期很多团队做决策就是写状态机加规则表：跟车、换道、超车、避让各写一套逻辑，用if-else串起来。这套东西在封闭园区或者低速泊车场景里能跑，但一到开放道路就露馅。原因很直接——真实世界的驾驶场景是连续且组合爆炸的。你跟车时前车可能同时在做减速和轻微偏航，旁边车道有车在加速逼近，后方还有摩托车穿插，规则表根本枚举不完。

更麻烦的是规则之间会冲突。比如“保持安全距离”和“提高通行效率”在拥堵时就是矛盾的，硬编码的优先级很难覆盖所有边界情况。我见过一个项目，规则写了三千多条，最后维护的人自己都说不清某条规则为什么存在。所以行业里逐渐转向用概率框架来建模决策问题，把“该怎么做”变成一个在不确定性下求最优策略的问题。MDP、POMDP、Bayesian这些工具就是在这个背景下被引入的。

2.2 MDP、POMDP、Bayesian三者的定位差异

这三个词经常被混着提，但它们在决策链路里的角色其实不一样。我用一个类比来说明：把开车想象成在雾天里走迷宫。

MDP假设你完全知道自己在迷宫的哪个位置，也知道每个岔路通向哪里，只是不知道哪条路最短，你要通过试错或者规划找到最优路径。对应到驾驶，就是假设状态完全可观测——你知道自车精确位置、周围每个障碍物的精确状态。这显然过于理想，但MDP是后面所有方法的基础，很多工程实现其实是“带噪声的MDP”。

POMDP承认你只能看到部分信息，雾天里你只能看到眼前几米，真实位置和障碍物意图是隐藏的。你要根据观测历史维护一个“信念”，也就是对当前状态的概率分布，然后在这个信念空间上做决策。这才是驾驶问题的真实写照——你永远不知道旁边那台车下一秒会不会突然变道。

Bayesian方法则是贯穿其中的工具。它既可以用来做意图推断（根据对方的历史轨迹推断它想变道还是想直行），也可以用来做风险估计（结合先验和观测更新碰撞概率），还可以用来做参数学习（从自动驾驶数据集里估计转移概率和观测模型）。所以我的理解是：MDP是骨架，POMDP是更贴近现实的骨架，Bayesian是填充骨架、处理不确定性的血肉。

2.3 方案选型的现实考量

理论上POMDP最正确，但直接求解POMDP是PSPACE难的，状态空间稍微大一点就炸。工程上没人真的去解原始POMDP，而是用各种近似：有的把信念状态离散化，有的用粒子滤波近似信念，有的干脆退化成“确定性规划加风险检查”。我参与过的项目里，比较务实的做法是分层——上层用POMDP思想做行为决策（选跟车、换道、让行这些宏观动作），下层用MDP或者优化方法做轨迹规划（在选定行为下生成具体轨迹）。

选型时我会问三个问题：第一，场景的观测不确定性有多大？如果传感器很干净、结构化道路，MDP加风险项可能就够了。第二，交互主体的数量和行为复杂度如何？如果周围车很多且博弈明显，POMDP或者基于博弈的近似更合适。第三，算力预算和实时性要求是多少？10Hz的决策周期下，能跑多复杂的推断和搜索，这个必须提前算清楚。下面这张表是我自己总结的选型参考。

3. 核心细节解析：从状态设计到信念更新

3.1 状态空间与动作空间怎么定

决策算法的第一步永远是定义状态和动作。状态设计得好不好，直接决定后面能不能收敛。我见过有人把状态定义成“自车速度、自车加速度、前车距离、前车速度、左车道是否有车、右车道是否有车”这种离散加连续的混合向量。这种设计能用，但有几个坑。

第一个坑是状态维度爆炸。如果你把周围每台车都单独建模，八台车就是十几个维度，再加上道路曲率、交通灯状态，状态空间会大到没法做值迭代。工程上的做法是做特征聚合，比如只保留“最近前车”“最危险侧车”这些关键交互对象，或者用相对位置和相对速度代替绝对量。

第二个坑是离散化粒度。MDP如果要做表格型求解，必须把连续状态离散化。速度按5米每秒一格、距离按10米一格，听起来合理，但边界处的决策会跳变。我的经验是离散化要跟控制层的平滑能力匹配，如果控制层能做很好的插值，决策层可以粗一点；如果控制层比较硬，决策层就得细，否则会出现“上一帧还让行、下一帧突然抢行”的抖动。

动作空间通常分两层：宏观行为（跟车、换道、超车、停车）和微观控制（加速度、转向角）。宏观动作是离散的，适合用MDP/POMDP求解；微观动作是连续的，一般交给规划层。我倾向于让决策层输出宏观行为加一个粗略的目标状态，规划层再细化，这样职责清晰，也方便调试。

3.2 转移模型与观测模型：Bayesian的用武之地

转移模型描述“执行动作后状态怎么变”，观测模型描述“给定状态会看到什么”。这两个模型是MDP和POMDP的核心，也是Bayesian方法最能发挥作用的地方。

先说转移模型。理想情况下它应该反映真实物理规律和周围车辆的交互反应。但精确建模周围车辆的反应几乎不可能，所以工程上常用简化假设：比如假设周围车保持当前速度做匀速运动，或者用IDM（智能驾驶员模型）这类跟驰模型来预测。这里Bayesian的价值在于，我们可以把模型参数当成随机变量，用实际数据去更新。比如IDM里的期望车头时距，不同地区、不同时段的驾驶风格不一样，用自动驾驶数据集里的跟车片段做贝叶斯估计，能得到比拍脑袋更靠谱的参数。

再说观测模型。传感器有噪声，检测有漏检和误检，这些都要在观测模型里体现。比如毫米波雷达对静止物体的检测置信度低，摄像头在逆光下容易漏检，这些特性如果不在观测模型里建模，POMDP的信念更新就会失真。我通常会用高斯混合模型来近似观测噪声，再用贝叶斯滤波（粒子滤波或扩展卡尔曼）做信念更新。粒子滤波的好处是能处理非高斯、非线性，缺点是粒子退化和计算量，需要仔细调粒子数和重采样策略。

3.3 奖励函数设计：安全、效率、舒适的三角平衡

奖励函数是决策算法的“价值观”。设计得好，系统行为就合理；设计得不好，要么过于保守被后车骂，要么过于激进出事故。我一般把奖励拆成三块：安全项、效率项、舒适项，再加一个合规项。

安全项通常用碰撞时间TTC或者距离的负指数来惩罚危险状态。这里有个细节：TTC的阈值不能设死。低速时2秒TTC可能很危险，高速时2秒TTC反而算安全。我见过用固定阈值的项目，结果在拥堵跟车时频繁急刹，体验极差。更好的做法是用相对速度归一化，或者用风险势场。

效率项鼓励尽快到达目标，但权重不能太高，否则会诱发危险动作。舒适项惩罚大加速度和大 jerk，这个对乘客体验影响很大。合规项包括限速、车道线约束、交通规则。这几项权重的调节是门手艺，没有标准答案。我的经验是先用仿真做粗调，再用实车数据做细调，而且不同场景（高速、城区、泊车）要用不同的权重配置，不能一套参数打天下。

注意：奖励函数里千万不要用“绝对禁止”这种硬约束去替代软惩罚，除非是法规红线。硬约束会让优化问题变得不可行，导致决策器无解。更好的做法是软惩罚加安全兜底模块。

4. 实操过程：一个可落地的决策模块怎么搭

4.1 从自动驾驶数据集里提取决策所需的先验

现在公开的自动驾驶数据集不少，像nuScenes、Waymo Open Dataset、Argoverse这些，里面既有传感器数据，也有轨迹标注。很多人拿它们训感知，其实对决策也极有价值。我通常会用它们做三件事。

第一，统计交互行为的先验分布。比如统计变道时目标车道后车的让行概率、跟车时前车急刹的频率、路口汇入时各方的博弈模式。这些统计量可以直接作为POMDP里转移模型的先验，或者作为Bayesian意图推断的先验概率。

第二，提取典型场景片段做回放测试。把数据集里的危险场景（cut-in、急刹、鬼探头）抽出来，构建一个回放测试集，用来验证决策算法的鲁棒性。这比纯仿真更接近真实分布。

第三，校准奖励函数。通过逆强化学习或者简单的偏好学习，从人类驾驶数据里反推奖励权重，让决策行为更接近人类。我试过用最大熵逆强化学习从跟车数据里学奖励，得到的权重比手工调的更平滑，急刹和急加速明显减少。

处理数据集时要注意坐标系对齐和时间同步。不同数据集的坐标系定义、采样频率、标注粒度都不一样，直接混用会引入系统性偏差。我一般会统一到自车坐标系，重采样到固定频率（比如10Hz），并对轨迹做平滑滤波，去掉标注噪声。

4.2 信念更新的工程实现

POMDP的信念更新是实操中最容易出问题的地方。我用粒子滤波做过一个变道意图推断模块，流程大致是这样：每个周围车辆维护一组粒子，每个粒子代表一个可能的意图（左变道、右变道、直行）和对应的运动状态。每帧根据观测更新粒子权重，权重低的粒子淘汰，权重高的粒子复制，再叠加过程噪声做预测。

这里有几个实操要点。粒子数不能太少，太少会退化，我一般每个意图至少50个粒子，三个意图就是150个，周围五台车就是750个，计算量要提前评估。重采样不能太频繁，否则会样本贫化，我通常当有效粒子数低于阈值时才重采样。过程噪声的方差要跟场景匹配，高速上可以小一点，城区路口要大一点，因为城区的不确定性更高。

另一个坑是意图的马尔可夫性假设。标准POMDP假设当前意图只依赖上一时刻意图，但实际驾驶中意图有持续性，司机决定变道后通常会保持一段时间。所以我在转移模型里加了意图的粘性，让意图切换概率低于0.1，这样推断出来的意图不会频繁跳变。

4.3 决策求解与实时性保障

信念更新完之后就是求解。如果状态空间小，可以用点基值迭代或者QMDP近似。QMDP的思路是先把信念当成确定性状态求Q值，再在信念上做一步前瞻，计算量比完整POMDP小很多，效果在驾驶场景里够用。如果状态空间大，我会用蒙特卡洛树搜索（MCTS）在信念空间上做在线规划，配合rollout策略做前瞻。

实时性是硬约束。10Hz意味着每100毫秒要出一次决策。我的做法是把决策分成快慢两个环路：快环用轻量级规则或查表做安全兜底，保证任何情况下都有输出；慢环跑POMDP或MCTS做优化决策，如果超时就沿用上一帧结果。这样既保证了实时性，又不会因为算力波动导致决策中断。

参数计算上，我会先估算单次信念更新的耗时。假设每帧处理5台车、每台150个粒子，单粒子更新大概几微秒，总耗时在毫秒级，加上求解的几十毫秒，整体能控制在预算内。如果超了，就减少粒子数或者降低求解精度，这是工程上的取舍。

5. 常见问题与排查技巧实录

5.1 决策抖动：为什么车会“犹豫”

决策抖动是最常见的问题，表现为车辆在两种行为之间反复切换，比如一会儿想变道一会儿又放弃。根因通常是信念更新不稳定或者奖励函数在边界处不连续。排查时我会先看信念曲线，如果意图概率在0.5附近来回跳，说明观测信息不足以区分意图，需要增加观测特征或者加时间平滑。如果信念稳定但决策跳，那就是奖励函数的问题，通常是两个动作的Q值太接近，加一点迟滞或者动作切换惩罚就能解决。

5.2 过于保守：被后车鸣笛的尴尬

有些团队为了安全把风险惩罚调得极高，结果车辆在匝道汇入时一直等，等到最后没空间了才硬挤。这种保守行为的根因是奖励函数里安全项权重过大，效率项被压制。我的调整方法是引入“社会合规”项，也就是参考人类驾驶的让行和抢行时机，用数据集统计出来的博弈模式做引导。另外可以设置一个“最小前进激励”，避免车辆无限等待。

5.3 计算超时：粒子滤波的实时性优化

粒子滤波在车辆多的时候容易超时。我试过几种优化：一是自适应粒子数，车辆少时少撒粒子，车辆多时再增加；二是把粒子更新放到GPU上并行；三是用低维特征代替完整状态，比如只推断意图不推断完整运动状态。实测下来，自适应粒子数加GPU并行能把耗时降低一半以上。

5.4 常见问题速查表

提示：调试决策算法时，一定要把信念、Q值、奖励分量都打日志可视化。光看车辆轨迹很难定位问题，看到内部状态才能快速判断是感知、推断还是优化出了问题。

6. 我对决策算法落地的一点个人体会

做了几个项目之后，我越来越觉得决策算法的难点不在数学，而在“定义问题”。MDP、POMDP、Bayesian这些工具本身是成熟的，难的是把真实驾驶场景抽象成合适的状态、动作、奖励和模型。抽象得太细，计算爆炸；抽象得太粗，行为不合理。这个平衡点没有理论公式，只能靠对场景的理解和大量实验去磨。

另外，别迷信端到端能解决一切。端到端在感知和规划上确实有优势，但决策层的可解释性和安全兜底在量产里仍然是刚需。我的做法是把概率框架作为主干，保证可解释和可验证，同时在局部用学习方法来提升拟人化。两者不是对立的，而是互补的。

最后分享一个我常用的小技巧：每次调完参数，别只看平均指标，一定要把最差的那些场景单独拎出来看。决策算法的价值往往体现在长尾场景里，平均分再高，一个危险场景处理不好就是大问题。把长尾场景做成回归测试集，每次改动都跑一遍，这是我踩过几次坑之后养成的习惯。