华为大咖说丨大模型不是万能的，如何正确使用大模型？

全文约5206字，阅读约需9分钟

大模型在很多方面有了长足的进步，解决了很多传统规则编码解决不了的问题，但大模型并不是万能的。

各行各业都在探索与LLM的结合应用，但真正用好并产生实际价值的并不多，通常会遇到很多问题：

① 评测时很好，真实场景就不行；
② 稍复杂的场景，效果就很差；
③ 优化不能体系化，优化效果时好时坏；
④ 某些局部智能，但另一部分又很糟糕，导致整体失败 ...

大模型到底行不行？这其中有一个重要原因是，看待和使用LLM的方式是否正确。

未来的AGI（通用人工智能）可能是完美的，但在AGI到来之前，LLM如同所有的方法一样，都有其擅长的和不擅长的领域，如何充分的扬长避短？在实际应用中，发挥LLM的最大价值，用好LLM才是关键。

本文结合实践和探索，从更好的理解LLM能力边界入手，探讨正确使用LLM的一种范式，提供一种思路。（特别声明：由于大模型技术在快速发展，本文是基于 2024 年底的技术现状撰写。）

PART 01 大模型不是万能的（道）

正确的认识大模型，是用好大模型的基础。（如果您对原理不感兴趣的，可直接跳到本章第1小节）

大模型基本原理，是一个黑盒的过程，比如人类从经验中学习总结的过程。关注的是从现象到结果，给予足够多的现象和结果，通过参数建立现象和结果的映射关系（万能近似定理），并基于此能够泛化到新现象上预测产生结果。由此可得，模型从现象和结果中总结掌握了什么样的规律，是否是准确的规律，是不得而知的，是通过外部评测来验证结果。早期的神经网络模型和LLM两者根本性区别在于，LLM能够对上下文信息更好的捕获，以及大规模产生更多泛化能力，进而能够处理更复杂的现象（输入），才让大模型的智能水平得到了根本性提升。

整个模式是基于经验总结，不同于人类的另一种思考模式：白盒模式。所谓白盒模式，先关注的是弄清楚事情内部运作的原理和规律，有了运作原理后再精确的处理新的输入。

题外话：人类的这种白盒思考，本身可能也是一种高级的从现象到结果的总结，只是不断的信息和层级叠加（蒸馏？）产生的高级思维，或许人类学习的方式都只有从现象总结，如马克思所说 “认识源于实践”，此处不展开。

同时，LLM作用在高维空间下。在高维空间中，数据分布更加稀疏，绝大多数预测本质是外推Extrapolation，而非插值Interpolation。LLM在预测方面虽有重大突破，但理论上，依然存在很多局限和挑战。（根据已有数据以及模型（函数）预测未知区域的函数值，预测的点在已有数据范围内就是interpolation（插值），范围外就是extrapolation（外推）。）

基于这些原理，至少反映了LLM 2个特征：

1）从已知预测未知，不能从未知预测未知。

LLM能够很好生成的内容，不是见过相似的，就是和已知信息有着某种内在的联系，具备了一定的泛化性。完全没见过的信息，准确度很低，基本等同于一种盲猜，就像第一次见面猜别人的姓名。比如私域知识里定义的一些规则，是无法直接准确生成的。

2）主基调仍是“鹦鹉学舌”，真正的思考能力仍在突破。

虽然LLM捕获了更多的上下文信息，但仍是一种现象到结果的映射，更多的像一种“口直心快”的反应机制(system1)。而现实中处理一件事，需要关注很多不同渠道的信息，进行综合思考和决策(system2)。不仅要学会知识，还要学会解决问题的思考模式，大模型直接进行综合处理能力仍在突破。

所以，当前LLM并不完美，合理、正确的用好大模型，才能充分激发其潜力和价值。以AI智能辅助编码为例，具体介绍用好LLM的3件事。

1.大模型擅长意图理解，但不擅长具体执行细节

基于对大量公共知识的学习，LLM具备了很强的理解和沟通能力，能够非常好的理解用户的意图。但具体到某个领域中可执行的细节内容，LLM是无法理解和生成的，大模型并不擅长具体的执行细节。

常见很多LLM应用都有一个误区，交给LLM一个任务，从自然语言直接生成私域内最终可执行结果，准确度很低，甚至不可用。

举例来说，以下分别是Office Copilot中下达修改PPT的指令，和在ADC低码平台（一体化低门槛开发平台）中下达页面代码生成的指令。

大模型能够很好理解用户意图的，但生成的最终代码中，需要对office的API非常熟悉，对不同参数有准确的理解和运用，并能够综合运用，但这些是LLM并不擅长的；同样在ADC低码平台中，DSL（DSL是一种专门针对特定问题领域设计的编程语言，可以简化问题的描述和解决方式，提高代码的可读性和维护性。）也是平台自己定义的，DSL的字段和细节属性，大模型完全不理解，没有能力很好的生成，而且一段DSL或API的背后需要大量的信息支撑。

