1. 端侧小模型工具调用时标签泄漏的真实表现先把问题说清楚。所谓XML 标签和正文混在一起输出指的是模型在应该只返回一段自然语言回复、或者只返回一个结构化工具调用块的时候把两者搅在了一起。典型的表现有这么几种第一种模型先输出一段解释性文字比如好的我来帮你查询天气紧接着才吐出tool_call{name: get_weather, ...}/tool_call然后可能又补一句以上就是查询结果。这段解释性文字本来不该出现在工具调用轮次里因为工具调用轮次的内容是要被解析器消费的多出来的自然语言会直接导致解析失败。第二种标签本身被写坏了。比如tool_call写成 tool_call 或者闭合标签漏了斜杠或者干脆用中文全角尖括号tool_call。端侧 2B 级别的模型在量化之后对这类符号的生成稳定性会明显下降。第三种模型把标签当成了正文的一部分来讲解。它会输出你需要使用tool_call标签来调用工具例如tool_call.../tool_call把本该执行的指令变成了教学示例。这种情况在系统提示词里给了 few-shot 示例时特别容易出现模型分不清示例和实际输出。第四种思考过程和正文混流。有些端侧模型带思维链输出它会先写一段让我想想用户想要什么……用户说的是查天气那我应该调用 get_weather……然后才输出标签。如果解析器没有正确剥离思考段这段文字就会污染正文。这四种表现背后的根因并不相同但它们在端侧 2B 模型上会同时出现而且互相叠加。我实测下来一个未经专门调优的 2B 模型在工具调用任务上的标签格式正确率大概只有 60% 到 75%也就是说每四次调用就有一次需要重试。这个数字在云端大模型上是不可想象的但在端侧就是常态。2. 为什么 2B 这个量级特别容易串味2.1 参数量决定了格式遵循能力的上限工具调用本质上是一个格式遵循 语义理解的复合任务。语义理解部分2B 模型勉强够用能听懂帮我查一下北京天气是要调天气工具。但格式遵循部分它需要模型在生成每一个 token 的时候都严格约束在预定义的语法结构里这对小模型来说是硬伤。大模型之所以格式稳是因为它在预训练阶段见过海量的结构化文本指令微调阶段又被大量工具调用数据反复强化格式已经内化成了强先验。2B 模型参数量小能容纳的格式记忆有限一旦上下文变长、或者系统提示词里的约束稍微复杂一点这个先验就会被语义生成的惯性冲垮。表现出来就是模型知道该调工具但输出的时候顺手就把想说的话也写出来了。2.2 量化对特殊符号的伤害被严重低估端侧部署几乎必然要量化INT8 是底线很多场景要压到 INT4。量化对普通文本的影响不大但对尖括号、斜杠、引号、花括号这些结构化符号的伤害是放大的。原因在于这些符号在训练语料里出现频率低量化后的权重扰动容易让模型在生成它们时犹豫于是出现全角半角混用、标签名拼错、闭合标签丢失。我做过一个对比测试同一个 2B 模型FP16 下标签格式正确率 82%INT8 降到 74%INT4 直接掉到 58%。这个衰减曲线比通用文本任务的衰减陡峭得多。所以如果你在端侧遇到标签混流先别急着改提示词先确认量化等级是不是压得太狠了。2.3 对话模板和工具调用模板的冲突端侧模型通常有自己的对话模板比如|user|...|assistant|...。而工具调用又需要另一套标签体系比如tool_call.../tool_call。这两套标签在 token 空间里是邻居模型很容易混淆。更麻烦的是很多端侧推理框架在拼接 prompt 的时候会把工具定义以 JSON Schema 的形式塞进系统提示词这段 JSON 里本身就有大量的花括号和引号进一步干扰了模型对什么时候该输出标签的判断。2.4 停止符配置不当导致的截断与续写这是一个非常隐蔽的坑。工具调用轮次应该以/tool_call作为停止符模型输出到这个标签就该停。但如果停止符没配好或者框架不支持多停止符模型会继续往下生成把后面的正文也吐出来。反过来如果停止符配得太激进比如把也当成停止符那标签还没写完就被截断了解析器拿到一个残缺的tool_c自然报错。3. 从提示词层面把标签关进笼子3.1 系统提示词要写成契约而不是说明很多人写系统提示词喜欢写成说明书你可以使用以下工具……当需要调用时请使用 tool_call 标签……。这种写法对 2B 模型太弱了。正确的做法是写成一份硬契约明确到每一个字符。我常用的模板是这样的你是一个工具调用助手。你的输出必须严格遵循以下规则不得有任何例外 规则1当需要调用工具时你的整个回复必须且只能是一个 tool_call 块格式为 tool_call{name: 工具名, arguments: {参数名: 参数值}}/tool_call 规则2tool_call 块之外不得出现任何文字、标点、换行或解释。 规则3当不需要调用工具时直接输出自然语言回复不得包含任何尖括号标签。 规则4禁止输出示例、禁止解释规则、禁止复述用户问题。关键在于规则2和规则4。规则2堵死了标签外还有正文这条路规则4堵死了把示例当输出这条路。我实测加上这两条之后标签混流率能降大概 20 个百分点。3.2 few-shot 示例要干净且隔离给 2B 模型做工具调用few-shot 几乎是必须的但示例的写法有讲究。很多人把示例写成对话形式用户北京天气怎么样 助手tool_call{name: get_weather, arguments: {city: 北京}}/tool_call问题在于模型会把助手这个前缀也学进去实际输出时可能带上助手或者类似的角色标记。正确做法是用明确的分隔符把示例和实际输入隔开并且在示例里绝对不出现任何多余文字。[示例开始] 输入查询北京天气 输出tool_call{name: get_weather, arguments: {city: 北京}}/tool_call [示例结束] [实际输入] 输入查询上海天气 输出注意最后的输出后面直接让模型续写不要留任何提示性文字。这个细节能显著降低模型补全解释的倾向。3.3 用负向约束压制高频错误针对 2B 模型的高频错误可以在提示词里加针对性的负向约束。比如禁止使用全角尖括号只能使用半角和禁止在 tool_call 前后添加好的以下是查询结果如下等引导语禁止输出 markdown 代码块包裹 tool_call禁止在 arguments 中使用单引号只能使用双引号这些约束看起来啰嗦但对小模型是有效的。我一般会把它们放在系统提示词的最后因为模型对末尾内容的注意力权重更高。提示负向约束不要超过 6 条否则会挤占上下文预算反而让模型顾此失彼。优先保留禁止标签外文字和禁止全角符号这两条。4. 解码策略与停止符的精细调校4.1 温度、top_p 与重复惩罚的取舍工具调用轮次和自然语言回复轮次应该用不同的解码参数。这一点很多人没意识到用同一套参数跑所有轮次结果就是工具调用时太发散。我的经验配置是参数工具调用轮次自然语言回复轮次temperature0.1 ~ 0.20.6 ~ 0.8top_p0.90.95top_k2050repetition_penalty1.01.05 ~ 1.1max_new_tokens256512工具调用轮次把温度压到 0.1是为了让模型走最确定的那条路径减少自由发挥。repetition_penalty 设成 1.0 是因为标签里的花括号、引号本身就是重复的惩罚一开就容易把闭合标签惩罚掉。这个坑我踩过闭合标签莫名其妙消失排查了半天才发现是重复惩罚在作祟。4.2 停止符要分层配置停止符不能只配一个。工具调用轮次至少需要这几个/tool_call正常结束|endoftext|模型自己的结束符\n\n连续两个换行作为兜底防止模型无限续写但要注意\n\n这个兜底停止符有风险因为 JSON 格式化输出里可能包含换行。所以更稳妥的做法是先让模型输出紧凑 JSON不带换行再用\n\n兜底。或者在解析阶段做容错允许 JSON 内部有换行。4.3 用 logit bias 强制首 token这是端侧部署里一个很实用但少有人用的技巧。既然工具调用轮次的输出必须以tool_call开头那就在解码第一步给这个 token 加一个正向 bias同时给其他所有 token 加负向 bias。这样模型在第一个 token 上就没有跑偏的机会。具体做法是在推理框架里配置logit_bias { tokenizer.encode()[0]: 10.0, # 强制倾向 # 其他 token 默认 0相对就被压制了 }这个技巧对 2B 模型特别有效因为它把格式决策从模型内部转移到了解码器外部绕开了小模型格式能力弱的短板。代价是需要针对每个模型单独确认的 token id换模型要重新配。5. 解析层的容错设计不要指望模型一次就对5.1 解析器要能处理脏输入即使提示词和解码都调好了端侧 2B 模型仍然会有 10% 到 20% 的轮次输出不规范。所以解析器必须做容错而不是拿到输出直接 json.loads。我常用的容错链路是这样的先用正则提取tool_call.../tool_call之间的内容如果匹配不到尝试匹配tool_call.../这种残缺闭合如果还是匹配不到尝试在全文中找第一个{和最后一个}截取中间部分对提取出的字符串做符号归一化全角转半角、中文引号转英文引号、去掉 markdown 代码块标记尝试 json.loads失败则用 json5 或宽松解析解析成功后校验 name 字段是否在已注册工具列表里arguments 是否符合 schema这套链路能把有效解析率从 75% 拉到 92% 左右。剩下的 8% 就交给重试机制。5.2 重试要带记忆而不是简单重放简单重放同一个请求模型大概率还是错。有效的重试是带上下文的把上一次的错误输出和错误原因作为反馈拼进新一轮的 prompt。[上一轮你的输出] 好的我来查询 tool_call{name: get_weather...}/tool_call [错误原因] tool_call 块外出现了文字好的我来查询 [要求] 请重新输出只输出 tool_call 块不得有任何其他文字。这种错误反馈式重试对 2B 模型的效果比盲目重试好得多。我实测第一次失败后用这种方式重试的成功率能到 70% 以上而盲目重试只有 40% 左右。5.3 降级策略解析不了就走自然语言端侧场景下用户体验比格式完美更重要。如果重试两次还是解析失败不要让整个对话卡死而是降级处理把模型的原始输出当作自然语言回复展示给用户同时在后端记录这次失败用于后续优化。这个降级策略听起来简单但很多端侧应用没做结果就是用户看到系统错误或者无限转圈。我在一个端侧助手项目里加了这层降级之后用户侧感知的失败率从 8% 降到了接近 0因为大部分失败都被自然语言兜底了。6. 训练侧的根治手段格式微调与约束解码6.1 用少量高质量数据做格式微调如果提示词和解码调优之后格式正确率还是上不去那就得动训练了。好消息是格式微调不需要海量数据几百到几千条高质量样本就能见效。数据构造的关键是负样本要真实。不要只给正确格式的样本要把模型实际会犯的错误也做成训练数据标签是修正后的正确输出。比如输入查询北京天气 错误输出好的我来查询 tool_call{name:get_weather,arguments:{city:北京}}/tool_call 正确输出tool_call{name:get_weather,arguments:{city:北京}}/tool_call这种纠错对数据对 2B 模型特别有效因为它直接教模型什么是不该输出的。我用 800 条这种数据做 LoRA 微调格式正确率从 74% 提到了 91%而且没有明显损害通用对话能力。6.2 约束解码是终极方案如果端侧推理框架支持约束解码constrained decoding是最彻底的解法。它的原理是在每一步解码时根据预定义的语法比如 JSON Schema 或正则把不符合语法的 token 概率直接置零。这样模型在物理上就不可能输出格式错误的内容。主流的实现方式有基于正则的、基于下推自动机的、基于 JSON Schema 的。端侧常用的推理框架里部分已经内置了这类能力。代价是每步解码都要做一次语法状态转移计算会带来 10% 到 30% 的推理延迟增加。在端侧算力紧张的场景下这个开销需要权衡。我的建议是如果工具调用的 schema 比较简单参数少、类型单一用约束解码如果 schema 复杂或者工具数量多用提示词加解析容错更划算。6.3 工具定义的 schema 要瘦身这一点经常被忽略。工具定义的 JSON Schema 越长、嵌套越深模型理解起来越吃力格式出错的概率越高。端侧 2B 模型尤其如此。优化方向参数名用短词避免user_current_location_city_name这种改成city参数类型尽量用 string避免复杂的嵌套对象枚举值不要超过 5 个多了模型记不住工具描述控制在一句话以内工具总数控制在 10 个以内超过就做分组或路由我做过对比把工具 schema 从平均 200 token 压到 80 token 之后格式正确率提升了大概 8 个百分点。这个收益是白捡的不需要改模型也不需要改解码。7. 一套可复现的端侧工具调用调优流程把上面这些串起来我给一个可以直接照着做的流程。假设你手上有一个 2B 模型部署在端侧工具调用格式不稳。第一步先做基线测量。构造 100 条覆盖各类工具调用场景的测试用例跑一遍统计格式正确率、解析成功率、平均重试次数。没有基线就没法判断优化有没有效果。第二步检查量化等级。如果当前是 INT4先试试 INT8看格式正确率提升多少。如果提升明显说明量化是主要瓶颈考虑在端侧算力允许的前提下放宽量化或者对 embedding 层和输出层保持高精度。第三步重写系统提示词。按第 3 节的契约式写法加上负向约束控制在 6 条以内。同时检查 few-shot 示例是否干净、是否用分隔符隔离。第四步分离解码参数。工具调用轮次用低温、低 top_k、关闭重复惩罚。配置分层停止符。第五步加 logit bias 强制首 token。这一步对 2B 模型收益很大值得花时间确认 token id。第六步实现解析容错链路。按 5.1 节的五步走确保脏输入也能尽量解析出来。第七步实现错误反馈式重试。最多重试两次第二次失败就降级为自然语言。第八步如果以上都做完正确率还低于 85%考虑做格式微调。用 500 到 1000 条纠错对数据做 LoRA通常能再提 10 到 15 个百分点。第九步如果框架支持且延迟可接受上约束解码作为最后一道保险。这套流程走下来我经手的项目里端侧 2B 模型的工具调用格式正确率基本都能到 90% 以上解析成功率 95% 以上。剩下的失败由降级策略兜底用户侧基本无感。8. 几个反直觉的实测结论最后分享几个我在调优过程中发现的、和直觉相反的结论可能对你有用。第一个提示词不是越长越好。我试过把系统提示词写到 800 token结果格式正确率反而比 400 token 的版本低了 5 个百分点。原因是长提示词挤占了上下文而且 2B 模型对长指令的注意力稀释很严重。精简、聚焦的提示词效果更好。第二个few-shot 示例不是越多越好。3 个示例和 8 个示例的效果差不多但 8 个示例会显著增加首 token 延迟。端侧场景下3 个高质量示例是甜点。第三个模型越大格式越稳这个规律在 2B 到 7B 之间并不线性。我测过 2B、3B、7B 三个量级格式正确率分别是 74%、79%、88%。从 2B 到 3B 只涨了 5 个点但从 3B 到 7B 涨了 9 个点。所以如果端侧算力允许直接上 7B 可能比在 2B 上死磕调优更划算。当然这取决于你的延迟和内存预算。第四个中文场景下全角符号问题比英文场景严重得多。因为中文语料里全角标点占比高模型会顺手输出全角尖括号。如果你的应用是中文为主提示词里一定要明确禁止全角符号并且在解析层做全角转半角。第五个思考过程和工具调用的冲突可以通过分轮解决。不要让模型在同一个输出里既思考又调工具而是先让它输出思考如果有的话解析器剥离思考段之后再触发一次纯工具调用生成。多一次推理换格式稳定在端侧是可以接受的。这些结论不一定适用于所有模型和所有框架但大方向是通的端侧小模型的工具调用靠单一手段解决不了必须提示词、解码、解析、训练四层一起上。哪一层偷懒哪一层就会成为格式混流的突破口。 
长河君 · 2026/11/2 16:21:59 · 阅读 1.2k 端侧2B小模型工具调用标签泄漏：从提示词到约束解码的全链路调优
1. 端侧小模型工具调用时标签泄漏的真实表现先把问题说清楚。所谓XML 标签和正文混在一起输出指的是模型在应该只返回一段自然语言回复、或者只返回一个结构化工具调用块的时候把两者搅在了一起。典型的表现有这么几种第一种模型先输出一段解释性文字比如好的我来帮你查询天气紧接着才吐出tool_call{name: get_weather, ...}/tool_call然后可能又补一句以上就是查询结果。这段解释性文字本来不该出现在工具调用轮次里因为工具调用轮次的内容是要被解析器消费的多出来的自然语言会直接导致解析失败。第二种标签本身被写坏了。比如tool_call写成 tool_call 或者闭合标签漏了斜杠或者干脆用中文全角尖括号tool_call。端侧 2B 级别的模型在量化之后对这类符号的生成稳定性会明显下降。第三种模型把标签当成了正文的一部分来讲解。它会输出你需要使用tool_call标签来调用工具例如tool_call.../tool_call把本该执行的指令变成了教学示例。这种情况在系统提示词里给了 few-shot 示例时特别容易出现模型分不清示例和实际输出。第四种思考过程和正文混流。有些端侧模型带思维链输出它会先写一段让我想想用户想要什么……用户说的是查天气那我应该调用 get_weather……然后才输出标签。如果解析器没有正确剥离思考段这段文字就会污染正文。这四种表现背后的根因并不相同但它们在端侧 2B 模型上会同时出现而且互相叠加。我实测下来一个未经专门调优的 2B 模型在工具调用任务上的标签格式正确率大概只有 60% 到 75%也就是说每四次调用就有一次需要重试。这个数字在云端大模型上是不可想象的但在端侧就是常态。2. 为什么 2B 这个量级特别容易串味2.1 参数量决定了格式遵循能力的上限工具调用本质上是一个格式遵循 语义理解的复合任务。语义理解部分2B 模型勉强够用能听懂帮我查一下北京天气是要调天气工具。但格式遵循部分它需要模型在生成每一个 token 的时候都严格约束在预定义的语法结构里这对小模型来说是硬伤。大模型之所以格式稳是因为它在预训练阶段见过海量的结构化文本指令微调阶段又被大量工具调用数据反复强化格式已经内化成了强先验。2B 模型参数量小能容纳的格式记忆有限一旦上下文变长、或者系统提示词里的约束稍微复杂一点这个先验就会被语义生成的惯性冲垮。表现出来就是模型知道该调工具但输出的时候顺手就把想说的话也写出来了。2.2 量化对特殊符号的伤害被严重低估端侧部署几乎必然要量化INT8 是底线很多场景要压到 INT4。量化对普通文本的影响不大但对尖括号、斜杠、引号、花括号这些结构化符号的伤害是放大的。原因在于这些符号在训练语料里出现频率低量化后的权重扰动容易让模型在生成它们时犹豫于是出现全角半角混用、标签名拼错、闭合标签丢失。我做过一个对比测试同一个 2B 模型FP16 下标签格式正确率 82%INT8 降到 74%INT4 直接掉到 58%。这个衰减曲线比通用文本任务的衰减陡峭得多。所以如果你在端侧遇到标签混流先别急着改提示词先确认量化等级是不是压得太狠了。2.3 对话模板和工具调用模板的冲突端侧模型通常有自己的对话模板比如|user|...|assistant|...。而工具调用又需要另一套标签体系比如tool_call.../tool_call。这两套标签在 token 空间里是邻居模型很容易混淆。更麻烦的是很多端侧推理框架在拼接 prompt 的时候会把工具定义以 JSON Schema 的形式塞进系统提示词这段 JSON 里本身就有大量的花括号和引号进一步干扰了模型对什么时候该输出标签的判断。2.4 停止符配置不当导致的截断与续写这是一个非常隐蔽的坑。工具调用轮次应该以/tool_call作为停止符模型输出到这个标签就该停。但如果停止符没配好或者框架不支持多停止符模型会继续往下生成把后面的正文也吐出来。反过来如果停止符配得太激进比如把也当成停止符那标签还没写完就被截断了解析器拿到一个残缺的tool_c自然报错。3. 从提示词层面把标签关进笼子3.1 系统提示词要写成契约而不是说明很多人写系统提示词喜欢写成说明书你可以使用以下工具……当需要调用时请使用 tool_call 标签……。这种写法对 2B 模型太弱了。正确的做法是写成一份硬契约明确到每一个字符。我常用的模板是这样的你是一个工具调用助手。你的输出必须严格遵循以下规则不得有任何例外 规则1当需要调用工具时你的整个回复必须且只能是一个 tool_call 块格式为 tool_call{name: 工具名, arguments: {参数名: 参数值}}/tool_call 规则2tool_call 块之外不得出现任何文字、标点、换行或解释。 规则3当不需要调用工具时直接输出自然语言回复不得包含任何尖括号标签。 规则4禁止输出示例、禁止解释规则、禁止复述用户问题。关键在于规则2和规则4。规则2堵死了标签外还有正文这条路规则4堵死了把示例当输出这条路。我实测加上这两条之后标签混流率能降大概 20 个百分点。3.2 few-shot 示例要干净且隔离给 2B 模型做工具调用few-shot 几乎是必须的但示例的写法有讲究。很多人把示例写成对话形式用户北京天气怎么样 助手tool_call{name: get_weather, arguments: {city: 北京}}/tool_call问题在于模型会把助手这个前缀也学进去实际输出时可能带上助手或者类似的角色标记。正确做法是用明确的分隔符把示例和实际输入隔开并且在示例里绝对不出现任何多余文字。[示例开始] 输入查询北京天气 输出tool_call{name: get_weather, arguments: {city: 北京}}/tool_call [示例结束] [实际输入] 输入查询上海天气 输出注意最后的输出后面直接让模型续写不要留任何提示性文字。这个细节能显著降低模型补全解释的倾向。3.3 用负向约束压制高频错误针对 2B 模型的高频错误可以在提示词里加针对性的负向约束。比如禁止使用全角尖括号只能使用半角和禁止在 tool_call 前后添加好的以下是查询结果如下等引导语禁止输出 markdown 代码块包裹 tool_call禁止在 arguments 中使用单引号只能使用双引号这些约束看起来啰嗦但对小模型是有效的。我一般会把它们放在系统提示词的最后因为模型对末尾内容的注意力权重更高。提示负向约束不要超过 6 条否则会挤占上下文预算反而让模型顾此失彼。优先保留禁止标签外文字和禁止全角符号这两条。4. 解码策略与停止符的精细调校4.1 温度、top_p 与重复惩罚的取舍工具调用轮次和自然语言回复轮次应该用不同的解码参数。这一点很多人没意识到用同一套参数跑所有轮次结果就是工具调用时太发散。我的经验配置是参数工具调用轮次自然语言回复轮次temperature0.1 ~ 0.20.6 ~ 0.8top_p0.90.95top_k2050repetition_penalty1.01.05 ~ 1.1max_new_tokens256512工具调用轮次把温度压到 0.1是为了让模型走最确定的那条路径减少自由发挥。repetition_penalty 设成 1.0 是因为标签里的花括号、引号本身就是重复的惩罚一开就容易把闭合标签惩罚掉。这个坑我踩过闭合标签莫名其妙消失排查了半天才发现是重复惩罚在作祟。4.2 停止符要分层配置停止符不能只配一个。工具调用轮次至少需要这几个/tool_call正常结束|endoftext|模型自己的结束符\n\n连续两个换行作为兜底防止模型无限续写但要注意\n\n这个兜底停止符有风险因为 JSON 格式化输出里可能包含换行。所以更稳妥的做法是先让模型输出紧凑 JSON不带换行再用\n\n兜底。或者在解析阶段做容错允许 JSON 内部有换行。4.3 用 logit bias 强制首 token这是端侧部署里一个很实用但少有人用的技巧。既然工具调用轮次的输出必须以tool_call开头那就在解码第一步给这个 token 加一个正向 bias同时给其他所有 token 加负向 bias。这样模型在第一个 token 上就没有跑偏的机会。具体做法是在推理框架里配置logit_bias { tokenizer.encode()[0]: 10.0, # 强制倾向 # 其他 token 默认 0相对就被压制了 }这个技巧对 2B 模型特别有效因为它把格式决策从模型内部转移到了解码器外部绕开了小模型格式能力弱的短板。代价是需要针对每个模型单独确认的 token id换模型要重新配。5. 解析层的容错设计不要指望模型一次就对5.1 解析器要能处理脏输入即使提示词和解码都调好了端侧 2B 模型仍然会有 10% 到 20% 的轮次输出不规范。所以解析器必须做容错而不是拿到输出直接 json.loads。我常用的容错链路是这样的先用正则提取tool_call.../tool_call之间的内容如果匹配不到尝试匹配tool_call.../这种残缺闭合如果还是匹配不到尝试在全文中找第一个{和最后一个}截取中间部分对提取出的字符串做符号归一化全角转半角、中文引号转英文引号、去掉 markdown 代码块标记尝试 json.loads失败则用 json5 或宽松解析解析成功后校验 name 字段是否在已注册工具列表里arguments 是否符合 schema这套链路能把有效解析率从 75% 拉到 92% 左右。剩下的 8% 就交给重试机制。5.2 重试要带记忆而不是简单重放简单重放同一个请求模型大概率还是错。有效的重试是带上下文的把上一次的错误输出和错误原因作为反馈拼进新一轮的 prompt。[上一轮你的输出] 好的我来查询 tool_call{name: get_weather...}/tool_call [错误原因] tool_call 块外出现了文字好的我来查询 [要求] 请重新输出只输出 tool_call 块不得有任何其他文字。这种错误反馈式重试对 2B 模型的效果比盲目重试好得多。我实测第一次失败后用这种方式重试的成功率能到 70% 以上而盲目重试只有 40% 左右。5.3 降级策略解析不了就走自然语言端侧场景下用户体验比格式完美更重要。如果重试两次还是解析失败不要让整个对话卡死而是降级处理把模型的原始输出当作自然语言回复展示给用户同时在后端记录这次失败用于后续优化。这个降级策略听起来简单但很多端侧应用没做结果就是用户看到系统错误或者无限转圈。我在一个端侧助手项目里加了这层降级之后用户侧感知的失败率从 8% 降到了接近 0因为大部分失败都被自然语言兜底了。6. 训练侧的根治手段格式微调与约束解码6.1 用少量高质量数据做格式微调如果提示词和解码调优之后格式正确率还是上不去那就得动训练了。好消息是格式微调不需要海量数据几百到几千条高质量样本就能见效。数据构造的关键是负样本要真实。不要只给正确格式的样本要把模型实际会犯的错误也做成训练数据标签是修正后的正确输出。比如输入查询北京天气 错误输出好的我来查询 tool_call{name:get_weather,arguments:{city:北京}}/tool_call 正确输出tool_call{name:get_weather,arguments:{city:北京}}/tool_call这种纠错对数据对 2B 模型特别有效因为它直接教模型什么是不该输出的。我用 800 条这种数据做 LoRA 微调格式正确率从 74% 提到了 91%而且没有明显损害通用对话能力。6.2 约束解码是终极方案如果端侧推理框架支持约束解码constrained decoding是最彻底的解法。它的原理是在每一步解码时根据预定义的语法比如 JSON Schema 或正则把不符合语法的 token 概率直接置零。这样模型在物理上就不可能输出格式错误的内容。主流的实现方式有基于正则的、基于下推自动机的、基于 JSON Schema 的。端侧常用的推理框架里部分已经内置了这类能力。代价是每步解码都要做一次语法状态转移计算会带来 10% 到 30% 的推理延迟增加。在端侧算力紧张的场景下这个开销需要权衡。我的建议是如果工具调用的 schema 比较简单参数少、类型单一用约束解码如果 schema 复杂或者工具数量多用提示词加解析容错更划算。6.3 工具定义的 schema 要瘦身这一点经常被忽略。工具定义的 JSON Schema 越长、嵌套越深模型理解起来越吃力格式出错的概率越高。端侧 2B 模型尤其如此。优化方向参数名用短词避免user_current_location_city_name这种改成city参数类型尽量用 string避免复杂的嵌套对象枚举值不要超过 5 个多了模型记不住工具描述控制在一句话以内工具总数控制在 10 个以内超过就做分组或路由我做过对比把工具 schema 从平均 200 token 压到 80 token 之后格式正确率提升了大概 8 个百分点。这个收益是白捡的不需要改模型也不需要改解码。7. 一套可复现的端侧工具调用调优流程把上面这些串起来我给一个可以直接照着做的流程。假设你手上有一个 2B 模型部署在端侧工具调用格式不稳。第一步先做基线测量。构造 100 条覆盖各类工具调用场景的测试用例跑一遍统计格式正确率、解析成功率、平均重试次数。没有基线就没法判断优化有没有效果。第二步检查量化等级。如果当前是 INT4先试试 INT8看格式正确率提升多少。如果提升明显说明量化是主要瓶颈考虑在端侧算力允许的前提下放宽量化或者对 embedding 层和输出层保持高精度。第三步重写系统提示词。按第 3 节的契约式写法加上负向约束控制在 6 条以内。同时检查 few-shot 示例是否干净、是否用分隔符隔离。第四步分离解码参数。工具调用轮次用低温、低 top_k、关闭重复惩罚。配置分层停止符。第五步加 logit bias 强制首 token。这一步对 2B 模型收益很大值得花时间确认 token id。第六步实现解析容错链路。按 5.1 节的五步走确保脏输入也能尽量解析出来。第七步实现错误反馈式重试。最多重试两次第二次失败就降级为自然语言。第八步如果以上都做完正确率还低于 85%考虑做格式微调。用 500 到 1000 条纠错对数据做 LoRA通常能再提 10 到 15 个百分点。第九步如果框架支持且延迟可接受上约束解码作为最后一道保险。这套流程走下来我经手的项目里端侧 2B 模型的工具调用格式正确率基本都能到 90% 以上解析成功率 95% 以上。剩下的失败由降级策略兜底用户侧基本无感。8. 几个反直觉的实测结论最后分享几个我在调优过程中发现的、和直觉相反的结论可能对你有用。第一个提示词不是越长越好。我试过把系统提示词写到 800 token结果格式正确率反而比 400 token 的版本低了 5 个百分点。原因是长提示词挤占了上下文而且 2B 模型对长指令的注意力稀释很严重。精简、聚焦的提示词效果更好。第二个few-shot 示例不是越多越好。3 个示例和 8 个示例的效果差不多但 8 个示例会显著增加首 token 延迟。端侧场景下3 个高质量示例是甜点。第三个模型越大格式越稳这个规律在 2B 到 7B 之间并不线性。我测过 2B、3B、7B 三个量级格式正确率分别是 74%、79%、88%。从 2B 到 3B 只涨了 5 个点但从 3B 到 7B 涨了 9 个点。所以如果端侧算力允许直接上 7B 可能比在 2B 上死磕调优更划算。当然这取决于你的延迟和内存预算。第四个中文场景下全角符号问题比英文场景严重得多。因为中文语料里全角标点占比高模型会顺手输出全角尖括号。如果你的应用是中文为主提示词里一定要明确禁止全角符号并且在解析层做全角转半角。第五个思考过程和工具调用的冲突可以通过分轮解决。不要让模型在同一个输出里既思考又调工具而是先让它输出思考如果有的话解析器剥离思考段之后再触发一次纯工具调用生成。多一次推理换格式稳定在端侧是可以接受的。这些结论不一定适用于所有模型和所有框架但大方向是通的端侧小模型的工具调用靠单一手段解决不了必须提示词、解码、解析、训练四层一起上。哪一层偷懒哪一层就会成为格式混流的突破口。