想象你刚接到出租车公司的特殊任务：公司不给你装导航，也不发纸质地图，只让你开着一辆新车去一座完全陌生的城市接客，条件是你必须边开车边在脑子里画地图。你每过一个路口就记一笔，每驶过一段直路就画一条线。几小时后，你脑中的地图居然比公司档案柜里那份三年前印刷的城市图还要新鲜。这就是在线建图（Online Mapping）的精髓——让自动驾驶汽车不再依赖出厂时预装的“死地图”，而是用自己的眼睛（传感器）和大脑（深度学习模型），在路上实时画出属于自己的“活地图”。 高精地图原本是自动驾驶的“秘密武器”：它包含车道线、停止线、路沿、路口等厘米级细节，比普通导航地图精细得多。但传统离线建图需要专业采集车跑遍全城、人工标注、反复校验，地图到手时城市可能已经变了样。以 HDMapNet 和 MapTR 为代表的在线建图技术，把“画地图”这件事搬到了车端，让车辆一边行驶一边构建局部地图，既新鲜又省钱。这篇文章会用“会画地图的司机”这个比喻，带你走一遍从传感器感知到向量化地图输出的完整技术路线。

岗位关联

对 AI 从业者而言，在线建图是自动驾驶感知与高精地图交叉领域最热的方向之一，理解 HDMapNet 与 MapTR 的建模思路，能帮你快速上手车端感知、向量化输出和多传感器融合相关的实际工程问题。

目录
  1. 可视化演示
  2. 在线建图概述
  3. 感知与BEV
  4. HDMapNet原理
  5. MapTR创新
  6. 拓扑关系
  7. 实时性权衡
  8. 系统应用价值
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示在线建图流水线：多传感器BEV特征经HDMapNet语义分割实例嵌入或MapTR端到端Transformer回归矢量化折线，含实时性精度权衡曲线与六边网格背景动画。

本节配有交互动效（进入视口后自动加载，约 3KB）。

在线建图概述

一位经验丰富的老司机开进陌生城市，第一件事不是翻地图，而是先跑两圈：哪条路是单行道、哪个路口早晚高峰会堵、哪条捷径能省五分钟，全都记在脑子里。这套“边开边记”的本事，就是在线建图的雏形。自动驾驶领域的高精地图，相当于给汽车准备的“毫米级城市图纸”——它不仅要画出路网，还要精确到车道线、停止线、路沿和路口的几何位置，误差通常要求控制在厘米级。

传统离线建图怎么做的呢？就像出版社派专人开车把全城拍一遍，再拿回编辑部人工描图、校对、印刷，最后发给每一辆车。这个流程往往耗时数周甚至数月，而城市道路每周都在变：围挡施工、标志重画、车道改线。等图纸送到司机手里，可能已经过时了。在线建图的思路完全不同：让每辆车利用自己的摄像头和激光雷达，在行驶途中实时构建局部高精地图，用完即走、边走边更新。

这项技术最大的难点在于“快”和“全”的平衡。车辆必须在上百毫秒内完成从原始图像到局部地图的全部计算，同时保证车道线、路沿等关键元素一个都不能漏。在线建图并不是要完全取代离线地图，而是作为离线地图的“新鲜补充”——离线提供全局框架，在线负责实时修正。

这三个环节像流水线上的三道工序，任何一道变慢，整张“活地图”送到方向盘手里就晚了。延迟控制得住，司机脑子里这张图才跟得上车轮的速度。

Tlatency=Tsense+Tbuild+Tpublish\displaystyle T_{\text{latency}} = T_{\text{sense}} + T_{\text{build}} + T_{\text{publish}}
在线建图的端到端延迟，等于感知、建图、发布三个阶段耗时之和。任何一段拖延都会让车辆决策“反应迟钝”。
  1. 感知耗时传感器从捕捉光线到输出特征图所花的时间，好比司机用眼睛看清路况的用时。
    TsenseT_{\text{sense}}
  2. 建图耗时神经网络把特征转换成地图元素所需的时间，如同司机在脑中把看到的路口画成线条。
    TbuildT_{\text{build}}
  3. 发布耗时把构建好的局部地图送入规划模块的时间，相当于司机把新路线“记牢”并交给手脚执行。
    TpublishT_{\text{publish}}

