使用OpenAI和LangChain介绍ML工程和LLMOps

使用OpenAI和LangChain介绍ML工程和LLMOps' can be condensed to '介绍ML工程和LLMOps使用OpenAI和LangChain

以下文章是基于Andy McMahon的《Python机器学习工程第二版》(Packt,2023年)的摘录。

用LLMs过大生活

截至撰写本文时,GPT4于2023年3月由OpenAI发布,该模型可能是迄今为止开发的最大机器学习模型,据报道拥有一万亿个参数,尽管OpenAI拒绝确认此数字。此后,微软和谷歌宣布在其产品套件中使用类似大型模型的先进聊天功能,并发布了一系列开源软件包和工具包,感觉好像每个人都在努力理解和应用。所有这些解决方案都利用了有史以来最大的神经网络模型之一,即大型语言模型(LLMs)。LLMs是更广泛的基础模型类别的一部分,这些模型不仅涵盖文本应用,还包括视频和音频。作者大致将这些模型分类为大多数组织无法考虑训练甚至托管的规模过大,因此通常会作为第三方服务使用。以安全可靠的方式解决这个集成挑战是现代机器学习工程中的主要挑战之一。由于新的模型和功能似乎每天都在发布,不容有失。让我们开始吧!

理解LLMs

LLM系统的主要重点是对各种基于文本的输入创建人类般的响应。LLMs基于Transformer架构,使这些模型能够并行处理输入,显著减少了训练所需的时间。

LLMs的Transformer架构,就像任何Transformer一样,由一系列编码器和解码器组成,利用自注意力和前馈神经网络。从高层次来看,您可以将编码器视为负责处理输入、将其转换为适当的数值表示,并将其馈送到解码器中,从中可以生成输出。Transformer的魔力来自于使用自注意力的能力,自注意力是一种捕捉句子中单词之间关系的机制。这导致表示这种关系的注意力向量,并且当计算多个这样的向量时,称为“多头注意力”。编码器和解码器都使用自注意力机制来捕捉输入和输出序列的上下文依赖关系。

在LLMs中使用的最受欢迎的基于Transformer的模型之一是谷歌开发的双向编码器表示来自Transformer(BERT)模型。BERT是一个预训练模型,可以针对各种自然语言任务进行微调。另一个受欢迎的架构是由OpenAI创建的生成式预训练Transformer(GPT)。

ChatGPT系统是由OpenAI于2022年11月发布的,当时它采用了第三代GPT模型,一经推出即引起轰动。截至撰写本文时的2023年3月,这些模型已经发展到第四代,非常强大。尽管我在打字的时候,GPT-4只对全球某些用户开放,但它已经引发了关于人工智能未来以及我们是否已经达到人工通用智能(AGI)的激烈讨论。作者不认为我们已经达到,但无论如何,这是一个令人兴奋的时刻!

使LLMs在每个新的业务环境或组织中重新训练成为不可行的是,它们是在庞大数据集上训练的。GPT-3于2020年发布,经过训练的文本标记数近5000亿。在这种情况下,标记是LLMs中用于训练和推理过程的一个小片段,大约是英语中的四个字符。所以这是很多文本!因此,训练这些模型的成本也相应巨大,即使推理的成本也可能非常高。这意味着那些不专注于生产这些模型的组织很可能无法看到规模经济和回报,无法为此规模的投资提供正当的理由。这还没有考虑到需要专业技能、优化基础设施以及获取所有这些数据的需求。这与几年前公共云的出现有很多相似之处,现在组织不再需要在本地基础设施或专业知识上投资太多,而是按照“所使用的”方式付费。最先进的机器学习模型也正在出现同样的情况。这并不意味着较小、更领域特定的模型已经被排除在外。事实上,我认为这将继续是组织可以利用其独特数据集推动与竞争对手的优势和构建更好产品的方式之一。最成功的团队将是那些能够以稳健的方式将这种方法与最大模型的方法相结合的团队。

