为什么数据分析师需要懂算法？

赵小洛 2023-07-28 12:13:50

通过和一些朋友交流，发现目前一些数据分析师，其实不是很清楚机器学习可以如何应用于业务，也不清楚自己到底要不要去学习算法知识。实际业务中一些复杂算法场景例如商品推荐、内容推荐、匹配策略等，其实都需要数据分析师做大量的探索验证工作。

分析师前期可以为建模指导方向，中后期也为模型的优化提供一些新的思路与数据洞察，此外用算法还可以大大提升分析效率与分析科学性。今天，就让我们详细的来了解一下数据分析师与算法的前世今生。

本篇目录：

对算法的一些理解
哪些场景下需要用到机器学习算法
算法的产出物及形态，如何应用于业务
为什么数据分析师需要会机器学习
数据分析师与算法工程师的职责差异
实际业务中如何分工配合可以效用最大化
数据分析师应该掌握的程度

一、对算法的一些理解

在讲分析师与算法之前，先来理解一下什么是算法（Algorithm），专业术语在很多书籍、文章里面都有分别的定义，通俗一点理解，大致上可以认为算法是为了解决某个问题的固定化计算方法与步骤。

拆解一下上面这句话：

目的：为了解决某个/某类问题，需要在这之前了解到背后的业务背景、关联场景；
方法：通过计算来实现，也就意味着需要具备具体的、可量化的信息输入，且可计算，而非不可执行的概念体；
步骤：有先后顺序，先做什么然后做什么最后做什么，每个过程之间还必须具备可行性，执行次数也一定是有限的；
结论：是否能够解决这个问题，效果如何，最终必须得有一个产出物。在算法之外，还有几层扩展；
决策：根据一个或者多个结论进行判断，这个过程是不是符合预期的，如何调整优化，是否可直接应用于业务；
应用拓展：除了解决最初的那个问题外，还有哪些同质类型的问题也可以得到解决，也就是场景的拓展。

具体的算法搭建过程就不说了，在不少工具书、专业书、案例书里面都有非常详细的讲解。回到问题上，什么场景下需要用到算法去解决问题。举几个生活里面的例子：

譬如说做菜：为了能吃的更好点，选择一本合适的食谱来准备食材、辅料，根据步骤和技巧“小火炖、中火炸、大火炒”，“一炒、二炖、三焖、四涮”，起锅装盘；
譬如上学：从家门出发，直走50米，第一个十字路口右转，继续直行100米，到达公交站，乘402路车，5站后下车，沿人行道继续行走200米，左转，再直行150米，最终到达校门。

这些都可以理解为算法，生活里面比比皆是，不过多数情况下成为了我们习惯的一种方式罢了。

二、哪些场景下需要用到机器学习算法

在很多场景下都需要用到机器学习算法，换一个角度，来说说我对应用场景的理解。本质上说，我过去的一些项目里面通过算法解决的问题大致上可以分为这么几类

1. 供需匹配的问题

量变产生质变，过去的十年时间，无论是在B2C，还是B2B、S2B、B2G，我们去建立用户画像做精准营销、做好推荐系统实现千人千面、对用户进行分层分类打标签、给用户的评价信息划分情绪好坏等等，都是为了更好的去做供需关系管理匹配。

视频个性化推荐是供需管理，商品个性化推荐是供需管理，网约车是供需管理，供需管理即“ 谁可以找谁消费到一件相对比较合适的东西（内容、物品、信息、线索、商机），在这个过程中还可能需要通过哪几个谁才能打通彼此之间的联系。”

衍生出的问题立马就出现了，如何从千万级甚至亿级的商品里面去做匹配召回，如何从万亿级的会话内容信息中定位线索，如何明确哪些人才是我们目标的特定人群，如何把相应的信息通过什么渠道push到最合适的人，如何去做到好的触达，又如何去回收这些人收到信息之后的反馈效果。

如果只有几千条数据，一个团队里面10来个人，每个人分个百来条逐一去确认，则不需通过分析也能实现，耗费的只不过是人力上的一些时间投入。

所以日常对接需求过程中，接到一个需求时，一般会先进行资源匹配评估，这个事情能不能通过叠人力的方式解决，如果通过线下大概需要花多少人力成本，用一些小样本数据的归纳总结能不能得出通用的规则。做调研然后去推行的成本有多少，产出有多少。

再之后才是通过算法方案去解决，投入的工程师要几人月，设备资源性能上的要求，能够持续多久，可以影响的层面，以及最后的产出估测。最后再综合考虑，这个投入产出比的情况下，到底是通过小数据分析去形成规则，还是需要通过算法去挖掘特征，以及方案的可持续性。

大公司里面资源较丰富，往往这两者会并行。从某种程度也就严格的区分了数据分析和数据算法间的职责边界；而中小企业资源有限，可能造成分析即算法的现象。

我们发现，供需匹配过程中涉及的算法，基本都是有监督算法，不论是人群分类、商品召回、需求匹配，都可以通过过去的经验进行一个初步标签建立，然后逐步去对划分的准确性进行校验和优化。

