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领域的新概念层出不穷，保持好奇是好事，但不要盲目跟风。看到一个新技术，先用三层架构拆解一下，看它到底在哪个层面做了什么。如果它解决的问题你正好遇到，那就深入研究；如果它只是换了个名字，那就没必要花时间。真正有价值的技术，往往是在某一层上做出了实质性的改进，而不是包装了一个新概念。
这个三层架构我用了很长时间，帮我在面对各种新概念时保持清醒。希望它也能帮你更高效地理解和应用大模型技术。后续我还会继续分享每一层的具体实现细节和代码示例，感兴趣的话可以持续关注。
