探索AI时代的应用工程化架构演进，一人公司时代还有多远?

序言

在当下生成式模型的AI时代，了解和使用AI相关技术是前后端研发同学迟早要面对的事。

所有产品都值得用AI去重新做一遍。其根本原因在于当下AI的形态即生成式模型是通过AI辅助来改变和创造新的产品形态，而不是像以往的技术一样只是对现有产品形态的补充。

简单来说，产品研发同学可以做的事情更多了。

一、当代AI的特点

当代AI来势汹汹，具备了通用的面向不同领域甚至全模式的强大推理能力，各类理论实践也在这两年爆炸式增长一时洛阳纸贵，大家对当代AI的了解基本在一个起跑线上，这也是当代AI魅力十足的重要原因之一。

对于AI，已有大量的研究表明，人的意识是非算法的，从哥德尔不完备定理到图灵不可计算问题都已经证实了基于图灵机的人工智能，也就是当代基于语言模型的预训练大模型 AI，是无法建立“自我”这个概念的。

因此当代AI仍然是以图灵理论架构为支撑，解决的仍然是图灵可计算问题，因此仍然需要一个良好可持续的应用架构去约束、引导并管理他。

二、对研发的挑战

回到现实，前端、后端等研发同学现有的经验和知识在短时间内还无法跨越这个门槛。而且如大模型算法、训练推理加速、异构计算等等也不是前后端研发同学的领域和优势。

但从最近大量涌现的AIGC相关实践文章，可以看到很多实践者也并非算法同学，这也说明前后端研发同学完全是可以做到的。也就是说只是基于现有大模型去做应用的门槛还是可以跨越的。

三、AI应用工程

当前所谓面向AI开发是向大模型不断输入Prompts，在对上下文 / 语境的控制下推理并得到我们期望结果的过程。

整个推理过程的效率以及结果的质量，除了大模型稳定性这个大前提外，最大的因素还在于我们的实践经验，也就是向AI提问或引导AI的技术。

想象下我们面前的是人而不是AI，那应该如何通过对话去建立语境产生引导，使对方满足我们的需求，即便这个需求是不合理的。有一本书《The Art of Deception》专门为这种场景提出了所谓社工学（Social Engineering）概念。

同样的，与之对应的适用于AI的则是当下热门的提示词工程（Prompts Engineering），之前就有人试过让ChatGPT扮演奶奶给孙子讲关于Windows激活码的故事得到了真正可用的MAK KEY。而这种类似人类社工学（Social Engineering）的提示词工程（Prompts Engineering）让AI解决需求的过程完全颠覆了传统编程常识。

四、AI场景分化

区别于AIGC内容生成这样笼统的概念，AI需要在不同场景分化为不同的特性，以下是比较典型的三类智能化场景：

4.1 知识密集型

与传统知识类场景不同，在AI时代我们还可以有知识摘要、提取、总结、分类，以及内容加工转换等等场景[12]。

比如，将知识结构化，转化为图谱（如脑图、流程图、架构图等等），细节内容补充（如增加示例、注释）等等。

4.2 交互密集型

如：角色扮演、社交辅助、场景顾问、辅助决策、办公办文综合协调等等强调大模型扮演不同角色的人机交互类辅助场景[15]。

4.3 文本/代码型

除了大段非结构文本生成，还有在低代码、无代码、混合研发场景中，与代码生成、代码测试，代码转译、代码评审等与编码相关的专业领域[15]。

可见我们面临的智能化场景问题是比较复杂的，很难通过人类预先思考固化去解决这种千变万化的需求，因为这些场景的自由度太大了。与一般编程语言的区区十几个关键词相比，人类思维是自由的难以约束的，这种情况下的将口语化的Prompts用在AI应用上想要解决复杂问题，这近乎是不可控的。

因此，如何将AI应用工程化为可控的，解决当下的大模型幻觉、漂移等问题，这是非常值得推敲也是我们讨论的核心问题。我们有必要引入新的理论指导产生新的架构去解决这些问题。

五、推理能力

下面将以业界对大模型的典型算法以及实践架构进行说明：

5.1 基础推理

我们使用大模型的核心能力就是推理，下面介绍几种业界知名的AI推理方案。

5.1.1 Standard IO

当没有推理过程时，我们向大模型发问他会直接给出答案，这种0过程的推理被称为Standard IO。在大部分情况下Standard IO都是不能一步到位解决我们问题的，需要我们自行甄别以及进一步引导，这几乎无法用于复杂任务，所以一般被作为各类优化实验中的对比参照。

