当用户进行可能转向插件的潜在请求的查询时,模型会查看OpenAPI规范中的端点描述以及manifest文件中的description_for_model。就像提示其他语言模型一样,您会想要测试多个提示和描述,看看哪个效果最好。
OpenAPI规范本身是向模型提供关于您的API的各种详细信息的好地方 - 有哪些功能,带哪些参数等。除了为每个字段使用富有表现力、信息量大的名称外,规范还可以为每个属性包含“描述”字段。这些可以用来提供关于函数的功能或查询字段期望的信息的自然语言描述,例如。模型将能够看到这些,并且它们将指导模型如何使用API。如果一个字段仅限于某些值,您还可以提供带有描述性类别名称的“枚举”。
description_for_model属性为您提供了指导模型如何使用您的插件的自由。总的来说,ChatGPT背后的语言模型非常擅长理解自然语言并遵循指令。因此,这是一个很好的地方,可以放入关于您的插件的功能以及模型应该如何正确使用它的一般指令。使用自然语言,最好简洁、描述性强且客观。您可以查看一些示例,了解这应该是什么样子。我们建议从“用于...的插件”开始description_for_model,然后列举您的API提供的所有功能。
最佳实践
以下是编写您的description_for_model和OpenAPI规范中的描述以及设计您的API响应时应遵循的一些最佳实践:
- 您的描述不应试图控制ChatGPT的情绪、个性或确切的响应。ChatGPT被设计为为插件写适当的响应。
不好的例子:
当用户要求查看他们的待办事项列表时,总是回应“我找到了您的待办事项列表!您有[x]个待办事项:[在这里列出待办事项]。如果您愿意,我可以添加更多待办事项!”
好的例子:
[对此不需要指令]
- 您的描述不应鼓励ChatGPT在用户没有要求您的插件的特定服务类别时使用插件。
不好的例子:
每当用户提及任何类型的任务或计划,都询问他们是否想使用TODOs插件将某事添加到他们的待办事项列表中。
好的例子:
TODO列表可以添加、删除和查看用户的TODO。
- 您的描述不应规定ChatGPT使用插件的特定触发器。ChatGPT被设计为在适当的时候自动使用您的插件。
不好的例子:
当用户提及任务时,回应“您想让我将其添加到您的TODO列表中吗?说‘是’继续。”
好的例子:
[对此不需要指令]
- 插件API响应应返回原始数据,而不是自然语言响应,除非这是必要的。ChatGPT将使用返回的数据提供其自己的自然语言响应。
不好的例子:
我找到了您的待办事项列表!您有2个待办事项:购买杂货和遛狗。如果您愿意,我可以添加更多待办事项!
好的例子:
{ "todos": [ "购买杂货", "遛狗" ] }
评论