大模型应用三层架构拆解：输入层、模型层与输出层的工程实践

1. 大模型三层架构到底在拆什么1.1 从一个常见困惑说起这两年做大模型应用开发的人几乎都会经历一个相似的阶段每隔几周就冒出一个新概念今天是某个新的提示词框架明天是某个新的智能体编排方案后天又出来一个检索增强的新玩法。追着追着就发现自己像在追一条永远追不上的尾巴学了一堆名词但真正落到项目里还是不知道该怎么选、怎么搭。我自己也踩过这个坑。最开始做对话类应用的时候看到别人用什么多轮反思、什么思维链、什么工具调用就一股脑往项目里塞结果系统变得又慢又贵效果还不稳定。后来复盘才发现问题不在于这些技术本身不好而在于我没有搞清楚它们各自处在整个系统的哪一层解决的是哪一类问题。把大模型应用拆开来看不管外面包装了多少新名词本质上都逃不出三层结构输入层、模型层、输出层。而真正决定一个应用好不好用的往往不是中间那个模型本身而是输入什么和输出怎么处理这两头。模型层反而是相对标准化的一层你换一个模型接口大同小异但输入怎么组织、输出怎么加工才是各家产品拉开差距的地方。这篇文章就是想把这三层彻底拆开讲清楚。我会说明每一层到底在做什么、为什么这么分层、每一层里那些花里胡哨的技术到底在解决什么问题以及在实际项目里应该怎么选、怎么搭。适合正在做大模型应用、被各种新概念绕晕、想找一个稳定框架来理解这一切的开发者。看完之后你再看任何一个新的AI玩法都能快速判断它属于哪一层、值不值得用。1.2 三层架构的划分逻辑先说清楚这三层是怎么划的以及为什么这么划。输入层指的是从用户发出请求到真正把内容送进模型之前的所有处理。这里面包括提示词的组装、上下文的拼接、历史对话的管理、外部知识的检索、工具的描述注入等等。一句话概括输入层决定了模型看到什么。模型层指的是模型本身完成推理计算的过程。这一层包括模型的选择、参数的配置、推理的调度、多模型的协同等等。它决定了模型怎么想。输出层指的是模型吐出结果之后到最终呈现给用户之前的所有处理。这里面包括结果的解析、格式的校验、内容的过滤、多轮结果的聚合、失败重试等等。它决定了模型说的话怎么变成能用的东西。为什么这么分因为这三层的变化频率和可控程度完全不同。模型层是最不稳定的模型版本迭代快、能力边界模糊、输出有随机性你很难完全控制它。而输入层和输出层是你可以完全掌控的你可以精确地决定给模型看什么、怎么让它看、拿到结果后怎么加工。所以一个成熟的系统一定是把尽可能多的确定性放在输入层和输出层把模型层当成一个能力提供方来用而不是把全部逻辑都押在模型身上。这个思路听起来简单但真正落地的时候很多人会不自觉地违反它。比如把复杂的业务规则写进提示词里让模型去判断这就是把本该在输出层做的校验推给了模型层结果就是不稳定。理解了分层逻辑你就能避免这类错误。2. 输入层决定模型看到什么2.1 提示词组装的核心思路输入层最基础的工作就是组装提示词。很多人觉得提示词就是把话写清楚其实远不止于此。提示词组装本质上是一个信息压缩和结构化的过程你要在有限的上下文窗口里塞进最能让模型做出正确判断的信息。我一般把提示词分成几个固定模块来组织角色设定、任务描述、约束条件、输入数据、输出格式要求。这几个模块的顺序和边界要清晰因为模型对位置是敏感的放在开头和放在结尾的信息被重视的程度不一样。角色设定放在最前面是为了给模型一个稳定的行为基调。但这里有个常见的误区就是角色写得越详细越好。实际上角色描述太长反而会稀释任务本身的权重。我的经验是角色设定控制在两三句话说清楚你是谁、你擅长什么、你的风格是什么就够了。任务描述是核心要具体到可执行。比如帮我分析这段文本就是模糊的从情感倾向、关键实体、潜在风险三个维度分析这段文本每个维度给出判断依据就是可执行的。任务描述越具体模型的输出越稳定。约束条件容易被忽略但它恰恰是提升稳定性的关键。比如如果信息不足明确说明缺少什么不要编造这一句就能大幅减少幻觉。约束条件要针对你实际遇到过的问题来写而不是抄一堆通用的。输入数据要明确标注边界。我习惯用清晰的分隔符把输入数据包起来比如用三个反引号或者特定的标记这样模型能准确区分指令和数据避免把数据里的内容当成指令来执行。输出格式要求放在最后因为模型对结尾的信息记忆比较深。如果你需要结构化输出这里要写清楚字段名、类型、示例。2.2 上下文管理与历史对话处理多轮对话是输入层里最容易被低估的部分。很多人以为多轮对话就是把历史消息全部拼进去其实这里面有很多讲究。首先是上下文窗口的预算分配。模型的上下文窗口是有限的历史对话、检索到的知识、当前问题、系统提示都要抢这块空间。如果不做管理很容易出现历史对话把知识挤没了或者知识把当前问题挤没了的情况。我的做法是给每一类内容设定一个预算上限比如系统提示占10%历史对话占30%检索知识占40%当前问题占20%超出就按优先级裁剪。其次是历史对话的压缩。当对话轮次多了全部保留既浪费空间又引入噪声。常见的做法有两种一种是滑动窗口只保留最近N轮另一种是摘要压缩把早期对话总结成一段摘要。滑动窗口简单但会丢失早期信息摘要压缩保留信息但会引入摘要本身的误差。我一般结合使用最近几轮保留原文更早的做摘要。还有一个细节是历史对话的清洗。用户的历史消息里可能包含无关内容、错误信息、甚至恶意注入。直接拼进去会污染模型的判断。我习惯在拼接前做一轮过滤把明显无关的内容去掉把可能是指令注入的内容做转义处理。提示上下文管理没有万能方案要根据你的具体场景来调。对话类应用重历史问答类应用重知识任务类应用重当前指令。先想清楚你的场景里哪类信息最重要再决定预算怎么分。2.3 外部知识检索的接入方式检索增强是输入层里最热门的技术但很多人用不好问题往往出在检索和组装的衔接上。检索本身是另一套系统的事这里只说检索结果怎么接入输入层。核心原则是检索到的内容不能直接堆进去要做筛选、排序、压缩。筛选是指去掉不相关的结果。检索系统返回的Top-K结果里往往有一部分是噪声。我一般会加一个相关性打分的环节低于阈值的直接丢掉。宁可少给几条也不要给一堆无关的干扰模型。排序是指把最相关的结果放在最显眼的位置。模型对上下文的不同位置敏感度不同把最重要的信息放在开头或结尾效果通常更好。压缩是指把长文档精简成关键片段。检索到的文档可能很长全部塞进去会挤占其他信息的空间。我习惯把每篇文档压缩成几句话的核心摘要或者只保留和当前问题最相关的段落。还有一个容易被忽略的点是引用标注。在拼接检索内容时给每条内容标上来源编号然后在输出格式要求里让模型引用编号。这样一方面方便追溯另一方面能约束模型不要编造因为它知道自己的每句话都要对应到具体来源。2.4 工具描述与函数调用的注入当应用需要模型调用外部工具时工具的描述也是输入层的一部分。这部分做得好不好直接决定了模型能不能正确选择和使用工具。工具描述的核心是让模型知道什么时候该用这个工具。很多人只写了工具的功能没写使用场景结果模型要么不用要么乱用。我的做法是每个工具描述里都包含三部分这个工具做什么、什么情况下用、输入参数是什么格式。参数描述要具体。比如一个查询天气的工具参数是城市名那就要说明城市名用中文不要带市字后缀这类细节。模型对参数的格式很敏感描述不清楚就容易传错。工具数量也要控制。工具太多会让模型选择困难而且每个工具的描述都占上下文。我一般把工具控制在十个以内超过就考虑分组或者用路由先做一层筛选。注意工具描述里的示例很重要。给一两个正确的调用示例能大幅提升模型调用的准确率。示例要覆盖典型的参数组合不要只给最简单的。3. 模型层能力提供方的正确用法3.1 模型选型的考量维度模型层虽然相对标准化但选型仍然是个技术活。选型不是选最强的而是选最合适的。我一般从几个维度来考量。能力匹配度是第一位的。不同模型在不同任务上的表现差异很大有的擅长推理有的擅长创作有的擅长代码。选型前要先明确你的核心任务是什么然后找在这个任务上表现好的模型。不要迷信榜单榜单上的综合分高不代表在你的具体任务上就好。成本是绕不开的。模型调用是按量计费的输入和输出的价格还不一样。如果你的应用调用量大成本会迅速累积。我一般会算一笔账单次调用的平均token消耗乘以日均调用量再乘以单价看看月度成本是否在预算内。如果超了就要考虑用更便宜的模型或者优化输入输出来降低token消耗。延迟直接影响用户体验。有些模型能力强但响应慢适合离线处理有些模型响应快但能力一般适合实时交互。要根据你的场景来权衡。我做过一个实时对话的应用最开始用了能力最强的模型结果用户等得不耐烦后来换成响应更快的模型体验反而更好。稳定性是长期运行的关键。有些模型高峰期会限流有些模型偶尔会返回异常。选型时要考虑有没有备用方案能不能快速切换。下面这张表是我常用的选型对照供参考考量维度关键问题常见取舍能力匹配核心任务是什么专用模型 vs 通用模型成本月度预算多少强模型少调用 vs 弱模型多调用延迟能接受多长响应实时交互 vs 离线批处理稳定性能否容忍异常单模型 vs 多模型备份3.2 参数配置的实际影响模型层有一堆参数可以调但真正影响大的就那么几个。我把常用的几个说一下实际影响。温度控制输出的随机性。温度低输出稳定但可能呆板温度高输出多样但可能跑偏。做事实性问答温度要低做创意生成温度可以高。我一般从0.3开始试根据效果上下调。最大输出长度要设合理。设太短输出被截断设太长浪费成本还可能让模型啰嗦。我一般根据任务预估一个合理值比如摘要任务设500创作任务设2000。top_p和温度类似控制采样的范围。一般调一个就行不用两个都调。我习惯固定top_p只调温度。惩罚项包括频率惩罚和存在惩罚用来抑制重复。如果发现模型老是重复同样的话可以适当加一点。但加太多会让输出变得不自然。这些参数没有标准答案要在你的具体任务上试。我的建议是每次只调一个参数观察效果变化找到适合你任务的组合后固定下来。3.3 多模型协同的常见模式单一模型往往满足不了复杂需求多模型协同就成了常见方案。我总结了几种模式。级联模式是用小模型先处理处理不了的再交给大模型。比如先用便宜的小模型做意图识别识别出复杂意图再调用大模型。这样能大幅降低成本。投票模式是让多个模型对同一问题给出答案然后取多数或综合。适合对准确性要求高的场景但成本翻倍。分工模式是不同模型负责不同环节。比如一个模型负责理解一个模型负责生成一个模型负责校验。这种模式灵活但编排复杂。兜底模式是主模型失败时切换到备用模型。适合对可用性要求高的场景。选哪种模式取决于你的核心诉求是成本、准确性还是可用性。我一般从级联模式开始因为它性价比最高。3.4 推理调度的稳定性设计模型调用不是百分之百成功的超时、限流、返回异常都可能发生。稳定性设计就是让系统在这些情况下还能正常工作。重试是最基本的。调用失败后等一小段时间再试通常能成功。但重试要有上限不能无限重试。我一般设两到三次间隔递增。超时要设合理。设太短正常的长响应会被误杀设太长用户等太久。我一般根据任务复杂度设简单任务10秒复杂任务30秒。降级是重试都失败后的方案。可以返回一个预设的兜底回复或者切换到备用模型。降级方案要提前准备好不能等出问题了才想。熔断是防止雪崩的。当某个模型连续失败多次就暂时不再调用它过一段时间再试。这样能避免把资源浪费在已经不可用的服务上。提示稳定性设计要在开发阶段就做不要等上线了出问题再补。我见过太多项目功能做得花哨一上量就崩就是因为没做这些基础设计。4. 输出层把模型的话变成能用的东西4.1 结构化输出的解析与校验模型输出的第一道处理就是解析。如果你要求了结构化输出就要有对应的解析逻辑。JSON解析是最常见的。但模型输出的JSON经常有问题比如多了markdown标记、少了引号、多了注释。解析前要先做清洗把代码块标记去掉把明显的格式问题修掉。解析失败要有兜底不能让整个流程崩掉。字段校验是解析后的必要步骤。检查必填字段有没有、类型对不对、值在不在合理范围。校验不通过的要标记出来走重试或人工处理。容错解析是应对模型不听话的。有时候模型就是不给标准格式这时候可以用正则提取关键信息或者用另一个模型来解析。我一般先试标准解析失败了再走容错。4.2 内容过滤与安全校验输出层是安全的最后一道关。模型可能生成不合适的内容必须在呈现给用户前过滤掉。敏感词过滤是最基础的。维护一个敏感词库输出前扫一遍命中的做替换或拦截。词库要定期更新覆盖新出现的风险词。内容分类是更高级的。用分类模型判断输出是否属于某个风险类别比如暴力、歧视、误导。分类模型可以比敏感词更准确地识别变体。一致性校验是防止自相矛盾的。有时候模型前后说的话不一致可以通过逻辑检查发现。比如前面说A是B后面说A不是B就要标记出来。过滤策略要平衡安全和体验。过滤太严正常内容被误伤过滤太松风险内容漏过。我一般分级处理高风险的直接拦截中风险的加提示低风险的放行但记录。4.3 多轮结果的聚合与去重当一次请求触发了多次模型调用输出层要把这些结果聚合起来。聚合是把多个结果合并成一个。比如让模型从不同角度分析同一问题输出层要把这些分析整合成一份完整报告。聚合可以用规则也可以用模型来做。去重是去掉重复内容。多次调用可能产生相似的结果直接拼接会很冗余。我一般用相似度计算超过阈值的只保留一条。排序是决定呈现顺序。重要的放前面次要的放后面。排序可以按相关性、按时间、按重要性。4.4 失败重试与降级策略输出层的失败处理同样重要。解析失败、校验不通过、过滤拦截都要有对应的处理。重试是首选。解析失败可以重新调用模型校验不通过可以把问题反馈给模型让它重做。重试要带上失败原因让模型知道哪里错了。降级是重试失败后的方案。可以返回部分结果可以返回预设回复可以转人工。降级方案要让用户知道发生了什么不要静默失败。记录是改进的依据。每次失败都要记录原因定期分析找出高频问题从输入层或模型层去优化。5. 三层协同的实战要点5.1 一个完整请求的生命周期把三层串起来看一个请求的完整流程是这样的用户输入进来输入层做预处理组装提示词拼接上下文检索知识注入工具描述然后调用模型层。模型层完成推理返回结果。输出层解析结果校验格式过滤内容聚合多轮结果最后呈现给用户。这个流程里每一层都可能出问题每一层都要有监控和日志。我习惯在每层的入口和出口都打点记录耗时、成功率、异常类型。这样出问题的时候能快速定位是哪一层的锅。5.2 各层的优化优先级资源有限的时候优化要有优先级。我的经验是先优化输入层再优化输出层最后才考虑模型层。为什么因为输入层的优化成本最低、见效最快。把提示词写好、把上下文管好、把知识检索做好往往能解决大部分效果问题。输出层的优化次之主要是提升稳定性和安全性。模型层的优化成本最高换模型、调参数、做协同都要投入不少精力而且效果不一定比前两层优化好。我见过很多项目一上来就纠结用哪个模型其实他们的提示词写得一塌糊涂换个再好的模型也救不回来。5.3 常见误区与避坑清单最后整理几个我踩过的坑供参考。误区一把业务逻辑写进提示词。提示词适合做引导不适合做精确判断。复杂的业务规则应该在代码里实现不要指望模型去执行。误区二忽视上下文预算。上下文窗口是有限资源不做管理就会互相挤占。要提前规划好各类内容的预算。误区三不做输出校验。模型输出不可信必须校验。不校验的系统迟早出问题。误区四只调模型不调输入输出。效果不好就换模型是治标不治本。先看看输入输出有没有优化空间。误区五不做监控和日志。出了问题不知道哪层的问题只能瞎猜。监控和日志是排查的基础。常见误区后果正确做法业务逻辑写进提示词不稳定、难维护规则用代码实现忽视上下文预算信息互相挤占提前规划预算不做输出校验异常输出直接呈现加解析和校验只调模型治标不治本先优化输入输出不做监控问题难定位每层打点记录这套三层架构的思路我在多个项目里用过最大的价值是提供了一个稳定的分析框架。不管外面出什么新概念你都可以问自己它属于哪一层解决什么问题值不值得引入想清楚这几个问题就不会被各种新花样带偏。