[机器翻译]So you want to build your own open source ChatGPT-style chatbot

138 阅读24分钟

莫斯拉哈克KS

**

**Hacks on YouTube **@mozhacks on Twitter **Hacks RSS Feed 下载火狐浏览器

所以你想建立自己的开源 ChatGPT 风格的聊天机器人......

斯蒂芬·胡德报道

发表于 27月 2023, <> 在人工智能,精选文章莫斯拉 

(扩展自 2023 年 DWeb 营地演讲

人工智能很可能被证明是多年来最具影响力和颠覆性的技术之一。这种影响不是理论上的:人工智能已经在以实质性的方式影响着真实的人,它已经改变了我们所熟悉和喜爱的网络。认识到潜在的利益和伤害,Mozilla致力于可信赖AI的原则。对我们来说,“可信赖”是指人工智能系统,这些系统对他们使用的数据和他们做出的决策是透明的,尊重用户隐私,优先考虑用户代理和安全,并努力最大限度地减少偏见和促进公平。

现状

目前,大多数人体验最新人工智能技术的主要方式是通过生成式人工智能聊天机器人。这些工具正在爆炸式地流行,因为它们为用户提供了很多价值,但占主导地位的产品(如 ChatGPT 和 Bard)都是由强大的科技公司运营的,通常使用专有技术。

在 Mozilla,我们相信开源的协作力量可以赋予用户权力,提高透明度,并且——也许最重要的是——确保技术不会仅仅根据一小群公司的世界观和财务动机发展。幸运的是,最近在开源人工智能领域取得了快速而令人兴奋的进展,特别是在为这些聊天机器人提供动力的大型语言模型(LLM)以及支持它们使用的工具方面。我们希望理解、支持并为这些努力做出贡献,因为我们相信它们提供了帮助确保出现的人工智能系统真正值得信赖的最佳方法之一。

挖掘

考虑到这一目标,Mozilla 创新团队的一个小团队最近在我们位于旧金山的总部举办了一场黑客马拉松。我们的目标:构建一个 Mozilla 内部聊天机器人原型,一个...

  • 完全独立,完全在 Mozilla 的云基础架构上运行,不依赖于第三方 API 或服务。
  • 使用免费的开源大型语言模型和工具构建。
  • 充满了Mozilla的信念,从值得信赖的AI到Mozilla宣言所支持的原则。

作为奖励,我们设定了一个扩展目标,即整合一定数量的内部 Mozilla 特定知识,以便聊天机器人可以回答员工有关内部事务的问题。

承担这个项目的Mozilla团队——Josh WhitingRupert Parry我——带来了不同水平的机器学习知识,但我们都没有构建过全栈AI聊天机器人。因此,这个项目的另一个目标就是卷起袖子学习!

这篇文章是关于分享这种学习的,希望它能帮助或激励你自己对这项技术的探索。组装一个开源的LLM驱动的聊天机器人是一项复杂的任务,需要在技术堆栈的多个层上进行许多决策。在这篇文章中,我将带您了解该堆栈的每一层,我们遇到的挑战,以及我们为满足自己的特定需求和截止日期而做出的决定。当然是YMMV。

准备好了吗?让我们开始,从堆栈的底部开始...

该图描述了构建开源聊天机器人所需的七个级别的功能和决策。我们聊天机器人探索的视觉表示。

决定出租地点和方式

我们面临的第一个问题是在哪里运行我们的应用程序。不乏大大小小的公司都渴望托管你的机器学习应用。它们有各种形状、大小、抽象级别和价格点。

对于许多人来说,这些服务物有所值。机器学习操作(又名“MLOps”)是一项不断发展的学科,这是有原因的:部署和管理这些应用很困难。它需要许多开发人员和运维人员尚不具备的特定知识和技能。失败的代价很高:配置不当的 AI 应用程序可能速度慢、成本高昂、提供质量差的体验,或者以上所有。

我们做了什么:我们这个为期一周的项目的明确目标是构建一个对 Mozilla 安全且完全私密的聊天机器人,没有外部各方能够监听、收集用户数据或以其他方式窥视其使用情况。我们还想尽可能多地了解开源人工智能技术的状态。因此,我们选择放弃任何第三方AI SaaS托管解决方案,而是在Mozilla现有的Google Cloud Platform(GCP)帐户中建立自己的虚拟服务器。在这样做的过程中,我们有效地致力于自己做 MLOps。但我们也可以充满信心地向前迈进,我们的系统将是私有的,完全在我们的控制之下。

选择运行时环境

使用 LLM 为应用程序提供支持需要为您的模型提供运行时引擎。有多种方法可以实际运行LLM,但由于时间限制,我们没有接近调查该项目中的所有方法。相反,我们专注于两个特定的开源解决方案:llama.cpp和Hugging Face生态系统。

对于那些不知道的人来说,Hugging Face是机器学习领域一家有影响力的初创公司,在普及机器学习的转换器架构方面发挥了重要作用。Hugging Face为构建机器学习应用程序提供了一个完整的平台,包括庞大的模型库以及广泛的教程和文档。它们还提供用于文本推理的托管 API(这是 LLM 驱动的聊天机器人在幕后所做的事情的正式名称)。

因为我们想避免依赖其他人的托管软件,所以我们选择尝试Hugging Face托管API的开源版本,该API可以在GitHub上的文本生成推理项目中找到。文本生成推理非常棒,因为就像Hugging Face自己的变形金刚库一样,它可以支持各种各样的模型和模型架构(下一节将详细介绍)。它还针对支持多个用户进行了优化,并且可通过 Docker 进行部署。

不幸的是,这是我们第一次开始遇到即时学习 MLOps 的有趣挑战的地方。我们在启动和运行服务器时遇到了很多麻烦。这在一定程度上是一个环境问题:由于Hugging Face的工具是GPU加速的,我们的服务器需要操作系统,硬件和驱动程序的特定组合。它特别需要安装NVIDIA的CUDA工具包(CUDA是GPU加速机器学习应用程序的主要API)。在最终让模型上线之前,我们为此苦苦挣扎了大半天,但即便如此,输出速度也比预期的要慢,结果也非常糟糕——这两个迹象都表明我们的堆栈中仍然存在一些问题。

现在,我不是在给这个项目投掷阴影。远非如此!我们喜欢拥抱脸,并且在其堆栈上进行构建提供了许多优势。我敢肯定,如果我们有更多的时间和/或实践经验,我们就会让事情顺利进行。但在这种情况下,时间是我们没有的奢侈品。我们故意缩短项目期限意味着我们不能在配置和部署问题上陷入太深的泥潭。我们需要让一些东西快速发挥作用,这样我们才能继续前进并继续学习。

正是在这一点上,我们将注意力转移到了llama.cpp,一个由Georgi Gerganov发起的开源项目。llama.cpp 完成了一个相当巧妙的技巧:它可以轻松地在消费级硬件上运行某一类 LLM,依靠 CPU 而不是需要高端 GPU。事实证明,现代CPU(尤其是像M1和M2这样的苹果硅CPU)可以做到这一点,至少对于最新一代相对较小的开源型号来说是这样。

LLAMA.cpp是一个了不起的项目,也是开源释放创造力和创新力量的一个很好的例子。我已经在我自己的个人AI实验中使用它,甚至写了一篇博客文章,展示了任何人都可以使用它在自己的MacBook上运行高质量的模型。因此,我们接下来尝试似乎是一件很自然的事情。

虽然 llama 本身.cpp只是一个命令行可执行文件——“cpp”代表“C++”——但它可以被 docker 化并像服务一样运行。至关重要的是,一组Python绑定可用,它们公开了OpenAI API规范的实现。这一切意味着什么?嗯,这意味着骆驼.cpp可以很容易地插入你自己的LLM来代替ChatGPT。这很重要,因为OpenAI的API正在被机器学习开发人员迅速而广泛地采用。模拟该API是像llama.cpp这样的开源产品的一个聪明的Judo。

我们做了什么:有了这些工具,我们能够非常快速地启动并运行骆驼.cpp。我们无需担心 CUDA 工具包版本和配置昂贵的托管 GPU,而是能够启动一个简单的 AMD 驱动的多核 CPU 虚拟服务器,然后......去。

选择您的型号

在这个叙述中,你会注意到的一个新兴趋势是,你在构建聊天机器人时做出的每一个决定都会与其他每一个决定相互作用。没有简单的选择,也没有免费的午餐。你做出的决定回来困扰你。

在我们的案例中,选择与美洲驼一起运行.cpp引入了一个重要后果:我们现在可用的模型列表受到限制。

快速历史课:2022 年底,Facebook 宣布了自己的大型语言模型 LLaMA。为了过度概括,LLaMA由两部分组成:模型数据本身和构建模型的体系结构。Facebook开源了LLaMA架构,但他们没有开源模型数据 相反,希望使用这些数据的人需要申请许可,并且他们对数据的使用仅限于非商业目的。

即便如此,LLaMA立即推动了寒武纪模型创新的爆炸式增长。斯坦福大学发布了Alpaca,这是他们通过称为微调的过程在LLaMA之上构建而成的。不久之后,LMSYS发布了Vicuna,可以说是一个更令人印象深刻的模型。还有几十个,如果不是几百个。

那么细则是什么?这些模型都是使用Facebook的模型数据开发的——用机器学习的话来说,就是“权重”。正因为如此,他们继承了Facebook对这些原始权重施加的法律限制。这意味着这些原本优秀的模型不能用于商业目的。因此,可悲的是,我们不得不将他们从我们的名单中删除。

但有一个好消息:即使LLaMA权重不是真正开放的,底层架构也是适当的开源代码。这使得构建利用LLaMA架构但不依赖于LLaMA权重的新模型成为可能。多个小组已经做到了这一点,从头开始训练自己的模型并将它们作为开源发布(通过MIT,Apache 2.0或Creative Commons许可证)。最近的一些例子包括OpenLLaMA,以及几天前的LLaMA 2,这是Facebook自己的LLaMA模型的全新版本,但这次明确授权用于商业用途(尽管其许多其他法律负担引发了它是否真正开源的严重问题)。

你好,后果

还记得骆驼.cpp吗?这个名字并非偶然。llama.cpp运行基于LLaMA架构的模型。这意味着我们能够在聊天机器人项目中利用上述模型。但这也意味着我们只能使用基于LLaMA架构的模型。

你看,还有很多其他的模型架构,还有更多的模型构建在它们之上。该列表太长,无法在此一一列举,但一些主要示例包括MPTFalconOpen Assistant。这些模型使用与LLaMA不同的架构,因此(目前)不能在llama.cpp上运行。这意味着我们不能在聊天机器人中使用它们,无论它们有多好。

模型、偏见、安全和您

现在,您可能已经注意到,到目前为止,我只是从许可和兼容性的角度谈论模型选择。这里还有另一组注意事项,它们与模型本身的质量有关。

模型是Mozilla对AI领域感兴趣的焦点之一。这是因为你对模型的选择目前是你最终的人工智能“可信度”的最大决定因素。大型语言模型在大量数据上进行训练,然后使用其他输入进一步微调,以调整其行为和输出以服务于特定用途。这些步骤中使用的数据代表了固有的策展选择,而这种选择带有大量偏见

根据训练模型的源,它可以表现出截然不同的特征。众所周知,有些模型容易产生幻觉(机器学习术语,指模型从整块布中发明的本质上是荒谬的反应),但更阴险的是模型可以选择或拒绝回答用户问题的多种方式。这些响应反映了模型本身的偏差。它们可能导致共享有毒内容、错误信息以及危险或有害信息。模型可能会对概念或人群表现出偏见。当然,房间里的大象是,今天网上提供的绝大多数培训材料都是英语的,这对谁可以使用这些工具以及他们将遇到的各种世界观都有可预见的影响。

虽然有很多资源可以评估LLM的原始力量和“质量”(一个流行的例子是Hugging Face的Open LLM排行榜),但在来源和偏见方面评估和比较模型仍然具有挑战性。在这个领域,Mozilla认为开源模型有潜力大放异彩,因为它们可以提供比商业产品更大的透明度。

我们做了什么:在将自己限制在运行在LLaMA架构上的商业上可用的开放模型之后,我们对几个模型进行了手动评估。该评估包括向每个模型提出一系列不同的问题,以比较它们对毒性、偏见、错误信息和危险内容的抵抗力。最终,我们暂时选择了Facebook的新LLaMA 2模型。我们认识到我们的限时方法可能存在缺陷,并且我们对这个模型的许可条款以及它们对开源模型可能代表的东西并不完全满意,所以不要认为这是一种认可。我们希望在未来重新评估我们的模型选择,因为我们继续学习和发展我们的思维。

使用嵌入和矢量搜索来扩展聊天机器人的知识

正如您可能还记得这篇文章的开头,我们为自己设定了一个延伸目标,即将一些内部 Mozilla 特定知识集成到我们的聊天机器人中。这个想法只是使用少量的内部Mozilla数据来构建概念验证 - 员工可以访问自己的事实,但LLM通常不会。

实现此目标的一种流行方法是使用带有嵌入的向量搜索。这是一种使自定义外部文档可供聊天机器人使用的技术,以便它可以利用它们来制定答案。这种技术既强大又有用,在未来的几个月和几年里,这个领域可能会有很多创新和进步。已经有各种开源和商业工具和服务可用于支持嵌入和矢量搜索。

在最简单的形式中,它通常像这样工作:

  • 您希望提供的数据必须从通常存储的任何位置检索,并使用称为嵌入模型的单独模型转换为嵌入。这些嵌入在聊天机器人可以访问它的地方(称为矢量数据库)中索引。
  • 当用户提出问题时,聊天机器人会在矢量数据库中搜索可能与用户查询相关的任何内容。
  • 然后,返回的相关内容将传递到主模型的上下文窗口(下文将详细介绍),并用于制定响应。

我们做了什么:因为我们希望保留对所有数据的完全控制,所以我们拒绝使用任何第三方嵌入服务或矢量数据库。相反,我们用Python编写了一个手动解决方案,它利用了all-mpnet-base-v2嵌入模型,SentenceTransformers嵌入库,LangChain(我们将在下面详细讨论)和FAISS向量数据库。我们只从公司内部维基中提供了少数文档,因此范围有限。但作为概念验证,它做到了。

快速工程的重要性

如果您一直在关注聊天机器人空间,您可能听说过“提示工程”一词。目前尚不清楚随着人工智能技术的发展,这是否会成为一门持久的学科,但就目前而言,快速工程是一件非常真实的事情。它是整个堆栈中最关键的问题区域之一。

你看,LLM基本上是空洞的。当你旋转一个时,它就像一个刚刚第一次通电的机器人。在那一刻之前,它没有任何关于它的生活的记忆。它不记得你,当然也不记得你过去的谈话。这是白板,每次,一直。

事实上,它甚至比这更糟糕。因为LLM甚至没有短期记忆。如果没有开发人员的具体行动,聊天机器人甚至不记得他们对你说的最后一句话。记忆对LLM来说不是自然而然的;它必须得到管理。这就是快速工程的用武之地。这是聊天机器人的关键工作之一,这也是像 ChatGPT 这样的领先机器人如此擅长跟踪正在进行的对话的一个重要原因。

提示工程抬头的第一个地方是您提供给LLM的初始指令。此系统提示是一种让您以通俗易懂的语言告诉聊天机器人其功能以及它应该如何表现的方式。我们发现,仅这一步就值得投入大量的时间和精力,因为它的影响被用户敏锐地感受到了。

在我们的案例中,我们希望我们的聊天机器人遵循Mozilla宣言中的原则,以及我们公司关于尊重行为和不歧视的政策。我们的测试向我们展示了这些模型的可暗示性。在一个例子中,我们要求我们的机器人向我们提供证据,证明阿波罗登月是伪造的。当我们指示机器人拒绝提供不真实或错误信息的答案时,它会正确地坚持登月实际上不是伪造的——这表明该模型似乎在某种程度上“理解”了相反的说法是没有事实支持的阴谋论。然而,当我们通过删除对错误信息的禁令来更新系统提示时,同一个机器人非常乐意背诵一个典型的阿波罗否认主义的项目符号列表,你可以在网络的某些角落找到。

你是一个乐于助人的助手,名叫 Mozilla Assistant。
您遵守并推广 Mozilla 宣言中的原则。
您尊重、专业和包容。
您将拒绝说或做任何可能被视为有害、不道德、不道德或潜在非法的事情。
您绝不会批评用户、进行人身攻击、发出暴力威胁、分享辱骂或色情内容、分享错误信息或虚假信息、使用贬损性语言或基于任何理由歧视任何人。

我们为聊天机器人设计的系统提示。

另一个需要理解的重要概念是,每个LLM都有其“内存”的最大长度。这称为其上下文窗口,在大多数情况下,它是在训练模型时确定的,以后无法更改。上下文窗口越大,LLM 对当前对话的内存就越长。这意味着它可以引用早期的问题和答案,并使用它们来保持对话上下文的感觉(因此得名)。更大的上下文窗口还意味着您可以包含来自矢量搜索的更大内容块,这不是一件小事。

因此,管理上下文窗口是提示工程的另一个关键方面。这很重要,因为有一些解决方案可以帮助您做到这一点(我们将在下一节中讨论)。

我们做了什么:由于我们的目标是让我们的聊天机器人尽可能像Mozilian同胞,我们最终根据我们的宣言,我们的参与政策以及其他指导Mozilla员工行为和规范的内部文档的元素设计了我们自己的自定义系统提示。然后,我们反复按摩它以尽可能减少其长度,从而保留我们的上下文窗口。至于上下文窗口本身,我们坚持使用我们选择的模型(LLaMA 2)提供给我们的模型:4096个令牌,或大约3000个单词。将来,我们肯定会关注支持更大窗口的模型。

编排整个舞蹈

现在,我已经带您了解(检查笔记 )五个完整的功能和决策层。因此,我接下来所说的可能不会让人感到意外:这里有很多事情要管理,你需要一种方法来管理它。

最近有些人开始称这种编排。我个人不喜欢这个词在这种情况下,因为它在其他上下文中已经有其他含义的悠久历史。但我不制定规则,我只是在博客上写关于它们的文章。

目前LLM领域领先的编排工具是LangChain,这是一个奇迹。它有一个一英里长的功能列表,它提供了惊人的功能和灵活性,它使您能够构建各种大小和复杂程度的 AI 应用程序。但随着这种力量而来的是相当多的复杂性。学习LangChain不一定是一件容易的事,更不用说利用它的全部力量了。你也许能猜到这是怎么回事...

我们做了什么:我们只很少使用LangChain来支持我们的嵌入和矢量搜索解决方案。否则,我们最终会转向清晰。我们的项目太短,太受限制,我们无法承诺使用这个特定的工具。相反,我们能够用自己编写的相对少量的Python代码来满足我们的大部分需求。这段代码“编排”了我已经讨论过的层上发生的所有事情,从注入代理提示符到管理上下文窗口,到嵌入私有内容,再到将其全部提供给LLM并返回响应。也就是说,如果有更多的时间,我们很可能不会手动完成这一切,尽管这听起来很矛盾。

处理用户界面

最后但并非最不重要的一点是,我们已经到达了聊天机器人蛋糕的顶层:用户界面。

OpenAI在推出ChatGPT时为聊天机器人UI设定了很高的标准。虽然这些接口表面上看起来很简单,但这更像是对良好设计的致敬,而不是简单问题空间的证据。聊天机器人 UI 需要呈现正在进行的对话,跟踪历史线程,管理以通常不一致的速度生成输出的后端,并处理许多其他可能性。

令人高兴的是,有几个开源聊天机器人UI可供选择。其中最受欢迎的是聊天机器人-ui。该项目实现了OpenAI API,因此它可以作为ChatGPT UI的直接替代品(同时仍然在幕后使用ChatGPT模型)。这也使得使用聊天机器人-ui作为您自己的 **LLM系统的前端变得相当简单。

我们做了什么:通常我们会使用chatbot-ui或类似的项目,这可能是你应该做的。然而,我们碰巧已经有了自己的内部(尚未发布)聊天机器人代码,称为“Companion”,Rupert 编写了这些代码来支持他的其他 AI 实验。由于我们碰巧手头有此代码及其作者,因此我们选择利用这种情况。通过使用 Companion 作为我们的 UI,我们能够快速迭代并试验我们的 UI,而不是其他方式。

结语

我很高兴地报告,在我们的黑客马拉松结束时,我们实现了我们的目标。我们提供了一个供内部 Mozilla 使用的聊天机器人原型,它完全托管在 Mozilla 中,可以安全、私密地使用,并尽最大努力在其行为中反映 Mozilla 的价值观。为了实现这一目标,我们不得不做出一些艰难的决定并接受一些妥协。但在每一步,我们都在学习。

A diagram depicting the specific path that we took through the chatbot "stack."我们为原型所走的道路。

 

这种学习超越了技术本身。我们了解到:

  • 开源聊天机器人仍然是一个不断发展的领域。仍然有太多的决定要做,没有足够的清晰文档,以及太多出错的方式。
  • 根据原始性能以外的标准评估和选择模型太难了。这意味着很难做出正确的选择来构建值得信赖的人工智能应用程序。
  • 有效的提示工程对于聊天机器人的成功至关重要,至少目前是这样。

展望未来的道路,Mozilla 有兴趣帮助解决这些挑战中的每一个。首先,我们已经开始研究如何让开发人员更容易加入开源机器学习生态系统。我们也希望在黑客马拉松工作的基础上,为开源社区做出有意义的贡献。请继续关注有关此方面和其他方面的更多新闻!

随着开源LLM现在广泛可用,并且面临如此多的风险,我们认为创造更美好未来的最佳方式是我们所有人在塑造它方面发挥集体和积极的作用。我希望这篇博文能帮助您更好地了解聊天机器人的世界,并鼓励您卷起袖子加入我们的工作台。

关于斯蒂芬·胡德

Stephen在Mozilla的创新团队工作,他目前关注的领域是人工智能和去中心化的社交媒体。他之前曾管理社交书签先驱 del.icio.us;共同创立了Storium,Blockboard和FairSpin;并参与了雅虎搜索和BEA WebLogic的工作。

斯蒂芬胡德的更多文章...