★ FEATURED ARTICLE 1. 一张图看懂大模型三层架构输入、理解、输出到底分工在哪1.1 为什么 AI 新功能看起来很多本质却很集中这两年每隔几天就能刷到类似“AI 又出了个新能力”的消息能识图、能听语音、能联网搜索、能自己调用软件、能生成完整报表……很多人觉得大模型像是有无限潜力今天一个突破、明天一个革命。我自己把这些功能逐个拆开看发现一个非常实用的规律绝大多数“新花样”并没有改变模型内部的核心推理逻辑真正变化的只有两端——输入端接收了什么、输出端怎样被处理和约束。换句话说你现在看到的大模型产品本质上就是固定的大脑加上可插拔的耳朵、眼睛和手。大脑内部的参数可能一两年才更新一次但耳朵能听什么、眼睛能看什么、手能做什么每季度都在变。理解这一点以后不管再出来什么新功能你都能迅速判断它属于哪一层、能解决什么问题、应该怎么调优不再被宣传话术带着走。1.2 三层到底分哪三层我把整个大模型应用体系拆成三层输入层负责把外界信息变成模型能理解的连续编码。文字进来要做 tokenization图片进来要做 patch embedding语音进来要做声学特征转换搜索结果、数据库记录、工具能力描述也都在这层被组装成模型能读的序列。理解计算层指模型本身。也就是那一堆 Transformer 层、注意力参数、预训练权重。它接收输入序列通过计算生成下一个字符的概率分布。这一层通常不需要普通使用者关心你很少能直接改动它。输出层负责把模型预测出来的概率分布变成实际文字、结构化数据、语音、图片或动作指令。它包含解码策略、格式约束、filter、外部动作映射比如把 JSON 输出解析成函数调用、把文本片段拼接成完整回复、把流式 token 变成前端可渲染的内容。很多人对“大模型 一个黑盒”的理解是给一句话进去出来一句话。实际上输入层和输出层都包含大量工程代码。所谓调优一个 AI 应用90% 的工作量都集中在这两层。1.3 一个更好记的类比大脑、感官、手脚你可以把三层结构想象成一个人。理解计算层是大脑负责思考输入层是感官决定你听到看到什么输出层是语言中枢和手脚决定你怎么表达、怎么行动。有人戴助听器听觉更好大脑没变有人拿纸笔记录待办输出工具升级大脑还是没变。大模型产品也一样新增一个“读 Excel”能力本质上是给输入层装了个新感官新增一个“自动执行操作”能力本质上是给输出层装了个新手脚。当你有了这套拆分思维再去看各种产品更新公告时会在脑子里自动画出一条线这部分是输入侧的新 connector那部分是输出侧的新 format。模型本身的那次大型发布才是真正意义上理解层的迭代。有了这条线你不容易被产品功能宣传迷惑也更清楚自己作为使用者的优化空间在哪里。2. 输入层拆解AI 能接收什么决定了它能玩出什么花2.1 从 Token 到 Patch输入进来的原始数据长什么样文本是最基础的输入。任何一个大模型第一件事就是把文本拆分成语义相对完整的 token。不同模型有不同 tokenizer英文通常一个单词拆成一个或两个 token中文按常用字和常用词来拆分一个汉字可能等于一到两个 token。这块对普通用户来说有实际影响你的输入长度、费用、处理速度全都按 token 计算。我见过有人把几千行日志直接贴进对话窗口模型秒回“内容太长”其实不是模型不行是请求长度触发了上下文窗口限制。你得规划好内容该截断截断、该摘要摘要、该分批分批。这就是输入层工程化的第一步。图片输入就不只是切词了。主流做法是把图片缩放成固定小方块序列每个小方块先过一个视觉编码器变成一组向量再通过投影层变成模型认得的高维表示。这一串向量和文本 token 混进同一个序列模型就能同时理解“图里的猫”和“这句话说的猫”是同一个东西。语音输入则先做声学特征提取再去语音编码器里转成 token 序列。关键认知多模态能力并不是模型真的拥有眼睛和耳朵而是输入层存在多个编码器把不同物理信号都转换成同一种大模型可以处理的统一序列格式。你在输入层接的东西越多模型能感知的信息越丰富“新花样”也就越多。2.2 多模态输入的编码图片、音频、视频是怎么混进模型里的图片进入模型通常有个分辨率上限超过的部分会被裁剪或缩放这会导致细节丢失。我在实践中遇到过一个场景把一张密密麻麻的收据拍照传给模型让它提取所有金额。它漏掉了右下角一行查日志发现那张图经过编码后被压成 448x448 的统一格子右下角小字在缩放过程中已经模糊得没法辨认了。后来处理方式是先对原图做局部放大把收据裁切成多个区域分别输入再汇总结果。这就是典型的输入层优化不改模型通过改造输入侧形态提升效果。视频输入的思路和图片类似拆成多帧之后逐帧处理。音频、文档PDF/Word也一样先做转换器解析器再进入模型。你可以把输入层理解成一个“万能信号转接器”什么信息进来都行重要的是转好后、塞进模型前是否保留足够信息。比如 OCR 出来的扫描件如果文字本身错了模型再怎么聪明也读不对——污染发生在入口处。2.3 输入层的实用技巧Prompt 上下文、工具描述和格式说明书输入层不只是传数据还包括你怎么组织数据。经常有人问我“Prompt 是不是玄学”我的回答是Prompt 其实是一份给输入层的编码说明书。你告诉模型“你是客服、语气要客气、最后给出三个选择”等于人为确定了输入空间的语义布局让模型在概率生成时更可能落入你想要的区域。实操中我常做这几件事先给系统预处理把长文档拆成小段或者提前用模型做摘要压缩到上下文固态区域后再送入主任务。给工具调用写清楚参数 schema告诉模型“这个工具有两个参数分别是 date 和 keyword类型是 string”模型才能正确生成 JSON。把示例放最后有些模型对开头指令更敏感把示例正好在指令之后效果更好。这个因模型而异我遇过差别还挺大。控制上下文总量不要让无关内容占用窗口。窗口是输入层最贵的资源塞太满会压缩模型有效注意力。3. 理解计算层为什么说模型“懂”但未必“聪明”3.1 注意力机制和参数记忆模型的“理解”实际是什么很多人把大模型理解成“百科全书 推理机”其实更接近一个超大的模式记忆和概率联想系统。它在训练时记住大量文本里的统计规律推理时根据上下文激活相关模式一个 token 接一个 token 地预测下一个最合适的词。注意力机制是它的核心工作方式每个输入位置都可以去“关注”序列里的其他位置。你说“小明把苹果给了小红她吃了一口”模型通过注意力判断“她”很可能指小红因为语义上更贴近“吃苹果”的人。这是经过大量文本训练学到的模式不是通过真正的逻辑规则推导出来的。因此模型经常表现出“懂”——它能准确续写、总结、类比但它不保证每一步都严格符合事实。理解层的能力边界就在这里它会做最可能的联想而不是做必然正确的推理。这解释了为什么数学题容易错、多步逻辑容易崩、常见信息容易背错。它并非蠢而是原理就是概率联想。3.2 上下文窗口的容量与限制长文本未必都“看着”上下文窗口不是无限大而且窗口中塞得越满注意力越分散。我做过一个压力测试把一个长 10 万 token 的文档丢进去中间隐藏关键信息然后问模型一个问题。它给出的答案经常偏向前文和后文的内容中间部分被“淹没”了。这就说明一个事实上下文长度和有效记忆长度不是一回事。你在输入层塞了很多内容但理解层未必对所有内容一视同仁。长文本应用中更可靠的做法是主动做信息检索把最相关的小片段抽出来放在显眼位置而不是把所有内容一股脑灌进去。还有一个常见误区以为上下文越大越好于是把几本书直接扔进去结果模型前言不搭后语。实际项目里我会先做一轮“提炼摘要关键段落定位”再让模型基于精炼后的内容作答。对模型来说输入少而精比多而杂效果好得多。3.3 幻觉从哪里来理解层不负责“求真”幻觉的根源要从概率联想机制说起。常出现这种情况你问一个模型“某事件发生在哪一年”它可能顺着“最流行的说法”答了一个常见年份但这个年份其实是错的。因为在训练语料里那个错误说法出现频率更高模型在计算下一个 token 时自然被带过去了。用一个生活类比你跟一个朋友聊天他没听清后半句但凭着开头一个词就顺着“猜”完了整句话——大模型就是那个朋友只不过它猜得往往比真人更流畅所以容易被你信任。它自己不觉得自己在猜它只是在做概率分布采样。因此防幻觉主要靠输入层和输出层输入层你要给它更可靠的资料检索结果、数据库记录让模型不是凭空联想输出层你要加约束、加验证环节让模型的生成结果可以和外部信息对照。理解层无法保证正确但工程上可以在周边把它“扶”平稳。4. 输出层才见真功夫解码、格式与下游衔接4.1 自回归生成与采样策略改一个参数语气完全变大模型的生成是逐字输出的。它每一步都会算出下一个词的概率分布然后通过解码策略挑一个 token。这里有很多可调参数工程上最常用的有temperature控制概率分布的平滑程度。温度越低越倾向选择高概率词输出越稳定保守温度越高选择越多样输出越有“创意”但也更容易跑偏。top_p核采样只从累计概率前 p 的词里选下一个词。它相当于画了一个候选范围防止采样跑到太偏的词。max_tokens限制输出长度防止模型无限写下去。这堆参数没直接改模型大脑却大幅度影响输出。我之前做过一个客服摘要项目同一批用户对话温度从 0.2 调到 0.7总结风格从“客观罗列”变成“带点主观推测”。业务方要求一定不能臆断于是全链路固定到 0.1 附近实测最稳。4.2 结构化输出让模型“可被程序调用”JSON、Schema 与函数调用纯文本聊天只是输出层最基础的能力。真正让它进入业务系统的是结构化输出。现代模型普遍支持“JSON 模式”或“函数调用模式”你提前声明输出结构模型在生成时会被约束只输出符合 schema 的 JSON。例如让模型从一段文字里提取客户信息schema 定义为{ name: string, phone: string, intent: string }模型就会自动遵守这个结构直接得到可解析的数据对象而不是给你一篇口头作文。函数调用则更进一步模型不再直接回答而是输出“调用某个函数并传参数”的指令外部代码解析后真正去执行动作。比如模型判断用户需要查天气就输出call_weather_api({city: 北京})程序接收到后去查完再把结果传回模型做二次回答。这里有个容易踩的坑模型输出 JSON 时偶尔会在结构里加多余字段或者把空值填成一个空字符串而不是 null。对策是把导出结构写得尽量严格在 schema 里显式允许 null并且解析时做容错清洗不要默认模型百分百规范。输出层的鲁棒性决定你这个应用在真实流量下崩不崩。4.3 流式输出把“慢生成”变成“像在思考”用户和模型对话时如果等全部生成完再一次性返回通常要等好几秒体验非常糟糕。流式输出把情况改成了边生成边推送用户看到的就是一个字一个字蹦出来感知延迟大幅下降。这个能力完全属于输出层工程和模型智力没半点关系。但在流式输出时做结构化解析很麻烦JSON 还没输出完你没法直接解析。常用做法是“等一个完整的闭合标签或大括号”再解析一次或者用增量解析器。我最初偷懒直接按流式片段做正则结果经常匹配一半失败。后来改成“缓冲 完整性判断”只对完整 JSON 块解析才稳定下来。5. 所有新花样到底新在哪用三层架构定位当前热点5.1 RAG替换输入不换引擎RAG检索增强生成的核心逻辑是外部知识库先召回相关片段再把它们拼进输入层让模型基于给定材料回答。它没有升级模型大脑也没有加强输出层只是改变了“模型看到什么”。一个典型的 RAG 流水线文档切块 → 向量化 → 存入向量数据库 → 用户提问时检索最相近的块 → 拼接成 prompt → 送入模型。因为输入层注入了最新数据、私有数据或其他来源模型就能回答超出其记忆范围的问题。这也是优化幻觉最务实的办法之一模型不猜了因为它“看到”了确切资料。项目中常见问题集中在切片策略和检索质量。切得过碎上下文碎片化切得过大检索噪声太多。我会把切块大小默认设在 300-500 字并根据文档结构微调标题、段落、表格分别处理。检索结果最好不只取 top1把 top3 相关的段落都送进去让模型自己权衡。5.2 Agent 的 Function Calling把输出变成动作Agent 类应用越来越火但拆开来看它很多时候不是模型“会思考了”而是把输出层扩展成了动作层。模型判断用户意图输出对应的函数调用指令外部程序真正执行动作再把结果送回输入层做下一轮处理。这个循环的关键点在于模型并不直接“操作电脑”或“点击按钮”它只是生成函数名和参数。动手的永远是外部代码。所有的工具都必须在输入层做好描述让模型知道“这个函数干嘛、有什么参数、何时调用”。工具描述不清模型即使知道该行动也会输出一个违规参数或错误工具名。我踩过一个实际坑给模型注册了一个查库存工具参数说明写得特别复杂还把业务规则写在了描述里。结果模型多次调错参数名排查很久后发现是描述太长模型不理解重点。简化描述并用示例说明后准确率立刻上来了。5.3 多模态和轻量化模型在输入端和大脑同时变形多模态模型对输入层改动很大增加视觉塔、音频塔让不同模态都能进入统一序列。但理解层仍是同一套 Transformer 结构只是训练数据里多了图文对照、音画对照。所以你可以看到视频理解、图片问答大爆发但模型推理的“默认常识”仍主要来自语言数据。轻量化模型走的是另一条路通过蒸馏、剪枝、量化把大脑本身变薄变小。它牺牲一部分理解能力换取在手机端、边缘端流畅运行。这类变化是真正的理解层改造但工程收益集中在部署效率对功能“新花样”贡献不大。遇到新品宣发时先用三层模型问自己它是输入层多了新连接器还是输出层多了新约束或者真把大脑换了一版大部分情况是前两层的组合创新。我没有贬低创新的意思——输入和输出层改导致的应用体验天差地别甚至比单纯模型升级更容易落地。理解层再强没有好的输入输出包装也很难用起来。5.4 一个实操判断框架快速评估任何新 AI 功能把每一条“新功能”往三层里套输入侧新增了什么类型的信号文字图像语音数据库搜索处理工具输出侧输出如何被消费纯文本JSON函数调用持续流式多轮循环理解层有没有换模型版本参数规模、训练方式有没有本质变化例如一个“图片转周报”功能本质是输入层加了图片编码输出层规范成结构化报告格式引擎没换。你掌握了框架就不会被名词吓住也能更快照着自己项目复制这类能力。6. 实操一场从输入到输出的完整实验6.1 场景设置我设计了一个业务场景来验证三层架构的实际影响把一张包含订货信息的手机截图 一段语音留言输入给模型要求它提取订单信息并生成结构化表格。第一步准备输入数据。截图里是一张含商品名、数量、单价的表格语音留言内容是“把里面的苹果 30 箱香蕉 20 箱发给华东仓库备注一下周末前到货”。模型需要理解图片和音频并最终输出{ items: [ {name: 苹果, quantity: 30, unit_price: 8.5}, {name: 香蕉, quantity: 20, unit_price: 6.2} ], deliver_to: 华东仓库, deadline: 周末前, note: 加急 }6.2 配置输入层和输出层的关键步骤输入层我做了三件事把图片压缩到模型要求尺寸且保持关键文字可读把音频转成 16k 采样率 wav并提示模型这是一段语音内容在系统提示里写明任务目标、输出字段全名、各字段含义。系统提示大致写成你是一个订单处理助手。根据用户提供的图片和语音信息提取订单字段严格按照 JSON 结构输出。如果信息缺失对应字段填 null不要猜测或补充。输出层启用 JSON 模式温度设为 0.2最大输出 token 设为 500同时定义好 schema要求字段固定。这样模型不会自由发挥只会输出我们约定的结构。实测结果第一次运行就成功提取了商品名称和数量但单价字段丢失因为图片中单价列有“¥”符号视觉编码时部分信息被噪声影响。我随后在输入层把图片做了二值化预处理并裁剪放大单价区域第二次运行全部字段都正确。这说明输入层的预处理质量直接决定输出层的准确率。6.3 踩坑记录格式、长度与多模态的隐性风险踩坑点一音频输入不是万能的。语音里“华东仓库”被模型听成了“花灯仓库”二次纠错时靠上下文才拉回来。如果有条件语音入口最好加一道本地 ASR 校验再进模型别让模糊音污染整个流程。踩坑点二JSON schema 一旦设置模型连“抱歉我现在无法处理”这类回复都无法输出因为它不符合结构要求。如果模型判断意图不符也要有“error”字段或降级方案否则整条链路会直接失败。踩坑点三温度 0 和 0.2 差别不大但 0.7 以上在结构化任务里基本失控。做数据提取类任务不要相信“稍高温度更有创造性”的说法稳定优先。7. 常见问题速查与个人体会7.1 六个高频坑现象、原因、解法为了让你真正“抄作业”我把最常遇到的情况整理成了一张速查表现象原因分析解决办法模型答非所问输入层指令模糊、上下文噪音太多精简 prompt明确任务边界删除无关内容长文档中关键信息被忽略上下文过长有效注意力被稀释提前检索相关片段做摘要压缩不整篇灌入输出 JSON 解析报错模型在结构里加字段、转义问题启用 JSON 模式schema 显式约束解析时容错清洗函数调用频繁传错参数工具描述过长模型抓不住重点简化工具描述给一个标准调用示例图片信息提取不全图像被压缩缩放细节丢失裁切放大局部区域分块输入后合并结果回答太“泛”不具体输出层缺乏格式约束增加输出模板指定分点/结构/长度必要时用 JSON 约束7.2 我个人的实操体会拆了这么多模型应用我自己在落地项目时最大的体会是不要去追“最强大脑”先把自己手头的输入输出两端理顺。很多团队花大力气换了更强模型结果 prompt 一团糟、工具说明含糊、输出没约束最终效果提升非常有限。反过来把输入预处理做好、让检索结果更精准、把输出格式卡死即使是中等模型也能在业务场景里立住。还有一个小技巧分享每一轮 prompt 设计时我都会先写“最终输出长什么样”倒推“模型需要什么信息”再决定“输入层应该塞什么”。这比从头自然语言描述需求可靠得多。另外多数用户对模型产生“失望”情绪往往不是模型不行而是输入太脏或者输出太“原生态”。你作为使用者完全有权利做输入清洗也完全有权利要求结构化输出。那些天花乱坠的新产品九成是在这两端做文章。看懂了这一点你可以直接用同样招式自己搭一套效果未必比市面上的差。
阅读完成 · 觉得有帮助？
