企业官网建设流程全解析

1. 先拆这个命题：为什么“RAG 产品”会走向“AI 基础设施”

如果把时间拨回这两年，大模型刚开始进入企业视野时，绝大多数团队的第一个动作就是做“知识库问答”。原因很简单：RAG（检索增强生成）刚好解决了大模型最要命的两个短板——幻觉和知识过时。企业文档一堆，内部系统一堆，“喂给大模型”这件事天然就有需求。

但做深了就会发现，一个 RAG 产品并不只是“向量检索 + 大模型对话”那么简单。它背后牵着文档解析、权限体系、数据更新链路、模型路由、成本核算、效果评估、安全审计……当企业里两三个部门同时要上 AI 能力时，每个部门自己搭一套 RAG，就是标准的重复造轮子。那时候你不得不思考：我到底是在买一个 RAG 产品，还是在建设企业的 AI 基础设施？

这个标题想说的核心其实是：大多数企业真正需要的不是“自建平台”，而是“用成熟产品解决业务问题”。不是说自建不行，而是说大多数企业没有那个必要，也没有那个条件。这篇文章我会从成本、技术构成、失败案例、落地路径几个角度，把这件事拆开讲清楚，适合正在做技术选型、负责 AI 落地决策的人参考。

2. RAG 的真实门槛：Demo 跑通不等于产品可用

2.1 为什么 RAG 成了企业 AI 落地最普遍的入口

先聊个基础问题：RAG 为什么这么火？因为它用一种“低成本、可解释、可干预”的方式补足了大模型的短板。模型不知道你公司内部有哪些制度流程，但你的文档里都有；模型会一本正经地胡说八道，但如果你把检索到的原文段落放进 prompt 里约束它“只能依据以下内容回答”，胡说八道的概率会大幅下降。

典型的使用场景一只手数不过来：内部制度问答、客服知识库、合同条款查询、研发代码检索、审计合规辅助、销售话术推荐。每个场景的底层逻辑一致：先检索，再生成。所以 RAG 成了大多数企业尝试 AI 的第一个应用形态。

但这里有一个容易被忽略的转折点。第一版 Demo 往往只证明“技术可行”，不证明“业务可用”。我见过太多团队拿着上传三个 PDF 的 Demo 去汇报，老板看完说“挺好，上线吧”，然后才发现：真实文档格式乱七八糟，有的是扫描件，有的是表格套表格，有的长达数百页；权限规则复杂到同一个人在不同部门能看的内容都不一样；文档每星期都在更新，却没人知道什么时候该重新摄入。

所以做 Demo 的时候，你面对的是一个精心挑选的、干净的数据子集；做产品的时候，你面对的是企业数据的真实混乱。这个鸿沟，是很多 RAG 项目从“演示成功”到“落地失败”的第一站。

2.2 从单点应用到底座：平台化的必然性

当一个业务部门做 RAG 时，它只是一个业务流程；当三个业务部门同时要做时，你发现每个人都在接模型 API、都在设计自己的知识库、都在调 embedding 参数、都在各自写一套权限逻辑。这时候“AI 基础设施”的概念就出现了。

AI 基础设施不是指 GPU 集群或者私有化大模型。对于绝大多数企业而言，它指的是供多个业务复用的公共能力层。具体拆下来包含几个模块：

• 模型接入与路由：统一封装不同模型、不同版本，支持按业务切换和成本控制；
• 知识库服务：文档处理、分块、向量化、存储、更新的标准流水线；
• 检索编排：混合检索、重排序、查询改写、多路召回这些通用逻辑；
• 统一权限与审计：对接企业现有身份体系，做到数据级权限隔离；
• 可观测与评估：链路追踪、调用日志、效果指标、成本分摊。

这就像盖楼。每个业务部门如果各自挖一口井，资源浪费是小事，取水的质量还不一样。而建设“供水管网”的人需要懂的是工程化的东西：水压怎么保证、管道怎么维护、不同楼层的需求怎么满足。把 RAG 产品升级为 AI 基础设施，本质上就是从“给一个业务做工具”变成“给整个组织做底座”。这句话听起来大气，但代价也大——它要求企业具备持续投入的平台工程能力。

3. 自建之前，先把这笔经济账算清楚

3.1 自建平台的真实成本构成

