1. 大模型三层架构到底在说什么1.1 从一个常见困惑说起很多人第一次接触大模型应用开发时都会被各种新概念砸晕。今天出一个RAG明天火一个Agent后天又冒出个Function Calling、MCP、思维链、结构化输出。每个看起来都是全新的东西每个都号称要改变世界。但如果你真的动手做过几个项目就会发现一个很有意思的现象这些花里胡哨的名词拆到最底层绝大多数都落在三个位置上——输入侧怎么组织、模型本身怎么选、输出侧怎么处理。我管这个叫大模型的“三层架构”。它不是某个官方标准而是我在实际做项目时总结出来的一套拆解框架。你拿任何一个AI新玩法往这三层里套基本都能找到它的位置。这个框架最大的价值在于当你面对一个从没见过的技术名词时不会慌因为你知道它无非是在这三层中的某一层做了文章。三层分别是输入层、模型层、输出层。输入层管的是“给模型看什么”模型层管的是“用哪个模型、怎么调”输出层管的是“拿到结果之后怎么用”。所有AI应用的花样本质上都是在这三层上做排列组合。1.2 为什么这个框架值得掌握你可能会问为什么不直接学具体技术而要搞一个框架原因很简单具体技术会过时框架不会。两年前大家都在讨论Prompt Engineering现在讨论得少了但Prompt本身并没有消失它只是被吸收进了输入层的常规操作里。去年Agent特别火今年大家开始冷静下来发现Agent的核心其实还是输入输出两端的工程问题。掌握这个框架之后你看到一个新技术第一反应不是“我要不要学”而是“它在这三层里动了哪一层”。这个判断能帮你省下大量时间。比如某个新出的框架号称能提升效果30%你一看它其实只是在输入层做了动态few-shot示例选择那你就知道它的上限在哪里适用场景是什么不会盲目跟风。提示这个框架不是用来否定新技术的而是帮你快速定位新技术的价值点和边界。任何新技术都值得了解但了解的方式应该是“它在哪一层做了什么改进”而不是“它又颠覆了什么”。1.3 三层架构的边界与关系三层之间不是孤立的。输入层的设计会直接影响模型层的选择模型层的能力又决定了输出层能做什么。举个例子如果你在输入层做了非常详细的格式化约束那模型层可能就不需要选最贵的那个输出层也不需要做太复杂的后处理。反过来如果你输入层给的信息很粗糙那模型层就得选能力更强的输出层也得加更多的校验和修正逻辑。这三层的关系有点像做菜。输入层是备菜模型层是灶台和火候输出层是装盘和调味。备菜备得好普通灶台也能炒出好菜备菜乱七八糟再好的灶台也救不回来。装盘和调味看似是最后一步但它决定了客人吃到嘴里的第一印象。我在实际项目中见过太多人把精力全花在模型层上整天比较哪个模型跑分高却忽略了输入层的组织和输出层的处理。结果就是同样的模型别人做出来的效果就是比他的好。差距不在模型在两头。2. 输入层决定模型看到什么2.1 输入层的核心任务输入层的核心任务只有一个在模型能力范围内给它提供最有利于完成任务的信息。这句话听起来简单做起来涉及的东西非常多。你要决定给模型什么背景信息、什么示例、什么格式约束、什么角色设定。每一个决定都会影响最终输出。很多人把输入层等同于写Prompt这个理解太窄了。Prompt只是输入层的一种表现形式。输入层还包括检索增强RAG、上下文管理、历史对话压缩、多模态信息融合、工具描述注入等等。凡是“在模型开始推理之前你为它准备的一切信息”都属于输入层。输入层做得好不好有一个很直接的判断标准如果把你的输入原封不动给一个聪明但完全不了解你业务的人看他能不能理解你要他做什么如果人看了都迷糊模型大概率也做不好。2.2 输入组织的四种常见模式在实际项目中输入层的组织方式大致可以归为四类。每一类都有它的适用场景和局限性。第一类纯指令模式。就是直接告诉模型要做什么不给示例不给背景。这种模式适合任务非常简单、模型本身能力足够强的场景。比如“把下面这段话翻译成英文”不需要任何额外信息。优点是简洁、token消耗少缺点是遇到复杂任务时模型容易跑偏。第二类指令加示例模式。在指令的基础上给几个输入输出的例子。这就是常说的few-shot。示例的作用是让模型通过模仿来理解你的意图。我试过在信息抽取任务里给三个示例和给零个示例准确率能差出百分之二三十。示例的选择很关键要覆盖典型情况和边界情况不能只给简单的。第三类指令加背景模式。这种模式常见于RAG应用。你先从知识库里检索出相关内容把内容和指令一起给模型。模型基于你给的背景信息来回答而不是靠它自己的记忆。这种模式能有效减少幻觉但前提是检索要准。检索不准背景信息就是噪音反而会干扰模型。第四类混合模式。把指令、示例、背景、格式约束全部组合在一起。这是实际项目中最常见的形态。难点在于怎么组织这些信息让模型能分清主次。我的经验是把最重要的指令放在最前面和最后面中间放背景和示例。因为模型对开头和结尾的信息注意力更强中间部分容易被忽略。2.3 输入层的关键参数与实操细节输入层有几个关键参数需要你根据实际情况调整。这些参数没有绝对的最优值只有适合当前场景的值。上下文长度这是输入层最硬的约束。每个模型都有最大上下文限制你所有输入信息加起来不能超过这个数。实际使用时不要贴着上限用。我一般会留出百分之二十到三十的余量因为输出也要占token。如果你输入塞得太满输出空间就被压缩了模型可能话说到一半就断了。信息密度同样长度的输入信息密度差别很大。废话越多有效信息占比越低模型抓重点的难度越大。我习惯在输入写完后做一次精简把“你可以”“请你”“麻烦你”这类客套话删掉把重复的约束合并。精简后的输入往往效果更好因为模型不需要在废话里找重点。格式约束的强度如果你需要模型输出特定格式输入层就要把格式要求写清楚。但要注意格式约束太强会限制模型的推理能力。比如你要求模型必须按JSON输出它可能为了满足格式而牺牲内容的准确性。我的做法是先让模型自由推理在输出层再做格式转换。如果必须在输入层约束格式那就把格式要求放在指令的最后并且给一个格式示例。示例的数量和质量few-shot的示例不是越多越好。我实测下来三到五个示例通常就够了。超过五个边际收益递减而且token消耗线性增长。示例的质量比数量重要得多。一个覆盖边界情况的示例价值超过十个普通示例。选择示例时要选那些能体现任务难点的而不是选最容易的。注意输入层的信息不是越多越好。每增加一段信息就增加了一份干扰模型的风险。我见过有人把整个知识库塞进输入结果模型完全抓不住重点。输入层的艺术在于做减法而不是做加法。2.4 输入层常见的坑与规避方法输入层最容易踩的坑有三个。第一个是信息过载。前面说了给太多信息反而会让模型迷失。规避方法是先确定任务的核心要素只给和核心要素直接相关的信息。其他信息要么不放要么放在次要位置。第二个坑是指令冲突。比如你前面说“请详细回答”后面又说“控制在三句话以内”。模型面对矛盾指令时行为不可预测。规避方法是写完输入后自己通读一遍检查有没有互相矛盾的约束。如果有明确优先级或者干脆删掉一个。第三个坑是示例偏差。如果你给的示例都是某一种类型模型就会倾向于按那种类型来处理所有输入。比如你做情感分类示例全是正面评价那模型遇到负面评价时可能也会判成正面。规避方法是示例要覆盖所有类别并且边界情况要单独给示例。我在实际项目里还遇到过一个更隐蔽的坑输入顺序影响输出。同样的信息换个顺序给模型结果可能不一样。这个现象在长输入里特别明显。我的应对策略是把最重要的信息放在输入的开头和结尾中间放次要信息。如果某个信息特别关键我会在开头和结尾各提一次。3. 模型层选对工具比用蛮力重要3.1 模型层的决策逻辑模型层要解决的问题是用哪个模型、用什么参数、要不要微调。这三个问题没有标准答案取决于你的任务复杂度、预算、延迟要求和数据情况。先说选模型。现在市面上的模型大致分三档轻量级、通用级、旗舰级。轻量级模型便宜、快但复杂任务容易出错。旗舰级模型能力强但贵、慢。通用级在中间。我的选型逻辑是先用旗舰级模型跑通任务确认任务可行之后再尝试用轻量级模型替代看效果下降多少。如果下降在可接受范围内就换轻量级省成本。如果下降太多就留在通用级或旗舰级。这个逻辑的好处是你不会一上来就被成本问题困住。先验证可行性再优化成本。很多人反过来一开始就纠结用哪个便宜模型结果任务跑不通浪费更多时间。3.2 参数调整的实际影响模型参数里最常调的是温度和最大输出长度。温度控制输出的随机性。温度低输出更确定、更保守温度高输出更多样、更有创意。做信息抽取、分类这种需要稳定输出的任务温度设低一点我一般用0.1到0.3。做创意写作、头脑风暴温度可以设高一点0.7到1.0。最大输出长度这个参数容易被忽略但它很关键。如果你设得太短模型话没说完就断了。设得太长又浪费token。我的做法是先不限制让模型完整输出一次看看实际用了多少token然后在此基础上加百分之二十作为上限。还有一个参数是top_p它和温度配合使用。top_p控制的是候选词的累积概率阈值。温度高的时候top_p可以设低一点防止模型选到太离谱的词。温度低的时候top_p可以设高一点给模型更多选择空间。这两个参数的组合需要根据具体任务来调没有万能公式。3.3 微调的适用场景与替代方案微调是模型层的一个重选项。它的本质是拿你的数据去调整模型的参数让模型更适应你的任务。微调的好处是效果上限高坏处是成本高、周期长、灵活性差。模型一旦微调就固定了后续任务变化还得重新微调。我的经验是绝大多数场景不需要微调。通过输入层的优化比如更好的示例、更清晰的指令、更精准的检索就能达到不错的效果。微调适合那些输入层优化已经做到极致、但效果仍然不达标的场景。比如特定领域的术语理解、特定格式的严格输出、特定风格的文本生成。如果确实需要微调我建议先做小规模实验。拿几百条数据试一下看效果提升是否明显。如果提升有限就不要继续投入了。微调的数据质量比数量重要。一千条高质量数据效果可能好过一万条噪音数据。提示微调之前先问自己三个问题输入层优化到极致了吗有没有更轻量的替代方案微调后的模型维护成本能接受吗三个问题有一个答案是否定的就先别微调。3.4 模型层的成本与延迟权衡成本和延迟是模型层绕不开的两个约束。成本主要是token费用延迟主要是响应时间。这两个约束经常是矛盾的能力强的模型效果好但贵且慢能力弱的模型便宜且快但效果可能不够。我的处理策略是分层处理。把任务拆成多个步骤简单的步骤用轻量级模型复杂的步骤用旗舰级模型。比如一个客服问答系统意图识别用轻量级模型答案生成用旗舰级模型。这样既控制了成本又保证了关键环节的效果。延迟方面如果应用场景对实时性要求高那就必须选响应快的模型。如果场景允许异步处理比如批量文档分析那就可以用慢一点但能力更强的模型。我见过有人为了省成本在实时场景用慢模型结果用户体验极差。这种省法得不偿失。还有一个技巧是缓存。如果某些输入是重复的可以把模型的输出缓存起来下次遇到相同输入直接返回缓存结果。这在FAQ场景特别有效。缓存能大幅降低成本和延迟但要注意缓存的失效策略避免返回过时信息。4. 输出层决定结果怎么用4.1 输出层的核心职责输出层的核心职责是把模型的原始输出转换成应用能直接使用的形式。模型输出的通常是自然语言文本但应用需要的是结构化的数据、特定的格式、或者经过校验的内容。输出层就是做这个转换的。很多人不重视输出层觉得模型输出什么就用什么。这是大错特错。模型输出是不稳定的同样的输入两次输出可能格式不一样、内容有偏差。如果你直接把模型输出透传给下游系统系统很容易崩。输出层的处理决定了你的应用是“能用”还是“好用”。输出层要做的事情包括格式解析、内容校验、错误处理、结果封装。格式解析是把文本转成JSON、XML或其他结构化格式。内容校验是检查输出是否符合预期比如必填字段有没有、数值范围对不对。错误处理是当输出不符合预期时怎么办是重试、降级还是报错。结果封装是把处理好的数据打包成下游需要的格式。4.2 结构化输出的实现方式结构化输出是输出层最常见的需求。实现方式有三种各有优劣。第一种Prompt约束加手动解析。在输入层要求模型按特定格式输出然后在输出层用正则或字符串处理来解析。这种方式最灵活但最不稳定。模型可能不按格式来解析容易失败。适合对稳定性要求不高的场景。第二种JSON模式。很多模型支持强制JSON输出你可以在调用时指定输出格式为JSON。这种方式比手动解析稳定得多因为模型被约束了输出格式。但要注意JSON模式可能会影响模型的内容质量因为模型要分心去满足格式要求。第三种Function Calling。把输出格式定义成一个函数签名让模型来填充参数。这种方式最稳定因为模型被训练成按函数签名输出。缺点是灵活性差格式必须在调用前定义好。适合格式固定的场景。我的选择逻辑是格式固定且要求稳定用Function Calling格式需要一定灵活性用JSON模式格式经常变或模型不支持前两种用Prompt约束加手动解析。4.3 输出校验与容错设计输出校验是输出层的安全网。模型输出不可控校验能帮你及时发现问题避免错误数据流入下游。校验分两层格式校验和内容校验。格式校验检查输出是否符合预期的结构。比如JSON能不能解析、必填字段在不在、字段类型对不对。格式校验通常用代码自动完成速度快、覆盖全。内容校验检查输出的内容是否合理。比如数值是否在合理范围、文本是否包含敏感词、逻辑是否自洽。内容校验有的能用代码做有的需要人工规则或另一个模型来判断。容错设计是当校验失败时怎么办。常见的策略有重试用同样的输入再调一次模型看能不能得到合格输出降级返回一个默认值或简化版结果报错把问题暴露给上游让上游决定怎么处理。我的经验是重试适合偶发性的格式错误降级适合非关键字段的缺失报错适合关键字段的缺失或内容严重异常。注意容错设计不是万能的。如果模型输出经常校验失败说明输入层或模型层有问题应该回头去优化那两层而不是在输出层无限打补丁。4.4 输出层的后处理技巧输出层的后处理有很多小技巧能显著提升最终结果的质量。我挑几个最实用的说。去重和合并模型有时会重复输出相同内容或者把本应合并的信息拆成多条。后处理时可以做去重和合并让结果更干净。格式规范化模型输出的日期、数字、单位可能格式不统一。后处理时统一格式比如日期统一成ISO格式数字统一保留两位小数。这样下游处理起来更方便。置信度过滤如果模型输出了置信度或概率可以根据阈值过滤掉低置信度的结果。这能减少错误信息的传播。人工审核标记对于关键输出可以标记出来让人工审核。比如金额超过一定数值、涉及敏感操作的结果自动打上待审核标记。这样既保证了效率又控制了风险。我在实际项目里还用过一招输出对比。让同一个模型对同一输入输出两次对比两次结果。如果差异很大说明这个输入模型没把握结果需要人工关注。如果差异很小说明模型比较确定可以自动通过。这个方法能有效识别出模型不确定的情况。5. 三层联动把框架用起来5.1 从需求到三层设计的映射拿到一个需求怎么用三层框架来设计我的流程是这样的先明确任务目标然后判断这个任务的核心难点在哪一层最后针对性地设计三层。举个例子需求是“从用户评论中提取产品问题和情感倾向”。任务目标是信息抽取。核心难点在输入层和输出层输入层要确保模型理解“产品问题”和“情感倾向”的定义输出层要确保提取结果结构化且准确。模型层反而简单通用级模型就够用。再举个例子需求是“生成个性化的营销文案”。任务目标是创意生成。核心难点在输入层和模型层输入层要提供足够的用户画像和产品信息模型层要选创意能力强的模型。输出层相对简单做基本的格式校验就行。这个映射过程能帮你把精力分配到正确的地方避免在不需要的地方过度设计。5.2 三层各自的优化优先级资源有限的时候三层优化的优先级怎么排我的经验是输入层优先输出层次之模型层最后。输入层的优化成本最低效果最直接。改改指令、调调示例、优化检索往往就能带来明显提升。输出层的优化成本中等主要是开发校验和后处理逻辑但一次开发长期受益。模型层的优化成本最高换模型要重新测试微调要准备数据和算力。所以我的建议是先把输入层做到极致再把输出层做扎实最后才考虑动模型层。很多项目在输入层和输出层优化完之后发现根本不需要换模型或微调效果已经够用了。5.3 一个完整的拆解示例假设你要做一个“合同关键信息提取”的功能。用三层框架来拆解输入层设计合同文本通常很长不能全文塞进去。先用检索或分段的方式定位到可能包含关键信息的段落。然后设计指令明确要提取哪些字段比如合同金额、签约方、有效期。给两到三个示例展示提取的格式和边界情况。最后加上格式约束要求输出JSON。模型层设计合同提取对准确性要求高选通用级或旗舰级模型。温度设低保证输出稳定。最大输出长度根据字段数量设定留出余量。不需要微调因为输入层的示例已经能引导模型。输出层设计解析JSON校验必填字段。金额字段做数值校验日期字段做格式校验。如果校验失败重试一次再失败标记为待人工处理。最后把结果封装成下游系统需要的格式。这个拆解过程清晰地把一个复杂需求分解成了三层各自的任务。每层的任务明确责任清晰开发和调试都有章可循。5.4 框架的局限与扩展这个三层框架不是万能的。它主要适用于单次调用模型的应用。对于多轮对话、Agent这类涉及多次模型调用的场景框架需要扩展。多轮对话里输入层还要管历史对话的压缩和选择输出层还要管对话状态的维护。Agent场景里模型层还要管工具的选择和调用。但即使在这些复杂场景里三层框架仍然是一个有用的起点。你可以先按三层拆解再把额外的复杂性作为扩展加进去。这样比一上来就面对一团乱麻要好得多。我在实际使用这个框架的过程中最大的体会是它帮你把“玄学”变成了“工程”。大模型应用开发经常给人一种不确定感好像效果好不好全靠运气。但用三层框架拆解之后你会发现每个环节都是可控的、可优化的。效果不好就逐层排查总能找到问题所在。最后分享一个我常用的排查顺序效果不对时先看输入层的信息够不够、清不清楚再看输出层的校验和处理有没有问题最后才怀疑模型层。这个顺序帮我省了很多时间因为大部分问题其实都出在输入层和输出层模型层反而是最稳定的那一环。