点击链接阅读原文，获取更多技术内容：探索AI时代的应用工程化架构演进，一人公司时代还有多远？-阿里云开发者社区

当代AI来势汹汹，本文从AI的特点、对研发的挑战、AI的应用工程和场景分化等剖析了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执行，执行的结果被填充到这个蓝图中，最终交由大模型得出结果，与一般方案不同，他不需要按步就班的去执行，这是突出“规划”能力的一个很好的方案。

内容剩余60%，完整内容请点击下方链接查看：探索AI时代的应用工程化架构演进，一人公司时代还有多远？-阿里云开发者社区

阿里云开发者社区，千万开发者的选择。百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流，尽在：阿里云开发者社区-云计算社区-阿里云