企业官网建设流程全解析

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

先把结论摆在最前面：不管市面上冒出多少新名词——Agent、RAG、Function Calling、多模态、工作流编排——把它们全部拆开看，本质上都落在三个位置上：输入层怎么组织、模型层怎么选、输出层怎么处理。这三层构成了我所说的“大模型三层架构”。

我做过不少AI应用落地的项目，从最早的简单API调用，到后来的知识库问答、智能体编排、多轮对话系统，踩过的坑不算少。回头看，真正决定一个AI应用好不好用的，往往不是模型本身有多强，而是你在输入层和输出层做了多少功夫。模型层反而是最“标准化”的一层——选一个合适的基座，调好参数，基本就那样了。

这个三层架构的核心逻辑是这样的：

• 输入层：决定你给模型“喂”什么。包括提示词设计、上下文组装、知识检索、历史对话管理、工具描述注入等。
• 模型层：决定用哪个模型、怎么调、要不要微调、推理参数怎么设。
• 输出层：决定拿到模型返回的原始文本之后怎么处理。包括格式解析、结构化提取、校验重试、后处理、多路融合等。

为什么我要强调这个拆法？因为很多刚入行的朋友一上来就盯着“用哪个模型”这个问题，觉得换个更强的模型就能解决一切。实测下来完全不是这么回事。同一个模型，输入层做得好和做得差，输出质量能差出好几个档次。输出层加不加校验和重试，线上故障率能差一个数量级。

一个我反复验证过的经验：在一个AI应用里，模型层的工作量大概占20%，输入层和输出层加起来占80%。但大部分人把80%的精力花在了那20%上。

这套架构的适用面非常广。你做的是企业知识库问答也好，智能客服也好，代码助手也好，甚至是用大模型做数据抽取、做内容审核、做报告生成，拆开来看都是这三层。区别只在于每层的具体实现方式不同。

下面我逐层拆开讲，把每一层的核心细节、实操要点、常见坑都过一遍。

2. 输入层：决定模型上限的关键战场

2.1 输入层到底包含哪些东西

很多人对“输入”的理解就是“写个prompt”。这太窄了。在实际项目里，输入层至少包含以下几个部分：

系统提示词（System Prompt）：定义模型的角色、行为边界、输出规范。这是最顶层的设计，决定了模型“是谁”。

上下文组装：把用户问题、检索到的知识片段、历史对话、工具描述等信息拼装成一个完整的输入序列。这里涉及拼接顺序、截断策略、优先级排序等问题。

知识检索（RAG）：如果应用需要基于外部知识回答，检索环节的质量直接决定输入质量。检索做不好，后面全白搭。

对话历史管理：多轮对话场景下，保留哪些历史、丢弃哪些历史、怎么压缩，都是需要设计的。

少样本示例（Few-shot）：在提示词里放几个输入输出示例，引导模型按预期格式回答。

工具/函数描述：如果模型需要调用外部工具，工具的名称、参数、描述怎么写在提示词里，直接影响模型能否正确调用。

这六个部分合在一起，才是完整的“输入层”。任何一个环节出问题，最终输出都会受影响。

2.2 系统提示词的设计原则

系统提示词是输入层的地基。我见过太多项目，系统提示词写得含糊不清，然后抱怨模型“不听话”。其实问题出在自己身上。

写系统提示词，我总结了几条实操原则：

第一条：角色定义要具体，不要泛泛而谈。“你是一个有用的助手”这种话等于没说。要具体到场景，比如“你是一个面向电商客服场景的问答助手，只回答退换货、物流、支付相关的问题，其他问题一律引导用户联系人工客服”。

第二条：输出格式要明确，最好给示例。如果你需要模型返回JSON，不要只说“请返回JSON格式”，而是直接给出JSON的结构模板。模型对结构化示例的遵循度远高于纯文字描述。

第三条：边界要写清楚。什么能做、什么不能做、遇到不确定的情况怎么处理，这些都要在系统提示词里明确。否则模型会“自由发挥”，在你不希望的场景下给出不该给的回答。

第四条：长度要控制。系统提示词不是越长越好。过长的系统提示词会占用宝贵的上下文窗口，而且可能让模型“迷失”在大量指令中。我的经验是，核心指令控制在500-1500字之间，复杂场景可以到2000字，但再长就要考虑拆分了。

实操心得：系统提示词写完之后，拿10-20个典型问题测一遍，看看模型是否按预期行为。如果发现偏差，优先改提示词，而不是换模型。

2.3 上下文组装的顺序与截断策略

上下文组装看起来简单——把东西拼起来就行——但实际上有很多讲究。

拼接顺序通常遵循这个优先级：系统提示词 > 工具描述 > 少样本示例 > 检索知识 > 对话历史 > 用户当前问题。为什么这么排？因为模型对靠近输入末尾的内容注意力更强（这是Transformer架构的特性决定的），所以用户当前问题放在最后，确保模型“记得住”。