感知与BEV

司机坐在驾驶座上，眼睛看到的画面是斜前方45度的透视视图——路面在画面里由宽变窄、车道线在前方汇聚成一点。但要画出一张好用的地图，光有前后左右四块“透视画面”远远不够。聪明的司机会在脑中自动切换到“上帝视角”：想象自己站在十层楼顶往下看，路面变成俯视图，车道线变成平行线，路口变成清晰的十字。这个“上帝视角”，在自动驾驶里叫作鸟瞰视角，也就是 BEV（Bird's Eye View）。

怎么从四幅环视图像拼出俯视图？靠的是相机标定参数。每一路摄像头都有自己的内参（焦距、主点）和外参（安装位置、朝向），把像素坐标投影到车身坐标系，再映射到一张统一的俯视栅格上。激光雷达的点云本身就是三维的，可以直接叠加进 BEV 网格。这样一来，不同传感器的信息被对齐到同一张“俯视画布”上，后面的建图模型就只需处理一张二维特征图，而不用同时应对四路透视画面。

BEV 的另一个好处是“尺度一致”：在俯视图里，车道线的宽度不会因为距离远近而改变，模型学习起来更稳定。就像司机看楼顶视图画地图，每条路的宽度和走向都一目了然，不会因为透视变形而画歪。

理解了投影的来龙去脉，再看 BEV 就简单了：它就是把“拍扁”的透视照片重新“摊平”成俯视图。司机在脑中做的正是这个逆变换，只不过他做了一万次，已经成了本能。

[uv1]=K[R∣t][XYZ1]\displaystyle \begin{bmatrix} u \\ v \\ 1 \end{bmatrix} = K \left[ R \mid t \right] \begin{bmatrix} X \\ Y \\ Z \\ 1 \end{bmatrix}
这是相机投影方程：世界坐标系中的一个三维点，通过外参旋转平移、内参缩放平移，最终落在图像像素坐标上。BEV 变换就是把这个过程的逆过程反复运用，把所有像素“摊”回俯视平面。
  1. 三维世界点路面上的一个真实点，记作 $(X, Y, Z, 1)^\top$，它代表“世界坐标系里那个位置有什么”。
    [XYZ1]\begin{bmatrix} X \\ Y \\ Z \\ 1 \end{bmatrix}
  2. 外参矩阵变换矩阵 $[R \mid t]$ 把这点的世界坐标换算成相机坐标，相当于告诉司机“这个点在摄像头前方多远、偏左多少”。
    [R∣t]\left[ R \mid t \right]
  3. 内参矩阵投影矩阵 $K$ 把相机坐标投影成图像像素坐标 $(u, v, 1)^\top$，相当于把三维世界“拍扁”到相机的二维照片上。
    K[XYZ1]→[uv1]K \begin{bmatrix} X \\ Y \\ Z \\ 1 \end{bmatrix} \rightarrow \begin{bmatrix} u \\ v \\ 1 \end{bmatrix}

HDMapNet原理

如果让新手司机画地图，他大概率会先拿彩笔把路面涂满颜色：白色虚线涂成浅灰、黄色实线涂成亮黄、路沿石涂成深蓝。涂完色再沿着色块边缘描线，得到一张“色块地图”。HDMapNet 的思路就是这样——先用神经网络对 BEV 特征图做像素级分类，判断每一个栅格属于车道线、路沿、人行道还是背景。

网络的主干通常是一个编码器-解码器结构：编码器把环视图像压缩成高维特征，解码器把特征上采样回原分辨率，输出逐像素的分类概率。这一步本质上就是语义分割，只不过 Segmentation 的对象从“人、车、树”换成了“地图元素”。分类完成后，HDMapNet 还需要做“描边”工作：把属于同一根车道线的像素聚类起来，用折线或多边形拟合成几何元素。这就像把色块地图拿给画师，画师沿着色块边缘描出正式的道路线稿。