5.1.2 Chain of Thought (CoT)

在2022年，著名的Chain of thought(CoT) [11] 论文的发表为AI对复杂任务的处理起了关键作用，即将一个复杂任务拆分成多个可管理的简单子任务，让大模型一步步地去思考，使每个小任务的提示和推理都是可控的。

可以简单理解为，“一个问题，不直接让大模型给出结果，而是让大模型一步一步的推理产生推论，并最终给出结果”。这个技术常常在Zero-Shot/Few-Shot下取得的结果很好。CoT已经是AI应用工程里的必备范式了，就好像面向过程的开发模式一样，接下来我们会一直使用他。

5.2 Chains架构

到这里不得不提一下Chains[24]，Chains是著名的大模型应用开发框架Langchain提供的一个模块，名如其义，chains的架构可以理解为是CoT的落地及延伸，从最基础的LLMChain再到常见场景的：APIChain、Retrieval QAChain、SQL Chain等等：

可以看到，在Chains架构中，每一个从Prompt到Answer的过程，都被标准化为不同类型的LLMChain。

整个需求从提出到结果的具体流程则被抽象成多个LLMChain的串联，在表现形式上非常像我们熟知的结构化以及函数式编程。

这是一个好消息，如果说Prompts和Answer是水和土壤，有了CoT的理论指导加上Chains的架构就好像开渠造河，将原本由AI随意发散而不可控的推理过程固化到了Chain和Chain的连接上，让一切都回归到我们认知中流程应有的样子。

但这真的是未来的AI应用开发吗？Chains这种依赖人脑思考并固化推理过程的做法就是AI的全部吗？

说到这里，可以思考一个问题：

在AI领域中我们是否用AI这块金子做锄头，我们解决需求的方式是锄地吗？在你的直觉中是否认为AI的能力和用法不仅仅如此，这是否是传统架构或者编程范式限制了我们的想象力？

5.3 更好的推理

5.3.1 CoT Self-Consistency(SC)

2023年5月，SelfCheckGPT[7] 论文中提到一种称为Self-Consistency的机制为幻觉检测作出了重要贡献，可以简单理解为“一个问题，让多个人参与多步思考和回答，最终由另一个人去评分，选出一个最佳答案。”

为一个问题一次性生成多个CoT，并为每个CoT的推论投票，最终得到最接近结果的推论，投票的是一个评价函数，常用的是BERT Score或n-gram。

5.3.2 Tree of Thought (ToT)

还是在今年，Tree of Thoughts（简称ToT）论文[10]发表。如果说CoT是一条链，那么ToT是由多条CoT链构成的一棵树，ToT揭示了AI是可以通过推理决策过程自主延伸的，这是一个重大的突破。

CoT强调的是任务分解为子任务的过程，而ToT则强调了分解任务就是生成多个思考过程，最终整个ToT会形成一个思维树结构，这样我们可以方便的将复杂问题到结果的思维路径作为Tree这样的经典数据结构，使用广度优先(BFS)或深度优先(DFS)查找来解决一个复杂问题，其中思维路径也就是CoT的每个推论状态则由前面提到的Self-Consistency或者其它等更先进方式去评估。

通过这种方式形成的以大模型自我推理决策的Tree结构是基于AI的场景下钻和逻辑自洽来完成的，简单来说，它替代了之前人类要做的关于理解、分析、执行、验证的整个过程在反复推演直到得出正确结果的整个过程。

六、增强语言模型 (ALM)

说到这里，我们已经拥有了有限范围内的自动推理和幻觉识别能力了，但大模型的潜力还不止这些。图灵奖的Yann LeCun（杨立昆）在2023年年初发表的论文里提到了增强语言模型Augmented Language Model (ALM)这个概念，提到了关于ALM的三个部分：

• 推理：将潜在复杂任务分解为简单子任务，子任务是可以用语言模型自身能解决或者调用其他工具可解决。
• 行为：ALM调用的工具会对虚拟或者真实世界产生影响并观测到结果。
• 工具：语言模型通过规则或者特殊token调用外部模块的能力，包括检索外部信息的检索系统，或者可以调用机器手臂的工具等。

当下我们能使用的大模型的上下文长度都太小了，无法跟上应用规模的扩增，因此大模型应当有从外部获取数据或者影响外部来扩充上下文的能力，这里的这个外部我们称作为环境。

