企业官网建设流程全解析

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

很多人第一次接触大模型应用开发，看到满屏的新概念——RAG、Agent、Function Calling、思维链、结构化输出、多模态——会觉得这是几十个互不相关的技术方向，每个都得单独学。但实际做过几个项目之后你会发现，这些东西翻来覆去就在解决两个问题：往模型里塞什么，以及拿到模型吐出来的东西之后怎么处理。

我把它总结成一个三层架构：输入层、模型层、输出层。模型层是底座，你基本动不了（除非做微调）；真正决定一个AI产品好不好用的，几乎全在输入层和输出层。市面上那些让人眼前一亮的新花样，拆到根上，要么是在输入端做了文章，要么是在输出端做了文章，或者两头都做。

这个框架的好处是：当你再看到一个没见过的新概念时，不用慌，先问自己——它是在改输入，还是在改输出？大部分情况下，答案立刻就清楚了。这篇文章我会把三层架构逐层拆开，讲清楚每层的核心逻辑、常见技术方案、实操中的关键参数，以及我自己踩过的坑。适合正在做AI应用开发但被各种概念绕晕的工程师，也适合想理解大模型产品底层逻辑的产品经理。

2. 输入层：决定模型能看到什么

2.1 输入层的本质是信息压缩与编排

大模型的上下文窗口是有限的。不管你用的是8K、32K还是128K的模型，塞进去的信息量总有上限。输入层要做的核心事情就是：在有限的窗口里，放进去最能让模型给出正确答案的信息。

这件事听起来简单，做起来极难。因为“什么信息最有用”这个问题，在没有看到模型输出之前，你很难100%确定。所以输入层的设计本质上是一个信息检索和编排的问题，它跟传统搜索引擎的思路有相似之处，但多了几个关键约束：

• 模型对信息的位置敏感。同样一段关键信息，放在上下文开头、中间、结尾，模型利用它的效果可能完全不同。业界有个说法叫“迷失在中间”（Lost in the Middle），指的是模型对上下文中间部分的信息利用率明显低于开头和结尾。
• 模型对信息的格式敏感。结构化的表格、带标记的段落、纯自然语言，模型的理解效果差异很大。
• 模型对信息的冗余度敏感。重复信息不一定有害，但会挤占窗口空间；信息太少又可能导致模型缺乏推理依据。

所以输入层设计的核心权衡是：在窗口限制下，最大化有效信息密度。

2.2 从Prompt Engineering到Context Engineering

早期大家聊的是Prompt Engineering——怎么把一句话写好。现在更准确的说法是Context Engineering——怎么把一整个上下文组装好。这个转变背后是应用复杂度的提升。

一个典型的输入层组装流程大概长这样：

1. 系统指令：定义模型的角色、行为边界、输出格式要求。这部分通常放在最前面，且在所有请求中保持一致。
2. 检索到的知识：从向量数据库、搜索引擎、文件系统中召回的相关内容。这部分是动态的，每次请求可能不同。
3. 对话历史：多轮对话中之前的交互记录。需要做截断或摘要处理，否则会无限增长。
4. 用户当前输入：本次请求的原始问题或指令。
5. 格式示例：如果需要模型输出特定格式，通常在这里给几个示例（Few-shot）。

这五部分的排列顺序、各自占多少token、用什么分隔符隔开，都会影响最终效果。我实测下来，系统指令放在最前面、用户输入放在最后面、检索内容夹在中间，是一个比较稳妥的默认方案。但如果检索内容特别关键，可以考虑在用户输入之后再重复一次关键片段——代价是消耗更多token。

2.3 检索增强生成（RAG）在输入层的位置

RAG是输入层最核心的技术之一。它的逻辑是：模型本身的知识不够用或者不够新，那就从外部知识库里检索相关内容，塞进上下文里让模型参考。

RAG的实操中有几个关键决策点：

切块策略。文档不能整篇塞进去，必须切成小块。切多大？按什么切？常见的做法是按语义段落切，每块300-800个token，块与块之间留10%-20%的重叠。重叠的目的是防止一个完整语义被切断后，两块都检索不到。但重叠太多会浪费存储和检索时间。