很多企业做自建决策时，只算了两笔账：服务器费用和 API 调用费用。这是最大的误区。自建一个企业级 AI 平台，成本大头根本不是硬件，而是人。

以一个最小的自建团队为例，想做正经的 AI 基础设施平台，至少需要：一名资深 AI 应用工程师负责检索方案和模型调优，一名数据工程师负责文档处理和数据管道，一名后端工程师负责权限、接口和稳定性，再加一名偏运维的工程师管部署、监控和成本。这四个人是起步款，不是高配。按照当前市场薪酬水平，每人年成本 60 万到 80 万是保守估算，一年的硬成本就是 240 万到 320 万。

这还没算 GPU。如果做私有化部署，即便用开源模型，也需要至少一台像样的训练/推理设备；如果走 API 模式，单次调用成本看起来不贵，但企业级并发的月账单通常远超预期。加上向量数据库集群、对象存储、带宽、备份这些基础设施费用，一年 30 万到 50 万属于常规水平。

隐性成本更不容忽视：安全审计流程要重新走一遍；合规部门要审查数据出境风险和权限模型；出了问题没有供应商可以背锅，全部自行消化。我见过最典型的情况是：某个团队花了半年时间自建平台，最后平台确实跑起来了，但业务部门等不了，早就花钱买了外部的 SaaS 工具用上了。自建团队反过来成了内部最清闲的人。

3.2 用决策矩阵判断你该不该自建

与其凭感觉拍板，不如用一个评分表过一遍。每个维度 1 到 5 分打分，加起来看结果。

总分 6 到 12 分，坚决别自建，直接买成熟产品；13 到 20 分，可以选择性自研部分组件，但整体还是以采购为主；21 分以上，才到了认真考虑自建平台的区间。这个打分表不是科学定论，但它能帮团队把决策从“老板拍脑袋”变成“基于事实的讨论”。

补充一个判断逻辑：你的竞争优势在“平台层”还是在“业务层”？如果你是一家本身就以数据处理和算法见长的公司，平台是核心资产；如果你是一家做业务的公司，比如做制造、做零售、做金融服务，你的竞争力来自业务流程、行业知识、客户关系，平台自建并不会让你更快地服务客户。这时候把平台工作外包给成熟产品，把精力放在业务场景上，反而是更理性的选择。

3.3 为什么“买”不等于“失去控制力”

很多人拒绝采购的原因是怕被厂商锁定，怕数据不安全，怕定制需求没人响应。真实情况是，大多数成熟的企业级产品都支持私有化部署、开源社区版本和 API 方式对接，数据主权问题并不会因为采购而自动失去。反而是自建团队如果只依赖一两个核心工程师，整个系统的可持续性风险更高。

另一个常被误解的点是：采购产品后，你的团队并不是无事可做。集成、二次开发、效果评估、业务推广、反馈闭环，这些工作一样不少。你省下来的，是那些“别人已经做好而你也不会做得更好”的部分——比如文档解析器的精度、多租户权限的成熟度、大规模检索的稳定性。用业内常说的一句话：不要重复发明轮子，除非你确定你的轮子比别人的圆。大多数企业并没有能力做出更圆的轮子。

4. 企业 AI 基础设施的五大组成模块拆解

4.1 模型层：不止是接一个 API Key

很多企业做 RAG 时以为模型层就是申请一个 API Key，调通接口就完事。真正到平台层面，模型层要解决的问题复杂得多。

首先是模型路由问题。同一个业务场景，可能今天是基础对话模型，明天换成了更强的推理模型，后天为了降本切换成蒸馏小模型。平台需要在请求层面做到无缝切换，现在的策略可能是“普通问题走便宜模型、复杂问题走强模型”。如果没有统一网关，每改一次模型都要改业务代码，那后面全是维护噩梦。

其次是成本控制。一次 RAG 请求，消耗的 token 不只是答案本身，还包括检索到的上下文、系统提示词、历史对话。一条 500 字的回答可能背后消耗了 3000 甚至 5000 token。没有平台级的用量统计和配额管理，月底账单出来的时候财务会找上门。

再一个是提示词和上下文窗口管理。业务方不需要关心到底怎么把检索结果拼进 prompt，平台层应该封装好这些策略。固定模板、动态排版、超长上下文截断，这些都是基础设施的能力。我的建议是：模型层必须做统一抽象，业务方通过接口调用，不允许业务代码里直接硬编码模型品牌和提示词模板。这样才能保证后续升级模型不影响业务。

