写点什么

虚拟座谈:采用大语言模型时应该注意什么

作者 | Anthony Alford, Meryem Arik, Numa Dhamani, Maggie Engler, T

  • 2024-11-04
    北京
  • 本文字数:6424 字

    阅读完需:约 21 分钟

虚拟座谈:采用大语言模型时应该注意什么

简介


大语言模型(LLM)是一种通用的人工智能解决方案,可以处理各种任务:回答问题、总结长篇文档,甚至编写代码。许多组织都希望采用这种技术,但随着创新步伐的加快,要跟上不同 LLM 的发展速度(每个选项都有自己的优势和风险)可能会很困难。


大多数人都熟悉通过 Web API 提供的大模型,如 ChatGPT。许多人也熟悉与这些模型相关的风险,如可能产生 “幻觉 ”和隐私问题。他们可能还知道,需要 “提示工程 ”才能从模型中获得最佳结果。但是,他们可能并不了解都有哪些模型可供选择或最佳实践。


在我们的虚拟座谈中,我们将讨论人们在采用 LLM 时应考虑的一些问题,以及如何针对具体的用例做出最佳选择。

虚拟座谈嘉宾


  • Meryem Arik:@TitanML 合伙创始人

  • Numa Dhamani:@KUNGFU.AI 首席机器学习工程师

  • Maggie Engler:@Inflection LLM 工程师兼研究员

  • Tingyi Li:@AWS 企业解决方案架构师

InfoQ:与 “本地 ”或自托管模型相比,在选择基于 API 的模型(如 ChatGPT)时有什么指导性原则吗?


Meryem Arik:关于应该使用自托管模型而不是基于 API 的模型,我们在最近的一篇博文中介绍了几个主要原因。首先是控制和数据隐私。对于很多企业来说,他们的 LLM 应用程序会接触到相当敏感的业务数据,因此对他们来说,控制可以看到这些数据的模型可能非常重要。


第二,可定制性。当使用自托管模型时,你可以控制模型中的所有权重。也就是说,你可以按照自己的意愿对模型进行微调或调整。即使是比较小的模型,这也能带来更好的结果。


第三,成本和可扩展性。诚然,在实验阶段,基于 API 的模型往往更便宜,因为不需要构建自托管的基础设施。但是,在大规模应用时,使用高效推理技术栈进行自托管往往成本更低,可扩展性更好。


现在,Llama 3 等开源模型已经问世,我们几乎没有理由不建设自托管能力。Llama 3 与领先的基于 API 的模型不相上下,但它有一个额外的好处,就是可以在自己的环境中进行私有部署。即使不是所有的应用程序都使用自托管模型,每个企业也都必须建设自托管能力,否则真的会错失良机。


Numa Dhamani: 在决定是采用基于 API 的模型还是本地或自托管模型时,有几个关键的因素需要考虑。首先是数据隐私和安全。使用基于 API 的模型可能会将敏感信息暴露给服务提供商。如果你的数据包含专有或敏感信息,这可能会是一个问题。另一方面,本地模型部署在组织自己的基础设施上,你可以保留对数据的控制。因此,对于医疗保健和金融等受数据隐私监管的行业来说,本地模型是更好的选择。


此外,成本和资源分配也是重要的考虑因素。在开始阶段,基于 API 的模型在运营开销方面往往更划算,因为你是按使用付费,避免了与基础设施设置和维护相关的费用。此外,它们通常也更容易集成和使用。有的组织没有能力或意愿管理人工智能系统所依赖的复杂的基础设施,对于他们来说,基于 API 的模型往往是理想之选。


不过,虽然在初始设置和持续维护方面,本地模型需要更多的资源,但长期来看,它们可以节约成本,并提供更大的灵活性。对于广泛并持续使用模型的组织来说,这尤其有利。本地托管还可以减少延迟,因为数据不需要在互联网上传输,而这对于时间敏感型应用来说至关重要。最后,依赖 API 模型可能会面临与服务可用性以及条款或定价变化相关的风险,从而影响长期规划和运营稳定性。