问题也随之而来：像素级分类和后处理是两套流程，任何一个环节的误差都会累积。比如一条车道线在分割图里断成两截，聚类时就被当作两根线；路沿被树荫遮挡时，分割结果会出现空洞。后处理规则写起来又长又脆，遇到下雨反光、车道线磨损的情况就容易“画崩”。这也让 HDMapNet 的精度和实时性都不太理想。

F1 分数就像给司机的“画图考核”：既不能乱画冤枉路（误检），也不能漏掉必经之路（漏检）。HDMapNet 在两项之间摇摆，说明“先涂色再描边”的画法确实不够利落。

F1=2×Precision×RecallPrecision+Recall\displaystyle F_1 = \frac{2 \times \text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}}
F1 分数是衡量建图质量的核心指标：它同时惩罚“画了不该画的线”（误检）和“漏画了该画的线”（漏检），是精度和召回率的调和平均。
  1. 精确率模型画出的线里，有多少条是真实存在的路，记作 Precision。
    Precision=TPTP+FP\text{Precision} = \frac{TP}{TP + FP}
  2. 召回率真实存在的路里，模型找回了多少条，记作 Recall。
    Recall=TPTP+FN\text{Recall} = \frac{TP}{TP + FN}
  3. 调和平均把精确率和召回率折中成一个综合分数，两个指标都高时 F1 才高。
    2×Precision×RecallPrecision+Recall\frac{2 \times \text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}}

MapTR创新

有经验的画图师傅不会先涂色再描边，而是直接用记号笔在透明纸上画线：一笔下去，就是一条路。MapTR 正是这个思路——它不再输出像素色块，而是直接输出一组有序的点序列，每个点有明确的坐标，点按顺序连起来就是一条车道线或路沿。这种表达方式叫作向量化地图元素。

向量化听起来抽象，实际效果很直观：一条车道线从“几万个像素组成的色块”变成“十几个点的坐标列表”。存储量小了几十倍，后续的规划模块拿到的也不再是图像，而是可以直接计算的折线。MapTR 把建图从“画像素画”升级成“画矢量图”，就像司机从用蜡笔涂色，换成了用数位板画 CAD 图纸。

要让网络直接输出点序列，训练时必须解决一个关键问题：模型预测出 10 条线，真值也有 10 条线，怎么知道哪条预测线对应哪条真值线？MapTR 用匈牙利算法做实例级匹配，遍历所有配对方案，找出总差异最小的一组对应关系。这个匹配过程只发生在训练阶段，推理时模型直接输出线，因此端到端且高效。

这个匹配过程，像极了老师批改地图作业：先判断学生画的第几条线对应标准答案的第几条线，再逐条打分。匹配对了，训练梯度才能传到正确的预测头上，模型才能越画越准。MapTR 的另一大亮点是分层查询：先做“实例查询”找到每条线的整体位置，再做“点查询”细化线上每个点的坐标，两层配合让输出既稳定又精细。

σ^=arg⁡min⁡σ∈ΘN∑i=1NLmatch(yi,y^σ(i))\displaystyle \hat{\sigma} = \arg\min_{\sigma \in \Theta_N} \sum_{i=1}^{N} \mathcal{L}_{\text{match}} \left( y_i, \hat{y}_{\sigma(i)} \right)
匈牙利匹配的数学表达：在所有可能的“预测线—真值线”配对方案中，挑选总匹配代价最小的一种，用它作为监督信号训练网络。
  1. 预测与真值集合模型输出 $N$ 条预测线，真值也有 $N$ 条线，两列“名单”需要一一对应。
    y^={y^1,…,y^N},y={y1,…,yN}\hat{y} = \{ \hat{y}_1, \dots, \hat{y}_N \}, \quad y = \{ y_1, \dots, y_N \}
  2. 所有配对方案$\Theta_N$ 表示 $N!$ 种排列，每种排列就是一种配对方式。
    σ∈ΘN\sigma \in \Theta_N
  3. 最小总代价对每种配对方式求所有线对的差异之和，取最小者作为最优匹配。
    σ^=arg⁡min⁡σ∑i=1NLmatch(yi,y^σ(i))\hat{\sigma} = \arg\min_{\sigma} \sum_{i=1}^{N} \mathcal{L}_{\text{match}} \left( y_i, \hat{y}_{\sigma(i)} \right)

