企业官网建设流程全解析

做了这么多年AI项目，我越来越确定一件事：阻碍AI落地的，从来不是模型本身，而是围绕模型展开的四层架构。这个判断不是我拍脑袋总结的，而是这些年亲眼看过太多团队在模型上游刃有余、在下游寸步难行之后，得出来的结论。今天就把这套四层架构完整拆开聊一聊，适合正在做AI应用落地、做技术选型、或者准备把大模型接进业务的人参考。

很多人一提到AI项目，第一反应就是“选什么模型”“要不要微调”“能不能追上最新的榜单”。但真正做过落地项目的人都清楚，模型选型只是万里长征第一步。数据怎么来、效果怎么评估、服务怎么部署、并发怎么扛、用户怎么用、迭代怎么做，每一个环节都可能让项目卡死。这些环节组合起来，就是我说的四层架构。把这四层理顺了，模型哪怕不是最强的那一个，整体效果也能稳稳跑起来。

1. 四层架构的全局观：模型只是水面上的冰山

1.1 为什么真正卡住项目的不是模型

先讲一个我亲眼见过的真实案例。一个团队做大模型客服助手，模型用的是当时排名靠前的开源模型，demo阶段效果惊艳，给老板展示的时候全场鼓掌。结果一进入生产环境就傻眼了：真实用户的问题千奇百怪，文档里的专业术语模型根本没见过，回答错误率飙升到不可接受。团队第一反应是换更大的模型，换了之后确有改善，但成本翻了十倍，响应速度慢了一半，用户反而更不满意了。

问题出在哪里？出在数据层、工程层和应用层，模型只是背锅的。

模型能力再强，它也只能回答“它知道的”和“你能给它的”。没有经过清洗和组织的知识库，模型再大也是闭着眼睛瞎猜。服务部署不合理，再好的模型也扛不住真实流量。交互设计跟不上，用户连第二句话都不想问。这就像一个顶级厨师进了没有食材、没有灶具、菜单乱写的餐厅，你怪厨师厨艺不行，没有道理。

所以我想先建立一个认知：模型层在四层架构里，往往是投入产出比最高、但实际难度最低的一层。真正比拼功夫的，是那些看起来不起眼的“外围”工程。

1.2 四层架构到底在分什么

我一般把AI落地拆成四层：模型层、数据层、工程层、应用层。每层解决的问题完全不同，但层级之间有严格的依赖关系，低层出了问题，高层做得再漂亮也白搭。

这里的核心逻辑是：模型层决定“能不能”，数据层决定“准不准”，工程层决定“稳不稳”，应用层决定“爽不爽”。四个字全部打通，一个AI项目才算真正落地。很多人只盯着第一层，后面三层的坑一个接着一个踩，项目自然卡住。

2. 模型层：选型做对了，能省三分之二的力气

2.1 模型选型先看三个硬指标

模型层的核心不是“追最强”，而是“选合适”。我自己的选型框架是三个硬指标：效果、成本、速度。

效果不用多说，就是拿你的业务问题去实测，看回答质量。成本要分两部分算：如果是API调用，看按token计费的单价；如果是本地部署，看需要的GPU显存、服务器台数、电费和运维人力。速度则直接影响用户体验，很多场景下用户能接受的响应时间是3秒以内，超过5秒流失率飙升。

以文本生成任务为例，同样是做客服助手，如果业务知识集中在固定领域，一个70B左右的开源模型微调之后的效果，完全不输给数百B的商用模型，但推理成本可能低一个数量级。如果只是做标题润色、摘要生成这类轻量任务，一个7B或者8B的模型已经绰绰有余。反过来，如果要做复杂推理、代码生成，那就不能省，老实选能力更强的模型。

这里有一个很实用的建议：不要一开始就在大模型上纠结。先拿几个候选模型跑一批代表性测试用例，效果差距不明显的前提下，优先选成本低、速度快的小模型。等架构跑通了，模型随时可以换——四层架构设计得好，模型层是可以做成可插拔的。

2.2 Transformer之后的新选项：扩散模型、多模态模型

