amBrain
FinTechSep 28, 2026阅读需 10 分钟

自建 ML 团队还是外包 AI 开发:如何决定,该找谁

ML 团队AI 外包自招还是找伙伴谁来做
图片加载失败

如果 AI 就是你出售的产品,就招一支 ML 团队。如果你只需要一两个 AI 系统,而公司里没有人能带领招进来的 ML 人员,就外包。

如果客户付钱买的就是 AI,而且模型在今后几年里每周都需要有人投入精力,就自己招一支 ML 团队。如果你只需要在已有的业务运营中加入一两个 AI 系统,而公司里没有人能带领招进来的 ML 人员、也没有人能评判候选人,就外包。选择由谁来做时,要找一家能拿出一个由它投入生产、至今仍在日常使用的 AI 系统的公司,并在合同里写明把代码、模型文件和评估集交给你。

简短的答案是:AI 就是你的产品时,就自己招人;AI 是业务中的一个工具、内部又没有人能带 ML 团队时,就外包。如果你选择外包,但系统要运行很多年,那就按顺序两件都做:外部团队做第一个版本,同时你招进两三个将来负责它的人。

我们需要的是 ML 研究人员,还是基于现有模型做开发的工程师?

提出这个问题的公司,大多数并不需要有人去发明或训练一个新模型。它们需要的是这样一个系统:拿一个现有的模型,把自己的文档、工单或交易交给它,检查它输出的东西,再把结果放到员工日常工作的地方。这是围绕模型的工程工作,要招的人和做研究的不是同一类人。

训练自己的模型,主要是在模型本身就是客户所购买的东西时才划算,而且需要大量标注数据。基于现有模型来构建,无论用的是提供方的服务,还是下载下来在自己服务器上运行的模型,需要的都是能把系统接起来、检查答案质量、让软件持续运行的人。在写岗位描述或联系合作伙伴之前,先决定你需要的是这两者中的哪一个。

一支内部 ML 团队,实际上由哪些人组成?

一个 ML 工程师不是一个团队。生产环境中的模型嵌在大量普通软件之中,而构建和运行这些软件的人占了团队的大部分。Google 关于 MLOps 的架构指南是这样说的:“在真实世界的 ML 系统中,只有一小部分由 ML 代码构成。所需的周边要素庞大而复杂。”

一支无需外部帮助就能构建并运行一套生产系统的团队,要覆盖四个角色:

  • 一位能规划工作、能评判 ML 候选人的负责人。没有这个人,公司就分不清谁是好人选、谁只是表现得很自信
  • 选择模型、准备数据、编写评估并改进结果的 ML 工程师
  • 从你已在运行的系统中取出干净、获准使用的数据,并让它持续流动的数据工程师
  • 负责运行基础设施的工程师:服务器或云账户、部署、监控,以及模型答案变差时触发的告警

在小团队里,一个人可以身兼其中两个角色,但没有人能身兼全部四个。还有一个角色在业务一侧,招谁都替代不了:决定什么才算正确答案的人。

一支内部 ML 团队要花多少钱?

薪资通常是最大的一项开支,公开数据可以提供一个参照。美国劳工统计局(BLS)没有单独公布机器学习工程师的工资数据。在它统计的最接近的几类职业中,2025 年 5 月的年薪中位数为:数据科学家 120,230 美元,软件开发人员 135,980 美元,计算机与信息研究科学家 140,300 美元。

这些是美国整个职业类别的中位数。已经把 ML 系统投入过生产的人是一个更小的群体,而你所在的地区和所需的资历,都会让这个数字上下浮动。

工资并不是一名员工的全部成本。据 BLS 的数据,2026 年 6 月,在美国私营部门的全部岗位中,工资和薪金占雇主薪酬支出的 70.0%,其余 30.0% 是福利。

在薪资之外,还有其他成本:

  • 每个岗位的招聘,以及负责人岗位空缺给之后每一次招聘带来的延误
  • 用于实验和生产的算力,会随着使用量增长
  • 用于数据标注、实验追踪和答案监控的工具
  • 你自己员工的工时:他们要在最初几个月里编写正确答案、检查模型的输出
  • 按构建阶段配置的团队,规模往往比运行建成后的系统所需的更大

本文不给出外包的价格区间:任何公司在看到任务、数据规则和工作量之前,都无法诚实地为这项工作定价。

