DriveCode: Domain Specific Numerical Encoding for LLM-Based Autonomous Driving

本文提出了 DriveCode，一种将数值映射为专用嵌入而非离散文本令牌的新型编码方法，旨在解决大语言模型在自动驾驶中数值推理精度不足的问题，并在多个数据集上验证了其在轨迹预测和控制信号生成方面的优越性能。

要点

这篇论文介绍了一种名为 DriveCode 的新方法，旨在让大语言模型（LLM）更好地驾驶汽车。

为了让你轻松理解，我们可以把自动驾驶想象成教一个超级聪明的“大脑”（大语言模型）去开车。

🚗 核心问题：大脑“数数”不太行

现在的自动驾驶大模型虽然很聪明，能看懂路况、听懂指令，但在处理数字时却像个“粗心的小学生”。

• 传统做法的缺陷：
  想象一下，如果模型要表达“车速是 12.5 米/秒”，它必须把"1"、"2"、"."、"5"拆成四个独立的文字符号（Token）来一个个猜。
  • 比喻：这就像让你用乐高积木拼出一个数字"12.5"。你拼好了"1"，再拼"2"，再拼小数点。在这个过程中，模型容易搞混位置关系，甚至可能拼出"15.2"或者"125"。
  • 后果：在开车时，这种微小的数字错误（比如把 12.5 看成 15.2）可能导致急刹车或撞车，非常危险。

💡 解决方案：DriveCode（给数字发“专属身份证”）

DriveCode 的核心思想是：别把数字当成文字来读，要把它们当成“连续的数值”来直接处理。

1. 输入端：给数字发“专属通行证”

• 传统做法：模型看到文本里的"8 秒”，把它当成普通的单词"8"和"s"。
• DriveCode 的做法：
  • 当文本里出现数字时，系统会把它替换成一个特殊的占位符 <数字令牌>。
  • 同时，真正的数字（比如 8.0）会被提取出来，通过一个**“数字投影器”（Number Projector），直接转换成模型能理解的“连续向量”**。
  • 比喻：以前模型是看文字说明书开车；现在，DriveCode 给数字发了一张**“专属身份证”**。模型不再去拼凑"8"和"0"，而是直接读取这张身份证上携带的完整数值信息。这就好比从“拼乐高”变成了“直接读取芯片里的数据”。

2. 输出端：直接“报数”，不再“拼字”

• 传统做法：模型要输出速度，得先想好要输出"1"，再想"2"，再想"."，最后想"5"。这需要很多步，容易出错。
• DriveCode 的做法：
  • 模型内部有一个**“数字头”**（Number Head）。当它需要输出速度时，它直接计算出一个精确的浮点数（比如 12.5），一步到位。
  • 比喻：以前模型是像打字员一样，一个字母一个字母地敲出"12.5"；现在它像是一个直接报数的裁判，直接喊出"12.5"，既快又准。

🌟 为什么这很重要？（生活中的类比）

想象你在教一个机器人做调酒师：

• 普通模型：你告诉它“加 50 毫升威士忌”。它可能理解成“加 5 个 0 毫升”或者“加 500 毫升”，因为它把"5"和"0"当成两个独立的字符，没理解"50"是一个整体数值。
• DriveCode 模型：它直接理解"50"是一个连续的数值概念。它知道"50 毫升”和"5 毫升”差别巨大，就像知道“加糖”和“加盐”的区别一样清晰。

在自动驾驶中，速度、转向角度、刹车距离都是连续的物理量。DriveCode 让模型能像人类老司机一样，对数字的大小和精度有直觉般的敏感度，而不是像处理文字一样去“猜”数字。

📊 实验结果：真的有效吗？

作者在多个自动驾驶数据集（如 DriveGPT4, OmniDrive）上测试了 DriveCode：

1. 更准：预测车辆轨迹和速度的误差更小。
2. 更快：因为不需要一个个字符去拼数字，推理速度（反应时间）更快，这对实时驾驶至关重要。
3. 更稳：减少了模型“胡言乱语”（幻觉）的情况，特别是在需要精确控制的场景下。

🚀 总结

DriveCode 就像是给大语言模型装上了一副**“数字特制眼镜”**。

• 戴上这副眼镜，模型不再把数字看作零散的字母，而是看作连续的、有物理意义的数值。
• 这让 AI 从“会说话的司机”进化成了“懂数学的赛车手”，能更精准、更安全地控制车辆。

这项技术解决了大模型在自动驾驶领域最大的短板之一，让 AI 开车从“大概差不多”走向了“精准控制”。

技术摘要

1. 研究背景与问题 (Problem)

核心痛点：
尽管大语言模型（LLMs）在自动驾驶领域展现出巨大潜力，但传统的**离散文本分词（Tokenization）**机制在处理数值时存在根本性缺陷，限制了其在安全关键型自动驾驶场景中的部署：

• 数值推理能力弱： LLM 将数字视为文本片段（如 "3.14" 被拆分为 "3", ".", "1", "4"），而非连续的物理量。这导致模型难以理解数值的实际大小、位值意义（Place Value）以及进行精确的数值比较（例如，模型可能错误地判断 "3.11 > 3.8"）。
• 精度与效率的矛盾： 在自动驾驶中，控制指令（如速度、转向角、轨迹点）需要极高的数值精度。传统方法需要逐字符生成数字，不仅推理效率低，而且容易累积误差。
• 感知与控制的不匹配： 自动驾驶系统对物理量的绝对偏差非常敏感，而标准 LLM 仅关注 Token 级别的差异，导致微小的数值错误可能引发轨迹不稳定或危险操作。

