ToB和ToG客户必读:金睛云华带您探索行业大模型

新闻
1年前

企业微信截图_16944128909456.png图1. 行业大模型概览

曲博技术稿1(1).jpg

图2. 行业大模型通用框架


序言

在不断发展的人工智能领域,大语言模型占据了重要位置。随着ChatGPT受到广泛认可,语言模型,尤其是大语言模型(Large Language Models,LLMs)成为科技领域的重要话题。这些模型在大量的文本数据上进行训练,使它们能够掌握复杂的语言模式与语义内容的细微差别。凭借前所未有的语言处理能力,LLMs能够生成高质量内容,完成复杂语言处理任务。以LLMs模型为核心的开发框架出现为自然语言处理打开了一个充满可能性的世界,可以用其创建行业大语言模型。本文重点阐述面向ToB和ToG客户的行业大语言模型,以及使用大模型的过程当中,可能遇到极大的数据安全与隐私挑战。在利用大模型能力的过程中用户的隐私数据跟环境需要掌握自己的手里,完全可控,避免任何的数据隐私泄露以及安全风险。基于此,行业厂商需要提出以私有安全行业大模型为核心的解决方案。此方案需要支持本地部署,所以不仅仅可以应用于独立私有环境,而且还可以根据业务模块独立部署隔离,让大模型的能力绝对私有、安全、可控,让围绕关键用户的业务构建大模型应用更简单、更方便。


其实,在讨论行业大模型的问题之前,需要明确一个问题。大模型(Large Model)是一个非常让人容易误解的名字,更准确叫法应该是基模型(Foundation Model)。就目前而言,大模型至少要有两个要素:(1)跨任务的通用性,即行业大模型;(2)跨域的通用性,即通用大模型。


研究和实践表明,在参数数量方面扩展模型可以显着提高任务性能。例如,GPT-2拥有15亿个参数(Radford et al. 2019),而其后继者GPT-3拥有1750亿个参数(Brown et al. 2020)。此外,在更多数据和计算上训练这些更大的模型甚至可以带来额外的性能提升。然而,模型大小的增加也导致了更高的计算和存储需求,使得许多行业的企业无法在自己的基础设施上训练和部署这些模型。当然,这些挑战促进了对行业大模型研发和部署的研究,早期结果表明仅使用一小部分参数,使用数据管理、模型精调和内存/计算优化(如LLAMA、GPTQ、GGML等)策略可以产生有竞争力的模型,例如微软的PHI-1模型(Gunasekar et al. 2023)和CodeLlama模型(Roziere et al. 2023)。对于PHI-1模型,使用1.3B参数,高质量的7B Tokens,八张Nvidia A100训练约4四天时间,其性能击败了参数规模是其10倍、使用数据量是其100倍的模型,特别是超过了1750亿参数的GPT-3.5。对于CodeLlama模型,参数规模为34B,以其作为基础精调的WizardCoder模型以73.2%的胜率击败GPT-4(1.8万亿,13万亿Tokens,20230315版本)的67%。

曲博技术稿1(2).jpg

表1. 尽管PHI-1训练的规模要小得多,但在HumanEval和MBPP上的表现优于除了GPT-4的同类模型,而且以PHI-1为基模型的精调模型WizardCoder也获得了更好的成绩。


曲博技术稿1(3).jpg

图3. wizardcode-python-34b-v1.0在此基准测试中获得第二名,超过GPT4(2023/03/15, 73.2 vs. 67.0),ChatGPT-3.5 (73.2 vs. 72.5)和Claude2 (73.2 vs. 71.2)。


尽管取得了这些进步,通用大模型和行业大模型之间的性能仍然存在差异,这篇文章旨在提供一些指导并涵盖以下内容:

(1)根据参数数量以及在单台GPU服务器或集群上预训练、精调、部署每个模型的能力,将生成模型分为行业大模型和通用大模型;

(2)讨论行业大模型构建方法,包括构建方法(高性能基础模型选择、数据管理、精调优化和推理优化)以及提供的优势(隐私和合规性、行业适应、延迟/成本、扩展和正常运行时间、数据效率、可解释性);

(3)一个简单的通用框架,用于根据业务问题的功能和非功能需求选择要使用的模型。


行业大模型

将“行业大模型”归类为可以在单台GPU服务器或GPU集群上进行精调和部署的模型,使它们对于大规模解决业务问题更加实用。通过检查神经网络模型的内存需求可以更好地理解这种分类。通常,模型中的每个参数如果存储为16位浮点数,则需要2个字节的内存(对于大多数用例来说,16位通常具有足够分辨率)。例如,具有10亿参数的模型将需要2GB显存。考虑到大多数消费级GPU设备具有8GB到80GB(例如Nvidia A100 GPU)显存,对本地行业大模型的定义包括参数大小从约40亿到400亿个参数的模型。而且,从模型量化方面的进展(Frantar等人提出的GPTQ技术;Dettmers等人提出的4bit量化技术)和参数高效精调(Hu等人提出的LORA精调,Dettmers等人提出的QLORA精调),以及高效注意力技术(Flash Attention-1和Flash Attention-2的进展)优化了训练速度和显存占用情况,有利于本地行业大模型使用更大的参数规模,例如40B的模型。而对于云端行业大模型,由于算力资源和数据资源更充足,可以使用更大的参数规模,甚至大于70B的模型,有利于满足不同行业用户的业务需求。