意图理解和执行细节，关注点分离。

很自然的处理方式是，既然LLM不擅长执行细节，那就让LLM能够擅长，常见有：

1）微调大模型，让LLM具备领域API、DSL的生成能力；

2）RAG，将领域知识外挂上去。

但这些方法的难点在于，相比于庞大的私域细节知识，能够真正让LLM准确生成的挑战依然很大，依然有很大的不确定性。一方面有时候需要理解的细节太多，超过了LLM的限制；另一方面，执行细节（如代码）的特点是任何一处细节都有可能导致整个任务失败。

这里提出另一个关键策略：意图理解和执行细节，关注点分离。

AS-IS： 将用户的输入和最终可执行内容的生成，都交给了LLM，LLM同时要完成意图理解和领域下执行细节知识的理解。意图理解是LLM擅长的，但领域的具体执行细节，LLM勉为其难，效果不理想。

TO-BE： LLM只做意图理解，基于意图理解生成一套可以规范化表达意图的中间态DSL，我们称为A-DSL （Aware / Advanced DSL）。A-DSL作为大模型更加友好的中间态语言，为意图理解和执行细节的桥梁。LLM基于意图理解生成A-DSL，再通过翻译器转义成个领域可执行的细节。实现意图理解和执行细节的关注点分离，扬长避短，LLM和传统规则编码协作，实现更高的准确度。

最终效果举例：

可以看出，最终LLM生成的代码（A-DSL）更简洁，从技术实现细节的表述，转变为功能的表述，功能表述是LLM擅长的，充分发挥了LLM的能力，让最终生成更准确。同时更简洁的输出带来推理时延大幅降低，更重要的，通过A-DSL的分层设计，可以突破LLM在复杂问题处理上的上限。

关键是，时刻关注哪些是LLM擅长，哪些是LLM不擅长的，关注点分离，各司其职，而不是全部交给LLM去完成。实际应用中，再叠加必要的大模型微调，RAG等手段，提升LLM的实际落地的综合效果。

2.大模型擅长“单一”任务，不擅长“关注点多”的任务

如前所述，大模型能够捕获大量上下文信息，能够整合一定的信息进行综合输出。但相比于一个真实任务，需要关注的信息量和关注点还是远远不够的。比如一个简单的CURD功能（CURD 是 Create（创建）、Read（读取）、Update（更新）和 Delete（删除）的首字母缩写词，常用于描述数据库操作中的基本功能），需要了解数据库、索引、SQL语法、Java编程语言、HTTP协议、HTML、CSS、JavaScript、RESTful API设计、Spring框架、事务处理、ORM、单元测试、性能、各种安全漏洞等等，还不包括docker、git、IDE等部署开发工具等，也不包括业务知识本身等。常规估计，做好一个简单CURD需要掌握的关注点可能在500+以上。放到普遍编码中，无限制的编码可能在10000+以上的关注点，限制场景和框架下1000+，低码封装后可以在100+关注点。

大模型擅长“单一”任务，但无法一次性直接处理这么多关注点的任务，并且要精确输出，任何细节错误都可能导致任务失败。真实生活中，很多看似简单的任务，都需要大量的上下文和关注点，比如整理一个项目计划表格，要考虑每个需求重要程度，客户紧急程度，人员能力，现有工作冲突，地域，时间节点，风险控制等等，再比如购买一个礼物也需要大量的关注点等。 

特别说明的是，这里的“单一”任务不一定代表简单任务，比如向LLM咨询一个医学问题，本身这件事涉及的关注点并不“单一”，但由于训练过程中，本身就包含了大量医学综合信息。所以这里的“单一”是相对模型学习到的能力而言的，不是以人的视角理解的单一，而是大模型中分开学习的知识，很难综合运用，形成“融会贯通”的复杂能力。

另一个角度，用户希望的智能，恰恰也体现在更少的关注点。把一件原本要做的事，换成文字描述去做，并不一定带来效率的提升；比如把一个字段大小从20调整到40，用文字表达反而没有写代码更快。真正的智能，核心应该体现在关注点的减少，从原本用户需要知道细节，并一步步实现，变为不需要知道细节，自动的完成才是智能。比如做一个蛋糕，用户不知道具体怎么做，他也不需要关注，结果蛋糕做好了，关注点降级才是智能的体现。

当前，大模型并不擅长“关注点多”的任务，或者说能力有限；而我们期望的智能又恰恰是，针对关注点多的任务进行关注点降级，两者的矛盾如何化解呢？

这里提供一种策略：纵向拆解问题，降低关注点。

避免一次性让LLM一杆子到底地处理一个复杂问题，而直接生成结果。

