企业买了 AI,为什么跑不起来-夜雨聆风

企业买了 AI,为什么跑不起来

一家企业花了几个月谈合同、走采购流程，把某个大模型的”企业版”跑起来了。三个月后，推广计划停摆，日活用户不到 10 人，全靠少数技术部门的同事维持。这是国内大量 AI 项目目前的真实状态。采购 ≠ 落地，而两者之间的差距，往往在技术决策阶段就已经注定了。更深的问题是：即使每个部门都”跑起来了”，各自建设的 AI 能力正在形成新一代孤岛，而这一次比数据孤岛更难治理。

“要不要微调””要不要 RAG””怎么和私有云打通”——这三个问题在企业 AI 落地的讨论里被问得最多，但得到的答案通常模糊或被产品销售驱动。国内企业在 AI 落地上面临的挑战有其特殊性：数据出境限制、现有私有云架构的网络隔离、以及合规要求对数据流向的管控。本文尝试给出这三个问题的工程答案，而不是营销答案。

决策路径的起点是数据能否出境，而不是”哪个模型能力最强”。数据出境合规决定了部署方式，部署方式决定了可用的基础模型，基础模型的能力边界决定了是否需要 RAG 或微调。顺序搞反了，后面的决策全部无效。

发生了什么

为什么这个问题现在尤其重要：

2024–2026 年，国内 AI 基础设施采购进入快速增长期，各家大模型厂商都在向中大型企业推销”企业版”方案。Qwen 系列、文心一言企业版、百川企业版、ChatGLM 私有化——加上 Azure OpenAI Service 的中国区服务，企业的选择空间前所未有地大。

但采购完成率和实际落地率之间存在明显的剪刀差：多家集成商和咨询公司反映，企业 AI 项目在”概念验证（PoC）通过 → 全面推广”这个阶段的失败率极高。主要卡点：

PoC 用的是脱敏数据，真实数据进不了测试环境
部署完成后没有人知道怎么写有效的 prompt
和现有系统的打通（OA、CRM、知识库）没有人力推进
模型回答质量不稳定，业务方信任度下降后不再使用

这四个卡点都不是”模型不够好”的问题，是落地工程和组织问题。

技术上这意味着什么

问题一：要不要微调（Fine-tuning）？

简短答案：95% 的场景不需要，而且你可能还没准备好。

微调适合的场景非常具体：

输出格式高度固定（如生成特定 JSON schema、特定法律文书格式）
任务领域极度专业，通用模型几乎没有覆盖（如某细分行业的专有术语体系）
需要模型”内化”某种风格或语气，而不是每次靠 prompt 注入

大多数企业实际面对的场景——内部知识库查询、文件摘要、会议纪要生成、代码审查——都不需要微调，靠 prompt 工程和 RAG 就能解决。

微调被过度推销有一个商业原因：它的部署周期更长、绑定更深，对服务商来说收入更可预期。销售话术通常是”用你们的数据训练专属模型，能力完全贴合业务”——这句话本身没有错，但省略了关键条件：“你们的数据”需要是高质量的标注语料，而不是从系统里导出来的原始日志。国内很多企业在接触微调方案时，手上的”数据”实际上是未经整理的 OA 附件、扫描 PDF、甚至是员工在群里发的语音转文字——这些数据在清洗之前毫无微调价值，而清洗工作本身就是一个独立的数据工程项目。

另一个常见的推销角度是”专属模型不会泄露数据”。这个说法混淆了部署方式和训练方式：如果担心数据安全，私有化部署通用模型同样能做到数据不出境，没必要为了安全理由去微调。真正推动微调需求的应该是能力瓶颈，而不是安全焦虑。

但从工程角度，微调的前置成本被严重低估了：

微调前置条件	典型企业的实际情况
高质量标注数据（≥1000 条）	大多数企业没有现成的标注语料
数据清洗和版本管理	通常需要专职数据工程师
评估集设计	需要领域专家参与，不能用自动化指标代替
持续微调更新（知识更新后）	业务知识每季度都在变，微调不是一次性工作
GPU 训练资源	A100/H100 的训练时间成本，按小时计费

如果上述条件都不具备，微调的结果通常是：花了大量成本，得到一个在几个特定测试集上效果好、但在真实业务场景下表现不稳定的模型。

什么时候应该认真考虑微调： 当你有超过 5,000 条高质量的领域标注数据、有评估体系、并且 prompt 工程已经达到明显瓶颈的时候。一个实用的判断标准：如果你还在讨论”prompt 怎么写”，就说明微调的时机还没到。

问题二：要不要 RAG（检索增强生成）？

简短答案：有内部知识库查询需求的场景，RAG 通常是正确答案。

