针对汽车保养场景下复杂表格文档碎片化及非结构化数据导致的智能问答效果不佳问题，提出基于多 Agent 系统的解决方案。通过梳理大模型架构与“变与不变”的思考，确立以模型、平台为核心，Agent、Prompt 为要素的实施原则。方案采用文档解析（大模型版）+ 百炼组合 RAG 进行可行性验证，发现准确率不足后，引入多智能体架构，利用车型改写、意图识别、Serverless 价格查询插件等工程化手段优化链路。最终实现离线数据处理与在线 Query 路由增强，准确率达 93.8%，验证了分而治之与标准化构建模式在公共云 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 为四大要素，构建高效、可用的大模型系统实现场景落地。可见，对四大要素理解的深度和广度，将直接影响到构建系统的最终效果。
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 利用率不足，进而导致了输出阶段成本高。这也是为何大模型的输出价格一般高于输入价格的原因。
回顾历年政府工作报告，从 2015 年提出的'互联网+'到 2019 年提出的'智能+'，再到今年首次提出的'人工智能+'，AI 被提升到了前所未有的高度。笔者认为，我们正在经历的是'大模型+'的时代。
大模型、大数据、大算力这三驾马车的系统性已经成型，加速地驱动着各个产业升级。然而，'大模型+'时代下，从服务于千行百业的场景落地角度看，什么是'变'的、什么又是'不变'的，来确保对客户服务的技术判断力和技术服务的领先力？
现在业界普遍认为，AI 技术的发展变化飞快。其核心可以从两个维度来看。
纵深上看，大模型的推理能力不断增强，正在从系统 1 思维（即快速、直觉、自动、易出错的思维模式）朝着系统 2 思维（即刻意、缓慢、有意识且更可靠的推理）进化与演进。比如刚发布不久的 OpenAI o1，第一次证明了 LLM 具有慢思考能力。业界较为一致的观点是，o1 通过 RL（强化学习）及 MCTS（蒙特卡洛树搜索），将 CoT（思维链）能力内化进 LLM 中，并运用强大的算力实现了 Post-Training 阶段的 Scaling。大模型的发展方向之一是基模的迭代并朝着 AGI 演进，而归纳世界的前提就是大模型具备系统 2 的能力，可见，我们正在加速 AGI 方向探索。
横向上看，基于 Transformer 的 NLP 领域 Scaling Law 有效性已经得到证明，而将该定律扩展到机器视觉、语言处理领域，并形成多模态融合，正在深度探索并取得了明显进展。比如 GPT-4o 把视觉理解模型、视觉生成模型、有声模型融合在了一起，从而更真实地感知与理解物理世界。而在场景建设方向，'大模型+'的链接能力也在不断被突破，如大模型 + 终端设备连接，大模型 + 智能控制等，丰富了大模型的'行为'能力，进而给具生智能装上'大脑'。
贝索斯曾说过，'大家经常会问未来 10 年，会有什么样的变化？但很少有关心，未来十年什么是不变的？我认为第二个问题比第一个问题更重要。'定义清楚了什么是'不变'的，形成抓手并迁移，才可能不断从'变'中，抽象出'不变'并形成内化。
面向大模型场景建设，不断挖掘其共性化建设，并形成标准化能力，从而应对千行百业中不断涌现的新场景、新变化。面向公共云业务场景的建设模式已经显现，类似于 Linux 系统架构，以大模型能力为内核，分层解耦形成对外服务能力，面向场景可组装平台化的大模型应用构建模式。通过三层软件架构，快速构建轻量级应用，实现高内聚、低耦合、变化隔离；通过平台化组装，实现多应用的'积木'组合，从而输出场景化解决方案。因此，无论大模型如何'变'，对外提供能量的接口层隔离了该变化，从而使得应用架构相对稳定。
百炼，作为阿里云大模型服务平台，服务于千行百业的大模型场景建设，其平台可用性、易用性至关重要。今年 5 月份 2.0 版本的发布，不仅深度践行了'一切皆智能体'的理念，更凸显了模型中心、应用中心、以及数据中心这 3 大核心板块的有机联动，易用性取得了前所未有的提升。
面向最高频使用的应用构建，百炼提供了 3 种构建模式，包括智能体、工作流、多智能体，其本质就是模块化、可组装化。可组装化技术，强调的是系统架构层面，是对已有技术的再组合和用法创新，注重系统从构建到演化的过程，如何以可组装的方式增强提升系统的韧性和快速适应性。
正如 Gartner 研究副总裁 David 所说，可组装方法，让系统能力变得可沉淀、可组合复用、可灵活应对各种变化，在新功能的实现速度上将比竞争对手快 80%。很多学员不仅能快速上手百炼，而且分钟级搭建完成 RAG 应用系统并使用，所'建'即所得。
早在 20 世纪 50、60 年代，诺伯特·维纳在《控制论》中就有对智能体概念进行讨论。随着深度神经网络的快速发展，尤其是大模型技术的爆发，基于 LLM 的智能体被广为人知。
智能体，是一种高效、智能的代理，能感知环境、解释数据、做出决策，并执行动作以实现预定的目标。其架构包含规划、记忆、工具、执行四大要素。通过将大模型嵌入到智能体中，可以更好地将模型的能力应用于实际场景。它为智能体提供了强大的推理能力，解释指令和上下文，使其能够更好地利用各种工具，诸如 API、搜索引擎等，实现（半）自主运作。
著名 AI 科学家吴恩达做过一项小型研究，结果表明，在编写代码的标准编码基准测试中，GPT-3.5 智能体，效果上比 GPT-4 表现更好。智能体已然成为大模型落地的关键载体，而大模型与智能体的有机结合，有助于提升整个场景落地的效果。
在软件领域，'分而治之'是一种常用的设计和开发理念，而在大模型场景中也同样适用。面向复杂任务场景，多智能体方法会将复杂任务分解为子任务，让不同的智能体完成不同的子任务，即专业'人'做专业'事'。AutoGen 论文中的消融研究显示，相比于单智能体，通过对复杂任务分解而构建的多智能体，其协作的表现更优。
拆解任务有助于降低单个大模型的输入复杂度以及理解难度，从而有利于大模型专注于'做'一件事情，其性能可能会更好。类比我们自身，在被洋洋洒洒地告知要处理 10 件事情，一次性要理解几千字的信息，与把这 10 件事情分开说、分开做，哪种做法更能做好做准确呢？其结果不言而喻。针对复杂表格所设计实现的方案正是基于这一思路。
LLM 的高速发展，为 NLP 带来了新的范式，即预训练 + 微调+Prompt 范式。其中，预训练是 LLM 的基石，解决的是领域（Domain）能力问题；而微调，解决的是某一任务（Task）问题，利用标注的任务数据，对预训练过的模型做进一步的优化，然而存在过拟合、灾难性遗忘等风险。不过，这两者有一个共性，就是都会改变模型的参数。
相反，提示词工程（Prompt Engineer，PE）无需更改模型参数，而是通过构建合理的 Prompt，激发大模型中蕴含的知识、引导其行为，从而生成高质量的结果。PE 最大的优势在于高效、灵活、成本低，而且避免了微调可能带来的问题。正因为如此，如果创业者只学习大模型的一个技术点，那就是 Prompt。事实上，这也是我们场景落地过程中，使用最多的调优手段。
提示词工程，是一种经验科学，其效果在不同的模型之间可能会有较大差异，但方法层面具有通用性，下面介绍一些笔者在实践中高频使用的方法：
复杂表格的智能问答场景，属于大模型 RAG 应用范畴。大模型 RAG 的基本原理主要分为 2 个阶段：
而在实际使用中，为了获得更好的模型性能，会在原始的 RAG 基础上，增加诸如混合检索、Rerank 等模块化能力，其中混合检索有两种形态，术语检索（即稀疏检索）以及语义检索（即密集检索）。
根据【场景分析】中提出的实施原则，优先选择技术路线 1、2，即优先基于百炼、百炼 + 阿里云产品，标准化能力构建，并验证其可行性。经过调研，探索出了 3 种可行性方案：
按照百炼平台 RAG 的搭建，第一步需要导入文档源，做文档解析。导入的复杂表格文档中，既有表格也有较长文段等，导致提交上传到百炼平台后进行解析出现报错。其原因为对于格式为 xlsx 的文档，数据类型要求是结构化类型，而我们上传的复杂表格，既有结构化数据、也有非结构化数据，因此解析失败。可见，方案 1 走不通，无法满足该项目场景。
由于复杂表格数据格式不统一、多样化、且数据杂糅，传统的文档解析经过尝试均无法满足，而基于多模态大模型的视觉感知，不仅能有效提取图片文字信息而且能做有效推理和生成，因此，考虑基于多模态大模型千问 VL 进行可行性测试。
方案的整体思路，将数据 excel 全部转为图片格式，然后调用基于 QwenVL Max 构建的多模态 RAG。其中，基模的视觉识别能力对整个方案起着至关重要的作用。经过实际验证，该模型能准确理解并给出正确回答，技术上看起来可行，但其存在明显的弊端：
回顾方案 1，最大的卡点问题是文档为 xlsx 格式但数据类型为非结构化，导致无法解析。进一步考虑，是否可以寻求具备该能力的阿里云产品，解决该 excel 文档解析问题，而一旦能打通，则后续便可以复用百炼 RAG 标准化能力，从而最小化定制、最大化复用地支撑该项目的快速实现。
方案的整体思路：
相比于其他 2 种方案，方案 3 标准化程度最高，实施上更轻量，且效果经过初步验证更优。因此，可行性方案采用的是方案 3。
可行性效果评测
基于方案 3 快速搭建的最小应用系统，根据实际测试样例进行批量测试，准确率为 51.2%。其结果表明，从可行性方案上，证明方案 3 的技术有效性，但从效果上，准确率较低，无法满足实际使用落地。
在可行性阶段，探索并验证了方案三（文档解析（大模型版）+ 百炼的组合 RAG）的技术可行性，效果上需要优化。在【Prompt】一节中提到了围绕大模型效果优化的 3 大方向，预训练、微调、PE，而 PE 是最高性价比的调优手段。因此，笔者的第一个直觉也是调 Prompt，效果确实也有提升，但是并不显著。事实上，经过深入分析，究其原因有 3 点：
综合上述 3 种解决思路，设计并最终形成了如下的方案架构，其设计的核心原则是分而治之，封装垂类 Agent，横向组装 API。分层来看，首先基于大模型服务工具，进行数据处理、数据分类等工作，其次通过百炼平台进行垂类 Agent 构建，最后，通过百炼 API 进行多智能体编排组装，且 Router Agent 做路由。
整个方案的工程链路建设，主要分为离线阶段和在线阶段两部分：
接下来，针对链路的关键模块进行简要阐述：
数据处理环节，主要是对表格数据中有错误、有重复、格式错误等情况进行优化，并对表格中的合并单元格进行分行处理等，随后做数据分类，将保养内容进行抽取，并形成结构化数据，构建保养内容知识库；将保养政策进行抽取，通过文档解析（大模型版）进行解析为 MD 数据，并通过百炼构建保养政策知识库。将保养价格数据进行抽取，并通过 Coding 实现 RDS 持久化，并对外提供数据查询服务，以及通过函数计算（FC）实现 Severless 调用。最终，数据质量得到大幅度提升。
车型改写的目的在于，车主提问的方式是开放式的，比如'16 年 xx 在北京，里程 5000 公里，保养需要多少钱？'xx 车型有多款，且每一款的上市时间各有不同，这时候就需要通过车型改写 Agent，进行改写，并输出完整的车型。
其 Prompt 如下所示：
#角色
你是一位问题改写专家，善于根据历史对话做问题改写，并调用【车型匹配插件】做二次改写，以及问题分类。
#技能，严格按照以下步骤执行
步骤 1：需要根据用户问题和历史对话，进行问题改写；
步骤 2：根据步骤 1 改写后的问题，如果提到车型，则提取到【车型】；如果提到时间，则提取到【时间】；否则，则不提取对应字段。
步骤 3：如果【车型】，则务必调用【车型匹配插件】，【车型】、【时间】（如果不为空）作为入参，获取匹配后的【车型全称】；
步骤 4：基于步骤 3 返回的结果，【车型全称】信息，对步骤 1 执行后的问题做二次改写；（只改写，不回答其他内容和思考过程）
步骤 5：根据改写后的问题，判断属于哪类问题。问题类别列表：保养价格类、保养内容类、保养政策类、其他类。
#约束
严格遵循：务必根据技能步骤执行，如果技能中步骤 3【车型匹配插件】被执行，则务必按照步骤 4 进行改写。
#输出格式，以 json 格式输出，样例：
{
"用户问题": "xx，5 万公里，北京保养需要多少钱？",
"提取的车型": "xx",
"插件返回车型": "xx2.0L",
"改写后问题": "xx2.0L，5 万公里，北京保养需要多少钱",
"问题类型": "价格类"
}
在完成多轮对话增强（带历史对话功能），做车型改写的同时，系统会进一步对问题进行意图识别，即理解用户真正的需求。意图识别是智能问答系统的关键部分，它决定了系统是否能够精确匹配用户的需求，确保了后端链路的精准路由。如，用户问'在成都保养单价需要多少钱？'，这时通过意图识别，则会精准路由到保养价格 Agent 链路。
主要利用的是文档智能产品的文档解析（大模型版）能力，实现了基于文档解析的 API 接口，由 xlsx 文档转化为 markdown 的在线功能，主流程如下所示：
#复杂表格解析主流程
def process_file(file_path):
#1、获取 client
client = get_cred_client()
print(f"file_path:{file_path}")
#2、提交复杂表格文件
id = submit_file(client,file_path)
while True:
#3、根据文件 id,查询状态
status = query(client,id)
if(status == "success"):
break
time.sleep(1)
#4、根据返回结果，获取解析后的数据，并存入 md 文件
get_parser_result(client,id)
函数计算是一个事件驱动的全托管 Serverless 计算服务。而我们开发的价格计算插件、车型插件都属于无状态服务，非常适合采用这种函数计算方式。只需将代码编写完成并上传即可，无需管理服务器等基础设施，充分体现了 Serverless 的极简运维，减少业务发布和扩容运维时间，降低用户业务构建门槛，降低用户保有资源的成本。
在测试评估阶段，根据实际样例集进行测评，其部分结果如下所示：
保养内容类样例，经过多智能体问答系统，能正确输出保养内容的相关信息。
保养价格样例，则准确给出对于车型的保养费用，且总费用、零件费用、工时价格，与表格数据完全一致。
经过批量测试，效果准确率达到 93.8%，相比于可行性方案，效果显著提升。
本文以汽车保养复杂表格的智能问答为切入点，系统地阐述了：
笔者认为，LLM 哲学三问的思考，有利于帮助初探大模型的同学们，串联知识碎片，系统性理解大模型；而'两大核心、四大要素'，以及'最大化标准、最小化做定开'的实施原则，为大模型场景落地的同学们，提供了具有实践价值的参考建议；最后，本文阐述的复杂表格多智能体方案及其经验，不局限于汽车保养场景，具有一定通用性，对其他行业有类似场景诉求的同学们，同样具有借鉴意义。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online