1. 大模型三层架构到底在拆什么1.1 从一个常见困惑说起这两年做大模型应用开发的人几乎都会经历一个相似的阶段每隔几周就冒出一个新概念今天是某个新的提示词框架明天是某个新的智能体编排方案后天又出来一个检索增强的变体。追着追着就发现自己像在追一条永远追不上的尾巴学了一堆名词但真正落到项目里还是不知道该怎么选、怎么搭。我自己也踩过这个坑。最开始做对话类应用的时候看到什么新方案都想往项目里塞结果架构越堆越复杂调试成本直线上升最后发现真正决定效果的根本不是那些花哨的编排层而是两个最朴素的问题你往模型里输入了什么以及你拿到模型输出之后怎么处理。把这句话再抽象一层其实所有大模型应用不管包装成什么形态都可以拆成三层来看。这个拆法不是某个官方标准而是我在多个项目里反复验证后总结出来的一套心智模型。它最大的价值在于当你再看到一个新概念时能立刻判断出它到底动的是哪一层从而决定要不要跟、值不值得跟。1.2 三层架构的整体轮廓先把三层摆出来后面再逐层展开。层级名称核心职责典型代表第一层输入层决定模型看到什么提示词、上下文拼接、检索结果、工具描述第二层模型层决定模型怎么算基座模型、微调权重、推理参数第三层输出层决定结果怎么用解析、校验、重试、格式化、后处理很多人一上来就盯着第二层觉得换个更强的模型就能解决一切。但实际项目里第一层和第三层能撬动的效果往往比换模型大得多而且成本低、迭代快。原因很简单模型层是别人训练好的你能动的空间有限而输入和输出这两层完全掌握在你自己手里。这个判断不是拍脑袋来的。我做过一个对比实验同一个任务固定模型不变只优化输入层的上下文组织方式准确率从六成出头提到了八成五以上再叠加输出层的校验和重试机制最终稳定在九成以上。整个过程没有动过一次模型权重也没有换过基座。这就是三层拆解的实际意义——它告诉你力气该往哪儿使。1.3 为什么这个拆法值得反复用有人可能会问市面上已经有那么多架构图了为什么还要自己搞一套。我的体会是大部分架构图是给“系统”画的讲的是数据怎么流动、服务怎么部署而三层拆解是给“效果”画的讲的是模型行为怎么被影响。这两个视角不冲突但解决的问题不一样。当你遇到效果问题时系统架构图帮不了你因为它不会告诉你“为什么模型这次答偏了”。但三层拆解可以先看输入层是不是给的信息不够或者有干扰再看模型层是不是能力边界到了最后看输出层是不是没做兜底。这个排查顺序能帮你快速定位问题所在而不是盲目地换模型、调参数。所以这套拆法我用了两年多从简单的文本分类到复杂的多轮工具调用基本都能套进去。接下来就逐层拆开讲每一层我会说清楚它管什么、怎么调、有哪些坑。2. 输入层决定模型看到什么2.1 输入层的本质是信息筛选输入层做的事情说白了就一件在模型有限的上下文窗口里塞进最有用的信息同时尽量不塞没用的。这件事听起来简单做起来极难因为“有用”和“没用”的边界往往要试了才知道。我见过太多项目输入层就是简单地把用户问题往模板里一填就发出去了。这种做法的上限很低因为模型拿到的信息量太少只能靠自己的先验知识硬答。而先验知识是有边界的一旦问题涉及私有数据、实时数据或者领域细节模型就开始编。输入层的优化空间主要体现在三个维度上信息的选择、信息的组织、信息的表达。这三个维度层层递进每一层都能带来明显的效果提升。2.2 信息选择什么该放进去信息选择是输入层的第一道关。核心原则是只放和当前任务直接相关的信息相关性越强越好数量越少越好。这里有个反直觉的点很多人以为上下文给得越多模型答得越准。实际恰恰相反。上下文过长会带来两个问题一是稀释注意力模型可能抓不住重点二是引入噪声无关信息会干扰判断。我做过测试同一个问答任务给模型三段相关文档和给十段文档其中七段弱相关前者的准确率反而更高。那怎么判断相关性常见做法是用检索。检索的本质就是信息选择它帮你从海量数据里挑出最相关的那几条。但检索本身也有讲究不是召回的越多越好。我的经验是召回数量控制在三到五条每条控制在几百字以内这个区间在多数任务上表现最稳。超过这个量边际收益急剧下降甚至转负。提示检索的“相关”不等于“相似”。语义相似度高不代表对回答有帮助。判断相关性时最好结合任务目标来看而不是只看向量距离。2.3 信息组织怎么摆放更有效选好了信息接下来是怎么摆。同样的几段内容摆放顺序不同模型的表现可能差出一大截。一个被反复验证的规律是把最关键的信息放在开头或结尾中间放次要信息。这和人阅读长文档的习惯类似开头和结尾的注意力最集中。模型虽然机制不同但在长上下文里也表现出类似的“首尾偏好”。另一个规律是结构化。把信息用清晰的分段、标题、列表组织起来比一大段连续文本效果好。原因在于结构化信息降低了模型解析的负担它能更快定位到关键部分。我通常会用类似这样的组织方式【背景信息】 ...相关事实 【参考资料】 1. ...第一条 2. ...第二条 【当前问题】 ...用户问题这种分块方式让模型一眼就能看出哪部分是事实、哪部分是问题减少混淆。实测下来比把所有内容揉成一段准确率能高出十来个点。2.4 信息表达措辞的微妙影响信息表达是输入层最容易被忽视、但影响很直接的一环。同样一个意思换个说法模型的表现可能完全不同。最典型的是指令的明确程度。模糊的指令比如“帮我看看这个”模型只能猜明确的指令比如“判断下面这段话的情感是正面还是负面只输出正面或负面”模型就能精准执行。指令越具体输出越可控这是铁律。还有一个技巧是给示例。在输入里放一两个输入输出示例模型会模仿这个模式来回答。这在格式要求严格的任务上特别有用比如要求输出特定结构的 JSON给个示例比写一堆格式说明管用得多。注意示例要选有代表性的别选边界情况。示例选偏了模型会跟着偏。我一般会选最典型的一两个而不是最难的。2.5 输入层的常见误区输入层最容易踩的坑我总结下来有三个。第一个是信息过载。前面说过上下文不是越多越好。很多人怕模型信息不够拼命往里塞结果适得其反。判断标准很简单如果一段信息删掉之后模型回答不受影响那它就是多余的。第二个是指令和资料混在一起。把“你要做什么”和“这是参考资料”混在一段里模型容易分不清哪些是指令、哪些是数据。分开写用标记隔开能避免这个问题。第三个是忽视顺序。同样的信息顺序不同效果不同但很多人随手一拼就发出去了。花点时间调整顺序把最重要的放首尾收益很直接。3. 模型层决定模型怎么算3.1 模型层能动的其实不多模型层是三层里最“重”的一层也是最难动的一层。对绝大多数应用开发者来说基座模型是别人训练好的你能做的只有选择和调用。所以这一层的核心问题不是“怎么训练”而是“怎么选、怎么调”。选模型这件事很多人只看榜单排名这其实是个误区。榜单测的是通用能力而你的任务是具体的。一个在通用榜单上排第一的模型在你的垂直任务上未必比排第十的好。选模型要看任务匹配度而不是看排名。我的做法是先圈定几个候选模型然后用自己任务的真实数据做小规模对比测试。测试集不用大几十条有代表性的样本就够重点看在自己任务上的表现而不是看通用指标。这个测试花不了多少时间但能避免选错模型带来的长期成本。3.2 推理参数几个真正有用的旋钮选定模型后能调的主要是推理参数。参数不少但真正对效果有明显影响的其实就那么几个。温度是最常被提到的。它控制输出的随机性温度低输出更确定温度高输出更多样。我的经验是需要准确、稳定的任务温度调到接近零需要创意、多样的任务温度调到中等偏高。但要注意温度不是越高越好太高会导致输出发散、逻辑混乱。最大输出长度也很关键。设得太短回答会被截断设得太长模型可能啰嗦。根据任务类型来定分类任务几十个 token 就够长文生成则要留足空间。重复惩罚在长文本生成时有用能减少模型复读机式的重复。但惩罚系数别设太高太高会让输出变得不自然。参数作用推荐范围适用场景温度控制随机性0 到 1准确任务取低创意任务取中高最大长度限制输出长度按任务定分类取小生成取大重复惩罚抑制重复1.0 到 1.2长文本生成3.3 微调什么时候值得做微调是模型层里成本最高、门槛最高的操作但也不是所有场景都值得做。我的判断标准是当输入层和输出层都优化到极限效果仍然不达标且你有足够的高质量标注数据时才考虑微调。为什么把微调放这么后面因为微调的成本不只是训练成本还有数据标注成本、维护成本、迭代成本。而且微调后的模型通用能力往往会下降需要小心平衡。很多团队一上来就想微调结果发现投入大量资源后效果提升还不如把输入层优化一下。微调真正适合的场景是任务非常固定、格式要求非常严格、且通用模型怎么调都达不到要求的情况。比如特定的结构化抽取、特定风格的文本生成。这种场景下微调能带来质变。3.4 模型层的取舍逻辑模型层的取舍本质是在效果、成本、速度之间找平衡。更强的模型效果更好但更贵、更慢更小的模型更快、更便宜但能力有限。我的策略是分层使用。简单任务用小模型复杂任务用大模型或者先用小模型试不行再升级到大模型。这种路由策略能在保证效果的同时控制成本。实测下来很多任务其实小模型就够用没必要全都上大模型。提示模型选型别一次定死。业务在变模型也在迭代定期重新评估是必要的。我一般每季度会重新跑一次对比测试。4. 输出层决定结果怎么用4.1 输出层是被低估的重灾区如果说输入层是大家比较重视的那输出层就是最容易被忽视的。很多人拿到模型输出直接就用了不做任何处理。这在 demo 阶段没问题但一上生产就出问题。模型输出有几个天然的不确定性格式可能不对、内容可能有错、边界情况可能没覆盖。这些问题不处理直接暴露给用户或下游系统轻则体验差重则出事故。输出层的价值就是把这些不确定性兜住。我见过一个项目模型输出直接入库结果某次模型多输出了一段解释文字导致数据解析失败整条链路卡住。如果输出层做了格式校验和清洗这种问题根本不会发生。4.2 解析把输出变成可用的结构解析是输出层的第一步。模型输出的是文本但下游系统往往需要结构化数据。这一步要做的就是把文本转成结构。最常见的是 JSON 解析。让模型输出 JSON然后解析成对象。但模型输出的 JSON 经常有问题比如多了个逗号、少了引号、或者干脆包在 markdown 代码块里。所以解析不能直接json.loads要先做清洗去掉多余标记再尝试解析失败了要有兜底。import json import re def parse_model_output(text): # 去掉 markdown 代码块标记 text re.sub(rjson|, , text).strip() try: return json.loads(text) except json.JSONDecodeError: # 尝试提取第一个 JSON 对象 match re.search(r\{.*\}, text, re.DOTALL) if match: try: return json.loads(match.group()) except json.JSONDecodeError: return None return None这段代码看着简单但能挡掉大部分格式问题。关键是永远不要假设模型输出是完美的一定要有兜底逻辑。4.3 校验把错误挡在门外解析完之后是校验。校验分两层一层是格式校验一层是内容校验。格式校验检查结构对不对字段全不全类型对不对。内容校验检查值合不合理比如数值在不在范围内、枚举值在不在允许集合里。这两层校验做完才能把数据交给下游。校验失败怎么办常见做法是重试。把校验失败的输出和错误信息一起塞回给模型让它重新生成。重试一般设一到两次太多会拖慢响应。如果重试还失败就走兜底逻辑比如返回默认值、转人工、或者给用户一个友好的提示。注意重试不是万能的。如果模型反复在同一个地方出错说明输入层可能有问题要回头检查输入而不是无限重试。4.4 后处理让输出更自然校验通过之后还有一步后处理目的是让输出更符合使用场景。后处理包括格式化、去重、补充、裁剪等。比如模型输出了一段带 markdown 标记的文本但你的展示场景不支持 markdown就要去掉标记。再比如模型输出了重复的内容要去重。这些处理看着琐碎但直接影响用户体验。还有一个重要的后处理是一致性检查。多轮对话里模型这次说的和上次说的可能矛盾。后处理阶段可以做一致性校验发现矛盾就标记出来或者触发重新生成。这在需要连贯性的场景里很重要。4.5 输出层的兜底设计输出层最重要的设计原则是永远假设模型会出错并为此准备好兜底。兜底分几个层次。第一层是重试让模型自己修正。第二层是降级用更保守的策略生成。第三层是兜底内容比如返回一个默认回复。第四层是转人工把处理不了的交给人工。这四层兜底能保证即使模型出问题系统也不会崩。我做过统计加了完整兜底之后线上事故率下降了一个数量级。这个投入非常值得。5. 三层联动新花样到底新在哪5.1 用三层框架识别新概念回到开头的问题怎么判断一个新概念值不值得跟。用三层框架一套答案就清楚了。如果它动的是输入层比如新的提示词组织方式、新的检索策略那大概率值得看因为输入层优化成本低、见效快。如果它动的是输出层比如新的解析校验方案、新的后处理流程也值得看因为输出层直接关系到稳定性。如果它动的是模型层比如新的微调方法、新的推理技术那要看你的资源和技术储备门槛相对高。这个判断方法能帮你过滤掉大量噪音。很多所谓的新花样拆开看不过是输入层或输出层的微调核心思想早就有了只是换了个包装。5.2 三层之间的相互影响三层不是孤立的它们之间有相互影响。输入层给的信息变了模型层的表现会变输出层的处理方式变了对输入层的要求也会变。举个例子如果你在输出层加了严格的结构校验那输入层就要相应地把格式要求写得更清楚减少模型出错的概率。反过来如果输入层给了很清晰的示例输出层的校验压力就小很多。这种联动关系在优化时要一起考虑不能只盯着一层改。我的习惯是每次优化都记录下改的是哪一层、效果变化多少。时间长了就能积累出自己任务上的“敏感度地图”知道哪一层的改动对自己任务影响最大。5.3 一个完整的优化案例说个具体的。之前做一个信息抽取任务从非结构化文本里抽结构化字段。一开始效果很差准确率不到六成。按三层拆解排查输入层发现给的文本太长关键信息被淹没于是加了检索只给相关段落模型层换了个更适合抽取任务的模型输出层加了字段校验和重试。三步做完准确率到了九成以上。其中贡献最大的是输入层的检索其次是输出层的校验模型层的贡献反而最小。这个结果再次印证了输入和输出这两层才是应用开发者真正的主战场。5.4 三层框架的边界这套框架也不是万能的。它主要适用于“用现成模型做应用”的场景。如果你是从零训练模型那模型层就是主战场框架的重心要调整。另外框架是帮你理清思路的工具不是教条。实际项目里三层往往要一起调反复迭代。别指望一次就把三层都调到最优那是理想情况。真实情况是先调输入层看效果再调输出层看稳定性最后才考虑模型层。这个顺序能让你用最小的成本拿到最大的收益。6. 实操中的经验与避坑6.1 输入层的三个实操技巧第一个技巧是先做减法再做加法。很多人优化输入层第一反应是加东西加示例、加背景、加约束。但更有效的做法是先减把没用的去掉看效果是不是反而更好。我做过好几次删掉一半上下文效果不降反升。第二个技巧是用真实数据测。别用自己编的例子测用线上真实的数据测。真实数据里的边界情况、噪声、多样性是编不出来的。只有用真实数据测才能发现真正的问题。第三个技巧是记录每次改动。输入层的改动很微妙改了什么、效果变了多少不记录的话很快就忘了。我一般会维护一个简单的表格记录改动内容、测试结果、结论。这个习惯帮我避免了很多重复踩坑。6.2 输出层的避坑清单输出层有几个坑我列出来你对照检查。坑表现解法不做解析直接使用格式错误导致下游崩溃加解析和清洗校验太松错误数据流入下游加格式和内容校验重试无上限响应变慢甚至死循环设重试上限和超时无兜底模型出错时系统无响应设计多层兜底后处理缺失输出不自然、不一致加格式化和一致性检查这张表里的每一条都是我真金白银踩出来的。尤其是重试无上限这条曾经导致过一个线上问题排查了半天才发现是重试逻辑没设上限。6.3 模型层的选型心得模型选型我的心得是别追新追稳。新模型出来先别急着换等它稳定一段时间看看社区反馈再决定要不要上。追新带来的收益往往抵不上不稳定带来的成本。另外多模型备份是必要的。别把宝押在一个模型上万一它出问题或者涨价你还有退路。我一般会保持两到三个候选模型定期测试随时可以切换。6.4 三层优化的优先级最后说说优先级。我的建议是输入层 输出层 模型层。输入层优化成本最低、见效最快应该最先做。输出层优化能提升稳定性是上生产的必要条件。模型层优化成本最高放在最后且只在前面两层都做到位之后才考虑。这个优先级不是绝对的但作为一个默认策略能帮你把有限的精力花在刀刃上。很多项目效果不好不是模型不行而是输入和输出这两层没做好。把这两层做扎实效果自然就上来了。这套三层拆解我用了很久也教给过不少人。它最大的价值不是告诉你具体怎么做而是给你一个思考的框架让你在面对层出不穷的新概念时能快速判断、理性选择。新花样会一直有但底层逻辑就那么几条。抓住这几条就不会被带着跑。 
长河君 · 2026/10/22 11:18:16 · 阅读 1.2k 大模型应用三层架构拆解：输入、模型与输出层的优化实践
1. 大模型三层架构到底在拆什么1.1 从一个常见困惑说起这两年做大模型应用开发的人几乎都会经历一个相似的阶段每隔几周就冒出一个新概念今天是某个新的提示词框架明天是某个新的智能体编排方案后天又出来一个检索增强的变体。追着追着就发现自己像在追一条永远追不上的尾巴学了一堆名词但真正落到项目里还是不知道该怎么选、怎么搭。我自己也踩过这个坑。最开始做对话类应用的时候看到什么新方案都想往项目里塞结果架构越堆越复杂调试成本直线上升最后发现真正决定效果的根本不是那些花哨的编排层而是两个最朴素的问题你往模型里输入了什么以及你拿到模型输出之后怎么处理。把这句话再抽象一层其实所有大模型应用不管包装成什么形态都可以拆成三层来看。这个拆法不是某个官方标准而是我在多个项目里反复验证后总结出来的一套心智模型。它最大的价值在于当你再看到一个新概念时能立刻判断出它到底动的是哪一层从而决定要不要跟、值不值得跟。1.2 三层架构的整体轮廓先把三层摆出来后面再逐层展开。层级名称核心职责典型代表第一层输入层决定模型看到什么提示词、上下文拼接、检索结果、工具描述第二层模型层决定模型怎么算基座模型、微调权重、推理参数第三层输出层决定结果怎么用解析、校验、重试、格式化、后处理很多人一上来就盯着第二层觉得换个更强的模型就能解决一切。但实际项目里第一层和第三层能撬动的效果往往比换模型大得多而且成本低、迭代快。原因很简单模型层是别人训练好的你能动的空间有限而输入和输出这两层完全掌握在你自己手里。这个判断不是拍脑袋来的。我做过一个对比实验同一个任务固定模型不变只优化输入层的上下文组织方式准确率从六成出头提到了八成五以上再叠加输出层的校验和重试机制最终稳定在九成以上。整个过程没有动过一次模型权重也没有换过基座。这就是三层拆解的实际意义——它告诉你力气该往哪儿使。1.3 为什么这个拆法值得反复用有人可能会问市面上已经有那么多架构图了为什么还要自己搞一套。我的体会是大部分架构图是给“系统”画的讲的是数据怎么流动、服务怎么部署而三层拆解是给“效果”画的讲的是模型行为怎么被影响。这两个视角不冲突但解决的问题不一样。当你遇到效果问题时系统架构图帮不了你因为它不会告诉你“为什么模型这次答偏了”。但三层拆解可以先看输入层是不是给的信息不够或者有干扰再看模型层是不是能力边界到了最后看输出层是不是没做兜底。这个排查顺序能帮你快速定位问题所在而不是盲目地换模型、调参数。所以这套拆法我用了两年多从简单的文本分类到复杂的多轮工具调用基本都能套进去。接下来就逐层拆开讲每一层我会说清楚它管什么、怎么调、有哪些坑。2. 输入层决定模型看到什么2.1 输入层的本质是信息筛选输入层做的事情说白了就一件在模型有限的上下文窗口里塞进最有用的信息同时尽量不塞没用的。这件事听起来简单做起来极难因为“有用”和“没用”的边界往往要试了才知道。我见过太多项目输入层就是简单地把用户问题往模板里一填就发出去了。这种做法的上限很低因为模型拿到的信息量太少只能靠自己的先验知识硬答。而先验知识是有边界的一旦问题涉及私有数据、实时数据或者领域细节模型就开始编。输入层的优化空间主要体现在三个维度上信息的选择、信息的组织、信息的表达。这三个维度层层递进每一层都能带来明显的效果提升。2.2 信息选择什么该放进去信息选择是输入层的第一道关。核心原则是只放和当前任务直接相关的信息相关性越强越好数量越少越好。这里有个反直觉的点很多人以为上下文给得越多模型答得越准。实际恰恰相反。上下文过长会带来两个问题一是稀释注意力模型可能抓不住重点二是引入噪声无关信息会干扰判断。我做过测试同一个问答任务给模型三段相关文档和给十段文档其中七段弱相关前者的准确率反而更高。那怎么判断相关性常见做法是用检索。检索的本质就是信息选择它帮你从海量数据里挑出最相关的那几条。但检索本身也有讲究不是召回的越多越好。我的经验是召回数量控制在三到五条每条控制在几百字以内这个区间在多数任务上表现最稳。超过这个量边际收益急剧下降甚至转负。提示检索的“相关”不等于“相似”。语义相似度高不代表对回答有帮助。判断相关性时最好结合任务目标来看而不是只看向量距离。2.3 信息组织怎么摆放更有效选好了信息接下来是怎么摆。同样的几段内容摆放顺序不同模型的表现可能差出一大截。一个被反复验证的规律是把最关键的信息放在开头或结尾中间放次要信息。这和人阅读长文档的习惯类似开头和结尾的注意力最集中。模型虽然机制不同但在长上下文里也表现出类似的“首尾偏好”。另一个规律是结构化。把信息用清晰的分段、标题、列表组织起来比一大段连续文本效果好。原因在于结构化信息降低了模型解析的负担它能更快定位到关键部分。我通常会用类似这样的组织方式【背景信息】 ...相关事实 【参考资料】 1. ...第一条 2. ...第二条 【当前问题】 ...用户问题这种分块方式让模型一眼就能看出哪部分是事实、哪部分是问题减少混淆。实测下来比把所有内容揉成一段准确率能高出十来个点。2.4 信息表达措辞的微妙影响信息表达是输入层最容易被忽视、但影响很直接的一环。同样一个意思换个说法模型的表现可能完全不同。最典型的是指令的明确程度。模糊的指令比如“帮我看看这个”模型只能猜明确的指令比如“判断下面这段话的情感是正面还是负面只输出正面或负面”模型就能精准执行。指令越具体输出越可控这是铁律。还有一个技巧是给示例。在输入里放一两个输入输出示例模型会模仿这个模式来回答。这在格式要求严格的任务上特别有用比如要求输出特定结构的 JSON给个示例比写一堆格式说明管用得多。注意示例要选有代表性的别选边界情况。示例选偏了模型会跟着偏。我一般会选最典型的一两个而不是最难的。2.5 输入层的常见误区输入层最容易踩的坑我总结下来有三个。第一个是信息过载。前面说过上下文不是越多越好。很多人怕模型信息不够拼命往里塞结果适得其反。判断标准很简单如果一段信息删掉之后模型回答不受影响那它就是多余的。第二个是指令和资料混在一起。把“你要做什么”和“这是参考资料”混在一段里模型容易分不清哪些是指令、哪些是数据。分开写用标记隔开能避免这个问题。第三个是忽视顺序。同样的信息顺序不同效果不同但很多人随手一拼就发出去了。花点时间调整顺序把最重要的放首尾收益很直接。3. 模型层决定模型怎么算3.1 模型层能动的其实不多模型层是三层里最“重”的一层也是最难动的一层。对绝大多数应用开发者来说基座模型是别人训练好的你能做的只有选择和调用。所以这一层的核心问题不是“怎么训练”而是“怎么选、怎么调”。选模型这件事很多人只看榜单排名这其实是个误区。榜单测的是通用能力而你的任务是具体的。一个在通用榜单上排第一的模型在你的垂直任务上未必比排第十的好。选模型要看任务匹配度而不是看排名。我的做法是先圈定几个候选模型然后用自己任务的真实数据做小规模对比测试。测试集不用大几十条有代表性的样本就够重点看在自己任务上的表现而不是看通用指标。这个测试花不了多少时间但能避免选错模型带来的长期成本。3.2 推理参数几个真正有用的旋钮选定模型后能调的主要是推理参数。参数不少但真正对效果有明显影响的其实就那么几个。温度是最常被提到的。它控制输出的随机性温度低输出更确定温度高输出更多样。我的经验是需要准确、稳定的任务温度调到接近零需要创意、多样的任务温度调到中等偏高。但要注意温度不是越高越好太高会导致输出发散、逻辑混乱。最大输出长度也很关键。设得太短回答会被截断设得太长模型可能啰嗦。根据任务类型来定分类任务几十个 token 就够长文生成则要留足空间。重复惩罚在长文本生成时有用能减少模型复读机式的重复。但惩罚系数别设太高太高会让输出变得不自然。参数作用推荐范围适用场景温度控制随机性0 到 1准确任务取低创意任务取中高最大长度限制输出长度按任务定分类取小生成取大重复惩罚抑制重复1.0 到 1.2长文本生成3.3 微调什么时候值得做微调是模型层里成本最高、门槛最高的操作但也不是所有场景都值得做。我的判断标准是当输入层和输出层都优化到极限效果仍然不达标且你有足够的高质量标注数据时才考虑微调。为什么把微调放这么后面因为微调的成本不只是训练成本还有数据标注成本、维护成本、迭代成本。而且微调后的模型通用能力往往会下降需要小心平衡。很多团队一上来就想微调结果发现投入大量资源后效果提升还不如把输入层优化一下。微调真正适合的场景是任务非常固定、格式要求非常严格、且通用模型怎么调都达不到要求的情况。比如特定的结构化抽取、特定风格的文本生成。这种场景下微调能带来质变。3.4 模型层的取舍逻辑模型层的取舍本质是在效果、成本、速度之间找平衡。更强的模型效果更好但更贵、更慢更小的模型更快、更便宜但能力有限。我的策略是分层使用。简单任务用小模型复杂任务用大模型或者先用小模型试不行再升级到大模型。这种路由策略能在保证效果的同时控制成本。实测下来很多任务其实小模型就够用没必要全都上大模型。提示模型选型别一次定死。业务在变模型也在迭代定期重新评估是必要的。我一般每季度会重新跑一次对比测试。4. 输出层决定结果怎么用4.1 输出层是被低估的重灾区如果说输入层是大家比较重视的那输出层就是最容易被忽视的。很多人拿到模型输出直接就用了不做任何处理。这在 demo 阶段没问题但一上生产就出问题。模型输出有几个天然的不确定性格式可能不对、内容可能有错、边界情况可能没覆盖。这些问题不处理直接暴露给用户或下游系统轻则体验差重则出事故。输出层的价值就是把这些不确定性兜住。我见过一个项目模型输出直接入库结果某次模型多输出了一段解释文字导致数据解析失败整条链路卡住。如果输出层做了格式校验和清洗这种问题根本不会发生。4.2 解析把输出变成可用的结构解析是输出层的第一步。模型输出的是文本但下游系统往往需要结构化数据。这一步要做的就是把文本转成结构。最常见的是 JSON 解析。让模型输出 JSON然后解析成对象。但模型输出的 JSON 经常有问题比如多了个逗号、少了引号、或者干脆包在 markdown 代码块里。所以解析不能直接json.loads要先做清洗去掉多余标记再尝试解析失败了要有兜底。import json import re def parse_model_output(text): # 去掉 markdown 代码块标记 text re.sub(rjson|, , text).strip() try: return json.loads(text) except json.JSONDecodeError: # 尝试提取第一个 JSON 对象 match re.search(r\{.*\}, text, re.DOTALL) if match: try: return json.loads(match.group()) except json.JSONDecodeError: return None return None这段代码看着简单但能挡掉大部分格式问题。关键是永远不要假设模型输出是完美的一定要有兜底逻辑。4.3 校验把错误挡在门外解析完之后是校验。校验分两层一层是格式校验一层是内容校验。格式校验检查结构对不对字段全不全类型对不对。内容校验检查值合不合理比如数值在不在范围内、枚举值在不在允许集合里。这两层校验做完才能把数据交给下游。校验失败怎么办常见做法是重试。把校验失败的输出和错误信息一起塞回给模型让它重新生成。重试一般设一到两次太多会拖慢响应。如果重试还失败就走兜底逻辑比如返回默认值、转人工、或者给用户一个友好的提示。注意重试不是万能的。如果模型反复在同一个地方出错说明输入层可能有问题要回头检查输入而不是无限重试。4.4 后处理让输出更自然校验通过之后还有一步后处理目的是让输出更符合使用场景。后处理包括格式化、去重、补充、裁剪等。比如模型输出了一段带 markdown 标记的文本但你的展示场景不支持 markdown就要去掉标记。再比如模型输出了重复的内容要去重。这些处理看着琐碎但直接影响用户体验。还有一个重要的后处理是一致性检查。多轮对话里模型这次说的和上次说的可能矛盾。后处理阶段可以做一致性校验发现矛盾就标记出来或者触发重新生成。这在需要连贯性的场景里很重要。4.5 输出层的兜底设计输出层最重要的设计原则是永远假设模型会出错并为此准备好兜底。兜底分几个层次。第一层是重试让模型自己修正。第二层是降级用更保守的策略生成。第三层是兜底内容比如返回一个默认回复。第四层是转人工把处理不了的交给人工。这四层兜底能保证即使模型出问题系统也不会崩。我做过统计加了完整兜底之后线上事故率下降了一个数量级。这个投入非常值得。5. 三层联动新花样到底新在哪5.1 用三层框架识别新概念回到开头的问题怎么判断一个新概念值不值得跟。用三层框架一套答案就清楚了。如果它动的是输入层比如新的提示词组织方式、新的检索策略那大概率值得看因为输入层优化成本低、见效快。如果它动的是输出层比如新的解析校验方案、新的后处理流程也值得看因为输出层直接关系到稳定性。如果它动的是模型层比如新的微调方法、新的推理技术那要看你的资源和技术储备门槛相对高。这个判断方法能帮你过滤掉大量噪音。很多所谓的新花样拆开看不过是输入层或输出层的微调核心思想早就有了只是换了个包装。5.2 三层之间的相互影响三层不是孤立的它们之间有相互影响。输入层给的信息变了模型层的表现会变输出层的处理方式变了对输入层的要求也会变。举个例子如果你在输出层加了严格的结构校验那输入层就要相应地把格式要求写得更清楚减少模型出错的概率。反过来如果输入层给了很清晰的示例输出层的校验压力就小很多。这种联动关系在优化时要一起考虑不能只盯着一层改。我的习惯是每次优化都记录下改的是哪一层、效果变化多少。时间长了就能积累出自己任务上的“敏感度地图”知道哪一层的改动对自己任务影响最大。5.3 一个完整的优化案例说个具体的。之前做一个信息抽取任务从非结构化文本里抽结构化字段。一开始效果很差准确率不到六成。按三层拆解排查输入层发现给的文本太长关键信息被淹没于是加了检索只给相关段落模型层换了个更适合抽取任务的模型输出层加了字段校验和重试。三步做完准确率到了九成以上。其中贡献最大的是输入层的检索其次是输出层的校验模型层的贡献反而最小。这个结果再次印证了输入和输出这两层才是应用开发者真正的主战场。5.4 三层框架的边界这套框架也不是万能的。它主要适用于“用现成模型做应用”的场景。如果你是从零训练模型那模型层就是主战场框架的重心要调整。另外框架是帮你理清思路的工具不是教条。实际项目里三层往往要一起调反复迭代。别指望一次就把三层都调到最优那是理想情况。真实情况是先调输入层看效果再调输出层看稳定性最后才考虑模型层。这个顺序能让你用最小的成本拿到最大的收益。6. 实操中的经验与避坑6.1 输入层的三个实操技巧第一个技巧是先做减法再做加法。很多人优化输入层第一反应是加东西加示例、加背景、加约束。但更有效的做法是先减把没用的去掉看效果是不是反而更好。我做过好几次删掉一半上下文效果不降反升。第二个技巧是用真实数据测。别用自己编的例子测用线上真实的数据测。真实数据里的边界情况、噪声、多样性是编不出来的。只有用真实数据测才能发现真正的问题。第三个技巧是记录每次改动。输入层的改动很微妙改了什么、效果变了多少不记录的话很快就忘了。我一般会维护一个简单的表格记录改动内容、测试结果、结论。这个习惯帮我避免了很多重复踩坑。6.2 输出层的避坑清单输出层有几个坑我列出来你对照检查。坑表现解法不做解析直接使用格式错误导致下游崩溃加解析和清洗校验太松错误数据流入下游加格式和内容校验重试无上限响应变慢甚至死循环设重试上限和超时无兜底模型出错时系统无响应设计多层兜底后处理缺失输出不自然、不一致加格式化和一致性检查这张表里的每一条都是我真金白银踩出来的。尤其是重试无上限这条曾经导致过一个线上问题排查了半天才发现是重试逻辑没设上限。6.3 模型层的选型心得模型选型我的心得是别追新追稳。新模型出来先别急着换等它稳定一段时间看看社区反馈再决定要不要上。追新带来的收益往往抵不上不稳定带来的成本。另外多模型备份是必要的。别把宝押在一个模型上万一它出问题或者涨价你还有退路。我一般会保持两到三个候选模型定期测试随时可以切换。6.4 三层优化的优先级最后说说优先级。我的建议是输入层 输出层 模型层。输入层优化成本最低、见效最快应该最先做。输出层优化能提升稳定性是上生产的必要条件。模型层优化成本最高放在最后且只在前面两层都做到位之后才考虑。这个优先级不是绝对的但作为一个默认策略能帮你把有限的精力花在刀刃上。很多项目效果不好不是模型不行而是输入和输出这两层没做好。把这两层做扎实效果自然就上来了。这套三层拆解我用了很久也教给过不少人。它最大的价值不是告诉你具体怎么做而是给你一个思考的框架让你在面对层出不穷的新概念时能快速判断、理性选择。新花样会一直有但底层逻辑就那么几条。抓住这几条就不会被带着跑。