1. 为什么说架构设计是AI应用的第一步这些年我接触的AI应用项目多了之后一个感受越来越强烈大多数从零起步的AI应用团队第一步都不是选模型、也不是调Prompt而是应该把架构图画出来。标题里“图解”这两个字恰恰是整个工程问题的核心——AI应用和传统软件开发最大的区别在于它多了一大堆不确定性系统组件从用户请求到模型返回结果这条链路上任何一个环节设计不好后面都会被反复返工。先说一个真实的场景。前段时间有个朋友带着自己的创意来找我他想做一个基于大模型的知识库问答产品。他开开心心告诉我他已经把核心Prompt调得很好了效果很满意准备直接上线。我问他“你的知识库数据存在哪里分片怎么做用户问的问题如果超出知识范围模型会说不知道吗有没有内容过滤机制并发上来之后模型调用怎么控制成本”他愣住了。这就是典型的“只做了模型层没做应用层”的问题。架构设计不是画一张好看的图交差它是在回答一组关键问题数据从哪来、怎么存、怎么检索模型怎么选、怎么调用、怎么降本业务逻辑放在哪一层、怎么跟模型交互用户请求和模型返回之间还要经过哪些处理出错了怎么办、怎么监控和恢复。这些问题不提前想清楚做的就不是AI应用而是一个包着接口的模型Demo。所以这篇内容适合谁正要开始做AI应用的产品经理、后端开发、运维工程师以及那些想把AI能力引入现有系统的技术负责人。不管你是准备用开源模型自建还是走API调用的轻量路线架构设计的方法论是通用的。接下来我按自己画过几十张架构图的经验把整套拆解思路原原本本讲一遍。2. AI应用架构的整体拆分六大核心板块2.1 接入层用户和系统之间的第一道门接入层的设计往往被低估但实际项目中它决定了整个应用的上限。这个层面对的是最终用户关联的是小程序、Web端、App、企业微信、钉钉这类具体入口。架构里面需要明确接入方式是HTTP接口、WebSocket长连接还是消息队列异步处理。我见过不少新手在AI应用里直接让用户请求打到模型API上这是非常危险的做法。接入层至少要承担三件事身份认证、流量控制、会话管理。身份认证要保证调用者合法流量控制要防止突发请求把成本打爆会话管理要维护多轮对话的上下文状态。画架构图时接入层我习惯用一个独立的区域框出来和业务逻辑分开。因为接入层的选型直接跟部署环境挂钩比如你打算部署在云服务器上那这层会涉及负载均衡、防火墙策略如果只是做企业内部工具可能就简单一个服务入口。这一层设计清楚后面加再多的功能模块都不用回头动地基。2.2 应用编排层业务逻辑的真正载体很多初次接触AI应用的人有一个认知误区认为大模型承担了业务逻辑。其实恰恰相反大模型只是完成“生成”这样一个动作业务逻辑必须放在应用编排层由代码或流程引擎来控制。用生活化的例子解释你把大模型当成一个非常聪明的实习生他能写出不错的文字、能回答不少问题但你不会把公司所有重要决策都直接交给他。真正把关的流程、数据校验、决策分支都控制在你自己手里。应用编排层具体做的事包括接收接入层传来的用户输入解析用户意图判断要不要调用模型、调用哪个模型、用什么样的Prompt模板模型返回结果后做格式校验、敏感信息过滤再决定是直接返回给用户还是触发下一步工具调用。这些流程在架构图中要清清楚楚地画出来不能含糊成“业务逻辑”四个大字就算完事。2.3 模型服务层所有智能能力的来源模型服务层是AI应用架构里最核心、也最容易被过度关注的一块。这层要回答的问题非常具体用闭源商用API还是开源自建模型用通用大模型还是领域微调模型不同场景是否要接入多个模型做路由我的建议是架构图上至少空出三个模型槽位主模型槽位、备用模型槽位、专用小模型槽位。主模型承担日常绝大多数对话任务备用模型在主模型限流或故障时自动切换专用小模型负责一些简单但高频的分类、抽取任务——比如判断用户问题属于哪个业务域这种任务没必要都交给大模型处理。模型服务层还需要关注推理参数配置。温度、Top-P、最大输出长度这些参数的设置直接影响生成结果的稳定性和成本。架构图上每个模型组件旁边我都习惯标注清楚它的关键参数默认值这样排查问题和优化时一目了然。2.4 知识增强层让模型真正了解你的业务对大多数垂直领域AI应用来说光靠模型自身的通用知识远远不够。这就是知识增强层存在的意义。目前主流做法是RAG检索增强生成核心思路是先把用户的私有知识文档做切分、向量化存入向量数据库用户提问时先在知识库里检索出相关内容再把这些内容作为上下文拼进Prompt最后交给模型生成回答。画知识增强层的时候至少要包含四个子模块文档解析模块、向量化模块、检索模块、重排序模块。文档解析负责把PDF、Word、Markdown等不同格式的内容转成可处理的文本向量化模块把文本切成合适的块并生成向量检索模块根据用户问题的向量相似度找出候选文档重排序模块在候选文档里精挑细选最相关的一批内容避免一次性把大量低质量内容塞进上下文。知识增强层是AI应用架构里相对独立的一块所以架构图中用虚线框分别标注离线流程和在线流程很重要。离线流程指文档进库的过程在线流程是用户提问时检索的过程。两个流程不要混画在一起否则后面排查检索质量问题时非常麻烦。2.5 数据基础层底层的数据底座数据基础层是最容易被画图时一笔带过、但项目落地时最折磨人的部分。它包含业务数据库、向量数据库、文件存储、缓存、消息队列等基础设施。业务数据库存用户账号、订单、交互记录这类结构化数据向量数据库存文档切块后的向量数据文件存储承载原始文件和小型附件缓存用来加速高频读取的数据比如热门的Prompt模板和频繁检索的知识摘要消息队列在异步场景中解耦调用关系比如文档解析是耗时操作可以先丢进队列后台慢慢处理。架构设计里数据基础层有一点特别重要数据流向不能画成蛛网状。我曾经在评审一个项目时看到架构图上从数据库到模型、到应用、到接入层拉了十几根线复杂得根本没法审查。好的数据流向应该是清晰的一条链路接入层接入请求应用编排层处理请求需要知识时访问检索模块检索模块查向量库模型从应用层拿到拼好的上下文后生成回答结果回传。这样一个流程走下来数据流向是单向的、干净的。2.6 可观测与治理层没有监控的架构是空中楼阁在架构图里加上可观测层是从Demo走向生产的关键标志。AI应用比传统应用复杂的地方在于它不仅会报“系统错误”这类技术故障还会出现“模型输出结果不准确”“回答内容包含风险信息”“同一问题不同时间回答不一致”这类业务层面的问题。可观测与治理层至少包括三个部分调用链路追踪记录每一个请求从进入到返回经过了哪些模块、耗时多少、消耗了多少Token质量评测定期用评测集跑一批典型问题检查回答准确率和相关性指标有没有明显波动安全治理对输入进行提示词注入检测、对输出进行敏感信息过滤和内容合规校验。这层在架构图中我建议画在整个系统的上层用横向带状的区块覆盖所有下游模块。因为它本质上是横切关注点不是某一个链路上的独立节点。3. 实操环节把一张架构图画规范的完整步骤3.1 画图之前的四件事很多开发者的习惯是打开画图工具就开始拖组件画到一半发现缺了模块又往里面塞最后图的布局一团乱。我建议动手之前先花半小时做四件事第一理清使用方和场景。这个应用是给内部员工用的效率工具还是给外部客户用的产品是单租户还是多租户这决定了接入层权限设计的复杂度。第二明确数据从哪里来、初始数据量大概多少。如果是企业知识库场景文档少则几百篇、多则几十万篇向量化和检索方案完全不一样。第三把要用的模型API列出来。是纯走第三方API还是混合使用开源模型部署这是架构里模型层的核心变量。第四想好交付形态。部署在自己服务器还是上云容器化还是传统虚拟机这影响架构图中是否要画容器编排和弹性伸缩模块。第四件事最容易被忽略但对运维兄弟来说却最重要。如果项目上线后突然涌进大量用户架构图上没有体现扩展策略整个系统的可用性就要打问号了。3.2 三个层次系统级、应用级、模块级“图解架构”不是画一张图就万事大吉。我自己的经验是至少要分出三个层次的图。系统级架构图面向汇报和技术选型评审重点展示系统跟周边系统之间的关系、网络边界、主要技术栈。比如整个系统分几大块、用了哪些数据库、模型部署在哪个环境、有哪些外部依赖。这种图看的人大多不是天天写代码的人所以组件不要画太细标注清楚核心交互即可。应用级架构图面向开发团队重点是整个应用的内部模块划分和调用关系。这张图需要把应用编排层里的流程画清楚用户请求进来经历哪些环节、每个环节调用什么模块、失败以后走什么支路。团队成员拿到这张图以后应该能直接找到自己需要开发的模块边界。模块级架构图聚焦某一个复杂模块。比如检索模块要画清楚索引构建流程、查询改写逻辑、向量检索和倒排索引怎么结合、重排序策略怎么配置。这类图对本人维护者最有用因为细节最多也最容易被遗忘。我自己通常等模块开发完以后再对照代码把图更新一遍避免图上画的东西跟实际跑的逻辑有偏差。三种层级图更新的频率也不一样。系统级半年更新一次就行应用级每次大版本迭代后更新模块级只要逻辑变了就随时改。这个习惯帮我避免了很多“图上写着A代码跑的是B”的尴尬。3.3 画法规范和视觉语言用Excalidraw、draw.io、ProcessOn或者PlantUML都可以画图工具的偏好不强求但视觉语言必须统一。我自己固定使用一套约定这里分享出来供参考。组件形状的约定外部系统用圆角矩形加虚线边框内部服务用直角矩形数据存储用圆柱形消息队列用带小圆弧的长方块模型的图标用多边形嵌套表示。颜色也有讲究模型层统一用一种颜色数据存储用另一种颜色接入和编排用暖色系知识增强层用冷色系。颜色不要超过五种不然打印成黑白稿或者投影到会议室屏幕上看起来完全是一团乱麻。连线规范方面实线代表同步调用虚线代表异步消息粗线代表数据流细线代表控制流。每一条线上都要用小字标注协议或大致的数据格式比如“HTTPS/JSON”“Kafka Topic”。不要画箭头不标注含义的线那种图过一个月你自己都看不懂。还有一个细节是图幅控制。一张应用级架构图组件数量控制在15到25个之间比较合适。超过25个信息密度太大很难一眼抓住核心链路少于15个则说明拆分粒度太粗看不出系统真实结构。画完之后把图缩放到50%再检查一遍如果能大致看出主流程和高亮模块说明信息层次是合格的。4. 四种典型架构模式与选型建议4.1 轻量直连模式这是最小可用的AI应用架构前端直接通过后端接口调用模型API没有知识库、没有复杂的编排流程甚至业务逻辑都极简化。典型场景是个人助手类小工具、原型验证项目、短期的企业内部提效脚本。这种模式的架构图最简单接入层和编排层可以合并模型层直接挂在下面数据层只需要交互日志存储。优点是开发速度快、成本低适合快速验证一个想法是否值得继续投入。缺点也非常明显模型知识停留在通用层面回答不了垂直领域问题没有知识增强手段准确率上限很低逻辑都藏在代码里流程复杂以后很难维护。如果只是想测试产品有没有人用、没人愿意付费其实根本不用一上来就上RAG和Agent架构先把轻量直连版本丢出去试错是最经济的选择。架构服务于阶段目标这句话在这里体现得最充分。4.2 标准RAG模式当前落地最广泛的AI应用架构就是RAG模式它解决的核心问题是让模型回答覆盖企业私有知识。架构上在轻量直连的基础上多了知识增强层文档解析入库、向量化、检索、重排序再拼接到Prompt里。这种模式适合客服问答、内部知识库检索、法律和金融辅助、产品使用帮助等场景。架构图上最大的变化就是出现了两条链路离线索引链路和在线问答链路。离线链路对实时性要求不高但要注意文档更新频率。如果知识库每周更新一次那可以设计成每天凌晨跑批任务如果知识库需要小时级更新就得引入增量索引机制。在线链路是整个系统的核心用户请求进来后先并行做检索和对话历史组装检索结果回来后再拼Prompt并调用模型整个过程要在2到5秒内完成才算合格。选型时要注意一点不是所有场景都需要向量数据库。如果知识库内容量在几万篇以下、检索逻辑以关键词为主传统数据库加全文索引也完全够用。盲目上向量库只会增加运维成本和架构复杂度。4.3 Agent智能体模式Agent模式是最近一年最火的方向也是在架构设计上最容易走偏的模式。Agent的核心能力不是“回答问题”而是“完成多步任务”。它把大模型当成一个拥有计划能力的调度大脑让模型自己决定调用哪些工具、按什么顺序调用、如何根据中间结果调整下一步行动。架构上Agent模式比RAG多了一个关键组件工具调用管理。系统里预先注册一批工具比如查天气、查库存、发邮件、访问数据库模型在推理过程中生成需要调用工具的指令应用层解析这些指令并实际执行再把执行结果送回给模型继续推理。画Agent架构图时要注意模型不是直接连接所有工具的。模型只输出结构化指令实际工具调用必须由应用编排层的执行器完成。这个设计既是为了安全又是为了可审计。没有经过执行器的工具调用相当于让模型直接操作生产系统风险太高了。Agent模式的架构图复杂度明显上升通常包含计划模块、工具注册中心、执行模块、记忆模块和反馈循环。组件之间的连接不再是一条直线而可能有环状结构。画这种图更要克制不然很容易画成蜘蛛网。4.4 多层协同模式当业务足够复杂比如既要做客服知识问答又要处理工单流转还要自动生成报表甚至需要多模型配合工作单一模式就不够用了。这时需要多层协同架构接入层统一入口编排层按业务流程路由到不同的能力模块每个模块内部再各自选用合适的模型和策略。多层协同模式的核心在设计原则业务编排与模型调用解耦。不要把复杂的业务判断全部丢进Prompt里让模型顺带完成路由、工具选择、格式解析、内容校验等工作。正确做法是能用规则判断的用规则只有规则处理不了的部分才交给模型。比如“用户属于哪个会员等级”这种问题直接查数据库就行不要让模型从对话里猜。架构图上的体现就是应用编排层内部会多一个“能力路由”节点旁边挂一张路由规则表。这张规则表是系统的决策核心它的可维护性决定了后续系统演进的灵活性。多层协同模式不适合初创小团队因为维护成本高更适合组织架构已经成熟、业务链路天然复杂的场景。5. 选型要点与设计决策的深层逻辑5.1 模型选型API调用还是私有化部署架构图上模型层的选型直接影响成本、隐私和运维方式。商用API的优势是开箱即用、推理质量高、不用管底层硬件劣势是数据要出网、单次调用成本随并发上升明显、受制于供应方的限流策略。私有化部署的优势是数据完全在内部、单次推理边际成本可控、可以针对业务做定制优化劣势是前期硬件投入高、需要专门的推理优化人员维护。我见过一个实际案例某企业内部知识库系统最初用API方案上线后爆发了数据合规问题被迫整体迁移到私有化部署。如果他们在画架构图的第一天就把数据合规要求画进去迁移成本完全可以避免。架构图里的每一层标注本质上都是在提前管理未来的风险和成本。5.2 RAG还是微调架构上怎么体现这个争论在技术社区几乎每周都会出现。我的答案是默认先考虑RAG把微调作为进阶选项。RAG的优势在于知识更新方便——内容变了重新索引一遍就行微调的优势在于改变模型的行为风格和格式遵循能力但它无法注入实时知识而且需要准备高质量的标注数据集。架构图中至少要为微调预留一个扩展位置哪怕初期不上线。我用虚线框画一个“模型微调流水线”里面放上数据准备、训练任务、模型评估三个子模块。等系统跑起来以后如果发现RAG无论如何做都满足不了特定领域的输出格式要求再启动微调工作流。这种设计让架构图既反映现状又能容纳演进。5.3 上下文管理与Token成本控制Token成本是AI应用架构里最隐秘的黑洞。以RAG模式为例一个回答消耗的Token大约等于“系统提示词加历史对话加检索文档拼接加模型输出”的总和。如果一次检索把上万字的文档都塞进Prompt很快就会发现模型质量没提升多少月度账单却翻了好几倍。架构图上每个调用模型的环节旁边我都建议标注一个“预估Token消耗区间”。这个区间不是拍脑袋填的而是根据历史平均对话轮数、每轮检索文档的默认块数和输出长度上限估算出来的。有了这个数字运维同学在监控里看到某个接口Token消耗异常时能够立刻定位到是哪一层出了问题而不是查半天日志才发现是Prompt构造逻辑被改了一行。5.4 缓存策略也是架构的一部分很多人画AI应用架构时不画缓存这是不对的。对高频重复的问题完全可以做一层缓存处理把用户问题做规范化处理后计算语义哈希在缓存里命中相同或近似的历史问题直接返回上次的模型输出。这样可以省掉大量模型调用成本尤其在知识库内容基本不变的情况下缓存命中率可以到三成以上。当然缓存策略要谨慎不能对结果实时性要求高的场景使用。但架构图里保留一个缓存组件的位置后续系统优化时你会感谢当初这个决定。6. 实操记录一个RAG应用从构想到架构落地的完整过程6.1 场景背景与需求梳理今年上半年我参与了一个面向企业内部员工的规章制度问答项目需求是让员工随时询问关于差旅报销、绩效考核、请假流程等制度问题回答要基于公司发布的文件不能编造。这是一个典型的RAG应用场景。第一步先梳理用户量和访问特征。企业内部员工大约上千人峰值并发预计在每分钟几十次请求的规模对话轮次平均在2到4轮。这个量级意味着单机部署完全可以承载不需要引入复杂的分布式架构。但我还是在架构图中预留了水平扩展能力因为上线后如果使用率超出预期加机器就行不用返工。数据量摸底后发现制度文件有一百多份总计约八十万字。这个规模对向量检索来说非常轻松但对切分和索引策略有一定要求因为部分文档里大量存在“根据《XX规定》第三条”这类交叉引用单纯按固定长度切分会把上下文关系切断。6.2 架构图第一版怎么画的我画的第一版架构图分为四个横向区域。最上部是接入层容器里画了企业微信入口和Web管理后台两个组件。中间是应用编排层核心组件包括意图识别模块、RAG检索编排模块、回答生成模块、反馈收集模块。第二层是模型服务层标注了主模型采用通用商用API备用模型是同供应商的轻量版本两个模型之间有一条带虚线标注的“熔断切换”关系。再往下是知识增强层画了离线文档解析管道、向量库和在线检索组件。最底部是数据基础层包括业务数据库、向量数据库、对象存储和日志存储。这张图画完以后团队花了三个小时开会评审最终改了三处一是在接入层增加了白名单限制只有内网IP段才能访问管理后台二是把文档解析管道从同步调用改成异步消息驱动避免超大文档解析时阻塞系统三是在回答生成模块增加了敏感信息脱敏发布订阅逻辑因为制度文件中可能包含薪酬信息。6.3 开发过程中对架构图的修正真正开发起来以后有一个细节暴露出了架构图的问题。文档里有大量的表格比如报销标准表、绩效考核评分表这些表格数据如果按文本切分再向量化检索效果非常差。因为表格被切碎以后表头信息对不上内容模型看了半天也不知道“一级城市住宿标准”对应的是多少钱。我们给知识增强层补了一个“表格结构化抽取”模块先用规则识别文档里的表格区域把每张表格转为结构化的键值对描述再独立向量化存储。检索时如果命中表格内容会把整张表的关键结构作为上下文传给模型而不是几块零零散散的文本碎片。这个模块上线后表格类问题的回答准确率从六成提升到了九成以上。这让我再次确认一个规律架构图永远不可能一次画完美但好的架构设计能留出修正空间。因为当初把知识增强层拆成了独立的模块增加表格结构化模块时才没有影响到检索链路和模型调用逻辑。6.4 上线后的架构演化和容量评估上线后的数据跟预期基本一致。日均请求量几百次模型调用平均耗时约1.8秒检索模块耗时约300毫秒整体回答链路在2.5秒左右。Token成本方面每轮对话平均消耗约2400个Token月度成本完全在可控范围内。随后我们做了一次容量评估按现有架构如果用户量翻五倍单机部署的实例CPU使用率会接近阈值需要额外增加一个服务实例前置负载均衡。向量数据库切换到集群模式加一个副本节点。模型调用层面因为走的是商用API由供应商负责扩展我们只需要注意限流策略。这些扩展动作在架构图上都能找到对应的挂载点真正做到按图索骥。7. 常见问题与排查技巧实录7.1 检索结果总是很差问题可能出在哪RAG架构里最常被吐槽的问题就是“答非所问”。遇到这种情况不要急着怀疑模型能力先排查知识增强层。我整理了一个从易到难排查顺序实际测试下来命中率很高第一步检查检索TopK和重排序。很多团队对检索到的文档不做重排序直接把Top3结果塞进Prompt。如果候选文档质量问题多回答效果必然受影响。第二步检查切分策略。固定500字切块和按语义段落切块检索效果可能差一大截。第三步检查向量化的维度适配。文本向量模型和检索模型维度不匹配是低级错误但时有发生。第四步检查Prompt模板中知识指令的表述。模型如果不知道“优先依据提供的材料回答”就算检索到正确答案也可能自由发挥。7.2 模型回答变慢之后的瓶颈定位AI应用响应变慢排查思路和传统应用完全不同。传统应用慢大概率是数据库查询慢或后端计算密集而AI应用慢通常集中在模型生成环节。如果发现回答耗时长先用链路追踪数据判断是“模型调用前慢”还是“模型调用本身慢”。模型调用前慢包括检索慢、上下文构造慢、安全检测慢模型调用本身慢主要受输出Token数和并发排队影响。一条经验法则输出Token数每增加一倍生成耗时大约增加一倍半到两倍。所以对追求响应速度的场景把回答长度上限设置短一些是见效最快的优化手段。7.3 每日成本超标应该从哪里开始查成本超标通常不是模型单价涨了而是Token消耗失控。首选排查对象是上下文膨胀——多轮对话场景下历史消息不断累加如果不做截断或者摘要压缩每轮都会把完整历史塞给模型Token消耗呈线性甚至超线性增长。我的做法是在架构图上标注清楚“上下文管理模块”的位置并且规定超过N轮以上的历史消息必须做摘要压缩超过M字符的消息体必须截断。这两个阈值写进代码里成本就基本可控了。其次排查的是检索块数量不要贪多三到五块有效内容比二十块无关内容对回答质量贡献更大。7.4 知识更新后模型还在答旧内容很多团队上线RAG后遇到一个问题明明确权部门和内容都更新了员工问起来模型回答的还是旧数据。绝大多数原因出在向量库的更新策略上。如果向量库只做新增不做删除旧版本文档的向量块依然参与检索就可能导致模型拿到新旧两套矛盾信息然后给出混乱回答。正确做法是在离线索引链路里实现“按文档ID全量替换”的语义同一份文档重新解析后先删掉该文档ID下的所有旧向量块再写入新的向量块。数据库层面要支持按文档ID批量删除的接口而不是简单清空全库重建。这个坑我踩过两次之后才长记性现在我在架构图上一定会明确标注“文档版本替换机制”并作为知识增强层的必选模块。8. 给初学者的三条核心建议画AI应用架构这件事不要求你一开始就是架构师但至少有三种能力需要刻意练习。第一学会用分层视角看系统。不管画什么系统先从“接入、应用、模型、数据、治理”这几层往下套再根据场景增减模块。分层不是形式主义而是让系统的复杂性问题分散到不同维度每个维度能独立演化和扩展。第二学会画“当前状态”和“目标状态”两张图。很多人一上来就画理想架构结果跟团队手头代码完全对不上久而久之大家对架构图失去信任。正确的做法是先画一张跟现状一致的图诚实反映系统当前的长相再画一张目标架构图让整个团队看到演进方向。两张图之间的差距就是未来几个迭代的开发任务清单。第三架构设计的关键成果不一定能被量化评价但一定能在风险到来时被验证。当用户量翻了十倍、当知识库突然要接入新的数据源、当模型服务商升价限流、当安全审查要求提供完整数据链路说明架构图就是支撑你做判断的底图。没有这层底图所有这些突发状况都会变成救火行动。我在实际项目里还有一个习惯每次项目交接或者大版本总结时把最新架构图单独打印出来贴在团队白板上。让新加入的同事从这张图开始读代码、了解系统让评审的人先看图再谈细节。一张好的AI应用架构图能替团队省掉大量靠口口相传的隐性知识流失成本这也是为什么我一直坚持先把图画出来再写代码的根本原因。