采用纵向拆解问题，类比人类构建复杂系统的思路，通常都先设计架构和骨架，划分区块，再逐步从每个区块是向下拆解打细，分层解决一个复杂问题，这样每层关注点可控，实现关注点降级。从大问题到小问题，从事情的轮廓到细节逐步清晰。而不能横向拆解问题，因为横向拆解只是降低了问题数量，没有降低问题的关注点；降关注点才是关键。

纵向拆解时，具体的分层策略建议：

1）第1层，需求意图层：接受用户原始需求，经过LLM意图理解后，转化生成为功能表述（比如采用前文提到的A-DSL表述等）； 

2）第2...n-1层，业务领域实体层：接受第1层的功能表述，继续拆解为多个有业务含义的实体/模块的操作，根据复杂度情况，有可能拆解为多层；（这里可以参考DDD领域驱动思路，DDD的思想是天生友好LLM的，知识比技术更重要。DDD本文不作展开，这也是降低关注点）

3）第n层，技术对象层：将业务领域实体解释翻译成技术实现，通过调用技术层封装定义的组件/对象/API等，构成对某个领域实体操作的具体实现；这部分以传统规则编码实现为主。底层的技术封装可以大幅度降低关注点，低代码本身就已很好完成了标准化封装。这也是笔者一直认为AI+低码的结合，是一个正确方向的原因。

在这个问题上，相关的常见措施有：COT，任务规划等；包括Agent主要目标也是在逐步拆解问题。无论是那种方法，都需要围绕核心思想开展：拆解问题，降低关注点。随着推理模型的增强，可以更多的依赖LLM自拆解。

让LLM持续只做它擅长的、“单一”的任务，充分发挥LLM能力。

3.大模型不适合做确定性的事

LLM很重要的一个突破，是解决了很多不确定性的事。比如同样的需求可以有不同的表述，模糊的、不清晰的表述都能够被很好的理解，并智能的给出答案。这些是传统基于规则编码很难做到的。

但大模型不适合做确定性的事，所谓确定性的事，就是可以通过传统规则编码做到的事，就不要用LLM来做，因为可能反而不准确。比如明确要修改一个参数，使用一个已封装的组件等。

列举一些是否适合LLM的任务案例：

确定的事和不确定的事分离

一个任务里通常会同时包含不确定性的事，和确定性的事。如果能够很好的拆分处理，让LLM处理其中不确定的部分，让传统编码实现确定的部分，协同配合取得更好的结果。 

以下为一种建议的策略，把一个任务的处理过程分为前处理器和后处理器。

前处理器：主要处理不确定部分，以LLM/向量库等为主，对用户原始诉求，进行意图理解、规范化输入、样本库匹配、Context动态拼接、LLM生成等；所生成的不是最终执行细节和结果，是基于功能的一种表述，如A-DSL。

后处理器：主要处理确定部分，以传统规则编码为主，对前处理器输出的结果进行校验、纠错、补全，并进行解析，翻译，形成最终输出的内容和执行细节。

类似的，function call（函数调用是指通过自然语言接口（NLI）将用户的请求转换为可执行的函数调用，并生成结构化的输出（如JSON对象）） 也是相关的一种综合解决思路，让LLM负责思考和规划指挥，具体确定性的工作交给不同的function工具更好的完成，实现分工、分离。

PART 02 用好大模型的一种范式 （术）

现阶段，正确认识LLM优势和短板，并扬长避短，充分发挥LLM的最大价值，并形成用好LLM的范式。

需反复强调的是，将一个任务从传统方法转换成LLM自然语言对话式实现，不是提效和智能化的关键。因为把一件事用文字描述清楚是一件难度很大甚至要求更高的事情。智能化的关键，是降低了所需要的知识要求，降低需要关注的关注点，屏蔽了大量的细节，才体现出智能化。避免缘木求鱼，本末倒置

结合以上，提供一种正确用好LLM的范式

一种正确用好LLM的范式：

① 意图理解和执行细节分离：

✘ 避免让LLM直接生成领域内执行细节的内容。
✔ 采用一种中间态DSL语言，将意图理解和执行细节进行关注点分离。发挥大模型擅长意图理解的优势。

② 降级关注点：

✘ 避免让LLM一次性处理一个关注点多的复杂问题。
✔ 围绕降低任务关注点的关键目标，纵向拆解复杂问题。从大问题到小问题，从轮廓到细节。

③ 确定性事和不确定事分离：

✘ 避免让LLM做编码可实现的确定性的事。
✔ 让LLM和传统规则编码结合，将不确定的事和确定的事分工互补协作，形成一套前后处理器的工程范式

统一的解题范式，让LLM的使用更体系化，更持续的、稳定的优化LLM应用效果。

PART 03 总结

 本质上，全文只说了一件事：LLM擅长什么就让它做什么，不擅长的就不让它做。无论未来AI如何发展，弥补了哪些短板，扬长避短始终是用好LLM的原则。