AI团队组织折腾手记

带 AI 团队两年，最头疼的是人和人的接口怎么划清——比调参烦多了。

事情是怎么走到这一步的

刚开始以为，团队里找几个有Kaggle经验的人，再加几个能写API的工程师，就能开干了。三个月下来，倒是把模型跑起来了，但产品经理拿到结果说"这东西用户不会这么用"，工程师说"模型就是这样训练的"，AI工程师说"你们到底要什么指标"。

场面一度很尴尬。

之后花了半年时间把团队结构、协作流程、角色边界翻来覆去调整了几轮，踩了不少坑，也算摸到了一点规律。下面把这几轮调整记下来，给同样在带 AI 团队的人当个对照。

起初踩过的坑

问题一：角色边界模糊

最早团队里所有人的title都是"AI工程师"，但到底做什么没人说得清。有人天天调模型超参数，有人盯着服务器GPU利用率，有人在跟产品经理对需求，还有人把时间花在写Swagger文档。

三个月review的时候发现，模型性能没什么变化，但每个人都在忙。

后来拆成了三个角色：

• AI算法工程师：专注模型训练、数据管道、实验管理
• MLOps工程师：负责模型部署、监控、基础设施
• AI产品工程师：夹在算法和产品之间，负责对齐需求、设计API、落地方案

说起来简单，但实际执行起来还会越界。比如算法工程师直接把模型压缩代码写到训练脚本里，产品工程师看到训练轮次太多直接改了配置。最后只好在代码仓库里明确目录结构，每个角色有自己的主战场。

问题二：评审流程卡住

早期每次需求评审都像吵架。产品说"要做个性化推荐"，算法说"需要冷启动数据"，产品说"先上线再说"，算法说"数据不够模型根本学不出来"。

问题在于双方不在一个频道里。

后来改了评审流程，产品提需求前必须先填一张表：

• 业务目标是什么（要写具体指标，比如"提高日活留存 2%"，别写"提升用户体验"）
• 用户行为数据有没有埋点
• 离线指标和线上指标怎么对齐
• 现有数据够不够，不够的话怎么补

这张表填不清楚，需求就不往下走。前期麻烦一点，但后面少了很多返工。

实际的组织结构

把角色和流程理清楚之后，团队结构慢慢稳定下来。

核心角色分工

这个图只是个理想状态，实际上协作会更复杂。比如算法工程师调模型时，可能会发现数据质量有问题，需要MLOps调整ETL流程；产品工程师在评估效果时，可能会发现模型输出格式不符合前端使用习惯，需要算法工程师改后处理逻辑。

跨角色协作的几个约定

为了减少沟通成本，团队内部定了几个约定：

1. 实验记录公开：所有模型实验记录在共享文档里，包含数据版本、代码版本、超参数、指标。谁都可以看，避免重复实验。

2. 模型接口先行：新模型开发前，先定义好输入输出格式，不一定要完整API，至少有清晰的schema文档。

3. 上线标准明确：模型上线前必须满足几项硬性指标：AUC > 0.75、线上A/B测试p-value < 0.05、延迟 < 100ms。不满足的不上，避免匆忙上线给业务造成负面影响。

4. 回滚策略预设：每次上线模型时，必须同时准备回滚方案，包括回滚到上一版本的步骤、回滚的数据保留时间、回滚后如何通知业务方。

几个真实的案例

案例一：推荐系统的上线节奏

去年做内容推荐时，踩过一个大坑。算法团队花了一个月把模型从0.72刷到0.78，兴冲冲上线，结果用户点击率反而掉了2%。

问题出在几个地方：

1. 离线评估用的是历史数据，但线上用户行为在变，模型学到的过时特征反而起了反作用
2. 模型输出的概率值直接按排序展示，但没有考虑内容的新鲜度、多样性，导致用户看到的内容都很类似
3. 上线前没有跟运营对齐推荐逻辑，他们不知道为什么有些内容被推上去，有些被压下来

后来改了策略：

• 训练数据只取最近两周的用户行为
• 排序时加入时间衰减和多样性打散
• 模型上线前，先跟运营同步推荐规则文档，让他们理解模型的偏好和局限