Maggie Engler: 大多数企业首先关注的是构建和维护成本。假设两种模型的规模和功能大致相同,基于 API 的模型在配置时所需的工程资源更少,而负载管理和扩展通常由 API 提供商负责。考虑到服务基础设施的成本,按 API 调用付费可能是值得的,尤其是对于探索性项目和概念验证而言。


对于长期、大批量使用,自托管模型可能更划算,而且对性能和延迟的控制能力更强。此外,对数据隐私和安全要求较高的组织也可能会选择使用自托管模型,以避免与第三方提供商共享数据。


Tingyi Li: 要在基于 API 的模型与本地或自托管模型之间做出选择,需要考虑各种因素,包括具体的用例、技术专长、资源可用性和预算。通常情况下,鉴于数据管理、隐私和透明度相关的法律法规要求,处于高度监管行业的公司将不得不采用内部托管模型。


如果你需要大量进行定制,或需要针对特定领域或用例对模型进行微调,那么自托管模型可能更适合你。它让你可以完全地控制模型架构、训练数据和参数。代价是,你需要负责维护基础设施、更新模型并解决出现的任何问题。


对于基于 API 的模型,定制选项可能仅限于提供商提供的内容,但你可以受益于自动更新、Bug 修复和功能改进,而无需为此付出额外的努力,因为这些都是由提供商完成的。


成本也是一个重要的考虑因素。基于 API 的模型通常采用订阅或按使用付费的模式,这可能更划算,特别是对于中小型应用程序而言。但是,随着使用量的增加,成本可能会大幅提高。而使用自托管模型,前期需要在基础设施和持续维护方面进行投资,但从长远来看,对于大流量应用而言,这种模型更划算。


此外,对于实时或延迟敏感的应用,本地托管模型可能可以提供更好的性能,因为这样可以消除网络开销。基于 API 的模型会因网络通信而产生额外的延迟。

InfoQ:在你们看来,什么情况下应对 LLM 进行微调,什么情况下可以使用 “开箱即用 ”的提示工程?


Arik: 我建议在进行微调之前,先尝试所有可以替代微调的技术,因为它们的工作量要小得多!可以使用的替代方法包括检索增强生成(RAG)、控制生成和提示调优。


Dhamani: 是对 LLM 进行微调还是采用提示工程主要取决于手头的任务。如果你有什么特殊要求,或者需要模型具有高度的特异性,那么微调可能是更好的选择。例如,如果你的企业属于一个有许多专业术语的细分行业,那么你就可以通过微调来调整模型的响应,以适应这些特定的上下文。


与此同时,提示工程更适用于一般的应用或任务,因为它们的定制化需求并不那么重要。如果你更看重的是适应各种任务的灵活性,而不是针对特定任务的深度专业化,那么这种方法尤其有用。


Engler: 对于特定的应用,如果你正在考虑使用 LLM,那么你应该有非常明确的成功标准。你应该有一套可以体现用户与模型交互方式的上下文,并在其中定义好成功的响应应该包含哪些组成部分,然后用于评估模型。此外,最好能够以这种方式评估任意模型。


对于许多应用而言,提示工程可能已经足够,而不需要任何额外的微调;恰当的提示可以产生可靠的原始响应,或者,如果有什么特殊的输出限制,则可以对响应进行后处理以满足这些限制。微调能让你对模型的响应进行更精细的控制,但还是应该首先尝试更简单的方法。


Li: 没有哪一种情况是必须进行微调的,但有很多情况应该避免微调。根据经验,应先从 “低垂的果实 ”开始:使用 “开箱即用 ”的模型,并及时开展提示工程和 RAG。不用半天时间,你就可以使用私有数据完成针对特定用例的快速概念验证,从而就可以对其在生产中的性能和成本进行粗略评估。


是否进行微调取决于你所追求的投资回报率,即把评估、微调模型的成本和所带来性能提升及为企业创造的商业价值进行比较。


例如,如果你有像 Perplexity.ai 这种由 GenAI 驱动的垂直化产品即服务,或者你希望将 GenAI 作为核心的差异化优势来推动业务发展,那么就可能需要在微调上进行投资。但是,随着 Llama3-8B 等开源模型的出现及其推理能力的提升,一些使用小模型的细分用例可能会变得更为可行并且简单。

InfoQ:对 LLM 的 “民主化 ”,你们有何看法?在某些情况下,开源 / 开放权重的小模型是否已经足够好?


