1. 大模型三层架构到底在拆什么第一次听到“大模型三层架构”这个说法很多人会下意识觉得又是哪个厂商在造概念。但我自己把市面上主流的大模型应用从里到外扒了一遍之后发现这个拆法确实抓住了本质。不管你看到的是对话助手、代码补全、文档问答、还是最近满天飞的智能体剥掉外壳之后核心逻辑都可以归到三个层次上输入层、模型层、输出层。这个拆法最大的价值在于它帮你把“AI能做什么”这个问题从“模型有多强”转移到了“你怎么设计输入和输出”。我见过太多团队在选模型上纠结几个月却对输入怎么组织、输出怎么处理几乎不做设计最后效果不好就怪模型不行。实际情况是同一个模型输入设计得好不好输出处理得细不细最终体验差距可以大到像两个产品。这篇文章适合谁看如果你是刚接触大模型应用开发的新手它能帮你建立一个清晰的思考框架知道力气该往哪里使。如果你已经在做相关项目但总觉得效果差口气它能帮你定位问题到底出在哪个环节。如果你只是对AI应用感兴趣的产品或运营角色它也能让你在和开发沟通时知道对方在说什么。我下面会按三层架构逐层拆解每一层都会讲清楚这一层到底在干什么、为什么这么设计、实际操作中怎么做、以及我踩过的坑。最后会给出一个完整的实操流程和常见问题排查表你可以直接拿去对照自己的项目。2. 输入层决定模型看到什么2.1 输入层的核心任务是什么输入层要做的事情说白了就一句话把用户的原始意图翻译成模型能理解、且能给出好结果的形式。用户说“帮我写个东西”这是原始意图。模型需要的是明确的指令、足够的上下文、以及合理的格式约束。输入层的所有工作都是在这两者之间搭桥。很多人低估了这一层的重要性觉得不就是把用户的话传给模型吗但实际做过就知道同样的模型输入层设计得好和不好输出质量能差出好几个档次。我做过一个对比测试同一个模型一组用原始用户提问直接调用另一组经过输入层优化补充角色设定、明确输出格式、加入示例后者的可用率从不到40%提升到了85%以上。输入层具体包含哪些工作我把它拆成四个核心模块指令设计、上下文管理、格式约束、示例注入。这四个模块不是每个场景都要全用但你需要知道它们各自解决什么问题什么时候该用哪个。2.2 指令设计把话说清楚比什么都重要指令设计是输入层最基础也最容易被忽视的部分。我见过太多人写指令的方式就是直接把用户问题扔进去然后抱怨模型回答不好。实际上指令设计有几个关键要素需要你刻意去组织。角色设定是最先要明确的。你让模型扮演什么角色它会调用不同的知识和表达方式。比如同样是回答一个技术问题“你是一个资深工程师”和“你是一个技术文档写手”给出的答案风格完全不同。前者更偏向实战经验后者更偏向结构化说明。我通常会在指令开头就明确角色而且角色要具体不要写“你是一个助手”这种废话要写“你是一个有十年经验的后端开发擅长用通俗语言解释复杂概念”。任务描述要具体到可执行的程度。“帮我分析一下”这种指令太模糊模型只能猜你想要什么。改成“请从性能、成本、维护难度三个维度分析以下方案每个维度给出评分和理由”模型就知道该怎么做了。这里有个经验任务描述里动词越具体输出越可控。“分析”“对比”“总结”“改写”“生成”这些动词每一个对应的输出结构都不一样。约束条件是很多人会漏掉的。你不告诉模型什么不能做它就可能给你一堆你不想要的东西。比如“不要使用专业术语”“控制在300字以内”“不要列举超过5个点”这些约束能大幅减少后期筛选的工作量。我一般会把约束分成硬约束和软约束硬约束是必须遵守的比如字数、格式软约束是尽量满足的比如语气、风格。实操心得指令设计完之后先自己读一遍。如果你读完都不知道具体要做什么模型肯定也不知道。一个简单的检验方法把指令给一个不了解背景的同事看问他“你知道我要你做什么吗”如果他能准确说出来说明指令合格了。2.3 上下文管理给模型足够的背景信息上下文管理解决的是“模型不知道背景”的问题。大模型本身没有记忆它只能看到你这一次传给它的内容。所以你需要把相关的背景信息、历史对话、参考资料都组织好传给它。这里有个关键决策什么信息该放什么信息不该放。放少了模型不了解情况放多了会稀释关键信息还可能超出模型的上下文窗口。我的经验是遵循“相关性优先”原则只放和当前任务直接相关的信息间接相关的用摘要形式带过不相关的坚决不放。具体操作上我通常会把上下文分成几个区块背景说明、历史对话摘要、参考资料、当前问题。背景说明用一两句话交代场景历史对话如果有就用摘要形式比如“用户之前询问了X我回答了Y”参考资料如果是文档就截取相关段落当前问题放在最后让模型重点关注。上下文长度控制是个技术活。我试过把一整篇文档直接扔进去让模型回答细节问题结果模型经常抓错重点。后来改成先用关键词检索出最相关的三段再传给模型准确率明显提升。这个思路就是现在常说的检索增强生成核心逻辑就是用检索来筛选上下文而不是把所有东西都塞进去。2.4 格式约束与示例注入让输出更可控格式约束解决的是“输出乱七八糟”的问题。你不告诉模型要什么格式它就可能给你一段散文、一个列表、或者一堆代码块混在一起。我通常会在指令里明确指定输出格式比如“用JSON格式返回”“用Markdown表格呈现”“分三段每段不超过100字”。示例注入是格式约束的加强版。与其用文字描述你要什么格式不如直接给一个例子。比如你要模型从一段文本里抽取信息与其说“请抽取姓名、年龄、职业”不如直接给一个示例输入和对应的输出。模型看到例子之后格式准确率会大幅提升。这个技巧在需要结构化输出的场景里特别好用我基本上每次做信息抽取都会带一两个示例。不过示例也不是越多越好。我试过给五个示例结果模型有时候会把示例里的具体内容也带进输出里。后来改成给一到两个高质量示例效果反而更稳定。示例的质量比数量重要一个覆盖了边界情况的示例比五个普通示例都有用。3. 模型层真正干活的那一层3.1 模型层在架构中的位置模型层是三层架构里最“黑盒”的一层。输入层把整理好的内容传进来模型层负责计算和生成输出层再把结果处理成用户能用的形式。对于大多数应用开发者来说模型层是你要去适配的而不是你要去改造的。你没法改变模型本身的参数但你可以选择用哪个模型、怎么调用它、以及调用时给什么参数。这里有个常见的认知误区很多人觉得模型层就是“选一个最强的模型”。但实际上模型选型要考虑的因素远不止“强不强”。成本、速度、上下文窗口大小、是否支持特定格式输出、是否支持函数调用这些都是选型时要权衡的。我见过一个团队用最贵的模型做简单的文本分类成本是必要支出的十几倍完全没必要。模型层还有一个关键决策是单模型还是多模型组合。简单任务用一个小模型就够了复杂任务可能需要先用小模型做初步处理再用大模型做精细加工。这种“模型流水线”的思路在实际项目中很常见既能控制成本又能保证效果。3.2 模型选型的核心考量维度选模型的时候我一般会从五个维度来评估能力、成本、速度、上下文窗口、特殊功能。这五个维度不是孤立的需要根据你的具体场景来权衡。能力方面不同模型在不同任务上的表现差异很大。有的模型擅长代码生成有的擅长创意写作有的擅长逻辑推理。我的做法是用你自己的实际任务做评测不要只看公开榜单。公开榜单的测试集和你的实际场景可能差很远。我通常会准备20到50个真实案例让候选模型跑一遍人工评估结果质量这样得出的结论才靠谱。成本方面要算的是“完成任务的综合成本”而不是单纯的API调用价格。一个便宜但需要多次调用才能完成任务的模型综合成本可能比一个贵但一次就搞定的模型更高。我一般会算一个“单任务成本”就是完成一个典型任务平均需要花多少钱这个指标比单价更有参考价值。速度方面要区分“首字延迟”和“生成速度”。首字延迟影响用户的第一印象生成速度影响用户的等待体验。对于交互式应用首字延迟更重要对于批量处理任务生成速度更重要。我实测下来首字延迟在1秒以内用户基本无感超过3秒就会明显觉得卡。上下文窗口大小决定了你能一次性传给模型多少信息。但要注意上下文窗口大不代表效果好。我试过用大窗口模型处理长文档结果模型对中间部分的内容经常“视而不见”。后来改成把长文档切分成小块分别处理再汇总结果效果反而更好。所以上下文窗口够用就行不用盲目追求大。特殊功能方面比如是否支持JSON模式输出、是否支持函数调用、是否支持流式输出这些会直接影响你的开发方式。如果模型原生支持JSON输出你就不需要自己写解析和容错逻辑能省不少事。3.3 调用参数怎么调模型调用时有一堆参数可以调但真正需要你关注的其实就几个温度、最大输出长度、top_p。其他参数大部分时候用默认值就行。温度控制的是输出的随机性。温度越低输出越确定、越保守温度越高输出越多样、越有创意。我的经验是需要准确性的任务用低温度0到0.3需要创意的任务用高温度0.7到1.0。比如信息抽取、代码生成用0.1到0.2文案写作、头脑风暴用0.8到0.9。中间地带0.4到0.6我一般不用因为既不够准确也不够有创意比较鸡肋。最大输出长度要设置得合理。设得太短模型话没说完就断了设得太长模型可能会啰嗦一大堆。我一般会根据任务类型来设简短回答设200到500详细分析设1000到2000长文生成设3000到4000。如果不确定可以先设一个较大的值然后在输出层做截断处理。top_p是另一个控制随机性的参数和温度配合使用。大部分时候我只调温度top_p保持默认。如果发现输出太发散可以适当降低top_p如果发现输出太死板可以适当提高。但这两个参数不要同时大调否则很难定位问题。注意事项调参数的时候一次只调一个调完观察效果再调下一个。同时调多个参数你根本不知道是哪个参数起了作用。我见过有人一次调五个参数结果效果变差了都不知道该回退哪个。3.4 模型层的常见误区第一个误区是迷信“最强模型”。最强模型不一定最适合你的场景。我做过一个文本分类任务用中等模型加好的输入设计准确率比用最强模型加普通输入设计还高。模型只是整个系统的一环输入和输出的设计同样重要。第二个误区是忽略模型的“脾气”。不同模型对指令的敏感度不一样。有的模型你稍微改一下指令措辞输出就完全不同有的模型比较“固执”你怎么说它都按自己的方式来。我的做法是换模型的时候一定要重新调输入层的指令不要指望一套指令在所有模型上都好用。第三个误区是不做降级方案。模型服务偶尔会出问题响应变慢或者报错。如果你的应用完全依赖单一模型出问题的时候就抓瞎了。我一般会准备一个备用模型主模型不可用的时候自动切换。备用模型可以弱一点但至少保证服务不中断。4. 输出层决定用户最终看到什么4.1 输出层为什么重要输出层是三层架构里最容易被低估的一层。很多人觉得模型生成完了就结束了直接把原始输出扔给用户。但实际上模型原始输出和用户能用的结果之间还有很长一段路要走。模型输出有几个常见问题格式不对、内容冗余、包含不该有的信息、结构不清晰。这些问题如果不在输出层处理就会直接暴露给用户严重影响体验。我见过一个问答应用模型回答其实挺准确的但每次都要加一句“希望这个回答对你有帮助”用户看多了就很烦。这种问题在输出层加一个简单的过滤就能解决。输出层的工作可以分成三类格式处理、内容过滤、结构优化。格式处理是把模型输出转成你需要的格式比如从Markdown转成纯文本、从文本里提取JSON。内容过滤是去掉不想要的内容比如重复、敏感信息、无关内容。结构优化是让输出更易读比如分段、加标题、调整顺序。4.2 格式处理从模型输出到可用数据格式处理最常见的情况是从模型输出里提取结构化数据。比如你让模型从一段文本里抽取姓名、电话、地址模型可能会返回一段自然语言描述你需要把它转成JSON格式。这个过程叫“解析”是输出层最基础的工作。解析的难点在于模型输出不稳定。同样的指令模型这次返回JSON下次可能返回Markdown表格再下次可能返回一段散文。我的做法是在输入层就明确要求JSON格式并在输出层做容错解析。容错解析的意思是先尝试标准JSON解析失败了就尝试从文本里用正则提取再失败了就返回一个默认值并记录日志。如果模型原生支持JSON模式输出那最好直接用它。JSON模式会强制模型输出合法的JSON省去很多解析的麻烦。但要注意JSON模式有时候会让模型“为了格式牺牲内容”输出一些空字段或者占位符。所以用了JSON模式之后还是要检查内容质量。另一种常见的格式处理是Markdown转纯文本。模型很喜欢用Markdown格式输出加粗、列表、代码块满天飞。如果你的展示端不支持Markdown就需要在输出层做转换。我一般会写一个简单的转换函数把常见的Markdown标记去掉保留文本内容。4.3 内容过滤去掉不该出现的东西内容过滤要处理的问题包括重复内容、无关内容、敏感信息、格式噪音。这些问题不处理用户就会觉得“这个AI不太聪明的样子”。重复内容是模型输出里最常见的问题之一。模型有时候会反复说同一句话或者把前面的内容换个说法再说一遍。我的处理方式是检测连续重复的句子或段落只保留第一次出现。这个逻辑用简单的字符串匹配就能实现不需要太复杂的算法。无关内容是指模型输出里和问题不相关的内容。比如你问“今天天气怎么样”模型回答完天气之后又加了一段“如果你想了解气候变化的原因我可以进一步解释”。这种内容在输出层可以过滤掉或者至少折叠起来不让用户直接看到。敏感信息过滤是必须做的。模型可能会输出一些不该输出的内容比如内部测试数据、个人隐私信息、或者不适当的表述。我一般会维护一个敏感词列表在输出层做扫描发现敏感内容就替换或拦截。这个列表需要持续更新因为模型的输出模式会变化。格式噪音是指那些影响阅读的格式问题比如过多的空行、不统一的列表符号、错位的缩进。这些问题看起来小但很影响观感。我一般会在输出层做一次“格式化清洗”统一空行数量、统一列表符号、调整缩进。4.4 结构优化让输出更好读结构优化是在内容没问题的基础上让输出更易读、更有条理。我常用的手法有几种分段、加小标题、调整顺序、控制长度。分段是最基本的。模型有时候会输出一大段文字读起来很累。我一般会在输出层检测段落长度超过一定字数就按句子边界拆分成多段。这个逻辑很简单但效果很明显。加小标题适合内容较长的输出。如果模型输出了一篇几百字的分析我会在输出层根据内容自动生成小标题或者从模型输出里提取关键句作为小标题。这样用户扫一眼就知道每段在讲什么。调整顺序是指把最重要的内容放到前面。模型有时候会把结论放在最后但用户可能没耐心看到最后。我一般会在输出层检测“结论”“总结”这类关键词把对应的段落提到前面。或者更简单的方式是在输入层就要求模型“先给结论再给分析”。控制长度是最后一道关。不管模型输出多长最终展示给用户的内容要控制在一个合理范围内。我一般会根据场景设一个上限超过就截断或者折叠。截断的时候要注意在句子边界截不要截到一半。5. 三层架构的完整实操流程5.1 从零搭建一个三层架构应用下面我以一个“文档问答助手”为例完整走一遍三层架构的搭建流程。这个助手的场景是用户上传一份文档然后针对文档内容提问助手给出基于文档的回答。第一步输入层设计。输入层需要处理三件事接收用户问题、检索文档相关内容、组装成模型能理解的输入。用户问题直接拿来用但要做一些预处理比如去掉多余的空格、统一标点符号。文档检索我一般用关键词匹配加语义检索的组合先粗筛再精排选出最相关的三段内容。组装输入的时候我会按“背景说明文档片段用户问题输出要求”的结构来组织。第二步模型层调用。模型选型上文档问答场景我一般选上下文窗口较大、指令遵循能力较强的模型。调用参数上温度设0.2左右保证准确性最大输出长度设800到1000。如果文档内容很长我会把检索出来的片段分别传给模型让模型先分别回答再汇总而不是一次性把整篇文档传进去。第三步输出层处理。模型输出之后先做格式清洗去掉多余的Markdown标记。然后做内容检查确认回答是基于文档内容的没有编造信息。最后做结构优化如果回答较长就分段如果包含多个要点就用列表呈现。这个流程听起来简单但每一步都有细节。比如文档检索的粒度怎么定太粗了检索不准太细了上下文不完整。我的经验是按段落检索但检索到之后把前后各一段也带上这样既有针对性又有上下文。5.2 关键参数的计算与选择三层架构里涉及不少参数我挑几个关键的说说怎么定。上下文窗口分配假设模型上下文窗口是8000个token你需要决定怎么分配。我的分配方案是系统指令占500文档片段占4000历史对话占1000用户问题占200输出预留2300。这个分配不是固定的根据实际情况调整。如果文档片段不够用就减少历史对话的占比。检索片段数量检索多少个文档片段传给模型太少了信息不够太多了稀释重点。我一般检索3到5个片段每个片段200到500字。这个数量是试出来的你可以从3个开始逐步增加观察效果变化。我实测下来超过5个片段之后效果提升就不明显了反而增加成本和延迟。温度设置文档问答场景温度设0.1到0.3。我一般设0.2这个值在准确性和灵活性之间比较平衡。如果发现回答太死板可以调到0.3如果发现回答开始编造就降到0.1。最大输出长度根据回答的预期长度来设。简短回答设300到500详细分析设800到1200。我一般会设一个比预期稍大的值然后在输出层做截断。这样比设得太短导致回答不完整要好。5.3 实操现场记录我拿一份产品需求文档做测试文档大概3000字。用户问题是“这个产品的核心功能有哪些”。输入层处理检索出三段最相关的内容分别是“产品概述”“核心功能”“功能优先级”三个部分。组装后的输入大概是系统指令你是一个文档问答助手请基于提供的文档内容回答问题不要编造文档中没有的信息 文档片段三段共约800字 用户问题 输出要求用列表形式列出核心功能每个功能用一句话说明。模型层调用温度0.2最大输出长度500。模型返回了大概200字的回答列出了四个核心功能每个功能有一句话说明。输出层处理格式清洗去掉了模型输出里的Markdown加粗标记。内容检查发现模型回答完全基于文档内容没有编造。结构优化把四个功能整理成了无序列表每个功能一行。最终用户看到的回答是四个功能点的列表简洁清晰。整个流程从用户提问到展示回答耗时大概2秒其中检索占300毫秒模型调用占1.5秒输出处理占200毫秒。5.4 效果评估与迭代三层架构搭好之后需要持续评估和迭代。我一般从三个维度评估准确性、完整性、可读性。准确性看回答是否基于文档内容有没有编造。我一般会人工抽查一批回答标记出有编造内容的案例分析是输入层检索不准还是模型层“幻觉”。如果是检索不准就调整检索策略如果是模型幻觉就加强输入层的约束指令。完整性看回答是否覆盖了用户问题的所有方面。有时候模型只回答了一部分漏掉了其他部分。这种情况我一般会在输入层加一句“请全面回答不要遗漏”或者在输出层做检查发现遗漏就重新调用模型补充。可读性看回答是否易读。我一般会找几个不了解背景的人看回答问他们“能看懂吗”“哪里看不懂”。根据反馈调整输出层的结构优化策略。迭代的节奏我一般是每周做一次小评估每月做一次大评估。小评估看关键指标有没有下降大评估做全面的人工评审。评估结果记录下来作为下一轮迭代的依据。6. 常见问题与排查技巧6.1 输入层常见问题问题一模型答非所问。这通常是输入层的指令不够明确。排查方法把输入内容打印出来自己读一遍看能不能准确理解要做什么。如果自己都理解不了模型肯定也不行。解决方法是细化指令把任务描述、输出格式、约束条件都写清楚。问题二模型忽略上下文。这通常是上下文太长或者关键信息被淹没。排查方法检查上下文长度是否超出模型窗口检查关键信息是否放在显眼位置。解决方法是精简上下文把最重要的信息放在开头或结尾中间部分用摘要。问题三模型输出格式不稳定。这通常是指令里的格式要求不够具体。排查方法看指令里有没有明确说“用JSON格式”“用表格呈现”。解决方法是加示例给一个输入输出的例子模型照着做的准确率会高很多。6.2 模型层常见问题问题一响应太慢。排查方法先看是首字延迟高还是生成速度慢。首字延迟高通常是输入太长生成速度慢通常是输出太长。解决方法是精简输入、限制输出长度、或者换更快的模型。问题二输出质量不稳定。排查方法检查温度设置是否太高检查输入是否每次一致。解决方法是降低温度、固定输入格式、加更多约束。问题三成本超预期。排查方法统计每次调用的token消耗看是输入消耗多还是输出消耗多。解决方法是精简输入、限制输出、或者换更便宜的模型。6.3 输出层常见问题问题一输出包含多余内容。排查方法看模型输出里有没有重复、无关内容。解决方法是加过滤规则去掉重复句子、过滤无关段落。问题二输出格式不对。排查方法看模型输出是否符合预期格式。解决方法是加强输入层的格式约束或者在输出层做格式转换。问题三输出内容有误。排查方法对照输入内容检查输出是否准确。解决方法是加强输入层的约束指令或者在输出层加校验逻辑发现错误就重新调用。6.4 常见问题速查表问题现象可能原因排查方法解决方向答非所问指令不明确自己读一遍输入细化指令忽略上下文上下文太长检查长度和位置精简上下文格式不稳定格式要求不具体检查指令加示例响应太慢输入或输出太长看延迟分布精简或换模型质量不稳定温度太高检查参数降低温度成本超预期token消耗大统计消耗精简或换模型输出冗余模型啰嗦检查输出加过滤规则输出有误模型幻觉对照输入加强约束避坑技巧排查问题的时候一次只改一个地方。我见过有人同时改指令、改参数、改模型结果问题解决了也不知道是哪个改动起了作用。正确的做法是定位问题、提出假设、改一个变量、验证效果、再改下一个。7. 三层架构的扩展思路三层架构这个框架不只适用于文档问答它可以套用到几乎所有大模型应用上。我简单说几个扩展方向。对话系统输入层管理对话历史模型层维护对话状态输出层处理多轮回复的连贯性。关键点是对话历史的压缩和摘要不能让历史对话无限增长。代码助手输入层处理代码上下文模型层做代码生成或补全输出层做语法检查和格式化。关键点是代码上下文的检索和拼接要把相关的函数和类定义都带上。内容生成输入层做主题和风格约束模型层生成内容输出层做质量检查和风格统一。关键点是输出层的质量评估要能自动判断生成内容是否达标。数据分析输入层把自然语言问题转成查询语句模型层执行查询或生成分析输出层把结果转成图表或报告。关键点是输入层的语义理解和输出层的可视化。每个方向的细节都不一样但三层架构的思考方式是一样的输入层决定模型看到什么模型层决定怎么计算输出层决定用户看到什么。把这三层都想清楚大部分问题都能找到对应的解决思路。我自己在实际项目里的体会是三层架构最大的价值不是让你多了一个分析框架而是让你在遇到问题的时候知道该往哪个方向找原因。效果不好先看输入层是不是没给够信息响应太慢先看模型层是不是选型不对用户不满意先看输出层是不是没处理好。这个排查顺序能帮你省很多时间。