值得一谈的是，在供需的某些场景过程中会并存很多涉及物联网的知识，譬如物流调度、配送匹配、路线优化、仓库建设等等供应链优化方面的事情，这些场景下除了算法外，还需要去了解下运筹学的内容。

2. 异常识别和诊断

异常检测，在前几年p2p还没有暴雷的时候，金融领域里面遍地都是，主要的场景就是风控，风控的场景细分：

信用卡交易反欺诈：分类任务，GBDT算法 / XGBT算法+LR逻辑回归；
信用卡申请反欺诈：分类任务，GBDT算法 / XGBT算法+LR逻辑回归；
贷款申请反欺诈：分类任务，GBDT算法 / XGBT算法+LR逻辑回归；
反洗钱：分类任务，GBDT算法 / XGBT算法+LR逻辑回归。

金融领域涉及到风控的几乎都是GBDT / XGBT+LR，因为在金融行业有一个非常特别的属性：监管。

对于算法结果必须有非常好的模型解释，对于LR模型来说，这是天然的优势，特征可解释，特征工程清晰，每个特征的贡献度、相关程度也可以被统计出来。

换了其他深度学习的模型，从最终的模型效果上来看，roc/auc/ks的表现没差，但是解释性极差，也就造成了很多应用上的壁垒。换一个通俗点说法，你很高级，然而并不实用，华而不实。

3. 排序

排序之所以单拎出来，它的应用场景其实有一定的局限性，但是怎么做好排序，客观、合理，却是一个值得去考究的事情。常见的排序应用场景有热点榜单、搜索排序、推荐排序等。

知乎的问题回答排序是一个经典的排序应用场景，既要保证优质高赞内容可以排在前面被用户浏览，又要保证新增内容有一定曝光量，同时需要综合考虑话题热度及社区调性等多重因素。

故需要将回答赞/踩数量、回答用户该领域权威性、赞/踩用户领域权威性、回答时间、回答争议性、回答用户的历史画像特征等综合权重进行算法排序。

4. 预测

数值预测与分类预测都属于预测场景。销售预测、股票预测、流量预测，这些都是常见的预测场景。11、12年的时候清一色的都会用arima，spss在手天下我有，没有什么是时序不能解决的，到后面就变成xgboost、LightGBM了。

5. 知识图谱

2012年的时候google推出了一个叫Knowledge Graph的产品，能够直观的看到词和其背后知识的关系。

很多大公司都已经在知识图谱的建设上进行布局了，知识图谱最早的应用是提升搜索引擎的能力，随后在辅助智能问答、自然语言理解、大数据分析、推荐计算、物联网设备互联、可解释性人工智能等多个方面展现出丰富的应用价值，这几年推广比较成功的应该是AI辅助司法进行案件判决。

信息检索/搜索：搜索引擎中对实体信息的精准聚合和匹配、对关键词的理解以及对搜索意图的语义分析等；
自然语言理解：知识图谱中的知识作为理解自然语言中实体和关系的背景信息；
问答系统：匹配问答模式和知识图谱中知识子图之间的映射；
推荐系统：将知识图谱作为一种辅助信息集成到推荐系统中以提供更加精准的推荐选项，知识图谱+推荐系统；
电子商务：构建商品的知识图谱用于精准匹配用户的购买意愿和商品候选集，知识图谱+推荐系统；
金融风控：利用实体之间的关系分析金融活动的风险以提供在风险触发后的补救措施（如反欺诈等）；
公安刑侦：分析实体和实体之间的关系获取案件线索等；
司法辅助：法律条文的结构化表示和查询用于辅助案件的判决等；
教育医疗：提供可视化的知识表示，用于药物分析、疾病诊断等；
社交类业务：社交类业务具备高度连接的特点，比如好友关系等，<用户1，关注，用户2>。

三、算法的产出物及形态，如何应用于业务

我们最近常听到的一个词叫“大数据杀熟”，应该是算法在业务上非常常用的一种应用场景。通常来说，算法的产出物有两种，第一种是算法产出的结果（分群、分类、预测值），第二种是算法产出的规则。

1. 产出结果

降维：无论是对数据的分类，还是对数值的预测，对业务应用都可以作为筛选对象，进一步缩小目标，找到清晰的划分边界。在一些临界点上算法会减少人力决策成本，从诸多策略中选择最优去做尝试；
精细化：把结果作为标签，结合CRM、广告系统、营销系统，帮助业务更便捷、更精准地获取信息，强化用户感知，制造新奇感引起用户注意，设置规则以提升用户使用黏性；
策略：降低成本、提效增益，算法本质上解决的就是这两件事情，算法产出结果可以有效的支撑策略制定，论证是或否的可行性。

2. 产出规则

很多时候我们往往只会关注到了结果本身，准确性、精确率、召回率怎么样，却忽略了算法产生的规则层应用。前面提到过的模型可解释性，其实就是一种规则的具象化。

在关联分析中，有提到过强相关、弱相关、不相关。作为一名业务，他可以说这个产出结果通过业务经验也能知道，而作为分析，则需要把所谓“经验”演绎为规则，这个规则就是通过数字串联起来的。