拓扑关系

画完道路线，地图其实只完成了一半。司机能用地图导航，靠的不只是“这里有一条路”，更关键的是“这条路右转能接上那条路”。道路之间的连接关系，在自动驾驶里叫作拓扑关系。想象一张城市地铁图：站点是顶点，线路是边，你要从 A 站到 B 站，靠的就是这张图的可达性。高精地图的拓扑也一样——把每段车道、每个路口看成节点，把允许的通行关系看成边。

拓扑关系对路径规划至关重要。自动驾驶的规划模块拿到向量化地图后，需要知道“当前车道前方是直行、左转还是必须变道”，十字路口哪几个方向可以通行，是否有禁止掉头标志。这些信息都藏在拓扑图里。MapTR 在输出向量元素的同时，也会预测元素之间的连接关系，把孤立的线装配成一张连通的路网。

在线建图的拓扑还有一个天然优势：它可以随时更新。离线地图遇到临时封路只能干瞪眼，而在线建图的车发现前方路口被围挡堵住，立刻就能在拓扑图里删掉那条边，通知规划模块绕行。就像老司机发现常走的路封了，马上换一条巷子钻过去，根本不耽误事。

有了拓扑，画线才升级成画网。对导航而言，“线”只回答了那里有什么，“网”才回答了怎么走。在线建图的终极目标，就是让每一辆车都拥有一张随时可改的活路网。

G=(V,E),E⊆{(vi,vj)∣vi,vj∈V}\displaystyle G = (V, E), \quad E \subseteq \{ (v_i, v_j) \mid v_i, v_j \in V \}
拓扑图 $G$ 由顶点集合 $V$ 和边集合 $E$ 构成。$V$ 是车道或路口的集合，$E$ 是它们之间允许通行的连接关系。
  1. 顶点集合把每段车道、每个路口抽象成图的顶点，记作 $V$。
    V={v1,v2,…,vn}V = \{ v_1, v_2, \dots, v_n \}
  2. 边集合两个顶点之间存在可通行关系时，就有一条边连接它们，所有边组成 $E$。
    E={(vi,vj)∣vi 可通行到 vj}E = \{ (v_i, v_j) \mid v_i \text{ 可通行到 } v_j \}
  3. 整体图结构顶点和边合起来构成拓扑图，规划算法在这张图上搜索路径。
    G=(V,E)G = (V, E)

实时性权衡

老司机画地图和乘客聊着天就能完成，但自动驾驶没有这么从容——它必须在行驶的同时完成感知、建图、规划、控制整个过程，其中任何一步慢于上百毫秒，车辆就可能错过刹车时机。在线建图作为中间环节，必须承受“边开车边画图”的苛刻约束。

为了压低延迟，工程上有一系列手段。首先是模型轻量化：用轻量骨干网络替代重型分类网络，牺牲少量精度换取成倍的速度。其次是单帧推理：MapTR 这类端到端模型从图像输入到地图输出只需一次前向传播，不像 HDMapNet 那样分割、聚类、拟合各跑一遍。再者是控制后处理开销：向量化输出直接可用，免去把像素转折线的步骤，就像记号笔画完不用再描边。

当然，实时性不是无限压榨的。过度轻量化会导致车道线断裂、路口元素漏检，反而增加下游规划的风险。真正的工程经验是在精度和速度之间找平衡点：高速场景要求更快，低速泊车场景可以稍微“慢工出细活”。一句话总结：地图画得再漂亮，如果送到方向盘手里时车已经撞了，那就毫无意义。

如果司机画一帧地图要花整整一秒，车速 60 公里/时下车辆已经冲出 16 米，足够撞上前方的障碍物。所以在线建图的天平上，速度的砝码往往比精度更重。

