Bootstrap

一窥廉价LLM时代的Agent策略框架设计

TL;DR

  • 介绍一种新的设计思路:用少量的prompt撬动尽可能多的智力工作量。

1、前提条件

1.1、高性价比LLM的到来

虽说现在各家LLM供应商都很难做到持续的快速提升,但从整个生态来说每个季度整个生态进展都是比较显著的。2024年Q2商用LLM API提供的能力有几个主要的进展:

  • 文本模态方面,效果真的能够接近和追上GPT4o的LLM供应商明显变多

  • 国内开始卷性价比,成本很低、效果还可以的模型正在变多,成为无法忽视的新类别。(指的是每M token 1-2RMB的那批模型中的效果较好的那部分。)

  • Context window也大都提升到至少32k token

可以预见,在未来半年高性价比的LLM应该会变得更加普及。

1.2、基于少量LLM调用的方案能力仍然很有限

单次LLM调用的能力方面:在国内半年,甚至一年中都没有太大的进展,单就文本模态来说GPT4和GPT4o的效果差异在不少方面都并不明显。其他家也只是做到追上了GPT4o,并没有显著超过GPT4o。国内各家也只是效果上接近于追上,在token生成速度上等其他方面还是有明显差距的。

Workflow和Agent策略框架的方面,过去半年没有太大的进展,甚至我现在都举不出来这半年的新例子。

RAG方案方面,过去半年中有一些开源工作,但整体的改进都不是针对于LLM workflow的,更多是一些其他方面。

1.3、人工调优workflow的成本仍然“较高”

对高质量要求的场景来说,目前大多还是基于人工预先构建workflow的方式。其问题是开发者调教的成本高,如果需要从专家脑子中把可传递的知识抠出来的话,其开发成本还要增加至少一个数量级。所以导致不少场景下,开发方尝试自己构建workflow的意愿较低。

严格来说这个成本高并不是之前很多人想象的总费用高,而是实际上开发者和领域专家对于调优workflow的耐心比大家预期要低,workflow的调优成本仍旧是显著高于开发者和领域专家的耐心的。我之前对此方面也认知不足,这是我在Q2认知上的一个主要修正。

对于质量要求不高的场景,应用开发方思路更多是压低成本搞免费、搞流量、筛用户等等,试图“寻求PMF(Product-Market Fit)”,而不是做好P。

连调教workflow都嫌成本高,微调在应用开发的前期阶段中的使用率更是在逐步降低。一方面是由于LLM模型能力的提升,微调的增量收益的下降,另一方面是微调需要的数据构建pipeline也是卡点之一,这又回到workflow构建的方面。(不过一旦前期PMF验证,有了一些数据积累之后,微调作为成本压缩和提速方案仍然是主要推荐的方案。)

目前,是否能PMF的风险和开发成本都较高的环节是产品原型开发并打磨到符合期望效果的这个阶段。而本文后续则是针对该环节的讨论。

2、问题

2.1、当下短视、无信心的大环境

既然单次LLM调用无法解决问题,通过更多次的调用仍然是一种主要的解决方案,至少在延迟和成本可接受的场景中,追加workflow可以有效的事先增量改进。可以“增量地投入成本、做不会影响其他方面的确定性改进”,这在产品迭代和企业内转型的过程中是非常难得的优点。

但问题在于,构建workflow的每个节点(大致对应到一个prompt)的成本还是较高,精调一个prompt只是为了完成一个环节,在不确定“PMF”(整体做完就大概率能取得直接收益)的情况下,应用层的开发方在这方面的意愿是低的,(也许这个意愿从去年开始就从来就没高过)。

好产品成本高,没人做;烂产品用户不买账似乎也正常。整个LLM应用生态似乎陷入了僵局,这大概也是目前生态萧条的一个原因——目前的技术方案性价比还不够高。

2.2、连workflow都要构建不起了

重新审视LLM,大家都同意它是一个前所未有的新工具,人类的第一个能够通用地处理语义的工具,还具有不错的场景迁移能力。就算LLM应用层再不成功,LLM模型层面还可以“算是成功的”,同一个产品(模型)可以用在很多场景下,可以被很多次使用,研发成本可以被有效分摊。

