企业官网建设流程全解析

1. 大模型三层架构到底在拆什么

1.1 从一个常见困惑说起

很多人第一次接触大模型应用开发时，脑子里是一团浆糊。今天看到有人用提示词工程做角色扮演，明天看到有人用RAG做知识库问答，后天又冒出个Agent自动调工具，再往后还有微调、蒸馏、量化一堆词砸过来。每个方向看起来都是一座独立的山头，学完一个又冒出一个，永远追不完。

但如果你把市面上所有大模型相关的“新花样”摊开来看，会发现一个很反直觉的事实：底层模型本身的变化其实很慢，真正在快速迭代的，是模型外面那两层——输入层和输出层。

我打个比方。大模型本身就像一台发动机，它的马力、油耗、响应曲线在出厂时就基本定死了。但你可以给这台发动机配不同的进气系统、不同的传动轴、不同的排气处理装置，最终呈现出来的驾驶体验可以天差地别。市面上那些让人眼花缭乱的AI产品，绝大多数不是在改发动机，而是在改进气和排气。

这就是三层架构的核心思路：

• 模型层：负责“理解与生成”的原始能力，是发动机本体
• 输入层：负责“给模型看什么”，是进气系统
• 输出层：负责“拿到结果后怎么处理”，是排气和传动系统

把这三层分清楚之后，你会发现一个很爽的事情：90%的AI新玩法，本质上都是在输入层和输出层做文章，模型层可能一行代码都没动。

1.2 为什么这个拆解框架值得掌握

我刚开始做AI应用的时候，也是看到什么火就学什么，学一个忘一个，因为每个教程都从不同的角度切入，知识之间连不起来。后来我把手头做过的七八个项目摊在桌上复盘，突然意识到它们其实都在同一个框架里跑，只是我一直在用不同的名字称呼同样的东西。

掌握三层架构之后，你至少获得三个好处：

第一，学习效率大幅提升。再看到一个新概念，你可以立刻问自己：它是在改输入、改输出，还是真的动了模型？大部分情况下答案是前两者，那你只需要理解它的输入输出策略就行了，不需要从头学一套新体系。

第二，方案选型有据可依。老板说“我们要做一个能回答公司内部文档的问答机器人”，你不需要纠结用哪个模型，而是先想清楚：输入层怎么把文档塞进去，输出层怎么保证答案不胡说。模型层反而是最后才需要考虑的。

第三，排查问题有方向感。模型回答不好，到底是输入没给够信息，还是输出没做约束，还是模型本身能力不够？三层分开看，定位问题的速度会快很多。

1.3 三层架构的边界在哪里

在展开之前，先把三层的边界划清楚，不然后面容易混淆。

模型层包括：基座模型的选择、微调、蒸馏、量化、推理加速。这一层的特点是——你动它，成本高、周期长、门槛高。大部分团队和个人开发者，其实很少真正去动这一层。

输入层包括：提示词设计、上下文组装、检索增强、示例选择、格式转换、多轮对话管理。这一层的核心问题是：在模型能力固定的前提下，怎么把信息以最优的形式喂给它。

输出层包括：结果解析、格式校验、后处理、多路投票、工具调用编排、安全过滤、结果缓存。这一层的核心问题是：模型吐出来的东西不一定能直接用，怎么把它变成可交付的产品。

注意：三层之间不是完全割裂的。比如微调有时候也会影响输入格式的设计，输出层的工具调用结果又可能反过来成为下一轮输入的一部分。但作为分析框架，先分开看，再合起来想，效率最高。

2. 输入层：决定模型看到什么，比模型本身更重要

2.1 输入层的核心任务是什么

输入层要解决的根本问题只有一个：在有限的上下文窗口里，塞进最有效的信息。

大模型的上下文窗口是有限的，即使现在动辄几十万token的窗口，也不是无限往里灌就好。信息太多，模型会“注意力涣散”，关键信息被淹没在噪音里。信息太少，模型没有足够依据，只能靠猜。