4.2 知识层：RAG 成败的 80% 在这里

知识库是整个 RAG 链条里最“脏活累活重”的部分，谁做谁知道。

第一个环节是文档解析。真实世界的文档远不止 PDF 和 Word。扫描件要过 OCR，复杂表格要还原结构，PPT 里的信息可能藏在备注里，Excel 多 sheet 要分别处理，HTML 页面要去除导航噪音。开源的解析库对付简单 PDF 没问题，但面对企业级文档时，解析的准确率直接决定后续检索的天花板。那句话说得很对：垃圾进，垃圾出。

第二个环节是分块策略。Chunk 大小没有标准答案：切太大，语义完整但检索定位不精确，容易把无关内容带进上下文；切太小的，细节清晰但语义破碎，经常出现在库里有答案却检索不到的情况。经验做法是 300 到 800 token 为一个块，同时设置 10% 到 20% 的重叠，并且对标题进行结构化拆分，用“父块存储、子块检索”的方式兼顾精度和上下文完整性。

第三个环节是 embedding 和检索策略。现在普遍的做法不是单纯向量检索，而是“混合检索”：向量召回 + 关键词匹配（BM25）并行，再用重排序模型（Reranker）对召回结果精排。为什么混合？因为向量检索擅长语义相似，但对精确的数字、物料编码、人名这些模糊得很；而关键词检索反着来。两者合并后，首响准确率能明显上一个台阶。这个组合方式在当前阶段是经过大量验证的稳健方案。

第四个环节是权限隔离。企业知识库最怕的是权限旁路：员工问 AI“帮我查找 XX 部门薪资制度”，AI 从向量库里检索出来了，但这个人根本没权限看这份文档。平台层的知识库服务必须做数据级权限过滤，即“检索阶段就按用户身份过滤掉无权访问的内容”，而不是生成之后再去拦。这个能力在自建时工作量不小，因为它要求文档在导入阶段就同步好权限标签，并且在每次检索时把权限矩阵带进查询里。

4.3 评估与可观测层：没有度量就没有迭代

RAG 做得怎么样，不能靠“感觉回答得还行”来衡量。平台层需要一套评估维度。业内常用三件套：检索命中率，答案忠实度，整体相关性。命中率看的是正确的知识到底有没有被召回；忠实度看的是答案是否只基于检索内容、有没有编造；相关性则是用户视角的综合满意度。

要做到可评估，必须有链路追踪：一个完整的 RAG 请求，经过了哪些环节、每个环节耗时多少、用了哪个模型、检索到了哪些文档、最终生成了什么答案，全部要能查到。不然出了问题无从排查，更不可能持续优化。这就像做后端服务必须有日志一样，AI 应用也不能例外。

可观测层还有一个容易忽略的功能：成本分摊。按部门、按应用标记 token 消耗和检索量，月底能给每个业务部门出账单。这一点在实操中特别实用——当业务部门知道 AI 调用要算成本的时候，他们提需求会克制很多，也不会出现“拿大模型聊天工具来做正式业务流程”这种资源浪费。

4.4 安全与治理层：合规要求的落地抓手

企业级 AI 平台区别于个人 Demo 的另一个关键点就是安全治理。数据安全不仅是技术需求，更是合规底线。核心动作包括：全链路的数据加密（传输中、存储中均需加密）；敏感信息识别与脱敏（身份证、手机号、银行卡号等字段在进入知识库前做检测；日志中不落明文）；完整的操作审计（谁在什么时候问了什么问题、系统返回了什么内容，需要留痕可查）。

多租户隔离也是治理层的常见需求。不同部门的数据要物理或逻辑隔离，防止跨租户越权访问。自建平台时，安全团队大概率会提出一堆要求，每条要求都对应人力投入；而成熟产品通常已经把这些能力内置了，这也是采购的一大隐形优势。

5. 大多数企业自建平台失败的真实原因

5.1 把“部署了开源组件”当成了“建成了平台”

我见过不少团队做的事情本质上是：用容器编排工具把开源组件部署上去，加个负载均衡和一个简单的前端界面，就宣布自建 AI 平台完成。但真正的平台工程不是部署，而是运营。

