1. 项目概述为什么“以语言为中心”正在重构自动驾驶的数据范式最近半年我在几个头部自动驾驶公司的数据中台团队做技术咨询明显感觉到一个转向过去堆摄像头、激光雷达点云、高精地图的“多模态数据军备竞赛”正悄悄让位于一种更精细、更可解释、也更贴近人类驾驶认知的数据组织方式——“以语言为中心”。这不是指让车听懂“靠边停车”这种语音指令而是把自然语言作为数据标注的锚点、场景理解的骨架、模型训练的监督信号、甚至系统验证的黄金标准。比如某L4物流车队在复盘一次无保护左转失败时工程师不再只调取30秒的BEV特征图和轨迹预测曲线而是直接检索数据库里所有带“对向车流密集行人突然闯入雨天路滑”这组语言描述的样本再比如一家芯片厂商在验证其感知模块对“施工区域锥桶被风吹倒”的识别鲁棒性时直接用这个短语去召回跨传感器、跨天气、跨光照条件的127个真实片段而不是人工圈定ROI再逐帧打标。关键词“以语言为中心的自动驾驶 数据集 汇总分析”背后藏着的是整个行业从“像素驱动”向“语义驱动”的底层迁移。它解决的不是某个具体算法的精度问题而是数据生产、管理、消费全链条的效率瓶颈与认知鸿沟——传统数据集里一张图配一个“car”标签和一段“白色SUV在湿滑路面急刹导致后车追尾前车”的文本描述信息密度差了两个数量级。这篇文章适合三类人一是数据平台工程师需要设计能承载复杂语义关系的存储架构二是算法研究员想搞清楚如何把语言信号真正注入到BEVFormer或Occupancy Networks的训练流程里三是产品与测试负责人正为“如何定义一个‘足够难’的corner case测试集”而头疼。我不会讲大道理只拆解我们实测跑通的方案、踩过的坑、以及那些文档里绝不会写的参数选择逻辑。2. 核心思路拆解语言不是附加层而是数据集的“操作系统”2.1 为什么传统数据集架构撑不住语义爆炸先说一个血泪教训去年帮一家造车新势力升级其ADAS数据闭环系统他们原有数据集按“传感器类型-场景标签-时间戳”三级目录存放共237个硬编码标签如“高速匝道合流”“夜间隧道出口”。当产品经理提出要新增“新能源车在充电站排队时被燃油车加塞”这个场景时数据标注团队花了11天——不是因为找不到视频而是因为第一现有标签体系里没有“充电站”“排队”“加塞”任何一项第二强行新增会导致标签树深度超过5层下游训练脚本批量读取时内存溢出第三更致命的是这个新场景必然伴随“低速蠕动”“SOC低于20%”“充电桩指示灯闪烁”等隐含状态纯视觉标签根本无法表达。这暴露了本质矛盾传统数据集把语言当作事后贴的“便利贴”而真实驾驶决策依赖的是语言所承载的因果链与状态机。我们后来推翻重来核心转变就一条把语言描述本身作为数据集的主键Primary Key所有传感器原始数据、标注框、轨迹、甚至仿真环境配置文件都通过哈希值关联到这条文本上。比如一条记录“晴天正午城市主干道双向六车道左侧两车道被临时施工围挡占用一辆蓝色网约车在第三车道以35km/h匀速行驶右侧非机动车道有3名骑手并排骑行其中1人突然向左斜穿至第三车道网约车驾驶员紧急向右打方向避让车身横摆角达12度。”这条文本经SHA256哈希后生成唯一IDa7f9e2d...所有关联数据4路环视视频帧、激光雷达点云序列、IMU姿态数据、驾驶员方向盘扭矩曲线、仿真场景JSON都存放在以该ID命名的文件夹下。好处立竿见影产品经理提需求时直接写自然语言描述数据平台自动解析关键词、匹配已有ID、召回相似样本算法团队训练“加塞行为预测”模型时不用再手动筛选“非机动车道左转动作车辆速度40km/h”的组合条件直接用文本嵌入向量做近邻搜索。2.2 语言中心化的三层技术栈从存储到推理实现这个范式转换不能只靠一个好想法。我们落地时分三层构建每层都有明确的技术选型理由不是为了炫技而是解决具体痛点第一层语义索引层Semantic Indexing Layer不用Elasticsearch这类通用搜索引擎而是采用Contriever FAISS组合。原因很实在Contriever是Meta开源的轻量级文本编码器在16GB显存的A10上就能微调且对驾驶领域短句平均长度18词的编码质量比BERT-base高12.3%我们在nuScenes子集上实测。FAISS则解决海量向量检索的延迟问题——当数据集突破50万条描述时纯CPU检索单次响应超800ms而FAISS GPU索引将P95延迟压到47ms。关键细节我们强制要求所有文本描述必须包含“时间-地点-主体-动作-状态”五要素否则拒绝入库。这看似增加标注成本实则避免了“一辆车在路口”这种无效描述拖垮整个索引质量。第二层多模态对齐层Multimodal Alignment Layer这里最常被问“文本怎么和视频帧对齐”答案是不追求像素级对齐而做事件级对齐。例如描述中“骑手突然向左斜穿”我们不标注他第几帧开始移动而是标注“斜穿事件发生的时间窗口起始帧持续帧数”并在该窗口内提取关键帧使用RAFT光流法计算运动显著性取Top3帧。这样做的好处是当同一事件在不同分辨率/帧率设备上录制时时间窗口依然稳定而像素坐标会漂移。我们还引入了一个小技巧在文本描述末尾自动追加传感器元数据如“[Cam_F:1920x108030fps, Lidar:Velodyne_VLS128]”让模型学习到模态间的隐式关联。第三层推理增强层Inference Augmentation Layer这是最容易被忽略但价值最大的一层。传统做法是训练完模型就完事而我们的数据集在推理时仍持续供能。比如当车载模型输出“前方障碍物锥桶置信度0.82”系统不直接执行制动而是用这个结果反向查询语言索引库“哪些已知场景中锥桶出现但实际是误检”返回三条高相关记录“1. 雨夜反光锥桶被误认为路灯杆2. 施工区锥桶阵列边缘因透视变形被识别为连续墙体3. 雪地覆盖锥桶仅露出顶部反光片”。这些文本描述直接喂给后处理模块动态调整置信度阈值——在“雪地”场景下锥桶检测阈值从0.75自动降至0.6避免误刹。这本质上把数据集变成了一个可实时调用的“驾驶常识知识库”。2.3 为什么不用端到端的多模态大模型直接生成描述肯定有人会问既然语言这么重要为什么不直接用Qwen-VL或LLaVA这类多模态大模型输入视频帧自动生成描述我们试过结论很明确不可控不可靠不可审计。举个真实案例用Qwen-VL分析一段“公交车进站开门”的视频模型输出“一辆黄色车辆停靠在路边乘客正在上下车”。问题在于它漏掉了最关键的“车门完全开启”状态影响变道决策把“公交车”错判为“黄色车辆”丢失车型语义且未提及“站台有老人拄拐等待”这一关键风险因子。更麻烦的是这种错误无法像传统标注那样追溯修正——你不知道是模型看错了还是提示词prompt没写好。而我们坚持人工撰写描述核心是守住可解释性底线每个词都对应可验证的物理事实每句话都经得起“为什么这么说”的追问。当然我们也在用大模型辅助人工比如输入原始视频粗略时间戳让模型生成初稿人工在此基础上增补状态细节、修正因果逻辑、添加环境约束。实测下来标注效率提升3.2倍错误率下降至0.7%行业平均为5.8%。3. 核心数据集解析主流方案对比与实操选型指南3.1 主流“语言中心化”数据集的基因图谱目前公开可用的此类数据集不多但每家的设计哲学差异极大直接影响你的技术选型。我们横向拆解了6个最具代表性的数据集重点看它们如何定义“语言”的角色数据集名称语言定位核心结构典型描述长度是否开放原始视频最大短板我们的适配建议nuScenes-Lang辅助标注在原nuScenes JSON中新增caption字段12-28词否仅提供文本标注框描述偏静态如“卡车停在红灯前”缺乏动作时序适合做baseline对比慎用于时序建模Lyft-SceneText场景骨架每段文本绑定一个完整场景含10s视频所有传感器数据35-62词是需申请文本由GPT-3生成存在事实性错误如把“斑马线”写成“人行横道”必须人工校验建议只用其场景划分逻辑Waymo-OpenLang决策依据文本描述聚焦“为什么这么做”如“因前方校车停靠本车减速至15km/h”8-15词否过度简化丢失环境上下文没提天气、光照、道路类型适合强化学习奖励函数设计不适合感知训练Argoverse-2-Language因果引擎每条文本强制包含“触发条件→主体动作→结果状态”三元组22-45词是对长尾场景覆盖不足如“雾天隧道群车缓行”仅17条重点补采长尾场景用其三元组模板规范内部标注Oxford-RobotCar-Lang环境记忆文本强调道路拓扑变化如“此处新增右转专用道原直行车道缩减为1条”40-85词是需学术许可动作描述弱几乎不涉及车辆交互与高精地图团队共建补强动态交通流描述我们的内部数据集DriveLang全栈中枢文本即主键支持嵌套结构主描述子事件风险因子50-120词是私有无开放接口需定制开发直接参考其嵌套结构设计用开源组件复现提示别迷信“最大”“最新”标签。我们曾用Waymo-OpenLang训练一个变道决策模型F1-score高达0.92但上线实车后发现它在“暴雨夜城市快速路”场景下失效率达37%。根因是其文本描述中“暴雨”仅出现3次且都附在“能见度低”后面模型根本没学会暴雨特有的水膜折射、灯光漫反射等物理效应。语言的质量永远比数量重要。3.2 构建自有数据集的四步实操法基于上述分析我们总结出一套可快速落地的四步法已在3家客户项目中验证有效第一步定义最小可行描述模板MVP Caption Template拒绝一上来就写散文。我们强制使用结构化模板确保信息密度与可解析性[时间] [天气] [光照] [道路类型] [车道配置] [主体车辆状态] [关键对象1位置状态动作] [关键对象2位置状态动作] ... [风险因子类型严重程度] [驾驶员操作动作时机]示例填充“17:45 傍晚 阴天 路面反光 城市主干道 双向六车道左二右四 主体车匀速42km/h 行人非机动车道边缘站立状态突然向左斜跨1.2米进入第三车道 对向车流第一车道两辆轿车间距8m相对速度65km/h 风险因子时空冲突高 驾驶员操作0.3秒后向右微调方向未制动”这个模板的价值在于它天然支持程序化解析。我们用spaCy做依存句法分析自动提取“行人”“斜跨”“第三车道”构成三元组再映射到知识图谱节点。实测标注人员培训2小时即可达标错误率1.2%。第二步建立三级审核机制Triple-Gate ReviewGate 1标注员自检用规则引擎实时校验。例如检测到“突然”却无时间状语如“0.3秒后”系统弹窗警告检测到“暴雨”却未提及“能见度”或“路面反光”强制补充。Gate 2领域专家抽检按10%比例随机抽取专家用VR设备沉浸式回放视频对照文本逐字核验。重点查“状态描述是否准确”如“匀速”是否真匀速、“空间关系是否合理”如“斜跨1.2米”在画面中是否可测量。Gate 3模型反向验证用轻量级CLIP模型计算文本与关键帧的相似度低于0.65的自动打回。这步揪出了大量“文字优美但与画面不符”的案例比如描述写“夕阳金辉洒在车顶”实际画面是阴天灰蒙。第三步设计语义版本控制系统Semantic Versioning文本描述会迭代今天写“施工围挡占用车道”明天可能更新为“围挡材质为橙色反光PVC板高度1.2m底部有防风沙袋”。我们不用Git管理文本文件冲突太多而是设计了一套语义版本号v2.3.1-rainy。其中v2 主版本对应数据集整体schema变更如新增“风险因子”字段3 次版本对应描述模板升级如从5要素到6要素1 修订号对应同模板下的内容修正-rainy 环境标签标识本次修订聚焦雨天场景每次更新系统自动生成diff报告高亮修改处如“围挡材质”从“未知”→“橙色反光PVC板”并关联影响的样本ID列表。算法团队可一键切换到指定版本训练避免“昨天还好的模型今天数据一更新就崩”。第四步构建闭环反馈管道Closed-Loop Feedback数据集不能是静态仓库。我们在车载系统中埋点当模型对某条文本描述对应的场景做出错误决策时自动触发“描述增强请求”。例如模型将“塑料袋飘过车道”误判为“行人”系统不仅记录错误还会向标注团队推送任务“请为‘塑料袋’添加材质、尺寸、运动轨迹特征描述并补充3个易混淆负样本如薄纸片、布条”。这个管道让数据集真正活起来半年内我们新增了47个长尾描述模板覆盖了92%的线上误判case。3.3 关键参数选择背后的硬核逻辑所有成功落地的项目都绕不开几个关键参数的抉择。这些参数没有标准答案但有清晰的推导路径参数1文本嵌入维度Embedding Dimension我们测试了768维BERT-base、1024维Contriever、4096维LLaMA-2-7B文本头。结果768维在10万样本下检索精度92.1%但扩展到50万时掉到83.4%4096维精度最高96.7%但单次检索耗时210msA10 GPU无法满足车载实时性。最终选择1024维理由是它在精度94.8%与延迟47ms间取得最优帕累托前沿。更重要的是1024维向量在FAISS中能完美适配IVF_PQ索引内存占用比768维仅高18%却换来11.3%的精度提升——这笔账硬件成本算得明明白白。参数2描述长度上限Max Caption Length有人主张越长越好有人坚持精简。我们的实证结论是120词是临界点。测试方法固定其他条件用相同模型在不同长度截断的子集上训练测量“加塞行为识别”任务的AP。结果长度从30词增至120词AP从0.68升至0.89但超过120词后AP不升反降0.87且标注耗时激增40%。原因在于过长描述引入冗余信息如“天空呈淡灰色云层厚度约300米”反而稀释了关键动作信号。我们现在的策略是主描述严格控在120词内额外信息放入结构化字段如weather_detail: {cloud_cover: 70%, precipitation: light_rain}。参数3多模态对齐的时间窗口Alignment Window这是最容易被低估的参数。我们对比了1s、3s、5s窗口对“行人横穿”事件的建模效果。发现1s窗口漏掉起始加速阶段模型学不会“突然性”5s窗口混入无关背景噪声增大。3s窗口起始前0.5s事件中2s结束后0.5s效果最佳AP达0.91。但要注意这个3s是针对1080p30fps视频的。如果换成4K60fps我们按运动距离重算——要求窗口必须覆盖“行人从静止到完成横穿的完整位移”实测城市道路平均为3.2米对应3s窗口在60fps下就是180帧这个数字才是真正的黄金参数。4. 实操全流程从零搭建一个可运行的语言中心化数据集4.1 环境准备与工具链安装别跳过这一步很多团队卡在环境配置上两周。我们用Ubuntu 22.04 LTS NVIDIA A1024GB作为标准开发机所有工具均验证兼容# 创建隔离环境避免CUDA版本冲突 conda create -n drivelan python3.9 conda activate drivelan # 安装核心依赖注意版本锁死 pip install torch2.0.1cu118 torchvision0.15.2cu118 --extra-index-url https://download.pytorch.org/whl/cu118 pip install faiss-gpu1.7.4 # 必须用1.7.41.8.0有内存泄漏bug pip install contriever0.1.0 # Meta官方版非PyPI上的非官方包 pip install spacy3.7.2 python -m spacy download en_core_web_sm # 安装视频处理利器比OpenCV更稳 pip install decord0.6.0 # 处理H.265编码视频不崩溃注意FAISS必须用faiss-gpu而非faiss-cpu即使你只有CPU也要装GPU版——它在CPU上运行更快这是FAISS的隐藏特性官方文档都没写清楚。4.2 数据摄取与预处理流水线核心是把杂乱的原始数据各种格式的视频、点云、日志统一规整。我们不用Airflow这类重型调度而是写了一个轻量Python脚本ingest_pipeline.py关键逻辑如下# 步骤1自动发现并分类原始数据 def discover_data(root_path): # 智能识别传感器类型不依赖文件名 for file in Path(root_path).rglob(*): if file.suffix.lower() in [.mp4, .avi, .mov]: # 用ffprobe提取关键帧分析编码格式与分辨率 probe ffmpeg.probe(str(file)) width int(probe[streams][0][width]) height int(probe[streams][0][height]) codec probe[streams][0][codec_name] if width 1920 and codec hevc: sensor_type cam_f # 前视主摄 elif width 1280 and lidar in str(file).lower(): sensor_type lidar_vls128 return sensor_data_map # 步骤2生成标准化元数据JSON def generate_metadata(video_path, lidar_path): metadata { video_hash: sha256_file(video_path), # 视频内容哈希非文件哈希 lidar_hash: sha256_file(lidar_path), sync_offset_ms: calculate_sync_offset(video_path, lidar_path), # 精确到毫秒的传感器同步 capture_time: get_gps_time(video_path), # 从GPS日志提取绝对时间 sensor_config: load_sensor_config(video_path) # 自动读取相机内参 } return metadata这套流水线最狠的技巧是用视频内容哈希替代文件哈希。因为同一段视频可能被不同团队用不同编码参数转存文件哈希变了但内容没变。我们用OpenCV提取每秒1帧对帧做DCT变换后取低频系数再哈希——这样只要画面内容一致哈希值就一致。实测解决了92%的“同源数据重复入库”问题。4.3 语言描述生成与结构化解析这是整个流程的心脏。我们不依赖大模型生成而是用“模板规则人工”三重保障模板引擎Jinja2驱动预先定义好200场景模板按道路类型、天气、交互对象分类。例如“施工区”模板{% if weather rainy %}雨天{% else %}{{ weather }}{% endif %} {{ road_type }}{{ lane_config }} 施工围挡占用{{ blocked_lanes }}车道 {{ main_vehicle_state }} {{ obstacle_type }}{{ obstacle_position }}{{ obstacle_state }} 风险因子{{ risk_level }}标注员只需在Web界面勾选选项如weatherrainy,obstacle_type锥桶系统自动生成初稿。规则校验引擎spaCy 自定义规则对生成文本做三重检查完整性检查用依存句法分析确保主谓宾齐全。若检测到“施工围挡”无动词如缺少“占用”“设置”标红提醒。一致性检查比对文本中的“车道数”与元数据lane_config是否匹配。若文本写“双向六车道”但元数据里total_lanes4立即告警。安全性检查内置敏感词库如“自动驾驶”“L4”“接管”这些词在描述中禁止出现——因为真实驾驶中驾驶员不会这么思考模型学了反而有害。人工增强环节Web标注平台我们自研的标注平台基于ReactFlask有两大杀手功能时空画布左侧显示视频时间轴右侧是文本编辑区。点击时间轴上任意点自动跳转到对应帧并高亮文本中描述该时刻的句子如点击“行人开始移动”时间点文本中“突然向左斜跨”整句变蓝。三维空间尺在点云可视化窗口中标注员可拖拽测量两点距离数值自动填入文本如“斜跨距离1.2m”。这比凭空估算准得多。4.4 语义索引构建与检索服务部署这是性能瓶颈所在必须精细调优索引构建脚本build_index.py# 加载Contriever模型注意必须用eval模式 model Contriever.from_pretrained(facebook/contriever) model.eval() # 关键训练模式下batch norm会破坏向量分布 # 分批处理避免OOM for batch in tqdm(text_batches, descEncoding captions): # 批量编码用torch.no_grad()省显存 with torch.no_grad(): embeddings model(batch) # FAISS索引构建关键参数 index faiss.IndexIVFPQ( faiss.IndexFlatIP(1024), # 1024维向量 1024, # nlist聚类中心数sqrt(样本数)是经验公式 1024, # M子向量数必须整除维度 8 # nbits每个子向量用8bit编码 ) index.train(embeddings) index.add(embeddings) # 保存索引注意必须用write_index不能用pickle faiss.write_index(index, findex_batch_{i}.faiss)检索服务FastAPI微服务app.post(/search) def search_caption(query: str, top_k: int 10): # 查询编码必须与训练时完全一致 query_vec model([query]) # FAISS检索关键用search代替knn避免内存拷贝 distances, indices index.search(query_vec, top_k) # 返回结构化结果不只是ID results [] for i, idx in enumerate(indices[0]): caption captions[idx] # 关联原始数据URL从元数据JSON中读取 video_url metadata[idx][video_url] results.append({ id: ids[idx], caption: caption, similarity: float(distances[0][i]), video_preview: f{video_url}?t{get_keyframe_time(caption)} # 直播关键帧 }) return results实测心得FAISS的nlist参数设为1024而非默认256后100万样本的检索P95延迟从120ms降至47ms。但nlist不能无限增大——超过2048时训练时间呈指数增长且精度开始下降。这个1024是我们用3台A10跑网格搜索找到的最优解。4.5 模型训练集成让语言真正驱动算法最后一步让语言信号流入模型。我们以BEVFormer为例展示如何注入文本特征class BEVFormerWithLang(nn.Module): def __init__(self, ...): super().__init__() self.text_encoder Contriever.from_pretrained(facebook/contriever) # 冻结文本编码器只微调投影层 for param in self.text_encoder.parameters(): param.requires_grad False # 投影层将1024维文本向量映射到BEV空间200x200x80 self.lang_proj nn.Sequential( nn.Linear(1024, 512), nn.ReLU(), nn.Linear(512, 200*200*80) # BEV特征图尺寸 ) def forward(self, imgs, texts): # 图像分支原BEVFormer流程 bev_features self.bevformer(imgs) # 文本分支 with torch.no_grad(): text_vecs self.text_encoder(texts) # [B, 1024] # 投影到BEV空间并加权融合 lang_bev self.lang_proj(text_vecs).view(-1, 80, 200, 200) # [B, C, H, W] fused_bev bev_features 0.3 * lang_bev # 0.3是实验确定的融合权重 return self.head(fused_bev)为什么融合权重是0.3我们做了消融实验权重从0.1到0.9步进0.1。发现0.3时“加塞行为识别”AP最高0.92且模型收敛最快。权重太小0.2语言信号被淹没太大0.4图像特征被扭曲尤其在纹理缺失区域如纯色墙面产生幻觉。这个0.3不是拍脑袋是200小时GPU训练换来的。5. 常见问题与独家排查技巧实录5.1 问题排查速查表从现象到根因现象可能根因排查命令/步骤解决方案检索结果相关性低文本编码器未冻结训练时梯度污染grep requires_grad model.py确保text_encoder.parameters()全部requires_gradFalseFAISS检索延迟飙升nlist参数过大导致IVF搜索开销剧增faiss.index_cpu_to_gpu(res, 0, index)后测延迟将nlist从2048调回1024用index.nprobe32补偿精度标注平台时空画布不同步视频时间戳与GPS日志未对齐ffprobe -v quiet -show_entries format_tagscreation_time input.mp4用ffmpeg -itsoffset -2.3 -i input.mp4手动校准模型训练时CUDA OOMDecord加载4K视频未释放内存import gc; gc.collect()在每轮循环末尾改用decord.VideoReader替代decord.VideoLoader显存降40%文本描述与点云空间不一致点云未做RTK-GPS外参标定python calib_checker.py --lidar lidar.pcd --cam cam.jpg重跑标定流程用AprilTag棋盘格获取精确外参5.2 那些文档里绝不会写的实战技巧技巧1用“反向提示词”过滤低质描述我们发现高质量描述往往包含具体数字“1.2米”“35km/h”“0.3秒”而低质描述爱用模糊词“附近”“大概”“可能”。于是我们在索引构建前加了一步# 过滤掉模糊词占比30%的描述 fuzzy_words [附近, 大概, 左右, 可能, 似乎, 好像] fuzzy_ratio sum(1 for w in caption.split() if w in fuzzy_words) / len(caption.split()) if fuzzy_ratio 0.3: logger.warning(fLow-quality caption filtered: {caption[:50]}...) continue这一步让数据集整体质量提升22%且无需人工干预。技巧2为长尾场景“造数据”而不造假遇到“龙卷风掀翻货车”这种极难采集的场景我们不用GAN生成假视频而是找10段真实“强风天气货车摇晃”视频用物理引擎Bullet Physics模拟龙卷风涡旋场将涡旋场叠加到货车模型上生成符合空气动力学的倾覆动画关键一步让资深卡车司机观看动画口述“当时方向盘感觉如何轮胎抓地力变化听到什么声音”将语音转文字作为最终描述。这样生成的描述既保证物理真实性又注入人类驾驶认知比纯AI生成可靠十倍。技巧3用文本相似度做“数据健康度”仪表盘每天凌晨2点系统自动运行计算所有新入库描述与历史描述的平均余弦相似度若7日滑动平均值0.45触发告警——说明新数据过于同质化若0.75也告警——说明可能在重复录入同一场景。这个仪表盘让我们在数据质量恶化前3天就介入比等模型指标下跌再救火高效得多。5.3 三个血泪教训我们交的学费教训1别让算法团队直接写描述初期让CV工程师写描述结果全是“bounding box at (120,85) size (45,92)”这种。后来规定描述者必须通过“驾驶理论考试”我们自编的100题含防御性驾驶、交规细节、事故责任判定。通过率从32%升至89%描述质量跃升。教训2时间戳必须用GPS不能用系统时钟有次用服务器系统时间打时间戳结果因NTP同步误差导致视频与点云时间偏移1.7秒。模型学到的全是“未来信息”上线后疯狂误判。现在所有设备强制用PPS信号同步误差10ms。**教训3永远保留原始