别再死磕大模型!专业模型+Agent才是大模型的未来之路

大语言模型(LLMs)的规模越来越大,但这并不意味着它们就更加出色。由确定性编排和基于代理的架构支持的专业模型,正为我们开辟一条更智能、更精准、更可靠的发展道路。

导言

随着大语言模型功能的不断增强,软件开发者和用户的期望也水涨船高,希望能充分利用这些新特性。然而,在追求进步的过程中,我们始终面临着一种平衡难题:每出现一个新的大语言模型,尽管在某些方面有所提升,但随之而来的是可靠性问题,比如信息不准确和所谓的“幻觉”现象。我们对模型的要求越来越高,而模型的可靠性却不断下降,如此循环往复。

难道就没有更好的解决办法了吗?我认为,如今我们对大语言模型的期望过高。每当有新的、更强大的模型出现,我们便迫不及待地赋予它更多任务,结果却一次次遭遇错误和不准确的输出。就像我前面说的,这种情况不断重复上演!

问题的关键在于,大语言模型是基于概率运行的,而概率的累积和增长有时会带来灾难性的后果。当模型处理简单任务时,其可靠性和准确性极高;但一旦面对复杂任务,小错误就会像滚雪球一样,呈指数级放大。从这个角度看,“小而精”或许才是更好的选择。

那如何才能让大语言模型更好地为我们服务呢?目前,“思维链”和“反思”等技术被广泛应用,它们将复杂的指令分解为一个个小的部分。然而,这种方法也存在核心问题:在整个指令流中,一个指令部分的输出往往依赖于前一步的结果,这种依赖性会导致“乘法”错误,即不准确的信息在指令流中不断累积。当指令流足够长时,就可能引发严重的错误。

本文旨在提出一种解决方案,大幅减少错误,提升大语言模型的可靠性。我们的方案融合了多种技术:

  1. 将提示分解为较小的任务:把任务拆解成“任务计划”,将大请求转化为一系列针对大语言模型的、微小且高度可靠的请求。
  2. 确定性编排:基于大语言模型的分支逻辑和工具使用(即计划执行),交给确定性且100%可靠的编排引擎处理。
  3. 专业大语言模型:随着性能提升和成本大幅降低,特定领域的专业大语言模型迎来发展机遇,这些模型能显著减少错误。
  4. 独立执行:每个任务步骤(本身就是一个较小的提示)被打包成独立的工作单元,传递给独立的专家大语言模型处理,这样能避免级联错误的累积。
  5. 以代理作为部署工具:代理将上述所有功能整合到一个统一的架构中。

问题陈述

但凡和大语言模型打过交道的人都知道,它们会生成不准确的信息,还会出现“幻觉”现象。在处理简单、明确的任务时,这种问题似乎还能控制,模型的响应通常可靠、可重复且准确。但一旦请求(或提供)的内容增多,情况就急转直下。

以基于大语言模型的软件开发为例,这是当下大语言模型最常见且实用的应用场景之一。开发者发现,使用这些模型生成简短程序或单功能脚本时,可靠性较高,几乎能做到零错误运行。然而,当要求模型生成更复杂的内容,比如多文件软件项目或大型复杂组件时,其可靠性和准确性就会大幅下降。很多时候,这些较长的代码输出首次运行时往往会出错,需要手动重新设计和修改。

这种性能上的差距使得大语言模型在大规模部署时困难重重,对于那些对正确性要求极高的项目来说,甚至根本不可行。在金融、医疗、保险等受严格监管的行业,情况更为严峻,这些行业的规范极为严格,几乎没有给大语言模型可能产生的事实错误或语义错误留下任何空间。

事实上,最近一项研究Long-context LLMs Struggle with Long In-context Learning指出了当前大语言模型存在的问题,特别强调了较长、上下文丰富的输入超出了大多数模型的处理能力,会加剧模型早期的不准确性。研究表明,“当前大语言模型在处理和理解长且上下文丰富的序列方面存在显著差距,长上下文理解和推理对现有大语言模型来说仍是一项极具挑战性的任务”。

这一问题进一步说明,尽管大语言模型潜力巨大,但在对精度要求极高或任务极为复杂的场景中,它们仍存在不足。不难理解,考虑到可能出现的高昂错误成本和法律风险,企业往往对集成这项技术持谨慎态度,尤其是在面对复杂需求时,大语言模型的不可预测性让企业望而却步。除非这些缺陷得到解决,否则一些极具潜力的市场机会将始终无法实现,特别是在银行、医疗保健、政府等需要严格合规的行业。

根本原因

