企业在 AI 模型的选择和部署策略上应当如何抉择？

最近我看到几个很有意思，但同时也有点让人不寒而栗的提示词。

把它们交给一个你经常使用的聊天机器人，让它根据你的写作和提问方式，推断你的年龄、收入、居住地和个人情况；预测你会怎样处理金钱、压力、冲突和风险；指出你自己可能没有察觉的性格特征、盲点和不安全感；最后，再列出那些你大概不愿意让雇主或陌生人知道的事情。

如果你已经和这个 AI 交流了很长时间，它给出的答案有时会“准得吓人”。

不过，这个倒不一定是 AI 在窥探你，而且 AI 的推断也未必正确。这甚至也不能证明云服务商一定拿了你的对话去训练模型。真正值得注意的是另一件事：一些单独看起来无关紧要、甚至谈不上敏感的信息，放在一起以后，可能形成一幅远比我们想象中更完整的画像。

同样地，企业也面临着类似问题，而且后果更严重。

01 CHAPTER

真正需要保护的，不只是原始数据

员工在日常工作中交给 AI 的，往往不是一份标着“机密”的完整文件，而是很多零散片段：一封客户邮件、一段会议纪要、一张报价表、几行代码、一份岗位说明、一次投诉记录，以及对某位供应商或同事的评价。

每一段信息单独看，风险可能都不大。但当模型把它们和历史对话、上传文件、企业知识库以及其他连接器中的信息放在一起，就有可能进一步推断出：

  • 哪些客户正在流失，哪些客户具有更高的价格承受力；
  • 公司的毛利压力、现金流状况和下一步投资重点；
  • 哪个流程最脆弱，哪个团队最依赖少数关键员工；
  • 尚未公布的产品方向、组织调整、并购意向或谈判底线；
  • 企业管理层的决策偏好、风险承受度和内部矛盾。

这类风险不只是想象。美国国家标准与技术研究院（NIST）在生成式 AI 风险管理框架中专门提醒，模型可能把来自不同来源的信息拼接起来，推断出用户没有直接披露、甚至训练数据中也不存在的敏感信息。国际学习表征会议（ICLR）的一项研究也发现，LLM 能够从真实 Reddit 用户留下的文本中推断位置、收入、性别等个人属性。这个实验当然不能直接等同于企业泄密概率，但它至少说明：推断本身，已经成为一种需要单独管理的信息风险。

过去我们关注的是“这份数据有没有被传出去”。现在还要再问一句：“把这些数据放在一起以后，模型还能看出什么？”

02 CHAPTER

云端不等于一定拿数据训练

讨论到这里，很容易滑向另一个极端：只要用了云端 LLM，企业数据就一定会被拿去训练或泄露。

这也不完全准确。

目前不少面向企业的模型服务和 API 都明确承诺，默认不会使用企业的输入和输出训练基础模型；有些服务还提供区域选择、专属实例、客户管理密钥、缩短留存期或零数据留存等能力。消费级聊天产品、企业版产品、普通 API、专属托管服务之间，也存在很大的数据条款和技术边界差异。

但“不用于训练”并不等于“不经过第三方处理”，也不一定等于“不留存”、“没有日志”、“没有人工审核可能”、“不会被连接器扩大访问范围”，更不等于模型无法在当前上下文中完成敏感推断。

所以，企业真正需要做的不是简单地问“能不能上云”，而是把几个问题逐项问清楚：

  • 输入、输出、文件、向量和对话历史分别保存在哪里？
  • 默认留存多久，哪些功能会额外保存状态？
  • 数据是否会跨区域处理，是否涉及其他服务商或子处理方？
  • 谁可以看到日志，谁有权删除，能否完成审计？
  • 模型接入了哪些邮箱、文档、CRM、代码库和业务系统？
  • 即使原始内容不算机密，组合以后会不会暴露关键经营判断？

真正需要防止的，不是云，而是没有边界的使用。