FPS=1Tinfer+Tpost\displaystyle \text{FPS} = \frac{1}{T_{\text{infer}} + T_{\text{post}}}
每秒可处理的帧数等于推理时间和后处理时间之和的倒数。帧率越高，车辆能越快拿到新鲜地图。
  1. 推理时间神经网络从输入图像到输出向量地图所需的时间，记为 $T_{\text{infer}}$。
    TinferT_{\text{infer}}
  2. 后处理时间对网络输出做过滤、微调等操作的时间，记为 $T_{\text{post}}$。
    TpostT_{\text{post}}
  3. 帧率换算两者相加取倒数，就是系统的实时帧率。
    1Tinfer+Tpost\frac{1}{T_{\text{infer}} + T_{\text{post}}}

系统应用价值

如果把在线建图装进一支网约车队，每辆车都成了“会画活地图的司机”。它们白天接客，晚上收车时把一天跑过的道路更新上传到云端，车队地图库就自动刷新了一遍。这种众包建图模式，彻底改变了高精地图的商业模式：不需要造价上千万的采集车，不需要漫长的出版周期，每一辆普通运营车都是移动的测绘员。

成本降低之外，在线建图还带来了场景泛化能力。离线地图覆盖不到的新城区、矿区、港口、地下停车场，车辆驶入即可边开边建图，几分钟内获得可用地图。正如新司机不用等印刷厂发货，开车转一圈就是一张新鲜图纸。对于 Robotaxi 在新区开城运营，这种能力意味着部署周期从“等地图半年”缩短到“试跑几天”。

动态更新更是离线地图无法企及的优点。道路施工、临时管制、运动会封路，这些变化在分钟级就能被在线建图捕获，并立即同步给同一区域的其他车辆。未来的趋势是车路协同：路侧设备也参与地图补充，车与路互相印证，让“活地图”越用越聪明。就像老司机们共享路况暗号，整个城市的交通脉络都在一刻不停地自我刷新。

当一支一万辆的车队每辆花几千元做软件升级，而传统采图车一套就要几千万元时，这个比值的优势不言自明。在线建图让高精地图从“奢侈品”变成了“日用品”，每个司机都在画图，每张地图都在生长。

Cfleet=Nvehicles×CperCsurvey\displaystyle C_{\text{fleet}} = \frac{N_{\text{vehicles}} \times C_{\text{per}}}{C_{\text{survey}}}
车队众包建图的总成本，等于参与车辆数与单车改造成本之积，再除以传统专业采集车的全套成本。当这个比值远小于 1 时，众包模式的成本优势就非常明显。
  1. 单车成本每辆运营车加装计算单元和软件授权的成本，记为 $C_{\text{per}}$。
    CperC_{\text{per}}
  2. 车队总成本乘以参与车辆数 $N_{\text{vehicles}}$，得到整个车队的建图投入。
    Nvehicles×CperN_{\text{vehicles}} \times C_{\text{per}}
  3. 相对成本比与传统采图总成本 $C_{\text{survey}}$ 相除，衡量众包模式的性价比。
    Nvehicles×CperCsurvey\frac{N_{\text{vehicles}} \times C_{\text{per}}}{C_{\text{survey}}}

AI 应用场景

自动驾驶出租车队开城部署

阶段：感知与地图构建

解决的问题：传统 Robotaxi 进入新城市，需要等待专业采图车完成高精地图采集，周期长达数月，严重拖慢开城节奏。在线建图让车辆在试运行阶段就同步建图，传感器所见即所得，地图随车队运营不断累积，把开城部署周期从数月压缩到数天。

具体案例：某 Robotaxi 公司在二线城市新开运营区域，首周先投放 20 辆搭载 MapTR 方案的测试车。车辆白天按固定路线跑图，晚上把新采集的向量化地图上传云端融合。一周后，该区域的地图新鲜度和覆盖率已超过三个月前离线采集的版本，车队正式开启收费运营。

矿区与港口无人驾驶快速部署

阶段：实时建图与定位

解决的问题：矿区、港口道路变化频繁，且没有公开地图数据，离线建图不现实。在线建图可在作业车辆首趟运行时就构建局部向量地图，并随着每趟运输实时更新，适配矿坑改道、堆料位置变化等动态场景。