Arik: 是的!不止一些:实际上是大多数。现在,Llama 3 已经发布,它输出的结果与许多基于 API 的模型不相上下。因此,几乎没有理由不使用开源语言模型。即使只是作为 “备份”,也应该进行自托管语言模型能力建设方面的投资,否则就是不负责任的,因为那会将大量的控制权交到第三方手中。


Dhamani: 毫无疑问,LLM 的民主化有可能促进人工智能领域的创新、降低准入门槛并增加竞争。在某些情况下,小型开源模型就足够了,甚至是有优势的。


对于教育、科研、实验以及计算资源有限的环境,它们尤其有价值。现在,个人和比较小的组织或研究机构也可以探索人工智能的能力,努力减少其局限性,并建立应用原型,而无需像使用大模型那样投入大量的资金。


当然,虽然对于某些任务,小模型已经非常有效,但在处理更复杂或更微妙的任务时,其性能通常无法与更先进的大模型相比。这种时候往往就需要在资源限制和任务性能要求之间做出平衡取舍。


Engler: 是的!小型开源模型的功能越来越强大,对于许多用例来说,它们已经足够好了。也有一些用例就是需要小模型,比如在移动设备上运行的 LLM。


我经常与一些提示工程师交谈,他们没有意识到小模型也行,而且可以为他们节省大量的资金。最近,我遇到一位顾问,他正在使用 GPT-4 完成一项任务,而实际上,一个参数少于十亿的模型就能够轻松地完成他的任务。我建议他们使用 GPT-4 标注几千个样例,然后使用这些样例对一个小模型进行微调,以节省推理成本。


Li: 无疑,开源 / 开放权重模型有很好的透明度,可以加速开源模型的开发和各种衍生产品的扩散。虽然小型开源 LLM 有其优势,但它们可能并不适合所有的用例。总体而言,我们目前还很少把开源模型与封闭模型相提并论。


不过,并不是所有用例都需要最先进或性能最好的模型。在很大程度上,开源和小型 LLM 的有效性取决于应用的具体要求、资源和限制。在许多情况下,它们可以提供一种可行且易于使用的方法来替代大型专有模型,尤其是辅以精心定制和优化的情况下。

InfoQ:使用 LLM 有哪些常见的风险?该如何避免?


Arik: 人们谈论最多的风险是幻觉问题。不过,我认为这不是一个问题,而是一个需要了解的 LLM 特征。如果构建者知道,幻觉是使用 LLM 构建应用程序时不可避免的问题,那么他们就可以努力设计出能够减轻幻觉的系统。


对于减少幻觉,最常见和最流行的方法是 RAG :这主要是指模型能够 “查找 ”信息帮助其生成答案的能力。RAG 的奇妙之处在于,它不仅能让模型实时访问数据,还增加了一个可视层,让用户可以查看模型在得出答案时使用了哪些信息。要了解有关 如何构建 RAG 应用程序的指导性原则,可以看一下我们的博客。


Dhamani:LLM 有若干风险和局限性,必须谨慎使用才能有效地利用其功能。有充分的证据表明,LLM 不仅会继承而且会放大训练数据中存在的偏见。这可能会导致歧视性的做法,使历史上存在的不公正和不平等永久化,尤其是在预测性警务、招聘或信用评分等敏感应用中。减少偏见的方法包括:彻底的偏见审计、使用和记录多样化的数据集以及包容性测试和验证流程。


另一个令人担忧的问题是隐私,因为 LLM 可能会无意中记住并泄露敏感信息。在训练过程中,可以通过隐私增强技术(如差分隐私)来缓解这一问题,如果要进一步保护用户数据,则可以部署强大的数据匿名协议。


LLM 也很容易产生幻觉(即产生似是而非的信息),可以利用 RAG 等技术为它们提供额外的上下文数据,这可能有助于缓解模型的幻觉。


最后,建议使用 “人机环路(human-in-the-loop)  ”解决方案,即通过人工智能来增强决策而不是取代决策,这不仅有助于减少幻觉、偏见和其他人们担忧的问题,如劳动力技能退化,还能确保核心点仍在人类经验上。