构建行业大模型

构建行业大模型通常包含以下方法:

(1)端到端训练:使用通用数据和行业数据混合,通过不断实验确定好数据配比,从头开始训练一个大模型,最典型的代表就是BloombergGPT;

(2)二次预训练:在一个通用模型的基础上做二次预训练,像CyberGPT就是做了二次预训练的,也需要不断实验确定好数据配比,最典型的代表CyberGPT、MedicalGPT、LAWGPT等;

(3)有监督精调:在一个通用模型的基础上做有监督精调(SFT),开源社区最普遍的做法,优势是可以快速看到不错的结果,但会发现要提高上限比较困难,最典型的代表LexiLaw等;

(4)数据融合:领域知识库、搜索引擎和行业大模型融合,针对行业大模型对行业精准知识和最新动态难以覆盖的问题,利用Langchain和向量数据库等方式在领域知识或者搜索引擎中获取相关内容,再利用大模型强大的摘要(Summarization)和问答能力(QA/VQA)生成回复;

(5)上下文学习:使用大模型的上下文学习能力(In Context Learning),通过构造与领域相关的prompt,由行业大模型直接生成回复。随着业界把上下文窗口(Context Window)越做越大,prompt中可以放下越来越多的领域知识,直接用大模型也可以对领域问题有很好的回复。

(6)语料库管理:专注于细化和筛选用于训练行业大模型的语料内容,高质量的行业语料训练参数量较小的模型也能够达到甚至超过通用大模型的性能。


以上这6种技术并不是孤立存在的,需要组合使用,才能最好的解决行业问题。对于方法1,不需要通用大模型作为基础,但需要重新训练一个参数规模和通用大模型相当的模型。方法2和方法3都是在通用大模型的基础上或多或少对权重进行了调整,都可以认为是重新训练了一个行业大模型。方法4、方法5和方法6就只是使用了通用大模型来解决行业问题,很难称之为完整训练了行业大模型。因此,构建一个行业大模型存在较大的认知偏差,方法1相当于重新训练一个行业大模型,需要上千张GPU卡。而方法2需要几百张GPU卡,方法3可能需要十几张GPU卡。因此,对于构建行业大模型,行业数据质量和规模、耗费GPU小时数、工程量等需要有深度认识。


自托管的行业大模型

使用本地部署的自托管行业大模具有多重优势:

(1)隐私、安全性和合规性:很多行业应用可能有严格的数据隐私、安全性和合规性要求。例如,用于训练或精调模型的允许数据源、如何处理或存储推理数据等可能存在限制,从而阻止使用第三方API。自托管行业大模型可以通过提供对大多数模型构建步骤的控制来解决这些问题;

(2)精调、行业适应和快速研究原型:使大模型适应用户的特定任务可以采取多种形式,包括精调、解码方案、提示方案等。行业级的大模型适合多种精调机制,可以使基础模型适应业务环境。新兴的参数高效精调(PEFT)技术,例如LORA、QLORA等,在精心准备的行业语料加持下,在可控的时间内完成行业大模型的升级迭代是可行的。易于处理的精调还可以实现行业模型提供商和用户内部的快速研究和创新。此外,访问模型权重可以实现低级控制进而适应特定任务;

(3)模型优化、成本和延迟行业大模型可以经过优化,以便在现有GPU或CPU基础设施上高效运行。这可能包括推理量化、GPU内核优化等技术,这些优化可以带来成本和延迟优势;

(4)扩展和正常运行时间:可控的部署堆栈可以更好地控制系统扩展和提高正常运行时间。这对于拥有经验丰富的工程团队和强大产品SLA要求的大型组织尤其重要,因为它有助于避免API访问超时;

(5)数据效率:像ChatGPT/GPT4这样的大型模型因其在各个领域的知识而令人印象深刻。然而,这也可能导致效率低下。根据行业的业务或产品目标,用户可能仅需要这些模型的部分功能。此外,如果用户在一个具体行业领域运营,那么可能需要比ChatGPT等多领域通用大模型拥有更具体的、更精确的行业知识。在这种情况下,可以从大量利用行业专业知识的系统设计中获得更多价值。这可能涉及在语料库上精调较小的模型或补充检索增强生成(Retrieval Augmented Generation,RAG)模块。


云托管的行业大模型

