对抗性测试
我们建议“红队”您的应用程序，以确保它对对抗性输入具有鲁棒性。 在广泛的输入和用户行为范围内测试您的产品，包括代表性集和反映有人试图“破坏”您的应用程序的集。 它会偏离主题吗？ 有人可以通过提示注入轻松重定向该功能吗？ “忽略之前的说明并改为执行此操作”？
人工循环中(HITL)
只要有可能，我们建议在实际使用之前对输出进行人工审查。 这在高风险领域和代码生成中尤为重要。 人们应该意识到系统的局限性，并且可以访问验证输出所需的任何信息(例如，如果应用程序总结了笔记，人们应该可以轻松访问原始笔记以供参考)。
提示工程
“提示工程”可以帮助约束输出文本的主题和语气。 这减少了产生不需要的内容的机会，即使用户试图产生它。 为模型提供额外的上下文(例如通过在新输入之前给出一些所需行为的高质量示例)可以更容易地将模型输出引导到所需的方向。
“了解你的客户”(KYC)
用户通常需要注册和登录才能访问您的服务。 将此服务链接到现有帐户(例如 Gmail、LinkedIn 或 Facebook 登录)可能会有所帮助，但可能并不适合所有用例。 要求提供信用卡或身份证可进一步降低风险。
约束用户输入和限制输出令牌
限制用户可以输入到提示中的文本量有助于避免提示注入。 限制输出令牌的数量有助于减少误用的机会。
缩小输入或输出的范围，尤其是来自可信来源的输入或输出范围，可以减少应用程序中可能的误用程度。
允许用户通过经过验证的下拉字段(例如，维基百科上的电影列表)输入比允许开放式文本输入更安全。
在可能的情况下，从后端经过验证的一组材料返回输出比返回新生成的内容更安全(例如，将客户查询路由到最匹配的现有客户支持文章，而不是尝试从- 划痕)。
允许用户报告问题
用户通常应该有一种易于使用的方法来报告不当功能或有关应用程序行为的其他问题(列出的电子邮件地址、票证提交方法等)。 此方法应由人工监控并酌情做出响应。
理解和传达限制
从幻觉的不准确信息到令人反感的输出，再到偏见等等，如果不进行重大修改，语言模型可能并不适合所有用例。 考虑模型是否适合您的目的，并评估 API 在广泛的潜在输入上的性能，以确定 API 性能可能下降的情况。 考虑您的客户群和他们将使用的输入范围，并确保他们的期望得到适当校准。
如果在您的开发过程中您确实注意到 API 或任何其他与 OpenAI 相关的安全问题，请通过我们的协调漏洞披露计划 提交这些问题 .
最终用户ID
在您的请求中发送最终用户 ID 可以成为帮助 OpenAI 监控和检测滥用的有用工具。 如果我们在您的应用程序中检测到任何违反政策的情况，这允许 OpenAI 为您的团队提供更多可操作的反馈。
ID 应该是唯一标识每个用户的字符串。 我们建议散列他们的用户名或电子邮件地址，以避免向我们发送任何识别信息。 如果您向未登录的用户提供产品预览，您可以改为发送会话 ID。
您可以通过 user 参数在 API 请求中包含最终用户 ID，如下所示：
curl https://api.openai.com/v1/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d '{
"model": "text-davinci-003",
"prompt": "This is a test",
"max_tokens": 5,
"user": "user123456"
}'