TLDR

• 本文希望回答一个问题：为什么目前效率场景的LLM应用在用户看来都很鸡肋，没有到达付费意愿线。

• 简略的答案是：大部分文本模态的应用提供的智力增量不够，需要至少100次96%准确率的LLM调用 或者 预置了领域知识的workflow/专家知识才行。

1、从与“陌生人”沟通说起

为了让读者更容易理解本文的视角，我们首先考虑与陌生人沟通的情况，这种情况与用户与Agent沟通是相似的。

当我们与陌生人沟通时，“获得了一个好的沟通体验，下次还愿意与他沟通”一般可以分类到下面几种情况：（下文中的【自己】指代第一人称【我】）

• 对方提供了很好的情绪价值，未必是对方故意的。

• 对方提供了自己需要的信息，甚至直接的世俗价值。

• 对方是一个领域专家，使用他的经验解决了自己关注的一个问题，或者是把他的解决思路教给了自己。

• 对方并非是专家，但思维很敏捷、视野较宽，能够在聊天中根据得到的信息随机应变，进行现场推演，让自己看到了自己未曾设想的思路/解决方案，并且自己觉得这些思路没那么不靠谱。

情绪价值目前不被视做效率场景的核心目标，提供信息可以纳入到智能搜索范围。那么剩下的两点从技术实现上来说，可以描述为：

• 对方有适合自己面对的问题/任务 的 经验/workflow，能够大概率地解决自己的问题。

• 对方未必很聪明或者思维很敏捷，他的workflow也并非聊天中现场想出来的，更多是之前的经验或者是经验的少量组合。

• 此时的核心价值是他“之前就持有”的workflow，应用这个workflow可能未必需要很复杂或者很高的推理成本。

• 对方并没有超过自己的经验/workflow，获得信息与自己接近，但进行了大量的思考工作（LLM推理），让结果变得显著。

• AI下棋是类似这种的情况，AI能够基于当前局面探索几步，并对于每个路径的剩余局面有预判，从中选择出较好的【行动】作为输出。AI并没有存储当前局面下的最优workflow，但它通过暴力探索获得了相对不错的方案。

• 在解决问题上也是类似的，Agent可以在内部尝试各种解决方案，最终交付给用户一个可靠性较高的方案作为结果。这时候需要Agent在内部进行大量知识型工作，包括推理或信息处理。

• 目前的智能检索是最简单的例子，在一次请求中，相当于LLM和其他模型并行或事先处理了大量的信息，交付过滤结果。

• 在多步的推理决策等场景下，能够在基于当前情况在思考中探索多种方案，并能选择出较好的方案交给用户。

简单来说也就是：

• 要么预置专家知识workflow，直接调用即可大概率解决问题。

• 靠暴力的计算（知识工作）来给出当前问题的较优方案。

2、专家知识

从直接解决问题的角度上来说，提取专家知识/workflow是最直接的方案，特别是很多专家知识的解决方案执行未必需要很高的大模型推理成本。独立求解一个问题难，但抄答案，抄答案的思路容易。

很多人能认识到提取专家知识的重要性，但现实很骨感。到目前为止“专家知识的提取过程”本身的成本很高已经是共识。

究其原因，大致有：

• 领域专家不愿意真心传授。教会徒弟饿死师傅。

• 传授成本太高：领域专家并不擅长传授，或workflow构建者与领域专家的认知差别过大导致沟通成本高，或领域专家的时间不够或时间成本太高。

• 领域专家的输出不是文字或能方便量化的方式，导致建模/学习困难，例如动作、绘画、气味、模糊不清的感觉。

• 领域专家只能传授原有流程，但如何依托于新方案构建合适的新流程是需要探索的，这需要跨界2方面的能力，人力成本高。

• 目前的新技术不足以满足原有流程的需求（即使在重新设计流程的情况下），新流程目前并没有能打通的方案。

目前“把领域专家的知识从他的大脑中提取出来，并固化为可执行的workflow”还是一个无法自动化的事情，很难低成本水平扩展。

不少人希望能够构建一个直接让领域专家可用的Agent平台来让他们自己调试和迭代，但这样的平台要能实现这种目标并不容易，具体讨论参见谈Agent构建平台的设计【2023H2】

3、堆砌足够的智力工作

第2节是老生常谈，而本节是很少有人提到的视角，即：在没有领域知识的时候，通过在单次使用中堆砌足够的智力工作来提升交付结果的价值。一个能给人直观感受的描述是：单次用户请求中，需要100次成功率96%+的等效LLM调用。

为什么说“成功率96%+”而不是说“GPT4级别”的LLM模型？

• GPT4是更常使用的说法，但workflow/推理环节中不少环节是可以在积累数据后转化为小模型的微调来降低成本的，所以很难说某某任务GPT3.5就不行，对于一些很难的步骤也很难说GPT4就足够好。