大语言模型依赖概率方法,而非固定规则(即它们具有不确定性),这就是为什么它们有时会给出错误或自相矛盾的回答。模型的每个输出令牌都是基于前一个令牌,以及从大量训练数据中学习到的概率来选择的,这就意味着无法保证最终生成的内容完全正确。更麻烦的是,即使输入和环境条件完全相同,每次运行模型得到的输出也可能不一样。这与确定性系统形成鲜明对比,确定性系统对于给定的输入,每次都会输出准确(或至少可验证准确)且一致的结果。

这种现象的根本原因,我称之为“选择的组合爆炸”。当模型处理短指令时,从输入到输出的过程简单直接,出错的概率较低;但处理长而复杂的指令时,就会面临更多的分支选择。选择越多,出错的可能性就越大,而且错误会不断累积和级联,呈指数级增长!

简单来说,由于每个令牌都依赖于前一个令牌,一个小小的错误(尤其是在处理初期出现的错误),就可能在后续文本中不断放大,最终导致灾难性的(或至少是不可靠、不可重复、不准确的)结果。

如图1“选择的组合爆炸”所示,通过一个简化计算可以直观地看到错误率的级联效应。虽然实际编码大语言模型的错误率要低得多,但为了便于理解“选择的组合爆炸”背后的数学原理,我们假设每个令牌的准确率为99%:

  • 100个令牌:准确率为37%()
  • 1,000个令牌:准确率为0.004%()
  • 10,000个令牌:准确率极低!

img

这也解释了为什么一些对大语言模型最有吸引力的应用场景——那些需要大规模输出或复杂推理的任务,往往伴随着最高的错误风险。如今,在决定大语言模型的应用场景时,这种权衡是一个重要的考虑因素。

潜在解决方案

一些从业者尝试通过迭代优化来提高大语言模型的准确性和可靠性。他们先让模型进行一次尝试,然后检查其中的不一致之处,并将这些错误反馈给模型进行修正。这种方法在处理较小的输出时效果不错,比如简短的代码片段或简洁的叙述。通过正视模型的初始缺陷并系统地进行纠正,开发者能够得到更好的最终结果。

img

类似的思路还有“思维链推理”,即促使模型逐步阐述其推理逻辑。这种方法通过迫使大语言模型详细列出问题与答案之间的中间步骤,来减少不准确信息和“幻觉”现象的出现。它能有效防止模型在复杂推理场景中直接得出缺乏依据的结论,减少不相关输出。然而,当模型的响应变长时,错误累积的根本问题依然无法得到解决。

归根结底,随着新项目规模和复杂性的增加,大语言模型预测的内在机制会导致错误不断累积,即使是最巧妙的指令设计或优化技术,其效果也会受到限制。

那使用更强大的大语言模型呢?我们常常寄希望于更新、更先进的大语言模型,认为它们能直接解决准确性和可靠性的问题。近期发布的模型在规模、训练数据和复杂性方面都有了重大突破,能够处理更长的输入指令,生成更复杂的答案,且在达到错误阈值前仍能保持一定的实用性。这种能力的提升虽然扩大了模型输出可靠结果的范围,但也只是推迟了问题的爆发。

一旦企业采用了这些高性能模型,就会很快发现对更广泛输出的需求也在同步增长。例如,在处理中等复杂度任务时取得的初步成功,可能会促使团队尝试更复杂、更细致的任务。但最终,错误的指数级增长问题(即“选择的组合爆炸”)还是会再次出现,我们又会陷入与使用较小模型时相同的困境(只不过规模更大)。

以ChatGPT为例,GPT3.5推出时,其出色的自然语言交互能力令人惊叹,但很快人们就发现了它在准确性和可靠性方面的不足。随后GPT4发布,虽然修复了部分问题,但随着我们对模型能力的挖掘,又发现了新的应用场景,而在探索这些新场景时,错误依然存在。当更新的大语言模型加入音频和视频功能后,错误问题依旧没有得到彻底解决。

根本问题在于,企业(尤其是那些对结果准确性要求极高的受监管行业)在实际应用中发现,即使模型能力有所提升,当请求超出一定范围时,仍然无法满足需求。尽管模型可靠性能的“窗口”有所扩大,但每增加一个令牌,出错的概率就会相应增加,而模型基于概率的本质并未改变。因此,一旦任务复杂度超出模型的处理能力,错误就会再次大量出现。

很遗憾,这充分表明单纯依靠扩展大语言模型的规模是有局限性的。即便模型不断升级,“选择的组合爆炸”及其带来的问题依然如影随形。

大语言模型专业化