具体案例：某港口部署无人集卡，作业区因施工临时封闭一条通道。集卡通过在线建图检测到路障后，自动更新局部地图的拓扑结构，在第二次经过时直接选择备用通道，全程无需人工介入，作业效率仅下降 3%。

城市级众包高精地图更新服务

阶段：地图数据闭环

解决的问题：高精地图的最大成本是维护——修路和改道每天都在发生。众包在线建图让普通运营车辆充当“众包测绘员”，后台自动收集各车上传的局部地图增量，与旧版地图做差集融合，生成更新的图层，大幅降低地图鲜度维护成本。

具体案例：一家地图服务商与网约车平台合作，利用十万辆运营车的行车记录仪数据，每天自动检测城市道路变更事件。某路口新增一条左转待转车道后，系统在 48 小时内完成“发现—验证—更新—发布”全流程，而旧流程需要两个月。

Python 演示

python67 行
import numpy as np def simulate_bev(lines, size=64):    """把若干条像素车道线画到 BEV 二值栅格上"""    grid = np.zeros((size, size), dtype=int)    for pts in lines:        for x, y in pts:            if 0 <= x < size and 0 <= y < size:                grid[y, x] = 1    return grid def pixel_to_vector(grid, gap=2):    """把 BEV 栅格中的前景像素聚类成若干条折线，并压成向量线"""    ys, xs = np.where(grid > 0)    if len(xs) == 0:        return []    order = np.argsort(xs)    xs, ys = xs[order], ys[order]    lines = []    cur = [(int(xs[0]), int(ys[0]))]    for i in range(1, len(xs)):        if abs(xs[i] - xs[i - 1]) <= gap and abs(ys[i] - ys[i - 1]) <= gap:            cur.append((int(xs[i]), int(ys[i])))        else:            lines.append(cur)            cur = [(int(xs[i]), int(ys[i]))]    lines.append(cur)    vec = [[line[0], line[-1]] for line in lines if len(line) >= 2]    return vec def match_lines(pred, gt, max_d=5):    """用贪心最近邻匹配预测线与真值线（简化版匈牙利匹配）"""    used = set()    matched = 0    for p in pred:        best = float("inf")        best_g = None        for gi, g in enumerate(gt):            if gi in used:                continue            d = min(np.hypot(p[0][0] - g[0][0], p[0][1] - g[0][1]),                    np.hypot(p[1][0] - g[1][0], p[1][1] - g[1][1]))            if d < best:                best = d                best_g = gi        if best <= max_d:            matched += 1            used.add(best_g)    return matched def f1_score(matched, n_pred, n_gt):    """根据匹配数计算 F1 分数"""    prec = matched / max(n_pred, 1e-6)    rec = matched / max(n_gt, 1e-6)    return 2 * prec * rec / (prec + rec) if __name__ == "__main__":    gt_lines = [        [(10, 20), (20, 22), (30, 24), (40, 26)],        [(10, 50), (20, 48), (30, 46), (40, 44)],    ]    bev = simulate_bev(gt_lines)    pred_lines = pixel_to_vector(bev)    m = match_lines(pred_lines, gt_lines)    print("预测向量线:", pred_lines)    print("匹配数:", m, "预测数:", len(pred_lines), "真值数:", len(gt_lines))    print("F1 分数:", round(f1_score(m, len(pred_lines), len(gt_lines)), 3))
目的：演示从 BEV 像素分割图到向量地图线，再到实例匹配与 F1 评估的完整流程，帮助你直观理解 HDMapNet 与 MapTR 的核心环节。
  1. simulate_bev(gt_lines)把真值线条画成一张二值栅格图，模拟分割网络输出。
  2. pixel_to_vector(bev)把前景像素按连通性聚类，每段只保留首尾点，完成“像素→向量”压缩。
  3. match_lines(pred, gt)依次为每条预测线找最近的真值线，模拟训练时的实例匹配。
  4. f1_score(matched, ...)用匹配结果计算精确率、召回率和 F1，对应建图质量评估。
  5. if __name__ == "__main__":定义两条真值车道线，跑通“感知→向量→匹配→评估”全流程。

常见误区

误区“SLAM 不就是建图吗？在线建图应该跟 SLAM 是一回事。”

