当出现新的创新或技术转变时,大公司通常是最后采用的。它们的等级制结构由各种权威层次组成,标准的法律审批和文书工作流程通常限制了实验的自由,这使得企业很难成为early adopters。但这在GPT-3的情况下似乎并非如此。 尽管API刚刚发布,企业就开始对其进行实验。然而,它们遇到了一个重大障碍:数据隐私。
简单来说,所有语言模型所做的就是根据前面的词序列预测下一个词。正如您在第2章中了解到的,OpenAI设计了几种技术,将GPT-3等语言模型的功能从简单的下一个词预测转变为更有用的NLP任务,如回答问题、总结文档和生成与上下文相关的文本。 通常,通过在训练提示中提供一些示例或创建一个定制的训练模型来微调语言模型或使其模拟特定行为,可以获得最佳结果。 您可以在训练提示中提供示例,但更强大的解决方案是使用fine-tuning API创建一个定制的训练模型。
OpenAI以开放式API的形式提供GPT-3,其中用户提供输入数据,API返回输出数据。 妥善保护、处理和处理用户数据是有兴趣使用GPT-3的公司需要考虑的一个关键问题。 OpenAI的Welinder指出,尽管企业领导者对GPT-3表达了各种担忧,但“SOC2合规性、地理围栏和在私有网络中运行API的功能是他们最大的担忧。”
OpenAI为模型安全性和误用设计的措施因此旨在解决数据隐私和安全问题这一宽泛问题。 例如,Stenography的创始人Bram Adams告诉我们OpenAI API的隐私和安全方面的问题。 “就目前而言,Stenography是一个直通API —— 它就像一条收费公路。 以便人们可以传递代码,原封不动地传递给OpenAI API,而不会在任何地方保存或记录它。” 在这些防护之外,Stenography就是OpenAI使用条款的超集。
我们与几家公司代表交谈,了解是什么阻止他们在生产中使用OpenAI API。 大多数人强调两个常见问题:
OpenAI公开的GPT-3 API的endpoint不应保留或保存作为模型fine-tuning/训练过程一部分提供给它的任何训练数据的任何部分。
在将数据发送到OpenAI API之前,公司希望确保第三方不能通过向API提供任何输入来提取或访问数据。
OpenAI通过提供安全性审查、企业合同、数据处理协议、第三方安全认证工作等来响应上述客户的关注和问题围绕数据处理和隐私。 在本章的其余部分,我们将深入探讨GitHub、Microsoft和Algolia等全球企业是如何解决这些问题并在规模上使用GPT-3的。 您还将了解OpenAI如何通过与Microsoft Azure OpenAI服务合作来适应企业级产品的需求。
案例研究:GitHub Copilot
让我们从2021年最热门的产品之一GitHub Copilot(图5-1)开始这段旅程。 GitHub Copilot是一个首创的AI成对编程器,可帮助用户更快更轻松地编写代码。 GitHub Next副总裁Oege de Moor说,其任务是“接触所有开发人员,最终目标是使编程对所有人都是可访问的。” 自动化冗长的任务(如编写冗余代码和编写单元测试用例)可以让开发人员“更关注工作的真正创造性部分,这涉及决定软件实际应该做什么”,并且“更多地考虑产品概念,而不是陷入编写代码的困境。”
正如Awan告诉我们的:“我现在更期待处理更多副项目,因为我知道GitHub Copilot会帮助我。Codex和Copilot编写了我代码的2%到10%左右。所以它已经使我提速2%到10%。所有这些都具有指数级的规模。那么明年的GPT-3会是什么样子呢?明年Codex会是什么样子呢?我可能会提速30%。”
让我们深入了解Copilot的内部工作原理。
工作原理
GitHub Copilot根据您正在处理的代码中的上下文绘制推断,例如,docstrings、注释和函数名称。 然后,它会自动建议下一行甚至整个函数,直接在您的编辑器中生成样板代码并建议与代码实现匹配的测试用例。 它使用代码编辑器的插件工作在广泛的框架和编程语言上,使其几乎与语言无关,且轻量且易于使用。
OpenAI研究员Harri Edwards指出,Copilot对于在新语言或框架中工作的程序员也是一个有用的工具:“通过谷歌搜索每件事来用不熟悉的语言编程,就像只带短语书就在外国旅行。 使用GitHub Copilot就像雇佣了一位传译员。”
GitHub Copilot由OpenAI的Codex驱动,这是GPT-3模型的后代,正如我们在第4章中所述,它是专门用于解释和编写代码而设计的。 “GitHub托管超过7300万开发人员,包含了大量公开可用的代码,这体现了社区的集体知识”,deMoor说。 这转化为Codex用于训练的数十亿行公开可用代码。 它理解编程和人类语言。
Codex利用简单英语的支持注释或说明从相关代码中获得线索,如图5-2所示。 Copilot编辑器扩展智能地选择要发送到GitHub Copilot服务的上下文,后者依次运行OpenAI的Codex模型来合成建议。 尽管Copilot生成代码,但用户仍然负责:您可以在建议的选项之间循环,选择接受或拒绝哪些,并手动编辑建议的代码。 GitHub Copilot适应您所做的编辑并匹配您的编码风格。 De Moor解释说:“它将自然语言与源代码联系起来,以便您可以在两个方向使用它。 您可以使用源代码生成注释,或者可以使用注释生成源代码,这使其无比强大。”
这种功能也间接改变了开发人员编写代码的方式。 当他们知道代码注释中的人类语言(如英语)将成为模型培训的一部分时,他们会撰写“更好、更准确的注释,以获得更好的Copilot结果”,de Moor说。
许多评论员担心将此工具交给无法判断代码质量的人可能会导致在代码库中引入错误或 bug。 与这种观点相反,de Moor 告诉我们:“我们收到了许多开发人员的反馈,说明Copilot使他们编写更好、更高效的代码。” 在当前的技术预览中,Copilot只能帮助您编写代码,如果您了解软件中的不同部分的工作方式,然后可以精确地告诉Copilot您想要它做什么。 Copilot鼓励健康的开发人员实践,如编写更准确的注释,并以生成更好的代码来奖励开发人员。
Copilot不仅限于编程的一般规则; 它甚至可以找到特定领域的细节,例如编写用于谱曲的程序。 要做到这一点,您需要了解音乐理论。 “看到Copilot如何以某种方式从其极大的训练数据中获取这一点简直令人惊叹,”de Moor补充说。
开发Copilot
De Moor说,设计Copilot的挑战之一是创建正确的用户体验,“让您可以协作方式使用此模型,而不会侵入性。” 目标是让它感觉像与编程伙伴或同事一起工作,“他知道更多关于枯燥的编码东西,所以您可以更专注于创建重要的东西。” 开发人员不断搜索现有的问题解决方案,并且经常参考Stack Overflow、搜索引擎和博客以获取实现和代码语法详细信息 - 这意味着来回移动编辑器和浏览器。 正如de Moor指出的,“作为开发人员,当您可以留在环境中并且只考虑问题时,您会更有生产力。” 这就是为什么GitHub的团队设计了Copilot,以在开发环境中提供建议。
软件相关产品或服务的开发目前需要技术或科学背景的问题,例如至少要学习一种编程语言。这只是一个开始。即使要用传统技术开发一个最小可行产品,你也需要了解软件工程各个方面涉及的不同元素,包括前端(用户如何与软件交互)和后端(处理逻辑如何工作)。这为那些没有技术或工程背景的人造成了进入壁垒。
De Moor认为Copilot是朝着使技术更易访问和包容的方向迈出的一步。如果开发者“越来越少地需要担心开发细节,只需要解释设计,解释他们想做什么的目的”,并让Copilot处理细节,那么更多人就能够使用这些工具来创建新产品和服务。
已经有几个无代码编程平台,但许多用户发现它们的局限性过于限制,从本质上“大大简化了编程体验”,使其“更加可视化,更加图形化,更易于使用”,根据de Moor的说法。 “这些东西非常适合开始,但不幸的是,它使能够使用这些平台构建的事物存在限制。” De Moor认为,Copilot同样易于使用,但通过使用完全可操作的编程工具而不是简化版本,它提供了更多选择。
在API方面进行扩展
长久以来,由于奥卡姆剃刀等理论概念和神经网络扩展到显著大小时结果的消失,语言模型的规模一直被低估。在传统的深度学习中,由于要避免梯度消失问题并在模型训练过程中引入复杂性,一直有规范要将模型大小保持在较小的参数较少的状态。奥卡姆剃刀暗示“简单的模型是最好的模型”,自诞生以来一直是AI社区的圭臬。这一原则一直是训练新模型的中心参考,这阻碍了人们对规模进行试验的热情。
2020年,当OpenAI发布其重要的语言模型GPT-3时,扩展的潜力引起了人们的注意,AI社区的共同观念开始发生变化。人们开始意识到“规模的恩赐”可以催生更通用的人工智能,其中像GPT-3这样的单一模型可以执行一系列任务。
托管和管理像GPT-3这样的模型需要在许多不同层面上具有精湛技术,包括模型体系结构的优化,其部署以及公众如何访问它。De Moor告诉我们:“当我们推出Copilot时,它在最初阶段使用OpenAI API基础设施,然后在推出后我们迎来了如此之多的人签署并希望使用该产品的爆炸式反应。”
尽管API能够处理大量请求,但实际请求数量及其频率仍使OpenAI团队感到惊讶。De Moor和他的团队“意识到需要一个更高效、更大的基础设施来部署,幸运的是,就在那时候,Microsoft Azure OpenAI出现了”,从而让他们得以进行所需的切换到Azure部署基础设施。
当我们询问构建和扩展Copilot的经验时,de Moor分享说:“早期我们误以为精度是唯一最重要的事情,但在产品之旅的某些时候后来,我们意识到这实际上是强大的AI模型与无缝的用户体验之间的权衡。” Copilot团队很快意识到,与任何足够规模的深度学习模型一样,速度和建议的准确性之间存在权衡。
通常,深度学习模型的层数越多,它就越准确。然而,更多层也意味着运行速度会更慢。Copilot团队不得不在两者之间找到某种平衡,正如de Moor所解释的:“我们的用例要求模型以闪电般的速度提供多个替代建议;如果不够快,用户可以轻松超越模型并自己编写代码。所以,我们发现一个稍微不那么强大的模型,它快速给出响应且维持结果质量”就是答案。
GitHub Copilot的用户采用速度之快和兴趣之大都令团队里的每个人感到惊讶,但这还没有结束。由于产品的有用性和代码建议的质量,团队看到使用Copilot生成的代码量呈指数增长,平均而言,“35%的新编写代码正由Copilot建议。随着我们更接近找到权衡模型功能和建议速度的正确平衡点,这个数字将继续增长“,de Moor说道。
当被询问关于作为请求Copilot一部分提交的代码的数据安全和隐私方面时,de Moor告诉我们:“Copilot架构的设计方式是,当用户将代码键入Copilot时,代码泄露到另一个用户那里的可能性为零。GitHub Copilot是一个代码合成器,而不是搜索引擎:它建议的绝大多数代码是独一无二生成的,以前从未见过。我们发现,约0.1%的时间,建议可能包含一些逐字摘录自训练集的代码段。”
GitHub Copilot的下一步是什么?
De Moor认为Copilot在代码审查以及编写方面都有很大的协助潜力。“想象一下自动代码审查器,它会自动查看你的更改并提出建议,使你的代码变得更好、更高效。GitHub目前的代码审查过程包括人工审查员,我们也在探索Copilot审查的想法。”
另一个正在探索的功能是代码解释。De Moor解释说,用户可以选择一段代码,“Copilot可以用简单的英语对其进行解释。” 这有可能作为一个有用的学习工具。此外,de Moor说,Copilot希望提供帮助“从一种编程语言到另一种编程语言翻译代码”的工具。
Copilot为开发者乃至任何想要创造性地开发软件将自己的想法变为现实的人打开了无限的机会。在GitHub Copilot和OpenAI的Codex之前,生成生产级代码、人工智能辅助代码审查以及在语言之间转换代码等功能一直是遥不可及的梦想。大语言模型与无代码和低代码平台的出现将使人们能够释放创造力并构建有趣和意想不到的应用程序。
案例研究:Algolia Answers
Algolia是一家知名的搜索解决方案提供商,其客户涵盖财富500强公司到新一代创业公司。它提供了一个符号化的、基于关键词的搜索API,可以与任何现有产品或应用程序集成。2020年,Algolia与OpenAI合作,将GPT-3与其已有的搜索技术连接起来。这一新一代的产品服务造就了Algolia Answers,它使客户能够为搜索查询构建一个智能的、基于语义的单一搜索终端。“我们开发其他公司使用的技术,”Algolia的产品经理Dustin Coates说。
Coates说,他们所说的智能搜索大致意思是“你搜索某样东西,立即得到回应,而不仅仅是得到记录、文章,而是得到真正回答问题的内容。” 简而言之,这是“一个搜索体验,人们不必准确输入单词。”
评估NLP选项
Algolia成立了一个专门团队来从事这项工作。当OpenAI联系他们,想了解Algolia是否对GPT-3感兴趣时,Coates的团队将其与竞争技术进行了比较。Algolia机器学习工程师Claire Helme-Guizon是最初Algolia Answers团队的成员,她解释说:“我们在BERT类模型上工作,以优化速度,DistilBERT,以及更稳定的模型,如RoBERTa,以及GPT-3的不同变体,如DaVinci、Ada等。” 他们创建了一个评级系统来比较不同模型的质量,并了解它们的优势和劣势。他们发现,Coates说,GPT-3“在返回的搜索结果质量方面表现非常好”。 速度和“成本是弱点,但API最终是决定因素,因为它允许Algolia在不必维护其基础设施的情况下使用该模型。Algolia询问现有客户是否可能对这样的搜索体验感兴趣,反响非常积极。
即使拥有这种质量的结果,Algolia仍有大量问题:它将如何适用于客户?架构是否可扩展? 在财务上是否可行? 为了回答这些问题,Coates解释说:“我们雕琢了一些具有更长文本内容的具体用例”,如出版和帮助台。
对于某些用例,仅依靠GPT-3获取搜索结果就足够好,但对于其他复杂的用例,可能有必要将GPT-3与其他模型集成。 GPT-3由于仅使用到某个时间点的数据进行训练,在涉及新鲜度、流行度或个性化结果的用例中会遇到困难。 当涉及到结果质量时,Algolia团队面临的挑战是GPT-3生成的语义相似度分数不是客户关心的唯一指标。 他们需要以某种方式将相似度分数与其他测量标准相结合,以确保客户得到令人满意的结果。 因此,他们引入了其他开源模型与GPT-3相结合来突出最佳结果。
数据隐私
Coates说,在引入这项新技术时,Algolia面临的最大挑战是法律挑战。 “通过法律、安全和采购可能是我们在整个项目中做的最困难的事情,因为你正在发送客户数据,并将其馈送到机器学习模型中。 我们如何删除这些数据? 我们如何确保它符合GDPR?我们如何处理所有这些事情? 我们如何知道OpenAI不会拿走这些数据并将其馈送到其他人的模型中? 所以有很多问题需要回答,需要订立很多协议。”
成本
到目前为止,我们看到的大多数GPT-3用例都是面向消费者(B2C)的产品,但对于像Algolia这样的企业对企业(B2B)公司来说,情况不同。 他们不仅需要OpenAI的定价对他们有利,而且还需要为客户优化定价,以便他们“可以获利,客户仍对他们正在构建的产品感兴趣”。
在搜索解决方案业务中,成功是根据通过量来衡量的。 因此,自然会考虑质量、成本和速度之间的权衡。 Coates说:“即使在我们不知道成本之前,Ada对我们来说也是正确的模型,因为速度。 但即使,假设达芬奇足够快,我们可能仍然会下降到Ada,只是因为成本度量。”
Helme-Guizon指出影响成本的因素包括“令牌数量以及发送的文档数量及其长度”。 Algolia的方法是构建“尽可能小的上下文窗口”——意味着一次发送到API的数据量——这仍然会在质量方面“相关足够”。
那么,他们如何解决这个问题呢? Coates解释说:“我们在OpenAI宣布定价之前就开始了,并且我们已经走得足够远,而且看到质量已经足够好,这是从我们在其他地方看到的,不知道定价是多少。 所以有相当多的不眠之夜,不知道定价是多少。 一旦我们知道了定价,[问题是]如何降低成本。 因为当我们第一次看到定价时,我们不确定我们是否能做到这一点。”
据Coates透露,他们确实投入了大量工作来优化适用于他们用例的价格,因为根据Coates的说法,定价将是所有试图在GPT-3之上建立业务的人“普遍存在的挑战”。 因此,强烈建议在产品开发的非常早期阶段就开始考虑价格优化。
速度和延迟
速度对Algolia尤为重要; 该公司向客户承诺闪电般快速的搜索功能,延迟仅限于几毫秒。 当团队评估OpenAI的提案时,他们对结果的质量很满意,但GPT-3的延迟是不可接受的。 “在我们的传统搜索中,结果往返时间少于50毫秒,”Coates说。 “我们正在搜索数亿份文档,必须是实时的。 当我们早期与OpenAI合作时,每个查询花费几分钟时间。”
Algolia确实决定尝试GPT-3,并开始为Algolia Answers进行初步实验和beta测试阶段。 但是,降低延迟和货币成本需要大量努力。 “我们开始于大约300毫秒,有时是400毫秒的总延迟,”Coates回忆道,“我们必须将其降低到50到100毫秒的范围内,才能够为客户使用。” 最终,Algolia想出了语义突出显示技术,该技术在GPT-3之上使用经过训练的问答模型执行微小搜索并找出正确答案。 GPT-3与其他开源模型的组合导致总延迟降低。 Helme-Guizon补充说,他们的结果质量更好,因为“这些模型经过训练以找到答案,而不仅仅是与查询相关的词汇。”
Helme-Guizon说,Algolia Answers架构的一个关键方面是读取器检索架构,其中AI读取器“通过使用Ada读取文档子集并理解它们,并给我们一个语义价值的置信度分数。” 虽然这是“一个不错的初步解决方案”,但她补充说,它存在很多挑战,“特别是延迟,因为你有那种依赖关系,无法同时异步处理第一批和第二批”。
GPT-3使用来自预测的嵌入来计算余弦相似度,这是一种数学度量,用于确定两个文档之间的相似度,而不考虑它们的大小。 Coates总结了这些挑战:首先,“你不能发送太多文档,否则响应会太慢,或者成本会太高”。 其次是“投出足够宽的网来获取所有相关文档,同时控制时间和成本”。
汲取的教训
那么,如果Algolia Answers今天重新开始,它会做些什么不同的事情? “使用GPT-3有时会让人不知所措,”Coates说。 “我们会在产品开发的早期阶段提出一些基本问题,比如‘我们是否愿意牺牲语义理解,因为我们在其他所有方面都有了这么大的改进?’ 我认为我们会在早期阶段就对延迟和不同排名因素的融合有了更多的思考。” 他补充说,他可以看到该项目“返回到基于BERT的模型。 我们可能会说原始质量不同于我们从GPT-3中获得的质量。 这是无可否认的。 但我认为,尽管我们爱上了这项技术,我们发现了我们没有解决的客户问题,技术必须遵循客户问题,而不是相反。”
那么Algolia对搜索的未来有何看法? Coates说:“我们不相信任何人真正解决了文本相关性和语义相关性的融合。 这是一个非常困难的问题,因为你可能会遇到文本相关但并不真正回答问题的情况。” 他设想“将更传统的、基于文本的一面,更可理解和可解释的一面,与这些更高级的语言模型结合起来。”
案例研究:微软Azure OpenAI服务
Algolia已经在OpenAI API上成熟,但不久之后,公司想要扩展其在欧洲的业务,这意味着它需要GDPR合规性。它开始与微软合作,后者正在启动其Azure OpenAI服务。在下一个案例研究中,我们将看一下该服务。
注定要建立伙伴关系
微软和OpenAI于2019年宣布建立伙伴关系,目标是为Azure客户提供访问GPT-3功能的途径。 这种伙伴关系建立在共同的愿景基础之上,即希望确保AI和AGI得到安全可靠的部署。微软向OpenAI投资10亿美元,资助API的启动,后者运行在Azure上。这种伙伴关系的高潮是将API推向市场,为更多人提供访问大型语言模型的途径。
Azure OpenAI服务的首席产品经理兼负责人Dominic Divakaruni说,他一直认为这种合作就像注定要建立的伙伴关系,并指出微软CEO萨蒂亚·纳德拉和OpenAI CEO山姆·奥特曼都多次谈到确保AI的好处能被广泛访问和分发。两家公司也都对AI创新的安全性表示关注。
目标,Divakaruni说,“是利用彼此的优势”,特别是OpenAI的用户体验和建模进步以及微软现有的与公司的关系、大型销售队伍和云基础设施。鉴于其客户基础,微软Azure团队了解企业云客户在合规性、认证、网络安全等方面的基本要求。
对微软来说,对GPT-3的兴趣在很大程度上始于它开辟新天地并在任何其他LLM类别的模型之前可用。微软投资的另一个关键因素是它获得了独家使用OpenAI的知识产权资产的能力。尽管有GPT-3的替代品,但Divakaruni说,OpenAI API的集中化是独一无二的。他指出,文本分析或翻译等服务的模型需要云提供商做“相当多的工作”来调整为API服务。另一方面,OpenAI提供的是“用于各种任务的相同API”,而不是“为特定任务创建的定制API”。
一个本地Azure的OpenAI API
OpenAI知道扩展云基础是必不可少的。从OpenAI API的诞生起,这个想法一直是在Azure中也有API的实例,以接触更多客户。 Divakaruni提到,OpenAI API和Azure OpenAI服务平台之间有更多的相似之处而不是差异。 从技术角度来看,目标非常相似:为人们提供相同的API和访问相同模型的途径。 Azure OpenAI服务的形状将更具Azure本地化,但微软希望与OpenAI客户的开发人员体验相匹配,特别是随着他们中的一些人从OpenAI API过渡到Azure OpenAI服务。
在撰写本书时,我们捕捉到Azure OpenAI服务团队仍在启动该平台,在广泛向客户发布之前,有很多问题需要解决。 OpenAI服务现在正在其服务中添加越来越多的模型; 目标是最终达到与OpenAI API在可用模型方面的同步或只差几个月。
资源管理
这两种服务之间的一个区别在于它们如何处理资源管理。 资源是通过服务(无论是OpenAI API还是Microsoft Azure)可用的可管理项目。 在OpenAI的上下文中,资源的示例将是API帐户或与帐户相关联的信用池。 Azure提供了一组更复杂的资源,如虚拟机、存储帐户、数据库、虚拟网络、订阅和管理组。
而OpenAI为每个组织提供单个API帐户,在Azure中,公司可以创建多个不同的资源,他们可以跟踪、监控和分配到不同的成本中心。 “它只是另一个一般的Azure资源,”Azure OpenAI服务的高级项目经理Christopher Hoder说,这使它可以开箱即用。
Azure中的资源管理是一种部署和管理功能,使客户能够在Azure帐户中创建、更新和删除资源。 它带有诸如访问控制、锁定和标签等功能,以便在部署后确保和组织客户资源。”
Hoder说,Azure有几层资源管理,允许公司和组织更好地管理定价和资源。 在高层次上,有一个组织的Azure帐户,在该帐户中,有多个Azure订阅。 在此 Subscription之内,有资源组,然后是资源本身。 “所有这些都可以进行监控、细分和访问控制,”Hoder补充道,这对大规模部署尤其重要。
安全和数据隐私
尽管微软尚未公开谈论其安全性,但Divakaruni告诉我们,该公司正在关注三个主要点:内容过滤器、滥用监控和安全优先方法。 该团队正在努力实现更多的安全执行元素,并计划使用客户反馈来了解这些元素中的哪些对用户最有意义,然后再正式推出。
团队还正在努力编写文档,详细说明隐私政策的实施架构,这将与客户共享以提供保证,即微软正在保护客户数据,同时确保其对使用人工智能的责任得到维护。 “许多来找我们的客户对OpenAI目前在OpenAI上的实现方式存在担忧,因为它更加开放,我们正在解决这些问题,”Divakaruni说。
内容过滤器以PII(个人身份可识别信息)过滤器的形式引入,它可以屏蔽性内容和其他类型的内容,其范围仍在确立之中。“其中的理念是为客户提供正确的旋钮来调整和迭代其特定域的内容,”Divakaruni说。
微软的企业客户在安全方面要求非常高。Azure OpenAI API服务团队正在利用其为其他产品(如Bing和Office)所做的工作。微软在模型开发和推动前沿方面历史悠久。“Office已经提供语言产品一段时间了。所以有一个相当广泛的内容审核功能......我们有一个专门的科学团队致力于为这些模型和空间构建适当的过滤器,”Divakaruni说。
OpenAI API用户通常请求地理围栏,这是一种围绕现实世界地理区域设置虚拟边界的技术,从而创建筒仓,将数据保存在特定位置。如果数据移动超出指定半径,它可以触发地理启用手机或其他便携式电子设备中的操作。例如,它可以在人员进入或退出地理围栏时向管理员发出警报,然后以推送通知或电子邮件的形式向用户的移动设备生成警报。地理围栏使企业能够准确跟踪、营销并有效地提醒管理员。Azure的地理围栏功能仍在开发中,但Divakaruni说,它已在实验基础上为一些选定的客户(如GitHub Copilot)实现。
面向企业的模型即服务
虽然Azure OpenAI服务一直与平台上的许多大型企业客户合作,但微软不准备公开讨论他们,并引用隐私问题和公众舆论的敏感性。它现在可以提到的都是其内部服务的示例。 GitHub Copilot一开始是在OpenAI API上,但现在主要出于规模原因已过渡到Azure OpenAI服务。运行在Azure上的其他内部服务示例有Dynamics 365客户服务、Power Apps、ML to code和Power BI服务。
Divakaruni说,他们看到许多来自金融服务行业和传统企业的兴趣,这些企业希望提升其客户体验。“有大量的文本信息要处理,并且对总结和帮助分析师(例如)快速确定与他们相关并有意义的文本有很大需求。我认为客户服务行业也是一个巨大的未开发领域。在呼叫中心信息中存在大量被锁定的音频信息,这些信息可以被转录,从而为试图改善客户体验的公司带来有意义的见解。” 他们看到的另一组用例是公司通过为内部API和软件开发工具包训练GPT-3来加速开发人员的生产力,以使这些工具更易于让员工访问。
Divakaruni指出,许多核心优势不在AI或ML中的企业希望以增加业务流程的有意义价值或提高客户体验的方式应用AI。 他们利用微软的实力优势帮助他们“构建解决方案。 Hoder说,Azure OpenAI服务团队完全预期其成熟的模型即服务方法会成为主流。 他指出,微软通过将其嵌入Office和Dynamics等消费者应用程序中来提供其即用体验。 需要更独特或定制支持的客户会下降一层到面向业务用户和开发人员的服务,如Power平台,它提供无代码或低代码方式来定制机器学习和AI。 “如果你下降一点,定制性更强,开发人员更关注,你就会结束在认知服务。 这一直是我们通过基于REST API的服务提供AI功能的模型。 现在我们正在引入OpenAI服务的更细粒度层...... 然后在底层,我们有面向数据科学的Azure机器学习工具,”Hoder解释道。
微软看到Azure OpenAI服务的巨大客户需求,但也可以证明迄今为止其他服务(如语音识别服务和表单识别器)的成功。 “我们看到许多对从图像中提取结构化信息并从PDF中提取表格和其他信息的能力的需求,以进行自动化数据摄取,然后结合分析和搜索功能。” Hoder说。 (请参阅例如本案例研究,了解客户如何使用微软的基于REST API的AI/ML服务。)
其他微软AI和ML服务
Azure OpenAI服务会影响微软产品线中的其他AI/ML服务吗,比如Azure机器学习工作室? Divakaruni告诉我们,两者在市场上都有立足之地:“这绝对不是胜者通吃。 市场上需要多种解决方案来满足特定的客户需求。” 客户的需求可能差异很大。 他们可能需要生成然后标记特定用例的数据。 他们可以使用Azure ML Studio或SageMaker等平台从头开始构建模型,然后针对该目的训练提炼的、较小的模型。
当然,这是一个大多数人无法接触到的利基。 Hoder指出,将数据科学能力带给客户“拓宽了访问权限;它使其民主化。” Divakaruni表示赞同:“越来越多的趋势将通过服务公开最大、最复杂的模型,而不是人们建立自己的模型。 为什么? “基本事实是训练这些模型需要大量的计算和大量的数据。 开发这些模型的公司不幸寥寥无几。 但作为我们所做的,我们有责任使其向世界公开。”
一般来说,能负担得起昂贵资源的数据科学团队强烈倾向于使用较低级别的机器学习平台(如Azure机器学习工作室)为其特定用例构建自己的知识产权。 Divakaruni认为,这种需求不太可能消失。
给企业的建议
Divakaruni说,调查Azure OpenAI服务的企业可以像调查任何其他云服务一样进行调查:您从最适合您的功能开始,然后查看各种技术是否符合您的需求。 “虽然技术很酷,肯定有惊喜因素,但你仍然要从‘哪里对我和我的业务来说最适用’开始。 然后用一组技术来解决它。”
下一步是检查如何从实验转向生产:“您还需要构建什么?” Divakaruni将此步骤称为“某人需要围绕注入的应用程序胶合剂,确保这些模型实际上能够在实时应用程序方案中运行。” 这是一个非常重要的任务,但企业需要考虑这一点,以了解基于GPT-3的应用程序需要投入多少。 Divakaruni建议问自己:“当您实现自动化时,此模型实际上会生成相关内容吗? 在将该功能内置到应用程序中时,它是否正在执行应该执行的操作?”
OpenAI还是Azure OpenAI服务:您应该使用哪个?
那么,对于有兴趣探索GPT-3的公司来说,问题是:OpenAI API还是Azure OpenAI服务? Divakaruni认为,OpenAI API版本更适合那些正在探索选择但没有特定项目实施计划的公司。 就访问而言,OpenAI肯定更进一步,其Playground使个人用户和公司更容易进行实验。 OpenAI API还允许访问最新的实验性模型和扩展API功能的API端点。
另一方面,Azure OpenAI服务目标定位于具有生产用例的用户群,这些用户从OpenAI API“毕业”或需要满足不同的合规性和隐私法规。 两家组织鼓励客户进行实验并验证其用例,然后用OpenAI API进行确定。 如果该平台满足他们的需求,微软鼓励客户留在该平台上,但当他们的生产需求变得更成熟并开始需要更多合规性时,他们应考虑过渡到Azure。
总结
在本章中,您看到了企业如何大规模使用基于GPT-3的产品,以及新的Microsoft Azure OpenAI服务如何为有兴趣成为GPT-3生态系统一部分的企业铺平道路。 我们已经深入探讨了扩展基于GPT-3的产品的细微差别,并分享了大规模企业级产品旅程的一些技巧。 在第6章中,我们将查看围绕OpenAI API和LLM的一些争议和挑战。