回头看LLM应用层的workflow,就能看到它的一个问题:每条prompt所能撬动的计算量不够高。在workflow的一次session调用中,大多prompt执行次数是:

  • 1次,该prompt在workflow的必经环节中

  • 平均不到1次,该prompt仅位于某个分支中,不是每次都能被调用。

而prompt/workflow的构建/调优成本是显著的。虽然说调教workflow可以有效地提升整个流程的正确率(或符合期望率),但很多场景下大家对于更高准确率的付费意愿并不能覆盖由此带来的研发成本甚至推理成本,更别说在现在所有人都短视和保守的大氛围下。

而现在的团队 要么有钱没信念、要么没钱没信念,总之有足够信念的团队不多。构建不起workflow,很多适合核心原因并不是没钱,而是大家对此没有信念,不信在这上投入能大概率地获得成功。所以无论大小公司、有钱没钱,构建足够复杂和高质量的workflow都是一件不容易的事情。

3、新的思路

是否有办法解决这种“靠完善workflow细节来改善效果”的方式成本较高的问题呢?其实有一些可能性:

  • 通过更少的prompt来尽量多的总体提升效果,减少prompt数量来降低prompt/workflow的开发成本。

  • 如果整个流程能够容忍质量不高的workflow节点,那么也可以通过削减prompt调优的工作来降低成本。

3.1、让每条prompt撬动尽可能多的有效智力工作量

本节先讨论第一点。通过更少的prompt数量来完成更多的效果提升,这听起来似乎不可能。但如果我们能够通过提升平均每个prompt能够撬动的计算量,那么是有可能完成更多的智力工作,乃至最终提升总产出价值的

什么叫撬动更多的计算量呢?就是能够在一次流程中,反复多次的调用同一个prompt。例如排序算法中的元素比较算子,对于N个元素的排序,平均调用了 O(N log N)次这个比较算子,调用了这么多次同样的算子函数,只是为了完成一次数组排序。

这样我们就可以在整体上进行设计,让一些环节(prompt)能够在不同的子问题上反复调用,并且这些调用的结果能够组合在一起,提供相对于一次调用来说更大的智力工作量。只要这些智力的工作量能够转化为最终的产品效果上的可见改进,那么就是可行的。单纯的堆砌计算量却无法转化为整体的智力工作量增量和最终价值增量的话,新增的计算量是没有意义的。

总结一下,在这个思路下重要的指标是:每个prompt可以撬动的有效智力工作量,它与每个prompt的LLM调用量正相关。这里的【有效】是指对最终的用户使用价值有可感知的提升。

当然这个方式有一些缺点,系统复杂度增加(但相对于手调的大量prompt的workflow来说还是更低的)、系统LLM推理成本增加、系统延迟时间增加。延迟时间可以靠有数据之后的微调蒸馏来优化,推理成本在过去还是一个不小的问题,但在可见的未来,廉价的高性价LLM是可以满足这种需求的。

3.2、以GraphRAG为例

之前我写文章的时候,还没有很有代表性的例子,而目前正好有了一个例子:GraphRAG

https://github.com/microsoft/graphrag

并不需要研究完GraphRAG的逻辑才能理解本文的思路,这里简单介绍一下:GraphRAG仍然是试图改进RAG的某些场景的效果,大思路是内部通过workflow构建一个知识图谱,来改善RAG的过程。它有几个特点:

  • 【F1】在索引构建阶段需要的LLM调用量比较大,远超大家一般习惯的LLM应用的调用量。

  • 【F2】构建的知识图谱并不是给用户的,它只是作为一个内部中间状态来改进效果。

  • 【F3】对于单次LLM调用结果错误的容忍度更高

F1就是之前所说的,虽然prompt数量并不多,但这些prompt/workflow会在它构建索引的过程中反复调用,撬动的计算量很多,且它们的结果可以被有效地结合在一起。

3.3、放弃对于中间环节完美结果的追求

继续前一节来讲F2和F3。降低workflow开发成本的另一个方式是降低对于单个节点的质量要求,这样就可以降低调优单个节点的成本。但这可行么?

