在如今的LLM应用生态里，函数调用已经不是锦上添花的功能，而是绕不开的核心能力。它让模型能通过外部API获取实时信息、操作第三方服务，把对话理解转化成实实在在的行动——从电子设计自动化到金融报告生成，从旅行规划到智能家居控制，领域边界正在被快速拓宽。

但问题在于，怎么让LLM更准确地理解和使用这些函数接口？MediaTek Research团队最近在这块做了系统性突破，从提示格式优化、数据集成策略到多语言支持，提出了不少有实操价值的方法。下面就来拆解他们的核心发现，给做LLM应用开发的工程师提供一些可直接落地的优化思路。

函数调用能力的关键地位

函数调用（Function Calling）的重要性不用多说。它让LLM能调用外部API来获取实时信息、操作服务，把模型的语言理解转化为实际行动。从电子设计自动化到金融报告生成，从旅行规划到智能家居控制，函数调用正在快速扩展LLM的应用版图。

然而，如何让LLM更准确地理解和使用函数接口，一直是困扰研究者和工程师的关键问题。MediaTek Research的研究团队最近在这一领域取得了重要突破，他们从提示格式优化、数据集成策略到多语言支持等多个维度，系统性地提升了LLM的函数调用能力。本文将详细解析他们的研究发现，为从事LLM应用开发的工程师提供切实可行的优化方案。

提示工程最新：重新思考函数描述的呈现方式

研究团队上来就挑战了传统的函数描述方式。他们对比了两种策略在提示中展示函数描述的效果：

1. 专门角色策略：为函数描述创建一个独立的角色（如"tools"），以JSON格式呈现函数信息。

2. 系统角色集成策略：将函数描述直接嵌入到系统角色的提示中，与使用说明一起呈现。

结果挺有意思：当函数描述通过专门角色呈现时，模型在相关性检测（Relevance Detection）方面表现更好——准确率达到49.58%，而系统角色集成策略只有39.58%。换句话说，模型能更准确地判断是否需要调用函数，从而减少不必要的调用。

背后的道理其实不复杂——模型能更清晰地识别出有函数可用和无函数可用的场景之间的区别。当函数描述被放在专门的角色中时，有函数和无函数的提示模板差异更明显，这帮助模型建立了更强的区分能力。

Prompt格式示例

为了让这些结论更直观，这里直接放出研究中使用的主要提示格式：

1. 无函数场景:

<|im_start|>system
You are a helpful assistant.
<|im_end|>
<|im_start|>user
Where is Boston?
<|im_end|>
<|im_start|>assistant

1. 专门角色提供函数:

<|im_start|>tools
[{"name": "get_current_weather", 
"description": "Get the current weather in a given location", 
"parameters": {"type": "object", "properties": {"location": 
{"type": "string", "description": "The city and state"}}, 
"required": ["location"]}}]
<|im_end|>
<|im_start|>system
You are a helpful assistant.
<|im_end|>
<|im_start|>user
What is the weather like in Boston?
<|im_end|>
<|im_start|>assistant

1. 系统角色集成函数:

<|im_start|>system
You are an expert in composing functions. Here is a list of functions in JSON format that you can invoke: [{"name": "get_current_weather", "description": "Get the current weather in a given location", "parameters": {"type": "object", "properties": {"location": {"type": "string", "description": "The city and state"}}, "required": ["location"]}}]
<|im_end|>
<|im_start|>user
What is the weather like in Boston?
<|im_end|>
<|im_start|>assistant

对应的生成结果示例：

1. 普通回答:

Boston is the capital city of the state of Massachusetts, located in the northeastern United States.
<|im_end|>

1. 带Decision Token的回答:

<|answer|>Boston is the capital city of the state of Massachusetts, located in the northeastern United States.
<|im_end|>

1. 函数调用:

[get_current_weather(location="Boston")]
<|im_end|>

1. 带Decision Token的函数调用:

<|use_tool|>[get_current_weather(location="Boston")]
<|im_end|>

1. 带推理过程的函数调用:

<|use_tool|>The user wants to get the weather in Boston. The a vailable tool 'get_current_weather' can be used to retrieve this information. The 'get_current_weather' tool can be used by specifying the city as 'Boston'.
[get_current_weather(location="Boston")]
<|im_end|>

数据集成：指令数据的意外收获

研究中最让人意外的发现之一，是指令跟随数据对函数调用能力的显著提升。研究者在训练数据中加入了11万条指令跟随数据，结果不仅没有削弱函数调用能力，反而带来了全面性能提升：