所以输入层的设计，本质上是一个信息压缩和排序的问题。你要在有限的预算里，买到最高的信息密度。

我见过很多新手做RAG，把检索到的十篇文档原封不动全塞进去，结果模型回答质量反而下降。原因很简单：十篇文档里可能只有两段话真正相关，其他都是干扰项。模型在大量无关信息中找答案，就像在嘈杂的菜市场里听人小声说话，听不清是正常的。

2.2 提示词工程的本质是信息编排

提示词工程这个词被用烂了，很多人以为就是“写一段好听的话让AI听话”。其实提示词工程的本质是信息编排——你决定给模型看什么、按什么顺序看、以什么形式看。

一个结构良好的提示词，通常包含这几个部分：

我自己的经验是，角色设定和任务描述加起来不要超过三句话。写太长反而稀释了重点。真正决定输出质量的是上下文信息和示例的质量。

举个例子。你要做一个客服问答机器人，差的提示词是这样的：

你是一个专业的客服助手，请根据以下信息回答用户问题。 信息：xxx 问题：xxx

好的提示词是这样的：

你是某产品的售后客服。用户的问题涉及退换货政策。 请只根据下面提供的政策条款回答，不要自行推断。 如果条款中没有相关信息，直接回复“这个问题我需要帮您转接人工客服”。 政策条款： 1. 签收后7天内可无理由退货，商品需保持完好。 2. 质量问题30天内可换货，需提供照片凭证。 3. 定制类商品不支持无理由退货。 用户问题：我买的定制款杯子有点瑕疵，能退吗？ 回答要求： - 先判断是否属于质量问题 - 再判断是否在退换货期限内 - 最后给出明确结论 - 不超过三句话

差别在哪里？差提示词只给了信息，好提示词给了信息、约束、推理路径和输出格式。模型在好提示词下的输出，几乎不需要后处理就能直接用。

2.3 检索增强生成的关键在检索质量

RAG是输入层最热门的方向，但很多人把注意力放错了地方。他们花大量时间调生成模型，却忽略了检索质量才是决定RAG效果的天花板。

检索质量取决于三件事：

第一，文档切分策略。把一篇长文档切成小块，切多大、怎么切，直接决定了检索的精度。切太大，一个块里混了多个主题，检索出来噪音多；切太小，信息不完整，模型拼不出完整答案。

我的经验值是：中文文档每块300到500字，英文文档每块150到250词。同时要保留一定的重叠区域，防止关键信息刚好被切在边界上。重叠比例一般设10%到20%。

第二，向量化模型的选择。不同向量化模型对不同领域文本的敏感度差异很大。通用模型在通用语料上表现好，但在专业领域可能不如领域内微调过的小模型。选型时一定要用你自己的数据做评测，不要只看排行榜。

第三，重排序策略。向量检索召回的结果，顺序往往不是最优的。加一个重排序模型，对召回结果重新打分排序，通常能带来明显的效果提升。重排序模型不需要和向量化模型一样大，一个小型交叉编码器就够用。

实操心得：RAG调优时，先固定生成模型不动，只调检索部分。检索的召回率和准确率上去了，生成质量自然跟着上去。反过来，检索不行，生成模型再强也救不回来。

2.4 上下文组装的顺序有讲究

模型对上下文不同位置的敏感度是不一样的。一般来说，开头和结尾的信息更容易被模型记住，中间部分容易被忽略。这个现象在长上下文中尤其明显。

所以组装上下文时，要把最重要的信息放在开头或结尾。比如：

• 系统指令放最前面
• 最相关的检索结果放最前面或最后面
• 次要的参考信息放中间
• 用户当前问题放最后面

另外，不同信息块之间要有清晰的分隔标记。用---、###或者明确的标签都可以，目的是让模型能区分不同来源的信息，不会把它们混在一起理解。

我踩过的一个坑是：把检索到的多个文档块直接拼接，中间只加换行。结果模型经常把A文档的内容和B文档的内容混在一起回答。后来加了明确的分隔标记和来源标注，问题就解决了。

