大模型三层架构拆解：输入与输出才是应用创新的主战场

如果你最近一直在追大模型应用开发的热点可能会觉得底层技术一天一个样。但我要说句实话把所有 AI 新花样拆开看绝大多数动作都发生在同一个三层架构的两端——输入什么、输出怎么处理。中间那层模型本身反而稳定得让人有点意外。这篇东西我想写给两类人一是被各种新名词绕晕的开发者想知道 RAG、Agent、结构化输出这些概念到底在解决什么问题二是已经在用大模型做项目、但总觉得效果不稳定的朋友。把这三层架构看清楚了你会发现很多产品的“创新”并没有想象中神秘你调优的思路也会清晰很多。1. 拆一次真实调用三层架构立刻浮出水面很多人把大模型当成一个黑盒只知道发消息、收回复。但如果把一次真实的 API 调用展开看三层架构其实非常直观。# 伪代码用你习惯的HTTP客户端实现均可 resp post( https://api.example.com/v1/chat/completions, { model: some-chat-model, messages: [ {role: system, content: 你是客服助手请用简洁中文回答。}, {role: user, content: 我的订单三天没发货怎么办} ] } ) answer resp.choices[0].message.content这段代码里模型层的存在感其实很弱。真正决定这次调用质量的是三块东西你往messages里塞了什么这就是输入层也叫输入适配层some-chat-model指代的那个参数巨多的网络这是模型层负责把输入 token 序列映射成输出 token 概率分布resp.choices[0].message.content拿到手之后你还要做的解析、校验、过滤、格式化这是输出层。注意一个容易被忽略的事实从系统架构角度看模型层是一个“一次前向推理 迭代解码”的固定流程它不像传统软件那样可以你随意改逻辑。你能干预它的方式只有两处进入它之前的信息编排和离开它之后的结果加工。1.1 请求里的每个字段都对应架构的一层把一次请求的要素归归类你会发现它们并不复杂请求/响应要素对应架构层它在干什么system 消息输入适配层定义任务角色、输出规范、话术边界user 消息输入适配层携带用户问题、检索材料、few-shot 示例tools / functions输入适配层给模型一张“它能调用什么工具”的清单model模型执行层指定用哪套网络权重做推理temperature / top_p输出处理层控制采样随机性的小旋钮content模型层原始产物按概率采样出来的 token 序列后处理代码输出处理层解析、校验、回填、再格式化有朋友会问temperature 也被算成输出层对。它不改变模型权重也不改变输入 token它只改变从 logits 到结果的采样方式本质上是“输出端怎么从候选词里挑一个出来”的规则。1.2 为什么说“新花样”都发生在模型的左右两侧拿现在最常听到的几个名词套一下提示词工程改的是输入消息的写法RAG把检索到的资料拼进输入上下文Agent“工具清单 历史轨迹”被写进输入模型输出侧再解析“是否调用工具”结构化输出在输出侧对 token 生成做约束要求它必须符合 JSON 语法多模态理解图像/音频先被编码成模型能读的 token再拼进输入序列。你会发现这些玩法没有一个是去改 Transformer 内部的某一层结构。它们全都在做两件事往输入里多塞信息、对输出做更强的控制与加工。这正是这篇文章想表达的“三层架构拆解”真正有用的地方。2. 中间那层为什么很稳定模型本体的边界与约束中间那层最容易被神话也最不值得你天天盯。它是整个系统的“推理核心”但它的工作范式简单到能一句话概括接收一串 token预测下一个 token。2.1 自回归生成一切能力都折叠在“预测下一个 token”里当前主流的大模型基本都是自回归架构。无论你让它写诗、做数学题、抽取合同里的日期还是规划一次旅行它的底层行为都一样根据已有的 token 序列计算词表上每个 token 出现的概率选一个出来拼到末尾再重复这个过程。你可以把它理解成一个“特别会接话的人”。你给它前半段它接后半段你给的前半段质量直接决定它后半段的质量它接出来的话可能很长、很啰嗦需要你在它说完之后自己整理重点。这个特性解释了很多工程现象。为什么提示词里写“请一步一步思考”会有效因为你在输入前缀里塞进了“需要输出推理步骤”的潜在 token 分布模型在接话时会倾向于先生成推理内容。为什么输出 token 太长会花更多钱因为每生成一个 token模型都要做一次前向推理还涉及缓存读取。中间层很稳定本质就是“接话”这个推理范式没有变。参数规模、训练数据、对齐方式的差异影响的只是“接话水平”而不是“接话方式”。2.2 KV Cache 和上下文窗口决定了为什么“输入什么”如此重要很多人以为模型的上下文窗口是一块“免费的无限内存”能塞多少就塞多少。实际上上下文越长KV Cache 占用的显存越大计算量也会明显上升。KV Cache 解决的是“重复计算”的问题。生成第 N 个 token 时注意力需要计算当前 token 与前面所有 token 的关系。如果不缓存每走一步都要重新算一遍历史 token 的 Key 和 Value代价爆炸。缓存之后历史结果被留着复用但代价是显存占用随序列长度线性增长。所以输入侧的设计不是风格问题而是实实在在的性能和成本问题。同样一个回答你把 few-shot 示例从 3 条加到 20 条输入 token 可能翻好几倍接口延迟和账单都会跟着涨。RAG 也不能无脑把整个知识库塞进去经常是“塞进去一大堆模型该看的没看到不该看的全看了”。这里有个很多项目踩过的坑上下文窗口标的数字很大但实际单次请求塞满了窗口后不仅慢还容易让模型“迷失在长文本里”最后答非所问。输入侧要做信息筛选而不是信息堆砌。2.3 微调算不算改模型算但改的也只是“映射偏好”有人会说那微调Fine-tuning不是改模型了吗微调确实改权重。但要想清楚一件事微调改的是模型输出内容的偏好和风格并没有改“输入到输出的推理范式”。你把一批特定格式的数据喂进去训练本质是让模型更适应“你设计的输入输出映射”。工程上可以用 LoRA 这类低成本方案实现但模型的计算流程、注意力机制、词表接口都没动。真正动中间层“骨架”的是那些底层架构层面的探索比如新一代注意力机制、状态空间模型、稀疏专家混合结构等。这类技术确实在演进但它属于基础模型研发的另一个维度和我们日常调接口、做应用不是一回事。拿它来抬杠没意义。对绝大多数业务开发者来说模型层就是一个“可以替换、但内部不必操心”的黑盒。3. 输入层所有聪明手段都是在“喂什么”上做文章输入层是整个三层架构里最热闹的战场。过去一年里冒出的新玩法大半都发生在这里。3.1 提示词工程把约束写进前缀就是在干预解码路径提示词工程不是玄学。它的本质是通过修改输入 token 序列影响模型后续生成 token 的概率分布。你可以在 system 消息里写“你是客服助手请用简洁中文回答”这是在给整段对话定基调。你可以提供 2 到 3 条用户提问和标准答案作为 few-shot 示例这相当于给模型看了“正确接话”的样板。你还可以说“请先分析原因再给出解决方案”这是在引导模型先走一段推理路径再落到答案上。实践下来有一条很实用的经验正面写“要做什么”比负面写“不要做什么”更稳定。比如“请直接输出结论不要输出过程”这种写法经常失效模型还是会带一堆解释更好的做法是给一个明确的输出模板告诉它“答案格式为结论 依据 建议”它反而更听话。原因也简单模型训练数据里正面指令对应的示范数量远多于负面指令。负面命令在 token 分布层面没有足够强的引导力容易被原始文本风格带跑。3.2 RAG 的本质把数据库临时写进上下文RAG检索增强生成看起来很高端拆开就是三条流水线先把你自己的文档切碎、向量化、存起来用户提问时把问题也向量化去库里召回最相关的片段最后把召回的片段拼到用户消息前面让模型基于这些材料回答。关键点在于模型本身的参数记忆里没有你的私有数据你只有通过输入层把材料喂进去它才“看得到”。所以 RAG 的效果上限由输入侧的检索质量决定。我之前调试过一个问答场景最初一直以为是模型回答能力不行后来发现是召回结果的问题——检索回来的片段跟问题根本对不上。重排之后哪怕模型没换回答质量立刻上了一个台阶。检索、重排、过滤这些环节本质上都是在给输入层做“信息筛选”让模型看到的内容更精准。3.3 Agent 的秘密把“能力清单”和“历史轨迹”一起塞进输入Agent 是大模型应用里非常典型的一种输入层玩法。你给模型一份工具清单每个工具包含名称、描述、参数 Schema。模型看到这份清单后会判断“当前任务是否需要调用工具”并在输出里吐出一个结构化的工具调用指令。执行完工具后工具结果又会被塞回下一轮的输入消息里模型继续判断下一步动作。换句话说Agent 的“规划能力”很大程度来自输入侧的编排。工具描述写得含糊模型就会乱调用工具描述写得好模型往往能自己规划出合理路径。这一步是纯粹的信息工程问题跟模型有没有“长出新的智能”没关系。3.4 多模态在输入层完成“翻译”与“拼接”图像、音频能进大模型也是输入层在做文章。图像会被编码成视觉 token音频会被编码成对应的声学 token这些 token 会和文本 token 拼在同一个序列里再一起送入模型。所以多模态能力的核心难点之一是“如何让不同模态的信息对齐到同一个语义空间”。你看到“模型能识别图片里的文字”本质上是视觉 token 和文本 token 在模型内部能够建立关联。这又再次验证了输入层的地位一切外部信息都要先被翻译成模型能读的 token才有资格进入决策流程。3.5 别忘了成本输入 token 是最直接的账单输入侧设计不仅影响效果还直接决定你烧多少钱。经验数据大概是很多 RAG 和 Agent 场景里输入 token 数量是输出 token 的好几倍。一次调用塞了 3000 token 的材料模型可能只回 200 token 的结果。计费按 token 来那你的成本大头其实在输入侧。省钱的思路不外乎三件事公共前缀尽量稳定方便命中缓存few-shot 示例控制数量挑最有代表性的检索召回控制在够用即可不要无脑扩大。重排环节通常比单纯增加召回数量更能提升效果也更省钱。4. 输出层决定一个 AI 功能能不能落地的变形空间输入层决定模型“看得懂什么”输出层决定“系统的下游能不能直接使用结果”。我见过太多项目死在输出侧——模型答得很好但返回结果没法被程序解析或者格式不对下游流程根本跑不通。4.1 结构化输出JSON、Schema 与约束解码最简单的做法是让模型“输出 JSON”。但如果你只写这一句你会发现它偶尔会夹带 Markdown 代码块偶尔会多一句“好的这是你要的 JSON”偶尔干脆输出不合法 JSON。这些不是模型太笨而是你的输出侧控制太弱。靠谱的做法有三层在请求里说清楚字段结构和含义最好直接把 JSON Schema 写进提示词开启平台提供的 JSON 模式。这类功能现在很常见底层是约束解码采样时把不符合 JSON 语法的 token 的概率直接压掉从机制上保证产出合法结构拿到结果后用代码做校验和兜底。解析失败时把报错信息回填给模型让它修正后重试一次这个“错误回填重试”的套路成功率极高。输出侧还要留意一个细节即使开了 JSON 模式模型也可能把内容包裹在 Markdown 代码块里。解析前先做字符串清理能少踩很多坑。4.2 Function Calling让“输出”直接变成下一个动作Function Calling 是结构化输出的进阶形态。模型不再只是“输出文本给你看”而是输出一个类似“调用工具 A参数是 B”的结构化指令由你的代码解析后去执行对应的本地函数。这意味着模型的输出可以直接接入自动化流程。比如一个助理应用模型输出“查询订单状态订单号 12345”你的后端收到这个结构后调订单接口再把结果作为下一轮输入喂回去。整个链路里模型的角色从一个“会说话的接口”变成了“会指挥协作的编排者”。它本质没有改变自回归范式只是输出端多了一层“按预定义格式吐指令”的约束。这个约束靠训练和提示词共同完成工程上还要处理“模型想调用不存在的工具”“参数类型不符合 Schema”这类异常这些都属于输出层的事。4.3 流式、校验、回填Agent 循环里的输出闭环输出层不只是“解析 JSON”。在 Agent 场景里输出是一个循环。第一步模型流式吐字。流式输出的价值有两方面对用户来说首字延迟低体验好对系统来说可以边输出边判断不必等全部生成完。第二步判断本次输出是“最终回答”还是“工具调用”。这一步要从模型返回的类型字段去判断而不是靠猜字符串开头。如果是工具调用解析出工具名和参数发给执行器拿到结果后拼接成新消息重新发起下一轮请求。第三步处理截断。如果模型因为达到max_tokens被截断返回的finish_reason会是 length 而不是 stop这时候摘要或回答可能停在半截。输出侧要做检测必要时把已有内容作为前缀让它续写。这三步里每一步都有很多业务细节但它们全部发生在模型输出之后属于标准的输出处理层工程。4.4 自洽性采样与幻觉抑制输出侧的最后一公里模型输出是概率性的同样的输入可能得到不同的答案。生产环境最怕的就是“这次对、下次错”的不稳定。两招很实用。第一调低 temperature任务型场景通常用 0 到 0.2 之间让采样更接近概率最大的路径如果业务允许直接取 argmax 也不是不行。第二对高风险判断做自洽性采样让模型用低温跑多次或者做几次不同视角的输出然后比较结果是否一致不一致时触发人工兜底。幻觉抑制也有不少工作在输出侧。比如 RAG 场景里可以要求模型输出时附上引用来源的编号然后在代码里校验这些编号是否真的存在于检索材料中。存在但引用错了或者引用不存在都能被拦下来。4.5 一张表看清主流玩法动的是哪一层拿一张表收束一下方便对照记忆玩法主要在输入侧做了什么主要在输出侧做了什么提示词工程 / CoT设计角色、指令、思维链引导提取最终答案隐藏思考过程RAG 问答检索内容拼入用户上下文拼接来源、校验引用、去幻觉Agent 智能体注入工具清单和历史轨迹解析工具调用指令路由执行结构化抽取定义字段 Schema 和示例约束解码、JSON 解析与校验多模态理解图像/音频转 token 后拼接处理坐标、特殊结构等输出格式记住这张表之后再看到任何新概念先问一句它改了输入还是改了输出大多数情况一两秒就能看穿。5. 一个模拟项目拆解我靠两层杠杆解决工单分类光讲原理容易飘我拿之前做的一个模拟项目 X 来走一遍完整流程。这个项目的目标是把用户提交的工单自动分类、写摘要并接入下游报表流程。5.1 V1 的惨状模型“能听懂”但不“听话”V1 写得很天真就是把工单全文塞到 user 消息里然后说“请分类并写摘要”。模型确实能听懂但输出完全不受控有时候用列表有时候用整段话分类枚举还可能自己发明新词。测试结果惨不忍睹分类准确率大约七成多JSON 解析成功率不到七成。看一眼样例就知道模型不是不会答而是不知道你要它“按什么格式交作业”。问题不在模型层在输出层和输入层都太粗糙。5.2 输入侧改造分类体系、Few-shot 与相似工单召回V2 集中改输入侧做了三件事。第一在 system 消息里把分类体系写清楚。不是简单列枚举值而是每个枚举值配一句定义和典型场景。模型看到的不只是“网络故障”这个词还有这个词的边界。第二加了两条 few-shot 示例。示例是精心挑的覆盖了最容易混淆的“网络故障”和“账密问题”让模型知道遇到底层网络不通和遇登录凭证过期时该怎么区分。第三把相似工单召回也接进来了。用向量检索把历史上最相似的已解决工单找出来作为参考案例拼进上下文。这一步对效果提升很意外地明显因为它等于给了模型“这次该怎么处理”的真实样板。改完再跑一轮分类准确率从七成多升到接近九成进步主要来自输入侧的边界定义和样例引导。5.3 输出侧的两个坑JSON 解析失败与回答过散V2 的准确率上去了但工程可用性还是不行问题全集中在输出侧。第一个坑是 JSON 解析失败。模型偶尔会输出“分类网络故障。摘要用户反映……”这种带解释的文字JSON 解析直接崩。解决办法分两层一是开启 JSON 模式从采样层面约束格式二是写了一个“错误回填重试”函数解析失败时把异常信息拼进下一轮输入让模型对照规范输出修正结果。实测下来加了这两个处理之后解析成功率从六成多拉到九成半。第二个坑是回答过散。摘要写得像小作文长度不可控下游报表根本放不下。处理办法是在提示词里明确“摘要不超过 60 字包含用户诉求和影响范围”同时在输出侧设置合理的max_tokens上限再用finish_reason检测是否被截断。别小看这个“字数约束”它是很多下游系统能接住结果的前提。5.4 最终效果与可复制的调参顺序这是模拟项目 X 里一轮实验的趋势数据不同业务复现时不必严格对标看走向即可版本分类准确率JSON 解析成功率摘要可用率输入成本对比V1 初始版76%65%70%基准V2 输入侧优化89%65%82%约 18%V3 输出侧优化93%97%95%约 5%调参顺序建议是先搞定输出侧的结构化与校验再接输入侧的检索和示例优化。因为如果结果连格式都不稳定输入侧再努力也无意义。6. 用一个问题框架评估所有新 AI 玩法最后分享一个我现在每天都在用的习惯遇到任何新的 AI 玩法、新工具、新框架先别急着追热点拿三层架构套一下。6.1 先问“输入变了什么、输出变了什么”一个新方案如果能在输入侧和输出侧说清楚它改了哪里它大概率值得看如果说半天都说不清这两点只是换个壳或者换了个底座模型那它的可替代性通常很高。举个例子同样是“让模型用企业知识回答”有人做 RAG有人做长上下文硬塞有人做微调。用架构框架一筛就明白RAG 和长上下文改的是输入侧微调改的是模型偏好它们的成本和迭代速度完全不同选型就顺了。6.2 什么时候才值得去碰模型本体模型层当然也有该碰的时候。当你发现输入侧无论怎么编排、输出侧无论怎么校验模型都学不会你的领域术语、抓不住固定格式这时候才轮到微调出场。判断标准很简单先用“输入输出杠杆”把问题压到最小把剩下的差距量化出来。如果量化后的差距依然明显且你有几百上千条高质量样本再考虑用 LoRA 这类低成本手段做适配。别一上来就微调那是把可快速迭代的工程问题拖成了训练周期很长的新项目。6.3 一点个人体会我现在的习惯是接到一个新需求先画一张三层图输入侧要准备什么信息模型层用哪种模型输出侧要做什么加工。大多数需求画完这张图答案已经出来一半。这些年看下来真正让你在业务上拉开差距的很少是“模型比别人新”而是把贴身的输入输出两层打磨到位知道什么信息该喂、什么信息不该喂、喂进去之后怎么把结果稳定地接回系统里。理解了这个框架再看热闹的 AI 圈子你会从容很多。