03 CHAPTER

私有化部署，不应是一场技术信仰之争

“私有化”也不是一个非黑即白的概念。它可以是部署在企业自己的服务器上，也可以是运行在客户控制的云账户或 VPC 中；可以完全离线，也可以采用专属托管模型，并通过严格的数据网关与外部模型协同。

对于客户资料、合同审阅、源代码、财务分析、研发知识、员工信息，以及会直接触发业务动作的核心流程，企业确实应该认真评估一条更私有、更可控的推理路径。

它的主要价值包括：

  1. 控制数据路径。企业可以决定哪些数据不能离开内部环境，哪些字段必须脱敏，哪些请求经过审批后才允许调用外部模型。
  2. 控制留存与审计。对话、检索、输出和工具调用可以纳入自己的身份权限、日志、删除、备份和审计体系。
  3. 把知识留在业务边界内。企业可以在本地建立 RAG 和知识权限，不必把完整知识库长期交给外部平台。
  4. 稳定成本、延迟和可用性。对高频、重复、边界清楚的任务，本地推理有机会获得更可预测的单位成本和响应时间，也更容易支持弱网或离线场景。
  5. 掌握模型与适配器的版本。企业可以冻结版本、重复评测、回滚，并为不同部门维护独立的 LoRA 适配器，而不必被外部模型升级牵着走。

但私有化部署不会自动带来安全。权限配置错误、日志中残留敏感内容、被污染的知识库、提示词注入、模型和依赖的供应链风险、内部人员滥用，以及缺乏补丁和监控，同样可能造成严重问题。

把一个开源模型下载到服务器上，只能说明“模型跑起来了”，不能说明企业已经拥有了一套安全、可靠、可运营的 AI 能力。

04 CHAPTER

什么条件下，私有化才真正值得做

我更倾向于从工作流，而不是从模型开始判断。

如果一个流程同时具备以下几项特征，私有化的优先级通常会明显提高：

  • 数据或推断结果具有较高敏感度；
  • 错误输出会造成实际的财务、法律、客户或运营后果；
  • 任务重复发生，输入输出边界相对稳定；
  • 调用量足够高，本地推理可能摊薄硬件和运维成本；
  • 对延迟、离线、数据驻留或版本稳定有明确要求；
  • 企业愿意承担模型评测、权限、监控、升级和应急响应的长期责任。

反过来，如果任务高度开放、使用频率很低、对最强推理能力依赖很大，数据经过脱敏后风险又不高，那么合规的企业级云模型可能仍然是更好的选择。

私有化真正的门槛，从来不是能不能把模型启动起来，而是有没有能力长期把它管好。

05 CHAPTER

LLM 还是 SLM：先找能通过评测的最小模型

企业一说私有化，常常首先想到部署一个尽可能大的 LLM。但在实际业务中，模型并不是越大越合适。

私有 LLM 更适合处理上下文复杂、表达开放、需要多步推理或跨领域理解的任务。例如复杂合同分析、研发知识问答、跨文档归纳，以及需要在多种工具之间规划步骤的 Agent。它的代价是更高的 GPU、内存、并发和运维要求。

SLM，也就是小语言模型，更适合边界清楚、重复度高、输出可以验证的任务。例如分类、字段抽取、工单路由、敏感信息识别、固定格式生成、本地检索辅助，以及流程中的第一层判断。它通常更容易在有限硬件上运行，延迟更低，也更容易被企业掌握和治理。

一个务实的架构往往不是二选一，而是分层处理：

  1. 先让本地 SLM 处理高频、敏感、结构化的常见任务；
  2. 较复杂但仍不能离开企业边界的请求，升级到更强的私有 LLM；
  3. 低敏感、开放式、需要最强通用推理的任务，在脱敏和策略检查后调用云端模型；
  4. 所有路径都经过统一的模型网关、身份权限、日志和评测体系。

