1. 引述
这是一篇自动驾驶领域的论文。我对这篇论文主要感兴趣的点在于其对于工具调用（Tool Call）的设计。这一点同时也被设计在了其强化微调时的奖励函数上。
2. 方法
2.1 思维链设计
论文思维链的每个步骤都被组织成五个要素：
-
所选工具（显式输出在思考过程中，也就是 <tool>）
模型在该步骤决定要调用的外部模块／工具名称（比如 "Open-Vocab Detector" 或 "Depth Estimator"），或者标记不调用任何工具。
-
子问题
针对当前推理目标，模型提出的一个更细粒度的问题。
例如在判断能否左转时，子问题可能是"前方来车速度如何？"或"左侧车道上有没有行人？"
-
不确定性标记
一个布尔值，标记"内部知识能否直接回答子问题"：
-
如果模型内部已有足够知识，可直接判断，则标记为 False
-
否则标记为 True，表示需要调用工具辅助判断。
-
-
初步答案
-
当不确定性标记为 False 时，模型直接给出问题的回答；
-
若不确定性标记为 True，此处留空，等待工具返回结果后再进行下一步推理。
-
-
下一步动作选择
指示是"继续推理"（Continue Reasoning）还是"结束推理并输出最终答案"（Conclude）。
2.2 工具调用
在开放词汇目标检测、轨迹预测等指定任务上，专门针对这方面的模型必然效果比语言模型好。如果让 LLM 去做这些任务，那么大概率是会生成幻觉的，就好比早期的 GPT，你问它数学题，它输出错误答案（幻觉）；而现在的 GPT 遇到复杂的数学问题会直接求助 Python，这就是工具调用（Tool Call）。
上图是论文的一个对比实验图，对比使用 tool 和不使用 tool 的效果。
论文的附录里面写了所有使用的 tool，而结果上这些 tool 是一个个的函数。在 SFT 阶段，论文对大模型输出形式进行微调（预热），在微调输出思维链那一块儿就用 <tool> 来指定调用哪个函数。
2.3 奖励函数
论文在摘要提到他们的创新包括： GRPO 微调、调用工具、思维链。事实上，GRPO 微调的论文现在一抓一大把，微调不是创新，微调的设置才是创新，确切来说（主要）是奖励函数的设计。
工具调用和思维链这两个创新需要和微调关联起来，意思就是说奖励函数的设计是包括了这两个创新点。
论文的奖励函数设计思路如下：
- 最终答案奖励：答案正确就基于正反馈
- 推理步骤奖励：思维链的推理是否正确（判断答案是不是蒙出来的，或者答案错误但是思路是对的）
- 工具调用奖励：在 "解题" 过程中，是否用了正确的辅助工具
具体的设计公式（给多少点奖励）论文并未提及。
2.4 方法流程
论文首先是构建了一个数据集。使用特定提示模板，让 GPT-4o 在每一步推理中决定是否调用工具，并生成"子问题 → （工具调用）→ 中间答案 → 下一步动作"的完整链式思维轨迹。
接着使用千问7B作为 LLM，使用 SFT 对模型进行预热，也就是规范模型输出格式，并告诉模型其将要面临的具体任务（比如这个数据集都是自动驾驶的数据，那么模型在监督微调之后，后续的回复就会更倾向自动驾驶）
最后在实际推理时，模型根据每步的"不确定"标记，实时决定是否调用工具，并将工具输出融入后续推理。