截断策略是另一个关键点。当所有内容加起来超过模型的上下文窗口时，你必须决定丢弃什么。常见的策略有：

• 优先保留系统提示词和用户当前问题，丢弃最早的历史对话。
• 对检索知识做重排序，只保留最相关的Top-K片段。
• 对长历史对话做摘要压缩，用摘要替代原始对话。

我一般会做一个“token预算表”，给每个部分分配固定的token上限，超出就按策略截断。这样能保证输入永远不会溢出，也不会因为某一部分过长而挤掉其他重要信息。

2.4 知识检索的质量决定一切

RAG（检索增强生成）是输入层里技术含量最高的部分。很多人以为RAG就是“把文档切块、存向量库、搜相似度”，但实际做起来远不止这么简单。

切块策略是第一道关。切太大，检索到的片段包含太多无关信息，干扰模型；切太小，可能丢失上下文，导致片段含义不完整。我的经验是，中文文档切块大小在300-500字之间比较合适，同时要设置10%-20%的重叠区域，避免关键信息被切断。

检索方式也不能只靠向量相似度。纯向量检索在语义匹配上表现好，但对精确关键词匹配（比如产品型号、专有名词）可能不够。我通常会用“向量检索+关键词检索”的混合方案，两路结果做融合排序。

重排序是提升检索质量的关键一步。初步检索召回Top-20片段后，用一个重排序模型（可以是小模型，也可以是交叉编码器）对这20个片段做精细打分，只取Top-3到Top-5注入上下文。这一步能显著减少无关信息对模型的干扰。

踩过的坑：早期做RAG时我直接拿向量检索的Top-5塞给模型，结果经常出现模型被无关片段“带偏”的情况。加了重排序之后，回答准确率提升了将近30%。

2.5 对话历史管理的取舍

多轮对话是很多AI应用的核心场景，但对话历史不能无限增长。我的做法是分层管理：

• 最近3轮对话：保留完整原文，确保短期上下文连贯。
• 3轮之前的对话：用模型生成摘要，压缩成一段简短描述。
• 超过10轮的对话：只保留摘要和关键实体信息（如用户提到的订单号、产品名等）。

这样既控制了token消耗，又不会让模型“失忆”。摘要的生成可以用便宜的小模型来做，成本很低。

3. 模型层：选型、调参与微调的决策框架

3.1 模型选型的核心考量维度

模型层是三层架构里最“标准化”的一层，但选型仍然需要认真对待。我通常从以下几个维度来评估：

能力维度：模型在目标场景下的表现。比如做代码生成就看代码能力，做中文问答就看中文理解能力。不要只看榜单分数，要拿自己的实际数据测。

成本维度：包括API调用成本（按token计费）和自部署成本（GPU资源）。这两者的平衡点取决于你的调用量。调用量小的时候用API更划算，调用量大了自部署可能更省。

延迟维度：首token延迟和整体生成延迟。对于实时交互场景（如客服对话），延迟要求高；对于离线批处理场景（如批量文档摘要），延迟要求低。

上下文窗口：决定了你一次能输入多少内容。做长文档分析就需要大窗口模型，做简单问答小窗口就够。

可控性：是否支持微调、是否支持结构化输出、是否有内容审核机制等。

3.2 推理参数怎么调才合理

模型推理时有一堆参数可以调：temperature、top_p、top_k、max_tokens、frequency_penalty、presence_penalty等。很多人要么全用默认值，要么乱调一通。我来说说每个参数的实际影响和推荐设置。

temperature：控制输出的随机性。值越高输出越多样，值越低输出越确定。做事实性问答时设0-0.3，做创意写作时设0.7-1.0。我一般默认设0.1-0.3，保证输出稳定。

top_p：核采样，控制候选词的范围。通常和temperature二选一调，不要同时大改。默认0.9-0.95比较稳妥。

max_tokens：最大输出长度。设太小会导致回答被截断，设太大浪费资源。根据场景预估，一般设512-2048之间。

frequency_penalty和presence_penalty：控制重复。做长文本生成时适当加一点（0.1-0.5），做短回答时保持0。

实操心得：调参这件事，先固定其他参数，只调一个，观察效果变化。不要一次改好几个参数，否则出了问题都不知道是哪个引起的。

3.3 什么时候该考虑微调

微调不是万能药。我见过很多团队一上来就想微调，结果发现效果还不如好好写提示词。我的判断标准是：

该微调的信号：

• 提示词已经优化到极限，效果仍然不达标。
• 需要模型学习特定的输出格式或风格，且少样本示例无法稳定实现。
• 有大量高质量标注数据（至少几百到几千条）。
• 需要压缩模型体积（用大模型蒸馏到小模型）。

不该微调的信号：

