序言
在当下生成式模型的 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 计算机架构研发，或者不再单一职责，转变为需求设计和开发落地二合一的 “高阶角色”，一人公司时代可能会提前到来。
点击立即免费试用云产品 开启云上实践之旅！
