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

本文于2023.7.8首发于知乎，根据目前的信息和认知有更新。

TLDR

• LLM-native应用的算法/策略仍然有复杂度的壁垒，但这个壁垒是在不断融化的。

• 系统中包含的prompt模板的数量是一个评价基于LLM程序复杂度的有效指标。
  

0、前言

本文不止适用于LLM-native应用，也适用于所有基于LLM能力构建的上层策略应用。

本质上本文讨论的不是狭义的 算法壁垒，而是更为广义的 策略/算法 的壁垒，为了避免误解，本文以下使用【策略】来指代 策略与算法。

1、策略壁垒的缺失？

ChatGPT API普及之后，赋能了很多领域很多之前并不做算法或者策略的人，使得他们能够快速建立一个功能“强大”的系统。这类项目的特点是：核心策略逻辑较少，主要靠调用LLM API实现。

大家几乎都在用同样的LLM API，prompt看起来也不是秘传配料那样不可模仿。甚至基于自然语言的底层LLM本身都是可被低成本替换的。这让大家思考这类应用的技术核心壁垒是什么？

而大部的技术人的直观想法是，主要壁垒已经不再是之前我们认为的那些核心算法性的壁垒。前一阵朱啸虎与傅盛的朋友圈争论也体现了这一点。

相对于前LLM时代，我也承认：策略性的壁垒确实降低了。不少人开始思考核心壁垒是否已经转移到了数据、品牌、生态、工程性技术等方面。本文并不否认这些。

本文仍然专注于分析：策略性的壁垒是否还存在，以及是什么。

2、复杂度壁垒

本文的观点是：策略壁垒仍然是可以存在的，这种壁垒我称之为“复杂度壁垒”。

目前光靠LLM并不能简单解决所有的问题，因为：

• 在实际场景中，经常需要有大量的“业务逻辑”、领域知识，这些内容LLM并不都知道。

• LLM自身有很明显的策略可靠性不足的问题，很多事情LLM（有可能）可以做，但不能保证都能做对。需要上层的策略来对此进行识别和再处理。

这两方面的解决方式都是需要在LLM API之上堆砌更多的业务逻辑或策略性的代码，例如：

• 把大任务拆解成小任务

• 按照业务逻辑的流程来安排LLM API调用并传递必要的信息

• 识别LLM API返回的结果是否正确

• 当LLM API结果不对时，如何进行处理

• ……

这其实就和传统大型系统类似了。在同样的硬件上，Office的壁垒在哪里？在于它庞大的代码量，或者说“必要的复杂度”足够大。

那么基于同样LLM API的LLM-native应用也是一样的，只要堆砌的“必要复杂度”足够大，就也足以成为壁垒。

这里需要简单讨论一下何谓【必要】，选用【必要】这个词是为了体现“在同等功能下最简单”的意思。此外我们还需要注意到，对于相同的场景，产品功能的增加和效果的改善是边际收益递减的。一般的目标应该是：用更低的成本堆砌出用户可感知的能力提升，这往往意味着整个系统的“必要复杂度”提升。而我们方案的实际复杂度不应该高过这个“必要复杂度”太多，特别是在底层技术能力发生变化之后。

3、本文场景下的 复杂度的度量

精确的度量系统的复杂度是十分困难的，就算是在实用意义上能够较为准确的度量也肯定是较为繁琐的。

为了方便大家对系统进行分析，这里给一个比较粗糙的度量指标：系统中包含的prompt模板的数量。

当我们讨论复杂系统的时候，经常要区分系统是否是可以被解耦的，也就是说是否是一个真正的复杂系统。这里也是类似的，我们可以把很多业务功能组装在一起来低成本的堆砌出一个较大的prompt模板数量。但你的追赶者也可以通过把系统按功能分解开来并行的逐个击破。

3.1、度量指标的直观性

虽然这是一个粗糙的指标，但我们还可以低成本地改进一下。

考虑：复杂度10的系统 vs 复杂度 100的系统，还有复杂度 300的系统 和复杂度500的系统。后者的gap大于前者么？可能并不是。

因为垒prompt模板的成本不是线性的，长期来看是次线性的。所以最好对这个指标做一些非线性变换来体现出这个方面。这里使用 Sqrt(prompt模板数量) 会更好一些。

为了方便大家引用与讨论，给这个指标一个名字【孔式Agent策略实现复杂度指标】。

4、如何构建壁垒

自从本文7月初写作以来，发现很多人仍然不理解怎么可能会构建出含有1000个prompt模板的策略系统。

虽然我们经常可以通过将一个复杂的prompt拆解为多个简单任务的prompt来提升准确率，但光靠这样也很难事先把业务流程拆分为1000个部分。

实际上想要构建一个高准确率的策略系统时，不光要拆分流程，还需要对于每次LLM返回的结果进行尽可能校验，发现那些能够被自动化发现的问题，并对于各种情况进行应对处理。实际上这种LLM失败情况的处理流程引入的代码量才是大头，这其中有多少还能够使用LLM进行处理与具体场景有关。虽然这些代码的被调用概率不大，但每个流程都能够提升一点全系统的准确率。这是一个聚沙成塔的过程。

以及现在各种XoT的框架及其场景特化实现会导致需要的LLM调用量和prompt模板数量进一步增加。

我后续会考虑专门撰文进一步讨论这个问题。

5、壁垒会较快的融化

与很多已有的领域不同，LLM领域的基础能力正在快速发展。

所以当LLM基础能力发生大幅提升时，完成同样功能的系统所需要的必要复杂度就会下降。造成壁垒的降低，追赶者的追赶成本降低。同时领先者还要及时的优化系统，要不然可能会被自己系统更高的复杂度带来的维护成本拖慢。

举个例子，可能一个领先者已经构建了一个含有1000个prompt的复杂策略流程来解决某个业务问题。但某次LLM能力大提升后，现在只需要300个prompt的策略系统就够了。构建含有1000个prompt的策略系统可能会让追赶者望而却步，但300个prompt的系统的构建成本看起来就没有那么贵了。

但这个融化我认为并不是无限的，我不认为一个含有1000个prompt的策略流程能够最后只用1个prompt就能够完成，从1000个降低到500个、300个是可能的，但即使在较长的时间（3年之内）我也不能为能融化到只有10个的程度。

这个融化比其他技术领域快的问题在LLM发展速度明显放缓之前应该都会存在。

这也驱使这系统的策略架构师看的更远，更早的为未来的技术基础能力进行预判、设计与储备。

6、已经出现的能力提升案例

目前我已经看到了几个对上层策略生态产生足够大撼动效果的LLM能力提升：

• 更长的Context window能力，直到大部分场景都基本够用。

• LLM的function calling能力。

• OpenAI Chat API的System message相对于传统prompt的“对LLM输出”的更强的控制能力。

这3个能力的提升都会造成上层策略的必要复杂度明显下降。

目前第一梯队的LLM API和开源方案中，这3个方面的首次提升几乎都是在OpenAI 0613的那一次更新中一起发布的，这就更加触动我了。

交流与合作

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

希望留言可以到知乎对应文章下留言。