尺度并不是唯一重要的组成部分。ChatGPT和GPT-4不仅在大量数据上进行了训练,而且还使用了一种称为强化学习与人类反馈(RLHF)的技术进行了微调。在这个过程中,模型被提供一个提示,比如一个对话的问题,并生成一系列潜在的回答。然后将这些回答呈现给人类评估者,评估者通过对回答的质量进行排名等方式提供反馈,这些反馈被用来训练一个奖励模型。然后可以通过类似于近端策略优化(PPO)的技术来微调潜在的语言模型。这其中的细节远远超出了本书的范围,但希望你能对这种非常规的数据科学有一些直觉。因为情况如此,我们必须学习如何将这些工具作为第三方解决方案来使用,并将其视为一个“黑箱”。我们将在下一节中介绍这个问题。

通过API消费LLM

正如前面所讨论的,作为希望与LLM和Foundation Models等进行交互的ML工程师,我们的思维方式的主要改变是,我们不能再假设我们有模型的实体、训练数据或测试数据。相反,我们必须将模型视为一个第三方服务,我们应该调用它来进行消费。幸运的是,有许多工具和技术可以实现这一点。

下一个示例将向您展示如何使用流行的LangChain包构建一个利用LLM的流水线。这个名字来自于要利用LLM的能力,我们经常不得不通过与其他系统和信息来源的调用来链接许多与它们的交互。

首先,我们来看一下调用OpenAI API的基本示例。

1. 安装LangChain和OpenAI的Python绑定:

2. 我们假设用户已经设置了OpenAI账户并拥有API密钥。您可以将其设置为环境变量,也可以使用类似GitHub提供的密钥管理器进行存储。我们将假设密钥可以作为环境变量访问。

3. 现在,在我们的Python脚本或模块中,我们可以使用通过LangChain包访问的OpenAI API定义我们将要调用的模型。这里,我们将使用“gpt-3.5-turbo”模型,它是最先进的GPT-3.5聊天模型:

4. 然后,Langchain通过PromptTemplates来便利地构建使用LLM的流水线,它允许您标准化我们将如何提示和解析模型的响应:

5. 然后,我们可以创建我们的第一个“链”,这是在LangChain中将相关步骤组合在一起的机制。这个第一个链是一个简单的链,它使用一个提示模板和输入来创建一个适当的提示,以便将其发送到LLM API,并返回一个格式化的响应:

您可以运行这个问题并将结果打印到终端作为一个测试:

这将返回:

作为一个AI语言模型,我没有实时信息的访问权限。然而,Andrew McMahon是一位位于英国布里斯托的自由数据科学家和软件工程师。

考虑到我是一位在苏格兰的大型银行工作的ML工程师,您可以看到即使是最复杂的LLM也会出错。这是一个我们称之为幻觉的例子,即LLM给出了一个不正确但似乎合理的答案。这仍然是一个构建基本机制的很好的例子,通过这个机制,我们可以以标准化的方式以编程方式与LLM进行交互。

LangChain还提供了使用链中的一种方法将多个提示组合在一起的能力:

这个一系列问题的响应相当冗长,但这是返回对象的第一个元素:

再次,不完全正确。您已经有了思路!通过一些提示工程和更好的对话设计,这个结果可以变得更好。我会让你自己玩耍并有一些乐趣。

这个对LangChain和LLM的快速介绍只是皮毛,但希望能给你足够的知识来将这些模型的调用融入到您的ML工作流程中。让我们继续讨论LLM作为AI助手在软件开发中成为工作流程的另一种重要方式。

用LLMOps构建未来

