多 Agent 系统方案：从 LLM 洞见到实践应用
本文以近期在负责的复杂表格智能问答为切入点，结合大模型的哲学三问（'是谁、从哪里来、到哪里去'），阐述对大模型的理解与判断，以及面向公共云 LLM 的建设模式思考，并分享软件设计 + 模型算法结合的一些研发实践经验。
一、前言
2022 年 11 月，ChatGPT 开启了'大模型+'时代，为整个 AI 软件市场带来了无限商机。据 ARK Invest 预测，到 2030 年左右，AI 软件市场的市场总值将达到 13 万亿美元，其中生成式 AI 的市场总值将达到 1.3 万亿美元左右。近期 Gartner 发布的 2024 中国基础设施战略技术成熟度曲线表明，未来 2-5 年生成式 AI 依然处于期望膨胀期，潜力巨大。
国内外大模型创业公司都在探索 PMF（Product Market Fit）新机会，主要有两大方向：一是基础模型的迭代，追求 AGI；二是大模型创新应用，以新技术驱动产品形态。面向生产力的大模型场景应用更有可能找到落地机会，比如知识问答场景。
在过去的一年多，笔者与多个团队深度合作共创，成功落地了多个大模型的场景建设，如国际奥运大模型、公文写作大模型等。目前主要专注于公共云汽车能源领域的大模型场景。让笔者感触最深的是，软件设计与模型算法的有机结合，是系统成功构建的关键因素之一。
二、背景
在汽车领域，汽车厂商旗下通常会有多个子品牌，不同品牌下有多款车型。面对众多车型，汽车厂商在服务于车主的过程中，长期以来产生了大量的碎片知识，如汽车延长保修、汽车保养等，散落在各种文档中，常见之一就是表格文档（xlsx）。
以汽车保养的表格场景为例，一般我们对表格的认知是数据报表、统计表等结构化内容，但此次的汽车保养表格则复杂得多。一份汽车保养表格中，同时包含了结构化和非结构化的内容，涵盖了汽车保养类别、保养条目、保养的价格、以及一些保养的政策等，内容多样且杂糅。
这类场景的咨询服务，效果不佳且效率非常低下。因此，如何整合这些碎片知识的复杂表格文档，构建智能问答系统，从而为车主提供可用、精准、人性化的问答服务，显得尤为重要。
三、场景分析
显然，汽车保养场景属于问答场景。智能问答系统的构建，目前最耳熟能详的方案是基于知识库的检索增强生成（RAG）。其通用做法是，基于百炼平台构建知识库，选择大模型，搭建 RAG 智能体，再加 Prompt 调优，从而建成一个智能问答系统。
这能满足很多场景下的日常使用，给人以错觉这就是大模型的最好表现，属于 60 分的逻辑，往往忽略了背后的思考和作为建设者的最终目标。笔者认为，作为大模型场景建设落地者，最大化挖掘大模型能力，并优化大型语言模型的工作流程，最终为客户带来极致的技术体验，是技术服务核心目标。这里体现的不仅是一种技术服务思维，更体现了一种研发思维，即匠工精神。
尽管汽车保养的表格复杂、数据多样、杂糅，且格式不统一，但是，从技术实现路线上可以大致分为 4 类。技术路线 1，基于百炼平台构建问答系统，标准化程度高，试错成本、人力投入较低。越往后，标准化程度越低、人力和试错成本越高。项目过程中，我们需要快速搭建、快速验证、不断调优，快速试错。由此可见，得出一个实施原则：面向公共云业务，最大化标准（用好阿里云百炼）、最小化做定开。
基于这一实施原则，抽象出两大核心：模型、平台。围绕模型开展的工作，绕不开 Agent 和 Prompt，因此将其定义为'两大核心、四大要素'，即以模型、平台为核心，以大模型、百炼平台、Agent、Prompt 为四大要素，构建高效、可用的大模型系统实现场景落地。可见，对四大要素理解的深度和广度，将直接影响到构建系统的最终效果。
四、要素 1：大模型——技术驱动产品
1、大模型架构——Decoder-Only Transformer
AI 领域有 3 个技术流派，分别是符号主义、连接主义以及行为主义。连接主义强调模仿人脑神经元结构，通过大量神经元相互连接处理信息。大语言模型（LLM）属于连接主义流派，采用 Transformer 架构。
原生 Transformer 架构中，Encoder（编码器）、Decoder（解码器）是其重要组成部分。基于 Transformer 架构的 LLM，根据编/解码器的组合方式不同，产生了三种不同模式：Encoder-Only 模式、Decoder-Only 模式、以及 Encoder-Decoder 模式。
可以看出，Decoder-Only Transformer 的 LLM 发展最为迅速，已成业界主流。其主要原因在于，相比于其他两种模式，Decoder-Only 模式允许模型通过给定的前文，以自回归方式进行文本生成，即迭代式地将已预测的词加入到先前输入序列中，继续预测下一个词，使得模型更简单、更专注，且在预测下一个词时计算效率更高。
Decoder-Only Transformer 架构，省略了 Encoder 部分，将用户 query 直接传递给解码器进行处理。其推理过程分为 2 个阶段：Prefill 阶段、Decode 阶段。
Prefill 阶段为计算密集型，是用户输入完 query 到生成首个 token 的过程，LLM 处理输入 token 以计算中间状态（Key-Value），用于生成第一个新 token。由于输入的内容已知，且不同 token 的 Key-Value 计算是独立的，从高纬度看，这是一种高度并行化的矩阵 - 矩阵操作，GPU 利用率较高。
Decode 阶段为访存密集型，LLM 自回归地一次生成一个输出 token，直到满足停止条件。过程中，每个顺序输出 token 需要频繁地在 HBM 和 SDRAM 中访问数据，获取之前所有迭代的输出状态（Key-Value），所以无法有效利用 GPU 的并行计算特长，GPU 利用率不足，进而导致了输出阶段成本高。这也是为何大模型的输出价格一般高于输入价格的原因。
