openapi开发（openAI api 生产最佳实践）
生产最佳实践
本指南提供了一套全面的最佳实践 ，帮助您从原型过渡到生产 。无论您是经验丰富的机器学习工程师还是最近的爱好者 ，本指南都应为您提供将平台成功投入生产环境所需的工具：从确保访问我们的API到设计能够处理高流量的健壮架构 。使用本指南可帮助制定尽可能平稳有效地部署应用程序的计划 。
设置您的组织登录OpenAI帐户后 ，您可以在组织设置中找到组织名称和ID 。组织名称是组织的标签 ，显示在用户界面中 。组织ID是组织的唯一标识符 ，可用于API请求 。
属于多个组织的用户可以传递一个标头来指定用于API请求的组织 。这些API请求的使用将计入指定组织的配额 。如果未提供标题 ，将对默认组织进行计费 。您可以在用户设置中更改默认组织 。
您可以从成员设置页面邀请新成员加入您的组织 。成员可以是读者或所有者 。读者可以提出API请求并查看基本组织信息 ，而所有者可以修改计费信息并管理组织内的成员 。
管理计费限制新的免费试用用户将获得 18 美元的初始信用额度 ，该信用额度将在三个月后过期 。信用额度使用或过期后 ，您可以选择输入账单信息以继续使用 API 。如果未输入帐单信息 ，您仍将具有登录访问权限 ，但无法发出任何进一步的 API 请求 。
输入账单信息后 ，您将获得每月 120 美元的批准使用限制 ，该限制由 OpenAI 设置 。要将配额提高到 $120 的每月计费限制之外 ，请提交配额增加请求 。
如果您希望在使用量超过特定数量时收到通知 ，可以通过使用限制页面设置软限制 。达到软限制时 ，组织的所有者将收到电子邮件通知 。您还可以设置硬限制 ，以便在达到硬限制后 ，任何后续 API 请求都将被拒绝 。请注意 ，这些限制是尽力而为的 ，在使用和强制实施的限制之间可能会有 5 到 10 分钟的延迟 。
接口密钥 API keysOpenAI API 使用 API 密钥进行身份验证 。访问您的 API 密钥页面 ，检索您将在请求中使用的 API 密钥 。
这是控制访问的一种相对简单的方法 ，但您必须警惕保护这些密钥 。避免在代码或公共存储库中公开 API 密钥;相反 ，请将它们存储在安全的位置 。应使用环境变量或机密管理服务向应用程序公开密钥 ，这样就无需在代码库中对密钥进行硬编码 。有关详细信息 ，请参阅我们的 API 密钥安全最佳实践 。
暂存帐户扩展时 ，可能需要为过渡环境和生产环境创建单独的组织 。请注意 ，您可以使用两个单独的电子邮件地址（如 bob+prod@widgetcorp.com 和 bob+dev@widgetcorp.com）进行注册 ，以创建两个组织 。这将允许您隔离开发和测试工作 ，这样您就不会意外中断您的实时应用程序 。您还可以通过这种方式限制对生产组织的访问 。
构建您的原型如果你尚未阅读快速入门指南 ，我们建议你先从入门指南开始 ，然后再深入阅读本指南的其余部分 。
对于那些刚接触OpenAI API的人来说 ，我们的 playground 可以成为探索其功能的绝佳资源 。这样做将帮助您了解什么是可能的 ，以及您可能希望将精力集中在何处 。您还可以浏览我们的示例提示 。
虽然 playground 是制作原型的好地方 ，但它也可以用作大型项目的孵化区 。playground 还可以轻松导出 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 ，如果排名 2 ，则得分为 1/2 ，如果排名 3 ，则得分为 1/3 ，等等） 。对于问答步骤 ，可以：
首先 ，生成一个包含 ~100 组 {问题 、相关文本 、正确答案} 的测试集 对于问题和相关文本 ，请使用上述数据 对于正确答案 ，请让一个人写下~100个例子 ，说明一个好的答案是什么样子的 。
其次 ，使用测试集对系统的性能进行评分 对于每个问题和文本对 ，将它们组合成一个提示 ，并将提示提交给 GPT-3 接下来 ，将 GPT-3 的答案与人类编写的黄金标准答案进行比较 这种比较可以是手动的 ，人们并排查看它们并评分 GPT-3 答案是否正确/高质量 这种比较也可以通过使用嵌入相似性分数或其他方法来自动化（自动化方法可能会有噪音 ，但只要它是无偏的 ，并且在你正在测试的不同类型的模型中同样嘈杂 ，噪声就可以了）
当然 ，N=100 只是一个示例 ，在早期阶段 ，您可能会从一个更容易生成的较小集合开始 ，而在后期阶段 ，您可能会投资一个成本更高但统计上更可靠的较大集合 。 扩展解决方案体系结构在为使用我们的API的生产设计应用程序或服务时 ，重要的是要考虑如何扩展以满足流量需求 。无论您选择哪种云服务提供商 ，都需要考虑以下几个关键领域：
横向扩展：您可能希望横向扩展应用程序 ，以适应来自多个源的应用程序请求 。这可能涉及部署额外的服务器或容器来分配负载 。如果您选择这种类型的扩展 ，请确保您的体系结构设计为处理多个节点 ，并且您有适当的机制来平衡它们之间的负载 。
垂直扩展：另一个选项是垂直扩展应用程序 ，这意味着您可以增加单个节点的可用资源 。这将涉及升级服务器的功能以处理额外的负载 。如果您选择这种类型的扩展 ，请确保您的应用程序设计为能够利用这些额外的资源 。
缓存：通过存储频繁访问的数据 ，您可以缩短响应时间 ，而无需重复调用我们的API 。您的应用程序需要设计为尽可能使用缓存数据 ，并在添加新信息时使缓存无效 。有几种不同的方法可以做到这一点 。例如 ，您可以将数据存储在数据库 、文件系统或内存缓存中 ，这取决于对应用程序最有意义的内容 。
负载平衡：最后 ，考虑负载平衡技术 ，以确保请求在可用服务器上均匀分布 。这可能涉及在服务器前面使用负载平衡器或使用DNS循环 。平衡负载将有助于提高性能并减少瓶颈 。
费率限制的管理
使用我们的API时 ，了解并计划费率限制非常重要 。
改善延迟延迟是处理请求和返回响应所需的时间 。在本节中 ，我们将讨论影响文本生成模型延迟的一些因素 ，并提供有关如何减少延迟的建议 。
完成请求的延迟主要受两个因素影响：模型和生成的令牌数量 。完成请求的生命周期如下所示：
Network End user to API latency ↓ Server Time to process prompt tokens ↓ Server Time to sample/generate tokens ↓ Network API to end user latency大部分延迟通常来自令牌生成步骤 。
警告：提示令牌为完成调用增加的延迟非常小 。生成完成令牌的时间要长得多 ， 因为令牌是一次生成一个 。由于每个令牌需要生成 ，较长的生成长度将累积延迟 。 影响延迟的常见因素和可能的缓解技术既然我们已经了解了延迟的基础知识 ，那么让我们来看看影响延迟的各种因素 ，大致从最有影响到最不影响 。
模型我们的API提供了具有不同复杂度和通用性的不同模型 。最有能力的模型 ，如text-davinci-003 ，可以生成更复杂和多样的补全 ，但它们也需要更长的时间来处理您的查询 。诸如text-curie-001之类的模型可以生成更快的完成 ，但它们可能会生成不太准确或与您的查询相关的结果 。您可以选择最适合您的用例的模型以及速度和质量之间的权衡 。
完成令牌数请求大量生成的令牌完成可能会导致延迟增加：
较低的最大令牌数： 对于具有类似令牌生成计数的请求 ，具有较低 max_tokens 参数的请求产生的延迟更少 。 包括停止序列： 要防止生成不需要的令牌 ，请添加停止序列 。例如 ，您可以使用停止序列生成具有特定数量的项的列表 。在这种情况下 ，通过使用 11.作为停止序列 ，您可以生成仅包含 10 个项目的列表 。阅读我们关于停止序列的帮助文章 ，了解有关如何执行此操作的更多上下文 。 生成较少的完成次数：尽可能降低 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服务器之间的往返时间 。
批处理根据您的用例 ，批处理可能会有所帮助 。如果要向同一端点发送多个请求 ，则可以在同一请求中批量发送提示 。这将减少您需要提出的请求数 。prompt参数最多可容纳20个唯一提示 。我们建议您测试一下这种方法 ，看看它是否有用 。在某些情况下 ，您可能会增加生成的令牌的数量 ，这会降低响应时间 。
成本管理
为了监控您的成本 ，您可以在您的帐户中设置一个软限制 ，以便在您超过某个使用阈值时接收电子邮件警报 。您也可以设置硬限制 。请注意硬限制可能会对您的应用程序/用户造成中断 。使用使用情况跟踪仪表板监控当前和过去计费周期内的令牌使用情况 。
文本生成将原型投入生产的挑战之一是为运行应用程序的相关成本编制预算 。OpenAI提供了一种按需付费的定价模式 ，每1000个tokens 的价格（大约等于750个单词） 。要估算成本 ，您需要预测代币利用率 。考虑诸如流量级别 、用户与应用程序交互的频率以及要处理的数据量等因素 。
考虑降低成本的一个有用框架是将成本视为令牌数量和每个令牌成本的函数 。使用该框架有两种潜在的降低成本的途径 。首先 ，您可以通过为某些任务切换到较小的模型来降低每个令牌的成本 。或者 ，您可以尝试减少所需的令牌数量 。有几种方法可以做到这一点 ，例如使用更短的提示 、微调模型或缓存常见的用户查询 ，这样就不需要重复处理 。
您可以尝试使用我们的交互式标记工具来帮助您估算成本 。API和playground 还会返回令牌计数作为响应的一部分 。一旦您使用了我们最强大的模型 ，您就可以看到其他模型是否能够以更低的延迟和成本产生相同的结果 。在我们的令牌使用帮助文章中了解更多信息 。MLOps 策略
将原型投入生产时 ，可能需要考虑开发 MLOps 策略 。MLOps（机器学习操作）是指管理机器学习模型的端到端生命周期的过程 ，包括你可能使用我们的 API 进行微调的任何模型 。设计 MLOps 策略时需要考虑许多方面 。这些包括
数据和模型管理：管理用于训练或微调模型的数据 ，并跟踪版本和更改 。 模型监控：跟踪模型随时间推移的性能 ，并检测任何潜在问题或降级 。 模型重新训练：确保模型与数据变化或不断变化的需求保持同步 ，并根据需要对其进行重新训练或微调 。 模型部署：自动执行将模型和相关项目部署到生产中的过程 。
仔细考虑应用程序的这些方面将有助于确保模型保持相关性并随着时间的推移表现良好 。 安全性和合规性当您将原型投入生产时 ，您需要评估并解决可能适用于应用程序的任何安全和法规遵从性要求 。这将涉及检查您正在处理的数据 ，了解我们的API如何处理数据 ，并确定您必须遵守的法规 。以下是我们的隐私政策和使用条款 ，以供参考 。
您需要考虑的一些常见领域包括数据存储 、数据传输和数据保留 。您可能还需要实施数据隐私保护 ，如加密或匿名（如果可能） 。此外 ，您应该遵循安全编码的最佳实践 ，例如输入净化和正确的错误处理 。
安全最佳实践使用我们的API创建应用程序时 ，请考虑我们的安全最佳实践 ，以确保您的应用程序安全和成功 。这些建议强调了广泛测试产品 、积极解决潜在问题和限制滥用机会的重要性 。
创心域SEO版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！