3. 输出层：模型吐出来的东西，离能用还差几步

3.1 输出层的核心任务是什么

输出层要解决的根本问题是：模型生成的内容是概率性的，但产品需要确定性的结果。

模型输出是一段文本，但你的下游系统可能需要一个JSON、一个枚举值、一个数据库记录、一个API调用。从自由文本到结构化结果，中间隔着输出层。

输出层的工作可以概括为四个字：约束、解析、校验、兜底。

约束是在生成时就引导模型按格式输出；解析是把文本转成程序能处理的结构；校验是检查结果是否符合业务规则；兜底是当一切失败时保证系统不崩溃。

3.2 结构化输出的三种实现路径

让模型输出结构化数据，有三条路可以走，各有优劣。

路径一：纯提示词约束。在提示词里写清楚要输出JSON，给出字段说明和示例。优点是实现简单，不依赖特定模型能力。缺点是模型不听话的时候会输出多余文字，解析容易失败。

路径二：函数调用或工具调用。利用模型平台提供的函数调用能力，让模型直接输出结构化的参数。优点是格式稳定，解析成功率高。缺点是依赖平台支持，灵活性受限于平台定义。

路径三：输出后解析加修复。不管模型输出什么，先用正则或解析器尝试提取结构化部分，失败的话再让模型重新格式化一次。优点是兼容性强，缺点是增加了一次调用，有延迟成本。

我自己的选择策略是：如果平台支持函数调用，优先用函数调用；如果不支持，用提示词约束加解析兜底。纯靠提示词约束而不做解析兜底，在生产环境里迟早出事。

3.3 输出校验的常见规则

模型输出即使格式正确，内容也不一定正确。输出校验要检查的东西包括：

• 字段完整性：该有的字段是不是都有
• 类型正确性：数字是不是数字，枚举值是不是在允许范围内
• 业务规则：比如金额不能为负，日期不能早于今天
• 一致性：多个字段之间有没有矛盾
• 安全过滤：有没有敏感内容、不当表述

这些校验规则最好做成可配置的，而不是硬编码在代码里。因为业务规则会变，硬编码的话每次改动都要发版。

注意：校验失败后的处理策略很重要。是直接返回错误，还是重试，还是降级到备用方案？我的建议是，关键业务路径一定要有降级方案。比如结构化输出失败时，降级为纯文本回答，至少保证用户能拿到东西。

3.4 多路投票与结果融合

对于同一个问题，让模型生成多次，然后投票选出最一致的结果，这是输出层提升稳定性的常用手段。特别适合分类、判断、抽取这类任务。

具体做法是：用相同的输入，但稍微不同的提示词或温度参数，让模型生成三到五次，然后对结果做多数投票。如果几次结果高度一致，说明模型比较确定；如果分歧很大，说明这个问题模型没把握，可以触发人工审核或降级处理。

成本上，多路投票意味着多倍调用，所以只适合对准确性要求高、对成本不敏感的场景。日常对话类应用没必要这么做。

结果融合是另一个思路。比如同时用检索结果和模型自身知识生成答案，然后把两个答案融合。或者同时用两个不同模型生成，取长补短。融合策略可以是简单的拼接，也可以是让模型自己判断哪个更好。

4. 模型层：什么时候才需要动发动机

4.1 模型层改动的真实成本

模型层的改动包括微调、蒸馏、量化、架构修改等。这些操作的共同特点是：成本高、周期长、门槛高。

微调一个模型，你需要准备高质量的训练数据，需要GPU资源，需要调参，需要评估。一套流程走下来，少则几天，多则几周。而且微调后的模型可能在某些任务上变好，在另一些任务上变差，需要仔细评估。

蒸馏和量化主要是为了降低推理成本，适合大规模部署的场景。如果只是做原型验证，完全没必要碰。

所以我的建议很直接：除非输入层和输出层都优化到极限了，否则不要轻易动模型层。大部分应用场景的问题，在输入输出层就能解决。

4.2 什么情况下才考虑微调