此外,为了满足行业中不同细分领域客户的需求,往往需要上千亿参数的大模型,需要行业大模型供应商利用GPU集群对基础模型进行精调和推理。因此,这些模型往往只能通过拥有训练、优化和托管这些模型资源的行业厂商通过API接口进行提供。


如何选择

由于有多个通用大模型提供商(例如OpenAI GPT4、Google提供Bard、PaLM等大型模型作为云服务)以及数千个小型开源模型(例如清华KEG实验室推出的GLM基模型、Meta推出的Llama基模型),选择正确的模型可能具有挑战性。对于大多数行业大模型来说,由于技术专长、精调的数据采集成本以及所需的GPU训练成本等原因,从头开始创建生成大模型既不可行也不建议这样做,特别是预训练步骤(甚至预训练像LLAMA这样的中小型模型的成本也在500万至2000万美元之间)。除了选择基模型之外,还需要做其他几个决定,例如采用云托管模型还是自托管模型、使用原生模型还是投资对其进行精调等,这些都是困惑的根源。为此,给出一些实践建议:


(1)功能需求:构建行业大模型工作流程的第一步是将业务需求转换为生成建模任务和数据模态。例如,如果业务需求是生成文档摘要,则可以将问题定义为文本模式中的摘要任务;

(2)精度需求:对于精度要求较高的任务(例如,强大的指令遵循能力、事实准确性、时间准确性等),建议使用较大的模型,它们往往性能更好。从程序语言生成自然语言、行业数据分析和总结等工作需要高精度,建议使用相对更大的模型。而有些任务是行业内细分场景的,例如代码编码转换、漏洞分析、载荷解读等,根据自定义高质量的数据精调小参数模型可能会产生更好的性能。针对那些本质上不需要较大模型编码的广泛行业知识或事实任务,精调小参数模型还可以带来效率优势;

(3)非功能性需求:隐私、安全性、合规性、正常运行时间、延迟、成本等非功能性需求可能会影响模型的选择。某些要求(例如安全性、数据合规性和隐私)可能会阻止使用第三方托管的API(例如,敏感的客户端数据无法发送到用户边界之外的系统)。其他要求,例如正常运行时间、延迟、成本,可以通过优化的自托管模型基础设施更好地解决;

(4)行业任务的MMLU测试:尽管已经建立了像MMLU(Hendrycks et al. 2020)这样的基准来评估大语言模型在各种任务中的表现,但这些基准可能无法完全捕捉模型在不同行业任务上的性能程度。例如,在MMLU上表现出色的模型可能会难以完成以下指令任务,解读威胁事件、进行威胁事件攻击链关联、分析攻击载荷和攻击意图等。因此,针对特定行业,非常有必要开发准确代表行业任务的MMLU基准,并基于它评估不同的大模型。可以讲,建立行业MMLU基准测试任务示例是构建行业大模型的关键一步。


行业大模型实践经验

(1)分布式训练框架:建议使用成熟的DeepSpeed,少用Pytorch原生的torchrun。在GPU数量较少的情况下,使用哪种训练框架并不是特别重要;然而,一旦涉及多节点集群,DeepSpeed的优势很明显,其简便的启动和便于性能分析的特点使其成为理想训练框架之选;

(2)弹性容错和自动重启机制:大模型训练不是以往那种单台GPU机训练几小时就结束的任务,往往需要GPU集群训练几周甚至几个月时间,这时候对于稳定训练非常关键。弹性容错能让你在机器故障的情况下依然继续重启训练;自动重启能让你在训练中断之后立刻重启训练;

(3)过程模型:训练过程中,每隔一段时间需要做个checkpointing,这样如果训练中断还能从上次的断点来恢复训练;

(4)训练加速方法:最常用的有Flash Attention(V1和V2),加速效果很不错,基本是开箱即用。其他的有算子融合,fused_kernels等;

(5)流水线并行和张量并行:大模型的参数规模都特别大,通常都会用流水线并行和张量并行的方法在GPU集群环境下训练大模型;

(6)目的明确:训练一次大模型的成本很高的。在训练之前先想清楚这次训练的目的,记录训练参数和中间过程结果,少做重复劳动;


结论

在本文中,我们探讨了行业大模型的性能、属性以及它们对不同业务问题的适用性。特别是,对于自托管的行业大模型优点,包括隐私、安全性、遵从性、精调、行业适应性、原型设计、模型优化、成本、延迟、可伸缩性、正常运行时间、数据效率和可解释性等。对于行业大模型提供商和行业用户,建议通过将业务需求转换为建模任务,考虑数据隐私和成本等非业务功能,并创建自定义的基准来评估行业大模型对于特定任务的性能,进而企业可以就哪种模型最适合他们的需求做出明智的决策!


参考

https://zhuanlan.zhihu.com/p/643805698

https://zhuanlan.zhihu.com/p/642611747

https://newsletter.victordibia.com/p/understanding-size-tradeoffs-with

1694413813849831.png