《普罗米修斯》中的「工程师」是「异形」LLM创造者吗

大家好，欢迎来到IT知识分享网。

电影《普罗米修斯》中的「工程师」是「异形」创造者吗?

透过《普罗米修斯》电影,在《异形》系列的世界观中,有个创造「人类」和「异形」,绰号被称为「工程师」的种族,在《异形》电影第一集的人们还叫他们为「太空骑师」,也有人称他们为Mala’kaks。我这里可以直接说他就是LLM工程师。(请原谅我这么形容工程师)

所以「工程师」可能是「异形」的创作者,但也有可能只是将「异形」弄成自己兵器的「改良者」。(有点言过其实?)

以下文长慎入。因为这与我要解释为什么需要有llamalife这样的工具有关。

评估机器生成文本的质量一直是自然语言处理(NLP)领域的长期挑战,在大型语言模型(LLM)时代更显得至关重要。我们需要深入了解LLM的特性和行为,才能更好地应用和改进它们。过去,人工评估一直是主要方法,因为人类能够可靠地评估文本中的细微差别和主观方面。在许多情况下,人类可以自然地辨别出最重要的评估因素,例如简洁性、创造力、语气和文化敏感度。相比之下,传统的自动评估指标(如BLEU、ROUGE)无法捕捉到人工评估的深度和精细度。

最近,使用大型语言模型(如GPT-4)作为评估工具受到了广泛关注,因为它有可能达到与人工评估相当的水平。初步研究表明,如果提示得当,LLM可以模仿人类评估的精细程度。然而,尽管使用专有LLM作为评估工具的优点是显而易见的,但也存在一些关键缺点:

1. 封闭源代码:专有LLM的内部运作没有向更广泛的学术界披露,缺乏透明度,阻碍了集体学术努力来改进或提升其评估能力。此外,这将学术界的核心原则──公平评估,置于营利实体的控制之下,引发了中立性和自主性的担忧。  
2. 无法控制版本:专有模型经常进行版本更新,但用户无法掌控。这带来了再现性挑战。再现性是科学探究的基石,版本变化导致的任何不一致都可能破坏依赖特定模型版本的研究发现的稳健性,尤其是在评估领域。
3. 高昂成本:LLM API的财务约束并非无足轻重。例如,在1000个评估实例上使用GPT-4评估四种大小(从7B到65B)的四种LLM变体,成本可能超过2000美元。这种规模的成本对学术机构或预算有限的研究人员来说可能是难以承受的。  

尽管有这些局限性,专有的LLM(如GPT-4)能够根据定制的评分规则来评估分数。具体而言,目前的资源局限于通用的、单一维度的评估指标,要么过于特定领域/任务(例如EM、Rouge),要么过于粗糙(例如helpfulness/harmlessness)。例如,AlpacaFarm的提示给出了偏好的单一定义,要求模型选择普遍偏好的模型响应。然而,响应偏好会因具体应用和价值观而有所不同。在现实世界中,用户可能对定制的评分规则更感兴趣,例如「哪种LLM生成的响应更有趣、幽默」或「哪种LLM在回答时特别注重文化敏感性」。然而,在我们的初步实验中,我们发现即使是最大的开源LLM(70B)与专有LLM相比,也不足以根据定制的评分规则进行评估。  

为了解决这些问题,KAIST AI, NAVER AI Lab,  NAVER Cloud,  华盛顿大学, MIT共同提出了Prometheus,一个13B参数的语言模型,旨在引入GPT-4的细粒度评估能力,同时保持开源、可重现和低成本。  

https://arxiv.org/pdf/2310.08491.pdf

这篇文章探讨了如何在没有昂贵GPU的情况下,利用各种开源软件组件来进行「LLM as Judge」的评估。在当前快速发展的AI领域中,成本和评估往往不像新模型的发表那样受到关注,但它们对开发者和企业应用AI系统至关重要。众所周知,预训练LLM的成本极高;而像OpenAI这样封闭源代码的LLM使用起来也很昂贵。

评估不仅对了解模型的性能表现至关重要,也有助于确定哪种模型最适合特定场景。当LLM被用来评估其他模型时(即所谓的LLM as Judge),评估本身的成本也可能很高。虽然推断优化技术也适用于LLM Judge,但似乎没有多少人对此感兴趣。  

本文作者检视了几个软件组件如何组合在一起,实现了无需昂贵GPU的LLM as Judge评估。这些组件在设计时就强调了用户控制、开源特性和互通性。

其中包括了用于LLM as Judge评估的开源模型Prometheus、作者所在的mzai团队开发并开源的lm-buddy工具(用于扩展微调和评估任务)以及Mozilla创新项目llamafile(将LLM打包成单一可携带文件)。作者展示了这些组件如何协同运作,在相对便宜的硬件上评估LLM,以及他们如何衡量评估模型本身的性能来做出明智的选择。  

