市面上关于大模型的讨论十篇里有八篇在讲参数规模、榜单排名、谁又刷新了哪个评测。但真正落到工程里你会发现一个很反直觉的事实不管上层应用怎么翻新底层能动的空间其实只有两个位置——输入侧和输出侧。中间那层模型本身对绝大多数开发者来说就是个黑盒你既改不动它的权重也换不掉它的注意力机制。我做过对话机器人、知识抽取、文档问答、智能客服这几类项目踩过的坑几乎都指向同一个结论把大模型拆成三层来看很多纠结的问题会瞬间清晰。这篇就按我自己的理解把这三层架构掰开揉碎讲一遍顺带把每层能做什么、不能做什么、实际项目里怎么选都摊开说清楚。适合正在做 AI 应用开发、准备面试、或者单纯想把大模型这摊事理明白的人看。1. 为什么三层这个切法比模型应用两分法好用1.1 两层视角的盲区在哪里大多数人接触大模型第一反应是把它分成模型和应用两块。模型负责推理应用负责调 API、拼界面。这个分法在 demo 阶段够用但一旦项目稍微复杂一点就会开始出问题。我最早做文档问答的时候就吃过这个亏。当时的需求是用户上传一份 PDF系统回答里面的问题。按两层视角我的思路是调模型 写前端。结果做出来效果很差模型要么答非所问要么把原文一字不差抄回来。我一开始以为是模型不行换了好几个效果都差不多。后来才意识到问题根本不在模型而在我怎么把 PDF 内容喂给它、以及怎么处理它吐出来的东西。这就是两层视角的盲区它把输入怎么组织和输出怎么加工这两件极其重要的事默认成了应用层顺手就做了的小事。实际上这两件事的工作量和难度往往比调模型本身大得多。1.2 三层架构的划分逻辑我习惯把整个链路切成三层输入层从原始数据到模型能吃的 prompt中间所有的清洗、切分、检索、拼接、模板化都算这一层。模型层真正做推理的那部分包括基础模型、微调后的模型、以及推理时的采样参数temperature、top_p 这些。输出层模型吐出来的原始文本到最终呈现给用户的结果之间所有的解析、校验、格式化、后处理。这个切法的好处是它把你能控制什么和你控制不了什么分得很清楚。模型层对大部分人来说是黑盒你只能通过选型和调参施加有限影响而输入层和输出层是完全属于你的地盘想怎么折腾就怎么折腾。提示判断一个需求该在哪层解决有个简单的问法——这件事是改变模型看到的东西还是改变模型说出来的东西前者归输入层后者归输出层两个都不沾的才考虑动模型层。1.3 一个真实项目的三层映射拿我做过的一个制度条例学习助手举例。用户问员工出差住宿标准是多少系统要给出准确答案。输入层做的事把几百页的制度文档切块、向量化、存进检索库用户提问时先检索出最相关的几段把这几段和问题拼成一个带指令的 prompt。模型层做的事拿着这个 prompt 生成答案我选的是一个中等规模、中文能力不错的模型temperature 调到 0.2 让它别太发散。输出层做的事检查答案里有没有引用到不存在的条款号把关键数字加粗如果检索置信度太低就追加一句建议查阅原文确认。你看真正决定这个助手好不好用的是输入层的切块策略和输出层的校验逻辑模型层反而换谁都差不多。这就是三层视角的价值——它让你把精力花在刀刃上。2. 输入层决定模型上限的那一半2.1 输入层到底包含哪些环节很多人以为输入层就是写 prompt这是最大的误解。完整的输入层至少包含这么几个环节数据获取从数据库、文档、网页、用户历史里把原始素材捞出来。清洗与切分去掉噪声把长文本切成合适大小的块。检索与筛选从海量素材里挑出跟当前问题最相关的部分。上下文组装把选中的素材、系统指令、对话历史、用户问题按一定顺序拼起来。模板化套上固定的格式让模型知道该扮演什么角色、按什么结构回答。这五步里任何一步做砸了模型再强也救不回来。我见过太多项目模型选的是顶配但因为切块切得稀碎检索出来的内容驴唇不对马嘴最后效果还不如一个规则系统。2.2 切块策略最容易被低估的细节切块chunking这件事看起来简单实际上坑最多。我总结了几种常见策略和它们的适用场景切块方式适用场景优点坑点固定长度切分结构松散的纯文本实现简单容易把一句话拦腰截断按段落切分文章、新闻语义完整段落长短不一可能超长按标题层级切分制度、手册、技术文档保留结构信息需要文档本身有清晰层级语义切分高质量问答相关性高计算成本高实现复杂重叠滑窗通用兜底减少信息丢失冗余增加检索变慢我自己的经验是制度类、手册类文档优先按标题层级切再对超长的叶子节点做二次切分。因为这类文档的价值往往藏在层级关系里——第3章第2节这个位置信息本身就有意义固定长度切分会把它切没。切块大小也有讲究。太小了单块信息不完整模型答不全太大了检索精度下降还容易超出上下文窗口。我一般从 300 到 500 字起步根据实际效果微调。有个反直觉的点块大小不是越小越精确。块太小会导致语义碎片化检索出来的东西看着相关实际缺胳膊少腿。2.3 检索环节的取舍检索这块主流做法是向量检索也就是把文本转成向量算相似度。但纯向量检索有个毛病它对关键词精确匹配不敏感。比如用户问第 17 条怎么规定的向量检索可能给你返回一堆语义相近但条款号不对的内容。我的做法是混合检索向量检索负责语义召回关键词检索比如 BM25负责精确匹配两路结果合并去重后再排序。实测下来在制度问答、法律咨询这类场景混合检索比纯向量检索的准确率能高出一截。排序环节也值得说一句。检索出来一堆候选怎么挑最相关的几条塞进 prompt简单点按相似度排序就行讲究点可以上一个重排模型rerank。重排模型的作用是精挑细选它比向量相似度更能判断真正的相关性。代价是多一次推理延迟会涨。我的建议是候选数量多、对准确率要求高的场景上重排否则省了。2.4 上下文组装的顺序玄学把检索到的内容、系统指令、用户问题拼成一个 prompt顺序是有讲究的。业界有个被反复验证的现象模型对 prompt 开头和结尾的内容记得最牢中间部分容易被忽略。这叫中间遗忘。所以组装的时候重要的指令放开头用户的核心问题放结尾检索到的参考资料放中间。如果参考资料特别多把最相关的放最前面和最后面次相关的塞中间。还有个细节给检索内容编号。比如【资料1】……【资料2】……然后在指令里要求模型引用资料时标注编号。这样输出层就能校验它引用的编号是不是真实存在的防止它编造来源。2.5 输入层的实操心得说几个我踩过的坑别把原始 HTML 直接喂进去。标签、脚本、样式会污染上下文浪费 token 还干扰模型。先转成纯文本。对话历史要截断。多轮对话里历史越长越容易跑偏。我一般只保留最近 5 到 10 轮更早的做摘要压缩。系统指令要具体。你是一个 helpful 的助手这种废话没用。要写清楚角色、任务、输出格式、禁止事项。给例子比讲道理管用。与其描述请按 JSON 格式输出不如直接给一个 JSON 示例。这叫少样本提示效果立竿见影。3. 模型层黑盒里能拧的那几个旋钮3.1 模型选型不是越大越好模型层对多数人来说是黑盒但选型是你必须做的决定。选型要考虑的维度不止能力强不强能力中文理解、推理、代码、多模态看你的任务需要什么。成本按 token 计费的得算清楚每次请求大概花多少。延迟在线交互场景首字延迟和总耗时都很关键。上下文窗口能塞多少内容直接决定输入层的设计空间。部署方式调 API 还是本地部署涉及数据合规和成本结构。我的经验是先用能力最强的模型把效果跑通确认方案可行再逐步降级到更便宜的模型看效果掉多少。很多时候你会发现任务本身不难小模型完全够用成本能降一个数量级。3.2 采样参数控制模型性格的旋钮模型推理时有几个参数直接决定输出的风格temperature控制随机性。0 附近最确定1 以上很发散。事实类问答调到 0.1 到 0.3创意写作可以到 0.7 以上。top_p也叫核采样控制候选词的范围。一般 0.9 左右比较稳。max_tokens限制输出长度防止模型啰嗦个没完。frequency_penalty / presence_penalty抑制重复长文本生成时有用。这几个参数里temperature 是最该调的。我见过有人做事实问答用默认的 1.0结果同一个问题问两次答案都不一样用户直接懵了。事实类任务temperature 一定要压低。3.3 微调什么时候值得做微调是模型层唯一能改模型的手段但它的门槛和成本都不低。我的判断标准是任务高度垂直、格式要求严格比如固定格式的信息抽取微调能显著提升稳定性。有大量高质量标注数据至少几千条少了没意义。prompt 工程已经榨干如果调 prompt 就能解决别急着微调。反过来说如果任务是开放式的、数据量不够、或者需求还在频繁变微调就是浪费钱。我见过团队花大价钱微调了一个模型结果需求一变微调成果直接作废。注意微调不是教模型新知识的好办法。想让模型掌握事实性知识检索增强RAG比微调靠谱得多。微调更适合教模型一种行为方式比如固定的输出格式、特定的语气。3.4 本地部署的现实考量有些场景必须本地部署比如数据不能出内网。这时候要考虑硬件显存够不够能不能装下模型。量化能省显存但会掉一点效果。推理框架不同的推理引擎在吞吐和延迟上差别很大选对了能省不少资源。并发本地部署的并发能力通常有限得做好排队和限流。本地部署的坑在于很多人低估了运维成本。模型跑起来只是第一步后面还有监控、扩缩容、版本管理一堆事。如果团队没有专门的运维慎重考虑。4. 输出层把能看变成能用4.1 输出层为什么重要模型吐出来的东西是能看的文本但不一定是能用的结果。输出层的任务就是把这个半成品加工成最终产品。举个最典型的例子你要模型返回结构化数据它可能给你一段带 markdown 代码块的 JSON前面还加一句好的以下是结果。这段文本人看着没问题但程序解析会直接报错。输出层要做的就是把代码块剥出来、把多余的话去掉、把 JSON 解析成对象。我做过一个信息抽取项目模型本身抽取准确率有 85%但因为输出格式不稳定程序解析成功率只有 60%。后来加了一层输出清洗和容错解析整体成功率拉回到 83%。输出层的价值很多时候比换个更强的模型还大。4.2 结构化输出的几种实现路径让模型稳定输出结构化数据有几种做法从弱到强纯 prompt 约束在指令里写清楚格式要求给示例。简单但不稳定。正则后处理模型输出后用正则提取。能兜底但正则写起来烦。JSON 模式很多模型 API 支持强制 JSON 输出这是最省心的。函数调用 / 工具调用让模型按预定义 schema 输出适合复杂结构。约束解码在解码阶段就限制输出符合语法最稳但需要框架支持。我的建议是能用 JSON 模式就用 JSON 模式不能用就 prompt 加正则兜底。函数调用适合需要模型决定调用哪个工具的场景纯数据抽取用不上。4.3 校验与兜底别信模型说的每一句话模型会一本正经地胡说八道这是常识。输出层必须有一道校验关卡格式校验JSON 能不能解析必填字段在不在。范围校验数字在不在合理区间枚举值是不是合法选项。引用校验如果要求引用来源检查引用的编号是否真实存在。一致性校验答案和检索到的资料是否矛盾。校验不通过怎么办两条路一是重试把错误信息反馈给模型让它重新生成二是降级返回一个保守的默认答案或者提示用户。重试要有次数上限别陷入死循环。4.4 流式输出的处理在线场景基本都用流式输出一个字一个字往外蹦用户体验好。但流式给输出层带来麻烦你没法等全部生成完再校验。我的处理方式是分层校验流式过程中做轻量校验比如敏感词、明显格式错误全部生成完再做完整校验。如果完整校验发现问题可以给用户一个重新生成的按钮而不是直接改已经显示的内容。还有个细节流式输出时如果模型中途开始输出 markdown 代码块前端要能正确渲染。这个坑我踩过用户看到一堆反引号体验很差。4.5 输出层的实操心得永远给输出加超时。模型偶尔会卡住没有超时机制会拖垮整个服务。记录原始输出。出问题时原始输出是排查的第一手资料别只存处理后的结果。后处理逻辑要幂等。同一段输出处理两次结果应该一样方便重试。给用户留退路。模型答得不好时提供换个说法再问或转人工的入口。5. 三层之间的边界与协作5.1 一个问题该在哪层解决这是实战中最常纠结的问题。我总结了一个判断流程模型不知道某件事 → 输入层把知识喂给它检索增强。模型知道但说不好 → 输入层调 prompt或者输出层做后处理。模型格式总是不对 → 先试输出层约束不行再考虑微调。模型风格不对 → 输入层给示例或者微调。模型能力不够 → 模型层换更强的模型。大部分问题其实都能在输入层和输出层解决真正需要动模型层的情况很少。5.2 三层的成本分布从成本角度看三层的投入差别很大层级主要成本优化空间输入层检索、存储、token 消耗大切块和检索策略直接影响 token 量模型层API 调用费或算力中选型和参数能省但受能力约束输出层计算资源相对小大纯逻辑处理几乎不花钱有意思的是输入层和输出层的优化往往能同时降低成本和提高质量。比如切块更精准检索出来的内容更少更相关token 消耗降了答案还更准。这种双赢的优化比单纯换便宜模型划算得多。5.3 迭代时的调试顺序项目效果不好从哪层开始查我的顺序是先看输入层检索出来的内容对不对prompt 组装有没有问题把实际发给模型的 prompt 打印出来看。再看输出层模型原始输出是什么后处理有没有把好结果搞坏最后看模型层前面都没问题才考虑换模型或调参。这个顺序的原因是输入层和输出层的问题最容易定位也最容易修模型层的问题最难搞。先易后难效率最高。6. 从三层视角看几个常见场景6.1 知识问答类应用这类应用的核心在输入层。检索质量决定上限模型只是把检索到的内容组织成通顺的话。我的经验是把 70% 的精力花在切块和检索上20% 花在输出校验10% 花在模型选型。具体做法文档按标题层级切块混合检索召回重排精选prompt 里明确要求只根据提供的资料回答资料里没有就说不知道。输出层校验引用编号防止编造。6.2 信息抽取类应用这类应用的核心在输出层。模型抽取能力通常够用难的是稳定输出结构化结果。做法是输入层给几个抽取示例少样本输出层用 JSON 模式加严格校验校验失败就重试。6.3 对话助手类应用这类应用三层都要照顾。输入层管理对话历史和角色设定模型层选一个响应快、对话能力强的输出层处理流式渲染和敏感内容过滤。6.4 内容生成类应用核心在输入层和模型层。输入层提供足够的素材和风格示例模型层选一个文笔好的temperature 调高一点增加多样性。输出层做基本的格式整理和事实核查。7. 面试和团队协作里的三层思维7.1 面试时怎么讲清楚三层面试被问到你怎么设计一个 AI 应用用三层框架回答会显得很有条理先说输入层怎么处理数据和组装 prompt再说模型层怎么选型和调参最后说输出层怎么校验和兜底。这样回答的好处是面试官能看出你理解整个链路而不是只会调 API。我面过不少人能讲清楚输入层和输出层的明显比只会说我用了某某模型的高一个档次。7.2 团队分工的参考三层架构也适合团队分工。输入层的工作偏数据和检索适合有后端和数据背景的人模型层偏算法适合有机器学习背景的人输出层偏工程和产品适合全栈或前端背景的人。当然小团队一人全包也正常但心里有这个划分协作时沟通会顺畅很多。7.3 需求评审时的价值需求评审时三层框架能帮你快速判断一个需求的工作量。产品说加个新功能你先问这是改输入、改输出还是改模型改输入和输出通常几天能搞定改模型可能要几周。有了这个判断排期就不会拍脑袋。8. 一些容易被忽略的工程细节8.1 日志与可观测性三层都要打日志。输入层记录实际组装的 prompt模型层记录 token 消耗和延迟输出层记录原始输出和处理结果。出问题时这些日志是唯一的线索。我见过没打日志的团队线上出问题只能靠猜排查效率极低。8.2 缓存策略输入层可以缓存检索结果相同问题不用重复检索。模型层可以缓存相同 prompt 的输出但要注意 temperature 大于 0 时输出不固定缓存意义有限。输出层的后处理结果也可以缓存。8.3 版本管理prompt 是要版本管理的。改了一版 prompt效果变好了还是变差了得有记录能对比。我一般把 prompt 存在配置文件或数据库里每次修改都留痕方便回滚。8.4 灰度与 A/B 测试prompt 改动、模型切换、检索策略调整都应该灰度发布。先放一小部分流量对比效果确认没问题再全量。这个习惯能避免很多线上事故。9. 我踩过的几个典型坑9.1 把模型当搜索引擎早期我做过一个问答直接把用户问题丢给模型指望它自己知道答案。结果它要么编要么答得模棱两可。后来才明白模型的知识是训练时固化的时效性和准确性都靠不住。该检索就检索别偷懒。9.2 忽略 token 成本有次做长文档问答把整篇文档塞进 prompt一次请求几万 token账单直接爆了。后来改成检索相关片段token 降了 90%效果还更好。上下文不是塞得越多越好塞得准才是关键。9.3 输出格式没约束做信息抽取时没约束输出格式模型一会儿返回 JSON一会儿返回表格一会儿又加一段解释。程序解析天天报错。后来强制 JSON 模式问题迎刃而解。能用结构化输出就用别跟模型客气。9.4 忘了处理模型拒答模型有时候会拒答比如我无法回答这个问题。如果输出层没处理这种情况用户会看到一个莫名其妙的回复。我的做法是检测这类拒答模式触发时走降级逻辑比如提示用户换个问法。9.5 检索和生成脱节有次检索出来的内容明明是对的但模型答错了。排查发现是 prompt 里检索内容和问题的位置隔太远模型没关联上。调整顺序后就好了。检索和生成之间的桥要搭好别让模型自己猜。10. 三层架构的边界在哪里10.1 不是所有问题都能靠三层解决三层架构是个分析框架不是万能药。有些问题它解决不了比如模型本身的能力天花板再怎么优化输入输出也突破不了。数据源本身质量差检索再牛也捞不出好东西。需求本身不清晰三层都无从下手。遇到这些情况得回到更上游去解决。10.2 三层会随技术演进而变化现在模型能力越来越强上下文窗口越来越大有些原本需要复杂输入层处理的事模型自己就能搞定。比如超长上下文模型出现后一些场景可以少做检索直接把文档塞进去。但这不意味着三层架构失效只是三层的边界在移动。理解框架比记住具体做法重要。10.3 给不同阶段团队的建议刚起步先把输入层和输出层做扎实模型用现成的 API别急着微调。有一定规模开始优化检索和 prompt建立评测体系用数据驱动迭代。成熟阶段考虑微调、本地部署、多模型路由把成本和效果都压到最优。我个人在实际项目里的体会是三层架构最大的价值不是让你多做什么而是让你知道什么时候不用做什么。很多团队一上来就想微调、就想换模型其实问题根本不在那。把输入层和输出层这两块属于自己的地盘经营好效果提升往往比折腾模型来得快。最后分享一个小技巧每次效果不好时先把实际发给模型的完整 prompt 打印出来从头到尾读一遍十有八九你自己就能发现问题在哪。