开源组件部署上去了，版本更新谁来做？集群扩容怎么规划？凌晨两点检索服务飙高延迟，有没有值班接警？向量数据库的备份策略是什么？模型升级后历史 embedding 需要重算吗？这些问题如果没人长期负责，平台就不是资产，而是负债。打个比方：买了毛坯房不等于有家，还得装修、通水电、搞物业。容器化部署解决的是“跑起来”的问题，平台化解决的是“长期稳定跑”的问题。两者的工作量差一个数量级。

5.2 低估了数据治理的时间占比

自建 AI 平台推进到知识库建设阶段，不少团队会卡在数据治理上。企业文档分散在个人电脑、共享网盘、OA 系统、业务数据库里，格式五花八门，更新版本混乱，多份文档互相矛盾，权限体系本身就理不清。做 RAG 之前，这些历史问题一直存在，只是没人关心；RAG 把这些问题暴露出来了。

一个容易被忽略的现实：数据准备阶段的工作量通常占总项目的 70% 到 80%，算法和模型只占小头。自建团队如果没有专职的数据工程师，用业务同学业余时间兼职整理数据，项目大概率会延期。采购成熟产品时，因为产品自带各类文档解析器和连接器，这部分工作量能压缩不少。

5.3 技术先行，业务价值没有跟上

有的团队立项之初就把重心放在“建平台”上，花了大半年把血缘关系、模型网关、多人权限都做完了，但具体业务场景还没想清楚。结果是平台功能一堆，没有核心应用跑在上面；没有业务量，就没有真实反馈，就没有迭代动力，项目进入死循环。

正确的节奏应该是反向的：先从一两个高价值场景切入，用最简单的方式跑通业务闭环，验证有真实收益，再逐步抽象公共能力，最终形成平台。一句行业里的老话：平台是被动沉淀出来的，不是主动规划出来的。先有应用，再有平台，平台才会有人用。

6. 不建平台，企业应该怎么落地：一条务实的路径

6.1 第一步：用成熟产品跑通第一个业务场景

既然确定不自建平台，第一步就是选择成熟 RAG 产品做业务落地。选择产品时，不要只看宣传页的功能列表，要拿真实业务数据做 POC 测试。准备一个测试集，包含三类文档：干净的文本 PDF、复杂的带表格文档、扫描图片。考察四个能力：

• 解析能力：能不能完整提取表格结构和图文信息；
• 检索能力：能否在混合检索下准确找到对应内容；
• 权限能力：是否支持对接企业身份体系和数据级过滤；
• 可扩展能力：API 是否完整，是否方便二次开发。

POC 期建议不超过两周。两周内出结果的方案继续谈；两周内连数据加载都很费劲的方案，后续支撑不了复杂业务，果断放弃。

这一步的关键不是选一个技术上最领先的方案，而是选一个能在你的数据环境下真正跑通的方案。以及别忘了算 ROI：把场景里节省的人力、提高的效率折算成金额，除以订阅成本，看得不划算。ROI 为正，才有继续扩大范围的底气。

6.2 第二步：从单场景扩展到多场景，让平台能力逐渐成形

第一个场景跑通后，紧接着要做的是把场景入口扩展。客服部门用了知识库问答，市场部门想用文档分析，研发部门想用代码辅助……需求会自然涌来。这时候不要急于自建，而是在现有产品基础上，按部门分批接入。用统一账号体系纳管，按业务域划分空间和权限，每个部门看到自己的知识库、自己的数据、自己的统计数据。所谓 AI 基础设施，在这个阶段的表现形式其实是一个“统一管理、按部门隔离的成熟产品”。

只有当出现以下三种情况时，才认真考虑自研部分组件：

• 成熟产品在某个环节效果明显不满足，比如特殊文档格式解析；
• 业务场景与产品功能深度耦合，比如需要把 RAG 嵌入核心业务系统的操作流；
• 规模化之后单位成本过高，需要自研替代方案来降本。

请注意，即便到了这一步，也是“点状自研、整体采购”的混合模式，跟“全面自建平台”是两个概念。

6.3 第三步：搭建最小可行团队并设定合理的预算节奏

不自建平台不代表不需要团队。最小可行团队配置是：一名具备 AI 应用开发经验的工程师（负责集成和二次开发），一名数据工程师（负责数据清洗和知识库维护），一名业务方代表（负责定义需求和验证效果）。三个人足够支撑初期业务落地。后续根据接入业务量按需增加。