回顾GraphRAG的知识谱图并不展示给用户这一点,如果“一个中间过程的环节并不展示给用户”、“整个流程也不强依赖于每个节点的质量都足够高,可以通过系统层面的冗余设计来取得超过单点能力的结果”,那么确实可以降低这些环节上的质量,只要它们对于最终效果的影响是可接受的。或者说只要最终效果可以接受,就不必纠结于中间环节的质量。

特别是目前人工调优workflow的成本已经不太能接受了,纠结中间的不完美结果似乎也没有太多意义,发现了问题也未必有人力去打磨所有的环节。当然这并不是说打磨中间环节没有意义,只是说在特定条件下不打磨也是可接受的。

进一步来说,不仅没必要让中间环节的输出结果都符合用户或分析人员的要求,实际上也没有必要追求workflow上的每个节点的输出质量都达到开发者的直觉期望。只要最终结果是可接受的,那么中间环节就算看起来很烂也是可以被接受的。优先去验证PMF,能收到钱/拿到价值认可,增加了团队的信念/信心,然后可以再来思考是否需要继续打磨细节。

极端来说,假设中间环节的输出全是LLM输出的一些看似乱码的东西,但只要整体最终结果是符合期望的,就也不是不能接受的。深度学习也是这样,只要结果是有用的,有自己的生态位,那么中间的隐空间表示到底人能不能理解不是那么的重要,能理解更好,不理解也不妨碍它被普遍使用。

不过构建整体流程的人做不到让中间过程输出乱码还能保持最终结果符合预期,系统的设计者总是需要以自己的思路拆解问题,构建一些流程来让不同的子调用的结果能够被大概率地组合为更大的智力工作结果。但这和传统算法的设计有所不同,也许没必要把每个细节都打磨到完全符合设计者的设计。能去改进中间环节固然好,但它不好并不很强的罪过,成本高和没有最终价值才是真罪过。

3.4、总结

从这个角度来说,这种不完美系统的设计工作似乎变得更加玄学了,我们需要按照某种思路进行拆解,但又没必要把所有环节都弄到跟自己的理想完全一致。这就有点像是深度学习中的,组合各种组件构建了一个网络,只要训练之后最终结果是可接受的,那么似乎也没有太多必要深入抠每个组件到底没有学习好。细节优化可以放在未来,从LLM应用的原型构建来说,最终效果好就够了。

我们最在乎的是开发成本、推理成本和效果,这里也跟深度学习有点像,我们可以构建不同规模和结构的网络,它们有着不同的成本和效果,这是一个两目标的优化问题。同样的两目标优化在LLM应用流程上也存在,对于每个应用场景,可能存在多种设计、需要不同的计算量、有着不同的整体效果,在两目标优化的图上占据不同的生态位。

总结一下以上的思路:

  • 提高每个prompt能够撬动的计算量来增加最终有效智力工作量/价值,通过减少prompt数量的方式降低开发成本。

  • 中间环节的结果的质量可能并非关键因素,也可以可以适当降低质量,只要最终结果可以接受就没问题。整个提供也应该增加鲁棒性设计,减少对于单次高准确率LLM调用的需求。

当然并不是说这是最佳的设计思路,只是说新的环境容许了这样一种新的设计思路。

3.5、与自主AI Agent框架的对比

回头看半年前的几个知名的AI Agent框架,它们似乎也符合这2点,但它们现在已经被人抛弃。问题是什么呢?

可能最主要的因素还是这些框架相对于单次LLM调用相比,虽然用少量的prompt撬动了大量的LLM调用,中间环节的过程也不算太好,但它们对于整个过程提供的增量价值十分有限。另外,这些框架大多对每次LLM调用的准确率依赖度极高,这使得它们被迫都要使用最昂贵的模型,且最终准确率收到累计调用次数的影响。

当然通用场景的通用问题解决能力就是很难做的,到目前还做出不来很正常。不过这并不否定在具体环境中能做出来的可能性,GraphRAG就给我们展示了一个这样的例子。不过,我估计GraphRAG大概率仍然接近于演示demo,未来未必会被大量直接采用,不过我们可以基于这种方法论来再设计一些真的可被接受的方案。

如何学习大模型 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%免费

在这里插入图片描述

;