TL;DR

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

1、前提条件

1.1、高性价比LLM的到来

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

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

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

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

最近3个月没有太多关注这方面的读者请看下我6月的LLM API简报 2024.6 W2 商用LLM API进展简评

可以预见，在未来半年高性价比的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可以有效地提升整个流程的正确率（或符合期望率），但很多场景下大家对于更高准确率的付费意愿并不能覆盖由此带来的研发成本甚至推理成本，更别说在现在所有人都短视和保守的大氛围下。

在 反思GenAI时代的复杂度应对方式【2024Q2】 中我提到，现在对于复杂一些系统的构建能力，看的已经是团队的信念的多少。而现在的团队 要么有钱没信念、要么没钱没信念，总之有足够信念的团队不多。构建不起workflow，很多适合核心原因并不是没钱，而是大家对此没有信念，不信在这上投入能大概率地获得成功。所以无论大小公司、有钱没钱，构建足够复杂和高质量的workflow都是一件不容易的事情。

3、新的思路

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

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

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

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

本节先讨论第一点。通过更少的prompt数量来完成更多的效果提升，这听起来似乎不可能。但如果我们能够通过提升平均每个prompt能够撬动的计算量，那么是有可能完成更多的智力工作，乃至最终提升总产出价值的。我之前在 谈为什么效率场景LLM应用没有爆发【2024Q1】 中提过，效率场景或者追求质量的场景中，目前LLM workflow提供的智力工作量不够多可能是一种主要原因。

什么叫撬动更多的计算量呢？就是能够在一次流程中，反复多次的调用同一个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，未来未必会被大量直接采用，不过我们可以基于这种方法论来再设计一些真的可被接受的方案。

A、结语

A.1、Agent策略框架

本文也属于之前的Agent框架思考系列文，之前的相关文章：

• 反思GenAI时代的复杂度应对方式【2024Q2】

• 团队的信念是支撑前期复杂系统开发的最主要因素

• 2024Q1再谈GenAI原生应用的算法策略壁垒在哪里

• 能产出高质量数据的workflow才是应用层算法策略壁垒

• 2024Q1对自主探索能力Agent设计的思考

• workflow是成功经验的最好的表达方式

• 谈为什么效率场景LLM应用没有爆发【2024Q1】

• 目前LLM应用提供的智力工作量不足是主要因素

• 谈LLM与Agent是否有学习能力【2023Q4】

• 目前的LLM和Agent没有学习能力

• 谈复杂Agent策略框架的设计（2）【2023Q4】

• 目前的自主Agent框架都不靠谱

• Multi Agent策略架构 基础（1）【2023Q4】

• Multi Agent框架有一点用，但不多

• 【2023Q3】LLM-native应用的算法壁垒在哪里 V1.1

• workflow的必要复杂度是应用层的算法策略壁垒

回头来看，我个人在这个大方向的认知还真是有了不小的演进。

虽然我在2023.7的时候就发声说应该考虑做一些LLM调用量/prompt很多的方案，但我也没能想到现在我在介绍一个这样的思路。当时我也没能预见到现在workflow构建的高成本与大家的低耐心、没能预见现在LLM应用层的乏善可陈和落地中遇到的很高的成本门槛和风险担忧，也没有预见到现在就已经开始卷高性价比LLM方案。

Workflow/Agent策略框架的设计思路是依托于底层LLM能力发展和上层的实际需求的，目前这些都仍然是在半年的尺度上在显著变化的。

A.2、廉价LLM时代的框架设计

廉价LLM时代的策略框架设计的方法论的全貌到底是怎么样的我目前也不知道。所以本文也只是【一窥】，仅讨论一些我目前认知到的部分。希望未来我或者LLM应用层的开发者能够总结出一些更具体的套路。

交流与合作

如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，见 联系方式。

本文于2024.7.10首发于微信公众号与知乎。

知乎链接 https://zhuanlan.zhihu.com/p/708143331