鉴于最近对LLMs的兴趣不断增长,人们对将这些模型集成到各种软件系统中的愿望并不缺乏。作为机器学习工程师,这应该立即引发我们的问题:“这在操作上意味着什么?”正如本书中所讨论的那样,运营和开发机器学习系统的结合被称为MLOps。然而,与LLMs一起工作可能会带来自己的有趣挑战,因此,出现了一个新术语LLMOps,为MLOps的这个子领域提供了一些良好的营销。这真的有什么不同吗?我不认为有很大的不同,但应该将其视为MLOps的一个子领域,具有自己的额外挑战。我在这个领域看到的一些主要挑战包括:

  • 更大的基础设施,即使是用于微调:如前所述,这些模型对于典型的组织或团队来说太大了,无法考虑自己进行训练,因此,团队将不得不利用第三方模型,无论是开源还是专有的,并对其进行微调。微调这种规模的模型仍然非常昂贵,因此在构建非常高效的数据摄取、准备和训练流程方面将更加重要。
  • 模型管理不同:当您训练自己的模型时,有效的机器学习工程要求我们定义好的版本控制实践,并存储提供实验和训练运行的渊源的元数据。在模型更常被外部托管的世界中,这可能稍微更难实现,因为我们没有访问培训数据、核心模型构件,甚至可能没有详细的模型架构。版本控制元数据可能会默认为模型的公开可用元数据,例如gpt-4-v1.3和类似的名称。这并不是很多信息,因此您可能需要思考如何丰富这些元数据,例如通过自己的示例运行和测试结果,以了解该模型在某些场景下的行为。这也与下一个点有关。
  • 回滚变得更加具有挑战性:如果您的模型由第三方外部托管,您无法控制该服务的路线图。这意味着如果版本5的模型出现问题,您想回滚到版本4,可能无法选择这个选项。这是与我们在本书中长时间讨论的模型性能漂移不同的一种“漂移”,但它将变得越来越重要。这意味着您应该准备自己的模型,可能远远没有相同级别的功能或规模,作为最后的备选方案,以防出现问题。
  • 模型性能更具挑战性:如前所述,由于基础模型作为外部托管服务提供,您的控制能力不再像以前那样大。这意味着如果您发现您正在使用的模型存在任何问题,无论是漂移还是其他错误,您的操作空间非常有限,您需要考虑刚刚讨论的默认回滚。
  • 应用自己的防护措施至关重要:LLMs会产生幻觉,他们会出错,他们可能会重复训练数据,甚至可能无意冒犯与他们互动的人。所有这些意味着随着这些模型被越来越多的组织采用,将需要开发应用定制防护措施的方法来利用这些模型的系统。例如,如果一个LLM被用于驱动下一代聊天机器人,您可以设想在LLM服务和聊天界面之间,您可以有一个系统层,检查突然的情绪变化和应该模糊处理的重要关键字或数据。该层可以使用更简单的机器学习模型和各种其他技术。在最复杂的情况下,它可以尝试确保聊天机器人不会违反组织建立的道德或其他规范。如果您的组织将气候危机作为重点领域,您可能希望实时筛查对该领域的重要科学发现违背的对话信息,例如。

由于基础模型时代才刚刚开始,随着时间的推移,可能会出现越来越复杂的挑战,让我们作为机器学习工程师保持忙碌。对我来说,这是我们作为一个社区面临的最激动人心的挑战之一:我们如何以一种仍然能够安全、高效和稳定地运行软件的方式利用机器学习社区开发的最复杂和最前沿的能力。您准备好接受这个挑战了吗?让我们深入探讨这些主题的一些细节,首先讨论LLM验证。

验证LLM

生成式AI模型的验证与其他机器学习模型的验证本质上是不同的,看起来更加复杂。其主要原因在于,当您生成内容时,您往往会在结果中创建从未存在过的非常复杂的数据!如果一个LLM在要求帮助总结和分析某个文档时返回一段生成的文本,如何确定答案是否“好”?如果您要求LLM将某些数据重新格式化为表格,如何构建一个合适的度量标准来捕捉它是否正确执行此操作?在生成上下文中,”模型性能”和”漂移”到底意味着什么,我该如何计算它们?其他问题可能更依赖于用例。例如,如果您正在构建信息检索或检索增强生成(参见知识密集型NLP任务的检索增强生成)解决方案,如何评估LLM生成的文本的真实性?

我们还需要考虑如何对LLM生成的输出进行筛选,以防止任何可能导致组织遭受伤害或声誉受损的有偏见或有毒输出。LLM验证的世界是复杂的!