检索方式。向量检索（语义相似度）和关键词检索（BM25等）各有优劣。向量检索擅长捕捉语义相近但用词不同的情况，关键词检索擅长精确匹配专有名词。实践中常用混合检索，两路召回后做融合排序。

重排序。初步检索回来的结果可能不够精准，用一个小的重排序模型对候选结果重新打分，取Top-N塞进上下文。这一步对最终效果提升很明显，但会增加延迟。

上下文组装。检索回来的多个块怎么拼？直接拼接是最简单的，但可能引入矛盾信息。更好的做法是给每个块加上来源标记，让模型知道信息出处，便于它在矛盾时做判断。

注意：RAG的效果上限取决于检索质量，而不是模型能力。检索不到正确信息，再强的模型也答不对。所以做RAG项目时，把70%的精力花在检索优化上，30%花在生成优化上，这个分配比例比较合理。

2.4 输入层的常见误区

第一个误区是塞得越多越好。实际上，无关信息会干扰模型判断，降低回答质量。我做过对比测试，同样的问题，塞入10个相关块和塞入3个高度相关块，后者的回答准确率反而更高。

第二个误区是忽略token成本。输入token是按量计费的，塞入大量无关内容不仅降低质量，还增加成本。一个优化良好的输入层，应该在保证质量的前提下尽量精简。

第三个误区是系统指令写得太长太细。有些开发者把系统指令写成几千字的行为规范，结果模型反而抓不住重点。系统指令应该简洁、明确、可执行，把详细规则放到示例里去体现。

3. 模型层：底座能力与微调边界

3.1 模型层能改什么、不能改什么

模型层是三层架构里最“重”的一层。训练一个基础模型需要海量数据、大量算力和专业团队，这不是普通开发者能碰的。但模型层并非完全不可动，有几条路径可以影响模型行为：

• 微调：用领域数据对模型做继续训练，改变模型的权重。成本较高，但效果最彻底。
• LoRA等参数高效微调：只训练一小部分参数，成本大幅降低，效果接近全量微调。
• 提示词工程：严格来说这属于输入层，但它直接影响模型层的输出，所以放在一起讨论。
• 模型选择：不同模型在不同任务上的表现差异很大，选对模型本身就是一种优化。

我的经验是：先穷尽输入层和输出层的优化手段，再考虑微调。很多团队一上来就想微调，结果发现把提示词写好、把检索做好之后，效果已经够用了。微调应该是最后的手段，而不是第一选择。

3.2 模型选型的实操考量

选模型不是选“最强”的，而是选“最合适”的。几个关键维度：

我踩过的一个坑是：只看榜单选了某个“最强”模型，结果在实际业务场景中，它的表现还不如一个中等模型。原因是榜单测试的任务类型和我们的业务差异太大。后来我们建立了一套自己的评测集，用真实业务数据做对比，选出来的模型才真正靠谱。

3.3 微调的正确打开方式

如果确实需要微调，有几个关键点：

数据质量远比数量重要。1000条高质量标注数据，效果可能好过10000条噪声数据。数据要覆盖真实场景中的各种情况，包括边界情况和容易出错的case。

明确微调目标。是想让模型学会特定格式的输出？还是想让它掌握领域知识？还是想改变它的语气风格？不同目标对应不同的数据构造方式和训练策略。

做好基线对比。微调之前，先用提示词工程+少样本学习做一个基线。微调之后，跟基线对比，确认提升确实来自微调而不是其他因素。

注意灾难性遗忘。微调可能让模型在通用能力上退化。如果业务场景既需要领域能力又需要通用能力，可以考虑用LoRA做轻量微调，或者保留一个通用模型作为兜底。

4. 输出层：从原始文本到可用结果

4.1 输出层为什么被严重低估

大部分教程讲到大模型应用，重点都在输入层和模型层，输出层往往一笔带过。但实际做产品时，输出层的工作量可能占到整个项目的40%以上。