很多刚做AI落地的人，一听到模型就只想到ChatGPT那种对话式的大语言模型。实际上，模型家族已经分得很细了。文本生成任务，主流依然是基于Transformer架构的各类LLM，这类模型适合理解、生成、推理场景。图像生成、图像修复、视频生成任务，Diffusion（扩散）模型才是主角。代码生成和翻译等场景，则出现了大量针对代码优化的专用模型。

选型时要明确一个原则：任务决定模型，而不是模型决定任务。图像修复就用专门的图像修复模型，而不是拿着LLM硬生成。做语音识别就选语音模型，不要指望对话模型能准确转录专业术语。

另外，AI编程任务这几年很火，出现了像Claude Code这样的工具，本质上是把大模型、代码解析、函数调用封装成一个Agent。这提醒我们一件事：模型层的边界正在模糊，很多能力被封装进了工具和应用里。作为落地者，你要判断的是“自己需要掌控到哪一层”，而不是什么都要从零开始。

2.3 模型层最容易踩的坑

第一个坑是“唯排名论”。看到某个模型在榜单上分数高，就直接换掉当前模型，结果业务效果反而下降。因为榜单测试集和你的业务数据分布可能完全不同，必须用自己的数据做回归测试。我见过太多团队被榜单牵着走，每出一个新模型就重构一次应用，代价非常大。

第二个坑是“忽视上下文工程”。同样的模型，给它的上下文组织得好不好，效果差一大截。你在模型层把prompt写得再花哨，都不如把知识库数据组织清晰来得实在。这部分工作严格来说跨模型层和数据层，但从实操看，模型层的大部分调优工作都在这里完成。

第三个坑是“忽略模型的版本兼容”。很多开源模型和API接口会升级，你一个月前跑通的prompt和参数，升级后可能表现完全不一样。生产环境一定要固定模型版本，新版本先灰度，不要一次全量切换。

3. 数据与知识层：决定AI“聪不聪明”的真正战场

3.1 知识库建设是AI落地的“水电煤”

模型层解决的是“语言理解和生成能力”，数据层解决的是“领域知识和业务事实”。没有数据层，再强的模型也只是个说话很流畅的千层饼——言之无物。

大多数企业在做AI落地时，并不是要从零训练一个大模型，而是要把已有的业务知识喂给模型。这些业务知识可能散落在文档、数据库、表格、聊天记录里。数据层的核心任务，就是把散落的业务知识整理成模型能利用的结构化内容。

目前业界最主流的方式是RAG（检索增强生成）：先把文档切分成小块，用Embedding模型转成向量存入向量数据库，用户提问时先从数据库里检索出相关片段，再把片段拼进上下文一起喂给模型。这么做的好处是不用微调模型，新知识随时可以加，修改知识也不会影响模型的通用能力。

3.2 从数据清洗到RAG效果评估

数据层不是简单地把Word文档丢进向量数据库就完了。一套完整的链路是这样的：

第一，数据收集。先盘点所有业务相关的内容，包括产品文档、操作手册、FAQ、历史工单、竞品分析等等。没有数据，后面全部白搭。

第二，清洗。去掉页眉页脚、目录、重复段落、无关的广告信息。这一步最枯燥但最关键——脏数据进，脏结果出。

第三，切分。切分策略直接影响检索效果。切得太碎，每段没有足够上下文；切得太大，检索命中后占用大量token，成本高且可能引入噪声。实操中我的经验是：按章节结构切，每个片段的长度控制在300～800字左右，段落之间重叠20～50字，保证语义完整性。

第四，向量化。选择一个稳定且成本可控的Embedding模型，把文本转成向量。这里要注意，Embedding模型和主模型一样需要选型测试，不同语言、不同领域的向量化效果差异很大。

第五，检索和评估。建一个几十条到上百条的真实问题集，逐一测试检索结果是否命中关键信息、最终回答是否正确。这一步要反复迭代，每次修改切分策略或者清洗规则后都跑一遍回归测试。

3.3 数据飞轮：让数据层持续变强