• 只是想让模型“知道”一些新知识——用RAG更合适。
• 标注数据不足或质量不高——微调反而会让模型变差。
• 需求还在频繁变化——微调一次成本不低，需求变了就白费。

微调的技术路线选择上，LoRA和QLoRA是目前最实用的方案，对显存要求低，训练速度快，效果也能接受。全量微调只有在数据量很大、效果要求极高时才考虑。

3.4 模型层的容灾与降级设计

线上系统不能只依赖一个模型。我的做法是至少配置两级降级：

• 主模型：能力最强，负责处理大部分请求。
• 备用模型：能力稍弱但更稳定或更便宜，主模型超时或报错时接管。
• 兜底策略：所有模型都不可用时，返回预设的兜底回复，而不是让用户看到错误页面。

这套机制在模型服务出现波动时特别管用。我经历过几次模型API临时不可用的情况，因为有降级设计，用户基本无感知。

4. 输出层：最容易被忽视但最影响体验的一环

4.1 输出层要解决的核心问题

模型返回的是原始文本，但你的应用需要的是结构化、可校验、可用的数据。这中间的差距，就是输出层要填补的。

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

格式解析：模型返回的可能是JSON、Markdown、纯文本，甚至是混合格式。你需要稳定地从中提取出需要的信息。

结构校验：解析出来的数据是否符合预期结构？字段是否齐全？类型是否正确？

内容校验：内容是否合规？是否包含敏感信息？是否偏离了预期主题？

失败重试：解析失败或校验不通过时，怎么处理？重试？降级？还是返回错误？

后处理：对模型输出做进一步加工，比如格式化、翻译、拼接、去重等。

这一层做得好不好，直接决定了用户体验。模型偶尔“胡说八道”不可怕，可怕的是你把它的“胡说八道”直接展示给了用户。

4.2 结构化输出的可靠实现方案

让模型输出JSON是常见需求，但模型经常会在JSON外面包一层解释文字，或者漏掉字段，或者格式出错。我的应对方案是：

第一层：提示词约束。在系统提示词里明确给出JSON schema，并强调“只返回JSON，不要有任何其他文字”。

第二层：解析容错。写一个健壮的解析器，能处理常见的格式偏差。比如用正则提取第一个{到最后一个}之间的内容，再尝试解析。

第三层：校验重试。解析成功后校验字段完整性和类型正确性。不通过则把错误信息拼回提示词，让模型重新生成。重试最多2-3次。

第四层：兜底默认值。重试仍然失败时，返回一个预设的默认结构，并记录日志供后续分析。

import json import re def parse_model_output(raw_text, schema, max_retries=3): for attempt in range(max_retries): # 尝试提取JSON match = re.search(r'\{.*\}', raw_text, re.DOTALL) if not match: raw_text = retry_generation(raw_text, "未找到JSON结构") continue try: data = json.loads(match.group()) except json.JSONDecodeError as e: raw_text = retry_generation(raw_text, f"JSON解析失败: {e}") continue # 校验字段 missing = [k for k in schema if k not in data] if missing: raw_text = retry_generation(raw_text, f"缺少字段: {missing}") continue return data return get_default_output(schema)

这段代码是我在实际项目中反复打磨出来的，核心思路就是“提取-解析-校验-重试”四步循环。你可以直接拿去改改用。

4.3 输出内容的质量把关

格式对了不代表内容对了。输出层还需要做内容层面的把关：

敏感信息过滤：检查输出是否包含手机号、身份证号、银行卡号等敏感信息，有则脱敏或拦截。

主题偏离检测：判断输出是否偏离了预期主题。简单做法是用关键词匹配，复杂做法是用另一个模型做判别。

事实一致性校验：如果应用场景对事实准确性要求高，可以把输出和检索到的知识做比对，检查是否有矛盾。

长度控制：输出过长时截断，过短时补充或重试。

这些检查不需要每个都做，根据你的场景选择。但敏感信息过滤我建议所有面向用户的应用都加上，这是底线。

4.4 流式输出的处理技巧

很多应用需要流式输出（逐字显示），提升用户体验。但流式输出给输出层带来了额外挑战：你拿到的是不完整的文本片段，无法直接做JSON解析。

我的处理方式是“边收边缓存，收完再解析”。具体来说：

• 流式阶段：只做简单的文本展示，不做结构化解析。
• 流结束：拿到完整文本后，再走正常的解析校验流程。
• 如果需要流式展示结构化数据：可以设计一种“流式友好的格式”，比如每行一个JSON对象（JSONL），收到一行就解析一行。

注意：流式输出时如果中途出错，已经展示给用户的内容无法撤回。所以流式场景下要格外注意内容审核的前置化——能在输入层拦住的，不要等到输出层。

4.5 多路输出的融合策略

