★ FEATURED ARTICLE 刚开始接触AI应用开发的时候我犯过一个特别蠢的错误代码还没写几行先花了一周时间把模型接口调通了结果到了联调阶段才发现整个系统的数据流是乱的用户请求进来之后不知道去哪取上下文模型返回结果也不知道该往哪儿写最后只能推倒重来。后来养成一个习惯不管项目多小先画一张AI应用架构图再动代码。就是这个习惯帮我避免了无数次返工。今天想聊的就是这件看起来不起眼、实际上能救命的事“图解AI应用架构设计”。不聊那些高大上的“大模型平台蓝图”就说说一个普通的AI应用——比如智能问答、文档分析、Agent工具——从想法到落地架构图应该怎么画、画完怎么用、里面每个格子到底在解决什么问题。适合正在做AI应用开发、想从“调通接口”走向“搭好系统”的工程师也适合那些项目刚起步、还没理清模块边界的团队。1. 为什么AI应用架构要先画图再动手我一直觉得AI应用和传统后端开发的本质区别不在于“用了大模型”而在于它的不确定性被放大了。传统接口的行为是可预期的输入合法输出基本可测。但AI应用不一样模型输出有概率性同样的Prompt可能给出不同的答案而且模型本身不持有业务上下文你需要想清楚上下文从哪里来、经过什么处理、最终怎么被模型消费。这些问题不先想明白代码写得再快也会被推倒。1.1 架构图解决的是“看不见的依赖”很多人写代码是靠脑子记依赖关系的小项目还行一旦模块超过六七个就会开始乱套。典型的现象是一个模块改了接口签名结果调用方漏改编译过了但运行时数据格式对不上AI应用里这种坑尤其常见因为很多数据是自然语言和结构化数据混在一起类型错误往往不是编译期报出来的而是到了推理阶段模型给了个奇怪回答你才发现。架构图在这里的真正价值是把每个模块之间的显式和隐式依赖摆在明面上。你要画的不是“系统结构图”而是“数据流向控制流向外部依赖”三合一的图。画完这张图你才能回答几个致命问题模型到底在系统的第几层知识库的更新路径是什么用户会话状态存在哪里异常时降级到哪一步我自己的经验是架构图的第一版一定很粗糙甚至很丑但没关系。画图这个动作本身会逼你把系统边界划清楚哪些是外部依赖模型API、向量库、网关哪些是自研模块服务层、调度层、缓存层哪些是配置而非代码Prompt模板、模型参数、知识库索引策略。1.2 什么样的AI应用值得画架构图不是所有AI功能都要画完整架构图。比如你只是调一个翻译接口、套一个文本分类模型那谈不上架构。但一旦出现以下特征中的任意两条架构图就应该出现在你的开发流程里有多个外部AI服务协作比如大模型负责生成、语音识别负责输入、视觉模型负责分析截图有持久化存储尤其是向量数据库或文档仓库同一份知识/上下文被多个功能模块共享需要面向真实用户有并发、延迟、成本约束需要人工介入或审核机制比如做一个“企业知识库问答机器人”表面上就是个对话接口实际上涉及文档解析、切片、向量化、检索、重排、Prompt组装、生成、引用追溯、权限过滤这些环节只要有一个断了用户感知就是“AI胡言乱语”。而架构图能让你一眼看出“权限过滤”在链路中的位置是否在检索之前而不是等上线后被用户告到客服。1.3 图解法的核心思路分层不越层任何一张好的AI应用架构图都遵循一个原则分层清晰、边界明确。我会把AI应用划分成四层接入层、业务逻辑层、AI能力层、数据层。每一层只跟相邻层通信不跨层跳转。接入层负责用户输入输出格式转换、鉴权、限流、协议适配业务逻辑层负责会话管理、业务规则校验、Prompt模板路由、工具调用编排AI能力层负责模型调用、RAG检索、结果后处理、多模型路由数据层负责向量库、关系库、文档存储、缓存“不越层”这个约束很多人不以为然实际操作中就是这条约束帮你挡住灾难的。比如有人图省事直接在接入层拼接Prompt字符串把业务逻辑和模型调用耦合在一起。初期很爽等Prompt迭代到第三版、用户权限规则也塞进去之后接入层会膨胀成“上帝模块”改一行Prompt要重新部署接入服务。分层画图、按层开发、按层部署这句话本身就是架构设计最核心的纪律。2. 一张图说清AI应用的核心模块AI应用架构图不是只有“模型”和“数据库”两个盒子的示意图。真正可用的架构图必须把每个模块的职责、关键接口、典型实现技术都标注出来。这一节我用一个实际的“AI文档问答助手”作为例子拆解一张中等复杂度架构图里必须出现的模块。2.1 接入层不止是API网关接入层是面向外部世界的窗口很多AI应用的体验问题其实都出在这一层。它要处理的远不止“转发请求”这一件事。首先是输入校验。用户传上来的可能是文件、图片、语音、长文本你得判断格式合法性、大小限制以及是不是恶意内容。其次是鉴权B端场景要校验租户和角色C端场景要管理匿名用户和登录用户的配额。接着是限流模型API有成本和并发限制接入层不做限流上游服务被拖垮只是时间问题。最后是协议适配同一个功能可能同时要支持HTTP同步返回和SSE流式输出这一步必须在接入层完成。我在架构图里给接入层画的典型组件包括路由网关、会话初始化器、输入校验器、流式输出适配器。注意接入层永远不要写业务规则不要出现“如果用户上传的是合同类型文档就走深度解析流程”这种逻辑那是业务层的事情。2.2 业务逻辑层AI应用的“大脑皮层”如果AI能力层是“思考层”业务逻辑层就是“决策层”。这一层负责理解用户意图属于哪个场景、该调用哪些工具、需要从哪些数据源取上下文、最终用哪套Prompt模板。一个容易被忽略的事实是AI应用里90%的业务逻辑不是“判断-执行”这种确定性代码而是“组装上下文-选模板-决定是否检索”这类半确定性流程。比如用户问“根据上季度销售数据分析华东区增长原因”业务逻辑层要做的事包括识别这是数据分析场景、检查当前用户有没有华东区权限、把问题拆成检索条件和分析指令、决定是否需要调用SQL生成工具。这些决策如果都塞到提示词里让模型自由发挥结果你也能想象——模型确实很聪明但没有权限约束的聪明就是事故隐患。业务逻辑层在架构图中要画清楚的子模块有四个会话状态管理器、Prompt模板路由、工具编排中心、策略配置中心。会话状态管理器维护多轮对话的上下文摘要和引用信息Prompt模板路由根据场景选择不同的提示词模板并完成变量填充工具编排中心负责调度外部工具调用比如搜索、SQL查询、维基检索策略配置中心则集中管理模型选择、温度参数、超时时间这些“运行时配置”。这层是架构图里最复杂的一块但也正是这层决定了你的AI应用是“玩具”还是“产品”。2.3 AI能力层模型不是唯一的重点很多刚入门的人把AI能力层理解成“放模型的地方”画一个OpenAI的方框再加一个Llama的方框就完事了。实际上这一层的核心是“围绕模型的一系列工程能力”。回答LLM调用的稳定性问题你需要一个模型网关组件负责多模型路由、重试、降级、成本统计。为了让回答不超时你要支持流式输出。为了让模型不乱说你要在AI能力层加入结果校验组件。至于RAG它的完整链路文档切片、向量化、索引、检索、重排序、上下文拼接更是AI能力层的主战场。如果你把RAG的每个环节都画在AI能力层的框里你的架构图已经比市面上六成博文里的示意图专业了。RAG的每个环节单独看都不难难的是它们之间的衔接文档在何时被切块切片后是否保留元数据向量索引更新与业务数据变更如何同步检索时topK取多少重排模型和生成模型如何配合这些细节全都在AI能力层的边界内一个成熟AI应用的竞争力恰恰就藏在这一层的工程化深度里。2.4 数据层向量库不是银弹数据层是架构图的地基但很多人对AI应用数据层的理解只停留在“PostgreSQL向量数据库”这种技术选型层面。我建议把数据层进一步拆成四个存储区源数据区原始文档、图片、音视频等非结构化数据存对象存储或文件系统结构化业务区用户信息、权限关系、业务订单等明确结构的数据存关系型数据库语义索引区文档切片后的向量以及标量过滤字段存向量数据库缓存区高频问答、模型响应、检索结果的临时缓存存Redis画数据层的时候重点要标出“数据流向”。文档进来之后是先到源数据区再经处理管线进入语义索引区业务数据变更时需要同步更新索引区里对应的向量用户问答时产生的上下文则读写缓存区。一个没有箭头的数据层画得再漂亮也是死的。3. 从请求到响应的数据流设计架构图如果只有模块和连线那训练有经验的工程师一天能画三张但全是废纸。真正让架构图有生命力的是数据流——一份请求从用户端出发经历了哪些模块在每个模块里被加工成了什么形态最后如何回到用户手里。3.1 时序视角一次完整问答的六步链路我习惯在架构图之外补一张时序图把一次典型的问答请求拆成六步。不要用只在架构图里画箭头然后自high一定要走一遍时序图才能发现隐藏的问题。第一步用户输入经过接入层的输入校验和鉴权被包装成内部标准请求格式写入会话上下文会话状态管理器。第二步业务逻辑层意图识别这里既可以用规则匹配也可以用小模型分类或者直接让大模型判断但无论哪种方式决策结果必须结构化作为后续路由依据。第三步检索触发如果判定需要知识库内容业务逻辑层调用AI能力层的RAG链路根据当前会话上下文生成检索Query去向量库召回topK候选。第四步Prompt组装业务逻辑层根据场景选择Prompt模板将检索结果、会话历史、用户输入、业务规则拼装成最终的模型输入。第五步模型推理AI能力层通过模型网关调用模型支持流式返回并把原始输出传给结果校验组件格式检查、内容安全过滤、引用完整性校验。第六步结果回写业务逻辑层把最终回答写入会话存储和缓存再经接入层返回给用户。这六步走完你会发现两个关键真相真正调用模型前后的大量工作才是架构差异所在上下文质量决定了回答质量而上下文是在第二步到第四步之间被加工出来的。一张架构图一张时序图组合使用能帮你把“AI应用”从玄学变成工程。3.2 异步与同步的边界选择AI推理耗时较长首Token几百毫秒到几秒都很常见如果在链路中同步等待模型结果你的API服务线程就会被无限拖住。因此数据流设计里必须明确区分“同步处理”和“异步处理”的边界。我的经验是两个原则用户体验需要即时反馈的用流式输出SSE/WebSocket把等待感降到最低重计算或长流程的用任务队列Celery、BullMQ异步处理。比如文档解析、批量向量化、定时知识库更新这些绝不可以在用户请求线程里做否则一次上传就把服务搞崩了。以“文档问答助手”为例用户上传PDF后应该立刻响应“文件已接收解析中”后台任务队列异步处理文档解析、切片、向量化完成后回调更新索引状态。用户多轮对话时则用SSE流式输出边推理边返回。这条边界如果不在架构图里画清楚开发过程中必然会出现谁等谁的问题是把解析过程拖到对话请求里还是让用户等文件解析完才能发问题——两个都是坏选择。3.3 缓存策略AI应用的隐形加速器AI应用里最容易被低估的模块是缓存。模型调用贵且慢如果你的AI应用每天都有一大堆完全相同的重复问题打到模型上烧的就不只是钱还有用户体验。我一般在三个位置加缓存。第一个是业务逻辑层入口的“整回答缓存”适合对同一问题、同一用户、会话状态下结果一致且不会过期的场景用问题Hash用户Id做Key命中直接返回历史回答。这个缓存对数据变化不敏感的场景特别有效。第二个是AI能力层的“中间结果缓存”比如RAG检索结果缓存同样的Query在短时间内再次检索向量和重排结果大概率一样缓存检索结果能省下二次向量计算。第三个是Prompt模板渲染结果缓存尤其是模板里拼接了大量静态知识与固定业务规则时把渲染结果缓存下来能减少字符串处理和上下文组装耗时。缓存最大坑在于失效问题索引更新后旧缓存还在用户得到的答案和最新知识不一致。我的做法是在数据流图里专门画一条“索引更新触发缓存失效”的虚线无论是文档新增还是删除都必须联动清除相关上下文的缓存。没有这条虚线缓存就是你的知识库版本分裂的元凶。4. 模型层选型与部署策略架构图画到最后总归要落到一个关键问题你的模型从哪来、跑在哪、怎么调节奏。模型层选型不是“哪个强用哪个”而是基于延迟、成本、可控性、数据合规四个维度综合权衡的结果。4.1 API调用还是私有化部署先从最简单的维度讲起。如果团队没有GPU资源、数据合规压力不大、业务对延迟容忍度较高直接调用商业模型API是最快路径。优点是几乎零运维成本模型能力迭代由供应商负责你只需要关注应用层工程缺点是单次调用成本会随着业务规模增长变得不可忽视并且存在数据外发合规风险。如果业务数据敏感或需要完全控制推理延迟与可用性就要考虑私有化部署开源模型。像Qwen、Llama这类相对成熟的开放模型在中等规模场景下完全可用。但请注意私有化部署不等于“装个Ollama就完事”你要自建推理服务处理显存管理、并发排队、模型分片、版本热更新、推理日志与监控。架构图上至少要多出三个组件推理服务、模型仓库、GPU资源监控。我个人对中小团队的建议是采用“混合路线”核心高价值场景私有化冷门低频场景走API这个决策在架构图里就应该被清晰标注。4.2 模型网关多模型共存的必需品AI应用架构图里如果只画了一个模型方框我基本可以判断这个应用走不远。模型供应商随时可能调整版本、限流、涨价单一模型的故障意味着整个应用瘫痪。所以在AI能力层一定要有一个模型网关。模型网关的核心能力有四块。第一路由策略按业务场景/用户等级/QPS权重把请求分发到不同模型第二重试与降级上游超时或报错时自动重试对非关键请求可以降级到小模型或模板回答第三成本统计记录每个场景、每个用户、每个模型的Token消耗把成本归因到业务线第四缓存与限流对重复请求做语义级缓存同时用维度限流保护下游模型。这四块能力落到架构图上就是AI能力层里最核心的一个组件。我见过一个真实案例某团队自研AI客服刚开始直接写死调用GPT-4后来某天上游服务波动客服系统整瘫一上午。架构调整后引入模型网关默认走自有部署的Qwen模型复杂问题才升级到GPT-4同时配置了重试3次和熔断降级之后再也没因为单模型服务不稳定影响过主流程。这种“看不见的稳定性”才是架构设计的真正价值。4.3 推理参数与架构设计的关系最后聊一个很多人忽略的“软参数”温度、Top-p、max_tokens、重复惩罚这些推理参数它们不只是模型推理的问题还应该反映在架构设计的配置中心里。原因是不同场景下推理参数差距极大。比如客服工单分类想要稳定温度设0或接近0营销文案生成想要创意温度设0.8-1.0代码生成想要确定性又要一定灵活温度设0.2。如果你的架构把这些参数分散写在业务代码里每次调整都要发版如果抽到配置中心产品经理都可以在后台调。更关键的是模型网关的多重路由策略本身就是基于这些参数生成不同的推理Profile。所以说推理参数不是模型工程师的私事它是架构层“配置策略”的一部分。我在架构图里专门给“策略配置中心”加了一个小方块里面列出模型选择、温度、超时时间、重试次数、缓存TTL等。这个方块能时刻提醒我架构不仅是静态的图还是运行时可变参数的载体。5. 实操过程与核心环节实现思路讲了一大堆落地才是硬道理。这一节我分享一个从0到1画AI应用架构图并照着搭建的完整实操过程。拿“企业内部智能问答机器人”举例结合前面拆的模块一步步来看最终架构图长什么样、模块之间怎么连。5.1 第一步确认业务边界和核心流程动笔画架构图之前先拿一页纸写下最核心的业务场景和问题清单。不需要列表很多五个以内即可。比如这个企业内部问答机器人核心场景是员工询问制度政策如休假规则、员工查询项目信息如某客户进展、上传新文档并让机器人学习。问题清单包括回答的实时性要求是多高、涉及的权限体系复杂吗、文档更新频率如何、知识库冷启动的数据量有多大、允许的模型成本上限是多少。工具上用简单的“场景×问题”矩阵就能梳理清楚。我画了一张表横向是场景纵向是刚才提到的非功能指标数据敏感度、实时性、成本、容错容忍度。每个格子做简单标注。这个矩阵就是架构图的第一层输入它告诉你接入层要不要做复杂的权限集成、业务逻辑层的策略配置要覆盖哪些场景、数据层的索引更新策略要设计到什么程度。5.2 第二步画出轻量级分层架构图接着就是动手画分层架构图。不用专业工具白纸、白板或者draw.io都行。我从上到下画四层接入层、业务逻辑层、AI能力层、数据层。然后在每层里摆组件。接入层画出网关、SSE适配器、鉴权模块。业务逻辑层画出会话管理器、意图路由器、Prompt模板中心、工具编排器、策略配置中心。AI能力层画出模型网关、RAG检索服务、结果校验器。数据层画出Redis缓存、PostgreSQL业务库、向量数据库Milvus、对象存储MinIO。层的右侧再画两个竖条偏左侧放外部依赖用户权限系统、邮件服务、OA接口偏右侧放非功能性设施监控、日志、告警。层与层之间用箭头连起来标注“同步调用”或“异步事件”。画出来之后退后两步看这张图如果你能顺着箭头把一次问答流程从头走到尾这张图就合格了。5.3 第三步落地核心代码骨架架构图确认后代码骨架其实已经可以照图搭了。我用FastAPI作为接入层和业务层的载体核心代码分模块对应架构图的层。关键骨架如下# 目录结构 ai_assistant/ ├── api/ # 接入层路由、鉴权、SSE ├── core/ # 业务逻辑层会话、意图、Prompt路由 ├── ai/ # AI能力层模型网关、RAG链路 ├── data/ # 数据层SQLAlchemy、Redis、向量库客户端 ├── config/ # 策略配置中心YAML管理推理参数 └── main.py模型网关的核心接口我写的比较简洁# ai/model_gateway.py async def chat_with_gateway(req: ChatRequest) - ChatResponse: # 优先尝试私有化部署的Qwen模型 try: resp await qwen_client.chat( messagesreq.messages, temperaturereq.temperature, max_tokensreq.max_tokens, ) return resp except QwenUnavailableError: # 降级到备用云上模型做一层超时控制 async with timeout(10): resp await cloud_api.chat( modelfallback-model-v2, messagesreq.messages, ) return resp这个网关的“重试与降级”逻辑看架构图一目了然模型框不再是一个孤零零的盒子。如果当初没画架构图大概率你会把这两个模型的调用逻辑写死在两个不同的业务模块里各管各的崩溃时才发现没有一个统一兜底。RAG检索服务的核心把向量检索和业务权限结合起来# ai/rag_retriever.py def retrieve(user_id: str, query: str, top_k: int 5): # 先从Redis查相同Query的缓存, 命中则跳过向量检索 cache_key frag:{hash(query)}:{user_id} cached redis_client.get(cache_key) if cached: return json.loads(cached) # 向量检索 元数据过虑 (权限隔离) docs vector_store.search( collectionenterprise_kb, query_embeddingembed(query), top_ktop_k, filter{allowed_dept_ids: get_user_dept_ids(user_id)}, ) # 把检索结果缓存 redis_client.setex(cache_key, ttl300, valuejson.dumps(docs)) return docs这段代码就对应了架构图里AI能力层的RAG服务和数据层的缓存组件。初次上手的人可能觉得“就这几行代码有什么好架构的”但你把向量检索和权限过滤放在同一个函数里就是“数据层权限在检索之前”这个架构决策的体现这比在模型生成之后筛结果要可靠得多。Prompt模板和策略配置中心的落地也是这样。我把每个场景的Prompt拆成独立的YAML配置意图路由器从这里读取场景对应的模板路径# config/prompts/leave_policy.yaml system: | 你是企业内部政策问答助手请严格根据下文中提供的文档内容回答 不要自行发挥。若文档中没有明确说明请回复抱歉暂无该政策细节。 context: | 【公司休假政策】 {retrieved_kb} user: | 用户的提问{input} 以上问题请给出准确、简洁的回答并注明政策出处。这样一来产品经理想调Prompt文案不需要动代码改配置即可。架构图中的策略配置中心就直接落实到这样一个文件目录里。这就是工程化和非工程化的差距广告素材的AI应用也能回答用户问题但没法快速迭代配置没法最低成本地让产品参与调优。5.4 第四步为每一次请求做端到端联调架构图定稿、骨架代码跑通之后就进入联调阶段。我的建议是不要用一个假想的“正确答案”来验证而是准备一组有代表性的测试用例覆盖核心架构决策的每一个分支。比如命中缓存的重复问题验证Redis链路、需要知识库检索的复杂问题验证向量召回和重排链路、权限不足的问题验证检索过滤链路、上游模型超时的场景验证降级链路、流式输出时网络中断的恢复验证SSE断线重连。每一条用例都要对照架构图里对应的那条链路。这轮联调的核心目的不是验证功能正确而是验证每一个架构决策在真实运行中的表现。模型网关的重试会不会导致重复扣费缓存命中后是否需要更新会话历史降级到备用模型后Prompt模板是否兼容这些细节问题早期暴露一个就修复一个比上线后被真实用户“测”出来强一百倍。6. 常见问题与排查技巧实录架构设计做多了你会发现在AI应用这个领域问题总是出现在几个固定位置。这一节把我在实际项目中反复踩过的坑整理成一份速查表每个都对标架构图里的具体模块。6.1 架构图常见问题速查表问题根因对应架构模块排查思路配置建议回答质量差、知识过时RAG检索链路没接索引更新事件AI能力层/数据层检查文档解析管线是否在索引更新后触发缓存失效向量库里旧切片是否被软删除建立“文档版本号切片增量更新”机制索引更新后清RAG缓存用户问同样问题回答反复横跳缺整回答缓存模型温度设置偏高业务逻辑层/策略中心查该请求是否命中缓存查模型网关配置温度对确定性问答场景设置温度0加语义缓存高并发下模型API超时/限流接入层没有限流模型网关缺熔断接入层/AI能力层看日志中限流状态码分布检查网关重试与熔断阈值接入层全局限流网关配置熔断阈值对关键场景做降级权限数据泄露用户问出无关部门数据权限过滤在检索之后而不是之前AI能力层/RAG链路检查RAG代码中向量检索是否存在元数据过滤参数看检索TopK返回是否包含越权文档权限过滤前置到检索语句中并在Prompt中隐藏未授权内容流式输出卡顿/前端掉字接入层SSE适配器与模型流式接口的协议不匹配接入层/AI能力层对比模型流式数据格式与前端解析格式检查网络代理缓冲统一SSE数据帧结构关闭网络中间层缓冲文档上传后机器人“没学过”文档解析、向量化是全异步流程状态未持久化业务逻辑层/数据层查任务队列任务状态检查向量库有无新索引任务状态入业务库上传成功后回调驱动向量索引更新这张表是我做AI应用架构咨询时用得最频繁的一张表几乎可以覆盖六成以上的线上问题。6.2 排查时的三条实操心得第一永远从架构图开始定位而不是从代码开始。出现线上问题时把架构图摊开顺着请求链路逐段打日志、看指标。基于“分层不越层”的架构你可以快速隔离故障在哪一层而不用在一万行代码里翻找。每次排查完把问题原因标注在架构图对应组件上一张张标注过的图就是团队最珍贵的故障知识库。第二AI应用的日志设计要围绕请求链路来建。给每个请求分配一个traceId从接入层开始透传到模型网关和RAG服务。这样不管问题出在Prompt组装还是模型调用你都可以用同一个traceId串起完整日志。不建这条链路AI应用出问题会特别痛苦因为你连“模型到底收到了什么上下文”都查不到。第三把“模型输出的质量”纳入监控指标。传统应用监控的是错误率、时延、吞吐AI应用还要多一个回答质量维度。最简单的做法是随机采样部分回答由脚本做规则校验比如是否包含引用、是否为空、是否超长再配合人工抽检。架构图里AI能力层的结果校验器不是摆设它是质量监控的第一道关卡。6.3 独家避坑技巧先画“丑图”再“美化”最后一个技巧也是最容易被忽略的第一版架构图一定要画得像草稿不要追求完美。很多团队在架构评审会上花几个小时争论箭头是实线还是虚线、组件名字用“搜索引擎”还是“信息检索服务”这种争论毫无意义。架构图的本质是信息传递工具画给开发团队看、画给自己理清思路不是参加设计比赛。我自己的做法是先用铅笔或白板画出一个能解释通的草图用“模块箭头一句话注释”的格式。草图确认后再花十分钟用draw.io或excalidraw整理成电子版发给团队。这里有一个很重要的细节电子版架构图一定要带上“数据流方向”的标注让新加入的工程师能够顺着图读懂系统而不是靠问人。一个合格的架构图应该让一个不熟悉项目的人十分钟内回答出“用户请求到达后依次经过哪些模块”“哪些模块是强依赖哪些可以降级”这两个问题。写在最后的经验分享我个人的体会是AI应用架构设计跟传统软件架构最大的不同在于它需要同时处理“工程的确定性”和“模型的不确定性”。确定性的部分比如数据流、缓存、权限、限流、部署还可以沿用传统架构的经验不确定性的部分比如Prompt质量、模型波动、检索召回效果则必须在架构上留出缓冲和降级空间。画好一张AI应用架构图就是给这两部分划清边界让确定性的工程系统能承载不确定性的模型行为。还有一个小技巧是我做每一个项目都会用到的架构图不是画完就扔的它需要跟代码同步演进。每过半程或大版本迭代把当前架构图和实际代码对照一遍看有没有模块被悄悄跨层调用、有没有新增的依赖没有画进去。这个习惯看着简单但能让你始终对整套系统保持全局感不会走着走着就迷失在代码的细节里。希望这篇分享能对你手头的AI应用有点帮助——先画图再写码省下的是真金白银的返工时间。
阅读完成 · 觉得有帮助？