Engler: 实际上,LLM 生成回复时肯定会存在误解。从本质上讲,它们是根据以往的数据预测最有可能的响应。这使得它们很容易编造出听起来很真实但实际上并不准确的信息,并强化偏见。


此外,这也意味着,非常规输入有时会产生意想不到的输出,我们已经看到过很多 LLM“越狱 ”行为,即规避了模型的某些训练,产生不安全的内容。关于缓解措施的讨论,可以写满一本书。但总的来说,这些风险有许多缓解方式,包括从可信数据源检索、针对鲁棒性进行微调以及对输入和输出进行消毒(sanitization)。


Li:LLM 有许多常见的风险,如利用误导信息进行诈骗、滥用知识产权、侵犯隐私、偏见等。也就是说,企业在考虑 AI 系统时要采用一种负责任的管理方式。


有 8 个关键的维度需要考虑,包括:公平性、可解释性、AI 系统的鲁棒性、AI 行为的可控性、数据隐私与安全、执行负责任的 AI 实践、AI 使用的透明度以及安全性(避免滥用和伤害)。为了落实这 8 个方面,就得将负责任的 AI 视为构建模型的公司和使用这些模型构建应用程序的公司之间共同的责任。

InfoQ:要成功地采用 LLM,需要进行哪些非技术性或组织性变革?


Arik: 一是整合资源。LLM 很难部署,而且需要大量的资源。也就是说,整合团队之间的资源有很大的价值。与其让各团队单独进行部署,不如让他们专注于构建优秀的应用程序,并共享由中心团队提供的资源。这样既可以更好地利用资源,又可以大大加快开发周期。


另一个是培训。LLM 的行为方式与人们想象中的计算机行为方式大相径庭:它们是非确定性的,有时会犯错误。为此,我们在与它们互动时就需要考虑到这一点。我们建议向非技术人员提供像 Mindstone 这样的优质课程。这样,他们就能更好地理解什么是人工智能,以及如何在工作中利用人工智能。


Dhamani: 要在组织内成功地采用 LLM,除了技术部署之外,还必须进行全面的组织变革。首先,需要领导层的支持。这不仅包括在各部门倡导使用 LLM,还包括劳动力培训、实现道德与治理框架,以及培养持续学习和发展的文化。


所有级别、所有部门的员工都应接受有关 LLM 基本知识的培训,包括大体了解 LLM 的工作方式、能力和局限性,以及与 LLM 互动的最佳做法。


实施强有力的道德与治理框架还能确保 LLM 的采用符合公平、隐私和透明度标准,防止潜在的道德和法律陷阱。


Engler: 在企业内部,要成功地采用 LLM,就必须对 LLM 的功能和存在的风险(包括幻觉和数据隐私问题)进行培训。但是,LLM 带来的变化可能比人们想象的少:目前,LLM 仍然最适合作为现有工作方式的补充,而不是取而代之。它们可以快速、高质量地完成初稿,解释概念,将更多繁琐的工作自动化。


斯坦福大学和麻省理工学院最近的一项研究发现,LLM 的使用使呼叫中心员工的整体工作效率提高了约 14%,其中新员工的效率提升最为明显;专家员工则没有得到多少帮助。企业在采用 LLM 时,应采取务实的迭代方法,不断进行试验并评估投资回报。


Li: 非技术性的组织变革至关重要,它可以最大限度地发挥 LLM 的优势并降低其潜在的风险。首先,组织需要培养一种拥抱 LLM 等 AI 技术的文化。这包括推动各级员工认识、理解并接受人工智能。


如果企业想要安全、负责任地开发人工智能,那么他们就应该采取以人为本的方法,优先培训领导者,推动科学发展,并力求将负责任的 AI 集成到在端到端 AI 生命周期中。他们应实施全面的培训计划,让员工掌握在工作流程中有效利用 LLM 的方法。这涉及以下内容的培训:最佳实践、道德考量以及如何解释和信任 AI 生成的内容。


应围绕 LLM 的使用制定明确的治理结构和政策,包括数据处理、模型部署、隐私保护和遵守监管要求的指导方针。最终,各组织应着眼于制定一个合乎道德的 GenAI 采用框架,以指导组织负责任地使用 LLM,这也符合组织的文化和实践。


