企业官网建设流程全解析

这几年关于大模型、智能体的讨论几乎铺满了整个技术圈，但真正落到企业侧的时候，大家会发现一个尴尬的事实：拿现成的通用AI服务去处理实际业务，要么数据不敢往外送，要么回答跟业务对不上，要么月底拉出账单一看，成本比预期高出一个量级。于是越来越多的团队开始认真考虑一个问题：能不能自己搭一套专属的人工智能系统？

这篇文章我会把这类项目从需求梳理、架构设计，到关键技术选型，再到落地排障的完整过程，按我自己实际带项目时的思路从头到尾拆一遍。适合正在做技术预研的架构师、负责AI落地的项目经理，以及想搞清楚“企业级AI到底怎么搞”的技术管理者参考。内容比较长，但每一步都是可以直接照抄作业的。

1. 先想清楚：为什么企业需要一套“专属”AI系统

很多企业第一次接触大模型时，第一个念头都是“先用现成的API试一试”。这个思路没问题，但试完第二阶段就会冒出一堆绕不开的问题：需求评审会上业务部门提的“我们想要一个AI助手”，落地时几乎都会演变成数据能不能出去、回答能不能精准、发票能不能解释清楚、成本能不能控住这四件事。

1.1 通用AI服务的三个天花板

先说数据私密性。企业内部的合同、技术文档、客户资料、财务数据，这些内容只要上传到外部API，不管对方怎么承诺“不留存”，合规和风控的同事都会先跳起来。我见过不止一个项目卡在这个环节，POC阶段用外部API跑得风生水起，等到真正要接生产环境时，数据安全评估直接叫停。

第二个天花板是业务耦合度。通用模型的知识截止时间和训练语料，决定了它对你所在行业的理解是“泛泛的”。律师问它某个监管指引的最新条款，它可能还停留在两年前的版本；工程师问它某个内部系统的接口规范，它更是完全没概念。而企业真正需要的AI，是要跟内部流程、历史数据、业务规则深度咬合的，不是聊聊天就完事。

第三个天花板是成本不可控。大模型API按Token计费，看起来便宜，但真到了生产环境，每个会话动辄上千Token，一个月几十万次调用，账单会很难看。而且更麻烦的是，一旦业务量涨上去，成本线性增长，你没有任何手段去压一压。自建专属系统的核心动机之一，就是把这种“每调用一次都在流血”的模式，变成可预测、可优化的固定成本。

1.2 专属AI系统的四种常见形态

我梳理过十几个企业AI项目，发现“专属”最终落地的形态基本逃不出下面四类：

• 私有化推理部署：把开源基座模型部署在自己的服务器上，数据和推理不出内网，主要解决数据安全和调用成本问题。
• RAG知识库问答：通过检索增强生成的方式，让模型基于企业内部的文档、数据库内容做回答，解决“模型不懂企业知识”的问题。
• 模型微调：在开源基座模型上用企业自己的数据进行参数微调或全量微调，让模型本身的风格、能力、输出格式贴合业务场景。
• 智能体工作流：把大模型作为推理核心，串联工具调用、API调用、多步骤任务执行，解决“AI只能聊天不能干活”的问题。

这里要特别说明一点：这四个形态不是互斥的，现实中往往是组合使用。比如一个企业内部智能客服，可能是“私有化部署 + RAG + 会话型工作流”；一个行业垂直写作辅助系统，可能是“微调 + 私有化部署”。搞清楚自己属于哪种组合，后面所有选型才有判断基准。

2. 整体架构设计：从业务问题到技术分层

很多团队一上来就纠结“用哪个模型”，这是典型的选型过早。模型在整个系统里只是一个环节，排在她前面的，是你要解决什么业务问题、数据在哪儿、流程长什么样、谁在用、并发多大。架构设计的第一步不是画技术图，而是把业务问题拆明白。

2.1 先做业务问题拆解

我习惯用一个很简单的模板来收敛需求：输入是什么，输出是什么，中间要用到什么数据，谁来用，多久要结果。举个例子，假设要做一个“销售合同智能审查助手”，输入是合同PDF，输出是风险条款列表和修改建议，中间要调阅公司历史合同库和合规规则库，使用对象是法务和销售助理，期望响应时间是分钟级。

把这个模板填完，你会发现技术选型的问题瞬间清晰了：需要解析PDF，所以要有一个文档解析环节；需要匹配历史合同，所以要向量化存储和检索；需要给出专业建议，所以基座模型得具备法律文本理解能力；法务人员用，所以界面要做成对话式还是表单式，决定了前端工作量。