什么时候自己招一支 ML 团队才合理?

当工作永无止境、知识值得留在内部时,招人才划算:

  • 客户付钱买的是模型做的事。竞争对手能买到和你一样的基础模型,所以你的团队在这些模型之上所做的工作,才是你在卖的东西
  • 模型每周都需要照看。Google 的 MLOps 指南列出了模型性能下降的两个原因:欠佳的代码,以及“不断演变的数据画像”。在数据一直变化的地方,重新训练和重新测试就是一项长期工作
  • 你手里有别人都没有的数据。摸清这些数据怪癖的人会变得难以替代,他们应该为你工作
  • 你能先招到一位有经验的负责人并留住他。团队的其余部分围绕这个人来搭建

如果前两条成立,就招人。在你的团队成形期间,外部工程师仍然可以帮你缩短起步阶段。

什么时候外包 AI 开发是更好的选择?

当 AI 是业务中的一个工具、而不是业务本身时,外包更合适:

  • 你需要的是一两个系统,比如读取收到的文档或给客服工单分类,而不是源源不断的新模型
  • 大部分工作是把模型接入你已在运行的系统,比如服务台系统、文档库或核心数据库。经常做这类事的公司,以前就碰到过你会遇到的集成问题
  • 公司里没有人能带领招进来的 ML 人员,也没人能评判候选人。招一支自己管不了的团队,等于花大价钱才发现你需要的其实是一个合作伙伴
  • 在承担薪资支出之前,你想先弄清楚这项任务到底行不行得通。由外部团队做出的第一个系统,会用你自己的数据回答这个问题

有一个公开的数据点也指向同一方向。MIT NANDA 于 2025 年 7 月发布的报告“The GenAI Divide”基于对 52 家组织的访谈。报告显示,从外部供应商采购或与外部供应商合作开发的生成式 AI 工具,约有 67% 最终投入部署,而完全在内部自建的工具约为 33%。作者说明这些数字是自报数据,并提醒差距中的一部分可能源于这些组织本身。

外包也有它自己的代价:关于系统如何运作的知识留在你公司之外,直到有人把它搬进来。

我们能不能先外包第一个 AI 系统,之后再招一支团队来接手?

可以,而且对一家预计要把系统运行很多年的公司来说,这往往是最稳妥的顺序。由外部团队做出第一个版本,你在开发期间、而不是开发结束之后,招进两三个人。他们评审代码,参与设计决策,并在临近结束时自己来运行系统,开发方在一旁看着。

只有当交接以一份清单的形式写进合同,列明你会收到、并且离开开发方也能使用的东西时,这才行得通:

  • 放在你自己仓库里的源代码,带完整历史
  • 凡是训练过或微调过模型的地方,交付模型本身:模型文件、生成这些文件所用的配置,以及它们所依据的数据或对这些数据的说明
  • 提示词和配置,与使用它们的代码一起做版本管理
  • 评估集:带有商定正确答案的真实示例,以及对照这些示例给系统打分的脚本
  • 数据管道,以及哪些数据可以去往哪里的书面规则
  • 部署、回滚,以及模型开始给出糟糕答案那一天的处置手册

要检查这套交付物中每个基础模型的许可证,因为许可条件会随着基于它构建的东西一起走。例如,Meta 的 Llama 3.3 许可证规定,如果你使用 Llama 来“创建、训练、微调或以其他方式改进一个被分发或提供的 AI 模型,你还应在任何此类 AI 模型名称的开头加上‘Llama’。”

一个对任何开发方都适用的交接测试:你新招的人修改一条提示词或一项配置,运行评估集,部署这次变更再把它回滚,整个过程中开发方没有任何人碰键盘。凡是他们必须去问开发方的东西,都是你还没有拥有的。

签约之前,我们应该问 AI 开发公司哪些问题?

对每一家候选公司,都以书面形式提出同样的问题:

  • 给我们看一个你们投入生产、至今仍在日常使用的 AI 系统。它做什么、今天由谁运行,模型答错时又会发生什么?
  • 工作期间,我们的数据会去哪里,包括日志、测试副本以及任何用于调优模型的东西?其中有没有任何部分会离开我们的服务器或账户,或者被用来改进你们为其他客户使用的工具?
  • 你们会如何衡量输出质量?我们期望有一个用我们自己的示例构建、在开发开始前就商定、并设有合格线的评估集
  • 最后我们具体会收到什么?我们自己的工程师能否在没有你们的情况下运行和修改这个系统?
  • 你们自己的哪些组件会留在系统里?逐一列出名称,以及我们使用它们的条件

