1. 大模型三层架构到底在拆什么1.1 从一个常见困惑说起这两年AI圈的新概念几乎是以周为单位往外冒。今天某个团队发布了一个“推理增强框架”明天另一个团队开源了“多智能体协作系统”后天又有人提出了“记忆增强对话架构”。名字一个比一个唬人架构图一张比一张复杂但如果你真的把这些东西拆开来看会发现一个很有意思的规律绝大多数所谓的“新花样”本质上都在做同一件事——要么改变输入给模型的内容要么改变模型输出之后的处理方式。我自己在过去一年多的时间里前前后后复现过十几个不同方向的AI应用项目从最简单的提示词工程到稍微复杂一点的检索增强生成再到多轮工具调用的智能体系统。踩了一圈坑之后我总结出一个非常实用的分析框架我把它叫做大模型三层架构。这个框架不涉及任何具体的模型内部结构而是从工程实现的角度把几乎所有大模型应用拆成三个层次来看。这三层分别是输入层、模型层、输出层。其中模型层对于绝大多数开发者来说是一个黑盒——你没法改GPT的内部权重也没法动Claude的注意力机制。所以真正能做出差异化的地方全部集中在输入层和输出层。这就是为什么我说所有AI新花样只在“输入什么”和“输出怎么处理”。1.2 三层架构的划分逻辑先把这个框架说清楚。输入层指的是在把请求发送给大模型之前你对输入做了哪些加工。这包括但不限于系统提示词的编写、上下文信息的拼接、历史对话的筛选、外部知识的检索与注入、用户意图的预处理等等。模型层就是大模型本身你调用API或者本地部署它负责根据输入生成输出。输出层指的是模型返回结果之后你对这个结果做了哪些后处理。这包括格式校验、内容过滤、结构化解析、多轮迭代、结果聚合、工具调用后的二次处理等等。为什么这么分因为在实际工程中模型层是不可控的。你换一个模型可能效果会变但你能做的事情非常有限——无非是选型、调参、微调。而输入层和输出层是完全由开发者掌控的你可以在这里做无限的创新。理解了这一点你再去看那些花里胡哨的新概念就能很快判断出它到底在哪个层面做文章。举个例子所谓“思维链提示”本质上是在输入层做文章——你在提示词里引导模型一步步思考。所谓“自洽性采样”本质上是在输出层做文章——你让模型生成多个答案然后投票选出最一致的那个。所谓“检索增强生成”横跨输入层和输出层——输入层注入检索到的文档输出层可能还要做引用标注和事实校验。1.3 为什么这个框架值得掌握掌握这个框架的好处非常直接。第一降低学习成本。你不需要每出一个新概念就去从头学一遍只需要判断它属于哪一层然后和你已知的方法做对比。第二提高方案设计能力。当你要解决一个具体问题时你可以系统性地思考我应该在输入层做什么优化在输出层做什么处理而不是盲目地试各种“最新技术”。第三方便技术选型。市面上的工具和框架非常多但如果你能清楚地知道每个工具在哪个层面起作用选型就会变得很有条理。我见过太多团队一上来就说要用“最先进的智能体架构”结果拆开一看核心逻辑就是在输入层拼了一段格式化的提示词在输出层做了一次JSON解析。不是说这样做不对而是如果你一开始就能看清楚本质就不会被那些复杂的架构图吓到也能更务实地评估工作量。2. 输入层决定模型看到什么2.1 系统提示词的设计哲学输入层最基础也最重要的部分就是系统提示词。很多人觉得写提示词就是“跟模型说清楚你要什么”这话没错但远远不够。系统提示词实际上是在定义模型的角色、约束模型的输出空间、提供必要的背景知识。我自己的经验是一个好的系统提示词应该包含四个要素角色定义、任务描述、约束条件、输出格式。角色定义决定了模型用什么样的语气和知识域来回应。比如你写“你是一个资深的法律顾问”模型就会倾向于用严谨、保守的语言你写“你是一个创意文案写手”模型就会更放得开。任务描述要具体到可执行的程度不要写“帮我分析一下这个问题”而要写“请从成本、工期、风险三个维度分析以下方案每个维度给出至少两条具体建议”。约束条件包括字数限制、禁止事项、边界情况处理等。输出格式最好给出明确的模板或示例。这里有一个很多人忽略的点系统提示词的顺序会影响效果。我把这个叫做“提示词的位置效应”。通常来说模型对开头和结尾的内容注意力更集中中间部分容易被稀释。所以重要的约束条件应该放在开头或结尾而不是埋在中间。我实测下来把输出格式要求放在系统提示词的最后一段遵循率会明显提高。2.2 上下文拼接的策略与陷阱上下文拼接是输入层的第二大块。当你需要模型基于某些材料来回答问题时你就要把这些材料拼接到输入里。听起来很简单但实际操作中有很多讲究。首先是拼接位置材料放在系统提示词之前还是之后放在用户问题之前还是之后我的经验是如果材料是背景知识放在系统提示词之后、用户问题之前比较合适如果材料是针对当前问题的参考资料放在用户问题之后、紧挨着问题效果更好。其次是拼接长度。大模型有上下文窗口限制你不能无限制地往里塞。而且即使没到上限过长的上下文也会导致“中间遗忘”现象——模型对中间部分的信息利用率明显下降。所以你需要做筛选和压缩。筛选的策略包括按相关性排序取Top-K、按时间倒序取最近N条、按重要性加权采样等。压缩的策略包括摘要化、关键信息抽取、去重合并等。还有一个很容易踩的坑拼接格式。如果你把多段材料简单地用换行拼在一起模型可能分不清哪些是材料、哪些是指令。我通常会用明确的分隔符和标签来标记比如用XML风格的标签把每段材料包起来并标注来源和类型。这样模型在生成回答时也能更方便地引用具体来源。2.3 检索增强输入层最核心的扩展手段检索增强生成是目前输入层最主流的扩展手段。它的核心思想很简单模型的知识有限那就从外部知识库里检索相关内容拼接到输入里让模型基于这些内容来回答。但要做好检索增强涉及的技术点非常多。首先是文档切分。你不能把一整本书直接塞进去需要切成合适大小的块。块太大检索精度下降块太小上下文不完整。常见的做法是按语义段落切分每块控制在200到500字之间块与块之间保留一定的重叠。重叠的作用是避免关键信息刚好被切断。其次是向量化与索引。你需要把每个文本块转成向量存到向量数据库里。向量化的质量直接影响检索效果。不同的嵌入模型在不同语言、不同领域上的表现差异很大需要根据你的实际数据来选。索引结构也有讲究常见的有扁平索引、倒排索引、层次化索引等分别适用于不同的数据规模和查询模式。然后是检索策略。最简单的就是按向量相似度取Top-K。但实际用起来纯向量检索经常会出现“语义相似但实际不相关”的情况。所以通常会结合关键词检索做混合检索再用重排序模型对结果做精排。重排序这一步非常关键它能把真正相关的内容排到前面显著提升最终效果。最后是注入方式。检索到的内容怎么拼接到输入里是直接罗列还是加上引导语我通常会在检索内容前面加一句“以下是与问题相关的参考资料请基于这些资料回答如果资料中没有相关信息请明确说明”。这样能减少模型编造答案的概率。2.4 输入层的进阶玩法除了上面说的这些输入层还有一些进阶玩法。比如少样本示例在输入里给几个“问题-答案”的示例让模型模仿这个模式来回答。示例的选择很关键要覆盖典型场景和边界情况。又比如动态提示词根据用户输入的类型动态选择不同的系统提示词模板。这需要你先做一个意图分类然后路由到对应的提示词。还有一个很有意思的方向是输入压缩。当上下文太长时你可以先用一个小模型或者规则方法把输入压缩一遍再送给大模型。压缩的方式包括抽取关键句、生成摘要、去除冗余信息等。这样做的好处是降低token消耗、加快响应速度同时可能提升效果因为去掉了噪声。我自己的体会是输入层的优化往往能带来最直接的收益。你把输入整理得越清晰、越有结构、越有针对性模型的输出质量就越高。而且输入层的优化通常不需要训练成本低、迭代快非常适合快速验证。3. 输出层决定模型给出什么3.1 结构化解析与格式校验输出层最基础的工作是结构化解析。大模型返回的通常是自然语言文本但你的下游系统可能需要JSON、XML或者特定的数据结构。所以你需要从文本里提取出结构化信息。最简单的做法是在提示词里要求模型输出JSON然后直接解析。但实际用起来模型经常会输出一些“额外的话”比如“好的以下是JSON”或者“希望这对你有帮助”。这些都会导致解析失败。所以你需要做格式校验和容错处理。我的做法是先用正则表达式提取出JSON部分然后尝试解析如果失败再用一个修复提示词让模型重新输出如果还失败就降级到人工处理或者返回默认值。这个流程看起来简单但在生产环境里非常必要。我见过太多项目因为没做容错模型偶尔输出一个格式错误就导致整个流程崩溃。除了JSON还有其他的结构化格式需求。比如你需要模型输出一个列表但模型可能输出成段落你需要模型输出一个评分但模型可能输出成一段解释。这些都需要在输出层做处理。通用的思路是在提示词里明确格式要求在输出层做严格校验对不合规的输出做修复或重试。3.2 内容过滤与安全校验输出层的第二项重要工作是内容过滤。模型可能会生成不准确、不适当或者不符合你业务要求的内容。你需要在输出层做一道防线。过滤的维度包括事实准确性、合规性、语气风格、敏感信息等。事实准确性方面如果你的应用场景对准确性要求高可以考虑做事实校验。一种做法是把模型的回答拆成若干事实断言然后逐条去知识库或者搜索引擎验证。这个做法成本较高但效果显著。另一种做法是让模型自己标注哪些部分是推测、哪些部分有依据然后在输出层根据标注做处理。合规性方面你需要根据你的业务场景定义一套规则。比如某些行业不能出现特定的承诺性语言某些场景不能出现个人隐私信息。这些规则可以用关键词匹配、正则表达式或者分类模型来实现。输出层的过滤应该是多层的先做快速规则过滤再做精细模型过滤最后做人工抽检。3.3 多轮迭代与自我修正输出层最有价值的能力之一是多轮迭代。模型一次生成的结果往往不够完美但你可以让模型基于第一次的输出做修正。常见的模式包括生成-批评-修正、生成-验证-重试、多方案生成-选择最优。“生成-批评-修正”的模式是这样的先让模型生成一个初稿然后让另一个模型实例或者同一个模型用不同的提示词对初稿提出批评意见最后让模型根据批评意见修改。这个模式在写作、代码生成等场景下效果很好。批评的提示词要具体比如“请从逻辑一致性、事实准确性、语言流畅度三个维度评价以下内容并给出具体的修改建议”。“生成-验证-重试”的模式适用于有明确验证标准的场景。比如你让模型生成一个SQL查询你可以先在测试数据库上执行验证如果报错就让模型根据错误信息重新生成。这个模式的关键是验证要自动化、错误信息要反馈给模型。“多方案生成-选择最优”的模式适用于创意类任务。让模型生成多个不同风格的方案然后用一个评分模型或者规则来选出最好的。这个模式的好处是能覆盖更多的可能性缺点是成本成倍增加。3.4 工具调用与结果聚合输出层的另一个重要能力是工具调用。模型本身不能查天气、不能发邮件、不能操作数据库但它可以生成调用这些工具的指令。输出层需要解析这些指令执行对应的工具然后把结果返回给模型或者直接返回给用户。工具调用的流程通常是模型输出一个结构化的工具调用请求包含工具名和参数输出层解析这个请求调用对应的函数拿到结果再把结果拼回上下文让模型生成最终回答。这个流程可能循环多次直到模型认为不需要再调用工具为止。这里的关键点是错误处理和超时控制。工具调用可能失败、可能超时、可能返回意料之外的结果。你需要在输出层做好这些情况的处理。我的做法是给每个工具调用设置超时时间失败时返回一个明确的错误信息给模型让模型决定是重试、换工具还是直接告诉用户无法完成。同时要设置最大循环次数防止模型陷入无限调用。结果聚合是另一个需要关注的点。当模型调用了多个工具或者做了多轮生成你需要把这些结果整合成一个连贯的回答。聚合的策略包括按时间顺序拼接、按重要性排序、生成一个摘要等。聚合的质量直接影响用户体验值得花时间打磨。4. 模型层不可控中的可控4.1 模型选型的核心考量虽然模型层对大多数开发者来说是个黑盒但选型仍然是最重要的决策之一。选型要考虑的维度包括能力、成本、延迟、稳定性、可定制性。能力方面不同模型在推理、写作、代码、多语言等维度上各有强弱需要根据你的任务特点来选。成本方面API调用按token计费不同模型价格差异很大需要算清楚你的预算。延迟方面有些模型响应快但能力弱有些模型能力强但响应慢。如果你的应用是实时对话延迟就很重要如果是离线批处理延迟可以放宽。稳定性方面要考虑API的可用性、限流策略、故障恢复机制。可定制性方面有些模型支持微调有些只支持提示词工程这会影响你的优化空间。我自己的经验是不要迷信“最强模型”。很多任务用中等能力的模型加上好的输入输出设计效果比用最强模型裸跑要好得多。而且中等模型的成本和延迟优势非常明显。所以选型的原则应该是先用中等模型做原型验证输入输出层的设计如果效果不够再升级模型。4.2 参数调优的实用技巧模型层虽然不能改内部结构但有一些参数可以调。最常见的是温度和Top-P。温度控制输出的随机性温度越高输出越多样温度越低输出越确定。对于需要准确性的任务温度设低一些对于创意类任务温度可以设高一些。Top-P控制采样范围通常和温度配合使用。还有一个重要参数是最大输出长度。设得太短模型可能话没说完就被截断设得太长浪费token还可能让模型啰嗦。我的做法是根据任务类型设置一个合理的上限同时在提示词里也说明期望的长度范围。频率惩罚和存在惩罚也是常用参数。频率惩罚降低重复词的出现概率存在惩罚鼓励模型引入新话题。这两个参数在长文本生成时比较有用但调得太高会导致语言不自然。我通常从0开始根据实际输出逐步调整。4.3 微调与提示词工程的取舍当提示词工程遇到瓶颈时很多人会考虑微调。微调确实能提升特定任务的效果但成本高、周期长、灵活性差。我的建议是先穷尽提示词工程的可能性再考虑微调。因为提示词工程迭代快、成本低而且很多问题其实通过更好的输入设计就能解决。如果确实需要微调也要注意几点。第一数据质量比数量重要几百条高质量样本可能比几万条低质量样本效果好。第二微调后的模型可能在其他任务上表现下降要做好评估。第三微调模型和提示词工程可以结合使用微调负责领域适应提示词负责任务适配。5. 三层架构的实战拆解5.1 案例一智能客服系统的架构设计假设你要做一个智能客服系统。用三层架构来拆解输入层要做的是用户意图识别、历史对话筛选、知识库检索、情绪识别。输出层要做的是回答格式校验、敏感词过滤、转人工判断、满意度预测。模型层就是选一个对话能力强的模型。具体来说输入层的意图识别可以用一个小分类模型来做把用户问题分到“咨询”“投诉”“售后”等类别然后路由到不同的提示词模板。历史对话筛选要保留最近几轮以及和当前问题相关的轮次避免上下文过长。知识库检索要结合产品文档和常见问题库用混合检索加重的排序。情绪识别可以用关键词加模型判断如果用户情绪激动输出层就要考虑优先转人工。输出层的敏感词过滤要覆盖业务禁语和合规要求。转人工判断要综合意图、情绪、模型置信度等因素。满意度预测可以在回答后面加一个隐式的反馈收集。整个系统的核心逻辑都在输入输出层模型层只是其中一个组件。5.2 案例二代码生成助手的架构设计再假设你要做一个代码生成助手。输入层要做的是编程语言识别、代码上下文提取、相关文档检索、错误信息解析。输出层要做的是代码语法校验、单元测试执行、格式化、注释生成。输入层的代码上下文提取很关键。你需要把当前文件的相关部分、依赖的接口定义、项目规范等信息拼接到输入里。相关文档检索可以从官方文档、内部wiki里找参考资料。错误信息解析是把编译错误或运行错误转成模型能理解的描述。输出层的语法校验可以用对应语言的解析器来做。单元测试执行是自动生成测试用例并运行验证代码是否正确。格式化用标准的格式化工具。注释生成是让模型给代码加注释提升可读性。这些输出层的处理能显著提升代码的可用性。5.3 案例三数据分析报告的架构设计再举一个数据分析报告的例子。输入层要做的是数据表结构解析、指标定义检索、分析目标澄清、历史报告参考。输出层要做的是数据计算校验、图表生成、结论一致性检查、报告格式化。输入层的数据表结构解析是把数据库的schema转成模型能理解的描述。指标定义检索是从指标字典里找到相关指标的计算口径。分析目标澄清是通过多轮对话明确用户到底想看什么。历史报告参考是找类似的分析报告作为风格和结构的参考。输出层的数据计算校验是把模型生成的SQL或计算逻辑实际执行一遍验证结果是否合理。图表生成是根据数据特点自动选择合适的图表类型。结论一致性检查是确保报告中的结论和数据对得上。报告格式化是输出成标准的报告模板。这些处理让最终报告既准确又美观。6. 常见问题与排查技巧6.1 输入层常见问题问题一模型忽略系统提示词中的约束。排查思路检查约束条件是否放在提示词的开头或结尾检查约束条件是否表述清晰、无歧义检查是否与用户问题冲突。解决技巧把最重要的约束用加粗或特殊标记标出在用户问题后面再重复一遍关键约束用少样本示例展示期望的行为。问题二检索内容不相关。排查思路检查文档切分是否合理检查嵌入模型是否适合你的领域检查检索策略是否单一。解决技巧调整切分粒度增加重叠换用领域适配的嵌入模型引入重排序模型结合关键词检索。问题三上下文过长导致效果下降。排查思路统计输入token数检查是否有冗余信息检查关键信息是否在中间位置。解决技巧做输入压缩把关键信息移到开头或结尾用摘要替代原文分批处理。6.2 输出层常见问题问题一JSON解析失败。排查思路检查模型输出是否包含额外文本检查JSON是否格式正确检查是否有特殊字符。解决技巧用正则提取JSON部分让模型重新生成用JSON修复工具在提示词里强调只输出JSON。问题二模型编造事实。排查思路检查输入是否提供了足够的事实依据检查提示词是否允许模型在不确定时承认不知道。解决技巧在提示词里明确要求基于给定资料回答要求模型标注信息来源对关键事实做外部校验降低温度参数。问题三多轮工具调用陷入循环。排查思路检查工具返回的错误信息是否清晰检查模型是否理解工具的能力边界检查是否有终止条件。解决技巧设置最大调用次数在工具返回错误时给出明确的处理建议在提示词里说明工具的使用场景和限制。6.3 三层协同的常见问题问题一输入层和输出层的处理逻辑冲突。比如输入层要求模型输出简洁输出层又需要详细信息来做校验。解决技巧统一设计输入输出规范在输入层就考虑输出层的需求用中间格式做过渡。问题二整体延迟过高。排查思路分别测量输入层、模型层、输出层的耗时找出瓶颈环节。解决技巧输入层做并行检索模型层选更快的模型或流式输出输出层做异步处理缓存常用结果。问题三效果评估困难。排查思路明确评估指标建立测试集做消融实验。解决技巧把评估拆到每一层输入层评估检索准确率模型层评估生成质量输出层评估最终可用性。7. 我踩过的坑和总结的经验7.1 不要过早追求复杂架构我刚开始做AI应用的时候总想着一步到位上来就搞多智能体、记忆系统、复杂的工作流。结果发现大部分复杂度并没有带来相应的效果提升反而让调试变得极其困难。后来我学乖了先用最简单的三层架构跑通再逐步增加复杂度。每次只加一个变量确保能清楚地知道是哪个改动带来了效果变化。7.2 输入层的投入产出比最高在三个层里输入层的优化往往能带来最直接的收益。把提示词写清楚、把上下文整理好、把检索做准确这些工作的成本不高但效果提升很明显。我见过很多团队花大量时间调模型参数、搞微调但提示词写得一塌糊涂上下文拼得乱七八糟最后效果不好还找不到原因。7.3 输出层的容错决定生产可用性实验室里跑通和在生产环境可用是两回事。生产环境里模型会输出各种意料之外的内容网络会抖动工具会失败。输出层的容错处理决定了你的系统能不能真正上线。我的经验是输出层的代码量往往是输入层的两到三倍因为要处理各种边界情况。7.4 建立自己的评估体系没有评估就没有优化。你需要建立一套适合自己业务的评估体系包括自动指标和人工评估。自动指标可以快速筛选方案人工评估可以把握最终质量。评估集要覆盖典型场景和边界情况并且要定期更新防止过拟合。7.5 保持对新技术的好奇但审慎AI领域的新概念层出不穷保持好奇是好事但不要盲目跟风。看到一个新技术先用三层架构拆解一下看它到底在哪个层面做了什么。如果它解决的问题你正好遇到那就深入研究如果它只是换了个名字那就没必要花时间。真正有价值的技术往往是在某一层上做出了实质性的改进而不是包装了一个新概念。这个三层架构我用了很长时间帮我在面对各种新概念时保持清醒。希望它也能帮你更高效地理解和应用大模型技术。后续我还会继续分享每一层的具体实现细节和代码示例感兴趣的话可以持续关注。