RAG 解决的是大模型的”知识时效”和”私有知识”问题：模型的训练数据截止于某个日期，而且不包含你公司的内部文档。RAG 通过在每次对话时从外部知识库检索相关片段，注入到 prompt 里，让模型”看到”它本来不知道的信息。

RAG 的核心技术组件：

文档处理：  原始文档（PDF / Word / HTML）    → 分块（Chunking，通常 256–512 tokens）    → Embedding 模型（文本 → 向量）    → 向量数据库存储查询时：  用户问题    → Embedding 模型（问题 → 向量）    → 向量相似度检索（Top-K 相关片段）    → 片段 + 问题注入 prompt    → 大模型生成答案

国内常见的技术选型：

组件	推荐选项	说明
Embedding 模型	BGE 系列（BAAI）	中文效果最好，可本地部署
向量数据库	Milvus（高并发）	国内团队（Zilliz）开源，文档友好
向量数据库	pgvector（已有 PG 栈）	不引入新组件，适合中小规模
向量数据库	Chroma（快速原型）	本地开发方便，生产规模有限
分块策略	递归字符分块	LangChain 默认，适用于大多数文档
RAG 框架	LangChain / LlamaIndex	成熟生态，国内有大量中文教程

RAG 被过度期望的几种典型场景：

RAG 不是”接入知识库就能用”，现实项目中 RAG 的期望落差有几个固定的来源：

“把所有内部文档都塞进去”的想法行不通：企业内部文档的质量参差不齐——有领导讲话稿、有几年前的老版制度、有扫描件、有多个部门各自修订的”同名文档”。RAG 的检索质量上限取决于知识库的质量下限，而不是取决于模型的能力。把没有整理的文档直接进库，结果是：问什么都能检索到”相关”的片段，但答案质量极不稳定，用户很快就失去信任。
“语义检索会自动理解意图”的误解：向量相似度检索擅长找”语义相似的内容”，不擅长回答”最新版是哪个””谁批准的””这个流程的例外情况”这类需要结构化逻辑或时序判断的问题。大量企业的知识库查询需求实际上是半结构化的（如：查某个项目的审批状态），这类问题用纯 RAG 效果有限，需要结合传统数据库查询（Text-to-SQL）才能答好。
一次部署、永久受益的期望：知识库需要持续维护。业务规则每季度都在变，产品文档每次版本迭代都要更新，老文档没有及时下架就会持续污染检索结果。RAG 带来的不只是部署成本，还有一个长期的文档治理责任，这在采购阶段几乎从不被提及。

RAG 常见的技术失败模式：

分块粒度不对

：太细导致每个块缺乏上下文，太粗导致检索噪音多
Embedding 模型和生成模型语言不匹配

：用英文 Embedding 处理中文文档，检索效果差
没有重排序（Re-ranking）

：向量相似度检索出来的 Top-K 片段不一定是最相关的，加一个轻量 Cross-Encoder 重排序能显著提升效果
文档质量差

：扫描 PDF、格式混乱的 Word 文档进 RAG 之前需要先做结构化处理，否则 Chunking 结果一片混乱

问题三：怎么和现有私有云打通？

这是国内企业落地 AI 最常被忽视、最容易变成项目卡点的问题。

国内私有云的典型架构：

大多数中大型企业（金融、制造、政府）的私有云基于以下之一：

华为云 Stack（HCS）

：国内市占率最高，基于 OpenStack 演进
VMware vSphere + NSX

：历史遗留较多，迁移到国产化中
TStack（腾讯私有云）/ Apsara Stack（阿里云）

：互联网和新兴企业较多
OpenStack 自建

：技术团队较强的企业

AI 服务需要打通的不只是”部署在哪”，而是一系列连接点：

网络隔离问题（最常见的卡点）：

私有云环境通常有严格的网络隔离：生产网、测试网、开发网相互隔离，访问 AI 服务需要申请网络策略放行。如果 AI 服务部署在 DMZ 或独立 GPU 集群，而业务系统在生产内网，中间可能需要走 API Gateway 或 Service Mesh 做流量代理，审批周期往往超过部署周期本身。

实用的打通路径：

方案 A（最简单）：API 网关代理  业务系统 → 内网 API Gateway → AI 服务集群  优点：不改业务代码，网络策略集中管理  缺点：增加一跳延迟，API Gateway 成为单点方案 B（Sidecar 模式）：  业务 Pod/VM → Sidecar 代理 → AI 服务  适合容器化（K8s）环境，配合 Istio/Envoy  优点：流量可观测，支持认证/限流  缺点：K8s 基础设施要求，改造成本高方案 C（离线批处理）：  业务系统 → 消息队列（Kafka/RocketMQ）→ AI Worker → 结果写回 DB  适合不需要实时响应的场景（文档批量处理、报告生成）  优点：解耦彻底，对网络隔离要求最低  缺点：不支持交互式对话