还要留意每家公司问了你什么。以前做过这类系统的公司,会先问你的任务和数据,然后才说出一个模型的名字。

外包 AI 开发时,有哪些危险信号?

  • 还没有人看过你的数据,方案里就已经点名了某个模型
  • 准确率数字没有附带测试集,或者附带的测试集是这家公司单方面挑选的
  • 合同允许用你的数据改进这家公司的共用工具,或者对此只字未提
  • 没有人问上线之后由谁来运行这个系统
  • 所有权条款保留了“我们的平台”或“我们的组件”,却没有列出它们具体是什么
  • 对每一项任务,第一个答案都是定制训练的模型。一家公司在收费训练模型之前,应该先解释为什么现有模型不行

哪些公司为其他企业开发 AI?你会推荐谁?

本文不点名哪家公司最好。一个不考虑你的任务、你的数据规则以及之后由谁运行系统的推荐,只是猜测。做这类工作的公司有五种,各自适合不同的情况:

  • 云服务商的专业服务部门及其合作伙伴网络。如果系统本来就要放在那家云上,这是一个合理的选择;可以预期,设计会建立在该服务商自家的托管服务之上
  • 大型咨询公司,适合 AI 是跨多个部门的更大变革中的一部分的情况。要问清楚谁来写代码,以及这些人是不是他们自己的员工
  • 专精型工程公司,适合构建一两个系统、并把它们接入你已在运行的东西。要他们拿出一个与你的问题相近的生产系统,而不是一份技术清单
  • 自由职业的 ML 工程师,适合边界清楚、公司内部有人能评判的任务。这个人一走,知识也跟着走
  • 软件厂商,适合常见的任务,比如客服聊天机器人或读取标准发票。现成的产品可能比招人和找人开发都更好,所以在定制任何东西之前先核实这一点

要列出候选名单,就写一页纸:用一句话写清任务,系统可以看到哪些数据、这些数据可以去往哪里,带有正确答案的真实示例,每天的工作量,以及上线后由谁负责这个系统。把同一页纸发给三家类型合适的公司,像比较它们的方案一样仔细地比较它们提出的问题。如果条件允许,在签下整个开发项目之前,先付费做一个附带书面验收标准的小规模第一阶段。

amBrain 在其中处于什么位置?

在上面描述的几类公司中,amBrain 属于工程公司。

关于自己在语言模型方面的工作,amBrain 是这样说的:“我们已在一家客户的金融科技边界之内,将一项 LLM 集成投入生产:把非结构化的经纪商与交易场所通知——公司行动、金融工具与保证金变更——抽取并规范化为交易系统所消费的结构化记录。”客户未具名,该项目的任何数字也均未公布。

amBrain 用一句话描述它与客户的合作方式:“三种合作方式:整体交付、专属团队,或工程师嵌入你的团队。”关于所有权,它的说法是:“客户拥有产品与代码的全部所有权,我们的可复用组件除外。”请像对待其他任何公司一样,要求 amBrain 逐项列出这些组件的名称。

如果你现在就要做决定,就从上一节那一页纸的需求说明开始。把它发给 amBrain 或任何别家,然后比较收到的回复。

常见问题

  • 我们能不能先招一个 ML 工程师起步?可以,但一个人顾不过来带队、开发、数据和运维,而且内部也没有人能评判他的工作。如果先招一个人,就招一个能带队的人,其余的人以后再招进来
  • 外包是不是意味着我们的数据要离开公司?不一定。外部团队可以按照你的访问规则,在你的服务器或云账户之内工作,合同里也可以写明这一点。要专门问清楚日志和测试副本会去哪里,因为人们容易忘记的正是这些副本
  • 外包出去的系统,以后能收回到内部吗?可以,前提是上面那份交接清单从一开始就写进了合同。开发结束后再补上会更难,因为在工作还记忆犹新的时候,没有人写过评估集或处置手册

手头有类似的设计?

带上您当前的架构和让您担心的故障场景,我们用半小时一起梳理。