文章核心观点 - 当前自动驾驶行业所宣称的“数据闭环”大多停留在算法团队内部的“小闭环”，距离能够“数据直接解决问题”的“大闭环”或“真闭环”仍有显著差距 [1] - 实现“真闭环”需要满足问题发现自动化、解决效果可量化可复盘、投入产出可评估等多层要求，而目前行业普遍存在被动闭环、归因困难、链路断裂、组织结构制约等典型断点 [4][5][7][18] - 一套有效的实践方案是：从量化真实世界的“体感指标”出发，通过轻量高召回的车端触发机制、代码级统一的触发与验证体系、结合大模型的自动问题分类与分发，构建一个可演进的数据闭环系统 [24][25][41][43] - 未来的发展方向在于通过端到端架构和闭环仿真/世界模型等技术，降低解决每个问题的边际成本，使数据驱动从口号变为可规模化复制的基础设施 [84][85][88] 行业现状：理想与现实之间的差距 - 理想中的“真闭环”定义：至少需要满足三层：1) 问题发现自动化，系统能从海量数据中自动发现异常行为并形成数据集；2) 解决效果可量化、可复盘，能持续追踪问题频率是否下降、是否引入新问题；3) 投入产出可评估，能判断每次数据、算力、开发投入是否值得 [4][5][7] - 行业普遍实践：多数厂商的“数据闭环”实质是“数据驱动的研发流程加一些自动化工具”，且局限在单个算法团队的“小闭环”视角 [8] - 典型小闭环流程：线上触发/抽取 → 清洗与标注 → 训练/回归 → 上线与监控，这更多是模块级、算法视角的闭环，而非系统级闭环 [9][13] 实现“真闭环”的主要挑战与断点 - 起点被动：大量问题仍依赖司机反馈、运营投诉、领导试驾或人工刷录像等被动方式发现，是“问题驱动数据”，而非“数据自动发现问题” [10] - 归因困难：同一现象（如急刹）背后常是感知、预测、规划、控制等多模块高度耦合的原因，缺乏体系化诊断工具，导致责任难以界定，效率低下 [12][15] - 链路不完整：许多团队的闭环止步于“数据到模型”，即关注离线技术指标提升，但未追踪是否解决了哪个具体的线上真实业务问题 [16] - 自动化程度有限：从问题发现、标注、训练、评估到上线的全流程中，人工干预环节仍占大头，系统更像高度自动化的生产线，而非可自我决策的“自愈系统” [17][21] - 组织架构制约：感知、预测、规划、控制、地图等团队以及Tier1、整车厂等各方边界分明，OKR各异，导致系统级闭环被组织结构天然拆散 [18][22] 一套具体的数据闭环实践方案 - 核心理念：从“体感指标”出发，用Trigger（触发器）把世界离散成token，再用大模型（LLM）做分类和路由，最后用统一代码串起“发现”和“验证” [25] - 量化真实痛点：将急刹、接管、大幅转向等用户有感的“体感指标”作为第一公民，要求100%记录，并沉淀为“每万公里急刹车率”等可统计指标 [26][27][28] - 车端轻量触发机制：在算力受限（如单颗Orin X）条件下，设计高召回、低开销的micro log机制，一旦发生疑似事件（如急刹），即打包关键状态信息上传，宁可多报，不能漏报 [30][32][33] - 云端验证与数据拉取：云端对micro log进行规则/模型过滤，确认可信后，再下发任务拉取包含更多中间结果和短视频的mini log，实现按需、分层的数据上传，避免带宽浪费 [34][35][38][39] - 代码级统一：将定义问题的Trigger逻辑代码在车端实时挖掘、云端历史数据挖掘、仿真验证评价三个场景中统一，确保从发现问题到验证修复的语义一致，无实现偏差 [41] - 问题自动分发体系：将Trigger体系视为领域专用的tokenizer，将原始数据流转化为高层语义事件序列（token），再文本化后输入大模型，由大模型作为时序分类器进行根因归因和团队路由 [43][45][47] - 持续学习闭环：利用研发人员在问题系统中真实的“改派”行为作为弱监督标签，持续回流训练大模型分类器，使其在真实业务分布下越用越准 [49] - 降低规则编写门槛：所有Trigger逻辑用纯Python实现并统一接口，配合详细的文档和示例，并利用大模型辅助，让测试、运营等非算法人员也能用自然语言描述需求并生成可微调的Trigger代码 [50][54][55] - 量产环境解耦：将数据挖掘Trigger设计为可云端下发的“配置”或运行在车端沙箱中的脚本，使其与主算法版本解耦，能灵活、快速地响应突发场景（如大雪天）的数据挖掘需求，而不影响系统安全与稳定性 [56][57] 数据管理与使用的关键见解 - 区分标签类型：严格区分“世界标签”（如天气、道路类型、交通参与者数量）和“算法标签”（如感知框抖动、规划重规划频率），前者用于精细场景筛选，后者用于算法归因调参 [60][61] - 向量检索的正确用法：向量检索适合作为“精筛”工具，而非“粗筛”主力面对海量数据时，应先用结构化标签规则过滤掉80%-90%的无关系数据，缩小范围后，再用向量检索进行语义级细筛，以提升效率和精度 [62][63][64] - 生成式/仿真数据的定位：主要用于补充现实中难以凑齐的长尾场景训练数据（如临时路障、路面坑洼），以扩大模型“见世面”但最终用于评测和放行的评测集必须坚持使用真实数据，因为无法完全模拟真实世界 [66][67][69] - 监控模型副作用：在引入生成数据提升召回时，需警惕误检（FP）在未知场景下恶化的风险采用对两个版本进行逐帧全量结果差分的方法，系统性监控差异模式，评估“涨得干不干净”，而不仅仅看召回率涨幅 [70][74][77] 未来展望与演进方向 - 当前本质：现有体系更接近一个“Bug-Driven开发体系”，核心是更快、更准、更系统地发现、量化和跟踪具体问题（bug） [77][80] - 现存卡口：当前主要瓶颈已从“发现问题”侧，转移到“谁来解决问题、怎么解决问题”侧，受限于人工标注成本、仿真验证的可信度以及研发人员带宽等刚性约束 [81][82][86] - 积极方向：端到端/模仿学习架构的兴起，通过直接对齐人类驾驶行为，绕开了中间真值难标的问题；同时，闭环仿真/世界模型的快速发展，旨在让“在仿真里充分暴露问题、充分迭代”更接近真实世界 [84][87] - 最终目标：通过降低解决每个问题的边际成本，并结合在Trigger体系、自动分类等工程实践上的积累，使“数据驱动”从口号变为一套能持续运行、可核算、能规模化复制的基础设施 [85][88]