这一步很多技术团队容易跳过，直接套一个“通用ChatBot”的架子。等做完了才发现业务方要的根本不是聊天，是“我上传一份60页的合同，帮我标出第37页第2条的赔付比例和行业标准不一致”。没有前置业务拆解，系统做得再花哨，业务部门用两周就弃了。

2.2 五层技术架构

一套企业专属AI系统，从下往上我习惯分五层来看：

• 基础设施层：GPU服务器、容器编排、存储、网络，核心是算力怎么管。
• 数据层：结构化数据、非结构化文档、向量数据库、数据治理流程，核心是企业知识怎么变成模型能用的形式。
• 模型层：基座模型、微调管道、量化压缩、推理服务框架，核心是模型怎么跑起来、怎么调优。
• 编排层：提示词模板、工作流引擎、工具调用、记忆管理、权限控制，核心是模型怎么跟业务动作配合。
• 应用层：Web端/移动端/企业IM集成、管理后台、日志审计、评测工具，核心是用户怎么用、运营怎么管。

每一层都有独立的选型问题，但层与层之间又强相关。比如你选了一个70B参数的基座模型，基础设施层的GPU配置就得跟着上；你决定用RAG而不微调，数据层的清洗和分块策略就变成关键；业务方要求支持复杂多跳问答，编排层就得考虑智能体架构而不是简单的“检索-拼接-生成”。架构设计本质上是在这些约束里找平衡。

2.3 自建、混合还是托管

这里要区分一个概念：完全自建不代表所有组件都自己部署。实际上我见过的大多数项目都走“混合”路线——模型权重自己部署在私有云或内网，但监控体系、日志分析这类非核心模块直接用现成方案。

完全自建的优势是数据完全可控、定制空间大，但劣势在于需要一支懂模型部署、懂推理优化、懂GPU运维的团队，对大多数非科技企业来说，这支团队的成本远高于想象。完全托管则等于把“专属”重新交回给了服务商，跟最初的诉求背道而驰。

我的建议是：核心数据和核心模型必须自控，周边组件能用开源替代的就不自研。例如向量数据库用开源方案，推理框架用社区成熟的方案，模型监控先用开源日志系统配合自定义指标。把有限的工程资源集中在业务效果、知识库质量、评测体系这些真正影响最终体验的环节上，而不是浪费在“把某个开源组件再做一遍”上。

3. 关键技术选型详解

这一部分是整个项目里最容易吵起来的地方，也是最需要拿数据说话的环节。我不会给出“无脑选XX”的结论，而是把判断逻辑和主要选项摆出来，你看完可以根据自己的约束条件做决定。

3.1 模型基座选型

基座模型的选择决定了整个系统的能力天花板。当前开源社区可选的基座模型按参数量大致分三档：

• 7B到13B档：单卡可部署，推理速度快，适合简单问答、文本分类、格式转换等任务。
• 30B到40B档：需要2到4张卡，综合能力明显强于小模型，适合多数企业内部知识问答和文本处理场景。
• 70B及以上档：需要多卡甚至多节点，推理成本高，但复杂推理、长文档理解、代码生成等能力显著提升。

选型时最关键的不是“哪个模型更强”，而是“你的任务复杂度是否真的需要这么大参数量的模型”。我做过一个测试：让7B模型和70B模型同时做企业内部的规章制度问答，在知识都来自RAG检索片段的情况下，两者的回答准确率差距不到5个百分点，但推理延迟差了三倍，部署成本差了十几倍。

所以我的经验是：先拿一批真实业务问题，几个候选模型都跑一遍，对比回答质量、延迟、成本三个维度，再做决策。不要迷信排行榜分数，那个分数是用通用数据集测出来的，跟你业务场景的相关性有限。许可证合规也要注意，选开源模型时看清楚模型许可证是否允许商用，以及有没有衍生品开源要求，这块建议让法务尽早参与。

3.2 RAG和微调怎么选

“到底做RAG还是微调”是出现频率最高的争议点。我的判断标准非常简单：

• 如果目标是“让模型知道企业独有的知识”，比如规章制度、产品文档、合同条款，用RAG。
• 如果目标是“让模型改变表达风格、输出格式、推理习惯”，比如要求答案必须是五段式结构、必须引用法条编号、必须使用特定语气，用微调。
• 如果两个目标都有，先做RAG，把检索到的内容拼进上下文，再看效果是否满足；不满足再考虑微调。

