AI 产品经理
人工智能
对比传统的产品经理，AI 产品经理更加注重对于人工智能行业、场景算法，以及验收评估标准的理解.
人工智能产业现状
对于人工智能的产业，我们可以基于产业链的上下游关系，把它分为基础层、技术层和应用层。
我们先来看最下面的基础层，它按照服务的线条被划分成芯片服务、云服务、机器学习平台和数据服务，它们都是我们整个 AI 行业最底层服务提供者。这里面，讯飞的开放平台是我们接触比较多的机器学习平台，阿里云、百度云是做得比较好的云服务提供商。
再上一层的技术层是 AI 技术的提供者，我按照技术类别对它进行了划分。这里面，我们比较熟悉的企业有商汤、依图，它们主要是提供计算机视觉服务，最常见的应用场景就是人脸识别了。
最上面的应用层是 AI 技术对各行业的应用服务，就拿我们最熟悉的抖音来说，它通过 AI 技术不仅能实现短视频内容的个性化分发，把你感兴趣的内容展示出来，还能在拍摄短视频时候，让你变美变瘦，身体各个部位“收放自如”。
除此之外，在整个 AI 产业链中，BAT 提供了全链条的服务，它们既做了最底层的基础服务，如云服务、机器学习平台，也做技术输出，如 BAT 会有自己的计算机视觉、语音识别等能力，同时也有对外的应用场景，所以我把它们放到了一列中。这个产业链上每一层的代表企业非常多，我就不细说了，你可以参考下面的全景图。
上面的全景图告诉了我们，整个产业链的分层和每层的典型公司都有哪些。目前行业内的成熟应用如下:
这里，我挑出了4个应用 AI 技术比较早，发展也相对成熟的行业，它们分别是金融风控，智能支付、智能安防以及智能客服。我会通过它们来给你讲讲，目前一些成熟的 AI 技术都是怎么应用的，应用它们对这些行业有什么帮助，以及这些行业中比较有代表性的企业和产品分别是什么。
- 金融风控行业 主要是用机器学习技术把原本依赖人工的风险管理变为了依赖机器算法的方式，通过收集借款人的相关数据（收入、年龄、购物偏好、过往平台借贷情况和还款情况等）输入到机器学习模型中，来预测借款人的还款意愿和还款能力，判断是否对他放款。
AI 技术的应用解决了原有人工信贷审核效率低下、无标准等问题。目前，市场上做金融风控的 AI 企业不只有老牌的百融云创、邦盛科技，还有蚂蚁集团、京东数科、度小满这样的大型互联网公司，还有冰鉴这样新型的创新型公司等等。
而智能支付行业主要是通过人脸识别、指纹识别、声纹识别、虹膜识别等多种生物识别技术，帮助商户提高支付效率。像蚂蚁、京东数科、商汤和云从科技这些我们比较熟悉的企业，都属于智能支付行业。其中，云从科技、旷视科技、商汤科技和依图科技还一起被誉为 CV 界的四小龙。
接着是智能安防行业 。互联网产品经理平时接触这个行业可能比较少，因为目前市场上主要做智能安防的企业有海康威视、大华股份、汉邦高科等，它们主要是通过人脸识别、多特征识别、姿态识别、行为分析、图像分析等相关技术融合业务场景的解决方案，来帮助企业、政府解决防控需求的。像我们都听说过，通过 AI 摄像头自动识别犯罪嫌疑人，通过深度学习技术检测车辆，并且识别出车牌号码等特征，用于停车场收费、交通执法等场景。
最后是智能客服行业。这个行业主要是通过自然语言处理技术、知识图谱，对用户输入的问题进行识别分析，根据知识系统寻找答案，解决原有人工客服效率低下、成本高这样的问题。
就像很多银行现在都采用智能客服，对它们的用户进行理财推荐，我就接到过不少这样的电话。但是一般来说，它们和真人的区别还是很明显的。目前市场上比较成熟的智能客服企业主要是环信、云知声、百度等等。
好了，现在我们已经知道了什么是人工智能，以及整个产业的现状。目前人工智能与各个行业还在不断融合，AI 也会继续向各个行业进行渗透。在我看来，AI 最终不会成为一个行业，而是会像移动互联网一样成为一个基础建设，赋能到整个互联网。
人工智能商业模式
在人工智能产业中，处于不同层级的企业，根据自身能力和方向的不同，都有自己的一套商业模式，充分了解 AI 公司的商业模式.总的来说，商业模式可以分为：数据收集和治理、计算资源服务、AI技术服务以及产品附加AI这四种。下面，我们一一来看。
首先，我们来看位于基础层的两类商业模式，数据收集和治理，以及计算资源服务。
数据收集和治理类型的公司大多拥有自己的数据流量入口，致力于对于数据的收集和加工。比如数据堂，它主要提供数据采集（包括从特定设备，地点采集，采集范围包括图片、文字、视频等）、数据标注（主要是对图像进行标注，如标注人脸、动作等）服务。
而计算资源服务类型的公司，又可以分成两类，一类致力于底层的芯片、传感器的研发服务，就像寒武纪这样的企业，它们作为一个人工智能芯片公司，主要的收入来自云端智能芯片加速卡业务、智能计算集群系统业务、智能处理器 IP 业务。另一类是 AI 计算服务，比如百度的 AI 开放平台，平台除了提供百度自有的 AI 能力之外，也为上下游合作伙伴提供了一个 AI 产品、技术展示与交易平台。
接着，我们再来看位于技术层的 AI 技术服务类公司，它们为自己产品或者上游企业提供底层的 AI 技术服务，服务模式更多的是技术接口对接，比如人脸识别服务的服务模式主要就是 API 接口或者 SDK 部署的方式。
最后是产品附加 AI，即应用层的大部分产品，它们都是通过 AI 技术叠加产品，赋能某个产业的模式。比如滴滴通过 AI 技术应用于自有的打车业务线，包括营销环节的智能发券、发单环节的订单预测、行车中的实时安全检测等等。
AI 产品经理所需技能
通过上面的分析，我们不难发现，不同产业层级和商业模式都需要具有相应能力的 AI 产品经理。那这些产品经理究竟有什么区别呢？接下来，我就结合应用层、技术层和基础层这三个层级企业的特性，来给你讲讲不同层级产品经理所需的技能，同时给你一些具体的转型建议。
首先是基础层。处于基础层的企业主要提供算力和数据服务，这些企业的特点是，偏硬件，偏底层技术，技术人员居多。这就要求 AI 产品经理了解如云计算、芯片、CPU/GPU/FPGA/ASIC 等硬件技术，以及行业数据收集处理等底层技术和框架。所以，原来从事底层硬件、技术平台、基础框架的产品经理，就比较适合转型到基础层了。
而处于技术层的企业，主要的业务是为自己的业务或者上游企业提供相应的技术接口。这些企业的特点是技术能力强，大部分业务都是 ToB 服务。这个时候，AI 产品经理就必须要具备企业所在领域的技术知识，如语音识别（ASR）、语音合成（TTS）、计算机视觉（CV）、自然语言处理（NLP）等通用技术，最好还能了解 TensorFlow、Caffe、SciKit-learn 这样的机器学习框架。
所以，技术层的 AI 产品经理本身必须具备一定的技术基础，最好还能是算法出身的工程师。但不管你属于哪一种，都一定要保有探索的热忱。
最后，我们再来看应用层，这类型公司就是我们日常生活中接触最多的互联网公司，只是其中一些公司走的比较靠前，应用了 AI 技术来赋能自己的内部业务。比如滴滴使用 AI 技术做智能分单、智能补贴；京东数科是用 AI 技术做智能反欺诈，大数据风控。这一层是互联网产品经理转型最多，也是成功率最高的一层。
处于应用层的企业，大多数直接面向 C 端用户，所以它们关注的是如何结合市场特点，来利用 AI 技术创造性地设计出符合市场需求的产品。所以这类型的产品经理不仅要求对所在行业有深刻的认识，同时也要对 AI 技术有一定的了解。能够与算法和研发工程师顺畅沟通与配合，能够判断算法同学交付的产品是否满足业务需求。
Ai产品经理 VS 传统产品经理
AI 产品经理作为产品经理，核心职责和底层能力与传统产品经理是一致的，仍然是通过技术手段实现业务目标，但是它们在面向的对象，使用的技术，以及岗位边界这三个方面却大有不同，不同在哪呢？接下来，我详细给你讲讲。
首先，我们来看面向对象上的不同。传统的产品经理更多活跃在 C 端，他们面向的是用户，比如电商产品经理、策略产品经理、社区产品经理等等。但是 AI 产品经理更多活跃在 B 端，面向的是各大企业，而且 AI 产品更多应用在 B 端的场景下，比如云从科技的人脸识别产品，大多是给到银行，应用于银行的自动柜员机开户等场景。
之所以有这些不同，主要是 C 端场景的产品，前期大部分都需要烧钱获客。但是对当前市场来说，线上流量越来越贵，C 端产品想要有所突破越来越难，倒不如去做 B 端服务，通过给企业服务的方式完成 AI 产品商业化。
其次，是实现产品目标的技术手段不同。传统产品经理对接的是研发工程师，需要通过研发工程师的代码，来完成产品的功能实现，那他们使用的就是研发技术。
而 AI 产品经理对接的是算法工程师和研发工程师，需要对接算法工程师完成具体的模型，再对接研发工程师进行工程开发联调和上线。最终，我们得到的产品形态可能是一个 API 接口，没有所谓的页面。比如，腾讯的人脸识别产品，对外暴露的就是一个 HTTP 接口，接口名称为人脸检测与分析，接口描述是识别上传图像上面的人脸信息，API 地址为 https://api.ai.qq.com/fcgi-bin/face/face_detectface。
基于这种情况，AI 产品经理除了要懂一些基本的研发技术之外，也需要深入学习算法知识，比如工作中常用到哪些算法，以及它们的实现逻辑等等。甚至，由于整个 AI 行业仍处于早期阶段，也就是技术驱动的阶段，因此 AI 产品经理需要了解更多的技术知识。
只有当整个 AI 行业趋于成熟，技术壁垒逐渐打破的时候，AI 产品经理才可以对技术只要做到了解就够用了。至于 AI 相关的技术，以及这些技术你需要掌握到什么程度，我会在后面的课程中和你详细说。
最后，我们再来看看 AI 产品经理在岗位边界上的不同。这个边界可以分为两个方面，一个是岗位要求的边界，一个是和技术人员协作的边界。
我们先来看传统产品经理的岗位要求。传统产品经理的岗位要求非常清晰，一般来说，电商产品经理需要懂得电商业务、供应链、电商后端设计，了解用户裂变、营销活动设计，社区产品经理要有社区、社交产品经验。而且每一家企业相同岗位的 JD （职位描述）差别不会太大。但 AI 产品经理的岗位要求非常模糊，同样是 AI 产品岗位，有的公司会要求你具有行业经验，不要求你懂技术，而有的公司会要求你必须懂技术，甚至要求你能看懂 Python 代码。
为什么 AI 产品经理的岗位要求这么模糊和混乱呢？这主要是因为 AI 产品岗位比较新，很多公司还不能确定这个岗位要做的事情。有些技术导向型的公司就希望产品经理懂技术，甚至是研发转岗过来的，有些偏业务导向的，则希望产品经理有丰富的行业经验。当然，也不排除有些公司对这个岗位自己都没有想法，只是从网站上抄袭 JD.
岗位要求的边界说完了，我们再来看看和技术人员协作的边界。这里说的不同主要体现在，传统产品经理和研发协作时候，只需要提供 PRD 文档（产品需求文档），对需求进行讲解，有问题及时提供解答就可以了。但是 AI 产品经理很难产出一个 ROI（投资回报率） 指标明确的 PRD 文档，以及我们和算法同学的沟通也不是一次需求宣讲就能完成的，通常我们需要进行多次的沟通确认，并且在沟通中逐渐清晰对于算法目标范围的设定。
AI 产品经理的工作职责和能力要求是什么？
AI 产品经理需要知道，你在什么场景下，可以通过什么样的技术来解决问题，解决到什么程度。比如，在智能客服场景，你可以通过自然语言理解技术让机器去回复一些标准的问答，来减轻人工客服的压力，但对于强个性化的用户问题，还是需要人工介入来解决的。
接下来，我就通过 AI 产品上线的过程，来和你详细讲讲 AI 产品经理的工作职责。一般来说，一个 AI 产品上线的流程大致可以分为，需求定义、方案设计、算法预研、模型构建、模型评估、工程开发、测试上线等几个步骤。这其中，产品经理需要主导的节点有定义产品方向、设计产品方案、跟进产品开发和产品验收评估，那我们重点关注这四个步骤。
- 定义产品方向
在我们决定做一个 AI 产品的时候，不管是处于基础层还是技术层或者是应用层的
AI 产品经理，首要的职责都应该是去定义一个 AI
产品。这包括，搞清楚这个行业的方向，这个行业通过 AI
技术可以解决的问题，这个AI产品具体的应用场景，需要的成本和它能产生的价值。
这就要求 AI 产品经理除了具备互联网产品经理的基础知识之外，还需要了解 AI 技术的边界，以及通过 AI 技术能够解决的问题是什么
- 设计产品方案
完成了产品定义之后，产品经理需要给出产品的设计方案。产品的设计方案会根据产品形态不同而不同，比如硬件和软件结合的 AI 产品，会包括外观结构的设计，机器学习平台的产品需要包括大量的交互设计，模型类的产品（推荐系统、用户画像）更多的是对于模型上线的业务指标的要求。
在这个阶段， AI 产品经理需要了解，现在市场主流算法都有哪些，不同的算法应用场景是什么，算法的技术边界在哪里。
比如，我们要从0到1做一个推荐系统，并且希望它能尽快上线，但如果模型同学打算用某种创新的深度学习模型去做就不合适了。因为深度学习的模型不仅技术难度高，而且模型训练时间久，需要的算力也更多，还有关键的一点是在推荐系统的0到1阶段，业务方领导会要求模型具有可解释性，所以创新模型就不如简单地协同过滤，加逻辑回归实现起来方便快捷。
只是对于技术人员来说，他们更希望用新技术去解决问题，如果我们完全不懂技术，用了深度学习模型之后，可能推荐系统上线周期不但增加了不少，而且效果也不一定会比传统的机器学习方式好多少。这个时候，产品经理就需要通过自己掌握的技术知识去把控技术和业务的平衡了。
另外还有一种更常见的情况，产品经理在和算法同学沟通方案的时候，他们会说，“这个模型我打算用 XGBoost 去做”，或者“目前很多数据没有结构化，我们需要先把一些数据结构化并且做归一化处理”等等。
相信很多同学看到这里都会有些懵，什么是 XGBoost，什么又是归一化？如果产品经理不停地去问算法同学这些问题，估计没有几个算法同学会愿意一点点去解释这些基础名词。
所以，对于 AI 产品经理来说，此阶段的能力要求为，基本的技术知识是必须要了解的。这些包括基本的统计学概率论知识，主流算法的基本原理和应用场景，以及这些算法可以帮助我们达成什么样的产品目标。
- 跟进产品开发
产品设计完成之后，就到了工程和算法同学分别进行开发的环节了。在这个过程中，你需要承担一些项目经理的职责，去跟进项目的上线进度，协调项目资源。
因此，这个阶段产品经理至少要知道模型的构建过程是怎么样的，否则产品经理怎么能够评估当前进度到哪里了呢？另外，产品经理还需要知道模型构建过程中，每个节点的产出物，以及它的上下游关系。只有这样，产品经理才可以清楚评估项目进度，遇到需要协调资源的时候，也知道产品在这个阶段需要的是什么。
- 产品验收评估
在这个阶段，产品经理的能力要求是，需要知道如何去评估一个模型，评估模型的指标都有哪些，具体评估的过程是怎么样的，以及评估结果在什么范围内是合理的。比如，你的算法工程师告诉你，这个模型的区分度是 40，那你至少要知道区分度是怎么计算的，40 是不是一个合理的数字。只有这样，产品经理才算对产品有完整的了解和把控。
产品经理技术全景图
AI 产品落地例子
业务背景
一个电商平台，有段时间我们发现，每个月老用户流失的数量已经远高于新用户的拉新数量，为了防止这个缺口越来越大，我们决定对可能流失的用户做提前预警，同时采取一些措施来挽留这些用户，实现这个目标的前提就是要开发一套用于预测流失用户的产品。
产品定义
当决定实现这个产品之后，首先我们要做的就是定义产品需求，明确做这件事情的背景、价值、以及预期目标都是什么。
在这个环节中，我们会和业务方共同沟通，来决定我们的业务预期目标是什么，期望什么时候上线。这里，我提到的业务方可能是运营同学，也可能是商务同学，这和你是一个 ToC 还是 ToB 的产品经理相关。
在这个预测用户流失的项目中，我的业务方就是运营，我们的期望是通过算法找出高流失可能性的人群，对这些人进行定向发券召回。这个项目的最终目标是，通过对高流失可能性的人群进行干预，让他们和没被干预过的人群相比，流失率降低 5%。
同时，由于我们运营计划是按月为节奏的，所以这个模型可以定义为离线模型，按月更新，每月月初预测一批流失人群。并且，我还期望这个模型的覆盖率能够达到 100%，让它可以对我们业务线所有用户进行预测。这些就是我们对模型的更新周期、离线/实时模式、覆盖率等相关要求了，我们需要把它们都记录到一份需求文档中。
技术预研
需求确定之后，产品经理需要和算法同学进行沟通，请算法同学对需求进行预判。具体来说，就是要判断目前积累的数据和沉淀的算法，是否可以达到我们的业务需求。如果现有数据量和数据维度不能满足算法模型的训练要求，那产品经理还需要协助算法同学进行数据获取，也就是后面我们要说的数据准备工作。
当然，即使数据达到算法的需求，产品经理也还是需要协助算法同学做数据准备，因为垂直业务线的产品经理更了解本领域的数据。
另外，在这个环节中，你可能还需要根据算法的预估，对需求的内容进行调整。比如，我们原定覆盖率为 100%，但是和算法同学沟通后发现，有部分刚刚注册的新用户是没有任何数据的。对于这部分人，算法无法正常打分，而且新用户也不在流失用户干预范围内，所以，我们后面会根据目前新老用户比例得到新的覆盖率指标，再把它放到需求中去。
数据准备
然后，我们就进入数据准备的环节了。这个环节，我们需要根据模型预研的结果以及公司的实际情况，帮助算法同学准备数据。
原因我们刚才也说了，就是因为产品经理基于对业务的理解，能判断哪些数据集更具备代表性。而算法同学，只能根据现有的数据去分析这些数据对模型是否有用，因为有些业务数据算法同学是想不到，所以自然不会去申请相关数据权限，也就不会分析这部分数据存在的特征。
比如说，我们在过去的用户调研中发现，用户一旦有过客诉并且没有解决，那么大概率会流失。如果出现了客诉，用户问题得到了很好地解决，反而可能成为高粘性的客户。这时候，我们就会把客诉数据提供给算法同学，请他们去申请数据表权限，评估数据是否可用。反之，如果我们没有把这些信息同步给算法同学，那么很可能我们就缺失了一个重要的特征。
在数据准备的部分，由于数据的不同，我们的获取方式也会有很大的差别。总的来说，数据可以分为三类，分别是内部业务数据、跨部门集团内数据以及外部采购的数据。接下来，我就分别说说这些数据怎么获取。
- 获取内部业务数据
内部数据是指部门内的业务数据，如我们的订单数据、访问日志，这些都可以直接从数仓中获取。当然还有一些情况是，我们想要的数据目前没有，你可以提需求让工程研发同学留存相关数据，比如，之前有些用户的行为数据没有留存，那我们就需要增加埋点将这些数据留存下来。
- 获取跨部门集团内数据
跨部门集团内数据指的是其他部门的业务数据，或者是统一的中台数据，这些数据需要我们根据公司数据管理规范按流程提取。在提取数据的时候，我们需要注意结合业务情况去判断该提取哪些数据。
- 获取外采数据
最后是外采数据的获取。在公司自己的数据不足以满足建模要求时候，我们可以考虑购买外部公司数据，或者直接去其他拥有数据的公司进行联合建模。
这个时候 ，我们就需要知道市场上不同的公司都能够提供什么。比如极光、友盟提供的是开发者服务，所以它们可以提供一些和 App 相关的用户画像等数据服务，再比如运营商可以提供和手机通话、上网流量、话费等相关数据等等。
直接采购外部数据非常方便，但我们一定要注意，出于对数据安全和消费者隐私保护的考虑，我们和第三方公司的所有合作都需要经过公司法务的审核，避免采购到不合规的数据产品，对自己的业务和公司造成不好的影响。比如说，在用户流失预测模型这个项目中，我们可以去调研自己的用户近期是否下载了竞品的 App，或者经常使用竞品 App，这都可以作为用户可能流失的一个特征。
当然，在数据准备的环节中，我希望你不仅能根据算法的要求，做一些数据准备的协助工作，还能够根据自己的经验积累，给到算法同学一些帮助，提供一些你认为可能会帮助到模型提升的特征。
具体到预测用户流失的产品上，我们可以根据经验提出用户可能流失的常见情况，比如我们可以参考客诉表，看看有哪些用户在客诉之后，问题没有解决或者解决得还不满意，那这些用户我们大概率就流失了，或者我们也可以分析用户的评价数据 ，如果用户评价中负面信息比较多，那他们也可能会流失等等。
模型的构建、宣讲及验收
数据准备之后，就到了模型构建的环节。这个环节会涉及整个模型的构建流程，包括模型设计、特征工程、模型训练、模型验证、模型融合。
即便你不需要进行模型构建的实际工作，你也需要知道这个流程是怎么进行的，这方便你了解算法同学的工作，以便评估整个项目的进度。这就好比互联网产品经理不需要写代码，但也要知道研发的开发流程是怎么样的。
不过，今天我们不会重点来讲具体的过程，我先卖个关子，你今天先记住这几个关键节点的名称，下节课我们再详细来讲。
模型构建完成之后，你需要组织算法同学对模型进行宣讲，让他们为你讲明白这个产品选择的算法是什么，为什么选择这个算法，都使用了哪些特征，模型的建模样本、测试样本都是什么，以及这个模型的测试结果是怎么样的。
对于流失预测模型来说，我需要知道它的主要特征是什么，选择了哪些样本进行建模，尤其是测试结果是否能够满足业务需求。当看到流失预测模型的测试结果的时候，我们发现模型召回率、KS 值都达到了标准，但是模型覆盖度只有 70%，比预期低了不少。但是，由于我们业务侧也只需要找到一部分流失用户进行挽留操作，所以，暂时不能覆盖全量人群我们也是可以接受的。像这样的问题，都是你在模型宣讲环节需要去注意并且去评估的。
在模型宣讲之后，你还需要对模型进行评估验收，从产品经理的角度去评判模型是否满足上线的标准。那在这个流失用户预测的项目上，我们就需要重点关注模型的准确率，是否模型预测的用户在一定周期后，确实发生了流失。如果模型准确率较低，将一些优惠券错配到了没有流失意愿的用户身上，就会造成营销预算的浪费。
模型宣讲环节的具体内容，以及模型宣讲后，我们对模型进行评估验收的具体指标都有哪些，我会在模型验收的章节和你细说，这里你先不用着急，你只要知道有模型宣讲和模型评估验收这两个环节，以及它们的整体流程，让自己对 AI 产品经理的工作流程有一个整体的理解就可以了。
工程开发及产品上线运营
模型通过了验收之后，我们就可以进入工程开发的环节了。其实在实际工作中，工程开发工作通常会和算法模型构建同步进行。毕竟，算法同学和工程同学分属两个团队，只要模型的输入输出确定之后，双方约定好 API 就满足了工程同学开发的条件了。
工程开发完成之后，就可以进行工程测试验收了。这和传统的互联网产品上线流程区别不大，也就是测试同学进行测试，发现 BUG 后提交给工程同学进行修复，再当测试同学测试通过之后，产品经理验收，或者叫做产品上线前走查，这里我就不再多说了。
另外，在工程上线之后，为了评估 AI 产品整体的效果，我们可以通过对上线后的系统做 AB 测试对比传统方案，进而量化 AI 产品的效果提升。这时候，我们需要关注在产品定义阶段对于产品的指标和目标期望。
相比于一般的互联网产品经理，AI 产品经理在产品上线之后，还需要持续观测数据的表现（模型效果）。因为 AI 模型效果表现会随着时间而缓慢衰减，你需要去监控模型表现，出现衰减后需要分析发生衰减的原因，判断是否需要模型进行迭代。
模型构建总结
重点指标总结
算法模型监控体系
算法模型的监控指标体系（后面简称监控体系），就是将业务数据进行采集，同时用可视化图表展现给用户，并且提供相应的告警功能。
一般来说，当业务线初建的时候，我们可以不用考虑太多监控体系的需求，因为我们需要把精力放到怎么让业务“活下去”。但是当业务“活”下来之后，我们就要开始考虑搭建监控体系，让模型能够“活得更好”。那么，监控体系是怎么做到的呢？
- 当前这条业务的现状和过去业务数据的对比
- 当前业务是否正常，可能存在的问题，并且通过这些问题追溯原因
- 未来业务的趋势，可能的完善方向
第一，你做这个项目的业务背景是什么？
做任何一件事之前，我们都要想清楚为什么要做，做监控体系之前也不例外。不同的业务背景意味着你对这个项目不同的解决路径，也意味着你对这个项目投入多少精力，这需要你在做这个项目之前考虑清楚。
一般来说，建设监控体系这个需求有可能是你作为产品经理在业务发展过程中发现的，也可能是你的老板或者客户提出来的。
如果是你自己打算做一个监控体系，那么你就要思考：
- 你为什么要做这个东西，现在是遇到了什么问题
- 你对这个问题的洞察怎么样
- 你的解决方案是什么，解决方案是不是只有监控体系这一个，还有没有其他的办法
举个例子，之前我们刚开始做AI项目的时候，根本没考虑过做监控体系，所以把很多精力都用在了模型的迭代和满足客户个性化需求上。突然有一天，客户反馈说，我们的评分产品全部返回默认值，经过排查我们才发现，这是模型底层依赖的数据源出了问题。解决这个问题之后，我们才决定去搭建一个监控体系。
所以在这个例子中，为了解决我们不能及时发现模型问题，比如无法了解当前调用数据的问题，就是我们做监控体系的背景。
如果是老板或者客户提出的，那么你要考虑他为什么要做这个。常见的原因有四个：
- 模型现在是否暴露出了一些问题，你没有发现
- 你的老板或者客户看到别人有监控体系，认为我们也要有
- 老板为了有一套系统去“占坑位”
- 老板打算把这套系统和模型能力一起打包做成一个解决方案，对B端销售
这个时候，老板/客户提出需要搭建一个模型产品监控体系就是我们的业务背景。
第二，你要给谁解决什么问题？
明确了业务背景，下一步，我们要明确监控体系是要给谁解决什么问题，这其实就是在明确我们要解决问题的价值是什么。具体来说你需要明确，你做的这个监控体系到底在解决谁的问题，解决的是什么问题。这听起来好像有些啰嗦，但这两个问题环环相扣，知道了目标用户，我们就能针对具体问题具体分析，得出这个监控体系的建设侧重点，做出令人满意的产品，因此把它们拆开来看还是很有必要的。
首先，怎么确定你的目标用户是谁呢？我们可以从需求提出的两个方面来思考。
如果这个需求是内部需求。比如说，你在过去的业务中发现模型出现了衰减，但是业务方不知道，这就会导致模型的最终效果不好，反馈延迟。这个时候，你的用户其实是你和你的业务方，因为你们需要尽早知道模型是否发生了异常。因此，这个监控体系的重点就要放在业务数据展示和告警提示上面。
再比如说，你的老板只是看别人有这个产品，认为你们也要有（有些大公司这种情况还是有的）。这个时候，你的用户就是你的老板，你要解决的就是“有没有”或者“占坑”的问题。因此，你的产品重点要放在业务展示上，展示的角度要以领导视角为主，甚至整个产品都可以做得比较简单，比如你可以先做一个MVP出来，解决“有没有”的问题。
如果这个需求是外部需求。比如说，你在B端市场销售模型时候，发现某家银行的风控业务人员想要更方便地进行模型的管理，也就是有一套一体化解决方案的需求。这个时候，你的用户是你的B端客户。因此，你的产品重点就要放到B端客户的业务痛点上，解决“卖得更好”的问题。
但是，有一点我们需要特别注意：很多时候，你的目标用户不只是真正使用你产品的用户。尤其是在B端场景下，在采购产品这件事情上，有决定权的往往不是真正使用者。
举个例子，像钉钉这样的软件，虽然使用者是我们这样的“打工人”，但真正具有购买决策权的往往是公司的HR或者CEO。如果你要做类似的软件，就要把他们当做你的用户，只有做出可以打动他们的功能，才能让你的产品具有竞争力。
明确了用户之后，你就可以去调研这些用户面对的问题是什么了。如果是内部业务线的需求，我们面对的问题可能就是，模型突然异常业务不能实时告警，并且及时处理。如果是ToB销售的业务需求，我们可能需要解决的问题，就是业务人员没有办法从全局角度管理和监控模型。
总的来说，要明确解决的问题是什么，需要你深入到业务中去挖掘用户的痛点，这也是产品经理最基础的要求。我给你的建议是，如果你做的是C端产品，你要把自己作为产品的用户，去深入体验产品、发现问题。如果你做的是B端产品，你要和业务的相关者深入沟通，最好和他们一起工作，看看他们的工作流程是怎么样的，有没有遇到什么问题，以及当前（没有产品的情况下啊）是怎么解决这些问题的。在这个过程中，你可以尝试利用“5W2H”的方法来问你的用户、问你自己。
第三，你要怎么解决问题？
总结
口诀: 问题 -> 范围 -> 调研 -> 建模 -> 验收宣讲 -> 上线运用 -> 监控迭代
- 明确业务问题
- 明确问题范围(数据范围,应用范围等等边界问题)
- 调研与准备(数据调研, 系统调研,方案调研)
- 构建模型
- 验收, 宣讲模型
- 模型上线
- 监控模型