正解SLAM 解决的是“机器人我在哪、周围几何结构什么样”的定位与几何构图问题，输出通常是点云或占据栅格；在线建图输出的是带语义和拓扑的向量化高精地图，比如车道线、路沿、路口连接关系。打个比方：SLAM 是司机摸黑记住了“左边有墙、右边有柱子”，在线建图是司机明确知道“右侧是双黄实线，前方路口可以左转”。后者才是能直接喂给规划模块的高层地图。

为何常见：两者都涉及“建图”二字，且现代系统常把 SLAM 和在线建图叠加使用，初学者容易混淆层级关系。

误区“分割图看起来已经很准了，直接用不行吗？还需要什么后处理？”

正解分割图是逐像素的分类概率，没有实例信息。一条车道线在分割图里断成几截，模型并不知道它们属于同一根线；两条相邻车道线粘连在一起，模型也无法自动切开。必须经过聚类、拟合、拼接等后处理才能得到几何元素，而这些规则在车道线磨损、雨天反光、树荫遮挡时极易出错。这也是 MapTR 直接输出向量实例能胜出的原因。

为何常见：分割图在人眼看来“颜色分明”，但人眼能自动补全断线，机器没有这种先验。

误区“MapTR 直接预测点坐标，不需要配对吧？”

正解推理时确实不需要，但训练时必须有。网络预测的 10 条线与标注的 10 条线顺序不确定，必须先用匈牙利算法找到最优的一一对应关系，才能计算损失并回传梯度。没有这一步，训练根本收敛不了。就像老师批改学生作业，得先搞清楚学生写的第 3 题对应标准答案的第 3 题，才能打分。

为何常见：很多人只关注推理链路，忽略了训练阶段的人工设计，误把“端到端推理”理解成“全程无监督”。

误区“高精地图当然越精确越好，少一个厘米都不行。”

正解在在线建图的场景下，精度必须为实时性让路。车辆的安全决策周期只有几十到上百毫秒，地图构建时间过长会让规划模块拿到过时信息，反而更危险。工程上常用“够用就好”的原则：车道线宽度误差几厘米不影响跟车和变道决策，但多花 50 毫秒后处理却可能错过刹车时机。快而稍粗的活地图，胜过慢而精细的死地图。

为何常见：离线高精地图时代，“精度”是唯一的硬指标，不少从业者把这条惯性思维带到了在线场景。

误区“既然能边开边画，那离线高精地图是不是没用了？”

正解在线建图只能感知车辆周围百米左右的局部区域，视距外还有大量盲区；而离线地图提供了全局路网、限速标志、车道数变化等先验信息。两者是互补关系：离线地图给“骨架”，在线建图给“新鲜血肉”。就像出租车司机既需要脑中的城市整体路网，也需要边开边观察眼前的临时路况，缺一不可。

为何常见：把“在线”理解为“取代离线”，忽视了感知范围受限的物理现实。

面试题

Q1. 在线建图相比传统离线高精地图，最突出的优势是？

单选题 · easy

  • A.地图可以实时更新← 正确答案
  • B.制图精度极大提升
  • C.使用更少的传感器
  • D.不再需要人工标注

答案：A。在线建图的核心价值是“边开边画”，地图实时更新，能反映刚发生的道路变化。精度提升、传感器减少、免标注都不是在线建图的本质优势。就像会画活地图的司机，优势在于图永远新鲜，而不是画得比印刷厂还精美。

Q2. 环视相机采集的透视图像要转换到统一视角，这个统一视角通常称为？

单选题 · easy

  • A.称为鸟瞰BEV视角← 正确答案
  • B.称为前视透视视角
  • C.称为侧视全景视角
  • D.称为后视盲区视角

答案：A。BEV 全称 Bird's Eye View，即鸟瞰视角，是从车顶上方往下看的俯视图。前视/侧视/后视都还是透视图，存在近大远小变形，只有 BEV 能让车道线保持平行关系，方便后续地图构建。

Q3. HDMapNet 对 BEV 特征图做像素级分类，这一步本质上属于？