选择模型时，最重要的不是参数排名，而是这几个问题：它在企业自己的任务集上能否达标？失败时会造成什么后果？并发和上下文需要多大？运行一年以后，总成本是多少？

可以把原则归纳得很简单：先分数据，再分任务；优先使用能够通过评测的最小模型，必要时再升级。

06 CHAPTER

LoRA 不是给模型“灌知识”

当本地模型表现不够稳定时，很多团队会马上想到微调。但微调之前，先要判断问题究竟出在哪里。

如果缺的是最新制度、产品资料、客户状态或企业知识，优先应该考虑 RAG。知识会变化，应该放在可更新、可授权、可追溯的知识库里，而不是不断写进模型参数。

LoRA 更适合解决稳定的“行为问题”：

  • 让模型更稳定地遵循企业术语和输出格式；
  • 提高某类分类、抽取、路由任务的一致性；
  • 学会特定工作流中的工具调用方式；
  • 强化什么情况下应该拒绝、升级给人工或要求补充信息；
  • 形成面向某个部门或场景的表达习惯。

LoRA 的思路，是冻结大部分基础模型参数，只训练一小组低秩适配参数；QLoRA 则进一步通过量化基础模型降低训练所需的显存。这让企业有机会以较低成本维护多个任务适配器，但“训练得动”不等于“训练得好”。

一个稳妥的顺序应该是：先做好提示词和基线，再接入 RAG 和结构化约束，建立固定评测集；只有剩余问题确实属于稳定行为偏差时，才进入 LoRA 或 QLoRA。

训练数据也不能因为模型在本地就放松要求。数据仍然要确认来源和授权、完成去标识化，覆盖正常案例、边界案例、拒绝案例和失败案例。Teacher Model 可以帮助预标注和扩充候选样本，但它的答案不能直接当成 Gold Data；人工审计和独立留出的评测集仍然不可替代。对于不能离开企业边界的原始数据，Teacher Model 也必须在同等受控的环境中运行，或者只接触经过脱敏的材料。

微调前后，必须让基础模型和 LoRA 模型在同一套未参与训练的业务评测集上比较。否则，我们看到的很可能只是模型更会模仿训练样本，而不是它在真实工作中变得更可靠。

07 CHAPTER

企业应该从哪里开始

企业不需要先立项建设一套庞大的“私有大模型平台”。更好的起点，是选择一条真实、敏感度较高、但边界又足够清楚的工作流：

  1. 画出数据从哪里来、经过哪里、最后触发什么业务动作；
  2. 标出哪些原始数据和推断结果不能离开企业边界；
  3. 用经过脱敏的样本，为云模型、私有 LLM 和 SLM 建立同一条效果基线；
  4. 建立准确率、稳定性、拒绝能力、延迟、成本和人工接管等评测指标；
  5. 先用提示词、RAG 和规则解决问题，再决定是否需要 LoRA；
  6. 验证通过以后，再把权限、日志、监控、回滚和团队交接补齐。

这也是我在 FFDE.ai 中越来越坚持的一点：AI 落地不能从“我们该部署哪个模型”开始，而要从“这条业务流程需要什么能力、证据和边界”开始。

云端模型仍然会是企业 AI 的重要组成部分。私有模型也不会取代所有云服务。真正成熟的策略，是知道哪些工作可以放心上云，哪些必须留在内部；什么任务值得用 LLM，什么任务一个 SLM 就已经足够；什么时候应该接知识库，什么时候才值得微调。

企业的 AI 自由，不是拥有最多的模型，而是拥有选择、替换、审计和继续改进这些模型的能力。

FFDE.ai 仍在持续研究和验证这套方法。如果您正在企业内部评估云端与私有模型的边界，或者已经遇到数据、部署、评测与微调方面的实际问题，欢迎交流。

→ https://ffde.com.cn

08 CHAPTER

参考资料

← 返回博客文章归档