数据合规的具体要求：

国内企业使用 AI 服务时，数据合规是绕不过的约束：

《数据安全法》《个人信息保护法》

：用户的个人数据（姓名、身份证、联系方式）不得传输给境外服务器，原则上也不应传入任何未经备案的 AI 服务
金融行业

：银保监会要求客户数据不出本行系统，AI 处理必须在行内完成
政务系统

：等保要求通常要求系统在政务云或自建机房部署

实际操作：在把任何文档传入 AI 系统之前，需要评估文档是否包含”受保护数据类别”。大多数内部知识库文档（技术文档、操作手册、产品说明书）不涉及个人数据，可以直接进 RAG；包含客户信息的文档（合同、工单）需要脱敏后进入，或者完全走私有化部署方案。

深度分析

智算基础设施正在变成新一代孤岛

过去十年，国内企业经历了一轮”数据孤岛”治理——花了大量资源把 ERP、CRM、OA 等系统的数据打通，建了数据中台、数据湖。现在，同样的问题正在 AI 基础设施层重演，而且速度更快、结构更难修复。

问题的起点是采购逻辑：AI 项目通常从单个业务部门的 PoC 开始，某个部门通过了验收、拿到了预算，部署了一套 GPU 集群 + 向量数据库 + 模型服务。另一个部门随后启动自己的 PoC，用了不同的模型厂商、不同的 Embedding 模型、不同的向量数据库版本。六个月后，同一家企业里可能跑着三套互不兼容的”智算平台”：

业务部门 A：Qwen 私有化 + Milvus 2.x + BGE-large业务部门 B：文心企业版 API + Elasticsearch 向量索引 + 文心 EmbeddingIT 部门：华为 ModelArts + GaussDB AI + 自研 Embedding

这三套系统各自能用，但：

用户提的同一个问题，在三个入口可能得到不同答案
同一份文档（如公司管理制度）在三个知识库里各有一份，更新不同步
每套系统有独立的运维团队、独立的安全审计要求、独立的合规备案

这不是理论担忧，是目前国内大型企业 AI 建设的常见现状。”先跑起来再说”的策略在 PoC 阶段合理，但在全公司推广阶段会形成技术债，而且这种技术债比数据孤岛更难清理——因为模型和知识库的耦合比数据库的 schema 更难标准化。

监管严格行业的不一致性问题尤其严重

金融、医疗、政务这三个行业，AI 落地的监管压力最大，但讽刺的是，它们的”智算孤岛”问题也最严重。原因是：越严格的监管环境，越倾向于”每个系统单独立项、单独审批、单独验收”，而不是”统一建设、统一接入”。

金融行业：

银行内部通常按条线（零售、对公、风控、运营）分别建设 AI 能力，条线之间的系统隔离本来就是监管要求（数据不能跨条线流动）。结果是：零售条线的智能客服用一套模型，风控条线的文本分析用另一套，运营条线的报告生成又是一套。当监管机构要求”解释 AI 决策依据”时，这三套系统给出的口径、术语、信心评分完全不一致——而监管机构只看到的是这家银行”的 AI 系统”。

更具体的问题是模型版本管理：监管机构要求金融机构保留 AI 模型的历史版本和决策日志，以便事后审计。但三套独立系统的日志格式不同，模型版本的记录方式不同，在需要提供统一审计报告时，人工整合成本极高。

医疗行业：

医院信息化建设通常按科室推进，各科室的 AI 辅助诊断系统往往来自不同厂商，训练数据集、诊断标准、输出格式各不相同。当医院管理层需要统计”AI 辅助准确率”时，会发现三个科室的数字根本没有可比性——因为底层定义就不一样。《人工智能辅助诊断软件》的注册证审批是按产品单独审批的，进一步固化了”各系统独立”的格局，没有动力打通。

政务系统：

等保分级要求不同密级的系统物理隔离，高密级系统无法调用低密级的 AI 服务。实践中，各委办局分别建 AI 能力，同一个城市可能有十几套”政务 AI 平台”并行，使用同样的开源模型但版本不同、提示词工程策略不同、安全过滤规则不同。当需要跨部门协同处理一个事务（如营业执照 + 税务 + 社保联办）时，各系统给出的结果经常相互矛盾，最终还是人工兜底。

为什么这个问题比数据孤岛更难解：