于算法而言，在模型解释时，也会碰到一些特征具备很强的规则，但往往容易只看数据结果，却忽略了其在实际业务过程中的意义和因果关系，于是造成了“算法分析出的结果不如根据经验拍脑袋决策”的现象。

四、为什么数据分析师需要会机器学习

我们先明确一个概念，即数据分析，它既可以作为一个社会中职业人的附加技能存在，也可以作为一个社会中职业人的主干职业进行发展。

1. 多数情况下，我们仅在迎合这个世界的法则，却并未去思考它为什么存在

在挖掘分析应用的项目中，算法是核心要素，大部分算法的实现原理，都会涉及一些高等数学知识。

数学本身非常抽象，学的快忘的快，自然而然算法对很多人来说具备某种神秘感。人类的好奇心和上进心，促进了人类的进化与生存，所以我要揭开那层神秘面纱去学习。

同样人也会经常高估自己的毅力及短期内可取得成果，所以往往是：费劲周折投入大量时间搞明白几个算法原理实现后，就再也没有继续坚持下去。此时可能走向一个极端，只要能使用第三方的算法库在自己的电脑中成功运行并能输出结果就可以，效果不好就再换一个算法尝试。

2. 数据分析为了达成业务目标，可以使用算法来进行快速论证

分析师懂算法非常有必要，最近几年，数据分析师的岗位职责中，或多或少会写一些算法相关要求。

我的认知是，初级分析师不需要懂算法即可cover大部分的工作内容。但是要想职业更上一层楼，增强分析的科学性严谨性和效率性，尤其是涉及算法策略驱动的业务类型中，分析师必须懂一些常用机器学习算法。

其实分析的重点还是聚焦在对目标问题的拆解、论证与实现上，对于绝大多数分析师而言，业务需求特征大致可归纳为，交付时间短、实现成效快、数据维度丰富、结论支撑足够、方便报告汇报。

大部分业务分析的场景都可以通过类似杜邦分析的方法进行层层下钻拆解，而这个过程对数学知识以及算法知识的涉及可能非常少。

业界已经有了非常多成熟的算法应用实践，有的时候为了做数据论证和探索，就需要用到类似算法，其目的是用最短的时间找到一个可以去下结论的突破点。于是在实际应用时会碰到一个前提，即每种算法都有其合适的应用场景及前置条件，且当具体使用时超级参数的影响也非常大。

所以如果我们不从更高层次去理解和对待算法，那么在实际运用时，就可能如刻舟求剑，难以取得预想效果或者过早的否掉一个本可以恰当解决当前问题的算法模型，只因为相关的工作没有足够的重视（例如数据清洗、特征选取方式不合理）。

skl包提供了大量简单函数，为了快速运用这些函数解决实际问题，我们不得不花时间去了解算法的内部原理及实现细节。建筑设计师不需要精通制造钢筋水泥的工艺，但需要了解不同钢铁、水泥的性质用途及之间配合关系，道理同样适用在这个环节。

3. 分析师要更好成长，横向知识储备必不可少

数据分析师的成长就像一场马拉松，需要合理分配时间精力。专注力和自制力是一种稀缺资源，需要用在最合适的地方。经常提醒自己的目标是什么，才能把事情做好，对于分析师来说尤其如此。

不仅仅是算法，在这个大的社会环境下，对于市场、行业、细分领域、垂直领域、岗位、职业、技术、技能、商业很多个方面都需要有所涉猎，因为分析只是一个技能，把它作为职业更需要贴切实际场景下做出相应合理的策略。

五、数据分析师与算法工程师的职责差异

1. 数据分析师的要求

懂业务是前提：视野需要尽可能宽，需要去了解行业大盘、市场动态、公司业务、商业模式、业务流程，建立自己的认知和判别思维，在指定场景下能够去用科学严谨的方法得出合理结论；
懂分析是核心：数据分析的基本方法原理、专业高效的数据分析方法论、灵活性的组合技巧运用、结合业务的适用分析方法论、高度的数据敏感性；
懂汇报是台阶：好的分析离不开好的报告，好的报告离不开好的汇报技巧，在谁的面前怎么说话，说什么话，也是一项技术活儿。

2. 算法工程师的要求

懂技术是前提：不同的算法可能用不同的时间、空间或效率来完成同样的任务，算法的运行效能需要具备一定的coding技术支撑。
专业极其细分：按照研究方向划分，主要是视频算法工程师、图像处理算法工程师、音频算法工程师、通信基带算法工程师、信号算法工程师、NLP算法工程师、生物医学信号算法工程师等知识深度宽泛。

3. 两者的共性和差异

共性：都需要对数据进行探索，发觉数据之间的模式和规律，从而运用一些列的规则和公式来解决实际的问题（都要读统计学、概率论）；
区别：数据分析通过一些传统的方法来解决实际问题，门槛低，人人都是数据分析，实现效果即可忽略性能；算法工程师的门槛相对较高，需要对原有的方法进行一定程度的创新，来解决特定领域中的问题，且需要保证算法的性能、效果、稳定。