大模型三层架构拆解所有 AI 新花样只在「输入什么 / 输出怎么处理」最近很多人问我大模型每天都能冒出新玩法今天做智能客服明天做报告生成后天又搞了个自动写代码工具这些到底是怎么做到的是模型又升级了其实大部分时候模型根本没变。你看到的那些让人眼前一亮的“AI 新花样”绝大多数是在模型的入口和出口下功夫。我做了几年大模型应用开发习惯把所有工作拆成三层输入处理层、模型内核层、输出处理层。搞懂这三层你就不再需要追着热点跑因为所有花活本质上只是在回答两个问题你给模型喂了什么你从模型吐出来的东西里做了什么这篇文章适合正在做 AI 应用、或者想把大模型真正用起来的人不管你是产品经理还是开发者都能从中找到一套思考框架。我会从原理讲到实操最后给一些踩过坑的经验保证你看完能拿着这套思路去拆解任何 AI 产品。1. 先建一张框架图大模型的三层架构到底是什么很多人把大模型理解成一个巨大的黑盒子输入一句话输出一句话中间全是神经网络。这个理解没错但对做应用的人来说太粗了。真正需要分清的是哪些东西是模型负责的哪些东西是你负责的。我的划分方式很简单输入层、内核层、输出层。1.1 我习惯把模型拆成“入口、内核、出口”三层入口层输入处理指的是在模型真正计算之前你为这次调用准备的所有内容。包括提示词怎么写、上下文怎么拼、历史对话怎么组织、外部文档怎么检索进来、用户的问题怎么被重新表述。这一层完全由你控制模型本身不参与。内核层模型推理指的是模型内部的参数和计算过程。对于大多数应用开发者来说这层就是 API。你发过去一段拼接好的文本模型基于预训练和微调学到的能力计算出一个概率分布然后从这个分布里采样生成文字。这个过程你无法干预除非你做微调或蒸馏那是另一个层级的工作。出口层输出处理指的是模型吐出来原始文本之后你做的所有事儿。包括解析 JSON、提取字段、过滤敏感词、把结果重新排版、把一段话拆成结构化数据、把输出的文字喂给另一个系统执行动作。很多产品真正体现体验差异的地方就在这一层。1.2 三层架构的核心逻辑一切应用创新都在输入和输出的加工上为什么说“所有 AI 新花样”都和输入输出有关因为模型内核的变化非常慢。你用的模型可能几个月甚至一年才升级一次但应用每天都在变。同一个模型你可以让它做客服、做翻译、做 SQL 生成、做角色扮演靠的完全是不同的输入构造和输出解析。我举个夸张的例子同样一个通用模型给它一段“你现在是数据库专家只输出 SQL”的输入再把用户自然语言问题附在后面它就能变成 SQL 生成器。然后你在输出层加上一个正则校验发现它生成了“SELECT * FROM users”就直接执行如果生成了错误的命令就重新生成。整个过程模型内核一点没动但产品形态完全变了。这就是三层架构的意义把变化留给输入输出把稳定留给内核。理解了这一点你再去看任何 AI 产品时就会自动去想它到底在入口做了哪些加工在出口做了哪些整理内部是不是还是那个通用模型2. 输入层决定模型“听懂了什么”输入层是最容易被低估的部分。很多人觉得写提示词就是“把话说清楚”其实不是。模型不是人它没有“理解”能力它只是在做概率预测。你给它一段文本它会根据统计规律续写最可能的下一段。所以输入的构造方式直接决定了续写方向。2.1 提示词不是咒语是上下文管理传统软件是有状态的你定义好变量和函数程序按逻辑执行。大模型不一样它每次调用都是“无状态”的——你给什么它回什么它不记得你之前说了什么除非你把历史都塞进去。因此提示词的核心作用就是你想让模型从哪个概率空间里采样就把相关语料放在它的上下文里。举个例子。你只输入“给我写一篇博客”模型可能给出任何主题、任何风格的文本。但如果你输入你是一位技术博主擅长用通俗语言解释复杂概念。请给我写一篇博客主题是“大模型的注意力机制”目标读者是完全不懂 AI 的普通用户字数 800 字。要求先讲一个生活化比喻再解释原理最后给出一个简单案例。模型续写出来的内容就会非常不一样。不是模型变聪明了而是你通过输入把它的预测空间从“所有中文文本”缩小到了“技术博客风格的文本”。所以我常说提示词的本质是上下文管理而不是魔法咒语。理解了这句话你就知道为什么“提示词工程”要不断迭代——因为你在控制模型的采样空间。2.2 输入层的高级玩法检索增强与记忆注入上下文管理再往前走一步就是检索增强生成RAG。RAG 的本质是在模型回答之前先把相关信息从外部知识库里检索出来拼到输入里。为什么这么干因为模型的内部知识是有限的它不知道你公司内部文档、你的数据库记录、最新新闻。你不可能每问一个问题就把整个知识库塞给模型只能根据用户问题把最相关的几段内容检索出来放进输入。具体流程是用户提问 - 把问题向量化 - 在向量数据库里找到相似文档 - 把文档片段和问题一起作为输入发给模型 - 模型基于给定文档回答。这一整套动作全部发生在输入层。我实测下来RAG 比反复让模型“记住”某个事实要可靠得多原因是模型没有任何真正意义上的记忆你喂给它什么它就只能用什么。和 RAG 类似的还有“记忆注入”比如在每轮对话前先把你之前记录的用户偏好拼进输入历史信息用户小张偏好简洁回复不喜欢表情符号上次咨询过退款政策。 当前问题发票怎么开这样模型自然会在回答时带上小张喜欢的风格。你说这是模型有记忆吗不是是输入层替模型“装”了一个记忆。2.3 输入层实操要点结构化输入、角色设定、示例引导输入层做得好的团队会把提示词当成代码来维护。我自己常用的几个技巧第一结构化输入比大白话可靠。把背景信息、指令、约束分块用清晰的标记区分。比如[系统] 你是一个合同审核助手。 [材料] {合同原文} [任务] 请找出合同中的风险条款并用中文列出。 [要求] 每条风险给出严重程度高/中/低和建议修改方式。这样模型更容易按照你期望的结构输出也方便程序去解析。第二少样本示例Few-shot永远比单纯描述好使。如果你希望模型输出固定格式不要只写“按以下格式输出”直接给它两个真实例子更好。比如输入明天北京天气如何 输出{城市: 北京, 查询: 天气, 日期: 明天} 输入帮订一张周五从上海到成都的机票。 输出{出发: 上海, 到达: 成都, 日期: 周五, 类型: 机票}模型看到模式后会模仿模式。这种能力很神奇你不需要解释“键是什么、值是什么”它自己会从例子里学。第三别忽视输入长度的限制。上下文窗口是有限的输入越长模型的响应质量和速度都会受影响。如果把整个知识库都塞进去模型可能会被噪音干扰。我之前做某项目时一开始把所有销售话术都放进输入模型回答质量反而变差因为关键信息被其他内容淹没了。后来改成先检索、再拼接效果立刻好了。输入层的核心能力是判断什么该给模型看什么不该给。这比“怎么把话说得漂亮”重要得多。3. 输出层决定模型“说得好不好”模型吐出来的是一段原始文本但产品需要的往往是干净、可解析、可执行的东西。输出层做的就是把这段自由文本“驯化”成真正可用的结果。很多开发者只关注提示词却忽略了输出层同样需要精心设计。3.1 解码参数温度、Top-P、Max Tokens 的真实影响在输出层最基础的控制是解码参数。温度temperature控制随机性温度越低概率越高的词被选中输出越确定温度越高越可能选到生僻词输出越有创造性。Top-P 也类似它控制采样时只考虑累积概率到达某个阈值的词。Max Tokens 限制输出长度。用场景来说你让模型做信息抽取、判断、生成 SQL温度设成 0 或者 0.2 最合适因为你需要稳定答案。你让模型写营销文案、写故事、做头脑风暴温度设成 0.7 到 0.9 更合适。有些产品为了追求千篇一律的“稳定感”把所有场景都设成低温结果就是文案干巴巴、创意完全出不来。输出参数不是固定值而是产品形态的一部分。我在实际项目中还会配合“重复惩罚”等参数来减少复读机现象。但请注意这些参数是输出层的“粗调”。真正让输出质量产生质变的是后面的结构化处理和解析。3.2 结构化输出和后处理把自由文本变成可用产品这里是我最想强调的一点模型的输出不是产品的终点而是半成品。做应用时几乎没有人直接展示模型的原始输出而是会做大量后处理。举例来说你想让模型从一篇文章里提取出“公司名、金额、日期”。你可以要求模型输出 JSON请从文本中提取信息并严格按照以下 JSON 格式返回 {公司名称: , 合同金额: , 签署日期: }但模型偶尔会在 JSON 前后附带解释性文字或者 JSON 本身非法缺少逗号、多余引号。如果你直接把字符串丢给json.loads()大概率报错。这时候输出层的价值就来了你要么用正则从响应中截出 JSON 片段要么用更宽容的解析器去容错。更稳妥的方案是在提示词里再做一层“保险丝”比如加上一句“只输出 JSON不要输出任何其他内容”然后在代码里保留解析失败的补救逻辑。再进一步如果模型输出的是 Markdown 表格或列表你可以用程序把它转换成 HTML、Word、PDF。很多“AI 生成 PPT”“AI 生成报告”类产品本质上就是模型负责生成文字和结构程序负责渲染成文件格式。输出层的想象力远比你想的大。3.3 输出层常见应用流式输出、函数调用、安全过滤流式输出Stream是很影响体验的功能。模型不是一次生成完整答案而是逐个 token或小块返回。你可以把它比喻成打字机效果。实现流式的好处是用户不用等 5 秒才能看到第一个字而是 0.5 秒后就开始看到内容。对聊天产品来说这个感知差异极大。不过流式也带来新问题因为内容是逐步到达的你没法一次性对完整输出做后处理。所以很多产品会做“边生成边缓冲”的方案先展示等全部完成后在后台再做修正和标记。函数调用Function Calling / Tool Use是输出层的另一种高级玩法。它让模型在生成文本时同时选择是否调用某个函数并输出符合函数签名的结构化参数。举个例子可用函数get_weather(city, date) 用户输入北京明天冷吗 模型输出调用函数 get_weather(city北京, date明天)这种方式让模型不只是“说话”还能“做事”。你的程序收到模型输出的函数名和参数后去调用天气 API再把结果反馈给模型让模型生成最终回答。整套链路里模型内核没变完全靠输入层的“函数定义”和输出层的“函数解析”实现了智能助手的能力。还有一个不能忘的是安全过滤。模型可能输出攻击性内容、幻觉数据或者不合适的词汇。输出层可以加关键词过滤、敏感信息脱敏、内容审核接口。这不是为了限制模型而是为了让产品合规、稳健。4. 中间层模型内核的“不变”与“微变”很多人在输入输出上折腾半天后会遇到一个瓶颈模型本身的某种能力确实没有怎么办这时候才轮到中间层——模型内核——上场。但动手之前你得先搞清楚什么情况该动内核什么情况不该动。4.1 为什么说模型层基本是“黑盒”对于使用 API 的人来说模型内核是一套固定的权重参数。你发请求它推理。除了供应商偶尔更新版本你没有任何办法直接改变这个黑盒。它的优点就是通用什么都会一点缺点也是通用什么都不太专精。比如你用通用模型做法律文档审核它可能对专业术语的理解不够准确。但你很少因此就直接去微调模型因为成本高、周期长、维护麻烦。更尴尬的是模型内部到底怎么“思考”的连研究者也很难完全解释。你问它“22 等于几”它能答出来但你问它“为什么这个逻辑不对”它可能洋洋洒洒解释一大堆实际上还是错的。这就是黑盒属性。我们能做的就是通过输入输出两层把模型的潜力压榨出来。4.2 微调、LoRA与RAG的关系什么时候才需要动模型先明确一个原则能在输入层解决的问题就不要动模型。想让模型知道某件事实用 RAG把事实写进输入。想让模型模仿某种语气在提示词里给例子。想让模型总是输出特定格式用少样本提示词。这些方法零成本、可迭代、可回滚。只有在以下场景才考虑微调你需要模型持续稳定地模仿某种特定文风或任务而提示词太长、太贵你需要模型掌握输入层无法描述的行业缩写、专有术语和规则你需要降低推理成本想用一个更小的模型达到原本通用大模型的效果。LoRA低秩适配是现在最流行的微调方式。它不动原模型的全部参数只训练一小部分适配器成本低。比如你有一个法律问答场景你可以用一批“问题-标准答案”数据训练 LoRA让模型更懂术语。但即使如此我仍然建议先从 RAG 加提示词开始。因为微调之后模型可能“学坏”——在训练数据不足时它可能记住噪声泛化能力下降。RAG 则不会污染模型本身的权重。还有一个常见误区把 RAG 和微调对立起来。实际上它们可以配合使用。RAG 负责给模型“查资料”微调负责教模型“怎么按你的口味写”。比如我先用 RAG 检索出产品相关条款再用微调后的模型以特定格式总结出来。两者分工明确效果远好于单用某一种。5. 实战拆解同一个模型如何做出不同应用理论讲多了容易飘我必须带你看三个具体场景演示三层架构如何落地。这三个场景我都实际做过讲清楚每一步是在哪一层做的、为什么。5.1 场景A让模型从“聊天”变成“结构化信息抽取”目标用户输入一段自然语言比如“帮我约明天下午三点和张总开会”程序要解析出结构化日历信息标题、时间、参与人。模型内核只是通用对话模型。输入层构造[系统] 你是一个日程助手。从用户话术中提取结构化信息。 [可用字段] 标题、开始时间、结束时间、参与人。 [规则说明] 时间格式使用YYYY-MM-DD HH:MM如果缺少结束时间默认开始时间后1小时如果缺少参与人填写“未指定”。 [示例] 用户帮我订周五晚上七点和李总吃饭 输出{标题:和李总吃饭,开始时间:周五 19:00,结束时间:周五 20:00,参与人:李总} [待解析内容] 帮我约明天下午三点和张总开会输出层处理模型返回一段 JSON 文本但偶尔会在 JSON 外加上“好的我已经提取了以下信息”之类的前缀。我在代码里先截取第一个{到最后一个}之间的内容再尝试解析。解析成功后还要做时区归一化“明天”不能直接进数据库得在程序里计算成具体日期这一步也是输出层。最终程序把解析后的 JSON 写入日历 API。整个过程模型内核完全没变但你得到的是一个好用的“短信语义解析器”。5.2 场景B让模型从“单轮对话”变成“多步工具调用”目标做一个能帮用户查天气、订酒店的客服机器人。光靠单轮问答不行必须支持多步动作。输入层构造在提示词里给模型声明可用工具[可用工具] search_flight(出发地, 目的地, 日期) search_hotel(城市, 入住日期, 离店日期) book_flight(航班号) [规则] 当用户请求涉及以上功能时必须输出 JSON{tool: 函数名, params: {参数}}。如果缺少必要参数先向用户询问。用户说“我周五要去上海帮我看看航班。”模型输出{tool: search_flight, params: {出发地: 北京, 目的地: 上海, 日期: 周五}}。输出层处理程序解析出函数名和参数后调用真实航班查询 API。拿到结果后再把它拼进输入层发送第二轮请求[已有航班结果] CA123 北京-上海 09:00-11:00票价1200元。 [用户问题] 那订这班吧。模型基于给定的航班结果输出{tool: book_flight, params: {航班号: CA123}}。程序再次调用订票 API。这个循环在输入层和输出层之间多次往返模型的“多步能力”其实是你通过程序支持出来的。你说它是 AI 智能我更愿意说是架构流程智能。5.3 场景C让模型从“生成文本”变成“生成图像/语音的指令”目标用户说“给我画一只在月球上打篮球的猫”程序最终要调用另一个图像生成模型。大语言模型本身不会画图但它可以生成绘图模型的提示词。输入层构造[系统] 你是一个提示词翻译器。把用户的自然语言描述转换成适合图像模型的英文提示词要求包含主体、场景、风格、光影等关键信息。 [用户输入] 一只猫在月球上打篮球模型输出类似A cute cat playing basketball on the moon, outer space background, cinematic lighting, 8k resolution。这就是一个典型的输出层“再加工”案例你把模型生成的提示词直接传给图像生成 API就能得到图片。同样如果你想让模型生成语音播报也可以在输入层指定“把下面文本转成口语化播报稿”输出层再调用 TTS。本质上大语言模型成了“多模态任务的编排中枢”而它自己只做了一件事根据输入输出文本。6. 常见问题与避坑技巧做输入输出处理这几年我踩过不少坑。挑几个最常见的做成速查表希望你少走弯路。6.1 输入太长被截断怎么办问题表现模型回答时明显丢失了输入末尾的信息甚至直接复述输入开头的内容。原因很简单上下文窗口有限输入超过限制就会被截断。解决办法不是盲目压缩而是做优先级排序。把最关键的内容放在输入的开头和结尾因为模型对这两个位置的注意力较强把容易丢失的中段放历史记录或次要资料。如果资料实在太多先用 RAG 检索出最相关的片段而不是全部塞进去。还要注意观察 token 消耗很多产品上线后成本飙升就是因为每次请求都携带了大量无用上下文。6.2 输出乱码、JSON解析失败怎么办模型输出不是程序约定它是概率生成所以“偶尔不守规矩”是常态。我之前做某个项目模型返回的 JSON 里出现了换行符和中文标点导致json.loads直接崩溃。解决方法分几层第一层是格式约定在提示词里明确“输出必须是纯 JSON不要 markdown不要注释”第二层是后处理用正则剥离多余前缀后缀或者写一个容错解析器把单引号换成双引号、去掉尾随逗号第三层是失败重试如果解析失败把“你刚才的输出格式不符合要求请重新输出”拼在历史后面再请求一次。后面这种办法实测非常有效。6.3 模型“能力不够”时先别急着微调几乎所有新人都会犯的一个错模型表现不好第一反应是“模型太笨换更大的模型或者微调”。但仔细排查后会发现90% 的情况是输入没写好或者输出后处理没兜住。比如模型不会做数学题可能是你输入的题目格式不对模型无法回答某领域问题可能是你没给它相关上下文模型输出格式老变可能是你少给了示例。我的建议流程是先优化提示词再加上少样本例子然后考虑 RAG最后才是微调。每一步都能在 10 分钟内验证而微调动辄要准备数据、训练、评估成本和风险高一个量级。在模型内核上做文章永远是最后一张牌。我个人最深的体会是大模型应用的工程难点从来不在“模型有多聪明”而在于你愿不愿意在输入和输出两条路上把它伺候好。输入决定了它的上限输出决定了产品的下限。你把这两层的细节打磨好哪怕用的模型再普通也能做出体验不错的产品。下次看到一个刷屏的 AI 应用不妨按三层架构拆一下你会突然发现很多炫酷效果背后的原理真的就一句话把输入包装好把输出处理好剩下的全是工程。