很多团队的数据层是一次性工程，上线之后就不再更新。这是数据层最大的浪费。

正确做法是建立数据飞轮：把每一天用户问到但AI没有回答好的问题收集起来，定期补充进知识库。把用户的反馈（点踩、修改、追问）作为信号，筛选真正有价值的增量知识。

我之前做过一个项目，上线时知识库里只有几百条标准问答，效果勉强及格。跑了三个月之后，通过不断把新问题和人工修正后的答案补充进去，知识库扩到两千多条，这时候AI的表现已经能让业务部门主动加预算了。这不是模型变强了，是数据层变厚了。

数据层的另外一个隐藏价值，是它能反哺模型选型。数据组织得足够好，你会发现对模型能力的要求大幅降低。很多小模型在结构化优秀的知识库加持下，效果可以逼近大模型，这正是数据层最性感的地方。

4. 工程层：部署、性能与稳定性最藏坑

4.1 本地部署还是API调用，先把账算清楚

工程层的第一个决策，是模型跑在哪。很多技术负责人特别热衷于本地部署大模型，觉得数据安全、可控性强。但本地部署不是免费午餐，它意味着你要自己搞定GPU服务器、模型推理框架、并发优化、容灾备份和运维监控。

我先给一个比较中肯的判断依据：如果你的业务对延迟不敏感、数据合规要求极高、调用量足够大到摊薄硬件成本，本地部署值得做。反过来，如果你只是想快速验证业务，数据敏感度可控，调用量也不稳定，API调用明显更划算。我自己做过的项目里，最少有一半最后回到了API方案，因为省下来的运维人力和硬件费用，完全可以覆盖API支出。

如果确实要本地部署，以目前主流的开源模型生态来看，个人电脑或者单卡服务器能跑的基本是7B、14B、32B量级的量化模型。规模再大，就需要多卡甚至多机，复杂度会指数级上升。模型文件下载也是很多新手头疼的问题，建议找可信的模型托管渠道，用支持断点续传的下载工具拉取，相比浏览器直接下载靠谱得多。

4.2 性能参数调优的五个切入点

工程层的性能优化，不是跑个benchmark就完事，线上真实负载才是唯一标准。我一般从五个方面入手：

第一，上下文长度管理。上下文越长，占用的显存和计算资源越大。不要图省事把全量知识都塞进上下文，能用检索解决的，绝不靠堆长度。

第二，并发控制。大模型推理是计算密集型任务，并发过高会互相拖垮，过低又浪费GPU。一般先通过压测找到该硬件的“甜点并发”——通常是GPU显存利用率和响应延迟的平衡点。

第三，量化。把模型从FP16量化到INT8甚至INT4，显存占用大幅降低，推理速度提升，目标效果损失可控。但量化不是无代价的，对长文本和复杂推理场景，质量下降可能很明显，必须拿真实数据测试。

第四，KV Cache。Transformer模型推理时，历史token的计算结果会缓存下来。合理控制缓存大小、用PageAttention这类机制管理显存碎片，能显著提升吞吐。值得了解的是，如果用过JVM内存模型，会发现KV Cache的管理思路和堆内存回收有相似之处——都是有限资源下的分配与复用问题。

第五，入口队列与超时。AI接口的响应时间天然比普通接口长，一定要给调用方设置合理的超时时间，同时做排队处理，避免因为一次慢请求拖垮整个服务。

4.3 稳定性设计：给AI加护栏

稳定性设计是工程层最容易忽视的部分，但恰恰是决定项目能不能活下来的部分。

首先，大模型API不是100%可靠的，网络抖动、限流、服务商故障随时可能发生。调用层必须做超时控制、重试机制和熔断降级。我的惯用做法是：如果主模型超时，自动降级到备选小模型，再不行就返回预设的兜底文案。保证用户永远有响应，哪怕是“当前服务繁忙，请稍后再试”。

其次，成本控制是稳定性的一部分。大模型项目一旦流量上来，token费用可能呈指数级增长。一定要在网关层做限流和配额管理，给每个用户、每个部门设置每日调用上限。我之前有个项目差点失控，就是因为有内部工具在跑定时任务，一个月烧掉了几万块的token。