此外,FMOps(Foundation Model Operations)需要组织在传统的 MLOps 实践中引入额外的机制,如人机环路、模型基准测试与评估。持续监测和评估对于评估 LLM 的性能、影响和投资回报率至关重要。组织应制定跟踪关键性能指标的衡量标准,征求用户的反馈意见,并随着时间的推移不断改进模型。


小结


我们在虚拟座谈中就几项一般性原则达成了共识。首先,在开始的时候,基于 API 的大型闭源 LLM 是一个很好的实验工具。不过,在许多情况下,比较小的开放模型也是一种可行的解决方案,而长期看来,自托管模型可以节省成本并解决隐私问题。


无论选择哪种模型,当试图改进模型的响应时,提示工程和检索增强生成(RAG)往往是比微调模型更好的选择。RAG 也能很好地降低 LLM 风险,如幻觉。


LLM 为公司和组织提供了一个提高员工效率的绝佳机会,尤其是当这些员工经过培训,了解了该技术的好处和局限性时。不过,企业应该有明确的成功标准,并跟踪模型使用的投资回报率。


原文链接:

https://www.infoq.com/articles/llm-adoption-considerations/

2024-11-04 08:055109

评论

发布
暂无评论
发现更多内容

如何成为一名优秀的技术Leader?

架构精进之路

成长笔记 七日更 28天写作

2021面试脚本!夜读互联网Java开发27大专题,终入P7

比伯

Java 程序员 面试 计算机 技术宅

还热乎的面经

书旅

百度 面试 面经

第一周

Richard

基于机器学习的逻辑回归模型

无誉

腾讯T3大佬亲自教你!一起刷完了这份1307页的安卓面试宝典吧,吐血整理

欢喜学安卓

android 程序员 面试 移动开发

mq消费幂等总结

A

MQ 幂等性 db

程序员的简历,要注意以下几点

田维常

简历

FFMpeg解码API以及在解码过程中存在的丢帧问题

wangwei1237

ffmpeg 视频解码

软件测试--cookie学习

测试人生路

软件测试

美团图数据库平台建设及业务实践

NebulaGraph

图数据库

k8s 上运行我们的 springboot 服务之——springboot服务https请求

柠檬

Java k8s https Istio,

AQS之ReentrantReadWriteLock写锁

伯阳

读写锁 ReentrantReadWriteLock 多线程与高并发 lock

有人相爱,有人年少财务自由,有人数据结构都背不出来

Java架构师迁哥

爱了爱了!带着问题深入学习Handler,吊打面试官系列!

欢喜学安卓

android 程序员 面试 移动开发

持币生息钱包APP系统开发|持币生息钱包软件开发

系统开发

架构师 3 期 3 班 -week9- 作业

zbest

作业 week9

Spring Boot 中集成ActiveMQ

武哥聊编程

Java springboot SpringBoot 2 28天写作 Activemq

数字钱包系统软件开发|数字钱包APP开发

系统开发

Redis中哈希分布不均匀该怎么办

Java 数据库 编程 程序员 面试

[JetPack] LiveData源码解析

Changing Lin

android 技术 JetPack

Pulsar vs Kafka,CTO 如何抉择?

Apache Pulsar

大数据 pulsar 消息中间件

高效学习:如何制定有价值的学习目标

石云升

学习 28天写作

深度模型的日志异常检测,还有谁不会?

华为云开发者联盟

运维 日志 网络 AIOPS 系统

全球城市ZoneId和UTC时间偏移量的最全对照表

YourBatman

GMT UTC ZoneId 时区

架构师 3 期 3 班 -week9- 总结

zbest

总结 week9

对微服务架构设计实践中若干问题的探讨

xcbeyond

微服务 28天写作

DCache 分布式存储系统|安装部署与应用创建

TARS基金会

缓存 分布式 微服务 存储 TARS

数据结构与算法 - 哈夫曼树

ios 数据结构与算法

关注直播 解锁采集器新功能

滴滴云

运维 可观测性 直播技术 滴滴夜莺

Java 程序经验小结:避免使用终结方法

后台技术汇

28天写作

虚拟座谈:采用大语言模型时应该注意什么_AI&大模型_InfoQ精选文章