大语言模型在能力不断提升的同时,成本也在大幅下降。这为开发更专业的应用创造了机会,企业不再需要依赖单一的通用模型。如今,企业有能力部署多个针对特定任务优化的小型模型,而无需等待通用模型慢慢进化。事实上,大语言模型走向专业化的趋势不仅在加速,而且似乎已不可阻挡。

img

这种专业化趋势在其他行业也屡见不鲜。在半导体制造领域,企业曾经试图自主制造整个芯片,但很快发现外包专业组件效率更高。随着时间的推移,高度专业化的制造工厂应运而生,不仅降低了成本,还提高了产品质量。供应链网络中也存在类似的模式,每个参与者都专注于发展自身的特定优势。其中的逻辑很简单:当每个参与者都专注于自己最擅长的领域时,整个系统都会从中受益。

经济学家将这种现象称为“比较优势理论”,即如果各方都专注于自身具有明显优势的活动,整体生产率就会提高。应用到我们的大语言模型领域,这意味着没有一个模型能够适用于所有场景。相反,多个专业模型可以蓬勃发展,每个模型都针对特定的窄领域进行训练。

在实际应用中,专业化意味着用户无需依赖单一的大型通用大语言模型。他们可以立即部署更小、更专业的大语言模型,在不影响性能的前提下,覆盖不同的业务领域。

专业大语言模型的编排

一些组织已经开始尝试编排多种语言模型,将通用大语言模型与一个或多个专业模型相结合。每个模型负责处理复杂任务的不同部分,确保不会有单个模型因承担整个任务而不堪重负。这种方式既能利用通用模型的多功能性,又能借助专业模型在特定领域的深厚专业知识。

这种方法通常依赖一个“编排器”大语言模型来解析和理解初始请求。这个编排器可以是通用大语言模型,也可以是专门用于任务规划的大语言模型。它会确定需要完成的任务,并制定包含多个步骤的任务计划,然后在可用的大语言模型清单中挑选最合适的模型,将具体的任务步骤分配给它们。

通过将大请求分解为一系列小的离散步骤,编排器确保每个步骤的指令简短、范围明确。这些专业大语言模型独立运行,通常只需要与自身特定功能相关的上下文信息。编排器负责协调各个模型的执行过程,收集最终输出,并将它们整合为一个连贯的结果。

这种设计实现了任务的独立性。正是由于任务规划和任务执行由不同的大语言模型独立处理,才使得整体错误率得以降低。一个领域出现的错误不会影响整个解决方案,因为每个步骤都有明确的边界,无需依赖单一执行线程的逐个令牌路径。

专业化带来的一个有趣“副产品”是,它还能缩小大语言模型所需的数据范围,仅保留完成任务所必需的数据。企业无需将所有数据都提供给通用大语言模型,而是可以将数据访问权限限制在经过授权、能够处理特定类型信息的专业模型上。例如,处理交易数据的金融大语言模型与编写营销文案的模型相互隔离,从而降低了不必要的数据泄露风险。

此外,这种编排方式在部署上也具有很大的灵活性。团队可以根据需求、训练情况或模型的可用性,随时插入新的专业模型,淘汰过时的旧模型。一切都围绕编排器为不同情况挑选最佳资源的能力展开,形成了一个动态发展的环境,无需对端到端架构进行全面改造。

代理:大语言模型编排器

代理在设计上就具备规划能力,通常由专门或通用的大语言模型来实现,它能够确定每个请求所需的具体步骤和资源。一旦制定好计划,代理就会进入执行阶段,调用相关工具或其他代理,这些工具和代理会独立完成各自负责的工作部分。各个组件之间的运行重叠度极低,这不仅保证了可靠性,还降低了错误在不同任务之间传播的可能性。

img

在这种模式下,代理首先会查看可用的大语言模型和工具清单,然后决定计划中的每个步骤应该由哪个资源来处理,无论是专业(特定领域)模型还是通用模型。代理会将请求分解为一个个明确的小操作,确保每个阶段都不会过于复杂或容易出错。每完成一个步骤,代理就会汇总输出结果,并根据预设的约束条件或验收标准进行验证。如果有需要,代理可以提示工具或模型重新执行某个操作或纠正错误,然后再进入下一步骤。

这种基于代理的方法还可以作为一系列微服务集成到企业基础设施中。每个微服务都可以根据企业的要求进行安全设置、监控和扩展。由于这种架构限制了单个故障的影响范围,避免了单个大语言模型试图处理所有细节时可能出现的“组合爆炸”问题,运维人员能够在一个更稳定的环境中工作。微服务模型也简化了新代理的发现和部署过程,使得在不影响整体流程的情况下,更容易部署带有专业大语言模型的新代理。

一类新的可解问题

让我们回顾一下走到这一步的过程。