最后，日志和监控要尽量详尽。记录每次请求的输入、输出、耗时、token数、模型版本、命中知识片段，这样出现问题时才能快速回溯定位。没有日志的AI系统，等于裸奔。

5. 应用层：场景编排与Agent才是用户体验的胜负手

5.1 “能聊”和“好用”之间隔着产品设计

应用层是用户直接接触的界面，它的好坏直接决定用户对你所有技术投入的感知。很多团队在这里犯的错是：模型能对话，就直接上线聊天框。结果用户问得稍微复杂一点，回答就开始跑偏，体验非常糟糕。

真正好用的AI应用，交互上是有设计感的。比如客服系统，用户说完问题之后，先把意图分类，分到“退款咨询”就走退款流程，分到“产品咨询”就走产品问答。知识库命中率低的时候，主动引导用户换种方式提问，而不是硬着头皮给一个错得离谱的答案。这些交互逻辑，属于产品设计的活儿，但技术团队必须深度参与，因为只有你清楚模型和知识库的能力边界在哪里。

5.2 从单次调用到Agent工作流

“Agent”和技术热词里的“AI Agent”这两年特别火，本质是把AI从“你问我答”升级成“你能办事”。单次调用只能让模型输出一段文本，Agent则是让模型基于目标，自主规划步骤、调用工具、观察结果、调整策略，直到完成整个任务。

举一个实际场景：用户提交一张模糊的老照片，要求修复。单次调用就是让模型直接生成一张修复图，效果完全看运气。Agent工作流则可以拆成：先判断照片损伤类型，调图像修复模型做处理，再判断是否需要放大，最后做人脸增强。每一步都由Agent协调不同模型和工具来完成，效果确定性强得多。

构建Agent工作流的常见方案是Coze、Dify这类低代码平台，或者直接用LangGraph、AutoGen这类框架自行编排。团队有了需求，建议从低代码平台起步快速验证，业务稳定了再考虑自研编排框架。不要一上来就搞复杂的Agent框架，编排链条越长，排查问题越痛苦。

5.3 上线只是开始：评估体系和运营迭代

应用层上线只是开始，后续的评估和运营决定了项目能不能长期跑下去。

我强烈建议从一开始就建立一套效果评估集，包含几百条真实业务问题，每一条都标注标准答案或者评分指引。每次模型更新、知识库调整、提示词修改，都用这套评估集跑一遍，对比分数变化。没有评估体系，所有“我觉得更好了”都是错觉。

运营方面，要定期分析用户提问日志，找到高频但回答不好的问题，定向优化知识库或调整交互流程。还要留意那些你没预料到的“野路子”用法，它们往往意味着新的业务增长点。我见过一个团队本来做产品问答，结果用户天天在里面查内部报销制度，后来直接衍生出一个内部服务机器人项目，上线后好评率比原产品还高。

6. 实操回放：一个知识问答型AI应用的完整落地过程

6.1 场景与四层方案

用一个具体的例子，把四层架构串起来给大家看。背景是一家做智能硬件设备的公司，想要一个面向内部售后的AI问答助手，帮助客服人员快速查询设备故障处理流程、产品参数、常见问题。

• 模型层：选了一个支持中文较好的开源模型，量化到INT8部署在内部服务器上，后期备用API方案作为降级通道。
• 数据层：收集了产品说明书、历史故障工单、FAQ文档，清洗后按章节切分，向量化存入本地的向量数据库。
• 工程层：用容器化方式部署推理服务，设置超时5秒、并发上限8请求，配置了降级方案和完整日志链路。
• 应用层：做了一个简单的对话框，内置了问题分类引导和知识库未命中提示文案。

6.2 落地各层的关键配置

模型层最花时间的是量化验证。我们把原始FP16模型和INT8量化模型各跑了50个真实售后问题，对比回答质量，发现INT8在故障描述类问题上的准确率只下降了不到2%，但推理速度提升了一倍多，显存占用降低了近一半，果断采用INT8。如果准确率下降超过5%，我一般就不建议量化，性价比就不高了。