比如“大模型操作机械手从桌上拿起了一杯咖啡”[16]，对于这个Act来说Tools是机械手，Action是拿起，Action Input是桌上的咖啡，而"咖啡在机械手中”，“桌上没有咖啡了”则是Observation[16]。

图中这个WebGPT[17] 的示例非常像gpt版bing，他是一个比较纯粹的Act类大模型，向WebGPT提出Question时，WebGPT会向Web搜索并给出建议结果，用户可以排序过滤这些结果后，再由WebGPT加工生成Answer。

ReAct [2][12]

之前，Acting和Reasoning一直是分开玩的，即使做在一起也并非以架构思维去看待，在2022年10月，ReAct的提出，最终Reasoning和Acting被连接在一起，并已经成为当下最能打的事实上的标准。那么对于这个架构，应用工程化的实践是怎么样的呢？

七、Agents架构

自今年4月的AutoGPT初始版本惊艳面世起就迅速在AI应用圈子传的火热，其一原因是AutoGPT的表现似乎更加贴近我们对AI应用架构的向往：

对于AutoGPT，我们只需要给他设定一个需求目标并授予他资源以及向资源交互的能力，再提供一组限制他行为的规则，那么他就可以通过“自问自答”的方式逐渐接近目标，再借助对结果的评估，最终完成需求。

很典型的，与Chains依赖人脑思考并固化推理过程的做法不同，他似乎在让AI自我启发的产生推理过程。相比chains架构，AutoGPT的Reasoing、Acting过程都是自动的，在实践上否定了人类在Prompts工程上的优势。

但这种未经修饰的原始自问自答的方式虽然可以帮助我们解决一些复杂的问题，但其推理决策能力相比人脑思考并固化推理决策过程的方式低效太多，具体表现在解决现实世界决策任务方面的有效性和灵活性不足。其参与现实世界的能力有限以及缺乏基准导致了这些不确定性。因此还需要更多的优化才能接近我们对AI应用架构的理想设计。

业界也早就注意到了推理决策过程在应用架构中的重要性，并为Auto-GPT类似应用做有效性和灵活性的基准考量。从LangChain Agents 还有最近的 huggingface 公布的还在试验阶段的 Transformers Agent，还有游戏开发领域的 Unity ML-Agents 中，我学习到了当下阶段按场景分化的更加完善的AI应用架构即Agents架构：

Agents [13] [24]

一个典型的Agents架构包括有以下部件：

7.1 Agent

一个调优的专用于推理与动作（reasoning and acting）的大模型，他的核心能力是规划任务和反思\持续完善，需要有强大的推理决策能力。

7.1.1 任务规划

任务规划：将大型任务分解为更小的可被管理的子目标，这样就可以高效的执行复杂任务。

XoT & ReWOO [4]

之前分享推理时提到的XoT（CoT、Cot-SC、ToT）都是比较典型的。另外介绍ReWOO，这也是一个基于计划的方案，思路是，当问题被提出时，制定出解决这个问题的各个Plan，并把Plan的结果留空（称为蓝图），Plan作为一个个的Act交由Worker执行，执行的结果被填充到这个蓝图中，最终交由大模型得出结果，与一般方案不同，他不需要按步就班的去执行，这是突出“规划”能力的一个很好的方案。

7.1.2 反思和持续完善

再是反思和持续完善，简单来说就是为大模型提供改进方案，帮助它从之前的错误中去学习，以更好的完成将来的任务。

ART[6] & Reflexion[15] [8]

拿ART来说，这是一个需要监督的方案，可以将发生过的推理过程沉淀下来，并在将来召回再使用。过程可以描述为：一个Task Library存放了多种类型任务的CoT，当向ART实例提问时，会从TaskLibrary中找到最适合的Task案例与用户的问题一起向大模型提问，最终结果由人脑评审并修正，结果会持久化到TaskLibrary。

而右边提到的Reflexion则将人脑部分换成了语言模型，转换成了由大模型自我学习优化自身行为，通过尝试、错误和自我反思来解决决策、编程和推理任务的架构。

在业界中比较优秀的案例有ReAct、BabyAGI等等，而ReAct是当下的事实标准，影响力深远。而OpenAI也在最近公布的Function Call中提供了基于GPT3.5 turbo \ 4.0的调优规划模型(0613版)。

