文章核心观点 - 文章系统阐述了一种名为“Trigger框架”的自动驾驶数据闭环核心系统，旨在将异常事件从依赖人工经验排查的原始模式，转变为自动发现、自动归因、自动生成问题单并汇总成头部问题的智能化流程 [3][5][6] - 该框架的核心设计原则是“三端统一”，即用同一套Trigger逻辑代码在车端、云端和仿真端运行，确保问题定义和判断标准的一致性，从而解决传统方式中逻辑重复、结论打架的问题 [10][15][16] - 通过将Trigger框架与大型语言模型（LLM）和工作流引擎（如Dify）结合，构建了从问题自动分类、自动创建工单、自动加入仿真回归测试到自动验证修复的完整工单闭环，极大提升了问题处理效率和系统化程度 [44][47][51][60] 从传统问题排查到Trigger框架的转变 - 传统自动驾驶问题排查高度依赖少数资深专家（“老法师”）的经验，经验难以系统化沉淀，人员变动会导致诊断质量下降 [3][4] - 传统方式在车端在线监控、云端历史数据挖掘和仿真评测中需要各写一套逻辑，导致对同一事件（如急刹车）的判断阈值和结论经常不一致 [3][4][10] - 传统排查产生的是分散的“散点”，难以系统性地识别和定位当前最需要优先解决的头部问题类型 [4] - Trigger框架的目标是实现异常事件的自动发现、自动归因、自动分发，并自动汇总成头部问题，让数据自己“长成”结构化的“问题样本” [5][6] Trigger框架的定义与核心思想 - Trigger被定义为 特征工程（Feature Engineering） 加 分词器（Tokenizer） 的组合 [7] - 特征工程：从原始日志（如姿态、感知结果、轨迹、底盘CAN信号、错误码等）中抽取一批“中间事件” [7] - 分词器：将这些中间事件按时间轴打成带有类型、时间戳和附加属性的“Token” [7] - 后续的问题分类、聚类和头部问题分析，都是在这些Token序列、场景标签和Case（案例）数据上进行的操作 [9] - 从系统视角看，MPI（万公里干预次数）/ MPS / MPD等顶层指标是组织的损失函数（Loss Function），而每一次异常或Bug都是推动系统学习的“样本” [3][11] 三端统一Trigger框架的总体设计 - 框架设计有两个硬性规定：1) Trigger逻辑必须用纯Python编写，遵守统一接口；2) 多端适配、性能优化等复杂性全部由框架隐藏，业务开发人员只需关注Trigger逻辑本身 [19] - 整体架构分为三层： 1. Trigger定义层：包含每个Trigger的元数据（如唯一ID、描述、所属模块、输入依赖、输出标签、复杂度等级）以及供LLM阅读的文档 [16][19] 2. Trigger Runtime（执行引擎）：为Trigger提供在云端、车端和仿真端完全一致的执行接口，屏蔽底层平台差异 [16][17][26] 3. Trigger管理与调度：包括Manager和发布系统 [19] - Trigger的执行生命周期包含三个统一方法： - init()：声明数据依赖（订阅哪些数据通道和字段）并初始化Trigger的全局状态（如跨帧需要保存的变量） [20][21][22] - eval()：按时间顺序（云端离线for循环、车端实时流回调）被调用，处理每一帧数据，根据业务逻辑判断是否生成中间事件（Token） [20][22] - analysis()：在一段数据（如一个Case）处理完成后被调用，进行总结并输出结构化的结论和标准字段 [20][25] - 框架通过高性能C++库实现昂贵的几何运算（如多边形相交、距离计算），并向Trigger脚本提供Python接口，以保证eval()函数的性能 [22][23][24] Trigger框架的工程实现与生态 - 采用 “框架库” 与 “Trigger逻辑库” 分离的双仓库架构 [30][32] - 框架库：包含核心Runtime、多端适配、高性能工具和可视化增强，由核心团队维护并遵循严格的发布流程 [30][32] - Trigger逻辑库：存放所有具体的业务Trigger规则（如急刹、大转向），由研发团队共同维护，并接入CI流水线和自动化测试 [32][34] - 为确保车端性能，需要下发到车端运行的Trigger必须通过台架性能测试闸门，只有消耗（CPU/内存/带宽）达标的Trigger才会被标记为可下发 [34][37] - 利用 大模型（LLM）和RAG（检索增强生成） 技术降低了Trigger编写门槛，构建了“Trigger编写助手” [35][38] - 将框架说明和示例Trigger作为提示词和知识库 [35] - 研发人员用自然语言描述监控需求，AI助手可自动生成Trigger代码骨架和可复用片段 [38] - 这使得大量调试经验得以代码化沉淀，成为系统的“知识库+工具箱” [36][39] - 框架支持极端的跨平台执行，甚至可以通过JS版Python解释器（如Pyodide）在纯前端网页环境中运行Trigger，极大降低了调试门槛 [30] 从Trigger到结构化Case的生成流水线 - 步骤1：车端体感Trigger（如急刹）发现可疑事件，以“自然分钟”为粒度生成一个 road_case（路测案例）并分配ID [40][43] - 步骤2：云端根据Trigger命中情况，决定为该case上传或保留相应的 microlog（无损二进制数据包）和 mini log（压缩可视化数据）作为“证据包” [40][43] - 步骤3：云端Trigger在microlog/mini log数据上运行第二轮更精细的识别，产出更多Token补充到该road_case下 [40][43] - 步骤4：一个road_case可能涉及多个模块问题，会据此拆分成多个 bad_case（不良案例）并分配给对应团队 [41][43] - 步骤5：所有road_case、bad_case、Token和标签最终落入统一的数据表，为后续的自动分类、聚类和统计分析提供基础 [42][43] 基于LLM与Trigger Token的自动问题分类 - 第一阶段（规则树）：早期使用纯规则树（if/else逻辑）进行分类，优点是可解释，但难以维护和扩展新问题 [44][45][48] - 第二阶段（LLM分类器）：利用Trigger产出的Token序列和场景标签，构建更智能的分类系统 [46] 1. 将Token序列转换成“事件脚本”文本描述 [46][49] 2. 将脚本和场景信息输入LLM，让其输出问题归属模块、类型、严重程度和建议责任团队等自然语言结论 [46][49] 3. 将LLM的自然语言输出映射回结构化的字段，写回bad_case表 [46][49] - 在此流程中，Trigger扮演了 Tokenizer（分词器） 的角色，将原始信号转化为Token序列；LLM则扮演 Classifier（分类器） 的角色，在Token的语义空间中完成分类与归因 [47][49] - 自动分类系统的效果通过研发反馈进行闭环评估和迭代：统计研发在认领工单后是否修改了自动分类的标签，并将这些修正案例反向喂给LLM，用于持续优化分类器 [66][67][70] 工单与仿真的自动化闭环 - 自动创建工单：LLM分类后的bad_case会自动转换为结构化工单（如Aone工单），自动填充标题、描述、附件链接、责任团队和优先级，无需人工补充背景信息 [52] - 自动加入仿真回归集：问题被自动加入到对应团队维护的仿真回归测试集合中，与CI/准出流程打通 [53][54] - 多版本自动回归验证：通过工作流（如Dify）串联，当有新的准出版本上线时，CI会自动用该版本在仿真平台跑对应问题的回归测试 [55][56] - 若测试通过，则标记问题在新版本已修复，老版本工单可自动关闭或等待升级 [56][57] - 若测试失败，工单保持打开状态，继续提醒团队处理 [56] - 系统集成：使用Dify等工作流引擎，将LLM与数据平台、仿真平台、工单系统等外部接口（通过MCP工具封装）连接起来，LLM作为决策“胶水”调用这些工具函数，驱动整个闭环流程 [58][59][60][61] - 简化运维入口：通过钉钉机器人，运维人员只需在群内发送问题截图和自然语言描述，即可自动触发后端完整的工作流，最终将创建好的工单和回放链接反馈到群内 [62][63][65] 从Case到头部问题发现 - 当积累了大量的road_case、bad_case、Token序列和自动分类标签后，问题聚类和头部问题发现便有了扎实的数据基础 [68][71] - 可以按模块、问题类型、场景进行分组统计，分析问题分布；也可以在地图上打点，识别高频问题路段；还可以利用Token序列模式进行聚类，找出一段时间内重复出现最多、对核心指标（MPI/MPD）影响最大的几类头部问题 [68][71]