作者特别欣赏Firefox的一个功能:在网址栏输入「moz://a」,就会自动跳转到Mozilla的宣言。Mozilla诞生自开源理念,其宣言谈到了对AI算法的控制权和用户体验的原则。在目前由封闭的AI即服务平台主导的市场中,这一点格外重要。

Mozilla的宣言引起了作者的共鸣,让他重新审视这些原则在日益被AI算法影响的现代网络中的意义。如果将「互联网」替换为「AI算法/框架」,Mozilla宣言中的原则仍然非常贴切。举例来说,可以解读为:  

– 个人应该能主导AI算法,塑造自己的使用体验  
– AI框架的性能取决于互通性、创新力和去中心化的参与
– 自由开源软件能推动AI成为公共资源

若专注在LLM这个AI的子领域,就能看出这些原则在目前由封闭、中心化AI即服务平台主导的市场中有多么重要。事实上,我们已经看到更开放的替代方案如雨后春笋般涌现。  

尽管业界可能还未形成对开源AI的共识,但新模型持续以开源许可的方式发布在HuggingFace上。它们附上了预训练的权重,可以直接使用或进行微调。有时也会发表论文,详述模型训练和使用的数据。但考虑到研究和再现性而分享训练代码、检查点和训练数据的模型非常少。这少数的例子包括BLOOM、Pythia系列、TinyLlama和Olmo。

在企业应用方面,也出现了类似的趋势,企业倾向选用小型、开放、专门的模型,而非大型封闭的模型。Sarah Wang和Shangda Xu的报告指出,成本只是企业做出这种选择的原因之一,且不是最重要的。其他原因包括控制力(企业既要确保数据安全,也要能理解模型的行为)和定制化能力(针对特定用例微调模型)。  

关于微调,Predibase工程师在最近的LoRA Bake Off简报中展示,小型开源微调模型在特定任务上的表现可以超越GPT-4。虽然理论上GPT-4也能微调,但OpenPipe等新创公司能筹得资金,正是因为企业需要控制力和定制化,要「以自己的微调模型取代GPT-4」。  

当然,要取代一个模型,光有互通性还不够,我们需要评估模型,比较它们的性能,才能选出最适合的那一个。  

作者在mzai从事评估任务时(包括NeurIPS LLM Efficiency Challenge和内部项目),直接体验到离线和线上模型性能(或用Context.ai指南中的说法:模型性能和产品性能)经常有重大差异,前者常无法预测后者。   

离线评估是在模型上进行,使用公认可预测模型特定任务表现的学术基准和指标。线上评估则是针对基于LLM的产品,通常以人工方式在定制化数据集上进行,目的是评估回应质量,包括幻觉程度、品牌语调契合度、面对对抗性输入的反应等更符合产品本身的指标。

这种「离线-线上落差」在其他领域也很常见。有趣的是,它在社交网络的推荐系统中尤其严重。

为了缩小这个落差,「LLM as Judge」的方法应运而生。它利用另一个LLM来评估你的LLM应用的回应。假设经过适当训练,它们比离线评估更能贴近线上性能,但成本又比人工线上评估低。 

和其他基于LLM的应用一样,这方面也有多种仰赖GPT-4的工具。比方说,Anyscale的Goku Mohandas和Philipp Moritz撰写的这篇文章,记录了一个作者很欣赏的GPT-4评估流程。作者之所以喜欢,是因为它有条不紊地分解每个步骤,附上了参考代码,并有详尽的结果分析。

值得庆幸的是,业界也陆续推出了依赖开源模型、性能媲美「GPT-4 as Judge」、但价格只是零头的替代方案。Prometheus和Ragas就是两个例子,可分别用于评估基于LLM和基于检索增强生成的系统。本文将聚焦在前者。

Prometheus是个完全开源的LLM(在HuggingFace以Apache 2.0许可发布),作为长篇内容的评估者,其能力与GPT-4不相上下。它能依照用户提供的评分规则,评估任何给定的长篇文字。实验显示,它与人类评估者的皮尔森相关系数高达0.897。介绍Prometheus的论文已被NeurIPS 2023的Instruction Workshop所接受,而且已有后续研究瞄准视觉-语言模型。

作者以一张图高度概括了Prometheus评分的运作方式。实务上,喂给Prometheus的每个提示(prompt)都由四部分组成:
1. 要评估模型所接收的指令(instruction) 
2. 该模型的回应
3. 一个得分最高的参考答案  
4. 自定义的评分规则,描述回答指令所需的主要方面

