大模型火了之后各种新概念、新玩法层出不穷今天一个“智能体”明天一个“思维链”后天又冒出个“多模态融合”。很多人追着这些名词跑越追越焦虑感觉永远学不完。但如果你把市面上主流的大模型应用掰开揉碎看一遍会发现一个让人踏实的事实所有 AI 新花样本质上只在两个地方做文章——输入什么以及输出怎么处理。中间那个负责“思考”的模型本体反而是最稳定的那一层。这个判断不是拍脑袋来的。我过去两年折腾过不少大模型落地项目从最简单的文档问答到稍微复杂点的自动化流程踩了一圈坑之后回头看真正决定一个应用好不好用的往往不是换了多强的模型而是输入侧喂了什么、输出侧怎么接。这篇文章就把这个三层架构彻底拆开讲清楚不管你是刚入门想搞明白大模型应用到底怎么回事还是已经做过一些项目但总觉得哪里没打通都能从中找到可以直接抄作业的思路和避坑经验。1. 三层架构到底怎么分先建立全局视角1.1 为什么是三层而不是两层或四层把大模型应用拆成三层是我试过多种分法之后觉得最顺手的一种。三层分别是输入层、模型层、输出层。输入层负责把用户的原始需求翻译成模型能理解的格式模型层负责推理生成输出层负责把模型吐出来的东西变成用户能直接用的结果。为什么不是两层因为很多人会把输入和输出混在一起叫“应用层”但实际操作中你会发现输入侧的问题和输出侧的问题完全是两码事。输入侧出问题表现为模型答非所问、理解偏差输出侧出问题表现为格式不对、没法对接下游系统。混在一起排查效率极低。为什么不是四层有人会把“数据层”单独拎出来但在大多数应用场景里数据要么是输入的一部分比如检索增强要么是输出的一部分比如写入数据库单独拆一层反而增加了理解成本。三层足够覆盖绝大多数情况而且边界清晰。提示这个分层不是学术定义而是实操视角的划分。目的是让你在遇到问题时能快速定位到底是哪一层出了毛病。1.2 模型层为什么反而最“无聊”模型层就是那个真正跑推理的大模型本身。你可能会觉得这是最核心的一层但实际上在应用开发中它是最不需要频繁改动的一层。原因很简单模型的能力边界在训练完成那一刻就基本确定了你能做的只是通过输入输出来适配它而不是改变它。我见过不少团队花大量时间纠结“用哪个模型”今天试试这个明天换换那个结果项目进度卡在选型上。但实际跑下来同一个任务不同主流模型的表现差异远没有想象中那么大真正拉开差距的是输入侧有没有把需求说清楚、输出侧有没有做好后处理。模型层还有一个特点它的迭代是平台方的事不是应用方的事。你今天用的模型版本下个月可能就升级了但你的输入输出逻辑不需要跟着大改。这就是为什么我说模型层最“无聊”——它稳定、被动是整个架构里的常量而不是变量。1.3 输入层和输出层才是真正的战场所有让人眼前一亮的 AI 应用创新点几乎都集中在输入层和输出层。输入层的创新包括更好的提示词设计、更精准的上下文检索、更合理的多轮对话管理、更丰富的多模态输入处理。输出层的创新包括结构化输出解析、多轮结果聚合、格式转换、与外部工具的联动。举个例子同样一个模型你直接问“帮我写个方案”和先给它喂三篇参考文档再问“按照这三篇文档的风格写个方案”输出质量天差地别。这个差异不来自模型来自输入层。再比如模型输出了一段 JSON你直接扔给用户看和解析后渲染成表格再展示体验完全不同。这个差异来自输出层。所以如果你想把 AI 应用做好精力应该花在输入输出这两层上而不是天天盯着模型排行榜。2. 输入层拆解决定模型“吃”到什么2.1 提示词工程只是输入层的一部分很多人一提到输入层就想到提示词工程觉得把提示词写好就万事大吉了。但提示词只是输入层的一个子集。完整的输入层至少包括四个部分系统指令、上下文信息、用户输入、历史对话。系统指令是给模型定角色的比如“你是一个专业的法律顾问”。上下文信息是你额外喂给模型的参考资料比如检索到的文档片段。用户输入是当前这一轮的问题。历史对话是之前几轮的交互记录。这四部分怎么组合、怎么排序、怎么控制长度都是输入层要解决的问题。我踩过的一个坑是早期做文档问答时把检索到的文档片段直接拼在用户问题前面结果模型经常把文档里的内容当成用户说的话来回应。后来改成用明确的分隔符把文档和问题隔开并加上“以下文档仅供参考请回答用户问题”的指令问题就解决了。这就是输入层设计不到位导致的。2.2 上下文检索输入层最值钱的能力如果说输入层有什么能力最值得投入那一定是上下文检索。大模型本身的知识是固定的但通过检索把外部知识注入到输入里就能让模型回答它原本不知道的事情。这就是检索增强生成的核心思路。检索增强生成听起来复杂拆开看就三步把用户问题转成向量在向量库里找最相似的文档片段把找到的片段塞进输入里。难点不在模型而在检索质量。检索不准喂进去的上下文就是噪音模型反而会被带偏。我在实际项目里总结了几条检索优化的经验。第一文档切分粒度很重要切得太碎会丢失上下文切得太大会引入无关信息一般按语义段落切分效果比较好。第二向量模型的选择比大模型的选择更影响检索效果因为检索不准后面全白搭。第三检索数量不是越多越好一般三到五条最相关的结果就够了多了反而干扰模型判断。注意检索增强生成不是万能药。如果外部知识本身质量差、结构乱检索出来的东西也是垃圾。输入层的质量上限取决于你的数据质量。2.3 多轮对话管理别让历史拖垮输入多轮对话是输入层里最容易被忽视的部分。很多人做对话系统时把全部历史对话都塞进输入里结果 token 消耗飞快模型还容易被早期无关内容干扰。正确的做法是有选择地保留历史。我的做法是只保留最近三到五轮对话并且对历史对话做摘要压缩。比如用户前面聊了十分钟的需求背景不需要把原话全带上用一两句话概括就行。这样既保留了上下文连贯性又控制了输入长度。还有一个技巧是“对话状态追踪”。把多轮对话中提取到的关键信息比如用户提到的日期、地点、偏好单独存成一个结构化状态每轮输入时把这个状态带上而不是带原始对话。这样输入更干净模型也更容易抓住重点。2.4 多模态输入图片、音频怎么喂给模型多模态输入是近两年的热点但实操中要注意不是所有模型都支持多模态支持的模型对输入格式也有要求。图片一般需要转成 base64 编码或者提供 URL音频需要先转成文字再输入视频更复杂通常要抽帧成图片序列。我做过一个图片理解的小项目经验是图片分辨率不是越高越好太高的分辨率会消耗大量 token而且模型对图片的理解能力有限关键信息清晰可见就够了。另外图片和文字的排列顺序会影响模型理解一般把图片放在相关文字旁边效果最好。音频输入目前最稳妥的方案还是先做语音转文字再把文字输入模型。直接端到端的语音理解模型虽然有但稳定性和可控性还不如转文字方案。视频输入同理抽关键帧加字幕转文字比直接喂视频靠谱得多。3. 输出层拆解决定用户“拿”到什么3.1 结构化输出让模型吐出来的东西能用模型默认输出的是自然语言文本但很多应用场景需要的是结构化数据。比如你要把模型输出存进数据库就需要 JSON要展示成表格就需要二维数组要触发下游动作就需要特定的指令格式。这些都需要在输出层做处理。让模型输出结构化数据有两种思路。一种是在提示词里明确要求模型按 JSON 格式输出另一种是让模型自由输出然后用解析器提取结构化信息。第一种思路更直接但模型有时会不听话输出带 markdown 代码块的 JSON 或者格式错误的 JSON。第二种思路更灵活但解析器要写得足够健壮。我的经验是两者结合提示词里要求 JSON 输出同时输出层加一个容错解析器能处理常见的格式偏差比如去掉代码块标记、补全缺失的括号、修正常见的键名拼写错误。这样既保证了结构化又不会因为模型偶尔不听话就整个流程崩掉。3.2 格式转换与渲染从文本到用户界面模型输出的文本要变成用户能看的东西中间需要一层格式转换。最简单的场景是纯文本展示复杂一点的场景包括把 markdown 转成 HTML 渲染、把 JSON 转成表格、把列表转成卡片、把代码块加上语法高亮。这一步看起来是前端的事但实际上输出层就要考虑好。比如模型输出的 markdown 里可能有表格你的渲染器要能正确处理可能有代码块要能识别语言类型可能有数学公式要能渲染成公式而不是纯文本。这些如果输出层不做处理前端就要做但前端做的话不同端网页、App、小程序就要各做一遍不如在输出层统一处理。我一般会在输出层做一个“标准化”步骤把模型输出的各种格式统一转成一种中间格式比如 HTML 片段或者结构化 JSON然后各端再基于中间格式做渲染。这样逻辑集中维护成本低。3.3 结果校验与兜底别让模型胡说八道直接出去模型会胡说八道这是常识。输出层的一个重要职责就是校验和兜底。校验包括事实性校验输出内容是否和已知事实矛盾、格式校验输出是否符合预期格式、安全校验输出是否包含不当内容。兜底就是当校验不通过时给用户一个合理的降级回复而不是直接把错误内容展示出去。事实性校验最难做因为你需要一个可信的知识源来比对。我的做法是对于关键事实在输入层就把可信信息喂给模型输出层再检查模型输出是否引用了这些信息。如果模型输出和输入信息矛盾就触发重新生成或者降级回复。格式校验相对简单就是检查输出是否符合预期的结构。安全校验可以用关键词过滤加模型自检的方式。兜底策略要根据场景设计比如客服场景可以回复“这个问题我暂时无法回答建议您联系人工客服”而不是硬答。3.4 输出与外部系统的联动输出层不只是给用户看的很多时候还要触发外部动作。比如模型判断用户意图是“查天气”输出层就要调用天气接口判断意图是“下单”输出层就要调用订单系统。这就是所谓的“工具调用”或“函数调用”。工具调用的关键是意图识别和参数提取。模型输出一段文本输出层要从中解析出用户想调用哪个工具、参数是什么。我的做法是让模型直接输出结构化的调用指令比如{tool: weather, params: {city: 北京}}然后输出层解析这个指令并执行。这样比让模型输出自然语言再解析要可靠得多。提示工具调用的参数校验一定要做。模型可能提取出错误的参数比如把城市名提取成省份名输出层要能识别并纠正或者返回错误让模型重新提取。4. 实操从零搭一个三层架构的问答应用4.1 场景定义与技术选型假设我们要做一个“内部文档问答助手”用户可以用自然语言提问系统从内部文档库里找答案并回复。这个场景足够典型覆盖了输入层的检索、模型层的推理、输出层的格式化。技术选型上模型层选一个主流的中等规模模型就够了不需要追求最大最强的因为我们的重点在输入输出。输入层的向量检索用一个轻量级的向量模型加一个向量数据库。输出层用一个简单的 Web 框架做接口前端用最基础的 HTML 加 JavaScript。这个选型的逻辑是把复杂度和成本控制在输入输出层模型层保持简单稳定。这样整个系统更容易调试也更容易替换组件。4.2 输入层实现文档切分与检索文档切分我按语义段落来每段控制在 300 到 500 字。太短了上下文不够太长了噪音太多。切分的时候保留段落标题这样检索到片段后还能知道它属于哪个章节。向量化用的是一个开源的中文向量模型把每个段落转成向量存进向量数据库。检索时把用户问题也转成向量算余弦相似度取 top 3 的段落。这里有个细节用户问题往往很短直接拿短问题去检索长文档相似度计算容易不准。我的做法是先让模型把用户问题扩展成几个相关查询分别检索后合并结果。比如用户问“报销流程”模型扩展成“报销需要什么材料”“报销审批要多久”“报销在哪里提交”这样检索覆盖面更广。4.3 模型层调用提示词模板设计提示词模板我分成三部分系统指令、上下文、用户问题。系统指令写清楚角色和输出要求上下文放检索到的文档片段用户问题放原始提问。模板大概长这样你是一个内部文档问答助手。请根据以下文档片段回答用户问题。 如果文档中没有相关信息请直接说“文档中没有找到相关信息”不要编造。 文档片段 {context} 用户问题{question} 请用简洁的中文回答并在回答末尾标注引用的文档片段编号。这个模板的关键点是明确要求不编造、要求标注引用。标注引用是为了输出层能做校验如果模型说了一个文档里没有的信息输出层可以检查引用编号对应的片段里有没有这个信息。4.4 输出层实现解析、校验与展示模型输出后输出层先做解析提取回答正文和引用编号。然后做校验检查引用编号是否有效检查回答内容是否能在引用片段中找到依据。校验通过就展示不通过就降级回复“抱歉我暂时无法确认这个问题的答案”。展示时把引用片段也一并展示出来让用户能看到答案的来源。这样既增加了可信度也方便用户自己判断。如果用户点击引用片段还能展开看完整段落。整个流程跑下来你会发现真正花时间的是输入层的文档处理和输出层的校验逻辑模型调用本身只是几行代码的事。这再次印证了那个判断新花样都在输入输出模型层只是执行者。5. 常见问题与排查技巧实录5.1 模型答非所问怎么排查答非所问是最常见的问题排查思路是从输入层往模型层查。先看输入里有没有把用户问题说清楚再看上下文有没有干扰信息最后才怀疑模型能力。我遇到过一次典型情况用户问“年假怎么算”模型回答了一堆考勤制度。查下来发现检索到的文档片段里有一大段考勤制度和年假无关但向量相似度很高被检索出来了。解决办法是在检索后加一个重排序步骤用更精细的模型对候选片段做二次排序把真正相关的排前面。5.2 输出格式不稳定的处理模型输出 JSON 时经常带 markdown 代码块标记或者键名大小写不一致或者少个括号。这些都要在输出层做容错处理。我的容错解析器大概做这几件事去掉首尾的代码块标记、尝试用 JSON 解析、解析失败就用正则提取键值对、键名统一转小写、缺失的括号自动补全。这套组合拳下来百分之九十五的格式问题都能自动修复。5.3 检索不准的优化路径检索不准的表现是明明文档里有答案但检索不到或者检索到的片段和问题无关。优化路径按优先级排先优化文档切分粒度再优化向量模型再优化检索策略最后才考虑换向量数据库。文档切分是最容易被忽视但影响最大的。我见过一个项目文档按固定字数切分结果一个完整的流程被切成三段检索到其中一段根本看不懂。改成按标题和段落切分后检索准确率直接上了一个台阶。5.4 多轮对话中上下文丢失的解决多轮对话中用户经常用代词指代前文内容比如“它”“那个”“上面说的”。如果历史对话没带全模型就不知道指代什么。解决办法是在输入层做指代消解把用户当前问题中的代词替换成具体指代的内容。比如用户上一轮问“报销流程”这一轮问“它需要多久”输入层把“它”替换成“报销流程”变成“报销流程需要多久”。这样即使历史对话带得少模型也能理解。指代消解可以用规则做也可以用模型做。规则做简单场景够用复杂场景还是得靠模型。但模型做会增加一次调用成本和延迟都会上升需要权衡。5.5 常见问题速查表问题表现可能原因排查方向解决思路答非所问输入上下文有干扰检查检索结果相关性加检索重排序格式错误模型不听话检查提示词格式要求加输出容错解析检索不到文档切分不合理检查切分粒度和方式按语义段落切分指代不明历史对话缺失检查多轮对话管理加指代消解编造信息模型幻觉检查输入是否有依据加输出事实校验响应太慢输入太长检查 token 数量压缩历史对话和上下文这张表是我在实际项目中反复用到的一个速查工具遇到问题先对号入座能省不少排查时间。6. 三层架构的扩展思路6.1 输入层的扩展从文本到多模态输入层往多模态扩展是趋势。图片输入可以做图文问答音频输入可以做语音助手视频输入可以做内容摘要。但扩展时要注意多模态输入的 token 消耗远大于纯文本成本控制是关键。我的建议是多模态输入先做预处理图片压缩到合适分辨率音频转文字视频抽关键帧。预处理后的输入再喂给模型既控制了成本也提高了理解准确率。6.2 输出层的扩展从展示到行动输出层往行动扩展就是工具调用和自动化流程。模型输出不只是给人看还能触发一系列动作。比如模型判断用户要订机票输出层就调用订票接口、填表单、发确认邮件。扩展的关键是定义好工具接口和参数规范。每个工具要有清晰的描述和参数 schema模型才能正确调用。输出层要做好参数校验和错误处理工具调用失败要有降级方案。6.3 模型层的扩展多模型路由虽然我说模型层最稳定但也不是完全不能动。多模型路由就是一个扩展方向简单问题用小模型复杂问题用大模型特定任务用专用模型。这样能在成本和效果之间取得平衡。路由逻辑可以放在输入层根据问题类型选择模型也可以放在输出层根据模型输出质量决定是否换模型重试。我一般放在输入层因为这样延迟更低用户体验更好。7. 我踩过的几个印象深刻的坑第一个坑是过度依赖模型能力。早期做项目时总觉得换个更强的模型就能解决问题结果换了一圈发现问题出在输入层的检索不准。后来把精力放在检索优化上效果立竿见影。这个教训让我明白模型是常量输入输出是变量。第二个坑是忽视输出校验。有一次做自动回复模型输出了一段看起来很像那么回事但实际上是编造的内容直接发出去了造成了不好的影响。从那以后我在输出层加了强制校验关键信息必须能在输入中找到依据才允许输出。第三个坑是上下文塞太多。为了“让模型知道更多”把大量历史对话和文档片段都塞进输入结果模型反而抓不住重点响应也慢。后来学会了做减法只保留最相关的信息效果反而更好。第四个坑是格式处理想当然。以为模型会乖乖按 JSON 输出结果各种格式偏差。后来写了容错解析器才把这个问题解决。这件事让我意识到输出层的健壮性和输入层的准确性同样重要。8. 给不同阶段从业者的建议如果你刚开始接触大模型应用建议先从输入层入手把提示词写好把检索做准。这两件事做好了效果提升最明显也最容易看到成果。如果你已经做过一些项目建议重点优化输出层。输出层的校验、格式化、工具调用是区分“玩具”和“产品”的关键。很多项目输入层做得不错但输出层粗糙导致用户体验差。如果你在带团队做项目建议把输入层和输出层分开专人负责。输入层的人关注数据质量和检索效果输出层的人关注格式稳定性和系统对接。模型层不需要专人盯定期评估一下就行。最后分享一个我常用的判断方法当你拿到一个新 AI 应用时先看它的输入设计再看它的输出处理基本就能判断它的技术含量和实用价值。那些只会在提示词里堆花活的往往输出层很粗糙那些输出层做得很精细的输入层通常也不会差。这个判断方法帮我省了很多研究新工具的时间。
