自动驾驶行业最近有个很有意思的讨论一边是号称“世界模拟器”的虚拟测试系统能在几天内跑完现实中几十年都开不完的里程另一边却是分散在海外的远程操作团队依然要用人的眼睛去盯路、用手去接管车辆。这两个画面放在一起很多人第一反应是矛盾——不是说要自动驾驶吗怎么还有人在远程开车不是说要靠数据闭环吗怎么还在大量人工标注我接触自动驾驶大概第六年了从早期的高精地图团队到后来的仿真平台建设再到和海外远程操作供应商打交道算是把这条链条上几个关键环节都摸了一遍。这期间最深的体会是大家通常喜欢讲自动驾驶很“科幻”但真正落地的时候它更像是一门精细的运营生意。模拟器和远程操作员不是前后替代的关系而是两个完全不同的工种在给同一套系统兜底也给同一套系统供血。这篇文章我想从“两面性”入手拆一下世界模拟器和海外操作员在自动驾驶体系里各自承担什么两者之间怎么配合以及企业在搭建这套体系时最容易踩的坑。如果你正在做自动驾驶相关的产品、研发或者运营又或者只是好奇这套系统为什么需要这么多“人肉劳动力”这篇应该能帮你把零散的信息串成一张完整的图。1. 一条“安全”路上同时有机器和人在跑自动驾驶的分工逻辑本质上是在解决同一个问题怎么让车在绝大多数情况下自己决策又在极少数情况下有人兜底。这个“极少数”的坑比大家想象的要深得多。举个例子路面施工绕行、警察临时手势指挥、高架下匝道被违停车堵死、暴雨天车道线完全消失这些场景不是算法学不会而是数据采集时根本遇不到几次。如果只靠实车去跑一年也凑不齐足够训练的有效样本。所以有了“世界模拟器”这条腿。它的价值是用程序化方式构造各种极端场景让自动驾驶模型在海量虚拟环境里反复试错。外面很多文章喜欢强调它“一天跑几百万英里”仿佛它是用来替代实际路测的。这个说法容易让人误判它不是为了取代真实道路而是为了在虚拟空间里模拟“现实世界可能出现的任何意外”。而远程操作员这条腿解决的是另一层问题当自动驾驶系统遇到自己不确定的场景车辆会请求远程协助。这一实时请求会分配给在沙盘前值守的人员让对方通过车端摄像头看到车辆周围情况然后给出决策建议。海外设点的原因很简单——时区覆盖、人力成本、语言能力以及一些地区对“远程安全员”岗位的政策要求。菲律宾团队是这类外包服务里比较常见的选择并不是因为他们水平低恰恰是因为当地有大批英语熟练、愿意做轮班值守的技术客服型人才。两条腿并行才让系统看上去“敢上路”。只靠模拟器系统永远会漏掉真实世界的偶发因素只靠远程操作员一旦遇到网络断连、值班不足就会瘫痪。真正的自动驾驶公司是把这两者当成一套连续系统来设计模拟器负责“穷举”远程人负责“兜底”数据再从两头流回同一个算法仓库。2. 拆开“世界模拟器”虚拟环境不是游戏引擎那么简单很多非技术背景的人以为世界模拟器就是拿一个高精度地图搭一个类似游戏的任务场景让自动驾驶车在里面跑就行。实际远不止这些。仿真平台首先要解决的问题是“传感器怎么骗过模型”。摄像头图像要真实激光雷达的反射特征要合理毫米波雷达的多径干扰也得模拟出来。如果这些环节偷懒模型在仿真里学到的能力在真实车辆上会完全变形。2.1 仿真层的三块基石我搭建仿真系统时一般会先盯着三个核心组件场景生成器不只是“在路口放一辆车”而是要附带行为模型。比如相邻车道车减速、后车加塞、行人突然横穿每个交通参与者都应该有符合概率分布的行为模式。最基础的做法是手工搭建关键场景进阶一点是用对抗网络去自动生成那些“让模型难受”的场景。传感器仿真摄像头仿真要做天气、光照、曝光、运动模糊激光雷达仿真要做反射强度、点云稀疏化、雨滴噪声毫米波雷达要模拟多普勒效应和地面杂波。这些如果不做模型会拿着一张“完美图片”做训练到了雨天就失灵。动力学模型车辆的响应要尽量贴近实车底盘包括转向延迟、悬挂俯仰、轮胎打滑。这个以前很多仿真系统不在乎后来发现模型学到的轨迹在真车上完全不可用就是因为底盘响应差异太大。这三块缺一不可。我见过一个团队花了两周时间搭出一套“画面看着很精美”的仿真场景结果场景里所有车的加速度是恒定的没有刹车和加速曲线模型在仿真里练出了“贴脸急刹”策略上车后被安全员骂了一周。这个教训让我后来养成了一个习惯任何仿真场景上线前至少要抽10%做回放让车辆动力学工程师肉眼确认一遍。2.2 从模拟器跑出来的数据怎么用仿真平台每天产出大量数据但“产出数据”不等于“更新模型”中间隔着一道筛选的工序。常规流程是这样的第一把模型在仿真里跑出来的决策轨迹和该场景下的最优参考轨迹做对比。这里的“最优”不是人拍的而是由规划控制团队预先设定好的安全走廊。第二找出失败样本包括碰撞、过度减速、频繁变道、错过出口等。把这些样本打上标签送进一个专门的“困难样本库”。第三做回归测试。每个新模型发布前必须跑一遍覆盖全场景库的回归集分数不能低于旧模型否则直接打回。这套流程里最容易出问题的是第二步标签标准不清。比如“频繁变道”到底多频繁算频繁如果没人定义不同标注员会给出完全不同的标记模型训练时就会收到互相矛盾的信号。后来我们的做法非常土直接建了一个规则表把“1公里内大于两次非必要车道切换”作为硬指标只允许算法自动打标不让人来主观判断。2.3 一个被低估的参数场景覆盖率仿真团队KPI到底是“跑了几百万公里”还是“覆盖了多少场景”以我的经验只看前者一定会翻车。因为仿真可以轻易重复跑同一个场景跑一百万次覆盖率依然低得可怜。我们内部会定期做一次“场景覆盖率审计”把所有仿真场景按天气、道路类型、交通参与者、事故类型四个维度排列找出完全空白或样本少于50条的格子然后主动去补。这件事听起来简单实际非常磨人因为有些组合在现实里根本不存在好不容易编出来又不合理。比如“大雪天的机场高架桥双向八车道”编出来之后大家怎么看都觉得假。但恰恰这类极端组合往往是真实世界中一次事故的温床。3. 海外操作员的真实工作台远程协助与数据标注远程操作员这个岗位这些年越来越重要但外界误解也最多。很多人以为就是坐在屏幕前“像玩GTA一样开车”实际上这个岗位需要极强的注意力管理能力而且每天处理的请求类型五花八门。大多数情况下操作员不是在开车而是在做“决策建议”他们看到的是自动驾驶系统无法判断的场景需要帮忙判断“要不要绕过去”“要不要靠边停”“要不要走哪条车道”。3.1 操作员的一天从队列里捞出一条接管请求我带队对接过海外操作团队他们的日常工作流大概是登录值守系统界面上会列出当前所有正在运行的自动驾驶车辆以及每辆车发起的远程请求。每个请求有一个优先级标签紧急程度高的一般是车辆停在路中间、车内有乘客、周围有障碍物这类会阻塞交通的事件紧急程度低的是“不确定下一段路是否封闭”这种规划类问题。操作员会先在15秒内查看车辆周边影像包括前视、后视、侧视摄像头以及矢量地图上的位置。如果情况明确操作员可以直接下发一条“继续行驶”或“靠边停车”的指令如果不明确则标记为需要进一步处理并通知云端调度。这里有一个关键设计操作员并不会直接控制方向盘而是“选择一条自动驾驶系统给出的候选轨迹”。系统会先计算出几条安全轨迹操作员只需要选择其中最合理的一条。这个设计把“远程人”的决策误差压缩到了最小同时保留了人在关键时刻的判断力。3.2 哪些情况需要人哪些情况机器自己扛并不是所有异常场景都需要人介入。如果一辆车被前方慢车挡住系统自己变道就能解决根本不会发请求。真正需要人的通常是有“信息缺口”的场景施工路障的走向不清晰系统不知道应该驶入哪一条车道。四方向交叉口有一个交警在打手势摄像头识别出“人在挥手”但没法判断手势语义。前方有异形车辆比如拖着收割机的拖拉机系统无法判断它的转弯半径。这些场景算法已经可以意识到“我不确定”这个意识和场景本身一样值钱。很多公司前几年都在疯狂提升这个“请求触发率”的精度太敏感了车没事就叫人运营成本爆炸太迟钝了车两眼一抹黑也不吭声安全风险极高。最优区间不是一直不变的会随着算法迭代不断移动所以需要每周统计一次接管请求率与接管原因分布。3.3 标准化操作标准与质量审查海外操作团队的管理比大家想象中复杂得多。因为操作员分散在不同地区他们的判断标准如果不统一模型训练数据会一团糟。我们会给每位操作员发一份非常细的操作手册里面甚至规定到“当车辆停在坡道上的时候如果前方有车辆绕行推荐跟车而不是借道”。操作员每次接管都会被记录录音、屏幕操作、决策结果、耗时全部存档。质量审查团队会随机抽5%的接管记录按“决策是否安全”“是否符合手册”“响应是否及时”三个维度打分。分数连续两周低于阈值的操作员会被安排重新培训培训材料用的就是一份真实的接管回放。4. 模拟器与操作员的“双向奔赴”数据闭环的隐藏逻辑写到这里你可能发现了模拟器和操作员不是两条平行线而是互相喂数据的关系。模拟器可以复现操作员遇到的场景用来自动化测试操作员则可以帮模拟器标注出“这个场景该给的正确答案”。这条数据闭环才是自动驾驶持续进化的核心。4.1 每次介入都是一次负样本训练远程操作员每次接管其实都在帮算法标注“这里的默认决策是错误的”。系统一开始大概率是想直行但操作员选择了绕行这个差异会被提取成一个训练样本。接下来要做两件事一是把这个场景写入仿真场景库让它变成回归测试的固定成员二是把操作员的决策轨迹作为“高级示范”让决策网络去模仿学习。这种方式比纯靠奖励函数调参要有效得多因为它利用了人类在真实世界里形成的常识。但这里有个陷阱操作员的决策不一定都正确。如果操作员因为疲劳或网络延迟做出了糟糕决策而这个决策被当成“示范”去喂模型就是灾难。所以我们会在训练前加一轮自动审核过滤掉“决策风险值异常”的样本。4.2 把“人的直觉”写进评测指标世界模拟器练出来的模型最大问题是“冷冰冰的合理性”。比如在某个路口算法认为“从两条排队车辆的缝隙里钻过去”是完全合理的因为计算出的碰撞概率很低。但换成一个有经验的驾驶员他一眼就知道这种决策会让后车按喇叭会让旁边司机紧张甚至引发路怒。这种“社会性”很难写进数学公式但可以通过人工介入数据去间接建模。具体做法是在模型评测指标中增加一项“接管满意度”计算模型决策轨迹与操作员实际决策轨迹的高层语义相似度。如果模型走了一条操作员从来不会走的路即使没有碰撞也会被扣分。随着这种语料越积越多模型会逐渐学会“更像人”的驾驶习惯而不是只做“最优化”的冷血决策。4.3 组织层面仿真工程师、运营团队、算法工程师如何协作数据闭环想跑通光靠技术不够组织上的摩擦力同样致命。仿真工程师觉得远程操作数据“脏”不愿意接运营团队觉得仿真场景“假”不愿意配合算法工程师夹在中间两边数据都觉得差点意思。我所经历的顺利项目后来都建立了每周一次的三方联席会议会上只讨论一件事把上一周最典型的20个接管案例在仿真里跑一遍看模拟能否复现无法复现的排期解决。这个会议听起来很普通但它用流程把三方绑在了一起。仿真不再是算法团队内部自嗨的工具运营团队的经验也不是一封邮件就完事。三方共享同一个场景库算同一个事故率指标这样才能避免“各干各的”这个自动驾驶行业最普遍的浪费。5. 真实落地中的常见问题排查与避坑实录讲完了体系框架最后说说实操中常见的问题。这几年不光我自己踩过坑周围同行也有不少类似的案例值得拿出来当参考。5.1 经典事故仿真得分高、实车接管多这是最常见也最迷惑的现象。新模型在仿真测试集上大幅领先旧模型一上车接管率反而升了。排查之后发现仿真场景库里的“雪天”“夜间”都是静态预设光照强度是固定值而真实车端的摄像头自动曝光会跟着环境剧烈变化。模型在仿真里没见过这种动态曝光过程一上线就抓瞎。现在我们的做法是在仿真系统里加入“传感器退化模拟”让每个场景至少同时跑三个光照版本、两个天气版本和一个传感器故障版本确保模型在虚拟环境里见过足够多的“不完美数据”。5.2 远程介入延迟和网络抖动处理海外操作员面临的永恒痛点是网络延迟。远程接管不像本地安全员数据要走跨海链路哪怕走专线也可能出现300到500毫秒的延时。这个延迟看起来不长但在高速场景下已经足够让车辆偏离原本轨迹了。解决方案不能指望网络变好只能从产品设计上适应。我们的做法是把远程介入分成两级第一级只发“允许”或“否定”指令这类指令数据量极小即使延迟高一点也能接受第二级才是轨迹选择指令必须带时间戳和超时重发机制。如果操作员1.5秒内没有确认车辆会自动执行“低速靠边停车”把决策权交还给本地系统。5.3 个人心得先定安全边界再谈覆盖率如果只能给一条建议我会说搭建任何仿真加远程协作体系之前先把“失败模式”全部定义清楚。自主研发阶段可以允许模型犯各种错但产品落地之后必须保证每条失败路径都有人兜底。我见过一些团队一上来就追求“仿真场景达到五位数”结果场景库堆了一堆垃圾真正用于验证核心安全逻辑的只有不到两成。更聪明的做法是先定义“安全包络”比如前车急刹且用户车道无法变线时车辆必须能在3秒内刹停施工区停车等待超过2分钟时必须发起远程请求。然后把每一个安全包络都做成仿真用例用最低成本先把底线守住再去谈覆盖率。最后再分享一个小技巧评估一个远程操作团队的时候别只看他们的平均响应时间多看看“响应标准差”。平均时间好看可能只是少数人很快拉高了均值标准差大说明很多人状态不稳定这种团队一旦遇到大规模并发请求就会瞬间崩盘。同样评估仿真系统也别只看“总里程”多看看“场景多样性”这个指标才是真正决定模型泛化能力的东西。自动驾驶的路还很长世界模拟器和海外操作员只是这条路上的两个缩影。它们一个代表机器可以如何无限复现世界另一个代表人在技术之外如何持续提供判断力。两边的配合远比单边的“技术突破”更值得关注因为量产落地那天决定用户体验的往往不是算法炫不炫而是整个系统兜底稳不稳。