作者以方块展示了一个来自Prometheus项目中mt_bench数据集的例子。这个数据集利用了MT Bench Human Judgements数据,后者收集了六个模型针对一系列开放式问题所生成的回答,并由人类专家评分。

当Prometheus收到这样的提示,它的回应会包含针对所提供回答的评估意见(以自然语言表达),以及一个符合评分规则范围的数字分数。 

Prometheus的代码、论文和训练数据都可以在GitHub获得。安装必要的依赖库,在run.py中填入提示模板后,就可以从命令行执行示例评估。此外,项目也提供了完整的基准测试脚本,可通过TGI调用模型服务来执行。

值得注意的是,Prometheus是Llama-2-Chat-13B模型的微调版本,因此非常占用内存:它需要GPU才能运作(原版模型需要超过70GB RAM的高端GPU),这是在评估模型所需的硬件之外,还得额外考虑的成本。为了克服这个限制,作者展示了如何执行此模型的量化版本,并评估它在与原版模型输出的相关性方面的性能。

在NeurIPS LLM Efficiency Challenge期间,作者体认到拥有简单且可扩展的LLM微调和评估系统至关重要。挑战预设提供的工具(微调用LitGPT,评估用HELM)可满足个别提交的需求。然而,作者同时微调和评估多个模型的经验,凸显了一些可以改进和通用化的机会。  

执行的任务流程
– 提供实验跟踪功能,让同个实验中的不同任务能共享成果和设置参数,并通过记录追溯成果的来源  
– 让任务规格保持简单,方便用户建立新规格
– 让不同组件通过开放或事实标准互通信息

LM Buddy是作者在mzai内部打造,并已开源到GitHub的框架,就是为了提供以上这些功能。在为开发者提供平台,去构建专用且值得信赖的AI代理的路上,这是一个核心组件,作者决定及早分享、公开开发。它目前提供了利用抽象化任务来微调和评估LLM的能力。

虽然还在早期阶段,该函数库已具备一些有用的特色:
– 基于命令行界面和YAML配置文件,提供简单的任务界面
– 通过Weights & Biases进行输入/输出成果的跟踪  
– 能在本地执行任务,也能利用Ray轻松扩展到远程集群

这个包目前提供两种任务类型:  
1. 微调任务:利用HuggingFace的模型和训练实现,以及Ray Train来扩展运算
2. 评估任务:可用Ray来扩展,目前依赖lm-evaluation-harness进行离线评估,以及Prometheus和Ragas进行LLM as Judge评估 

当需要进行推理时,无论是要评估的模型或是作为LLM Judge,作者都使用vLLM提供模型服务,并确保他们使用和开发的函数库都支持OpenAI API。

作为LM Buddy任务的Prometheus评估,会读取一个包含要评估提示的输入数据集,将那些提示传送给通过vLLM提供服务的LLM Judge,输出的是另一个版本的数据集,内容增加了Prometheus的意见和分数。使用原版Prometheus模型时,作者会为它分配一个GPU,然后从(可能很多台)只有CPU的机器执行评估任务。

在LM Buddy上执行Prometheus评估的细节和示例可以在教程中找到,内容包括:  
– 准备输入数据集(或使用Prometheus项目提供的数据集之一)  
– 通过OpenAI兼容的API提供Prometheus服务
– 从示例开始,准备配置文件
– 执行评估命令

虽然这在作者内部项目运作良好,但他发现仍要求用户(1)专门配一张GPU来做评估,(2)自己设置并部署Prometheus模型服务。有没有办法让终端用户做起来更简单呢?

llamafile是Mozilla创新项目的倡议,旨在「将端到端LLM聊天机器人的所有复杂性,压缩到单一个可在六种操作系统上执行的文件中」。它利用了两个开源项目:llama.cpp专注于在消费级硬件上执行LLM,Cosmopolitan则是将C语言程序编译成可在多种操作系统上执行的通用可执行文件。虽然Cosmopolitan和llama.cpp已经问世一段时间,但它们绝佳地展现了「整体大于部分总和」。  

llamafile让我们从单一文件在笔记本电脑上执行模型:通过简单的Flask中间层代理llama.cpp自己的服务器,它可以通过OpenAI兼容的API访问。而且多亏了Justine Tunney最近为llamafile改进的矩阵乘法核心,提示处理速度大幅提升,表现优于单独使用llama.cpp和ollama。

这对作者的意义是,(1)可以无缝地将vLLM提供的Prometheus服务替换为llamafile版本,(2)它可以在各式各样的硬件设置上执行。

