利用意图分类识别用户查询中最相关的指令
在一些需要处理众多独立指令集的任务中，先对查询的类型进行分类，然后根据这个分类来确定需要的指令，这样做往往是有益的。具体方法是，先定义固定的类别，并为处理这些类别中的任务硬编码相关指令。这个过程还可以递归地应用于把一个任务分解成多个阶段。这种方法的好处是，每个查询只包含执行下一个任务阶段所需的指令，相比于用一个查询来完成整个任务，这样可以降低错误率。同时，这也可能降低成本，因为较长的提示的运行成本更高（更多详情请参见 定价信息）。
比如，对于客户服务应用来说，可以有效地把查询分为以下几类：
| 系统 | 你会收到客户服务的查询。请把每个查询分为一个主要类别和一个次要类别，并以 json 格式提供结果，键值分别为：primary 和 secondary。 主要类别包括：账单、技术支持、账户管理或一般咨询。 账单的次要类别包括： – 取消订阅或升级 – 添加支付方式 – 解释收费 – 争议收费。 技术支持的次要类别包括： – 故障排除 – 设备兼容性 – 软件更新。 账户管理的次要类别包括： – 密码重置 – 更新个人信息 – 关闭账户 – 账户安全。 一般咨询的次要类别包括： – 产品信息 – 定价 – 反馈 – 与人交谈。 |
| 用户 | 我需要重新恢复我的互联网连接。 |
基于客户查询的分类，我们可以为模型提供一系列更具体的指令来处理下一步。例如，如果客户需要“故障排除”的帮助。
| 系统 | 你将负责处理技术支持中的客户服务咨询，需要进行故障排查。帮助用户的步骤如下： – 首先，请用户检查路由器的所有电缆连接是否牢固。需要注意的是，电缆有可能随着时间推移而松动。 – 如果确认电缆连接无误但问题依旧，请询问他们使用的路由器型号。 – 接下来，根据路由器型号提供重启设备的具体指导： — 若型号为 MTD-327J，建议按住红色按钮 5 秒，然后等待 5 分钟后再检查网络连接。 — 若型号为 MTD-327S，建议拔掉电源后重新插上，同样等待 5 分钟后检查网络连接。 – 如果重启设备并等待 5 分钟后用户的问题仍未解决，请将他们转接至 IT 支持，并显示 IT 支持请求 的信息。 – 如果用户开始询问与本次故障排查无关的问题，请确认他们是否愿意结束当前的故障排查话题，并按照给定的分类方案处理他们的请求。 <在此处插入上面的主要/次要分类方案> |
| 用户 | 我需要重新恢复我的互联网连接。 |
请注意，模型被设定为在对话状态发生变化时发出特殊指令。这使我们的系统能够转变为一个状态机，根据当前的状态来决定注入哪些指令，以及从该状态出发可以转换到哪些状态。通过监控对话状态、相关指令以及状态转换，我们能更好地控制用户体验，这在非结构化的交流方式中难以实现。
对于需要长时间对话的对话应用，总结或筛选先前的对话内容
由于模型的上下文长度是固定的，用户与助手的对话不能无限延续，尤其是当整个对话内容都包含在上下文窗口中时。
解决这一问题的方法之一是概括之前的对话。当输入内容达到一定长度时，可以触发对部分对话内容进行概括的查询，这样的概括可以作为系统消息的一部分。或者，也可以在整个对话过程中不断后台概括之前的对话内容。
另一种方法是动态地挑选对话中与当前问题最相关的部分。详情可见策略 “利用基于嵌入向量的搜索实现高效的知识检索”。
分步总结长文档，并递归地构建完整的总结
因为模型的上下文长度是固定的，所以它们无法一次性总结超过上下文长度减去所生成摘要长度的文本。
例如，要总结一本很长的书，我们可以使用一系列的查询来分别总结书中的每个章节。这些部分的摘要可以被连结并进一步总结，形成摘要的摘要。这个过程可以递归地进行，直至整本书被总结完毕。如果在理解书中后续部分时需要前面章节的信息，那么在总结当前部分内容时附加一个前面内容的连续摘要会是一个实用的技巧。OpenAI 之前利用 GPT-3 的变种对这种总结书籍的方法进行了 研究。