单选题 · mid

  • A.语义分割计算← 正确答案
  • B.目标检测框架
  • C.实例聚类算法
  • D.点云配准过程

答案：A。HDMapNet 对每个像素判断它是车道线、路沿还是背景，这是典型的语义分割任务。目标检测输出框、实例聚类输出实例分组、点云配准对齐传感器，都不是像素级地图元素分类。

Q4. MapTR 用一组有序点表示一条车道线，这种表达方式称为？

单选题 · mid

  • A.向量化表达方式← 正确答案
  • B.栅格化表达方式
  • C.体素化表达方式
  • D.参数化表达方式

答案：A。MapTR 把车道线建模成一个点序列，点与点相连成折线，直接存储坐标，属于向量化表达。栅格化是像素网格，体素化是三维网格，参数化是用函数参数描述形状，都不是 MapTR 的核心表达。

Q5. MapTR 训练时用匈牙利算法，主要解决的问题是？

单选题 · mid

  • A.预测与真值的实例匹配← 正确答案
  • B.相机内参的自动标定
  • C.激光雷达的扫描对齐
  • D.车辆行驶路径的规划

答案：A。匈牙利算法在训练中寻找预测线和真值线的最优一一对应关系，使总匹配代价最小。如果把地图线比作试卷上的题，这个算法就是确定“学生写的第一题对应标准答案的第几题”，是训练的前提。

Q6. 在线建图的实时性主要受哪个环节的硬约束？

单选题 · mid

  • A.车辆安全决策周期← 正确答案
  • B.云端存储容量大小
  • C.供电系统输出功率
  • D.车身喷漆颜色亮度

答案：A。自动驾驶的感知—规划—控制在数十到上百毫秒内闭环，在线建图必须在这个周期内完成，否则车辆拿到的是过时地图。云端存储、供电、车身颜色与实时建图延迟没有直接关系。

Q7. HDMapNet 分割输出后仍需后处理，最主要的原因是什么？

单选题 · hard

  • A.像素聚类需拟合几何线← 正确答案
  • B.点云配准需计算旋转量
  • C.图像增强需调整明暗度
  • D.轨迹规划需融合惯性量

答案：A。分割图只有像素类别，没有实例归属，也不知道几何形状。必须把属于同一根线的像素聚类起来，再用折线或多边形拟合，才能变成规划模块可用的几何元素。HDMapNet 的局限正在于这一繁琐且脆弱的“像素到几何”转化。

Q8. MapTR 的分层查询机制包含哪两个层级？

单选题 · hard

  • A.实例查询与点查询← 正确答案
  • B.车道查询与路标查询
  • C.特征查询与区域查询
  • D.语义查询与拓扑查询

答案：A。MapTR 先做实例查询，确定“这是第几条线”，再做点查询，细化“线上每个点的坐标”。实例级查询保证线之间不混淆，点级查询保证线形状精确。两个层级配合，让一条条车道线像流水线上的工件一样被依次精确定位。

Q9. 在线建图对自动驾驶系统的价值包括哪些？

多选题 · mid

  • A.降低地图采集成本← 正确答案
  • B.提高新场景泛化力← 正确答案
  • C.替代全部激光雷达
  • D.支持地图动态更新← 正确答案

答案：ABD。在线建图让普通车辆兼职采图，大幅降低成本；新城区无需等待离线地图即可运营，提升泛化能力；道路变化能被实时捕获并更新地图。但它不能替代激光雷达，因为建图只是感知的下游任务，传感器硬件冗余仍然必要。

Q10. 关于 MapTR 与 HDMapNet，下列说法正确的有哪些？

多选题 · hard

  • A.MapTR直接输出向量化地图← 正确答案
  • B.HDMapNet依赖像素级分割← 正确答案
  • C.MapTR不需要训练匹配机制
  • D.HDMapNet能直接输出折线

答案：AB。MapTR 端到端输出点序列组成的向量线，训练时依赖匈牙利匹配，C 错误；HDMapNet 先做像素级分割，再经后处理拟合几何，不能直接输出折线，D 错误。这就像用记号笔画线（MapTR）和涂色再描边（HDMapNet）的区别——前者一步到位，后者工序繁多。