llamafile的GitHub项目已经提供了多种模型可供下载,而HuggingFace最近也开始正式支持llamafile格式的模型。在作者做实验之前,还没有llamafile格式的Prometheus模型,所以他必须自己构建。步骤大致分为(1)编译llamafile、(2)下载GGUF格式的Prometheus模型、(3)把所有东西打包在一起。

作者提供了详细的指令说明如何构建Prometheus的llamafile。一旦执行了Prometheus的llamafile,它会将模型加载到内存并打开一个包含聊天UI的浏览器标签页。你可以开始聊天,测试一切运作正常(毕竟Prometheus模型就是个微调版的Llama)。

由于作者的lm-buddy任务要求通过OpenAI兼容的API提供Prometheus服务,我们可以执行几个命令让llamafile兼容此API。这会启动一个在本地监听指定URL的服务器。现在你只需将prometheus.inference.url设置为此URL,就能使用Prometheus的llamafile版本进行评估了。  

接着作者分享了一些实验结果。首先是量化对质量的影响。和TheBloke在HuggingFace上发布的其他GGUF格式模型一样,他们的Prometheus页面有个Provided files区块,提供了根据量化程度而有所不同的模型变体。

量化是一种通过使用更低精度的数据类型来表示模型权重和激活值,藉此减少内存需求和计算成本的技术。使用的位数越少,模型就越小,能在更便宜的硬件上执行;但同时在近似原始模型权重时的质量也会变差,影响整体表现。

TheBloke的表格在这方面很有帮助,除了显示用于量化的位数和整体模型大小外,还有个「use case」字段,以高层次描述了模型的质量。为了让结果更具解释力,作者决定衡量不同量化程度的模型在评分上与原版模型的一致性。

他们取了Vicuna基准,用lm-buddy执行了三次评估,分别使用vLLM提供的Prometheus服务和本地的量化版llamafile模型,然后计算它们平均分数的皮尔森相关系数(PCC)。PCC介于[-1, 1]区间,数值越高代表越相关。  

结果显示,用于量化的位数越多,llamafile模型与原版越一致,PCC值也越高。虽然Q8模型与原版最相似,但Q5的PCC值也相当高,却只需16GB RAM。

接着作者测试了Prometheus和llamafile在简单的自定义场景中的一致性。他们在RAG情境中测试了不同模型,从预定义问题生成模型答案,然后用Prometheus进行人工评估和自动评估,使用自定义评分规则,分别执行原版模型和llamafile版本。

结果显示,作者的手动标注与原版Prometheus模型的PCC为0.73,显示两种评估整体上是一致的。手动标注与llamafile的PCC为0.7,显示量化版模型整体上与原版相当一致。原版Prometheus模型与llamafile版本的PCC则高达0.9。  

最后是评估速度和成本的比较。作者在配备A100 GPU的机器上使用原版Prometheus模型,以及在不同架构上使用基于特定llamafile的Prometheus,执行了相同的Vicuna基准测试。该基准包含320个提示,各自评估3次,总计960个HTTP请求。

比较表显示,要判断哪种模型最符合成本效益并不容易。它需要综合考虑不同变量,包括绝对成本(不只是每小时价格,在该硬件上执行特定评估任务需要多少小时,也是相关信息)和按需、预留或自备硬件的价格(即需要执行多少次这样的推理)。视需求而定,使用按需GPU或买台新笔记本电脑可能会便宜许多。

本文所述的本地LLM as Judge评估乃是许多开放开发项目共同努力的成果。时间轴上展示的项目虽然只是其中一部分,但已足以说明让作者的工作成为可能的秘诀:这些项目不仅要开源,更要在设计之初就考虑互通性。从打造可移植执行文件到定义发布LLM的标准二进制格式,从分享预量化模型到以通用API提供模型服务,所有这些努力都是为了鼓励软件模块化和人与人之间的协作。  

作者提醒我们要注意,Prometheus只是众多LLM as Judge方法之一,更重要的是,LLM as Judge本身并非万灵丹:毕竟我们还是在跟LLM打交道!其表现取决于提供的评分规则质量,以及我们用作评估者的模型之泛化能力。还有个非常重要的问题:「谁来审核审核者?」作者在这里只有将不同模型的表现与一些基准做了部分比较。尽管我们最信赖的还是人类做的ML评估,展示一些我们可以试验的开放、平价的人工评估替代品仍然重要:无论是为了在特定使用案例中做出明智的模型选择,或是为了在模型质量和成本间取得最佳平衡。

这篇文章展示了如何利用开源工具生态系统进行本地化的LLM评估,在降低成本的同时保有对流程的掌控。随着AI技术的快速发展,这种开放、协作的方式将变得越来越重要。唯有携手打造一个透明、可互通的AI框架,我们才能充分发挥这项革命性技术的潜力。