我们能做些什么呢?值得庆幸的是,这一切并不都是在真空中发生的,已经发布了几个基准测试工具和数据集,可以帮助我们的工作。由于这些工具的实际示例还不多,但我们将讨论主要要点,以便您了解现状并紧跟事物的发展。让我们列举一些面向LLM的知名评估框架和数据集:

  • OpenAI Evals:这是一个框架,OpenAI允许众包开发针对LLMs生成的提议文本完成的测试。evals的核心概念是“完成函数协议”,它是一种标准化与LLM交互时返回的字符串测试的机制。该框架可在GitHub上获得。
  • 语言模型整体评估(HELM):这个项目来自斯坦福大学,自称为LLM性能的“活基准”。它为您提供了各种数据集、模型和指标,并显示了这些不同组合的性能。它是一个非常强大的资源,您可以用它来构建自己的测试场景,或者直接使用这些信息来了解使用特定LLM的风险和潜在好处。HELM基准测试可在此处获取。
  • Guardrails AI:这是一个Python包,允许您以与Pydantic相似的方式对LLM输出进行验证,这是一个非常强大的想法!您还可以使用它来构建与LLM的控制流,以处理出现问题的情况,例如,当响应不满足您设定的标准时,您可以使用Guardrails AI重新提示LLM,希望得到不同的响应。要使用Guardrails AI,您需要指定一个可靠的AI标记语言(RAIL)文件,该文件定义了XML样式的提示格式和预期行为。Guardrails AI可在GitHub上获取。

还有更多这样的框架正在不断创建中,但随着越来越多的组织希望将基于LLM的系统从有趣的概念验证推进到实际解决方案,熟悉核心概念和现有的数据集将变得越来越重要。在本章的倒数第二节中,我们将简要讨论在构建LLM应用程序时管理”提示”时遇到的一些具体挑战。

PromptOps

在使用接受文本输入的生成式AI时,我们通常将输入的数据称为”提示”,以捕捉与这些模型一起工作的会话起源和输入需要响应的概念,就像人的提示一样。为简单起见,无论我们向LLM提供何种内容,无论是通过用户界面还是通过API调用,我们都将称其为提示。

与我们通常提供给机器学习模型的数据相比,提示通常是不同的。它们可以非常自由形式,长度各异,并且在大多数情况下表达了我们希望模型采取的行动意图。在其他机器学习建模问题中,我们当然可以输入非结构化的文本数据,但缺少这种意图部分。所有这些都导致我们作为与这些模型合作的机器学习工程师需要考虑一些重要的问题。

首先,提示的塑造很重要。最近,”提示工程”一词在数据社区中变得流行,并指的是在设计提示的内容和格式时需要进行大量思考。这是我们在使用这些模型设计我们的机器学习系统时需要记住的事情。我们应该问自己诸如”我能为我的应用程序或用例标准化提示格式吗?”、”我能否提供适当的额外格式或内容,以获得更好的结果?”以及类似的问题。我将继续称之为提示工程。

其次,提示不是您典型的机器学习输入,跟踪和管理它们是一个新的有趣挑战。这个挑战的复杂性在于相同的提示可能会给不同的模型产生非常不同的输出,甚至在同一模型的不同版本中也是如此。我们应该仔细考虑跟踪提示的来源以及它们生成的输出。我将这个挑战称为提示管理。

最后,我们面临的挑战并不一定是提示所特有的,但如果我们允许系统的用户自己输入提示,这个挑战就变得更加重要了,例如在聊天界面中。在这种情况下,我们需要对输入和输出的数据应用一些筛选和混淆规则,以确保模型没有以某种方式“越狱”,逃避任何防护措施。我们还希望防范可能旨在从这些系统中提取训练数据的对抗性攻击,从而获取个人身份识别或其他关键信息,这些信息我们不希望分享。当您开始探索这个充满挑战的新LLMOps世界时,牢记这些与提示相关的挑战将是很重要的。

接受挑战吧!

希望前面的段落已经让您相信,在LLMOps领域有一些独特的探索领域,并且这个领域非常适合创新。这些观点只是触及到了这个丰富新世界的表面,但我个人认为它们强调了我们目前还没有答案。您准备好帮助构建未来了吗?