★ FEATURED ARTICLE 1. 为什么“三层架构”是理解大模型应用的万能钥匙很多人第一次接触大模型应用开发时会被各种新名词砸晕RAG、Agent、Function Calling、思维链、提示词工程、微调、向量数据库……每一个词背后都有一整套教程和工具链学完一圈下来脑子里的感觉就是“东西太多了根本记不住”。但如果你把市面上所有大模型应用案例摊开来看会发现一个反直觉的事实它们本质上都在做同一件事——控制输入什么以及处理输出怎么用。中间那个“模型本身”反而是最不需要你操心的部分。你不需要训练它不需要理解注意力机制的每一个矩阵乘法你只需要知道它是一个“输入文本、输出文本”的黑盒。这就是我所说的“三层架构”第一层输入层——你往模型里塞什么。包括系统提示词、用户问题、检索到的文档片段、历史对话、工具描述、少样本示例等。第二层模型层——模型本身的能力边界。包括上下文窗口大小、推理能力、指令遵循能力、知识截止日期、多模态支持等。第三层输出层——你怎么处理模型吐出来的东西。包括解析结构化输出、调用外部工具、校验事实性、格式化展示、多轮迭代等。这三层里模型层是“给定条件”你改不了除非微调但那是另一回事。真正决定一个应用好不好用的是输入层和输出层的设计。换句话说所有AI新花样本质上都是在“输入什么”和“输出怎么处理”上做文章。我举个例子你就明白了。假设你要做一个“合同审查助手”。输入层要做的事是把合同文本切块、检索相关法条、拼接成提示词、告诉模型“你是一个资深法务”。输出层要做的事是让模型按JSON格式输出风险点、对每个风险点标注严重程度、如果模型说“不确定”就触发人工复核。模型层呢你选一个上下文窗口够大、中文理解够好的模型就行。整个系统的复杂度90%在输入和输出两端。这篇文章就是要把这三层拆开揉碎告诉你每一层里有哪些关键决策点、常见的坑在哪里、以及怎么用最小的成本做出最稳的效果。不管你是刚入门的新手还是已经做过几个Demo的老手这套框架都能帮你把脑子里零散的知识点串成一条线。2. 输入层决定模型上限的隐形战场2.1 系统提示词不是“写作文”而是“定规矩”很多人写系统提示词的习惯是写一大段话把能想到的要求全塞进去觉得写得越多模型越听话。实测下来这种做法往往适得其反。模型在长提示词里会“迷失”前面说的规则到后面就忘了或者被后面的指令覆盖掉。我自己的经验是系统提示词要像写API文档一样写而不是像写散文一样写。什么意思API文档的特点是结构清晰、每条规则独立、有明确的输入输出定义、边界条件写清楚。系统提示词也应该这样。一个可复用的系统提示词模板长这样# 角色 你是一个[具体角色]负责[具体任务]。 # 能力边界 - 你可以做[列出允许的操作] - 你不能做[列出禁止的操作] - 遇到不确定的情况[定义兜底行为] # 输出格式 [明确定义输出的结构最好给一个示例] # 约束条件 - [约束1] - [约束2]这个模板的好处是模型在处理时会把每个部分当成独立的指令块来对待不会互相干扰。而且当你需要调整时你知道改哪个部分不用重写整个提示词。还有一个细节把最重要的规则放在最前面和最后面。这是基于模型注意力分布的经验——中间部分的内容容易被“稀释”。如果你有一条绝对不能违反的规则比如“不得编造法条编号”把它放在系统提示词的第一句和最后一句各说一遍。2.2 上下文窗口的“黄金分割点”上下文窗口大小是模型层的硬指标但怎么用满这个窗口是输入层的艺术。我见过太多人把整个知识库往提示词里塞结果模型反而变笨了。原因很简单信息过载会导致注意力分散。我的做法是把上下文窗口分成几个功能区每个区有明确的预算。区域建议占比内容系统指令区10%-15%角色定义、规则、输出格式少样本示例区15%-20%2-3个高质量示例检索知识区40%-50%与当前问题最相关的文档片段对话历史区10%-15%最近3-5轮对话用户问题区5%-10%当前问题这个分配不是绝对的但核心原则是检索知识区不能超过一半。超过一半模型就会变成“复读机”只会从文档里抄不会推理。我试过把检索区压到30%把省下来的空间给少样本示例结果模型输出的结构化程度明显提升。还有一个实操技巧在检索知识区的每个片段前加一个“来源标签”。比如[来源产品手册v2.3第4章] 退货政策自签收之日起7天内可无理由退货... [来源客服培训材料2024版] 退货流程用户需先在小程序提交申请...这个标签的作用是让模型知道“这段话是从哪来的”当它需要引用时可以准确标注来源。没有这个标签模型会把所有检索内容当成“自己知道的知识”输出时就不带出处了。2.3 少样本示例质量比数量重要十倍少样本示例Few-shot Examples是输入层里性价比最高的工具。但很多人用错了方向他们放10个示例每个示例都是随便写的。结果模型学到的不是“任务模式”而是“示例里的噪声”。我的原则是2-3个精挑细选的示例胜过10个凑数的。每个示例要满足三个条件覆盖一个典型场景不要选边缘案例选最常见的输入类型。展示完整的输入输出对包括输入文本和期望的输出格式。包含一个“困难案例”比如输入有歧义时模型应该怎么处理。举个例子如果你在做“情感分类”任务示例可以这样设计示例1典型正面 输入这个产品用起来很顺手续航也够用。 输出{sentiment: positive, confidence: 0.9, reason: 明确表达满意} 示例2典型负面 输入收到货就坏了客服还不理人。 输出{sentiment: negative, confidence: 0.95, reason: 质量问题服务问题} 示例3困难案例-混合情感 输入东西不错但物流太慢了。 输出{sentiment: mixed, confidence: 0.7, reason: 产品正面物流负面}注意第三个示例它教模型在遇到混合情感时不要强行二选一而是输出“mixed”。这个规则如果你只用文字描述模型可能记不住但用一个示例展示模型就能学会。还有一个坑示例的顺序会影响结果。模型有“近因效应”最后一个示例对输出的影响最大。所以如果你希望模型偏向某种输出风格把最符合你期望的示例放在最后。2.4 检索增强生成RAG的输入层陷阱RAG是现在最火的应用模式但很多人只关注“怎么检索”忽略了“检索到的东西怎么放进提示词”。这里有两个常见的坑坑一检索片段直接拼接没有去重和排序。如果检索返回5个片段其中3个讲的是同一件事模型会收到重复信息导致输出冗余。我的做法是先对检索结果做一次聚类把相似度高于0.9的片段合并然后按与问题的相关度排序只取前3-4个。坑二检索片段没有“边界标记”。如果直接把片段拼在一起模型分不清哪里是文档A的结尾、哪里是文档B的开头。我习惯用XML标签包裹每个片段document id1 source产品手册 退货政策自签收之日起7天内可无理由退货... /document document id2 source客服培训 退货流程用户需先在小程序提交申请... /documentXML标签的好处是模型对结构化标记很敏感能准确识别每个片段的边界。而且当模型需要引用时可以直接说“根据文档1”方便你后续做溯源。3. 模型层选型不是选“最强”而是选“最合适”3.1 上下文窗口、推理能力、成本的不可能三角选模型时所有人都会面临一个三角困境上下文窗口大、推理能力强、成本低这三者不可能同时满足。你必须根据场景做取舍。我整理了一个决策表帮你快速定位场景特征优先考虑可以妥协典型模型类型长文档摘要、合同审查上下文窗口推理深度长窗口模型数学推理、代码生成推理能力上下文窗口推理增强模型高并发客服、批量分类成本推理深度轻量模型多轮复杂对话综合平衡极致成本通用中杯模型这个表的关键洞察是没有“最好”的模型只有“最适合当前任务”的模型。我见过一个团队用最贵的推理模型做简单的文本分类成本翻了20倍效果只提升了2%。这就是典型的选型错配。还有一个实操建议不要只用一个模型。很多生产系统会做“模型路由”简单任务走轻量模型复杂任务走推理模型。比如用户问“今天天气怎么样”没必要调用推理模型用户问“帮我分析这份财报的潜在风险”才需要上重武器。路由逻辑可以基于问题长度、关键词、或者一个轻量分类器来判断。3.2 温度参数不是“创意开关”而是“分布调节器”温度Temperature是模型层最被误解的参数。很多人把它当成“创意开关”温度高有创意温度低保守。这个理解只对了一半。从原理上说温度调节的是模型输出概率分布的“平滑程度”。温度趋近0时模型总是选概率最高的那个词输出最确定温度升高时低概率词也有机会被选中输出更多样。但这里有个关键细节温度不是线性影响创造力的。在0到0.5之间温度主要影响“确定性”在0.5到1.0之间才开始影响“多样性”超过1.0输出会变得混乱甚至语法错误。我的经验值是事实性任务问答、摘要、翻译温度0-0.3结构化输出JSON、表格温度0-0.2创意写作文案、故事温度0.7-0.9头脑风暴生成多个方案温度0.9-1.0还有一个坑温度和其他参数会互相影响。比如Top-p核采样和温度一起用时效果不是简单叠加。如果你设了温度0.8又把Top-p设成0.5实际多样性会比你预期的低。我的建议是只调一个参数另一个保持默认。通常调温度就够了。3.3 模型的知识截止日期一个容易被忽略的“隐形边界”每个模型都有知识截止日期意思是它训练数据只到某个时间点。这个日期之后发生的事情模型不知道。但问题是模型不会主动告诉你“我不知道”。它会用已有的知识去“编”一个看起来合理的答案。这个坑在时效性强的场景里特别致命。比如你问“最新的XX政策是什么”模型可能会把两年前的旧政策改个日期就给你。如果你不核实直接用了后果可能很严重。我的应对策略是在系统提示词里明确写“如果问题涉及[具体时间范围]之后的事件请回答‘我需要最新信息建议查询权威来源’”。同时在输出层加一个校验步骤如果模型输出里包含具体日期、数字、政策名称触发人工复核或二次检索。还有一个技巧把“知识截止日期”写进系统提示词。比如“你的知识截止到2024年6月。如果用户询问此日期之后的事件请明确告知你可能没有最新信息。” 这样模型在遇到边界情况时会主动“举手”而不是硬编。4. 输出层从“能说会道”到“能干活”的关键一跃4.1 结构化输出让模型说“机器能懂的话”模型默认输出的是自然语言但下游系统需要的是结构化数据。把自然语言转成JSON、XML、表格是输出层最基础也最重要的任务。很多人用“请输出JSON格式”这种指令然后祈祷模型听话。实测下来成功率大概70%。剩下30%的情况模型会加一句“好的以下是JSON”或者在JSON外面包一层解释文字。我的做法是用“模式约束”代替“格式请求”。具体来说在系统提示词里定义一个严格的输出模式并给出一个“反例”# 输出格式 你必须输出一个合法的JSON对象不要包含任何其他文字。 JSON结构如下 { answer: string, confidence: 0.0-1.0, sources: [string] } # 错误示例不要这样输出 好的以下是JSON { answer: ... }这个“错误示例”很关键。模型看到“不要这样输出”之后会主动避免在JSON前后加解释文字。我实测下来加了错误示例后结构化输出的成功率从70%提升到了95%以上。还有一个进阶技巧用“输出解析器”做二次校验。即使模型输出了JSON也可能有语法错误比如多了个逗号。在代码里加一个try-catch解析失败时自动重试或降级处理。这个成本很低但能避免很多线上事故。4.2 工具调用让模型从“说”到“做”工具调用Function Calling是输出层最强大的能力。模型不再只是生成文本而是可以触发外部操作查数据库、发邮件、调API、控制设备。但工具调用的坑也最多。我见过最常见的错误是工具描述写得太模糊。比如一个“查询天气”的工具描述只写“查询天气”。模型不知道这个工具需要什么参数、返回什么格式、适用于什么场景。正确的工具描述应该包含{ name: get_weather, description: 查询指定城市的当前天气。适用于用户询问天气、温度、降水等场景。不适用于查询历史天气或未来预报。, parameters: { city: { type: string, description: 城市名称必须是中文如北京、上海 }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位默认celsius } } }注意description里的“适用于”和“不适用于”——这能帮模型判断什么时候该调用、什么时候不该调用。没有这个边界模型可能会在用户问“明天天气”时也调用这个工具然后返回错误结果。还有一个关键点工具调用的结果要“翻译”回自然语言。模型调用工具后拿到的是JSON数据但用户需要的是自然语言回答。这个“翻译”步骤不能省。我通常会在工具返回后再给模型一个提示“根据工具返回的数据用自然语言回答用户的问题不要直接输出JSON。”4.3 输出校验三道防线挡住“胡说八道”模型会“幻觉”——编造不存在的事实、引用不存在的来源、给出错误的计算。输出层的核心任务之一就是建立校验机制。我的做法是三道防线第一道格式校验。检查输出是否符合预期的结构JSON是否合法、必填字段是否存在、数值是否在合理范围。这道防线用代码就能实现成本最低。第二道事实校验。如果输出包含具体事实日期、数字、名称用检索或规则库做交叉验证。比如模型说“根据XX法第XX条”就去法条库里查一下这条是否存在。这道防线需要一些领域知识但能挡住大部分严重错误。第三道一致性校验。让模型自己检查一遍输出。具体做法是把原始问题和模型输出一起再喂给模型问“这个回答是否准确有没有遗漏或错误” 这道防线成本最高但能发现一些微妙的逻辑问题。三道防线的顺序是先格式、再事实、最后一致性。因为格式错误最容易发现也最容易修复事实错误需要外部知识一致性检查最耗时放在最后。4.4 多轮迭代让模型“再想想”有时候模型第一次输出不够好但直接重新生成又浪费。这时候可以用“迭代优化”的策略把第一次输出作为输入让模型改进。具体做法是你之前的回答是 [第一次输出] 请检查这个回答并做以下改进 1. 如果缺少具体数据补充数据 2. 如果逻辑不清晰重新组织 3. 如果语气不合适调整语气 输出改进后的版本。这个技巧在写作、分析、规划类任务里特别有效。我试过让模型写产品文案第一版平平无奇迭代两次后质量明显提升。关键是迭代次数不要超过3次。超过3次模型会开始“过度优化”把原本正确的内容改错。还有一个变体多视角生成。让模型从不同角色出发生成多个版本然后选最好的。比如“分别以技术专家、普通用户、竞争对手的视角评价这个方案”。这个方法能帮你发现盲点但成本较高适合重要决策场景。5. 三层架构的实战组合一个完整案例的拆解5.1 场景定义从“需求”到“三层映射”假设我们要做一个“技术文档问答助手”。用户可以用自然语言提问系统从一堆技术文档里找到答案并给出出处。这个需求拆到三层里是这样的输入层用户问题 检索到的文档片段 系统提示词定义角色和输出格式模型层选一个上下文窗口够大至少32K、中文理解好的通用模型输出层解析JSON输出、提取答案和出处、如果置信度低则提示“建议查阅原文”这个拆解看起来简单但每一步都有细节。下面我按三层分别展开。5.2 输入层的具体设计系统提示词这样写# 角色 你是一个技术文档问答助手。你的任务是根据提供的文档片段回答用户的技术问题。 # 规则 1. 只使用提供的文档片段中的信息回答不要使用你自己的知识。 2. 如果文档片段中没有相关信息回答“根据现有文档我无法回答这个问题”。 3. 每个回答必须标注来源格式为[文档ID]。 # 输出格式 { answer: string, sources: [文档ID], confidence: 0.0-1.0 }检索策略用向量检索找Top-5相关片段然后用一个轻量模型做重排序取Top-3。每个片段前加[文档ID]标签。少样本示例放2个示例一个正常回答一个“无法回答”的情况。5.3 模型层的参数配置温度0.1事实性任务要确定性Top-p默认不调最大输出长度500 tokens答案不会太长停止序列}JSON结束符防止模型继续生成5.4 输出层的处理链路解析JSON如果失败重试一次再失败返回“系统繁忙”。检查confidence字段如果低于0.6在答案前加“根据现有文档信息可能不完整”。提取sources字段在答案末尾附上“参考文档[ID列表]”。如果answer包含“无法回答”记录日志用于后续优化检索策略。这个链路跑下来整个系统的准确率和用户体验都比“直接问模型”好很多。关键是把每一层的职责分清楚了输入层负责“给对信息”模型层负责“理解信息”输出层负责“用好信息”。6. 那些年我踩过的三层架构坑6.1 输入层的坑提示词越长越好刚入门时我总觉得提示词写得越详细越好。有一次做一个“会议纪要生成”的任务我写了800字的系统提示词把能想到的规则全塞进去了。结果模型输出反而变差了——它开始“过度解读”某些规则把不重要的细节放大。后来我学乖了提示词的长度和效果不是正相关的。关键规则要精炼示例要典型其他细节让模型自己发挥。现在我的系统提示词通常控制在300字以内效果反而更稳。6.2 模型层的坑盲目追求“最强模型”有一段时间我不管什么任务都用最贵的推理模型。结果发现对于简单的文本分类任务推理模型和轻量模型的准确率只差1%但成本差了15倍。而且推理模型因为“想得太多”有时候会把简单问题复杂化。现在的做法是先用轻量模型跑一遍如果效果不达标再升级模型。大部分任务其实不需要顶级模型。6.3 输出层的坑忽略“失败路径”最开始做输出解析时我只考虑了“成功解析”的情况。结果上线后模型偶尔输出格式错误整个系统就崩了。后来我加了完整的失败处理解析失败→重试→降级→记录日志。这个“失败路径”的设计比“成功路径”更重要。还有一个坑没有给模型“说不”的机会。如果检索不到相关信息模型应该能说“我不知道”而不是硬编一个答案。我在系统提示词里明确写了“如果文档中没有相关信息回答‘无法回答’”这个简单的规则避免了很多幻觉问题。7. 三层架构的扩展思考新花样到底新在哪回到标题那句话“所有AI新花样只在输入什么/输出怎么处理”。现在你可以验证一下RAG新在输入层——把检索结果放进提示词。Agent新在输出层——把模型的输出解析成工具调用。思维链新在输入层——在提示词里加“让我们一步步思考”。Function Calling新在输出层——结构化输出工具调用。多模态新在输入层图片/音频输入和输出层图片/音频输出。微调新在模型层——但本质还是调整“输入-输出”的映射关系。所以当你看到一个新概念时先问自己它改的是输入层、模型层、还是输出层大部分情况下答案是输入层或输出层。模型层的变化比如新的架构、更大的参数量是少数。这个框架的价值在于它帮你把“学不完的新知识”变成了“三个固定位置的排列组合”。你不需要追每一个新名词只需要关注输入层有什么新工具比如新的检索方法、新的提示词技巧输出层有什么新玩法比如新的解析方式、新的工具集成。模型层等它真的变了再说。我在实际项目里的体会是把三层拆清楚之后排查问题变得容易多了。效果不好时先看输入层——检索对不对提示词有没有歧义再看输出层——解析有没有问题校验够不够最后才考虑换模型。大部分问题其实出在输入和输出两端模型本身很少是瓶颈。最后分享一个小技巧每次调整只改一层的一个变量。比如这次只改检索策略下次只改输出格式。如果同时改多个地方你根本不知道是哪个改动起了作用。这个原则听起来简单但能帮你省下大量“瞎调”的时间。
阅读完成 · 觉得有帮助？