预算结构建议：把 60% 以上的预算放在平台订阅和 API 调用费用上，剩下预算用于人力、培训和运营推广。很多企业预算分配是反过来的——大头花在自研人力上，买工具反而抠抠搜搜。这个心态可以改改了。设置三个里程碑：两周 POC，一个月跑通首个业务闭环，三个月完成效果评估和多场景扩展决策。这三个节点分别卡住技术可行性、业务可行性和规模化可行性，把风险前置到每个节点之前。

7. 实操中遇到的典型问题与对应策略

7.1 检索结果总是不正确的排查思路

知识库检索不准，优先排查三个环节：先看索引内容是否已正确更新，很多时候是知识库已经有新版本文档，但系统索引还是旧数据；再看查询语句是否过于口语化，关键词匹配在短查询时不占优，可以加入查询改写逻辑将自然语言改成包含关键实体的检索语句；最后看分块策略，把大文档按标题层级切分后检索准确率通常会有明显上升。

7.2 回答内容出现幻觉或与原文不符

如果检索到的知识正确但回答错了，优先检查 prompt 指令是否足够严格。比较有效的写法是：明确告诉模型“只能基于提供的检索内容回答”，并设置“检索内容不足时直接说明不知道”。另外一个高效的做法是把检索到的原文用明确的标记括起来，放在 prompt 的前部，让模型把原文当作参考资料而非闲聊素材。若仍然出现幻觉，可以调低模型的 temperature 参数，让输出更忠于上下文。

7.3 权限泄漏的风险如何规避

权限泄漏是 RAG 产品落地时的高危问题。配置权限时必须确认：知识导入阶段做权限打标，检索阶段做过滤，生成阶段再做一次脱敏。三者的配合缺一不可。如果采购的成熟产品不支持在检索阶段过滤权限，宁可不用也不能上线。这个红线非常明确：权限不能靠生成模型自觉约束，必须在检索环节强制过滤。这也是某些自建方案做不好、最终翻车的重灾区。

7.4 知识更新不生效，系统回答陈旧

向量库里的内容不是文件替换了就能自动更新。需要建立触发机制：当源文档发生变化时，重新解析、重新分块、重新生成 embedding，将旧向量删除。如果产品有自动同步能力，务必配置测试用例验证“修改、新增、删除”三种情况都能正确处理。实际项目中，因遗漏删除机制导致 AI 反复引用过期流程的案例，不在少数。

7.5 成本逐步失控的应对方法

AI 应用上线初期，业务部门会有新鲜感，调用量增长飞快。为了防止成本失控，可以采取分级模型策略，简单问题走小模型、复杂问题走大模型；设置部门配额和调用熔断机制；建立月度成本复盘制度，按业务域拆分账单。有数据才能讨论，才有收敛的空间。成本管理不是限制业务，而是让业务对资源消耗有感知、合理规划。

8. 几条关于 RAG 平台选型的真实经验

第一，宁可选择一个“功能少但数据接入顺滑”的平台，也不要选择一个“功能全但接不进你数据”的平台。数据链路通畅是一切效果的基础。这个结论来自多个项目的共同教训。

第二，评估 RAG 产品时，找业务人员来测，不找技术人员测。技术人员测试时习惯于看技术指标、调检索参数，业务人员测的是好不好用、回答准不准、敢不敢真用。得到业务认可的方案，才能落地。

第三，尽量选择生态开放的产品。这里的开放指的是：API 文档完整、支持二次开发、有活跃社区或插件体系、底层支持替换模型。如果一切功能都是黑盒，后期想优化时会非常被动。

第四，平台和业务团队的关系越早明确越好。谁负责平台运维、谁负责业务优化、谁能提需求、需求按什么节奏响应，这些约定清楚了，才能避免“平台团队做了没人用、业务团队想用没人管”的尴尬局面。人员分工的执行细节，远比技术方案的选型更影响最终成败。

我个人的体会是：大多数企业卡在自建决策上的原因，不是技术能力不够，而是对“平台”二字的想象过于宏大。RAG 产品是解决问题的工具，AI 基础设施是支撑多业务的组织能力，这两者之间并不需要靠“自建平台”来跨越。用成熟产品把业务跑起来，在过程中沉淀出属于自己团队的方法论和评估体系，这才是更经济、也更可持续的路径。如果你正在做这个决策，不妨先把注意力从“我们能建什么”转移到“业务真正需要什么”上——答案通常会清晰很多。