数据孤岛的本质是”数据格式和 API 不统一”，解法是 ETL + 数据标准化。但智算孤岛叠加了模型行为的不一致性：即使两套系统用同一个基础模型，不同的 prompt 模板、不同的 Embedding 版本、不同的知识库分块策略，会产生系统性的行为差异，而这种差异没有客观的”正确答案”来校准。

数据可以做 schema 标准化，模型输出无法直接标准化——你不能强制要求两个 RAG 系统对同一个问题给出相同的答案，除非底层的知识库、检索策略、模型版本完全一致。在监管机构要求”一致性”的场景下，这是一个没有简单技术解法的问题。

为什么 PoC 成功率高、全面推广失败率也高？

PoC 阶段的成功条件通常是：精选的文档、精心设计的测试问题、技术团队主导评估。这套条件在全面推广时全部消失：文档质量参差不齐、提问方式五花八门、评估方是对 AI 陌生的业务人员。

这不是 AI 的问题，是 PoC 环节没有测真实场景的问题。

有效的 PoC 设计应该包含：

用真实的、未经筛选的业务文档（而不是样本文档）
让实际使用者（而不是技术评估人员）设计测试问题
测试边界情况：文档里没有答案时，模型是否正确说”不知道”而不是编造答案
测试系统集成路径，而不只是模型能力

开源 vs. 闭源的选择框架：

这个问题在国内比在其他市场更复杂，因为数据出境限制实际上把”闭源境外模型”（GPT-4、Claude）的可用场景限制在了脱敏数据或不涉及个人信息的场景。国内企业的实际选择通常是：

场景	推荐路线	理由
内部知识库，含敏感数据	开源本地部署（Qwen / ChatGLM）	数据不出域
代码辅助（内部代码库）	开源本地部署	代码是商业机密
通用内容生成（非敏感）	国内闭源 API（文心/通义）	合规更简单
研究和实验	境外闭源 API（Claude / GPT）	能力更强，但有出境限制

落地成功率最高的场景：

根据多个集成项目的反馈，目前落地成功率最高的 AI 应用场景是：

代码审查辅助

：输入代码，输出问题列表——任务明确，结果可验证，不依赖模型”理解业务”
结构化文档生成

：给定模板和输入数据，生成周报/月报/合同摘要——格式固定，质量可控
批量文档分类和标签

：给大量文档打标签，替代人工操作——即使偶尔出错也可接受

成功率最低的场景：开放式知识问答（”我们公司的政策是什么”）——这要求 RAG 覆盖所有相关文档、文档保持最新、模型能正确识别检索失败。这三个条件同时满足需要持续的工程投入。

值得关注的信号

监管机构是否发布 AI 系统一致性要求：金融行业的 AI 监管目前关注的是”可解释性”和”模型风险管理”，还没有明确要求跨系统输出一致性。如果银保监会或证监会发布相关指引，要求同一机构的 AI 系统遵循统一的决策口径，将直接推动金融机构做智算整合。
企业 AI 中台产品是否出现：数据孤岛问题最终靠数据中台（OneData 等）缓解。类似地，如果有厂商推出”AI 中台”产品——统一的模型接入层、统一的知识库管理、统一的审计日志格式——并被监管严格行业采用，说明孤岛问题已经严重到产生市场需求。
RAG 框架的国内采用情况：LangChain 和 LlamaIndex 都有中文生态，但国内也出现了本土替代品（如阿里的 PAI-RAG、腾讯的 LightRAG 等）。如果本土框架开始在企业场景规模化落地，说明国内 AI 工程能力在快速成熟。
Milvus 的版本动向：Milvus 3.0 已经在 2025 年底发布，支持更细粒度的向量和标量混合检索（Hybrid Search）。这对 RAG 的精度有显著提升，值得关注国内企业的采用时间线。
模型厂商的企业级 SLA：目前国内大模型厂商的企业版服务，SLA 普遍在 99.5% 左右，低于国际主流云服务的 99.9%。如果某家厂商率先把 SLA 提升并配套赔偿机制，这会成为企业采购的强信号。

补充背景

RAG 的技术演进： RAG 的概念来自 Lewis 等人 2020 年在 NeurIPS 的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》。原始论文的场景是 Wikipedia 检索，但在大模型时代被广泛应用于私有文档检索。当前的工程实践已经远超原始论文，包括混合检索（稠密 + 稀疏）、重排序、查询重写等多种增强技术。

BGE Embedding 模型： BGE（BAAI General Embedding）是北京智源人工智能研究院开源的中英双语 Embedding 模型系列，在中文语义检索任务上表现最好，是国内 RAG 实践中使用最广的 Embedding 模型。在 HuggingFace MTEB 中文排行榜长期排名前列。