1. 为什么“三层架构”是理解大模型应用的万能钥匙很多人第一次接触大模型应用开发时会被各种新名词砸晕RAG、Agent、Function Calling、思维链、多模态、工作流编排……每隔几周就冒出一个新概念感觉永远追不完。但如果你把这些花样全部拆开看会发现一个让人安心的事实几乎所有大模型应用本质上都在做三件事——决定输入什么、决定模型怎么处理、决定输出怎么用。这就是我所说的“三层架构”。这个框架不是什么官方标准而是我在实际做项目时总结出来的一套思维模型。它的价值在于当你面对一个从没见过的新框架或新产品时可以迅速把它归类到这三层中的某一层或某几层然后判断它到底解决了什么问题、值不值得投入时间学。三层分别是什么第一层是输入层解决的是“给模型看什么”的问题包括提示词设计、上下文组装、检索增强、多模态输入等。第二层是处理层解决的是“模型怎么想”的问题包括推理策略、工具调用、多步规划、自我反思等。第三层是输出层解决的是“拿到结果之后怎么办”的问题包括格式解析、结果校验、后处理管线、与外部系统的对接等。为什么说这个框架好用因为大模型本身是一个黑盒你能控制的只有它的输入和输出。处理层虽然涉及模型内部的推理过程但你能施加的影响也主要是通过输入来间接引导。所以从工程角度看真正可操作的空间集中在输入层和输出层处理层更多是选择用什么模型、用什么推理策略的问题。我见过不少团队在做一个大模型应用时把80%的精力花在“换更好的模型”上却忽略了输入组装和输出处理才是真正决定产品质量的地方。同一个模型输入层做得好不好输出质量可以差出好几倍。同样输出层有没有做校验和兜底直接决定了产品能不能上线。接下来的内容我会逐层拆解每一层到底包含哪些具体技术点、常见的坑在哪里、实际项目中应该怎么选。每一层我都会给出可操作的方案和参数建议而不是泛泛而谈。2. 输入层决定模型上限的关键战场2.1 提示词工程只是输入层最表面的一层一说到输入层大多数人第一反应就是“写提示词”。确实提示词是输入层最直观的部分但它远不是全部。提示词工程解决的是“怎么把任务说清楚”的问题而输入层要解决的是“怎么把正确的信息以正确的形式送到模型面前”。举个例子你要做一个客服问答系统。提示词可以写成“你是一个客服助手请根据以下知识回答用户问题”。但真正决定回答质量的是你有没有把相关的知识片段检索出来、有没有把历史对话整理成合适的格式、有没有把用户当前问题和上下文正确拼接。这些都属于输入层的范畴。提示词工程的核心技巧其实就那么几条角色设定、任务描述、输出格式约束、少样本示例。这些技巧在大多数场景下都够用了。真正难的是上下文组装——在有限的上下文窗口里放哪些信息、按什么顺序放、怎么压缩。我做过一个对比测试同一个模型、同一个问题一组直接把所有相关文档塞进去另一组做了精心的上下文筛选和排序。结果后者的回答准确率高出近40%。这说明输入层的优化空间远比换模型大。2.2 上下文组装的三个核心决策上下文组装是输入层最核心的工作。每次调用模型之前你都需要决定三件事放什么、放多少、怎么排。放什么取决于你的任务类型。如果是问答任务你需要放相关的知识片段和对话历史。如果是代码生成任务你需要放相关的代码文件、接口定义和错误信息。如果是数据分析任务你需要放数据摘要和字段说明。关键原则是只放和当前任务直接相关的信息无关信息不仅浪费上下文窗口还会干扰模型的注意力。放多少是一个需要实测的问题。上下文窗口虽然越来越大但不是塞得越多越好。我实测下来的经验是对于问答类任务有效信息占比低于30%时模型的表现会明显下降。也就是说如果你塞了10000个token的上下文其中真正有用的不到3000个token那不如精简到3000个token再送进去。怎么排经常被忽略但影响很大。一个实用的原则是最重要的信息放在最前面和最后面。模型对上下文开头和结尾的关注度高于中间部分这是注意力机制的特性决定的。所以如果你有一段最关键的知识不要放在中间要么放最前面要么放最后面。下面是一个上下文组装的示例结构我在多个项目中都用过这个模板def build_context(system_prompt, knowledge_chunks, chat_history, user_query): # 第一段系统提示词定义角色和任务 context f[系统指令]\n{system_prompt}\n\n # 第二段知识片段按相关度排序最相关的放最前 context [参考资料]\n for i, chunk in enumerate(knowledge_chunks[:5]): context f资料{i1}{chunk}\n context \n # 第三段对话历史只保留最近几轮 context [对话历史]\n for turn in chat_history[-3:]: context f用户{turn[user]}\n助手{turn[assistant]}\n context \n # 第四段当前问题放在最后 context f[当前问题]\n{user_query} return context这个结构看起来简单但每一段的顺序和截断策略都是经过实测调整的。比如知识片段限制在5条以内对话历史只保留最近3轮这些都是为了避免上下文过长导致模型注意力分散。2.3 检索增强输入层最值得投入的方向检索增强生成RAG是输入层最重要的技术之一。它的核心思路是在模型回答之前先从外部知识库中检索出相关信息作为上下文的一部分送给模型。这样模型就能基于最新、最准确的信息来回答而不是只依赖训练时记住的内容。RAG的流程可以拆成四个步骤文档切分、向量化、检索、重排序。每一步都有讲究。文档切分不是简单地按固定长度切。我试过按500字切、按段落切、按语义切效果差异很大。对于技术文档按段落切通常最好因为每个段落本身就是一个完整的语义单元。对于对话记录按轮次切更合适。切分粒度太细会导致检索到的片段缺乏上下文太粗则会引入无关信息。我的经验值是每个片段控制在200到500字之间并且保留一定的重叠区域比如前后各重叠50字避免关键信息被切断。向量化就是选择合适的嵌入模型把文本转成向量。这里有一个常见的误区很多人直接用通用的嵌入模型不做任何微调。对于垂直领域通用模型的效果可能不够好。如果条件允许用领域数据对嵌入模型做微调检索准确率能提升不少。如果没有微调条件至少要在检索时加入关键词匹配作为补充纯向量检索在专有名词上容易翻车。检索阶段的核心参数是返回结果数量。返回太少可能漏掉关键信息返回太多会引入噪声。我的经验是先返回10到20个候选然后用重排序模型筛选出最相关的3到5个。这个两阶段策略比直接返回固定数量效果好很多。重排序是很多人忽略的一步。向量检索是基于语义相似度的但语义相似不等于真正相关。重排序模型可以更精细地判断查询和文档之间的相关性。我用过的方案里交叉编码器Cross-Encoder做重排序的效果明显好于纯向量相似度。2.4 多模态输入的处理要点当输入不只是文本时输入层的复杂度会上升一个量级。图片、音频、视频、表格、PDF每种格式都有自己的处理方式。图片输入的关键是分辨率和对齐。模型对图片的理解能力受分辨率影响很大太小的图片看不清细节太大的图片会被压缩导致信息丢失。我的经验是对于文档截图类图片分辨率保持在1024x1024左右比较合适对于自然场景图片可以适当降低到512x512。PDF处理是另一个大坑。很多PDF是扫描件需要先做OCR。但OCR出来的文本往往格式混乱段落边界不清。我的做法是先用版面分析工具识别出标题、正文、表格、图片区域然后分别处理。表格单独提取成结构化数据图片单独做描述生成正文按段落整理。这样比直接OCR整页效果好得多。音频输入需要先做语音转文字然后按文本处理。但要注意语音转文字的结果往往没有标点需要做后处理加上标点否则模型理解起来会很吃力。3. 处理层模型选择与推理策略的取舍3.1 不是所有任务都需要最强的模型处理层最核心的决策是用什么模型。很多人下意识觉得“用最强的就对了”但实际项目中模型选择是一个需要权衡成本、延迟和效果的工程问题。我把常见任务按复杂度分成三档。第一档是简单任务比如文本分类、信息抽取、格式转换。这类任务用小模型就够了速度快、成本低效果和大模型差距不大。第二档是中等任务比如问答、摘要、翻译。这类任务需要一定的理解能力中等规模的模型通常够用。第三档是复杂任务比如多步推理、代码生成、创意写作。这类任务才真正需要大模型。我做过一个实测在信息抽取任务上小模型和大模型的效果差距不到5%但成本差了将近20倍。所以先从小模型试起效果不够再往上换这是最务实的策略。另一个重要决策是用通用模型还是领域模型。通用模型在大多数场景下表现不错但在垂直领域比如医疗、法律、金融可能不够专业。如果有条件用领域数据做微调效果提升很明显。但微调需要标注数据和算力不是所有团队都有条件。折中方案是用通用模型加领域知识库做检索增强效果也能接受。3.2 工具调用让模型突破自身限制工具调用Function Calling是处理层最重要的能力之一。它的本质是模型不直接回答问题而是输出一个“调用某个工具的请求”由外部系统执行后再把结果返回给模型。这个机制解决了一个根本问题模型的知识是静态的但很多任务需要动态信息。比如查天气、查库存、算数学题这些都需要实时数据或精确计算。工具调用让模型可以“借用”外部能力。工具调用的设计有几个关键点。工具描述要清晰模型需要知道每个工具是干什么的、需要什么参数。描述模糊会导致模型调用错误的工具或传错参数。参数校验要严格模型输出的参数不一定符合预期需要在执行前做校验和修正。错误处理要完善工具调用可能失败需要有重试和降级机制。我踩过的一个坑是工具数量太多导致模型选择困难。当可用工具超过10个时模型选错工具的概率明显上升。解决方案是对工具做分组先让模型选择工具类别再在类别内选择具体工具。这个两阶段策略把工具选择准确率从70%提升到了90%以上。3.3 多步推理把复杂任务拆成可执行的步骤对于复杂任务让模型一步到位给出答案往往效果不好。更好的做法是把任务拆成多个步骤每一步的输出作为下一步的输入。这就是多步推理的核心思路。常见的多步推理模式有几种。链式推理是把任务拆成线性步骤一步步执行。树式推理是在每一步生成多个候选然后选择最优路径。反思式推理是让模型先给出答案然后自我检查并修正。我在实际项目中最常用的是链式推理加反思。具体做法是先让模型生成一个初步方案然后让模型自己检查这个方案有没有问题最后根据检查结果生成最终方案。这个“生成-检查-修正”的循环对于代码生成和方案设计类任务效果提升很明显。但多步推理也有代价延迟增加、成本上升。每一步都需要调用一次模型三步就是三倍的成本。所以只在必要时使用多步推理简单任务一步到位就好。3.4 推理策略的选择框架面对一个具体任务怎么决定用什么推理策略我总结了一个简单的判断框架任务特征推荐策略理由单步可完成输入输出明确直接推理不需要额外开销需要外部信息或计算工具调用模型自身能力不足需要多步逻辑推导链式推理分步降低单步难度答案不唯一需要探索树式推理多路径增加覆盖对准确性要求极高反思式推理自我检查减少错误任务复杂且步骤多组合策略按需组合上述方法这个框架不是绝对的但可以作为一个起点。实际选择时还要考虑延迟要求和成本预算。如果延迟敏感就尽量用简单策略如果成本敏感就控制推理步数。4. 输出层从模型输出到可用产品的最后一公里4.1 结构化输出让模型结果可编程模型输出的原始文本是给人看的但产品需要的是结构化数据。输出层的第一项工作就是把模型的自由文本转成程序能处理的格式。最直接的方式是让模型直接输出JSON。但这里有一个坑模型输出的JSON不一定是合法的。可能缺少引号、可能有多余的逗号、可能嵌套层级不对。所以永远不要直接解析模型输出的JSON一定要做校验和修复。我的做法是分三步。第一步用提示词约束输出格式明确告诉模型“只输出JSON不要有其他内容”。第二步用JSON解析器尝试解析如果失败就用正则表达式提取JSON部分再解析。第三步用schema校验工具检查字段是否完整、类型是否正确。如果校验失败把错误信息返回给模型让它重新生成。对于更复杂的结构化输出比如表格、树形结构可以考虑用模型输出Markdown表格或缩进文本然后自己写解析器转换。这种方式比直接输出JSON更稳定因为模型对Markdown格式的遵循度通常更高。4.2 结果校验不是所有输出都能直接用模型会产生幻觉这是众所周知的问题。输出层的校验就是要在结果送到用户之前把明显错误的内容拦截下来。校验分几个层次。格式校验是最基本的检查输出是否符合预期的格式。范围校验检查数值是否在合理范围内比如价格不能是负数、日期不能是过去的时间。一致性校验检查输出内部是否自相矛盾比如前面说“有库存”后面说“已售罄”。事实校验是最难的一层需要和外部知识库对比确认模型陈述的事实是否正确。实际项目中格式校验和范围校验是必须做的成本低、效果好。一致性校验可以用另一个模型来做让模型检查自己的输出是否自洽。事实校验成本最高通常只在关键场景下做。我踩过的一个坑是过度依赖模型自我校验。让模型检查自己的输出它往往会说“没问题”即使实际上有问题。后来我改成用另一个独立的模型来做校验效果好了很多。校验模型和生成模型最好是不同的避免相同的偏见。4.3 后处理管线把原始输出变成最终产品模型输出经过校验之后还需要经过一系列后处理才能变成最终产品。后处理的内容取决于具体应用场景。对于文本生成类应用后处理可能包括去除重复内容、调整语气风格、添加格式化标记、拼接模板文本。对于代码生成类应用后处理包括语法检查、格式化、添加注释、生成测试用例。对于数据分析类应用后处理包括单位换算、精度调整、图表生成。后处理管线的设计原则是每一步只做一件事步骤之间解耦。这样当某一步出问题时容易定位和修复。比如格式化和语法检查分开做不要混在一个步骤里。另一个原则是后处理要可配置。不同场景可能需要不同的后处理步骤把每一步做成可插拔的模块根据配置决定启用哪些步骤。这样一套管线可以服务多个场景不用为每个场景单独写代码。4.4 流式输出与用户体验的平衡流式输出是提升用户体验的重要手段。模型生成一个token就返回一个token用户不用等全部生成完就能看到内容。但流式输出给输出层带来了新的挑战。第一个挑战是校验时机。非流式输出可以在全部生成完之后做校验但流式输出需要在生成过程中做校验。我的做法是先做流式输出保证体验同时在后台做完整校验如果校验发现问题再撤回或修正。这需要前端支持内容替换。第二个挑战是结构化输出的流式化。JSON格式在流式输出时很难处理因为JSON的合法性需要完整解析才能确认。解决方案是流式输出时用简单的分隔符格式比如每行一个字段等全部生成完后再转成JSON。第三个挑战是中断处理。用户可能在生成过程中取消请求这时需要正确清理资源、保存已生成的内容。我见过不少项目在中断处理上出问题导致资源泄漏或状态不一致。5. 三层架构在实际项目中的组合应用5.1 一个完整案例的逐层拆解拿一个智能文档问答系统来举例。用户上传一份合同然后问“这份合同的违约金比例是多少”。输入层要做的事情把合同PDF解析成文本按条款切分对每个条款做向量化存入向量库。用户提问时把问题向量化检索出最相关的条款片段组装成上下文。上下文里包括系统提示词、检索到的条款、用户问题。处理层要做的事情选择模型。这个任务需要理解法律文本中等规模的模型通常够用。如果合同里有复杂的计算比如违约金按天数累计可能需要工具调用来做计算。推理策略上单步推理通常够用但如果问题涉及多个条款的交叉引用可能需要链式推理。输出层要做的事情模型输出的是自然语言答案需要提取出具体的数字和单位。校验这个数字是否在合同文本中出现过避免模型编造。后处理把答案格式化成“根据第X条违约金比例为Y%”的形式。如果用户需要还可以生成引用来源。这个案例里三层各司其职。输入层决定了模型能看到什么处理层决定了模型怎么思考输出层决定了最终呈现什么。任何一层出问题都会影响最终效果。5.2 不同场景下三层的权重差异三层的重要性在不同场景下是不一样的。我根据经验总结了一个权重参考场景类型输入层权重处理层权重输出层权重知识问答高中中代码生成中高高内容创作高中低数据分析中高高客服对话高中中文档处理高低高知识问答类场景输入层的检索质量直接决定回答质量所以权重最高。代码生成类场景处理层的推理策略和输出层的语法校验都很关键。内容创作类场景输入层的提示词和上下文决定创作方向输出层反而不用太复杂。这个权重表可以帮助你在资源有限时决定优先优化哪一层。比如做知识问答先把检索做好比换模型效果更明显。5.3 常见误区只关注处理层我见过太多团队把大部分精力花在处理层上不断尝试新模型、新推理框架却忽略了输入和输出。结果就是模型换了一个又一个效果提升不明显因为瓶颈根本不在模型上。一个典型的误区是认为“模型越强效果越好”。实际上当输入层的检索质量很差时再强的模型也回答不好。因为模型只能基于你给它的信息来回答你给的信息不对它只能编造。另一个误区是忽略输出层的工程化。模型输出直接返回给用户不做校验、不做后处理。结果就是用户经常看到格式错误、事实错误、不完整的回答。这些问题不是换模型能解决的必须在输出层做工程处理。我的建议是先把输入层和输出层做扎实再考虑优化处理层。输入层做好检索和上下文组装输出层做好校验和后处理这两层的投入产出比远高于换模型。6. 从三层架构看技术选型与迭代节奏6.1 新框架出现时怎么快速判断价值每当一个新框架或新产品出现时我会用三层架构来快速判断它值不值得学。具体方法是问三个问题它主要解决哪一层的问题这一层我现在的痛点是什么它能带来多大提升比如一个检索框架它解决的是输入层的检索问题。如果我现在的检索准确率很低那它就值得关注。如果我现在的检索已经够用了那它可能只是锦上添花。再比如一个推理框架它解决的是处理层的推理策略问题。如果我的任务很简单不需要多步推理那它对我的价值就有限。这个方法可以帮你过滤掉大量“看起来很美但用不上”的新技术把时间花在真正能解决你问题的东西上。6.2 迭代优先级先做哪一层项目刚开始时三层的迭代顺序建议是先做输入层再做输出层最后优化处理层。输入层是基础。输入层没做好后面两层再优化也是白搭。先把提示词写好、把上下文组装逻辑跑通、把检索做起来。这一步不需要太多资源但效果立竿见影。输出层是保障。输入层跑通后模型能给出回答了但回答可能格式不对、可能有错误。这时候加上输出校验和后处理让结果变得可用。这一步也不需要太多资源但能显著提升产品质量。处理层是优化。当前两层都做扎实了再考虑换更好的模型、加更复杂的推理策略。这时候你会发现处理层的优化效果更容易体现出来因为瓶颈已经不在输入和输出上了。6.3 团队分工与三层架构的对应关系如果是一个团队在做大模型应用三层架构也可以对应到不同的角色分工。输入层的工作适合数据工程师和搜索工程师来做。文档处理、向量化、检索优化这些是他们的强项。输出层的工作适合后端工程师来做。格式校验、后处理管线、API设计这些是后端工程的常规工作。处理层的工作适合算法工程师来做。模型选型、推理策略、效果调优这些需要算法背景。当然小团队可能一个人全包。但即使是一个人也可以按这三层来组织工作每次专注一层避免同时处理太多变量。6.4 三层架构的边界与局限三层架构是一个思维工具不是万能公式。它也有局限。首先三层之间的边界不是绝对的。比如工具调用它既涉及处理层的推理策略也涉及输出层的格式解析。实际项目中三层是相互影响的不能完全割裂。其次这个框架主要适用于应用层开发不适用于模型训练。如果你在做预训练或微调关注点会完全不同。最后三层架构是一个静态框架但大模型技术在快速演进。今天属于处理层的能力明天可能被整合到模型内部。所以这个框架需要定期更新不能一成不变。我在实际使用中的体会是三层架构最大的价值不是分类而是帮你建立一种“可控性思维”。大模型很复杂但你能控制的只有输入和输出。把可控的部分做到极致不可控的部分自然会有更好的表现。这个思路在我做过的多个项目里都得到了验证。