• 相对来说使用成功率才是一个更面向结果的指标，既然是堆砌智力工作，那么就需要一定的可靠性，不可靠的推理放在整体流程中可能会直接破坏整个结果，造成一颗老鼠屎坏了一锅汤的效果。

• 提成成功率未必仅靠LLM调用，某些环节可以有低成本的错误检测方式，可以通过发现错误时候重试来降低对于模型的要求，此时仍然能够满足整体流程的需求。（只是牺牲了延时）

• 这里的96%是指大概25次能接受犯错1次，是一个可以用于分析各个领域的默认值。一些高准确场景需要更高的要求。

这里的100次是个概数，现在的很多应用连10次都没有达到，在包含的领域知识不足时，用户的体验就会使：提供的智力价值有限，很鸡肋，不愿意付钱。也就是说好像自己不花钱，稍微想一下也能做，没到要花钱的买服务的程度。这方面海外的付费意愿高一点，能接受的最低智力价值更低一点，但面对的问题是类似的。

3.1、延迟问题

很多开发者不采用更多次LLM调用或者更复杂流程的一个原因是用户不能接受太高的响应延迟。这确实是人性特点之一。在实际人与人对话中，虽然人能对对面的人的反应时间有更多耐心，但也只有思维敏捷的人才能做到在不熟悉的领域快速提供足够的智力价值。这个问题就是很难，无论是对于现在的Agent还是人来说。

好在Agent并非只有一个大脑，如果workflow中有足够可以并行的部分，是可以并行启动大量LLM推理的，智能检索类场景就是最典型的例子，不同文档的检索之间的相互依赖较弱，比较容易发挥计算机系统可以并行计算的特点，特别是在有云化的LLM推理算力资源时。

但不少场景workflow就是很长，传统方式延迟较大，这会是难点，也是未来算法技术团队驾驭复杂workflow能力的主要领域之一。此处并非本文的主题，仅指出2点：

• 在交互上进行设计，给用户更多状态展示，增加耐心，详细讨论见： LLM-native应用的算法壁垒在哪里 【2023Q3】

• 在上游环节完成之前就进行预先的投机执行，以更多的计算成本换更低延迟。这会导致计算流程明显复杂，这方面这里先不展开。展望LLM的流式输入增量计算能力 V2【2024Q1】中讨论了在LLM支持的情况，但即使LLM不支持流式增量计算也可以在workflow上进行投机执行。

4、总结

上述两种思路并非互斥的，可以联合使用。

现在的LLM应用大多两边都不好，所以导致能够提供的智力价值较低，对于用户来说价值不够高。不像是文生图那样，大部分用户不会画图，即使专业画师也无法短时间内快速出图，所以文生图方向大模型产品的价值用户更容易感知和付费。

2023年文本模态这边没有出现大家期望的那种事先成本不是特别高、但受众很大的Super App的原因之一应该就是这点：提供的智力价值不够，无论是通过事先预置还是执行中探索提供的。

5、技术展望

除了延时之外，堆砌大量LLM调用的另一个问题是LLM推理成本/API费用。目前LLM速度还较慢，推理成本还较高，所以只能在少数高价值场景才能使用这种方式。

但目前来看，2024-2025年的LLM推理成本和延时都会显著降低。

• 2023.10月之后，OpenAI以外的商用LLM API能力正在快速发展，到目前已经有接近于GPT4能力的模型出现了。随着技术的进一步优化，整体模型的调用成本、需要的参数量等会有所优化。

• 已经可预见硬件成本也在显著降低，目前AMD的发力速度很快，MI300等卡的计划定价显著低于NVidia，其他定制计算芯片也都正在路上。硬件方面提升导致的推理成本下降大概是未来2年贡献最大的。

所以虽然现在大部分workflow很难使用100次级别的LLM调用，但在我来看已经可以考虑为此方向进行设计和储备了。

附录A、关于调用次数计数的一些细节讨论

各种XoT/MultiAgent方案中，其实调用次数都是比较明确的。但CoT除外，且CoT还有很多用法，不能一概而论。虽然目前只有投资人和刚入行文本模态的人才把CoT挂在嘴边，但它在本文的场景下有时候并不能当成1次调用，所以增加本节简单讨论。

它可以用于连续的执行串行的workflow，但一般会以牺牲准确率为代价。在追求准确率的场景下更建议把多个步骤以多次LLM调用来事先，方便中间插入错误检查逻辑。这种场景下使用的1次CoT可以对应到多次的LLM调用。

CoT也可以用于降低问题的难度，来让较低能力的LLM也能提升准确率。这时候它只是一种优化prompt的手段，仍然建议只算成1次LLM调用。

交流与合作

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

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

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

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