阿里资深Leader：组建技术团队的一些思考(6)

文档、数据、代码、评测在线化

①文档在线化：春节期间我建了个团队语雀，自己做顶层设计，写好框架，然后让同学们把业务、技术、资源、技术影响力等等和工作相关的内容都填写其中。

这样子，每个同学都可以看到团队的各种信息和资源，以及其他人的工作。目前团队的语雀还对部分关联紧密的兄弟团队完全开放。

②数据在线化：如果同学们各自管理自己的数据，形成数据孤岛不说，发生机器重装，或者转岗、离职，往往数据就丢了。

接手的时候，能清理出来的有标签数据远远低于应有的数量，就是因为一直没有做数据的在线化管理。

团队里的言奇同学做了样本大表项目，已经完成了将整个智能认知团队的全面标签数据在线化。

这一点非常重要，后续在开发各种新模型，以及做预训练模型时，就拥有不同业务不同场景不同风险的大量数据，在短时间内取得了良好的效果。

③代码在线化：这个正在进行中，预期 S2 结束时完成。

出发点是：

代码是团队重要的技术资产，应该统一管理，提高安全性。

在线化后方便团队协作，共享优秀代码。

基础性模块代码统一，降低维护成本。

④评测在线化：也在进行中，设想是在一些特定任务上做几种经典模型和确认无误的主流模型，能够一键实现自己的模型和前者的自动化比对，提升工作效率。

除此之外还有个作用：经典模型的结果可以作为 baseline，帮助验证深度模型的正确性。

因为，你做了一个深度模型，效果好也就罢了，效果不好的时候都搞不清楚是模型不适用，还是自己的代码写错了。

找对前进的方向

主管最重要的职责之一是当同学们迷茫的时候明确前进的方向。

接着前面商业化的例子，详细情况是这样的：我们通过阿里云对外输出文本风险识别的算法能力做商业化，比如涉政、色情低俗、广告、辱骂等。

我接手的时候，有 3-4 个同学全职投入这项工作，他们工作非常努力，干得也很辛苦，但是效果并不好， PK 竞品的时候并无胜算。出了什么问题呢?

分析之后，我发现以下问题：

①确实是一个内容维度的问题，但只使用了分类模型一种方式。

分类模型适合解决静态标准的问题，并不适合及时响应业务上的快速变化。模型迭代更新的速度做到极限也只能是 T+1 或者 T+2 天，且人力消耗高。

之前的主管为了解决这个问题，在分类模型中塞了一个风险词包，由算法同学维护更新，接到运营反馈的 badcase 之后手动添加到风险词包，然后定时推送到分类模型应用中。

这个复杂的机制带来了词典的频繁构建，结果导致应用的稳定性问题频发，甚至已经无法更新。

②缺乏顶层设计，同学们各自为战。

几个风险各自单独做模型，技术选型高度自由，百花齐放，starspace、SVM、CRF、kenlm、textCNN 都有，难以统一提升能力，维护的难度大。

③做了过多的个性化定制，导致后续维护和升级的成本非常高。

几乎为每一个稍微大一点的用户都单独做了模型，付费调用量不大，模型倒是有了好几十个。同学们频繁地做模型的迭代更新(每周都至少有 1-2 次)，占用大量人力。

怎么办呢?建设技术体系去解决某一类问题，而不是某个技术点去解决某一个问题;结合安全业务的特点，设计可以强化通用算法效果的基础能力或处理框架。

上面两句话不是我说的，来源于前主管。(插一句：本文还有一些内容来源于前主管和主管，向主管学习是提升自己的一个重要途径。)

具体来说，解法有几点：

明确风险词包、相似性检索、分类模型、风险知识图谱 4 种手段适合完成的任务，且相互配合。

把风险词包从分类模型中拆出来，降低应用的复杂度，以及模型迭代的频率，解决稳定性问题。

分类模型的结构尽可能统一，标准尽可能不变，持续把效果做强。

自从 BERT 提出以来，NLP 问题的基本范式从原来的 task-specific 的模型结构设计转变到语言模型 pretrain+ 下游任务 finetuning 的模式。工作重点应该转向预训练模型与知识蒸馏。

由于目前对内的内容交互风险管控业务也在我的团队内，我就贴一张全局视角的问题分析与解决方案。

全局视角的 UGC 风险管控思路

明确解法之后，同学们快速做了实践，到 4 月份就基本扭转了被动的局面，随后打了翻身仗，付费调用量增长 25 倍。

现在模型的更新周期降低到以月为周期，稳定性大幅度提升，同学们也不再疲于奔命;而且，投入的人力也明显下降了。

绩效的考核

绩效考核决定了收益的分配，也是团队最重要的事情之一。

如果把团队比作一个模型，考核的标准就是 loss function。loss function 一旦确定，模型的优化方向也就定了，团队成员会按照利益最大化原则沿着这个方向调整自己的 action 。

所以，考核标准的设计需要体现团队的定位、价值和需求;在执行的过程中需要满足平等性。

（编辑：ASP站长网）