本指南提供了一套全面的最佳实践，可帮助您从原型过渡到生产。无论您是经验丰富的机器学习工程师还是最近的爱好者，本指南都应为您提供成功将平台在生产环境中运行所需的工具：从保护对 API 的访问到设计可以处理高流量的强大架构。使用本指南可帮助制定计划，以尽可能顺利有效地部署应用程序。
原文链接：Production best practices – OpenAI API
设置您的组织
登录 OpenAI 帐户后，您可以在组织设置中找到您的组织名称和 ID。组织名称是组织的标签，显示在用户界面中。组织 ID 是组织的唯一标识符，可用于 API 请求。
属于多个组织的用户可以传递标头以指定用于 API 请求的组织。这些 API 请求的使用量将计入指定组织的配额。如果未提供标头，则将对默认组织计费。您可以在用户设置中更改默认组织。
您可以从成员设置页面邀请新成员加入您的组织。成员可以是读者或所有者。读者可以发出 API 请求并查看组织的基本信息，而所有者可以修改账单信息并管理组织内的成员。
管理计费限制
新的免费试用用户将获得 18 美元的初始信用额度，该信用额度将在三个月后过期。信用额度使用或过期后，您可以选择输入账单信息以继续使用 API。如果未输入帐单信息，您仍将具有登录访问权限，但无法发出任何进一步的 API 请求。
输入账单信息后，您将获得每月 120 美元的批准使用限制，该限制由 OpenAI 设置。要将配额提高到 $120 的每月计费限制之外，请提交配额增加请求。
如果您希望在使用量超过特定数量时收到通知，可以通过使用限制页面设置软限制。达到软限制时，组织的所有者将收到电子邮件通知。您还可以设置硬限制，以便在达到硬限制后，任何后续 API 请求都将被拒绝。请注意，这些限制是尽力而为的，在使用和强制实施的限制之间可能会有 5 到 10 分钟的延迟。
接口密钥
OpenAI API 使用 API 密钥进行身份验证。访问您的 API 密钥页面，检索您将在请求中使用的 API 密钥。
这是控制访问的一种相对简单的方法，但您必须警惕保护这些密钥。避免在代码或公共存储库中公开 API 密钥;相反，请将它们存储在安全的位置。应使用环境变量或机密管理服务向应用程序公开密钥，这样就无需在代码库中对密钥进行硬编码。有关详细信息，请参阅我们的 API 密钥安全最佳实践。
暂存帐户
扩展时，可能需要为过渡环境和生产环境创建单独的组织。请注意，您可以使用两个单独的电子邮件地址（如 bob+prod@widgetcorp.com 和 bob+dev@widgetcorp.com）进行注册，以创建两个组织。这将允许您隔离开发和测试工作，这样您就不会意外中断您的实时应用程序。您还可以通过这种方式限制对生产组织的访问。
构建您的原型
如果你尚未阅读快速入门指南，我们建议你先从入门指南开始，然后再深入阅读本指南的其余部分。
对于那些刚接触OpenAI API的人来说，我们的游乐场可以成为探索其功能的绝佳资源。这样做将帮助您了解什么是可能的，以及您可能希望将精力集中在何处。您还可以浏览我们的示例提示。
虽然游乐场是制作原型的好地方，但它也可以用作大型项目的孵化区。游乐场还可以轻松导出 API 请求的代码片段并与协作者共享提示，使其成为开发过程中不可或缺的一部分。
其他提示
- 首先确定您希望应用程序具有的核心功能。考虑您需要的数据输入、输出和流程的类型。旨在使原型尽可能集中，以便您可以快速有效地进行迭代。
- 选择您最熟悉且最符合您的项目目标的编程语言和框架。一些流行的选项包括Python，Java和Node.js。请参阅库支持页面，了解有关我们的团队和更广泛的开发人员社区维护的库绑定的更多信息。
- 开发环境和支持：使用正确的工具和库设置开发环境，并确保拥有训练模型所需的资源。利用我们的文档、社区论坛和帮助中心获取故障排除帮助。如果您正在使用 Python 进行开发，请查看此结构化项目指南（存储库结构是项目架构的关键部分）。要与我们的支持工程师联系，只需登录您的帐户并使用“帮助”按钮开始对话。
提高提示可靠性的技术
即使经过仔细规划，在应用程序中使用 GPT-3 时，为意外问题做好准备也很重要。在某些情况下，模型可能会在任务上失败，因此考虑可以执行哪些操作来提高应用程序的可靠性会很有帮助。
如果您的任务涉及逻辑推理或复杂性，您可能需要采取其他步骤来构建更可靠的提示。有关一些有用的建议，请参阅我们的提高可靠性的技术指南。总体而言，建议围绕：
- 将不可靠的操作分解为更小、更可靠的操作（例如，选择推理提示)
- 使用多个步骤或多个关系使系统的可靠性高于任何单个组件（例如，maieutic 提示)
评估和迭代
开发生产系统最重要的方面之一是定期评估和迭代实验。此过程允许您测量性能、解决问题和微调模型以提高准确性和效率。此过程的一个关键部分是为功能创建评估数据集。以下是需要记住的几点：
- 确保评估集代表模型将在现实世界中使用的数据。这将使您能够评估模型在以前从未见过的数据上的性能，并帮助您了解它对新情况的泛化程度。
- 定期更新评估集，以确保它随着模型的发展和新数据的出现而保持相关性。
- 使用各种指标来评估模型的性能。根据您的应用程序和业务成果，这可能包括准确性、精度、召回率、F1 分数或平均精度 （MAP）。此外，您可以将微调与权重和偏差同步，以跟踪实验、模型和数据集。
- 将模型的性能与基线进行比较。这将使您更好地了解模型的优点和缺点，并有助于指导您未来的开发工作。
通过定期评估和迭代试验，您可以确保 GPT 驱动的应用程序或原型随着时间的推移不断改进。
评估语言模型
语言模型可能难以评估，因为评估生成的语言的质量通常是主观的，并且有许多不同的方法可以用语言正确传达相同的消息。例如，在评估一个模型总结一长段文本的能力时，有许多正确的摘要。话虽如此，设计良好的评估对于机器学习的进步至关重要。
评估套件需要全面、易于运行且速度相当快（取决于模型大小）。它还需要易于继续添加到套件中，因为一个月的综合内容可能会在另一个月过时。我们应该优先考虑拥有多样化的任务和任务，以识别模型或功能中的弱点，这些弱点没有随着扩展而改进。
评估系统的最简单方法是手动检查其输出。它正在做你想做的事吗？输出是否高质量？它们是否一致？
自动评估
加快测试速度的最佳方法是开发自动评估。但是，这在更主观的应用程序中（如摘要任务）中可能无法实现。
当很容易将最终输出分级为正确或不正确时，自动评估效果最佳。例如，如果要微调分类器以将文本字符串分类为 A 类或 B 类，则相当简单：使用示例输入和输出对创建一个测试集，在输入上运行系统，然后根据正确的输出对系统输出进行分级（查看准确性、F1 分数、交叉熵等指标）。
如果您的输出是半开放式的，就像会议记录摘要器一样，那么定义成功可能会更棘手：例如，是什么让一个摘要比另一个更好？在这里，可能的技术包括：
- 用“黄金标准”答案编写一个测试，然后测量每个黄金标准答案和系统输出之间的某种相似性分数（我们已经看到嵌入在这方面效果很好）
- 构建一个鉴别器系统来判断/排名输出，然后给该鉴别器一组输出，其中一个由被测系统生成（这甚至可以是 GPT 模型，询问问题是否被给定输出正确回答）
- 建立一个评估模型，检查答案组成部分的真实性;例如，检测引用是否实际出现在给定文本中
对于非常开放的任务，例如创意故事作者，自动评估更加困难。尽管有可能开发质量指标来查看拼写错误、单词多样性和可读性分数，但这些指标并不能真正捕捉到一篇文章的创意质量。在找不到好的自动化指标的情况下，人工评估仍然是最佳方法。
评估基于 GPT-3 的系统的示例过程
作为一个例子，让我们考虑构建基于检索的问答系统的情况。
基于检索的问答系统有两个步骤。首先，用户的查询用于对知识库中可能相关的文档进行排名。其次，GPT-3 获得排名靠前的文档，并要求生成查询的答案。
可以进行评估以衡量每个步骤的性能。
对于搜索步骤，可以：
- 首先，生成一个包含 ~100 个问题的测试集，并为每个问题生成一组正确的文档
- 如果您有任何问题，这些问题可以来自用户数据;否则，您可以发明一组风格和难度不同的问题。
- 对于每个问题，请让一个人手动搜索知识库并记录包含答案的文档集。
- 其次，使用测试集对系统的性能进行评分
- 对于每个问题，使用系统对候选文档进行排名（例如，通过文档嵌入与查询嵌入的余弦相似性）。
- 如果候选文档至少包含 1 个来自答案键的相关文档，则可以以二进制准确性分数 1 对结果进行评分，否则则为 0
- 您还可以使用连续指标，如平均倒数排名，它可以帮助区分接近正确或远非正确的答案（例如，如果正确的文档是排名 1，则得分为 1/2，如果排名 3，则得分为 <>/<>，如果排名 <>，则得分为 <>/<>，等等）。
对于问答步骤，可以：
- 首先，生成一个包含 ~100 组 {问题、相关文本、正确答案} 的测试集
- 对于问题和相关文本，请使用上述数据
- 对于正确答案，请让一个人写下~100个例子，说明一个好的答案是什么样子的。
其次，使用测试集对系统的性能进行评分
- 对于每个问题和文本对，将它们组合成一个提示，并将提示提交给 GPT-3
- 接下来，将 GPT-3 的答案与人类编写的黄金标准答案进行比较
- 这种比较可以是手动的，人们并排查看它们并评分 GPT-3 答案是否正确/高质量
- 这种比较也可以通过使用嵌入相似性分数或其他方法来自动化（自动化方法可能会有噪音，但只要它是无偏的，并且在你正在测试的不同类型的模型中同样嘈杂，噪声就可以了）
当然，这只是一个例子，在早期阶段，你可能会从一个更容易生成的较小集合开始，而在后期阶段，你可能会投资一个更大的集合，它的成本更高，但在统计上更可靠。N=100
扩展解决方案体系结构
在使用我们的 API 为生产环境设计应用程序或服务时，请务必考虑如何扩展以满足流量需求。无论您选择哪种云服务提供商，您都需要考虑几个关键领域：
- 水平缩放：你可能希望水平横向扩展应用程序，以适应来自多个源的应用程序请求。这可能涉及部署其他服务器或容器来分配负载。如果选择这种类型的缩放，请确保您的体系结构设计为处理多个节点，并且您有适当的机制来平衡它们之间的负载。
- 垂直扩展：另一种选择是垂直纵向扩展应用程序，这意味着您可以增强单个节点可用的资源。这将涉及升级服务器的功能以处理额外的负载。如果选择这种类型的缩放，请确保应用程序设计为利用这些额外资源。
- 缓存：通过存储频繁访问的数据，您可以缩短响应时间，而无需重复调用我们的 API。应用程序需要设计为尽可能使用缓存数据，并在添加新信息时使缓存失效。有几种不同的方法可以做到这一点。例如，您可以将数据存储在数据库、文件系统或内存中缓存中，具体取决于什么对应用程序最有意义。
- 负载平衡：最后，考虑负载平衡技术，以确保请求在可用服务器之间均匀分布。这可能涉及在服务器前面使用负载均衡器或使用 DNS 轮循机制。平衡负载将有助于提高性能并减少瓶颈。
管理速率限制
使用我们的 API 时，了解和规划速率限制非常重要。
改善延迟
延迟是处理请求和返回响应所需的时间。在本节中，我们将讨论影响文本生成模型延迟的一些因素，并提供有关如何减少延迟的建议。
完成请求的延迟主要受两个因素影响：模型和生成的令牌数量。完成请求的生命周期如下所示：
大部分延迟通常来自令牌生成步骤。
直觉：提示令牌为完成调用增加的延迟非常小。生成完成令牌的时间要长得多，因为令牌是一次生成一个。由于每个令牌需要生成，较长的生成长度将累积延迟。
影响延迟的常见因素和可能的缓解技术
现在我们已经了解了延迟的基础知识，让我们看一下可能影响延迟的各种因素，大致从影响最大到影响最小。
模型
我们的API提供了具有不同复杂度和通用性的不同模型。功能最强大的模型（如 text-davinci-003）可以生成更复杂、更多样化的完成，但它们也需要更长的时间来处理查询。 诸如 text-curie-001之类的模型可以生成更快的完成速度，但它们可能会生成不太准确或与查询不太相关的结果。您可以选择最适合您的用例的模型，并在速度和质量之间进行权衡。
完成令牌数
请求大量生成的令牌完成可能会导致延迟增加：
- 较低的最大令牌数：对于具有类似令牌生成计数的请求，具有较低参数
max_tokens的请求产生的延迟更少。 - 包括停止序列：要防止生成不需要的令牌，请添加停止序列。例如，您可以使用停止序列生成具有特定数量的项的列表。在这种情况下，通过用作停止序列，您可以生成一个仅包含 10 个项目的列表，因为完成将在达到时停止。阅读我们关于停止序列的帮助文章，了解有关如何执行此操作的更多上下文。
11.11. - 生成较少的完成次数：尽可能降低
n和best_of的值，n指为每个提示生成的完成次数，best_of用于表示每个令牌对数概率最高的结果。
如果 n 和 best_of 都等于 1（这是默认值），则生成的令牌数最多等于max_tokens 。
如果 n（返回的完成数）或 best_of（为考虑而生成的完成数）设置为 > 1 ，则每个请求将创建多个输出。在这里，您可以将生成的令牌数量视为[ max_tokens * max (n, best_of) ]
流
在请求中进行设置 stream: true 会使模型在令牌可用时立即开始返回令牌，而不是等待生成完整的令牌序列。它不会更改获取所有令牌的时间，但它减少了我们想要显示部分进度或将停止生成的应用程序的第一个令牌的时间。这可以是更好的用户体验和用户体验改进，因此值得尝试流式传输。
基础设施
我们的服务器目前位于美国。虽然我们希望将来能够实现全局冗余，但与此同时，您可以考虑将基础设施的相关部分定位在美国，以最大限度地减少服务器和 OpenAI 服务器之间的往返时间。
批处理
根据您的使用案例，批处理可能会有所帮助。如果要向同一终端节点发送多个请求，则可以在同一请求中批量发送提示。这将减少您需要发出的请求数量。提示参数最多可容纳 20 个唯一提示。我们建议您测试此方法，看看是否有帮助。在某些情况下，您最终可能会增加生成的令牌数量，这会减慢响应时间。
管理成本
要监控您的成本，您可以在帐户中设置软限制，以便在超过特定使用阈值后接收电子邮件警报。您还可以设置硬性限制。请注意硬限制可能会对应用程序/用户造成中断。使用使用情况跟踪仪表板监视当前和过去的计费周期内的令牌使用情况。
文本生成
将原型投入生产的挑战之一是预算与运行应用程序相关的成本。OpenAI提供即用即付的定价模式，每1个代币的价格（大约等于000个单词）。若要估算成本，需要预测令牌利用率。考虑流量级别、用户与应用程序交互的频率以及将要处理的数据量等因素。
考虑降低成本的一个有用框架是将成本视为代币数量和每个代币成本的函数。使用此框架有两种降低成本的潜在途径。首先，您可以通过为某些任务切换到较小的模型来降低成本，从而降低每个令牌的成本。或者，您可以尝试减少所需的令牌数量。有几种方法可以执行此操作，例如使用较短的提示、微调模型或缓存常见用户查询，以便不需要重复处理它们。
您可以尝试使用我们的交互式分词器工具来帮助您估算成本。API 和操场还会返回令牌计数作为响应的一部分。使用我们功能最强大的模型后，您可以查看其他模型是否可以以更低的延迟和成本产生相同的结果。有关详细信息，请参阅我们的令牌使用帮助文章。
MLOps 策略
将原型投入生产时，可能需要考虑开发 MLOps 策略。MLOps（机器学习操作）是指管理机器学习模型的端到端生命周期的过程，包括你可能使用我们的 API 进行微调的任何模型。设计 MLOps 策略时需要考虑许多方面。这些包括
- 数据和模型管理：管理用于训练或微调模型的数据，并跟踪版本和更改。
- 模型监控：跟踪模型随时间推移的性能，并检测任何潜在问题或降级。
- 模型重新训练：确保模型与数据变化或不断变化的需求保持同步，并根据需要对其进行重新训练或微调。
- 模型部署：自动执行将模型和相关项目部署到生产中的过程。
仔细考虑应用程序的这些方面将有助于确保模型保持相关性并随着时间的推移表现良好。
安全性和合规性
将原型投入生产时，需要评估并满足可能适用于应用程序的任何安全性和合规性要求。这将涉及检查您正在处理的数据，了解我们的API如何处理数据，并确定您必须遵守哪些法规。作为参考，以下是我们的隐私政策和使用条款。
您需要考虑的一些常见领域包括数据存储、数据传输和数据保留。您可能还需要实施数据隐私保护，例如加密或匿名化（如果可能）。此外，还应遵循安全编码的最佳做法，例如输入清理和正确的错误处理。
安全最佳实践
使用我们的 API 创建应用程序时，请考虑我们的安全最佳实践，以确保您的应用程序安全且成功。这些建议强调了广泛测试产品、积极主动地解决潜在问题以及限制滥用机会的重要性。