数据层的切分策略调了三轮。第一次按固定长度300字硬切，结果很多段落被切断，检索时命中内容不完整。第二次改成按章节标题先分大块，再对过长的大块按段落切，效果明显好很多。这里的关键心得是：切分一定要尊重文档原本的结构，标题级别越清晰，RAG的检索命中准度越好。

工程层最实用的一个配置是降级链。正常情况下走内部开源模型；如果内部服务响应超过3秒或者报错，立刻自动切换到API备用模型；如果API也超时，直接返回“暂时无法回答，请稍后再试”。这条降级链上线后，系统在最极端的情况下也没有出现过完全无响应的状况。

应用层我们借鉴了“意图分类前置”的思路，用户提问后先让模型判断属于产品咨询、故障维修、还是投诉建议，不同意图走不同的检索策略和提示词模板。这个小改动让最终回答的满意度提升了约三成，边际成本几乎为零。

6.3 上线后的三个意外

第一个意外：客服人员的关键词提问方式。很多人不用完整句子，直接输入“风扇异响”“电机不转”这种碎片化短语，原始的向量检索效果很差。后来我们加了一步：先用小模型把口语化短句补全成完整问题，再做知识库检索，问题迎刃而解。

第二个意外：生产环境设备的专业名词在通用向量模型里语义表示不够好。比如“霍尔传感器”“PID控制”这些词，通用Embedding模型理解有限。后来我们把维基百科和技术文档的术语解释作为补充知识，单独建立了一个术语表向量集合，检索时优先命中，效果显著提升。

第三个意外：流量洪峰比预想来得快。一次内部业务培训后，大量客服同时使用，服务器一度过载。幸好有降级链和限流策略，系统没有整体崩溃，但体验还是受了影响。我们已经开始规划负载均衡和横向扩容，这是工程层接下来要补的一课。

7. 常见问题速查与排查思路

7.1 回答质量差，怎么判断是哪一层的问题

这是被问到最多的问题。我提供一个简单的排查顺序：先看答案是否“有依据”，再看是否“表达流畅”。如果回答流畅但内容明显不对，大概率是数据层问题——知识库没命中、切分不合理或者检索策略有问题。如果回答本身就前言不搭后语、逻辑混乱，那才轮到模型层。

很多团队一遇到质量问题就想着换大模型，结果换完之后原本能答对的简单问题反而答错了。正确做法是：固定模型不变，先优化知识库的组织和检索策略，效果不达标再考虑换模型，换完之后必须回测全部测试集。

7.2 响应太慢、总是超时

响应慢的原因通常有三个：上下文太长导致计算量过大；并发太高互相挤占资源；没有开流式输出。很多AI应用快速响应的方法很简单——把输出改成流式，用户第一句话看到的时间能压缩到几百毫秒，体感上快了很多。

如果后端推理本身耗时太长，优先检查输入上下文有没有塞入多余内容。每次都把几万字的历史记录带进去，再快的GPU也扛不住。

7.3 显存不够怎么办

显存不够时的优先级应该是：先尝试量化（FP16到INT8），再缩小上下文长度，然后考虑换小尺寸模型，最后才上多卡。多卡推理的通信开销很大，小模型跑多卡往往得不偿失。如果显存只是差一点点，可以调整KV Cache策略，或者开启CPU offload，把一部分不常用的计算挪到内存里。

7.4 排查优先级速查表

这张表不是绝对真理，但它能帮你快速收敛问题，而不是每次出了问题都毫无头绪地瞎调。

我在实际项目里最大的体会是，给团队做AI培训的时候，所有人都在问模型，真正动手做的时候，所有坑都在模型之外。四层架构听起来像是一堆正确的废话，但真按这个框架去搭建项目、分配资源和排优先级，项目的推进节奏和成功率都会完全不一样。下次再遇到AI项目卡壳，先别急着怪模型，按四层架构逐层体检，你会发现问题往往藏在那个你一直没注意的地方。