• 函数调用准确率（AST Summary）从74.62%提升到85.25%

• 相关性检测准确率从38.33%提升到49.58%

这个结果直接碘伏了“专注于函数调用数据才能提升函数调用能力”的老认知。背后的道理可能在于：指令跟随数据帮助模型建立了更好的语义理解能力，这种基础能力的提升反过来增强了模型理解和使用函数接口的能力。同时，指令数据中包含了大量非函数调用场景，也帮模型更好地识别什么时候应该直接回答而不是调用函数。

Decision Token：二元决策机制

为了进一步提升模型的相关性检测能力，研究团队提出了一个创新的Decision Token机制。核心思想很简单：在生成响应之前，先让模型做一个明确的二元决策——是直接回答还是调用函数。

具体实现上，引入了两个特殊token：

• <|answer|>：表示模型决定直接回答

• <|use_tool|>：表示模型决定调用函数

这种设计把原本隐含在生成过程中的决策明确化了，强制模型在生成具体回答或函数调用之前，先对查询的性质做出判断。实验数据很有说服力：当结合合成的非函数调用数据使用时，这个机制能把相关性检测准确率提升到65.42%。

另外，Decision Token还意外地简化了非函数调用数据的生成过程——通过移除原始数据中被调用的函数，就能轻松创建对应的训练样本。这下数据获取的难题也得到了缓解。

多语言支持的突破：专向翻译管道

全球化背景下，如何让函数调用能力突破语言障碍是关键挑战。研究者设计了一个专门的翻译管道来应对：细粒度翻译策略——保持函数名称和描述不变，只翻译自然语言部分，同时保证JSON结构完整。

以中文为例，他们用这个管道生成了1.9万条中文函数调用数据。实验结果很不错：即使只使用这些翻译数据进行微调，模型在中文（繁体）函数调用基准测试上的表现就有显著提升：

• AST Summary从52.37%提升到61.56%

• 相关性检测从36.67%提升到41.25%

这说明只要翻译策略得当，函数调用能力是能有效迁移到其他语言的。

多语言翻译Pipeline的技术细节

研究团队开发的翻译pipeline采用精细处理策略，主要分三步：

1. 预处理阶段：识别并标记不需要翻译的技术元素（函数名、JSON结构等），提取需要翻译的自然语言内容，保存原始格式信息。

2. 翻译处理：使用商业级LLM进行单轮查询翻译，提供明确的翻译规则和约束，保持专业术语的一致性。

3. 后处理阶段：验证翻译后的JSON结构完整性，确保函数调用格式正确性，进行质量检查和修正。

下面是一个实际的翻译示例：

原始数据：

{
"conversations": [
{"role": "user", "content": "What's the weather like in Taipei?"},
{"role": "assistant", "content": "Let me check the weather for you."},
{"tool_calls": [{"name": "get_current_weather", "arguments": {"location": "Taipei"}}]}
]
}

翻译后数据：

{
"conversations": [
{"role": "user", "content": "台北的天氣如何？"},
{"role": "assistant", "content": "讓我幫您查看天氣。"},
{"tool_calls": [{"name": "get_current_weather", "arguments": {"location": "Taipei"}}]}
]
}

注意函数名和location参数值保持不变，只翻译对话内容。这种精细策略保证了函数调用的正确性。

实验结果显示，这种翻译策略在多个语言上都取得了显著效果：

这些数据足以证明该翻译pipeline的有效性和可扩展性。

实践启示：面向工程师的优化建议

基于这些研究发现，针对正在开发基于LLM函数调用功能的工程师，这里总结几条可以直接借鉴的建议：

1. 提示格式设计

   • 优先考虑使用专门的角色来呈现函数描述
   • 确保有函数和无函数场景的提示模板有明显区别
   • 在系统提示中清晰说明函数使用的规则和限制

2. 训练数据构建

   • 不要局限于纯函数调用数据
   • 有意识地加入高质量的指令跟随数据
   • 通过Decision Token机制构建非函数调用数据

3. 多语言支持实现

   • 采用专门的翻译管道，而不是简单的机器翻译
   • 仔细区分需要翻译和不需要翻译的内容
   • 确保翻译后数据的结构完整性

4. 评估和优化

   • 同时关注函数调用准确率和相关性检测
   • 在多种场景下测试模型的判断能力
   • 持续收集和分析失败案例

通过这些持续的优化和创新，LLM的函数调用能力正在变得更加强大和实用，给AI应用开发带来更多可能性。