网站优化软件下载,学网站开发有什么好处,深圳外贸公司招聘信息,怎么查看网站是哪个公司做的本文整理自 2023 年 9 月 3 日 QCon 全球软件开发大会 2023 北京站 —— 从 MLOps 到 LMOps 分论坛的同名主题演讲。 本次分享的内容结构如下#xff1a; 从 MLOps 到 LMOps#xff1b; MLOps 概述、挑战与解决方案#xff1b; LMOps 实施挑战与关键技术#xff08;大模… 本文整理自 2023 年 9 月 3 日 QCon 全球软件开发大会 2023 · 北京站 —— 从 MLOps 到 LMOps 分论坛的同名主题演讲。 本次分享的内容结构如下 从 MLOps 到 LMOps MLOps 概述、挑战与解决方案 LMOps 实施挑战与关键技术大模型推理性能优化、Prompt 构建和自动优化、上下文长度扩展 未来展望。
1 从 MLOps 到 LMOps
众所周知目前我们实现人工智能的主要技术手段是机器学习技术特别是其中基于深层神经网络的深度学习技术。机器学习的本质是通过具有学习能力的算法、对数据进行建模的技术。
深度学习借助大规模的算力解决了机器学习中特征表示的人工干预的瓶颈在效果上取得了巨大突破。因此机器学习成为目前人工智能的主流技术。
深度学习和生成式大模型之间的关系如下图右侧所示在 2012 年至 2016 年左右像卷积神经网络、对抗生成网络、ResNet 等经典的深度学习模型已经在计算视觉、语音识别、自然语言处理等领域取得了显著的效果提升。这些经典深度学习模型既有判别式、也有生成式它们往往会在 ImageNet、COCO 等有标注的数据集上进行预训练形成带有预训练权重、可以进一步进行 Fine-tuning 的预训练模型。
在 2017 年 Transformer 结构在自然语言处理领域首先被成功应用在这之后以 Transformer 为基础组件的生成式大模型逐步成为视觉、自然语言处理、跨模态理解和生成领域的主流技术。
这类技术通常以 Transformer 和注意力机制作为组件并且它可以并行地进行自监督学习参数规模在十亿以上。其中将生成式大模型技术应用在语言建模上的方式被称为「大语言模型」。在经过进一步的调优之后形成了像 ChatGPT、文心一言等被大家熟知的对话式、生成式大语言模型应用。 DevOps 是贯穿传统软件生命周期的方法论和最佳的技术实践它包括软件的需求提出、代码开发、测试、上线运维和推广运营等多个环节。其中的关键技术包括需求管理、版本控制、持续集成、组件化、容器化、微服务、持续交付、自动化运维等。目前 DevOps 的平台和工具已经成为大多数软件开发企业驾驭软件研发运营最有效的方法。
MLOps 是机器学习时代的 DevOps其主要作用就是连接模型构建团队和业务建立起标准化的模型开发、训练、部署、上线、监控的最佳实践从而提高质量简化管理流程。在大规模生产环境中自动部署机器学习和深度学习模型让模型与业务需求、规则要求更好地保持一致。
下面将为大家简单概述 MLOps 与 DevOps 以及两者的共同点与区别后面也会为大家详细讲解 MLOps 与 DevOps 相关概念、挑战与解决方案。
MLOps 与 DevOps 的共同点 简化步骤流程MLOps 与 DevOps 通过建立清晰、连续的步骤简化软件开发 / 模型开发过程。MLOps 以缩短 ML 开发中的周转时间为主。 降低沟通成本MLOps 与 DevOps 通过建立标准化的流程步骤来降低沟通的成本。MLOps 相当于是系统管理员、数据科学团队和整个组织中其他部门之间对如何开发和维护生产模型达成共识。
MLOps 与 DevOps 的区别 MLOps 有更加复杂的版本控制对于机器学习代码并不是唯一不断变化的输入数据、参数、元数据、日志以及最后的模型都需要做好版本管理。 持续监控和持续训练DevOps 和 MLOps 中的监控之间的区别在于软件不会降级而机器学习模型会降级。数据将随着业务环境的变化和调整而继续变化和调整从而导致模型退化。 和经典深度学习模型相比大模型在人工智能技术与应用层面也发生了巨大的变化比如在以下 4 个层面 数据首先在数据上大模型的预训练通常需要 TB 至 PB 级别的数据这个数据规模和对应的数据加工技术是和经典深度学习模型很不一样的。同时现在的大模型还越来越多的以多模态、指令、对话数据作为训练或调优输入在数据内容上和之前也有不同。 训练现在的千亿参数级别的大模型往往需要千卡甚至万卡进行分布式训练这其中的调度、容错、通信技术和之前大不相同大模型在调优过程中也出现了很多低资源开销、高效率的技术。 评估经典深度学习模型往往基于人工标注的测试数据集来计算客观指标并评估模型效果。因为大模型生成的海量内容暂无标准的答案所以我们无法全部依赖人工去评判内容的质量。因此大模型的效果和性能需要建立与以往不同的评估基准和评估方法。 推理通过提示工程去调教大模型的输出无论在自然语言处理还是视觉生成领域之前经典的深度学习模型都不具备这些能力。 大模型在技术和应用模式上带来了巨大的变化也对企业提出了新的挑战比如如何对 AI 能力进行运用和管理、如何实现大模型规模化落地。这些对于数据工程、模型调优、模型交付、服务运营、支撑能力等环节都提出了新的要求。
LMOps 可以帮助企业解决大模型带来的上述新挑战。
LMOps 是大模型开发、运营一体化的方案让企业快速自建与管理大模型。通过整合各种能力与模型运营全过程的标准化要求帮助企业实现从数据到服务的完整流程让大模型快速、高效地部署在生产环境中提高大模型应用落地的效率和质量。
人工智能发展让 MLOps 和 LMOps 平台和工具呈现在我们眼前。接下来我将为大家详细拆解 MLOps、LMOps 面临的挑战以及对应的解决方案。 2 MLOps 概述、挑战与解决方案
数据及模型缺乏统一的管理底层基础设施不统一、且分散在不同的算法研发小组中。比如在汽车工业早期实践中一辆汽车的制作过程只由一位工人手工参与缺乏协作而导致浪费大量的造车时间与人工精力。
这也让机器学习模型研发面临第二个问题模型整体开发部署与迭代的周期较长。
模型的监控体系不够完善模型在实验室环境下是不会出现效果变化的但现实业务数据则不同随着数据分布和数据结构的变化模型的实际应用效果则可能出现衰减这就需要一个持续监控能力。
角色协同因为人工智能整个应用系统的开发过程中, 会涉及到的业务团队, 运维团队和算法工程师团队之间的协同相关环节的打通而往往就在这个环节中我们会遇到一个难以逾越的障碍这个真应了托尔斯泰的名言通畅的企业是相似的不通畅的企业各自有各自的不通畅方式。什么人有何种权限能访问多少资源彼此会不会冲突和影响也需要一个统一协调和管理的平台或机制。 在 MLOps 的具体实践中如果计划构建一个 MLOps 实践需要贯穿机器学习生命周期的全流程包括数据处理、模型构建、模型训练、模型部署、预测服务落地和后续监控优化。每个环节都有一系列的难题待续解决和管理。
所以构建 MLOps 实践需要相应的工具将各个流程之间进行自动化和打通并建立起基于流水线的协同机制。 为此百度智能云推出 AI 中台构建 MLOps 实践让机器学习系统所有步骤自动化运行、实时监控。
百度 AI 中台是依托百度大脑十余年 AI 技术与能力的积累目前已经为金融、能源、互联网、教育、运营商、制造、政府等行业提供了智能中台解决方案帮助企业构建统一的 AI 基础设施实现 AI 资产的共建共享、敏捷的智能应用开发。
百度 AI 中台的功能架构全景图如下图所示 样本中心主要对接数据中台、获取数据并对数据进行特征处理或数据标注。 AI 开发平台当数据完成特征处理、标注后数据会进入 AI 开发平台来进行进一步的开发工作。AI 开发平台主要面向算法工程师帮助算法工程师开发平台其他功能快速进行模型开发和训练。 模型中心完成训练的模型会进入模型中心统一管理。 AI 服务运行平台最终模型中心处理好的模型部署包发往 AI 服务运行平台上线部署最后由软件工程师整合到客户应用中。
AI 中台整个流程在模型风险管理的监控体系下可以做到全流程可检查、可追溯降低企业应用AI 能力的风险。而在整个流程中的数据也可以形成对应的 AI 资产进行企业内跨组织跨部门的分享打破部门藩篱避免重复建设。
大模型平台是 AI 中台的组成部分面向生成式 AI 的基础设施。百度 AI 中台既对外直接提供模型能力又支持企业自主高效构建。
当前百度 AI 中台已经覆盖 MLOps 方法论的核心环节并已获得信通院相关标准旗舰级认证。百度 AI 中台也是国内唯一一家能获得此级别认证的产品或方案。 下面将为大家简单介绍 MLOps 核心的技术。 自动化数据标注模型真正运行起来人工标注占据了大量的时间、人力劳动成本。MLOps 通过自动化方式进行数据标注去除噪声数据保证模型训练数据的质量节省人工数据标注的时间、成本。 实验管理 版本控制自动收集实验参数配合 Git 等版本控制系统来管理代码、数据、模型文件等。当模型需要进行效果追踪和对比时可以通过前期自动收集的实验参数进行回溯不断优化模型效果。 AutoML AutoDL使用 AutoML 等技术来自动搜索算法和调参快速找到最佳模型并加速实验周期。 可解释性通过可解释性技术来分析模型行为响应大模型监管、安全的需求提高模型透明度。 漂移监控当模型上线以后数据发生变化导致模型效果下降所以需要不断监控、优化模型。漂移监控可以收集模型训练和推理的日志设置关键指标监控模型性能并可实现自动重训。 模型适配持续扩展模型适配的硬件范围促成广泛环境下的自动部署。 模型压缩使用剪枝、量化等技术来压缩模型大小减少显存占用提升运行速度降低部署成本。 API-Centric平台主要操作行为可代码化连同实验版本信息可自动执行。 3 LMOps 实施挑战与关键技术
如下图所示虽然 LMOps 问世不久但整个上下游的各类公司已经共同构建了繁荣的生态。近期大模型引发的投资热里有三分之一的资金投在了 LMOps 相关工具或平台上。
虽然企业较多也出现了一些新面孔不过依然可划分数据、训练、评估、推理、部署和安全这 6 个主要环节。今天时间有限我挑了几个有大模型特色的技术点来和大家分享。 目前针对大模型推理性能优化、Prompt 工程、上下文长度扩展等三个具有大模型特色的技术点已经整合至百度智能云千帆大模型平台。
千帆大模型平台以智能云算力基础设施以及 AI 中台成熟能力为基础重新定义了大模型时代的 AI 应用构建范式。其广泛兼容市场上的几十个主流大模型覆盖 LMOps 生命周期并可实现自动化。
应用开发者无需掌握模型细节通过简单的页面交互即可进行大模型微调、评估、压缩、部署、提示功能等功能。同时还支持插件机制应用方可以通过插件来扩展自身大模型场景。 3.1 大模型推理性能优化
QAT 是量化感知训练Quantization-aware-training的缩写它是一种在模型训练过程中引入伪量化Fake-quantization来模拟量化过程中带来的误差的方法目的是让模型能够适应量化后的数值表示从而减少量化后模型的精度损失。
QAT 的优势是 可以在训练时就考虑量化误差使模型更加鲁棒避免后处理量化带来的较大精度损失。 可以使用更高精度的梯度更新权重避免量化噪声对优化过程的干扰。 可以使用更灵活的量化策略如对不同层使用不同的量化位宽、对不同通道使用不同的缩放因子等。
QAT 的劣势和局限性是 需要修改模型训练代码增加伪量化操作和观察器可能会影响模型结构和性能。 需要重新训练模型增加训练时间和成本。 需要选择合适的量化配置和超参数如量化位宽、观察器类型、校准数据集等这些可能会影响量化效果。 百度智能云针对大模型提供四种训练后量化方案分别是针对权重、激活层以及 k/v cache 进行量化从而实现了不同压缩效果供开发者使用。 per-channel 就是 weight 的每个 channel 使用单独的量化参数这种方法比 per-tensor 的量化方法更细致量化参数的自由度也更好所以可以得到精度无损的效果。
per-group 是指对权重参数进行分组再将每个组进行 int8/Int4 的量化。分组可以采用不同的策略比如每 128 个权重参数分为一个组然后它的每个组就可以有各自不同的最大最小值范围和精度整体会精度更高。 针对大模型量化可以在量化前增加一定的 smooth 过程平滑权重分布解决大模型权重分布不够均匀的问题。
引入超参数 s 可以很好地平衡量化过程中激活函数量化和权重量化之间难易度的差异使得整个量化过程更加平滑同时也提高了量化方案的泛化性。通过这两点改进可以有效减轻大模型量化带来的精度损失使量化后的模型精度更接近原始全精度模型从而实现高效的大模型部署。
该方案通用性好对于千亿级别的大模型能节省一半显存或卡数且精度无损同时速度也能提升 1.5 倍。 在前述方案中权重和激活都是由 int8 保存的但是大模型中另外一个消耗显存的运行时参数 k/v cache 依然是 FP16 保存的。
为此我们新增了 k/v cache int8 量化。可以在保证速度的情况下显存进一步压缩 15%节约运行时显存实现真正意义上的全流程 int8 量化。 模型稀疏是一种模型压缩的技术它的目的是减少模型中的参数数量从而降低模型的存储空间和计算复杂度。模型稀疏的原理是利用某种策略如权重剪枝、特征选择、矩阵分解等将模型中的一些参数置为零或删除让模型变得稀疏。在模型稀疏下只有少数参数是非零的。
静态压缩是在训练结束后对模型进行压缩动态压缩是在模型训练过程中就进行压缩。相比静态压缩动态压缩使用更多原因如下 动态压缩可以持续优化。当训练过程中识别出不重要的参数可以直接进行压缩。动态压缩可以随着训练的过程持续进行压缩优化。 灵活调整。动态压缩可以根据资源情况动态调整压缩率适应不同的部署需求。 动态压缩可以更好地保留重要信息。动态压缩可以在训练过程中识别参数重要性保留对模型更为重要的信息。 百度智能云的大模型方案主要是基于业界最新的探索进行的方案实现。SparseGPT 是其中一个被应用的方案。
SparseGPT 算法是奥地利科学技术研究所 ( ISTA ) 的两名研究人员 Elias Frantar 和 Dan Alistarh 开创的首次针对 100 至 1000 亿参数的模型规模可以进行精确的单次剪枝方法。
SparseGPT 重建算法的可视化。给定一个固定的剪枝掩码 M使用 Hessian 逆序列HUj并更新这些行中位于列「右侧」的剩余权重逐步修剪权重矩阵 W 的每一列中的权重处理。具体来说修剪后权重深蓝⾊「右侧」的权重将被更新以补偿修剪错误而未修剪的权重不会生成更新浅蓝⾊。
该方法处理后的大模型性能最大可提升 60%。此外SparseGPT 是对量化方法的补充二者可以结合应用。 另外一种被应用的方案是 WandA。
传统的剪枝思路是非常直接的即对网络里的权重如果其绝对值小于一定阈值就会认为该权重所起到的作用不大直接清空成 0。
新的 WandA 方案则是提出需要同时考虑权重和激活因此处理时先要将权重和激活进行一个乘法运算然后将其中小于阈值的参数归零。
该方案在精度上并不比 SparseGPT 优越但效率非常高耗时上有数十倍的提升。
通过上述这些方法自今年 4 月以来千帆大模型平台上的部分模型推理性能已经提升了 10 倍以上。 3.2 Prompt 构建和自动优化
大模型因为参数量巨大所以有着强大的语言生成能力。但是它的输出也极端依赖于输入的质量。如果输入不当很可能得到错误的回答。
所以如何给大模型提供合适的输入成为一个值得研究的问题。找到最佳输入方式的工作现在被称为提示工程。
提示工程需要研究不同类型的提示格式找到对特定任务最有效的表述方式。同时还需要考虑输入的长度、语句结构等因素使 Prompt 既包含足够的信息又不会过于冗长。
一个好的 Prompt 能明确交代任务要求并让模型聚焦于关键信息从而生成出优质的输出。 让普通用户自己构建复杂的 Prompt 往往不太实际因为设计出一个高质量的 Prompt 需要专业知识和大量时间。如果直接让用户提供自然语言的问题或请求系统帮助用户自动转换为合适的 Prompt会对用户更加友好。理想情况下用户只需要用简单的语句表达需求不需要操心底层的 Prompt 格式。
为实现这一目标一种方法是建立 Prompt 模板库根据用户查询的意图匹配已有的高效模板然后插入查询的关键信息自动生成 Prompt。另一种方法是训练一个模型可以直接把自然语言转化为充分表达其意图的 Prompt 语句。此外还可以在用户查询后用反馈机制多次迭代优化 Prompt直到生成满意的回复。 常见的提示工程有一些经典办法: 直接提出问题这是效果最难保障的一种方式。直接提出问题的方式回答的效果取决于大模型训练是否充分以及是否进行过良好的指令微调压力主要集中在大模型侧。 小样本提示。用户先给大模型举一些例子然后让大模型回答同类型的问题这种方式的效果普遍较好。 CoT 提示过程是一种最近开发的提示方法它鼓励大语言模型解释其推理过程。思维链的主要思想是通过向大语言模型展示一些包含逻辑推理过程的样例, 并要求大模型在回答时同样显示推理过程。这种推理的解释往往会引导出更准确的结果。 生成知识提示让大模型发挥自身潜在知识丰富的优势通过自我完善背景信息从而获得准确的答案。 刚才讲过人工的提示工程有两个问题第一个问题是探索耗时巨大普通用户不会费心思构建适合的 Prompt。第二个问题是不同的模板适应的任务有限不通用。
在工程落地上讲当前有两种办法可以使 Prompt 工程进一步自动化。
第一个是专用模型即应用系统接收 Prompt 后先发往一个分类模型, 让它判断这个 Prompt 是否可优化。如果需要则发往一个专门使用大量指令训练出来的一个新模型这个模型对原始 Prompt 进行润色和补充然后再发往 LLM从而获得更好的答案。这种方案简单直接但整体推理开销变大了一些。
另一种方案是让大模型先生成结果然后自己对结果进行分析同时提供优化建议 继续让大模型利用优化建议生成多个相关 Prompt大模型对这些新生成的 Prompt 继续评估和建议从而生成最佳 Prompt。该方案自动化程度更高但也有两个局限一是依赖核心大模型自身的能力二是推理开销会更大。可以作为离线任务对 Prompt 模板库进行自动补充。 3.3 上下文长度扩展
很多大模型的输入只有 2K 至 3K token对大模型应用造成局限。所以每次大模型例如 GPT-4、Claude 对 Context 进行扩展后市场都给予热烈反馈。
这个四海皆同的痛点导致学界和工程界提出了一系列的技术方案例如外挂方案 直接外推内插方案等来快速拓展大模型的输入输出长度。由于方案数量过多本篇文章将为大家精选两个简单的方案进行详细描述。 为了解决大模型上下文长度不足的问题我们可以采取一种直接的方法即将原始输入或背景资料进行切分并将其存入向量数据库。
然后根据用户 Prompt 到向量数据库中进行匹配以向量数据库中匹配到的片段作为 Prompt 背景知识让大模型生成回答。
比如对一本书的内容进行提问就可以用这种办法。
向量数据库可以提供快速的查询和检索操作使得处理过程更加高效也是为什么近期向量数据库突然火爆的原因。对于摘要任务也可以先切片然后分段进行总结将总结合并或改变循环顺序。顺序摘要层层总结。
然而这种方法也存在一些局限性。例如切分可能导致信息的丢失和重复从而影响模型的准确性。 在一些特殊的长上下文场景例如阅读理解我们可以采用完全外挂的基于 Naive Bayes 的 NBCE 解决输入 query 原文后长度超限的问题。其原理是将原文切分成若干个小片段并对每个片段采用 query 提问并计算哪个生成结果与 query 最相关。其假设是问题只和原文的部分有关并且切分的小片段之间对问题的回答没有相互依赖。但这种方法场景局限性很强且效果一般。
所以NBCE 应运而生。NBCENaive Bayes-based Context Extension即朴素贝叶斯上下文扩展。NBCE 的主要适用场景是假设要预测的答案可以分为若干个片段每个片段只依赖于一个Context。它基于朴素贝叶斯思想来扩展 LLM 的 Context 处理长度有着即插即用、模型无关、无须微调、线性效率、实现简单等优点。 那有没有更加通用的应对长上下文的方案呢
目前业界用的比较多的是位置插值的方法。我们知道最原始的 Transformer 中为了让同一个 token 的 Embedding也就是输入 x在不同位置上有区别采用了对输入的 Embedding 向量进行绝对位置编码的方式也就是在 Embedding 向量的每一个维度分量上加上一个基于绝对位置的三角函数增量值。
但这种方法直接扩展上下文长度的上限会导致生成效果急剧下降。因此有学者提出了对于经过权重矩阵 Q 相乘后的 query 向量和矩阵 K 相乘后的 key 向量分别乘以基于位置的三角函数的增量也就是 RoPE 编码它相当于把相同的 q 和 k 向量在不同的位置进行了不同角度的调整。
在这个编码的基础上进一步调整向量每一个维度的距离进制就形成了位置插值的上下文长度扩展方法。这种方法的通用性较好且仅需要少量长文本数据进行调优即可。当然长上下文增强的技术还在不断发展目前已经出现了不需要调优且较为通用的其他方法。 4 未来展望
过去的半年我们经历了一场百模大战在开源社区隔三差五就有新的大模型出现相关的技术也越来越标准化、同质化。特别是 LLaMA 系列, 让我们学了不少「驼」系英语单词比如 llama 是美洲驼alpaca 是羊驼vicuna 是小羊驼。为什么有那么多以驼命名的大语言模型呢
因为大语言模型 Large Language Model 的缩写是 LLM当年 Meta 公司觉得两个 L 在一起不太好念所以就选了一个相近的词语 llama它的意思是美洲驼。而后来基于这个开源大模型调优的很多开源模型就都给自己取了驼系名称。
同时我们可以看到在这一轮硅谷的大模型的创业公司中不包括 OpenAI有将近 1/3 的资金投入了 MLOps 和 LMOps 的工具和平台方向。 越来越多的高质量开源模型将充斥市场国外是有 LLaMA 系列国内也有一系列自主开源模型这个状态还会延续一段时间。但由于模型本身同质例如 Dolly 12B 等参数量较低效果一般的模型会彻底沉寂。同时闭源模型会主攻多模态或更加智能的方向。
行业大模型也会是一个短期繁荣的景象。未来新一代超强模型会覆盖行业大模型的能力从而抑制其发展势头。标志性事件就是 GPT-4 在金融领域的能力超过了专门训练的 BloombergGPT。一种解释是大模型在数万亿的训练语料加持下已经获得了全行业知识只是缺乏合适的激发手段。当然这个是我们的一个基础判断但行业尤其是企业内部的知识库还是有其价值的值得深入积累。
最后就是 LMOps 平台依然重要。因为企业关注成本即便企业不再尝试自主开发大模型但使用和运营 LMOps 平台依然有集约化建设和规模化运营带来的成本优势。 以上是今天分享的全部内容。
点击阅读原文了解更多产品信息
——END——
推荐阅读
百度APP iOS端包体积50M优化实践(七)编译器优化
百度搜索内容HTAP表格存储系统
大模型时代“人人可AI”的百度开发者平台长什么样
数十万QPS百度热点大事件搜索的稳定性保障实践
百度搜索万亿规模特征计算系统实践