有些场景下，你可能会让模型生成多个候选输出，然后选最好的一个。或者用多个模型分别生成，再做融合。这就是输出层的“多路融合”。

常见的融合策略有：

• 投票法：多个输出中取多数一致的结果。适合分类、选择题等有确定答案的场景。
• 打分法：用一个评分模型给每个输出打分，取最高分。适合生成类场景。
• 拼接法：把多个输出的优点拼在一起。适合摘要、报告生成等场景。
• 交叉验证法：用一个输出去验证另一个输出的事实性。适合对准确性要求极高的场景。

多路融合的代价是成本翻倍，所以只在对质量要求极高的场景下使用。

5. 三层架构的联动与常见问题排查

5.1 三层之间的信息流与反馈闭环

三层不是孤立的，它们之间存在信息流动和反馈闭环。

输入层的问题会导致模型层“巧妇难为无米之炊”——检索不到相关知识，模型再强也答不对。模型层的问题会导致输出层“垃圾进垃圾出”——模型生成的内容本身就有问题，后处理再厉害也救不回来。输出层的问题会导致“最后一公里”失败——内容都对，但格式错了、校验没过，用户还是用不了。

我习惯在每层都埋监控点：

• 输入层：记录每次请求的token消耗、检索命中率、上下文截断情况。
• 模型层：记录延迟、错误率、token生成速度。
• 输出层：记录解析成功率、校验通过率、重试次数。

这些数据汇总起来，就能快速定位问题出在哪一层。比如解析成功率突然下降，那大概率是模型输出格式变了，需要检查是不是模型版本更新了，或者提示词被改动了。

5.2 常见问题速查表

这张表是我在实际运维中慢慢积累出来的，基本上覆盖了80%的常见问题。遇到问题时先查表，能省不少时间。

5.3 性能优化的几个实用手段

三层架构的性能优化，我通常从这几个地方入手：

输入层优化：压缩系统提示词、减少不必要的少样本示例、对检索结果做更严格的筛选。输入token少了，推理速度自然快。

模型层优化：用推理加速框架（如vLLM、TensorRT-LLM）、开启量化（INT8/INT4）、使用KV Cache复用。这些手段能显著降低延迟。

输出层优化：解析和校验逻辑尽量轻量，避免在关键路径上做复杂计算。重试逻辑要设上限，避免无限循环。

缓存策略：对高频相同或相似请求做缓存。输入层可以做语义缓存（相似问题命中同一缓存），输出层可以做结果缓存。

一个容易被忽视的优化点：把输出层的校验逻辑做成异步的。先返回结果给用户，校验在后台跑，发现问题再异步修正或告警。这样用户感知的延迟会低很多。

5.4 从三层架构看AI应用开发的岗位需求

聊到这里，顺便说说AI应用开发这个岗位。现在市面上招AI应用开发工程师的团队越来越多，但要求差异很大。

有的岗位其实只是“调API”——把模型接口封装一下，做个简单的对话界面。这种岗位技术含量不高，可替代性强。

有的岗位则要求全栈能力——既要懂输入层的提示词工程和RAG，又要懂模型层的选型和调参，还要懂输出层的工程化处理。这种岗位才是真正有价值的。

我的建议是，不管你现在做的是哪一层，都要把三层都摸一遍。只懂提示词的人容易被替代，只懂模型部署的人路会越走越窄。三层都懂的人，才能独立负责一个AI应用的完整落地。

学习路线上，我建议按这个顺序：先搞懂输入层的提示词设计和RAG，这是最容易上手也最见效果的；然后了解模型层的基本原理和选型逻辑；最后深入输出层的工程化处理，这是区分“demo”和“产品”的关键。

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

做AI应用落地这段时间，最大的感受是：模型能力是天花板，但工程能力决定你离天花板有多近。同一个模型，在不同团队手里做出来的产品，体验可以天差地别。差距不在模型本身，而在三层架构的每一层细节里。

输入层里，一个精心设计的系统提示词能让模型表现提升一个档次。输出层里，一个健壮的解析重试机制能让线上故障率降低一个数量级。这些都是“脏活累活”，但恰恰是这些活决定了产品的可用性。

另一个体会是：不要追求一步到位。我见过太多团队想一开始就把三层都做到完美，结果迟迟上不了线。正确的做法是先跑通最小闭环——输入层用最简单的提示词，模型层用API调用，输出层直接展示原始文本——然后根据实际反馈逐步优化每一层。

最后分享一个小技巧：每次优化只改一层的一个点，改完立刻用同一批测试用例验证效果。这样你才能清楚地知道每个改动带来了多少提升。同时改多个地方，效果好了不知道是哪个起了作用，效果差了也不知道是哪个拖了后腿。

这套三层架构的拆法，我在多个项目里反复验证过，不管是做知识库问答、智能客服、内容生成还是数据分析，都能套用。希望对你有所启发。