这是 GPT 最佳实践的第三部分，任务拆分，第二部分（提供参考文本）在这里，更多部分在这里。
第三部分，将复杂任务拆分为较简单的子任务
就像在软件工程中将复杂系统分解为一组模块化组件一样，将任务分解成子任务也是一个好的做法。与较简单的任务相比，复杂任务往往具有更高的错误率。此外，复杂任务通常可以重新定义为由较简单的任务组成的工作流，其中早期任务的输出被用于构建后续任务的输入。
策略：
- 使用意图分类来识别用户查询中最相关的指令。
- 对于需要进行非常长对话的对话应用程序，可以对先前的对话进行总结或过滤 。
- 将长文档分段进行摘要，并递归地构建完整摘要。
策略：使用意图分类来确定用户查询最相关的指令
对于需要大量独立指令集来处理不同情况的任务，首先对查询类型进行分类，然后根据该分类确定所需的指令可能是有益的。这可以通过定义固定的类别并硬编码处理给定类别中的任务所需的相关指令来实现。这个过程也可以递归应用，将任务分解为一系列阶段。这种方法的优点是，每个查询只包含执行任务下一阶段所需的那些指令，与使用单个查询执行整个任务相比，可以降低错误率。这也可能导致更低的成本，因为更大的提示运行成本更高（参见价格信息）。
例如，对于客户服务应用，查询可以有用地分类如下：
| 角色 | 对话 |
|---|---|
| SYSTEM | You will be provided with customer service queries. Classify each query into a primary category and a secondary category. Provide your output in json format with the keys: primary and secondary. Primary categories: Billing, Technical Support, Account Management, or General Inquiry. Billing secondary categories: - Unsubscribe or upgrade - Add a payment method - Explanation for charge - Dispute a charge Technical Support secondary categories: - Troubleshooting - Device compatibility - Software updates Account Management secondary categories: - Password reset - Update personal information - Close account - Account security General Inquiry secondary categories: - Product information - Pricing - Feedback - Speak to a human 你将得到一些客户服务查询。将每个查询分类为主要类别和次要类别。以json格式提供你的输出，键为：primary和secondary。 主要类别：计费，技术支持，账户管理，或一般查询。 计费次要类别： - 取消订阅或升级 - 添加付款方式 - 收费解释 - 争议收费 技术支持次要类别： - 故障排除 - 设备兼容性 - 软件更新 账户管理次要类别： - 重置密码 - 更新个人信息 - 关闭账户 - 账户安全 一般查询次要类别： - 产品信息 - 定价 - 反馈 - 与人交谈 |
| USER | I need to get my internet working again. 我需要再次使我的互联网工作。 |
根据客户查询的分类，可以向GPT模型提供一组更具体的指令来处理下一步。例如，假设客户需要帮助进行"故障排除"。
| 角色 | 对话 |
|---|---|
| SYSTEM | You will be provided with customer service inquiries that require troubleshooting in a technical support context. Help the user by: - Ask them to check that all cables to/from the router are connected. Note that it is common for cables to come loose over time. - If all cables are connected and the issue persists, ask them which router model they are using - Now you will advise them how to restart their device: -- If the model number is MTD-327J, advise them to push the red button and hold it for 5 seconds, then wait 5 minutes before testing the connection. -- If the model number is MTD-327S, advise them to unplug and replug it, then wait 5 minutes before testing the connection. - If the customer's issue persists after restarting the device and waiting 5 minutes, connect them to IT support by outputting {"IT support requested"}. - If the user starts asking questions that are unrelated to this topic then confirm if they would like to end the current chat about troubleshooting and classify their request according to the following scheme: <insert primary/secondary classification scheme from above here> 你将得到需要在技术支持环境中进行故障排除的客户服务查询。帮助用户： - 让他们检查到/从路由器的所有电缆是否连接。注意，电缆随着时间的推移松动是很常见的。 - 如果所有电缆都连接了，问题仍然存在，问他们使用的是哪种型号的路由器 - 现在你将建议他们如何重启设备： -- 如果型号是 MTD-327J，建议他们按下红色按钮并保持5秒，然后等待5分钟再测试连接。 -- 如果型号是 MTD-327S，建议他们拔掉电源再插上，然后等待5分钟再测试连接。 - 如果客户在重启设备并等待5分钟后问题仍然存在，通过输出 {"IT support requested"} 将他们连接到 IT 支持。 - 如果用户开始提出与此主题无关的问题，那么确认他们是否希望结束当前关于故障排除的聊天，并根据以下方案对他们的请求进行分类： <在这里插入上述的主要/次要分类方案> |
| USER | Ineed to get my internet working again. 我需要再次使我的互联网工作。 |
注意，模型已被指示发出特殊的字符串来指示对话状态何时发生变化。这使我们能够将系统转变为状态机，其中状态决定注入哪些指令。通过跟踪状态，了解在该状态下哪些指令是相关的，以及可选地，从该状态允许哪些状态转换，我们可以在用户体验周围设置防护栏，这在结构较少的方法中很难实现。
策略：对需要进行非常长对话的对话应用程序，总结或过滤以前的对话
由于GPT具有固定的上下文长度，因此用户和助手之间的对话，如果整个对话都包含在上下文窗口中，就不能无限期地继续下去。
对于这个问题有各种各样的解决方法，其中之一就是总结对话的前几轮。一旦输入的大小达到预定的阈值长度，这就可能触发一个查询，总结对话的一部分，而先前对话的总结可以作为系统消息的一部分包含在内。或者，先前的对话可以在整个对话过程中在后台异步地进行总结。
另一种解决方案是动态选择与当前查询最相关的对话的前一部分。参见策略"使用基于嵌入的搜索来实现有效的知识检索"。
策略：逐片总结长文档并递归构建完整总结
由于GPT具有固定的上下文长度，它们不能用于在单个查询中总结比上下文长度减去生成的总结长度更长的文本。
要总结一篇非常长的文档，如一本书，我们可以使用一系列查询来总结文档的每一部分。部分总结可以被连接起来并总结，产生总结的总结。这个过程可以递归进行，直到整个文档被总结。如果需要使用关于早期部分的信息来理解后期部分，那么一个可能有用的技巧是，在总结某一点的内容时，包含一个运行的总结，这个总结在书中任何给定点之前的文本。OpenAI在以前的研究中已经研究过这种用于总结书籍的程序的有效性，使用的是GPT-3的变体。
