自然语言处理:第八十三章 Prompt格式到底多重要？

本人项目地点大全：Victor94-king/NLP__ManVictor: CSDN of ManVictor

写在前面: 笔者更新不易，渴望走过路过点个关注和赞，笔芯!!!
写在前面: 笔者更新不易，渴望走过路过点个关注和赞，笔芯!!!
写在前面: 笔者更新不易，渴望走过路过点个关注和赞，笔芯!!!

函数调用能力的关键职位

在当前大语言模子（LLM）的应用生态中，函数调用能力（Function Calling）已经成为一项不可或缺的焦点能力。它使LLM能够通过调用外部API获取及时信息、操作第三方服务，从而将模子的语言理解能力转化为实际的行动能力。从电子设计主动化到金融陈诉天生，从旅行规划到智能家居控制，函数调用正在将LLM的应用版图快速扩展到各个领域。
然而，如何让LLM更准确地理解和使用函数接口，不停是困扰研究者和工程师的关键问题。MediaTek Research的研究团队近来在这一领域取得了重要突破，他们从提示格式优化、数据集成策略到多语言支持等多个维度，体系性地提升了LLM的函数调用能力。本文将详细解析他们的研究发现，为从事LLM应用开发的工程师提供切实可行的优化方案。

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

在这项研究中，研究者起首挑战了传统的函数形貌方式。他们提出了两种不同的策略来在提示中展示函数形貌：

• 专门角色策略： 为函数形貌创建一个独立的角色（如"tools"），以JSON格式呈现函数信息。
  
• 体系角色集成策略： 将函数形貌直接嵌入到体系角色的提示中，与使用说明一起呈现。
  

这两种策略的实验效果令人深思。研究发现，当函数形貌通过专门角色呈现时，模子在相关性检测（Relevance Detection）方面表现更好。这意味着模子能更准确地判定是否必要调用函数，从而淘汰不必要的函数调用。研究发现，使用专门角色策略时，相关性检测准确率达到49.58%，而体系角色集成策略则为39.58%。
研究者以为，这种差异源于模子能更清晰地辨认出有函数可用和无函数可用的场景之间的区别。当函数形貌被放在专门的角色中时，有函数和无函数的提示模板差异更显着，这帮助模子建立了更强的区分能力。

Prompt格式示例

毫无疑问，准确推理时，Prompt格式明显影响推理的精准度。研究中探索了三种重要的提示格式：

• 无函数场景:
  

1. <|im_start|>system
2. You are a helpful assistant.
3. <|im_end|>
4. <|im_start|>user
5. Where is Boston?
6. <|im_end|>
7. <|im_start|>assistant

复制代码

• 专门角色提供函数:
  

1. <|im_start|>tools
2. [{"name": "get_current_weather",
3. "description": "Get the current weather in a given location",
4. "parameters": {"type": "object", "properties": {"location":
5. {"type": "string", "description": "The city and state"}},
6. "required": ["location"]}}]
7. <|im_end|>
8. <|im_start|>system
9. You are a helpful assistant.
10. <|im_end|>
11. <|im_start|>user
12. What is the weather like in Boston?
13. <|im_end|>
14. <|im_start|>assistant

复制代码

• 体系角色集成函数:
  

1. <|im_start|>system
2. 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"]}}]
3. <|im_end|>
4. <|im_start|>user
5. What is the weather like in Boston?
6. <|im_end|>
7. <|im_start|>assistant

复制代码

对应的天生效果示例：

• 普通回答:
  

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

复制代码

• 带Decision Token的回答:
  

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

复制代码

• 函数调用:
  

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

复制代码

• 带Decision Token的函数调用:
  

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

复制代码

• 带推理过程的函数调用:
  

1. <|use_tool|>The user wants to get the weather in Boston. The available 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")]
2. <|im_end|>

复制代码

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

研究中最令人惊奇的发现之一是指令跟随（Instruction Following）数据对函数调用能力的明显提升作用。研究者在训练数据中加入了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采用了精细的处理策略，重要包罗以下步骤：

• 预处理阶段：
  

• 辨认并标记不必要翻译的技术元素（函数名、JSON布局等）
  
• 提取必要翻译的自然语言内容
  
• 保存原始格式信息
  

• 翻译处理：
  

• 使用商业级LLM举行单轮查询翻译
  
• 提供明白的翻译规则和束缚
  
• 保持专业术语的划一性
  

• 后处理阶段：
  

• 验证翻译后的JSON布局完备性
  
• 确保函数调用格式的正确性
  
• 举行质量查抄和修正
  

以下是一个实际的翻译示例：
原始数据：

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

复制代码

翻译后数据：

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

复制代码

注意函数名和location参数值保持不变，只翻译对话内容。这种精细的翻译策略确保了函数调用的正确性。
实验效果显示，这种翻译策略在多个语言上都取得了明显效果：
语言原始AST Summary翻译后AST Summary提升中文52.37%61.56%+9.19%日语51.25%59.83%+8.58%韩语50.94%58.71%+7.77% 这些效果证明白该翻译pipeline的有效性和可扩展性。
实践启示：面向工程师的优化发起

基于这项研究的发现，我们可以为正在开发基于LLM函数调用功能的工程师提供以下具体发起：

• 提示格式设计
  

• 优先思量使用专门的角色来呈现函数形貌
  
• 确保有函数和无函数场景的提示模板有显着区别
  
• 在体系提示中清晰说明函数使用的规则和限制
  

• 训练数据构建
  

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

• 多语言支持实现
  

• 采用专门的翻译管道而不是简朴的呆板翻译
  
• 仔细区分必要翻译和不必要翻译的内容
  
• 确保翻译后数据的布局完备性
  

• 评估和优化
  

• 同时关注函数调用准确率和相关性检测
  
• 在多种场景下测试模子的判定能力
  
• 连续网络和分析失败案例
  

通过这些连续的优化和创新，LLM的函数调用能力变得更加强大和实用，为AI应用开发带来更多可能性。关于prompt格式问题，您也可以看下我之前的文章

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。