原因很简单：模型输出的是自然语言文本，而下游系统需要的是结构化数据、可执行操作、或者符合特定格式的内容。这个“翻译”过程就是输出层的核心工作。

输出层要解决的问题包括：

• 格式约束：让模型输出JSON、XML、Markdown表格等结构化格式。
• 内容校验：检查输出是否包含幻觉、是否违反安全规则、是否符合业务逻辑。
• 后处理：对输出做清洗、补全、转换，使其能被下游系统消费。
• 多轮编排：如果一个任务需要多次调用模型，输出层要负责串联这些调用。

4.2 结构化输出的实现方案

让模型输出JSON是最常见的需求。实现方式有几种：

方案一：提示词约束。在系统指令里明确要求输出JSON格式，并给出schema示例。这是最简单的方式，但可靠性一般，模型偶尔会输出多余的解释文字。

方案二：JSON模式。部分模型API支持强制JSON输出，开启后模型只会输出合法JSON。可靠性大幅提升，但灵活性受限。

方案三：Function Calling。把输出格式定义为一个函数调用，模型会按照函数参数schema输出。这种方式可靠性高，且支持复杂的嵌套结构。

方案四：输出后解析+重试。先让模型自由输出，然后用解析器提取结构化信息。如果解析失败，把错误信息反馈给模型让它重新输出。这种方式最灵活，但需要处理重试逻辑。

我通常的组合是：JSON模式 + 输出后校验 + 失败重试。JSON模式保证大部分情况下格式正确，输出后校验检查内容合法性，失败重试处理少数异常情况。

4.3 输出校验与幻觉抑制

模型输出的内容不一定正确，这是大模型的固有特性。输出层的校验环节要尽可能拦截错误信息。

常见的校验手段：

• 事实性校验：把输出中的关键事实与知识库比对，不一致的标记出来。
• 逻辑校验：检查输出是否符合业务规则，比如金额是否在合理范围、日期是否合法。
• 引用校验：如果要求模型引用来源，检查引用的来源是否真实存在。
• 安全校验：检查输出是否包含敏感信息、是否违反内容政策。

校验发现问题后，处理方式有几种：直接拒绝返回、返回但标记警告、触发重新生成、降级到人工处理。选择哪种方式取决于业务对准确率的要求和容错能力。

提示：不要试图100%消除幻觉。当前技术条件下，这做不到。更务实的做法是建立分层处理机制：高置信度的直接返回，中置信度的加提示返回，低置信度的转人工或拒绝。

4.4 输出层的进阶玩法

除了基本的格式化和校验，输出层还有一些进阶玩法：

思维链后处理。让模型先输出推理过程再输出结论，然后从输出中提取结论部分。推理过程可以用于调试和审计，结论部分用于下游消费。

多候选生成与投票。同一个问题让模型生成多个答案，然后通过投票或打分选出最佳答案。这种方式能提升准确率，但成本翻倍。

流式输出与增量处理。模型边生成边输出，下游系统可以增量处理，降低感知延迟。适合对话类、写作类场景。

输出缓存。对于相同或相似的输入，缓存模型输出，避免重复调用。需要注意缓存的失效策略，因为模型版本更新后旧缓存可能不再适用。

5. 三层架构的协同与实战拆解

5.1 一个完整案例的逐层分析

假设我们要做一个“合同关键信息提取”的功能。输入是一份合同文本，输出是结构化的关键字段（甲方、乙方、金额、期限等）。

输入层设计：合同文本可能很长，不能整篇塞进去。先做切块，然后针对每个要提取的字段，检索最相关的段落。比如提取“金额”时，检索包含金额相关表述的段落。同时，在系统指令中明确输出格式和字段定义。

模型层选择：这个任务需要较强的指令遵循能力和结构化输出能力。选择一个支持JSON模式的中等规模模型即可，不需要最强的推理模型。成本可控，延迟也低。

输出层设计：模型输出JSON后，做字段校验。金额字段检查是否为数字、是否在合理范围；日期字段检查格式是否合法；甲乙方名称检查是否为空。校验失败的字段标记出来，触发针对性重试或人工复核。