有三种情况，微调是值得考虑的：

第一，任务格式非常固定，且对延迟敏感。比如一个固定的信息抽取任务，每次都要从文本里抽同样的几个字段。用提示词也能做，但每次都要传一长串指令和示例，token消耗大、延迟高。微调之后，输入可以很短，输出直接就是结果。

第二，领域术语和表达方式非常特殊。通用模型在高度专业的领域（比如某些细分工程领域）可能表现不佳，因为训练数据里这类语料少。微调可以注入领域知识。

第三，需要模型学会一种很难用提示词描述的“风格”。比如特定的写作风格、特定的推理路径。提示词能描述的风格，尽量用提示词；描述不了的，才考虑微调。

4.3 模型选型的实用考量

选模型不是越大越好，也不是越新越好。要考虑的因素包括：

我的经验是：先用中等规模的模型做原型，验证流程跑通后，再根据实际瓶颈决定是升级模型还是优化输入输出。很多时候，优化输入输出带来的提升，比换一个更大的模型更明显，而且成本更低。

5. 三层架构的实战拆解案例

5.1 案例背景与需求描述

假设我们要做一个“合同关键信息抽取”的工具。输入是一份合同文本，输出是结构化的关键字段：合同双方、签订日期、合同金额、付款方式、违约条款摘要。

这个需求看起来简单，但实际做起来有很多细节。我们按三层架构来拆解。

5.2 输入层设计：怎么把合同喂给模型

合同文本通常很长，几千到几万字不等。直接全文塞进去，token消耗大，而且模型容易遗漏关键信息。

输入层的策略是：

第一步，文档预处理。把合同按章节切分，识别出“当事人信息”“合同金额”“付款条款”“违约责任”等关键章节。切分可以用规则匹配加模型判断结合的方式。

第二步，关键章节优先。把识别出的关键章节放在上下文的前面，其他章节放在后面作为补充。如果总长度超过窗口限制，优先保留关键章节。

第三步，提示词设计。提示词里明确列出要抽取的字段、每个字段的格式要求、以及找不到时的处理方式。

从下面的合同文本中抽取以下字段，以JSON格式输出： - party_a: 甲方名称，字符串 - party_b: 乙方名称，字符串 - sign_date: 签订日期，格式YYYY-MM-DD - amount: 合同金额，数字，单位元 - payment_method: 付款方式，字符串 - breach_summary: 违约条款摘要，不超过100字 如果某个字段在文本中找不到，值设为null。 只输出JSON，不要输出其他内容。 合同文本： {contract_text}

5.3 输出层设计：怎么保证抽取结果可用

模型输出的JSON不一定可靠。可能字段缺失，可能格式错误，可能金额单位不对。输出层要做几件事：

解析。用JSON解析器尝试解析模型输出。如果失败，用正则提取JSON部分再解析。再失败，触发重试。

校验。检查必填字段是否存在，日期格式是否正确，金额是否为正数。校验规则用配置表管理，方便调整。

归一化。把不同格式的日期统一成标准格式，把金额统一成数字，把付款方式映射到预定义的枚举值。

兜底。如果解析和校验都失败，返回一个标记为“需人工处理”的结果，而不是直接报错。

5.4 模型层在这个案例中的角色

这个案例中，模型层其实不需要做任何改动。选择一个通用能力较强的模型，配合好的输入输出设计，就能达到不错的效果。

如果发现某些字段的抽取准确率一直上不去，比如“违约条款摘要”总是抓不住重点，那可以考虑两个方向：一是优化输入层的提示词和示例，二是收集一批标注数据做微调。但后者是最后的选择。

6. 常见问题与排查技巧实录

6.1 模型不按格式输出怎么办

这是输出层最常见的问题。模型明明被要求输出JSON，却输出了一段解释文字加JSON。

排查思路：