为什么不推荐一上来就微调？因为微调的本质是改变模型的参数，而企业知识是高频更新的，今天微调进去的制度细则，下个月改了，你还得重新微调；RAG只需要更新文档库或向量库，几分钟就生效。另外，微调需要准备大量高质量的“输入-期望输出”对，这个数据准备成本往往被严重低估。我看过不少项目微调完确实学会了企业的语气风格，但一问到具体知识点反而更差，原因就是微调数据里夹杂了噪声。

当然RAG也有自己的毛病：检索质量上限决定了生成质量上限。如果向量检索从来就召回不到正确片段，模型再强也没用。所以实用的路线是：RAG优先，微调兜底，两者组合。

3.3 推理部署与算力配置

模型选完之后，紧接着就是让它跑起来。推理层面有几个关键技术点决定最终体验：

第一个是量化。把模型权重从FP16降到INT8或INT4，显存占用直接砍半甚至砍到四分之一。以某开源基座模型为例，一个70B模型在FP16下推理需要大约140GB显存，做INT4量化后只需要35GB左右，一张主流数据中心级显卡就能带起来。量化会带来少量精度损失，但对大多数知识问答场景来说几乎无感。

第二个是推理框架。不要把模型用原始的Transformers库直接部署，KPI会很惨。成熟方案的选择上，社区里最主流的做法是使用带连续批处理、PagedAttention、张量并行等优化的推理服务框架，吞吐量能比朴素实现提升数倍到数十倍。另外一个常见选项是以TensorRT为核心做深度优化的方案，首次构建引擎时间较长，但延迟表现极佳，适合对延迟极其敏感的在线场景。

第三个是GPU规格与数量规划。这里要算两笔账：一是显存容量至少要能装下量化后的模型权重加上约20%的KV Cache和运行时开销；二是吞吐量需求决定卡数。假设业务峰值是50并发,每次问答平均生成300个Token，目标单Token延迟不超过50毫秒，那么单张卡需要具备的生成吞吐能力就是300除以0.05再乘以50，折算下来的生成Token吞吐要求会远超单卡极限，常见做法是多卡做分布式推理并水平扩展副本。这个数字不需要算得很精确，但要能回答“为什么需要四张卡而不是两张”这个问题，否则采购审批都过不了。

3.4 向量数据库与检索链路

RAG系统的检索效果，一半在分块策略，一半在Embedding模型和向量数据库。先说Embedding模型，企业内部的文本往往带有大量专业术语，通用Embedding模型的效果并不理想。建议在真实业务语料上做一个小的检索评测集，拿几个候选Embedding模型跑一下召回率对比，再定选型。不要只看模型排行榜上的综合分数。

分块策略是另一个被低估的关键点。我见过最典型的失败案例：把一份200页的规章制度文档按固定长度切块，每块500个字符，结果大量上下文被切断，检索阶段召回了很多“半句话”，生成阶段自然答非所问。好的分块策略应该先按文档结构切分，比如按章节、按条款、按段落，再对过长段落做二次切分，同时保留段落级元数据（文档名、章节号、页码），这样既能保证语义完整，又能给大模型提供引用来源。

向量数据库的选型，主要看三点：是否支持过滤条件（例如按部门、按文档类型过滤），是否支持混合检索（向量检索+关键词检索），以及写入和查询的延迟是否满足业务要求。很多场景下不需要引入独立的向量数据库服务，直接使用带有向量索引能力的传统数据库也能胜任。我见过不少中小团队一开始就上一个独立的向量数据库组件，结果运维复杂度上去了，但业务查询量一天才几千次，完全是大炮打蚊子。选型的原则还是那句话：数据量、查询量、团队运维能力，三者匹配才是最优解。

3.5 智能体编排与工作流

当你发现业务方要的不只是“回答问题”，而是要“替我把事情办了”，这个时候就需要引入智能体编排。举一个真实场景：业务人员问“帮我查一下上季度华东区的销售额，并和去年同期做个对比，再生成一份摘要邮件”。这个任务不能靠单轮检索完成，它需要大模型按顺序拆解步骤：先调用内部BI接口拉数据、再检索历史报表、再套用摘要模板、最后生成邮件草稿。

智能体编排层要解决的问题包括：任务怎么拆解、工具怎么注册、上下文怎么管理、权限怎么控制、步骤失败怎么重试。市场上已有的开源编排框架普遍支持“工具调用+工作流定义”的模式，你可以把内部接口封装成工具，让模型在对话过程中自动选择调用。这里要特别强调权限控制，企业内部系统对接AI后，必须让模型只能调用它被授权调用的工具，并且在日志里完整记录每一次工具调用的入参和出参。否则一旦模型被恶意提示词诱导，去调用了不该调用的接口，后果会很严重。

