赞
踩
1、实际业务项目的理解、完成、平衡
•对业务理解,分析问题,能够抽象成具体的技术问题,形成正确的思路和方法
为什么强调这一点?因为,很多时候大家对业务问题表达的比较清晰,但是还是都站在一个业务方的角度,因为我们是要做技术的,要用技术把它实现,所以怎么把业务问题定义成一个技术问题,这里还不是特别清晰,这点很重要。举个例子:比方说我们要做一个像车牌识别,那么具体有几步?有检测的问题,然后具体还有切字,还有识别的问题,甚至其他的一些内容把它定义成一个分割问题,对不对?就是怎么样把业务问题转化成技术问题,这是一个重要的能力,也是我们技术进行业务落地的第一步,这里自然而然就涉及到一个问题,就是对这个业务问题我们定义成什么样的一个技术问题比较合适。即使面对同样的一个业务问题也可以定义成不同的技术问题,比方说我们要去判断一个司机是否带着安全带,很简单,我们可以把它当做一个识别问题来对待---就看这个人有没有带安全带;一个分类问题;那么还可以作为一个检测问题,检测看看能不能检测到安全带在司机的身上;甚至我们可以把它定义成一个分割问题,对于每一个像素,它是不是安全带,还是人的身上的一个部位把它分割出来,这个业务问题定义成什么样的技术问题更合适,这个需要在长期的业务落地的过程中,不断的去打磨,不断的去积累,不断的去培养自己的这种感觉。
•理解业务要求的真实诉求,适当做出建议,最终要达到业务要求的精度
在做业务的时候,要从业务的角度来了解业务方的真正的诉求,提出一个合理的建议,最终达到一个业务的要求。这里需要我们对整个业务应用的场景有一个非常深入的理解,同时能够站在业务方的角度上思考问题。
并不是说业务对你提什么要求,然后你就做什么要求,这样做的话,你其实并不是一个真正好的技术人员,更别说AI架构师。换位思考一下,假设你是业务方,不管你提什么需求,作为解决方案提供者的小伙子都满足你,你顶多也只能给他一个评价,说这个小伙子干活很踏实。但是如果你能够站在业务方的角度,对整个产品的应用过程中可能会出现哪些问题,以及我们用什么样的一个方案去规避这些问题,从业务场景去出发,站在业务方的角度上去思考这个产品,提出一些合理的建议,以及根据这些建议设计一个解决方案。那么就相当于你确实能够帮他去解决,从他的角度来解决后续的一个产品整体的生命周期问题。
•关注时间、成本、质量三者是否能够有效平衡
对于产品研发,还要小心一个陷阱,有的时候经常在和业务方沟通的时候会发现一个问题:业务方说到什么样的产品,在市面上也有其他类似的产品。就觉得这个需求一定能实现,产品一定能做出来。这是一个陷阱,要考虑到做出这个产品,要跟自己的团队,跟自己的公司所处的阶段以及所拥有的资源进行一个整体的考量,并不是说别人能做出这个产品,那么我们花时间花精力,往里面死磕,就一定能搞出这个产品来,要整体的要达到一个平衡。
对于这点,还有一个方面就是在项目中要进行一个合理的模块拆解,尤其是时间这一块,有的时候大家会发现,做同样的一个项目,你的时间往往是别人做这个项目的时间的两到三倍,那么大概率是你整个模块划分没有做好,任务拆分没有做到位。
举个简单的例子,这个例子也非常经典的,华罗庚是咱们老一辈的无产阶级数学家,当时他也举过一个例子就是谈喝茶泡茶这件事情,一共分为像洗茶壶、烧开水、准备茶叶、泡茶,简单说分为4步,你怎么来做呢?那么有一个人他是这么做的,先把茶壶洗了,然后烧开水,开水烧完了之后,急急忙忙的去准备茶叶跟茶具好吧,然后把茶泡了。那么第二个人他可能是把茶壶洗了,然后在烧开水的过程中,他在准备茶叶跟茶具,最后等着水烧完了之后,这些所有的前续的这些工作也都做完了,慢慢的把茶泡完之后,等茶凉了喝。
这个时候就涉及到一个问题,哪个会更合理。显然是第二个方案,为什么这么说?在有一些能够并行的事情的时候,我们得把这个时间充分的利用起来,使得我们整个项目推进能够更快速更高效的进行。当然讲的也只是说对于一个人做一个任务,那么在多个团队配合的时候,或者多个流程多个人共同协作的时候,这个问题会变得更加的突出。
再举一个例,比如说我们整个AI开发团队要开发一个模型,里面包括有数据标注,模型训练,还有工程化的开发,最后模块的测试以及合入系统。假如就这5大步,那么怎么样去进行一个比较好的划分?如果你没有数据,肯定就没有办法进行模拟训练,所以数据标注肯定是先要搞,但是在搞数据标注的过程中,其实其他有些工作是可以并行的,其实工程化开发是可以并行的,因为你数据最后标注完了之后训练出来模型,基本上大概率可以用一个初始化的模型,例如随机噪声初始化的一个,或ImageNet初始化的一个模型,或者精度不太高的模型去替待,然后做后续的工程化开发。那么工程化开发完了之后,正常流程的话,我们要把它进行一个模块测试,看看有没有内存泄漏,看看这些功能是不是都满足,之后才会合入到整个系统进行联调。
但是其实这里面还有个地方可以并行,就是说我们在工程化开发完了之后,可以让一个同学做这个模块的测试,然后另外一个同学就把没有测试的开发出来的东西先就合入到系统,去进行联调,对接口,对联调的一些功能。如果后面的合入系统整个过程都通过了的话,就可以直接把测试通过的模块直接拿过来就用就可以了,就不需要按照正常的、传统的这样的串行的一个个流程走下去,这里面整个5个模块其实是有3个都可以并行去做,那么甚至今天我要在整个流程,只要是多流程的时候也可以运行,比方说像你的一个项目分成了多个模块,如果是以上下游这样的一个模块一个关系,这个时候,假如下游需要的一些数据,我们可以用一些仿真数据,或者是用一些我们标注的数据,模拟上游的一个输出结果,然后来进行下一个模块的开发。如果可以的话,那么我们整个多模块,一个串型的多模块是可以用并行的这种开发方式进行开发的。
这就是所说的,怎么样能够使得时间成本和质量达到更加有效的一个平衡,更加快速的往前推进。
2、技术方案“本身的预见性”,根据业务有长线且合理的规划
•项目技术方案的可持续性,从公司更大层面的技术设计,未来是否可优化,可持续
这点主要就是说要针对咱们公司的现状,还有业务线,去考虑5年之后,公司期望做成一个什么样子?是在哪些赛道上进行发力。需要储备哪些技术能力?那么你在现在的时候就要为5年之后或者10年之后,为公司所需要的这些能力进行一些布局,进行一些提前的规划。
3、个人较为全面的技术素质及储备
•个人的技术素质,知道什么问题可以用什么技术解决,什么技术可以做到什么程度,可以从哪里借力
AI架构师,作为一个tech leader, 个人能力始终是要不断的往前去提升的,不断的去丰富自己。那么这里面也是从三个方面去说明,第一个方面就是在技术的储备量,技术边界以及技术工具,还有一些技术平台方面,那么自然解决的问题就是如何利用技术储备量把这个产品做好,知道用什么样的技术去实现。本身AI技术的发展日新月异,像早些年,那么当时做分割的话,基本上都是用马尔科夫场,然后去用线性传递这些优化器,去解一个数学模型,那么现在基本上都是堆一个网络就直接开始训练了。
有些人可能认为,是不是反正这技术发展也快,我用到的时候再学呗。那么如果有这样的一个想法的话,你最后到真正用的时候,会惊奇的发现,结果会让你大失所望。因为整个技术都是一脉相承的,在一个不断的演化的过程中,所以你只有认识了他爷爷,才能认识到孙子是一样的道理,就是你在该领域之前的一些知识如果完全不了解,最新的技术也很难跟得上。
所以这块还是要不断的保持着一个技术状态和感觉。在技术边界这方面,就是要清楚现在例如像分割、检测,还有识别以及跟踪等等这些技术,大概对于你的这个业务场景下,这样的一批数据能做到一个什么样的准确率。现在在学术界也好,工业界也好,技术达到一个什么样的水平。比方说像ImageNet这样一个大规模的识别任务,在2012年之前,整个算法的识别率是远远要低于人类的,后来深度学习出来之后,不断的提升,那么2012年之后机器的一个识别准确率已经要高于人类的一个准确率了。所以基本上在识别任务上,大家比较流行的一个说法就是:你人眼能够看出来的问题,用网络去做,基本上在数据量够的话,是能得到一个很好的解决的。这就是一个识别的技术边界,从2012年之前到我们现在还不断的推进的一个过程中,算法所能够达到的一个不同的高度,那么在这一块的话大家一定要有些感觉,因为你有感觉之后你就能够知道有的时候业务方提出来的任务到底是能做还是不能做,有的时候你可能两个月做出来,两个月做不出来,不一定是他不能做,有可能是确实没有找到一个好的方法。但是有一些问题是这个问题用现在的这些技术他真的就没办法解决,那么对于这种问题,就一定不要让自己的团队掉到陷阱里面去。
说到从哪里可以借力,主要说的是一些技术工具,还有技术平台。比如你想知道最新的一些科研成果可以去百度学术或者google scholar这些都可以。以及其他一些平台,例如AIStudio,会提供现有的模型,甚至有的已经封装成一些解决方案,这些都是可以从中得到一些基础技术能力的加持,以及一些公开的数据集,比方说像做3D的大家知道的是ShapeNet,还有像ImageNet可能是大家耳熟能详的,还有Object365-检测任务的大型数据集,以及做交通场景的,像Kitty。所以,当你面对这些任务时,从哪里能拿到数据,从哪里能拿到知识,从哪里能拿到模型,最主要的是三方面。这是需要去关注的一个内容。
•储备面对主流需求的完整技术栈,并知道技术栈里的每个技术未来可以怎么优化,具体到选型、数据量、优化方法
这其实就是对前面说的技术能力的细化了,得到完整的技术栈以及知道技术栈未来的发展方向,或者现在技术方向上大家研究的一个趋势,是往哪个方向去研究,以及哪些问题没有被解决,哪些问题已经得到很好的解决了,这些都会对你后续怎样去选定技术路线,选定你的优化方向和选择什么方法,起到一个很好的帮助作用。
还有说到数据量的问题,经常听到有同学问,说要多少数据能够把这个问题解决掉,这个问题其实没有一个统一的答案。一个相对的指导性意见是你先做出来一个初版模型,用一定的数据量,比方说1万的数据,无论是检测、分割、识别任务也好,先用1万个数据做出一个初版的模型,然后你再加上2倍或者5倍的数据,看一下能到一个什么样的程度。一般你的指标是和数据量的指数是呈现性有关系的。 那为什么说先做了看一下呢?因为不同的任务的难易程度是不一样的,比方说分类问题,假如说区分人和狗和区分猫和狗,它所需要的数据量也是不同的,对不对?这个是没有一个统一答案的,就是你要去看,一般人一眼能够看出来,并且场景不复杂的,可能几百个数据就能够把这个问题解决。但是具体到你的业务场景,业务场景有多样化,是需要一个AI架构师自己去分析、判断的。
•个人对技术团队的影响力
这其实是一个相对比较高一点的要求,因为作为一个架构师,你要带领一群团队去打仗,不是单打独斗。那么这里面技术能力包括几方面,一方面是整个团队的技术能力的一个提升,那么这里面就需要去了解团队中每一个组员他的技术能力的特点,尽量让团队中的每个同学沿着它既定的技术方向把它越做越深,而不要按照业务去拆分,比方说这个人负责一个业务,那么这个业务里面可能既有分割又检测又有识别,他什么东西都搞一点,然后另外一个人也是负责另外一个业务,也是这三个东西,都是这三种技术都要涉及到,那么他也是这三个东西,每种都学一点,然后这样就不太好,无法在自己的专深领域做深做透。所以就是你要知道团队每个成员所擅长的技术特点,按照他的技术能力,把他的技术擅长点进行拆分之后,在整个团队中一起去做项目,把不同的技术点整合起来。
那么就是不但个人的技术能力要不断的提升,整体团队的技术能力也需要不断的往前去提升。可以按照这样的方式,例如:按照不同的技术方向让大家每周做 Paper Reading,比方说你是做检测的好,你可以沿着检测方向一起去做,那么每一周的话,检测方向上假如说有4个同学,那么每个同学的话每周会读两篇论文,然后这两篇论文的话会在团队内部去跟大家一起去分享。以一种PPT的形式,就是把这个论文中最新的一些技术,还有你觉得哪些点是对我们哪些项目有用,将这些东西大家跟大家分享一下,然后大家轮流去做。而且做完了PPT之后,用一个类似wiki的东西把它保留下来,这样时不时大家可以回头去温习一下之前看过的一些Paper或者一些技术方案,那么对团队整个技术能力的提升也是很有帮助的。
还要说的就是一个工作和合作流程、合作规范,这可能真的是按照不同的业务特点,可能会有不同的合作流程和规范了。比方说举个例子,就是说我们策略团队和工程团队怎么去分工,怎么去合作,假如说是一个平台化的产品,它对外部客户来说是一个统一的解决方案,这种情况尽量让工程团队做一个比较统一的架构,然后策略同学直接在架构上面进行开发,然后统一的接口进行开放。这样的话是比较友好的;那么如果咱们团队是做一个To B定制化的产品,那么大概率,因为你像外面To B的客户的话,买一个产品,它的交付的端口,还有客户交付的需求都是不一样的。那么这一块的话基本上是工程团队会离交互侧会更近一点。所以在接口的定义这里,基本上是交给工程团队去做,基本上不能是从策略同学、策略团队里面出一个统一的交接口,这样交给外部的客户,外面的使用者拿到这个东西会疯掉了,因为它会有一些不同的需求,所以怎么样去梳理合作的流程以及模块或者说是每一个团队所负责的任务,也是需要AI架构师根据业务的特点进行思考和调整。
最后想跟大家说的就是整个团队的建设和人才的培养,就是当你开始能带五六个人的团队的时候,你就要开始考虑怎么让你下面的人,他们也能够去带领一个五六个人的团队,因为管理上面有一个说法,就是一个人能够有效管理的人基本上就是5~6个人。所以如果你手下平行的管了10个人,不好意思,大概你的管理是不到位的,你基本上能够有效管理的就是6个人,那么你如果想团队继续扩大的话,那么需要你这个团队当中有些人能够承担起管理下一层团队这样的一个任务。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。