首先,多个大语言模型的组合通过将特定任务分配给最合适的模型,有效解决了“组合爆炸”问题。将通用模型与专业模型相结合,避免了单个系统承担生成长且相互依赖的输出的压力,降低了错误级联的风险。这种转变让开发者能够充分发挥每个模型的优势,而不会过度消耗某个模型的资源,也无需让模型处理不适合它的任务。

其次,我们把代理视为实现这种协调的关键机制。代理作为编排器,设计并执行任务计划,将子任务分配给最合适的模型或工具。通过微服务的形式实现,这些代理继承了企业在安全、监控和高可用性方面的成熟解决方案。团队无需在单一的大语言模型环境中重新开发这些功能,而是可以采用主流的DevOps实践来维护系统的性能和可靠性。

最终,我们得到了一个框架,在这个框架中,“组合爆炸”带来的挑战被最小化,但也出现了一些新问题。

例如,随着时间推移管理冗长的对话,重点不再是生成连续的令牌流,而是如何在多个会话中构建和持久化状态。同样重要的是,要建立人工反馈或干预的标准方法。在关键节点,可能需要领域专家的指导和关注,因此提供一个统一的手动输入接口至关重要。

状态管理也是一个难题。在单一的大语言模型方法中,所有内容可能都在一个上下文窗口中处理;而在基于代理的架构中,数据会在不同模块之间传递,每个模块都有自己的内存和检查点机制。不过,我们可以借助事件流、分布式缓存以及定义良好的交换API等成熟的工程模式来解决这些问题。这些解决方案借鉴了数十年的分布式系统设计经验,有助于构建一个稳定且可扩展的系统,而无需完全依赖提示工程。

当然,这些额外的复杂性需要精心规划,但它们都是“已知的未知”。我们已经掌握了保护微服务、审计日志以及管理不同组件间数据流的方法。虽然采用模块化方法需要进行协调,但它确实消除了单个大语言模型能力受限的瓶颈。

结论

大语言模型会持续发展和改进,但由于其不确定性的设计以及“选择的组合爆炸”问题,错误、不准确和“幻觉”现象仍将伴随我们。

所以,我们不必一味等待下一个大语言模型的出现,还有其他可行的选择。大语言模型能力的提升和成本的降低推动了专业化发展,新的编排技术让我们能够将复杂问题拆解为更易处理的小问题,同时减少错误和不准确的情况。当我们将这些技术应用于基于代理的架构(尤其是基于微服务构建的架构)时,还能借助数十年来在安全、可观测性和可操作性方面的经验,应对新方法带来的挑战。

正是这种新方法,将大语言模型不确定性和“选择的组合爆炸”这一“永恒难题”,转化为一个基于可解决、长期研究且理解透彻的方案的分解问题,有效减少了错误和不准确情况的发生。

如何学习大模型 AI ?

由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。

但是具体到个人,只能说是:

“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。

这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。

我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述

第一阶段(10天):初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。

  • 大模型 AI 能干什么?
  • 大模型是怎样获得「智能」的?
  • 用好 AI 的核心心法
  • 大模型应用业务架构
  • 大模型应用技术架构
  • 代码示例:向 GPT-3.5 灌入新知识
  • 提示工程的意义和核心思想
  • Prompt 典型构成
  • 指令调优方法论
  • 思维链和思维树
  • Prompt 攻击和防范

第二阶段(30天):高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。

  • 为什么要做 RAG
  • 搭建一个简单的 ChatPDF
  • 检索的基础概念
  • 什么是向量表示(Embeddings)
  • 向量数据库与向量检索
  • 基于向量检索的 RAG
  • 搭建 RAG 系统的扩展知识
  • 混合检索与 RAG-Fusion 简介
  • 向量模型本地部署

第三阶段(30天):模型训练

恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。

到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?

  • 为什么要做 RAG
  • 什么是模型
  • 什么是模型训练
  • 求解器 & 损失函数简介
  • 小实验2:手写一个简单的神经网络并训练它
  • 什么是训练/预训练/微调/轻量化微调
  • Transformer结构简介
  • 轻量化微调
  • 实验数据集的构建

第四阶段(20天):商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。

  • 硬件选型
  • 带你了解全球大模型
  • 使用国产大模型服务
  • 搭建 OpenAI 代理
  • 热身:基于阿里云 PAI 部署 Stable Diffusion
  • 在本地计算机运行大模型
  • 大模型的私有化部署
  • 基于 vLLM 部署大模型
  • 案例:如何优雅地在阿里云私有部署开源大模型
  • 部署一套开源 LLM 项目
  • 内容安全
  • 互联网信息服务算法备案

学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。

如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值