4. 从0到1的实操过程：一个企业内部知识问答系统的落地记录

前面讲了选型逻辑，这一段我以“企业内部知识问答系统”为例，把完整落地过程按阶段拆开。这个案例我去年实际带过，业务方是一家中型制造企业，知识库里有几千份技术文档、操作规程和质量标准，希望让一线工程师用自然语言查询。

4.1 第一阶段：需求定义与可行性验证

这个阶段用一到两周时间，做两件事。

第一件事是把“AI问答”这个模糊概念，变成具体的用户故事。我们拉了一线工程师做访谈，发现他们最想解决的痛点不是“找不到文档”，而是“找到了但不知道哪一份是当前有效版本”。这就变成了一条很清晰的产品要求：回答必须标注信息来源和文档版本号。这个发现直接影响后RAG阶段的元数据设计。

第二件事是拿几十条真实问题做模型能力摸底。我们选了三个候选基座模型，用同样的提示词模板跑一遍，让业务方盲评回答质量。摸底的结果是：13B模型在短句检索类问题上完全够用，但在涉及多条件筛选的问题上经常漏条件；而更大参数的模型在大幅提升准确率的同时，也带来了更长的首Token延迟。结合并发预期和成本预算，我们最终在架构讨论中确定以量化后的中等规模模型作为主推理模型，并在检索链路优化上投入更多资源，而不是盲目上超大杯。

4.2 第二阶段：数据治理与知识库构建

数据治理是最不性感的环节，但效果好不好全看它。我们做的第一件事是盘点文档现状：很多文档散落在个人电脑和FTP服务器里，格式五花八门，PDF有扫描版也有文字版，Word文档普遍没有规范的标题层级。

处理流程是这样的：先做格式归一化，扫描版PDF优先做OCR，文字版PDF和Word统一转成纯文本；然后做文档清理，去掉页眉页脚、目录页、表格里无效重复的内容；最后做结构化解析，按文档的自带层级切成段落块，没层级的按语义段落切。每个切好的块都写上元数据：所属文档编号、章节路径、版本号、生效日期、责任部门。

这里有一个花钱买教训的点：千万不要忽略版本问题。我们第一批导入的知识库里混入了五年前已经废止的质量标准文档，上线第二天就有工程师反馈问答结果跟现行规程矛盾。后来我们加了“当前生效版本”过滤字段，检索时强制只召回最新版本，问题才算解决。

4.3 第三阶段：RAG链路搭建与调优

知识库建好后，我一般分三步来调链路。

第一步是做召回质量评测。准备一百条问题-答案对，每条问题标注了它应该命中的文档片段。先跑一遍Embedding检索，算召回率。我们第一版召回率只有百分之六十多，检查后发现很多问题是关键词型，比如“某某设备的最大转速是多少”，Embedding检索对这类精确数字型问题匹配不好。解决办法是把检索模式改成“向量召回+关键词召回并行”，再做结果融合。这之后召回率提上了百分之八十。

第二步是重排序环节。召回Top 20个片段，全部塞给大模型会让上下文太长且噪声太多。我们接入了一个轻量级的跨编码器重排序模型，对召回片段按相关性重新打分，只取Top 5送到生成环节。这一步把生成答案的准确率又拉高了几个点。重排序模型的计算量比较大，但好在只需要处理召回后的少量片段，延迟可控。

第三步是提示词工程与生成策略。提示词不是随便写几句“你是一个助手”就完事的。我们最终的提示词里包含了：系统角色定义、回答风格要求、引用来源格式要求、知识库片段内容、检索不到时的拒绝策略。特别是“检索不到时怎么办”，很多系统在这里翻车——片段里没有对应答案，模型就开始自由发挥编造。我们在提示词里明确要求：如果片段中不包含答案，必须直接说“知识库中没有找到相关信息”，禁止推测性作答。

4.4 第四阶段：评测体系与持续迭代

评测是专属AI系统跟通用AI服务最大的区别。你既然投入了成本自建，就要有能力回答“它到底好不好”这个问题。

我们搭了一套半自动评测机制：每周从真实用户会话里抽取新增的问题，加上历史沉淀的回归问题集，组成约三百条的评测集；每次修改提示词、更换模型版本或调整分块参数，都全量跑一遍评测集，对比回答质量评分。评分方式分为自动指标和人工抽查，自动指标主要看检索召回率、答案是否包含引用、响应时间是否达标；人工抽查则每月抽五十条，由业务专家评估答案的准确性和可用性。

