文章核心观点 - 截至2025年底，自动驾驶行业所宣称的“数据闭环”大多仍停留在各算法团队内部的“小闭环”，距离理想中“数据直接解决问题”的“大闭环”仍有数层台阶之遥 [1] 数据闭环的理想标准 - 真正的数据闭环至少需满足三层标准：问题发现自动化、解决效果可量化可复盘、投入产出可评估 [4][5] - 问题发现应实现从线上问题自动归类、构建数据集、进入训练/仿真、产出候选方案到自动评估效果的全流程自动化，人的角色主要是定义目标和拍板 [4] - 系统需能持续追踪新版本上线后，特定问题的发生频率是否下降，以及是否引入了新的负面问题 [7] - 需要设计并落地一套从车端实时触发到云端历史数据挖掘、仿真评价的代码级统一的触发器（Trigger）体系 [5] - 目标是将每一次急刹车、接管或奇怪行为都结构化、可计算，减少主观判断 [5] 行业现状与主要断点 - 目前多数厂商的“数据闭环”实质是“数据驱动的研发流程加一些自动化工具”，且局限在单个算法团队的小视角 [8] - 一个典型流程包括：各模块定义Trigger捞取数据、清洗标注、训练回归、上线监控，但这更多是模块级、算法视角的小闭环，而非系统级闭环 [9][13] - 主要断点之一：问题发现多为“被动闭环”，依赖司机反馈、运营投诉或人工刷录像，而非系统从海量数据中自动发现异常，是“问题驱动数据”而非“数据自动发现问题” [10][14] - 主要断点之二：问题归因困难，同一现象（如急刹）背后常是感知、预测、规划、控制等多模块高度耦合的原因，缺乏体系化诊断工具，导致责任划分不清 [12][15] - 主要断点之三：数据到方案的链路常止步于“数据到模型”，即只关注离线技术指标提升，缺乏对解决了哪个真实线上问题以及业务价值的追踪 [16] - 主要断点之四：“自愈”程度有限，从问题收集、标注、训练、评估到上线的全流程中，人工干预仍占大头，系统更像高度自动化的生产线而非能自我决策的“自愈系统” [17][21] - 主要断点之五：组织结构（如各算法团队、Tier1、整车厂各有各的OKR和边界）本身成为闭环的断点，导致系统层面难以协同 [18][22] 作者实践的数据闭环体系 - 体系设计理念激进，将“数据当产品、指标当第一公民”来设计 [24] - 整体思路：从“体感指标”出发，用Trigger将世界离散成token，再用LLM进行分类和路由，最后用统一代码串联发现与验证 [25] - 从体感指标出发：将用户有感的体感指标（如急刹、接管次数）作为“第一公民”，要求100%记录，并放弃“拷盘式”上传，采用类似互联网埋点的事件上报方式 [26][27][29] - 车端Trigger机制：在算力受限（仅一颗Orin X）条件下，采用高召回、极低开销的micro log/mini log机制，车端先以轻量Trigger打包疑似事件数据（micro log），云端二次确认后，再触发上传更详细数据（mini log） [30][32][33][34][35] - 定制化数据拉取：问题经人工初分或LLM分类后，会根据责任团队（如规控、感知、硬件）定制化下发任务，拉取所需细粒度数据（如规划轨迹、原始传感器数据、CAN报文），而非简单记KPI [36][40] - 代码级统一：实现了车端数据挖掘、云端历史数据挖掘、仿真验证评价的Trigger逻辑代码级统一，确保从问题定义到验证评估的语义一致，避免实现偏差 [41][44] - 问题自动分发：构建了领域专用tokenizer（Trigger）加classifier（LLM）的两阶段架构，Trigger将原始多模态时序信号编码成离散token序列，再文本化后交由LLM进行时序分类和路由 [43][45][47][48] - 弱监督在线学习：利用研发人员在问题管理系统中的真实“改派行为”作为弱监督标签，持续优化LLM分类器，形成在线学习闭环 [49][53] - Trigger框架统一与易用性：所有Trigger逻辑用纯Python实现且跨平台可跑，通过提供结构化文档和示例，并利用LLM辅助生成代码，降低编写门槛，让测试、运营等非算法同学也能参与 [50][54][55] - 量产环境解耦：将数据挖掘Trigger与线上主算法版本解耦，挖掘逻辑可作为“配置”或脚本通过云端下发，在车端沙箱中执行，从而灵活应对突发场景（如大雪天）而不必等待整车版本更新 [56][57][59] - 动态控制挖掘行为：云端对挖掘任务进行动态启停控制，当数据量足够覆盖必要场景分布后，自动关闭或降采样，避免数据重复和资源浪费 [59] 数据标签与检索策略 - 严格区分“世界标签”（客观物理世界/场景属性，如天气、道路类型）和“算法标签”（算法中间结果/表现，如检测框抖动），前者用于精细筛选和分布分析，后者用于归因与调参 [60][61] - 向量检索不适合作为海量存量数据的粗筛主力，因其召回成本高、语义易受训练分布影响且长尾场景易被淹没，更合理的做法是先利用结构化标签规则过滤掉80%-90%无效数据，再在缩小的子集上用向量检索进行语义级精筛 [62][63][64] 生成式与仿真数据的定位 - 生成式/仿真数据主要用于补充现实中难以凑齐的长尾场景训练（如路上的锥桶、路面坑洼），以扩大模型“见世面”并提升召回，但不能替代真实评测 [65][66][67][68] - 最终用于评测和放行的评测集坚持只使用真实数据，因为无法证明仿真完全模拟了真实世界 [69] - 警惕生成式数据提升召回时可能引入误检（FP）副作用，由于评测集难以完全覆盖FP，可能导致线上模型“到处乱看东西” [70][71][72][73] - 采用版本间逐帧全量差异分析来监控副作用：对两个版本在同一批真实数据上的感知结果进行全量比对，先不争论真值对错，而是分析差异模式（如哪些距离段、类别下差异激增），结合人工抽查判断是召回提升还是误检泛滥，确保“涨得干净” [74][75][76][78][79] 未来展望与挑战 - 当前体系更接近“Bug-Driven开发体系”，推动迭代的核心是具体bug的发现、量化和跟踪 [77][80] - 当前主要卡口已从“发现问题”侧转向“解决问题”侧，受限于研发人力带宽、标注成本以及仿真验证能否代表真实世界等挑战 [81][82][83] - 两个乐观方向：端到端/模仿学习架构兴起，其更直接对齐人类驾驶行为，绕开部分中间真值标注难题；闭环仿真/世界模型快速发展，旨在让仿真环境更接近真实世界，以支撑大规模自动化验证 [84][87] - 未来需降低解决一个bug的边际成本，并让端到端等方法在验证和安全上更可控，结合现有工程实践积累，才能使“数据驱动”从口号变为可持续运行、能算账、可规模化复制的基础设施 [85][88]