1. 大模型三层架构到底在拆什么先把结论摆在最前面不管市面上冒出多少新名词——Agent、RAG、Function Calling、多模态、工作流编排——把它们全部拆开看本质上都落在三个位置上输入层怎么组织、模型层怎么选、输出层怎么处理。这三层构成了我所说的“大模型三层架构”。我做过不少AI应用落地的项目从最早的简单API调用到后来的知识库问答、智能体编排、多轮对话系统踩过的坑不算少。回头看真正决定一个AI应用好不好用的往往不是模型本身有多强而是你在输入层和输出层做了多少功夫。模型层反而是最“标准化”的一层——选一个合适的基座调好参数基本就那样了。这个三层架构的核心逻辑是这样的输入层决定你给模型“喂”什么。包括提示词设计、上下文组装、知识检索、历史对话管理、工具描述注入等。模型层决定用哪个模型、怎么调、要不要微调、推理参数怎么设。输出层决定拿到模型返回的原始文本之后怎么处理。包括格式解析、结构化提取、校验重试、后处理、多路融合等。为什么我要强调这个拆法因为很多刚入行的朋友一上来就盯着“用哪个模型”这个问题觉得换个更强的模型就能解决一切。实测下来完全不是这么回事。同一个模型输入层做得好和做得差输出质量能差出好几个档次。输出层加不加校验和重试线上故障率能差一个数量级。一个我反复验证过的经验在一个AI应用里模型层的工作量大概占20%输入层和输出层加起来占80%。但大部分人把80%的精力花在了那20%上。这套架构的适用面非常广。你做的是企业知识库问答也好智能客服也好代码助手也好甚至是用大模型做数据抽取、做内容审核、做报告生成拆开来看都是这三层。区别只在于每层的具体实现方式不同。下面我逐层拆开讲把每一层的核心细节、实操要点、常见坑都过一遍。2. 输入层决定模型上限的关键战场2.1 输入层到底包含哪些东西很多人对“输入”的理解就是“写个prompt”。这太窄了。在实际项目里输入层至少包含以下几个部分系统提示词System Prompt定义模型的角色、行为边界、输出规范。这是最顶层的设计决定了模型“是谁”。上下文组装把用户问题、检索到的知识片段、历史对话、工具描述等信息拼装成一个完整的输入序列。这里涉及拼接顺序、截断策略、优先级排序等问题。知识检索RAG如果应用需要基于外部知识回答检索环节的质量直接决定输入质量。检索做不好后面全白搭。对话历史管理多轮对话场景下保留哪些历史、丢弃哪些历史、怎么压缩都是需要设计的。少样本示例Few-shot在提示词里放几个输入输出示例引导模型按预期格式回答。工具/函数描述如果模型需要调用外部工具工具的名称、参数、描述怎么写在提示词里直接影响模型能否正确调用。这六个部分合在一起才是完整的“输入层”。任何一个环节出问题最终输出都会受影响。2.2 系统提示词的设计原则系统提示词是输入层的地基。我见过太多项目系统提示词写得含糊不清然后抱怨模型“不听话”。其实问题出在自己身上。写系统提示词我总结了几条实操原则第一条角色定义要具体不要泛泛而谈。“你是一个有用的助手”这种话等于没说。要具体到场景比如“你是一个面向电商客服场景的问答助手只回答退换货、物流、支付相关的问题其他问题一律引导用户联系人工客服”。第二条输出格式要明确最好给示例。如果你需要模型返回JSON不要只说“请返回JSON格式”而是直接给出JSON的结构模板。模型对结构化示例的遵循度远高于纯文字描述。第三条边界要写清楚。什么能做、什么不能做、遇到不确定的情况怎么处理这些都要在系统提示词里明确。否则模型会“自由发挥”在你不希望的场景下给出不该给的回答。第四条长度要控制。系统提示词不是越长越好。过长的系统提示词会占用宝贵的上下文窗口而且可能让模型“迷失”在大量指令中。我的经验是核心指令控制在500-1500字之间复杂场景可以到2000字但再长就要考虑拆分了。实操心得系统提示词写完之后拿10-20个典型问题测一遍看看模型是否按预期行为。如果发现偏差优先改提示词而不是换模型。2.3 上下文组装的顺序与截断策略上下文组装看起来简单——把东西拼起来就行——但实际上有很多讲究。拼接顺序通常遵循这个优先级系统提示词 工具描述 少样本示例 检索知识 对话历史 用户当前问题。为什么这么排因为模型对靠近输入末尾的内容注意力更强这是Transformer架构的特性决定的所以用户当前问题放在最后确保模型“记得住”。截断策略是另一个关键点。当所有内容加起来超过模型的上下文窗口时你必须决定丢弃什么。常见的策略有优先保留系统提示词和用户当前问题丢弃最早的历史对话。对检索知识做重排序只保留最相关的Top-K片段。对长历史对话做摘要压缩用摘要替代原始对话。我一般会做一个“token预算表”给每个部分分配固定的token上限超出就按策略截断。这样能保证输入永远不会溢出也不会因为某一部分过长而挤掉其他重要信息。组成部分建议token预算占比截断策略系统提示词10%-15%不截断超限则精简工具描述5%-10%按需加载不用的工具不注入少样本示例10%-20%减少示例数量检索知识30%-40%重排序后取Top-K对话历史10%-20%摘要压缩或滑动窗口用户当前问题5%-10%不截断2.4 知识检索的质量决定一切RAG检索增强生成是输入层里技术含量最高的部分。很多人以为RAG就是“把文档切块、存向量库、搜相似度”但实际做起来远不止这么简单。切块策略是第一道关。切太大检索到的片段包含太多无关信息干扰模型切太小可能丢失上下文导致片段含义不完整。我的经验是中文文档切块大小在300-500字之间比较合适同时要设置10%-20%的重叠区域避免关键信息被切断。检索方式也不能只靠向量相似度。纯向量检索在语义匹配上表现好但对精确关键词匹配比如产品型号、专有名词可能不够。我通常会用“向量检索关键词检索”的混合方案两路结果做融合排序。重排序是提升检索质量的关键一步。初步检索召回Top-20片段后用一个重排序模型可以是小模型也可以是交叉编码器对这20个片段做精细打分只取Top-3到Top-5注入上下文。这一步能显著减少无关信息对模型的干扰。踩过的坑早期做RAG时我直接拿向量检索的Top-5塞给模型结果经常出现模型被无关片段“带偏”的情况。加了重排序之后回答准确率提升了将近30%。2.5 对话历史管理的取舍多轮对话是很多AI应用的核心场景但对话历史不能无限增长。我的做法是分层管理最近3轮对话保留完整原文确保短期上下文连贯。3轮之前的对话用模型生成摘要压缩成一段简短描述。超过10轮的对话只保留摘要和关键实体信息如用户提到的订单号、产品名等。这样既控制了token消耗又不会让模型“失忆”。摘要的生成可以用便宜的小模型来做成本很低。3. 模型层选型、调参与微调的决策框架3.1 模型选型的核心考量维度模型层是三层架构里最“标准化”的一层但选型仍然需要认真对待。我通常从以下几个维度来评估能力维度模型在目标场景下的表现。比如做代码生成就看代码能力做中文问答就看中文理解能力。不要只看榜单分数要拿自己的实际数据测。成本维度包括API调用成本按token计费和自部署成本GPU资源。这两者的平衡点取决于你的调用量。调用量小的时候用API更划算调用量大了自部署可能更省。延迟维度首token延迟和整体生成延迟。对于实时交互场景如客服对话延迟要求高对于离线批处理场景如批量文档摘要延迟要求低。上下文窗口决定了你一次能输入多少内容。做长文档分析就需要大窗口模型做简单问答小窗口就够。可控性是否支持微调、是否支持结构化输出、是否有内容审核机制等。考量维度轻量场景中等场景重度场景推荐方案API调用小模型API调用中模型或自部署小模型自部署中大型模型成本敏感度高中低延迟要求低中高典型场景内容分类、简单问答知识库问答、摘要生成复杂推理、代码生成3.2 推理参数怎么调才合理模型推理时有一堆参数可以调temperature、top_p、top_k、max_tokens、frequency_penalty、presence_penalty等。很多人要么全用默认值要么乱调一通。我来说说每个参数的实际影响和推荐设置。temperature控制输出的随机性。值越高输出越多样值越低输出越确定。做事实性问答时设0-0.3做创意写作时设0.7-1.0。我一般默认设0.1-0.3保证输出稳定。top_p核采样控制候选词的范围。通常和temperature二选一调不要同时大改。默认0.9-0.95比较稳妥。max_tokens最大输出长度。设太小会导致回答被截断设太大浪费资源。根据场景预估一般设512-2048之间。frequency_penalty和presence_penalty控制重复。做长文本生成时适当加一点0.1-0.5做短回答时保持0。实操心得调参这件事先固定其他参数只调一个观察效果变化。不要一次改好几个参数否则出了问题都不知道是哪个引起的。3.3 什么时候该考虑微调微调不是万能药。我见过很多团队一上来就想微调结果发现效果还不如好好写提示词。我的判断标准是该微调的信号提示词已经优化到极限效果仍然不达标。需要模型学习特定的输出格式或风格且少样本示例无法稳定实现。有大量高质量标注数据至少几百到几千条。需要压缩模型体积用大模型蒸馏到小模型。不该微调的信号只是想让模型“知道”一些新知识——用RAG更合适。标注数据不足或质量不高——微调反而会让模型变差。需求还在频繁变化——微调一次成本不低需求变了就白费。微调的技术路线选择上LoRA和QLoRA是目前最实用的方案对显存要求低训练速度快效果也能接受。全量微调只有在数据量很大、效果要求极高时才考虑。3.4 模型层的容灾与降级设计线上系统不能只依赖一个模型。我的做法是至少配置两级降级主模型能力最强负责处理大部分请求。备用模型能力稍弱但更稳定或更便宜主模型超时或报错时接管。兜底策略所有模型都不可用时返回预设的兜底回复而不是让用户看到错误页面。这套机制在模型服务出现波动时特别管用。我经历过几次模型API临时不可用的情况因为有降级设计用户基本无感知。4. 输出层最容易被忽视但最影响体验的一环4.1 输出层要解决的核心问题模型返回的是原始文本但你的应用需要的是结构化、可校验、可用的数据。这中间的差距就是输出层要填补的。输出层要解决的核心问题包括格式解析模型返回的可能是JSON、Markdown、纯文本甚至是混合格式。你需要稳定地从中提取出需要的信息。结构校验解析出来的数据是否符合预期结构字段是否齐全类型是否正确内容校验内容是否合规是否包含敏感信息是否偏离了预期主题失败重试解析失败或校验不通过时怎么处理重试降级还是返回错误后处理对模型输出做进一步加工比如格式化、翻译、拼接、去重等。这一层做得好不好直接决定了用户体验。模型偶尔“胡说八道”不可怕可怕的是你把它的“胡说八道”直接展示给了用户。4.2 结构化输出的可靠实现方案让模型输出JSON是常见需求但模型经常会在JSON外面包一层解释文字或者漏掉字段或者格式出错。我的应对方案是第一层提示词约束。在系统提示词里明确给出JSON schema并强调“只返回JSON不要有任何其他文字”。第二层解析容错。写一个健壮的解析器能处理常见的格式偏差。比如用正则提取第一个{到最后一个}之间的内容再尝试解析。第三层校验重试。解析成功后校验字段完整性和类型正确性。不通过则把错误信息拼回提示词让模型重新生成。重试最多2-3次。第四层兜底默认值。重试仍然失败时返回一个预设的默认结构并记录日志供后续分析。import json import re def parse_model_output(raw_text, schema, max_retries3): for attempt in range(max_retries): # 尝试提取JSON match re.search(r\{.*\}, raw_text, re.DOTALL) if not match: raw_text retry_generation(raw_text, 未找到JSON结构) continue try: data json.loads(match.group()) except json.JSONDecodeError as e: raw_text retry_generation(raw_text, fJSON解析失败: {e}) continue # 校验字段 missing [k for k in schema if k not in data] if missing: raw_text retry_generation(raw_text, f缺少字段: {missing}) continue return data return get_default_output(schema)这段代码是我在实际项目中反复打磨出来的核心思路就是“提取-解析-校验-重试”四步循环。你可以直接拿去改改用。4.3 输出内容的质量把关格式对了不代表内容对了。输出层还需要做内容层面的把关敏感信息过滤检查输出是否包含手机号、身份证号、银行卡号等敏感信息有则脱敏或拦截。主题偏离检测判断输出是否偏离了预期主题。简单做法是用关键词匹配复杂做法是用另一个模型做判别。事实一致性校验如果应用场景对事实准确性要求高可以把输出和检索到的知识做比对检查是否有矛盾。长度控制输出过长时截断过短时补充或重试。这些检查不需要每个都做根据你的场景选择。但敏感信息过滤我建议所有面向用户的应用都加上这是底线。4.4 流式输出的处理技巧很多应用需要流式输出逐字显示提升用户体验。但流式输出给输出层带来了额外挑战你拿到的是不完整的文本片段无法直接做JSON解析。我的处理方式是“边收边缓存收完再解析”。具体来说流式阶段只做简单的文本展示不做结构化解析。流结束拿到完整文本后再走正常的解析校验流程。如果需要流式展示结构化数据可以设计一种“流式友好的格式”比如每行一个JSON对象JSONL收到一行就解析一行。注意流式输出时如果中途出错已经展示给用户的内容无法撤回。所以流式场景下要格外注意内容审核的前置化——能在输入层拦住的不要等到输出层。4.5 多路输出的融合策略有些场景下你可能会让模型生成多个候选输出然后选最好的一个。或者用多个模型分别生成再做融合。这就是输出层的“多路融合”。常见的融合策略有投票法多个输出中取多数一致的结果。适合分类、选择题等有确定答案的场景。打分法用一个评分模型给每个输出打分取最高分。适合生成类场景。拼接法把多个输出的优点拼在一起。适合摘要、报告生成等场景。交叉验证法用一个输出去验证另一个输出的事实性。适合对准确性要求极高的场景。多路融合的代价是成本翻倍所以只在对质量要求极高的场景下使用。5. 三层架构的联动与常见问题排查5.1 三层之间的信息流与反馈闭环三层不是孤立的它们之间存在信息流动和反馈闭环。输入层的问题会导致模型层“巧妇难为无米之炊”——检索不到相关知识模型再强也答不对。模型层的问题会导致输出层“垃圾进垃圾出”——模型生成的内容本身就有问题后处理再厉害也救不回来。输出层的问题会导致“最后一公里”失败——内容都对但格式错了、校验没过用户还是用不了。我习惯在每层都埋监控点输入层记录每次请求的token消耗、检索命中率、上下文截断情况。模型层记录延迟、错误率、token生成速度。输出层记录解析成功率、校验通过率、重试次数。这些数据汇总起来就能快速定位问题出在哪一层。比如解析成功率突然下降那大概率是模型输出格式变了需要检查是不是模型版本更新了或者提示词被改动了。5.2 常见问题速查表现象可能原因排查方向解决方案回答不准确检索知识无关检查检索Top-K结果优化切块和重排序回答格式错误提示词约束不够检查系统提示词增加格式示例和强调回答被截断max_tokens太小检查输出长度分布调大max_tokens响应太慢模型太大或输入太长检查各层耗时换小模型或压缩输入重复回答历史对话管理不当检查对话历史加摘要压缩或滑动窗口调用工具失败工具描述不清检查工具定义完善参数说明和示例内容不合规输出层过滤缺失检查审核逻辑增加敏感词和模型审核这张表是我在实际运维中慢慢积累出来的基本上覆盖了80%的常见问题。遇到问题时先查表能省不少时间。5.3 性能优化的几个实用手段三层架构的性能优化我通常从这几个地方入手输入层优化压缩系统提示词、减少不必要的少样本示例、对检索结果做更严格的筛选。输入token少了推理速度自然快。模型层优化用推理加速框架如vLLM、TensorRT-LLM、开启量化INT8/INT4、使用KV Cache复用。这些手段能显著降低延迟。输出层优化解析和校验逻辑尽量轻量避免在关键路径上做复杂计算。重试逻辑要设上限避免无限循环。缓存策略对高频相同或相似请求做缓存。输入层可以做语义缓存相似问题命中同一缓存输出层可以做结果缓存。一个容易被忽视的优化点把输出层的校验逻辑做成异步的。先返回结果给用户校验在后台跑发现问题再异步修正或告警。这样用户感知的延迟会低很多。5.4 从三层架构看AI应用开发的岗位需求聊到这里顺便说说AI应用开发这个岗位。现在市面上招AI应用开发工程师的团队越来越多但要求差异很大。有的岗位其实只是“调API”——把模型接口封装一下做个简单的对话界面。这种岗位技术含量不高可替代性强。有的岗位则要求全栈能力——既要懂输入层的提示词工程和RAG又要懂模型层的选型和调参还要懂输出层的工程化处理。这种岗位才是真正有价值的。我的建议是不管你现在做的是哪一层都要把三层都摸一遍。只懂提示词的人容易被替代只懂模型部署的人路会越走越窄。三层都懂的人才能独立负责一个AI应用的完整落地。学习路线上我建议按这个顺序先搞懂输入层的提示词设计和RAG这是最容易上手也最见效果的然后了解模型层的基本原理和选型逻辑最后深入输出层的工程化处理这是区分“demo”和“产品”的关键。6. 一些实操中的个人体会做AI应用落地这段时间最大的感受是模型能力是天花板但工程能力决定你离天花板有多近。同一个模型在不同团队手里做出来的产品体验可以天差地别。差距不在模型本身而在三层架构的每一层细节里。输入层里一个精心设计的系统提示词能让模型表现提升一个档次。输出层里一个健壮的解析重试机制能让线上故障率降低一个数量级。这些都是“脏活累活”但恰恰是这些活决定了产品的可用性。另一个体会是不要追求一步到位。我见过太多团队想一开始就把三层都做到完美结果迟迟上不了线。正确的做法是先跑通最小闭环——输入层用最简单的提示词模型层用API调用输出层直接展示原始文本——然后根据实际反馈逐步优化每一层。最后分享一个小技巧每次优化只改一层的一个点改完立刻用同一批测试用例验证效果。这样你才能清楚地知道每个改动带来了多少提升。同时改多个地方效果好了不知道是哪个起了作用效果差了也不知道是哪个拖了后腿。这套三层架构的拆法我在多个项目里反复验证过不管是做知识库问答、智能客服、内容生成还是数据分析都能套用。希望对你有所启发。