7.2 Memory

memory包括Context和History[13]。

7.2.1 Context

语境上下文，这个我们比较熟悉了，类似人脑的STM(Short-term memory 短期记忆)，为Agent提供上下文能力，当下大模型的提示词工程化就是基于上下文的。

7.2.2 History

回忆，类似人脑的LTM(Long-term memory 长期记忆），为Agent提供了存储和召回关联数据的能力。

RAG[9] [14] & FLARE [8]

像WebGPT一样检索数据就是非常常见的场景，区别于传统的内容检索，我们也有一些通过大模型增强检索的方案，如：RAG、FLARE等。

在实践中通常选择支持快速最大内积搜索（MIPS）的近似最近邻 (ANN) 算法数据库与这些方案配套，这块有很多向量数据库可供选择了，也是当下市场上的热门领域，不过多阐述，有兴趣的同学可以了解下阿里云的基于Tail的VectorDB，以及云原生向量数据仓库AnalyticDB PostgreSQL版，这里就不详细介绍了。

7.3 Tools

一组工具集或者Agent可以利用的所有外部资源，这是Agent可调用、可执行的能力，它既可以是一个函数、api，还可以是其它任何大模型，包括另一个Agent应用等等。[13]

ChatGPT的插件以及OpenAI API Function Calls都是Tools应用范畴的最佳案例。

当下适用于互联网的常用思路是提供不同领域的api以及这些api的说明用法文档，由Agent的推理去判断需要使用的api在Tools中是否存在，这是个不断查阅、调用、证实的过程：

API Bank: Augment Tool[3]

API Bank是一个Benchmark工具，在他的论文里为我们提供了一个可行的API调用思路：

• Step1. 向Agent提供API Manual Agent可以在它各个规划任务中，使用关键词去API Manual中检索并总结出所需API用法，用法说明可以按Prompts Engineering提出的方案，利用Few-Shot或者Zero-Shot CoT去引导Agent。
• Step2. 向Agent提供API和输入检查器 当Agent已经掌握API的用法后，Agent可以生成API所需参数，并调用API获取结果，这个过程需要不断的检查输入的参数是否正确，以及评估输出的结果是否符合预期。

八、对未来的思考

相比Chains，Agents真正的发挥了AI的潜力，也是即将开始流行的先进架构。在我对Agents的理解中，它更像一个图灵机的实现架构而不是我们平时讨论的应用层架构。

我们回忆一下图灵理论架构为支撑的冯诺依曼架构或者近似的哈佛架构。

一个事实是，在冯诺依曼架构或者哈佛架构设备的实际开发中，我们会去关心如何使用相应协议去寻址去读写总线操作不同设备，如UART、I2C、SPI总线协议，这都是我们要学习掌握的，但我们基本不会关心CPU中的CU、ALU等单元。

另一个事实是，PC CPU内部是多总线的哈佛架构，而在CPU外又是基于单一总线的冯诺依曼架构，而片上系统（SOC）又会在不同场景DSP、ARM等进一步集成与高速运算相关的部件。

计算机架构这样求同存异的继续发展下去，将这些单元与高速存储及总线等作为抽象概念去进一步封装。而AI应用也是类似的，Agent会将相关的规划反思改进能力不断的作为自身的核心能力封装。

因此，对于未来的AI应用极有可能不是在传统计算机上运行的程序，而是标准化的需求，在以规划能力专精的Agent 大模型作为CPU的AI计算机虚拟实例上直接运行的，而我们今天所谈论的应用架构，也会沉积到底层转变为AI计算机的核心架构。

AI计算机中以规划决策专精的Agent 大模型将会以规划决策能力的评估(Benchmark)取代传统以核心数、频率GHz为标准的计算单元评估体系，而AI计算机依赖的外围设备即Tools也会在不同的专业领域中更加深入以提供更专业的执行能力。

最终AI计算机将图灵完备，通过AI的自举将迭代产物从工程领域提升到工业领域。

而AI厂商也将从当下以MetaGPT、AgentVerse等Multi-Agents方案转变为对AI计算机以及相关集群或其它整合方案厂商，技术人员可能成为AI计算机架构研发，或者不再单一职责，转变为需求设计和开发落地二合一的“高阶角色”，一人公司时代可能会提前到来。

作者｜偏左

点击立即免费试用云产品 开启云上实践之旅！

原文链接

本文为阿里云原创内容，未经允许不得转载。