这次折腾之后，团队内部形成了"离线指标是参考，线上指标才是硬道理"的共识。

案例二：模型压缩的协作问题

另一个坑出现在模型压缩上。算法工程师为了把模型从50MB压缩到10MB，直接把浮点32位改成8位整型，模型大小确实下来了，但推理精度从0.78掉到0.71，业务方不接受。

问题在于，算法工程师只看了模型体积指标，但忽略了业务真正关心的是精度和成本之间的平衡。

后来改成两步走：

1. 先跟业务方对齐，明确可以接受的精度损失范围（比如0.78降到0.75可以接受）
2. 在这个约束条件下，尝试不同的压缩方案（剪枝、蒸馏、量化），记录每种方案的精度和压缩率

最终采用了知识蒸馏方案，把精度保持在0.76，模型体积压缩到18MB，业务方能接受，服务器成本也降下来。

实际遇到的一些边界问题

问题：小团队要不要设这么多角色？

有些小团队觉得，只有三五个人，拆这么细会不会效率反而低？

确实，如果团队只有3-4个人，硬要按照"算法/MLOps/产品"三个角色拆分，反而会导致一个人干三个人的活，责任边界不清。

这种情况下，可以考虑：

• 设立"AI工程师"通用角色，但明确每个人当前的主战场
• 一个周期内（比如一个月），一个人只重点负责一件事
• 关键环节（如上线评审）必须有跨角色视角的人参与，避免单一视角决策

问题：AI工程师要不要写业务代码？

这是个常见争议。有的公司要求AI工程师什么都写，从模型训练到前端都要会；有的公司严格限制AI工程师只碰模型代码。

我的经验是，AI工程师应该懂业务代码，但不一定要自己写。

原因很简单：

1. 懂业务代码，才能知道模型输出在业务里怎么用，避免模型设计脱离实际
2. 但让AI工程师花大量时间写业务逻辑，反而会影响他在算法上的精进

折中方案是：

• AI工程师在项目早期参与业务架构设计
• 关键的业务逻辑（如模型输出如何影响前端展示）由AI工程师和后端工程师共同review
• 实际编码以后端工程师为主，AI工程师只在必要时上手

工具和基础设施

团队协作顺畅，离不开工具支撑。我们用的一些东西：

1. 实验追踪：用MLflow记录实验，包括代码版本、数据版本、超参数、指标。避免"三个月前这个模型怎么训练的"这种问题。

2. 模型注册：模型训练完成后，注册到中心仓库，附上元数据（训练数据版本、评估指标、作者、时间）。上线时只从注册中心拉模型，避免随便复制文件导致版本混乱。

3. CI/CD流水线：模型训练、评估、测试、打包、部署全部自动化。一次手动触发，后续全部流水线执行，减少人工操作失误。

4. 监控告警：上线后监控模型输入分布、输出分布、延迟、错误率。分布偏移超过阈值时自动告警，避免模型性能退化没人发现。

这些工具用起来前期要投入时间，但后期确实能省不少心。

写在后面

带AI团队两年，最大的感触是，AI团队的组织跟传统软件团队最大的不同在于，不确定性。

传统软件团队可以通过严格的流程控制质量，但AI项目很多结果不可预测。模型效果好不好，有时候跑了实验才知道；用户会不会买账，有时候上线了才知道。

这种不确定性对组织协作提出了更高要求：角色边界要清晰，但又要灵活应对变化；流程要规范，但又要允许探索；工具要自动化，但又要能支撑快速迭代。

没什么标准答案，适合自己团队的才是最好的。如果你也在带AI团队，希望这篇文章能给你一点参考，至少帮你避开一些我们已经踩过的坑。

最后一句真话：团队组织这件事，从来没有完成的时候。业务在变，人在变，团队结构也得跟着调整。持续观察、持续复盘，可能比一开始就设计一个"完美结构"更有用。

参考

• 《Machine Learning Engineering in Action》
• 《Designing Machine Learning Systems》
• 《Effective Data Science Infrastructure》

版权声明: 本文首发于 指尖魔法屋-AI团队组织折腾手记（https://blog.thinkmoon.cn/post/999-ai-team-organization-practice/） 转载或引用必须申明原指尖魔法屋来源及源地址！