• 检查提示词里的格式约束是否足够明确。不要只说“输出JSON”，要说“只输出JSON，不要有任何其他文字”。
• 检查示例是否展示了正确的格式。如果示例里带了多余文字，模型会模仿。
• 检查温度参数是否过高。温度越高，模型越自由，格式约束力越弱。结构化输出任务建议温度设0到0.3。
• 如果平台支持函数调用，改用函数调用方式，格式稳定性会好很多。

6.2 检索结果不相关怎么调

RAG场景下，检索出来的内容跟问题不相关，原因可能出在多个环节。

我的经验是，先看召回率，再看准确率。如果相关文档根本没被召回，后面排序再好也没用。召回率上去了，再用重排序提准确率。

6.3 上下文太长导致效果下降怎么办

上下文不是越长越好。太长的上下文会导致两个问题：一是成本高，二是模型注意力分散。

解决思路：

• 压缩。对检索到的文档做摘要，只保留关键信息。摘要可以用模型来做，也可以用规则提取。
• 筛选。只保留最相关的几个文档块，而不是全部塞进去。
• 分层。先让模型判断哪些信息相关，再针对相关信息做详细处理。
• 分步。把复杂任务拆成多个步骤，每一步只处理一部分信息。

实操心得：我做过一个对比测试，同一个问题，塞10个文档块和塞3个最相关的文档块，后者回答质量反而更高。信息过载是真实存在的问题。

6.4 模型回答不稳定怎么处理

同一个问题，模型每次回答不一样，这在需要确定性的场景下很头疼。

处理手段：

• 降低温度。温度设0，让模型每次选概率最高的词。但注意，即使温度设0，由于浮点计算和并行处理的差异，结果也可能有微小不同。
• 多路投票。生成多次，取多数一致的结果。
• 固定随机种子。如果平台支持，设置随机种子可以让结果可复现。
• 输出约束。把开放生成变成选择或填空，减少模型自由发挥的空间。

6.5 成本控制有哪些实用技巧

大模型调用成本是很多团队关心的问题。几个实用的省钱技巧：

缓存。相同或相似的输入，直接返回缓存结果。对于FAQ类场景，缓存命中率可以很高。

分级。简单问题用便宜的小模型，复杂问题才用大模型。可以先用小模型判断问题难度，再路由到不同模型。

压缩输入。精简提示词，去除不必要的示例和说明。输入token少了，成本自然降。

控制输出长度。在提示词里限制输出长度，避免模型长篇大论。

批量处理。如果有大量离线任务，可以批量调用，利用平台的批量折扣。

7. 三层架构的扩展思考

7.1 输入输出层的创新空间远大于模型层

模型层的创新门槛很高，需要大量资源。但输入输出层的创新门槛低得多，而且效果往往立竿见影。

我观察到一个现象：很多看起来“很AI”的产品，拆开来看，模型层用的是通用API，真正的差异化在输入输出层。比如更好的检索策略、更精细的输出控制、更流畅的多轮对话管理。这些才是产品竞争力的来源。

7.2 三层架构不是静态的

三层之间的边界会随着技术发展而变化。今天需要在输出层做的复杂后处理，明天可能模型原生就支持了。今天需要在输入层做的检索增强，明天可能模型的长上下文能力就覆盖了。

所以保持对三层架构的理解，但不要把它当成固定不变的教条。定期回顾自己的技术栈，看看哪些工作可以下沉到模型层，哪些可以上移到输入输出层。

7.3 给不同阶段开发者的建议

刚入门的人，先把输入层玩熟。提示词设计、上下文组装、简单的RAG，这些是基本功。不要一上来就想着微调。

有一定经验的人，重点打磨输出层。结构化输出、校验、兜底、多路投票，这些是生产环境和demo的分水岭。

资深开发者，可以关注模型层的优化，但前提是输入输出层已经没有明显瓶颈了。否则微调带来的提升，可能还不如优化一下提示词。

我个人在实际操作中的体会是，三层架构最大的价值不是技术上的，而是思维上的。它让你在面对一个新问题时，能快速定位到应该在哪一层发力，而不是盲目地试各种工具和框架。这个框架帮我省了很多时间，希望对你也有用。