持续迭代最重要的原则是：每次只改一个变量。我最开始测试时经常同时调整提示词和分块大小，结果效果变好了也不知道是哪一步的功劳。后来改成A/B对比，一次只动一个变量，记录清楚前后指标变化，迭代效率明显提升。这套评测体系累计用了大半年，帮我们避免了一次模型升级导致的全面回退——新版模型在通用能力上更强，但在我们特定术语理解上反而退步了，因为没有评测集兜底差点直接上生产。

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

最后这部分把我在多个项目里反复踩过的坑集中整理一下，看到类似症状可以直接照着排查。

5.1 模型“一本正经胡说八道”怎么治

这是最常见的投诉，现象是回答语气很自信，但内容跟事实对不上。多数情况下问题出在检索环节而不是生成环节。排查顺序是：先看召回片段里有没有正确答案；如果有，说明生成时没把片段用好，需要调整提示词，要求严格基于片段作答；如果召回片段里就没有正确答案，说明知识库里缺内容或者分块切得不对，那就需要回到数据层补内容。

如果这两种都排除了，模型仍然在凭空生成，还有一个容易被忽略的原因：部分量化推理配置下模型能力下降明显，幻觉率上升。遇到这种情况，对比一下未量化和量化后的回答，如果差异明显，说明质量问题出在推理优化环节。

5.2 检索召回不准

单纯按向量相似度检索，经常出现语义相近但指向错误的情况。比如问“发票报销流程”，召回片段里全是差旅报销的内容，因为“发票”和“报销”在语义空间里离得太近。我的建议是不要在向量检索一棵树上吊死，加上关键词过滤和规则优先：如果问题里包含“发票”这个业务词汇，先按标签过滤到发票相关文档，再做向量排序。这种简单规则往往比花哨的检索策略更有效。

分块粒度过细也会导致召回片段能回答不全面。设想某个问题的答案分散在两个片段里，每个片段都被召回了，但重排序只给了其中一个高分，另一个被丢掉，生成结果自然缺了一半。排查时会发现“把Top 5改成Top 8”之后准确率突然提升，就是这个原因。

5.3 显存不足与推理延迟超标

部署初期最容易报OOM。第一件事确认量化是否生效；第二件事检查KV Cache分配，很多框架默认给每请求预留很大的KV Cache空间，并发一高就爆显存，需要根据任务特性调整最大生成Token数以及KV Cache复用策略。

延迟超标则要先明确是首Token延迟还是完整生成延迟。首Token延迟高，通常是模型权重加载和预填充计算太慢，优先排查是否开启连续的预填充调度；完整生成延迟高，通常是生成阶段每步解码太慢，优先考虑量化精度、批处理大小和GPU规格。还有一个常见问题：把并发请求直接打到同一个推理实例上，没有做消息队列削峰，高峰期延迟直接翻倍。

5.4 团队能力与项目节奏

技术问题反而好解决，更常见的是团队能力跟不上项目进度。一个专属AI系统需要至少三类角色：懂模型和推理的算法工程师、懂系统集成和数据的后端工程师、懂产品设计和业务洞察的行业专家。很多企业只有后端开发，硬着头皮去啃模型部署，结果两个月过去连推理性能都没调好。

我比较推荐的做法是：起步阶段砍掉非核心需求，把范围限到“一个场景、一条链路、一个闭环”，比如就做“设备故障知识问答”这一件事。团队可以一边学一边做，等闭环链路稳定了，再往多场景扩展。不要试图一次性覆盖公司所有知识域，那会让知识库质量、评测集、权限模型全部失控，项目大概率烂尾。这个节奏问题比任何技术选型都更影响成败。

最后分享一点个人体会

做了这么多企业AI项目，最大的感受是：技术选型永远不是最难的部分，最难的是让业务方、管理层、算法团队和数据团队在同一个认知层面上对话。所谓“搭建专属人工智能系统”，本质上不是搞一个大模型就完事了，而是把数据、模型、流程、组织能力全部重新梳理一遍。我个人习惯是先跑一个最小闭环，哪怕效果糙一点，让业务方真实用起来，拿到真实反馈后再定义第二期需求。这个思路比一开始就追求“完美方案”要靠谱得多，至少在踩坑的时候，你踩的是自己挖的小坑，而不是替整个团队挖的大坑。