2. 方法论 (Methodology)

作者提出了 DriveCode，一种专为 LLM 自动驾驶设计的数值编码方案。其核心思想是将数字视为一种独立的模态（Dedicated Modality），而非文本的一部分，实现从输入到输出的全连续数值处理。

2.1 核心架构

DriveCode 基于 LLaVA-NeXT 架构，主要包含三个关键组件：

1. 数据预处理 (Data Preprocessing)：
   • 利用正则表达式从原始文本中提取具有物理意义的数值（如速度、距离）。
   • 将文本中的数字替换为统一占位符 <number_token>。
   • 将提取的原始数值转换为浮点数列表，与占位符严格对齐。
2. 数值投影器 (Number Projector)：
   • 输入端： 设计了一个专用的多层感知机（MLP），将提取的连续数值 $x_k$ 映射到 LLM 的隐藏层空间（Hidden Space），生成数值嵌入 $e^{(k)}_{num}$。
   • 融合： 这些数值嵌入与视觉特征（来自图像编码器）和文本嵌入在占位符位置进行拼接，形成统一的多模态序列输入。
3. 数值头 (Number Head)：
   • 输出端： 在 LLM 生成 <number_token> 时，并行运行一个数值回归头（Number Head）。
   • 机制： 该头直接根据隐藏状态回归出连续的数值，而不是通过生成文本 Token 来拼凑数字。生成的数值会再次通过数值投影器，作为下一个自回归步骤的输入嵌入。

2.2 训练目标 (Loss Function)

模型采用多任务联合训练，总损失函数为：
$$L = L_{text} + \lambda L_{num}$$

• 文本损失 ($L_{text}$)： 标准的交叉熵损失，用于预测文本 Token。
• 数值损失 ($L_{num}$)：
  • 对于标量控制信号（如速度）：使用 $L_1$ 回归损失。
  • 对于轨迹预测（如路径点）：使用 $L_2$ 距离损失。
• 对齐机制： 数值回归是在生成 <number_token> 的前一个隐藏状态上进行的，确保了离散 Token 预测与连续数值回归的对齐。

3. 主要贡献 (Key Contributions)

1. 专用数值投影器： 设计了一个将数值映射为 LLM 隐藏空间专用嵌入的模块，使数值能与文本和视觉特征联合处理，打破了数字仅作为离散文本的限制。
2. 数值回归头： 提出了一种直接从隐藏状态回归连续数值的机制，使模型能在单个输出序列中同时生成自然语言解释和高精度控制指令，无需逐字符生成数字。
3. 跨模态对齐与实证验证： 在 OmniDrive、DriveGPT4 和 DriveGPT4-V2 三个数据集上进行了广泛评估，证明了该方法在轨迹预测和控制信号生成上的优越性，并验证了显式数值编码对提升 LLM 自动驾驶系统性能的有效性。

4. 实验结果 (Results)

实验在三个主要数据集上进行，对比基线包括 ADAPT（仅文本描述）、DriveGPT4（标准文本分词）和 xVal（缩放嵌入）。

• 控制信号预测 (DriveGPT4 & DriveGPT4-V2)：
  • 精度提升： DriveCode 在速度（Speed）和转向角（Turning Angle）的均方根误差（RMSE）上均取得了最佳表现。例如，在 DriveGPT4 上，速度 RMSE 从 DriveGPT4 的 1.30 降低至 1.08，转向角 RMSE 从 8.98 降低至 7.71。
  • 误差容忍度： 在中等和大误差阈值（如 $A_{0.5}, A_{1.0}$）下，DriveCode 的准确率显著高于基线模型。
• 轨迹预测 (OmniDrive)：
  • 在轨迹 L2 距离误差上，DriveCode (2.8274m) 优于纯文本基线 (3.0797m)。
• 消融实验：
  • 对比实验表明，仅在输出端进行数值回归（Variant）比纯文本（Text）效果好，而同时在输入端引入数值投影（DriveCode）效果最佳，证明了输入和输出的双向数值对齐至关重要。
• 效率分析：
  • 推理加速： 由于避免了逐字符生成数字（如生成 "3", ".", "1", "4" 四个 Token），DriveCode 将每个样本的平均推理时间从 3.37 秒降低至 3.18 秒，显著降低了延迟，更适合实时自动驾驶场景。

5. 意义与总结 (Significance)

• 突破 LLM 数值瓶颈： DriveCode 解决了 LLM 在自动驾驶领域应用的核心障碍——数值理解与生成的不精确性。通过将数字作为独立模态处理，模型能够更准确地理解物理量的连续性和位值意义。
• 端到端自动驾驶的新范式： 该方法为构建“感知 - 规划 - 控制”一体化的端到端自动驾驶系统提供了新的技术路径，使得 LLM 不仅能进行语义推理，还能输出高精度的物理控制指令。
• 安全性与实时性： 通过减少数值生成的 Token 数量和推理延迟，DriveCode 提升了系统在安全关键场景下的响应速度和可靠性，为未来 LLM 在自动驾驶中的实际部署奠定了基础。

局限性： 目前方法依赖于数值提取与占位符的严格对齐，若提取失败或格式不一致可能引入噪声；此外，整体性能仍受限于基础 LLM 的能力。未来工作将探索在闭环仿真环境中的评估及多尺度数值表示。