这个案例中，输入层的检索质量决定了模型能否看到正确信息，输出层的校验决定了最终结果的可靠性。模型层反而是一个相对标准化的选择。

5.2 三层之间的反馈循环

三层架构不是单向的，而是一个循环系统。输出层的校验结果可以反馈到输入层，优化检索策略；模型层的表现可以反馈到输入层，调整提示词；输出层的错误案例可以积累起来，用于后续的微调数据。

我习惯在项目初期就建立一套日志系统，记录每次调用的输入、输出、校验结果、人工反馈。这些数据是后续优化的基础。没有数据，优化就是拍脑袋。

5.3 不同场景下的架构侧重

不同应用场景对三层的侧重完全不同：

这个表格不是绝对的，但能帮你快速定位当前项目的优化重点。如果你做的是知识问答，输入层的检索优化优先级最高；如果你做的是内容生成，输出层的格式和安全处理可能更关键。

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

6.1 输入层常见问题

问题：检索到的内容明明包含答案，模型却说不知道。

排查思路：先检查检索内容是否真的塞进了上下文。有时候检索到了但组装时被截断了。再检查检索内容在上下文中的位置，如果在中间部分，尝试移到开头或结尾。还可以检查系统指令是否过于严格，导致模型不敢使用检索内容。

问题：多轮对话中模型忘记之前的约定。

排查思路：检查对话历史是否被正确保留。有些框架会自动截断历史，可能把关键约定截掉了。解决方案是把关键约定放到系统指令里，而不是依赖对话历史。

6.2 输出层常见问题

问题：模型输出的JSON格式不稳定，偶尔多出解释文字。

排查思路：开启JSON模式或Function Calling。如果模型不支持，在提示词中强调“只输出JSON，不要任何其他文字”，并给出严格的示例。还可以在输出后加一个解析步骤，自动提取JSON部分。

问题：模型输出内容正确但格式不符合下游要求。

排查思路：在系统指令中给出明确的格式示例，包括字段名、数据类型、嵌套结构。如果格式复杂，考虑用Function Calling定义schema。输出后加一个格式转换层，把模型输出映射到下游需要的格式。

6.3 跨层问题

问题：整体延迟太高。

排查思路：分层定位。输入层看检索和组装的耗时，模型层看首token时间和生成速度，输出层看校验和后处理的耗时。常见优化手段包括：检索结果缓存、流式输出、并行校验、模型降级。

问题：成本超出预期。

排查思路：统计各层的token消耗。输入层通常是消耗大头，检查是否有冗余信息。输出层如果做了多候选生成，成本会翻倍。模型层可以考虑用更小的模型处理简单请求，复杂请求才用大模型。

6.4 我的避坑清单

• 不要在没有评测集的情况下优化。拍脑袋调参，越调越乱。
• 不要忽略日志。出了问题没有日志，排查全靠猜。
• 不要一次性改多个变量。每次只改一个，确认效果后再改下一个。
• 不要迷信“最佳实践”。别人的最佳实践在你的场景下可能不适用。
• 不要等到项目后期才考虑输出层。输出层的复杂度往往被低估，早期就要设计好。

7. 一些实操中的个人体会

做了一段时间大模型应用之后，我最大的体会是：这个领域变化很快，但底层逻辑变化很慢。新的模型、新的框架、新的工具层出不穷，但输入层的信息编排、模型层的能力边界、输出层的格式校验，这些核心问题一直没变。

另一个体会是：工程能力比算法能力更重要。大部分应用场景不需要你发明新算法，而是需要你把现有的技术组件合理地组装起来，处理好各种边界情况和异常流程。一个设计良好的输入层和输出层，能让中等模型发挥出接近顶级模型的效果。

最后分享一个小技巧：当你面对一个复杂需求不知道从何下手时，先把它拆成“输入是什么、输出是什么、中间需要模型做什么”三个问题。回答完这三个问题，技术方案基本就清晰了。这个思考框架帮我省了很多纠结的时间。