一、引言

• AI的产品化和工程化是前沿科研成果向具体商业化场景落地的必由之路。总的来说，AI商业化落地存在两大难题：一是产品化和商业化路径如何实现；二是科研算法如何向工程领域转化。要解决真实世界的AI问题，首先，要学习如何将最好的AI技术转化为最有价值的产品，其次，要做好AI技术的工程实现与工程部署。

（一）产品视角

• 如何认识AI的产品化路径，如何理解不同类型的市场和用户，如何设计有价值的AI产品。

（二）工程视角

• 如何从工程视角实现AI产品，典型的、与AI相关的系统架构有哪些，典型的设计模式有哪些。

二、从AI科研到AI商业化

• 今天，“如何实现AI商业化落地”是一个被反复讨论甚至被不断质疑的话题。一方面，AI在许多场景和平台上实现了巨大的商业价值—Google、Facebook、Amazon、阿里和腾讯等公司早已在搜索引擎、广告推荐、商品推荐等领域，熟练并广泛地使用了机器学习，同时创造了巨大的营收。另一方面，大批怀着科技改造世界的美好梦想，在医疗、金融、制造、零售、能源、交通和仓储等垂直领域耕耘的创业者们却发现：理解客户场景和需求难、找到技术和业务的结合点难、实验结果和客户需求之间的差异巨大、单项AI技术难以解决客户的综合问题、概念验证或科研项目极难转化为客户的实际采购需求、实际项目实施的复杂度和定制化程度远超预期、技术和产品的可复制性不强，以及难以形成稳定的产品和可持续的销售……的确，AI科研与AI商业化落地存在着巨大的鸿沟。这是因为科研的关注点（例如，技术如何突破、论文质量高不高、数据指标如何等）与商业化的关注点（例如，能不能赚钱、能不能持续赚钱、能不能轻松持续赚钱）之间，存在着较大差异，如下图所示。
  

（一）今天的AI技术有非常明显的边界

• 在涉及从浅层信息到知识映射的任务时，或涉及单纯的数据建模任务时，它往往表现得性能出众，甚至超过人类完成类似任务时的平均智力水平。例如，今天的AI技术可以轻松快速地识别出人脸，可以快速完成从语音到文字的转换，可以快速从大数据（如广告点击日志）中建立数学模型并用于预测（如广告点击率预估）。但是，在涉及深层知识表示和知识理解（或者说基于符号语义的建模任务）时，今天的AI技术又“幼稚”得像一个两三岁的小孩，例如，当今顶级的AI技术连“预订餐厅”这样的限定领域任务，都还需要人类的配合才能完成（据《纽约时报》在2019年5月22日的报道，Google发布的Duplex辅助预订服务在任务完成的最终效果上非常亮眼，但其实有相当一部分对话是在真人参与下完成的）。简单会话尚且如此，那么对于更复杂的知识理解和推理任务，我们可能还需要相当长的时间才能看到AI技术的进步。

（二）今天的AI技术在有限领域里可成为支柱技术

• 今天的AI技术在搜索引擎、广告推荐等有限领域里，可以真正成为核心业务的支柱技术。但在更广泛的领域里，很多AI公司的产品和解决方案至今都还停留在帮助客户的公司塑造一个“拥抱新技术”的良好形象上，或是为客户的非核心业务提供一些“有用但非亟须”的工具，而不是深入到客户的核心业务内部，帮助客户获得更大的盈利及成长空间。如何用技术帮助客户提升价值，这件事往往是很多科研人员和在校学生很难理解的——没有在商业环境下打拼过，就很难意识到：到底什么样的技术对企业的生存（或者说赚钱）最重要。因为要获得这种认知，人们不仅需要计算机科学知识，更需要具体行业的相关知识。

（三）产业实践强调的是完整的系统工程或者完整的技术栈

• 对于计算机或相关专业的高校在校学生来说，他们在学校里学到的学科知识和在工程上实现一个真正可用、好用的AI系统之间，同样存在着不小的鸿沟。从下图中不难看出，学校教学在一定程度上强调的是离散的知识点，而产业实践强调的是完整的系统工程，或者说是完整的技术栈。学生在学校学过机器学习、计算机系统结构、操作系统和分布式系统等课程，但是如果没有办法将这些知识融会贯通，去构建一套能够解决真实问题的系统逻辑的话，那么他们是无法将AI技术转化成工程产品的。从某种程度上说，学生只有在学校接受过能灵活运用学科知识去解决真实问题的专业性训练，毕业后才能成为高水平的算法工程师、系统工程师或架构设计师。
  

• 真实的AI产品或系统，往往由一个完整技术栈组成，大致会涵盖硬件架构、操作系统、分布式架构、核心算法、应用逻辑、部署和维护等多个层次的技术框架与技术组件，其中，每一个技术框架或技术组件又可能是由学生在学校里学过的多种学科知识共同支撑的。 比如，我们要做一个图像识别系统用于超市的商品监控，一些缺乏实践经验的算法工程师可能会认为，商品识别不过就是目标检测（Object Detection）和目标分类（Object Classification）这两个任务，这可以借助一系列通用算法，如Faster R-CNN（Region-CNN）、YOLO和SSD（Single Shot MultiBoxDetector）等来完成。但一个有经验的系统工程师或系统架构师则会在算法之外提出更多的问题。

（1）我们需要多少训练数据？这些数据从哪里来？
（2）模型是否有定期或实时更新的需求？如何更新？
（3）推断（Inference）计算部署在哪里？是在终端？还是在云端？
（4）终端计算和存储能力是否有限制？是否需要对模型进行压缩？
（5）AI算法本身是否有分布式的需求，如分布式的训练？
（6）图像如何采集？采集到的图像如何传输到运行算法的计算节点上？
（7）识别结果和操作日志如何保存并用于后续的算法优化？
……

• 这些问题看似是工程问题或是系统架构问题，但其实也和AI算法本身息息相关。如何从一个专业的系统工程师或系统架构师的视角看待AI系统的设计与实现，这是我们要重点讨论的另一个问题。

三、产品经理视角——数据驱动的产品研发

• 产品经理需要具备的重要素质是严密的逻辑思维能力和系统化的方法论。不同领域的产品设计和产品管理，在方法论上也不尽相同。对于与AI和大数据相关的产品和解决方案，数据驱动的理念和方法论也许是最为重要的。

（一）数据驱动

1、数据驱动的含义

• Eric Schmidt与Jonathan Rosenberg在合著的How Google Works一书中提到了Google“依数据做决策”的做法：

互联网时代的一项重要变革是，我们具备了能够用定量的方式来分析商业流程中几乎每个层面的能力……如果你没有数据，你就无法做决策……这就是大多数Google的会议室都有两个投影仪的原因—一个用于记录办公室的视频会议或投影会议，另一个则用于展示数据。

• 所谓“数据驱动”，就是产品经理在产品管理的全流程中，始终坚持以数据为决策依据的方法论。产品经理从收集数据开始，依据数据中体现出来的统计规律进行产品设计以及做出相应的产品决策，然后快速收集用户反馈数据，并根据反馈数据修改产品设计。上述过程反复迭代，可以达到不断完善产品的目的，如下图所示。
  

2、为什么产品经理要以数据为驱动呢？

（1）数据具有可度量的属性

• 可度量意味着：可评估、可管理、可改进和可持续。

（2）数据具有客观性

• 在产品设计和研发的过程中，产品经理往往会面临大量难以取舍和难以决断的情形，此时，数据是帮助他们做出决策的最佳依据。

（3）数据只有较少的偏见

• 数据本身当然有偏见，但当缺少数据时，我们会因为缺乏客观评估标准而引入更多偏见；相比于数据驱动，以经验驱动或信心驱动的产品研发有可能在短期内或在个别项目中取得巨大成功，但其累积的偏见会越来越多。

（4）数据易于可视化

• 基于长期积累的数据，产品经理更易于对其进行智能分析。

3、数据驱动的基本思想

• 从根本上说，数据驱动的思路就是用可度量的方式指导产品定义、产品设计和产品开发。大数据工程师和AI算法工程师应该非常熟悉数据驱动的基本思想：在机器学习领域，为了验证一个新算法的性能如何，我们就需要有数据集，并用一定的方法和指标来度量该算法在数据集上表现出的性能，以及还需要有作为参照的基线。机器学习领域里有关数据驱动的核心思想完全可以用于指导产品管理——这基本就是数据驱动的产品思维。
• 从实际执行的角度讲，数据驱动就是指在产品管理的每一个环节，用可度量的数据指标来指导产品决策，比如：
  （1）用户需求是否存在？我们需要精准的用户调研数据。
  （2）市场空间是否足够大？我们需要客观的市场调研数据。
  （3）产品是否应该包含某个功能特性？可以针对这个功能特性做小规模实验，并收集实验数据。
  （4）产品是否有可能在竞争中胜出？分析竞品数据同样很重要。
  （5）营销和推广渠道如何搭建？这就需要我们做对比测试并获得客观的渠道转化率数据。
  （6）产品的用户界面是否美观易用？这也可以通过对比实验结果的数据来判定。
• 数据驱动的核心是：相信数据具有可评估、可管理、可改进和可持续的属性，与我们通过“拍脑袋”做出的主观判定相比，数据偏见少、更客观。当然，熟悉统计学和机器学习的读者很清楚，统计数据里看似公正、实则偏颇的事情也有很多，比如著名的“幸存者偏差”。但严密的逻辑加上科学的度量方法，还是可以更大概率地保证数据的客观性，从而为决策提供更好的支持。
• 学过统计学和机器学习的读者应该非常熟悉ROC（Receiver Operating Characteristic，受试者工程特征）曲线，ROC曲线反映的是伪阳性率（False Positive Rate，FPR）和真阳性率（TruePositive Rate，TPR）之间的关系。我们应该都清楚，在多数真实系统中，必须在算法的伪阳性率（假警报比率）和真阳性率（敏感度）之间做一个折中或权衡。
• 类似地，我们在用数据驱动的方式去思考一个产品定义或产品设计时，也需要懂得取舍或权衡的艺术。例如，一个线上知识社群类产品，如果增加一个“一句话吐槽（类似日式冷吐槽）”的功能，那么社群平台在大概率上可能会增加新注册用户数量、活跃用户数量和平均用户在线时长。与此同时，这样偏娱乐性功能的上线，多半会带来娱乐型用户占比的增加，这是否会进一步影响有价值的知识内容的积累，或者付费类知识课程的转化率呢？这就需要产品经理通过对比实验，并仔细收集、分析数据，最终做出最优的折中或权衡了。

（二）典型C端产品的设计和管理

• 一个典型C端产品的研发过程如下图所示。因为市场机会、市场容量、竞品态势的变化瞬息万变，今天的互联网和互联网产品尤其需要快速迭代的产品研发模式。可以说，在今天中国的C端产品市场里，根本没有所谓的“蓝海”，几乎每个战场/赛道在初具规模的时候，就会有大批强有力的竞争者参与进来，并形成“红海”。在“红海之战”里，快速迭代的思想需要提高重视、重点强调。这是因为通过快速迭代，产品经理可以更早地获得用户反馈数据，更早地指导和修正产品设计，更早地做出符合市场规律的正确决策。
  
• 在具体的执行层面，很多C端产品的产品经理都非常熟悉两件事：一个是数据埋点，一个是A/B测试。数据埋点指的是在产品的前后端逻辑里，技术人员加入特定的日志代码，用于记录与用户操作或系统功能有关的事件。通过埋点记录下来的信息被存储在系统的前后端日志中，而产品经理则经常需要从这些日志中寻找数据的规律，挖掘数据背后的价值。比如，一个电子商务网站或APP，可以通过数据埋点了解到某用户在浏览商品时，曾把一件商品加入购物车但后来又“删除”了此商品的行为，甚至可以有针对性地记录下商品被加入购物车直到最终“删除”之间，用户又执行了哪些操作。然后，产品经理根据用户交互日志，分析在什么情况下用户更容易放弃一个订单，并据此改进产品设计，提高购物车中商品的实际转化率。A/B测试是指将不同版本或不同迭代周期的功能按照一定的用户触达比例同时发布。比如，针对一个实时通信工具，我们想在新版本的迭代中测试一个新功能——根据用户的输入特点，系统向其提供相应的表情包。但对于这个新功能，我们不确定这个功能是否会得到用户认可，那么我们可以通过前后端软件的设置，将特定比例（如1%）的用户导流到带有新功能的版本中，剩余 99%的用户仍然使用不含新功能的版本。将用户导流到不同版本的做法，既可以根据一个预先设定的条件（如某地域符合某年龄段的用户）来选择新版本的测试用户，也可以随机选择新版本的测试用户。这种有对比的测试，我们可以很容易得到新版本用户相对于旧版本用户的变化数据。例如，聊天的平均时长和对话轮次有无提升、原有的输入功能是否受到影响、新功能的使用频次是否达到了预期等。
• 总体上，评估一个C端网站、APP或微信小程序产品的数据指标有很多，大致可以分为渠道转化效率、用户活跃度、用户使用率和用户留存率等几个大类，每个大类中又有一系列的常用指标。需要强调的是，对于不同类型的网站、APP或微信小程序，决定它们价值的核心逻辑并不一定是相同的。例如，对于一个搜索引擎来说，用户在产品上的停留时间（平均单次使用时长）并不一定能反映出系统的真正价值，因为好的搜索引擎通常能更快地帮助用户找到目标，并将用户带到目标网站或APP上，这时的用户平均使用时长反而较低。但对于一个内容类的网站或APP，例如短视频应用、新闻聚合应用等，用户的平均使用时长就特别重要，这个时长乘以用户的活跃度（例如月活跃用户，Monthly Active User，简称MAU），然后再乘以一个平均的广告转化率，基本就是内容类网站或APP最基本的收入模型了。

（三）典型B端产品解决方案的设计和管理

• B端产品解决方案指的是那些专向政府机构或企业提供软硬件系统，以政府机构或企业内部使用为主。下图展示了一个典型的B端产品解决方案的研发过程。B端产品解决方案的调研、立项、研发、实施和推广的整个流程与C端产品相比，差异巨大。
  
• B端产品研发具有客户需求导向和销售导向的特点，客户的实际采购与使用意愿实际上决定着B端产品解决方案的成败，而这又进一步由解决方案本身是否与客户需求相契合、是否能融入客户现有业务流程并为客户的业务带来增值所决定的。相比之下，技术是否先进、产品是否有创意，通常并不是决定性因素。因此，B端产品解决方案对数据的依赖，往往不是C端产品所关心的用户使用率、留存率等指标，而是对客户现有业务流程、商业模式和实际需求的精准分析。
• 举例来说，假设我们想用机器学习算法改进某个零售行业客户的供应链管理，如果向目标客户介绍：我们的机器学习算法采用了多么前沿的技术，我们的相关算法论文已发表在顶级会议上，我们的算法曾在某数据集上获得过第一名的成绩——这些信息可以展示我们的技术实力，但无法从根本上影响到客户的采购与使用意愿。真正有效的方法是，我们需要深入到客户目前的供应链管理流程细节中，或借助客户已积累的大数据资源，或帮助客户建立更有效的大数据流程，然后从中找到客户当前在供应链管理中效率最低的环节，并针对这个环节设计最实用（而不一定是最先进）的算法。
• 接下来，我们还必须在客户现场进行POC测试。比如，首先选取客户在某个省的供应链子系统，并根据历史数据用合适的算法预测该省在未来三个月各项原料的采购数量、销售预期等。然后，定量评估POC系统能为客户业务带来多大的价值提升空间，如节省了多少成本。如果在POC项目中获得了满意的结果，客户就有可能认可算法和系统的价值，并将POC合同转化为实际采购合同（通常还要通过竞标）。最后，在系统正式实施和维护中，数据采集环节（特别是对能提升业务价值的相关数据的采集）也非常重要，它会帮助我们进一步优化解决方案，并从中抽象出可以复用的模块或产品，并在同行业的其他客户中进行推广。
• 简单地说，B端产品的解决方案最根本的成功要素就是，我们能否帮助客户提升业务价值。此外，解决方案是否具有行业代表性，是否能加快合同回款以获得良好的现金流，是否能大幅减少后期维护成本，是否能积累可复用的技术、产品等，这些都是衡量B端产品解决方案是否成功的重要指标。

（四）AI技术的产品化

• 一个特定的AI技术（如对手写数学公式的识别），是选择走C端路线还是选择走B端路线，未来二者所必须经历的数据驱动的产品研发、管理过程是大不相同的，细节见下图。
  

1、决定主打C端产品必须回答的问题

• 一个手写数学公式APP或微信小程序的最终用户是谁？是学数学的小学生、中学生？是需要辅导作业的家长？还是为课程教学做准备的老师？
• 如果结合教育场景，推出一款能智能帮助老师、家长批改学生作业的APP，那么这个APP的推广渠道、盈利模式是什么？是简单地通过在线软件商店来推广，还是通过线上线下的运营渠道来推广？是通过在APP里植入广告来赚钱，还是通过APP向其他教育类业务导流来赚钱？
• 在每个特定的商业模式下，响应的市场规模有多大？预期的用户增长情况如何？竞争对手有多少？预期的营收在三年或五年时间里的成长曲线会如何？等等。

2、决定主打B端解决方案或服务必须回答的问题

• 这个解决方案或服务是面向哪个行业的？

• 如果是面向教育行业，那么我们的潜在客户是学校、教育机构，还是有内部教育培训需求的企业？

• 在潜在客户的业务流程里，对手写数学公式的识别功能是必须的吗？

• 这个功能是否能够帮助客户建立一个新的业务增长点？如果不能，是否能够帮助客户提升现有业务流程的效率，或降低现有业务的成本？

• 这个解决方案的服务模式和收费模式是怎样的？是基于云平台的API调用并按调用次数收费，还是基于定制化的软件服务并按软件授权来收费？等等。

• 总之，从产品经理的视角出发，要构建好的产品或解决方案，我们不能只懂技术或只懂AI，好技术团队必须同时具备对市场的分析能力、对目标客户/用户的触达能力，以及对目标行业/业务的深入理解能力。

四、架构设计师视角——典型AI架构

• 除从产品经理的视角看待与AI应用相关的问题外，学会从架构设计师的角度看待问题，对我们实现与AI相关的产品，也有非常大的帮助。
• 产品经理在看待问题时，强调的是市场、需求、方案、特性及产品生命周期的全流程管理。而架构设计师在看待问题时，强调的是如何用最适合的技术让产品满足需求。这是相辅相成的两个方面。
• 无论是产品研发中的哪一类角色，如AI算法工程师、AI系统工程师或用户界面工程师等，都或多或少需要了解一个产品的整体设计和整体方案。因此，架构设计师在思考和设计产品时经常使用的方法与流程，就非常值得我们多加关注，并仔细研习。

（一）为什么要重视系统架构

• 在一个技术团队里，不同角色所具备的技能应具有互补性。架构设计师擅长整体架构设计，前、后端工程师擅长编程，AI算法研究员、算法工程师擅长机器学习算法的设计与实现。但笔者一直强调，每一类角色都必须具备较广阔的技术视野，能对自己专长以外的技术有一定的认识。就拿AI算法研究员和算法工程师来说，对系统架构基础知识的了解和认识是必不可少的，主要原因有如下几点。

1、算法实现并不等于问题解决

• 在学术界，最重要的是提出问题及研究出解决方案，而在工业界最需要的是解决问题。其次，实验室环境中的“问题解决”也不等于工程现场中的“问题解决”。只要不是纯粹的科研问题，AI算法工程师就必须考虑工程实现层面对算法的支持或约束，比如，要知道AI代码部署在哪里、AI计算发生在哪里、AI计算所需的数据/资源是从哪里获取的。

2、工程师需要最快、最好、最有可扩展性地解决问题

3、对典型软硬件系统架构的理解是高效交流的通用语言

• 对典型软硬件系统架构的理解，其实是在一个系统工程中，科学家、AI算法工程师、前端工程师、后端工程师、大数据工程师和硬件工程师等不同角色之间，进行顺利沟通、高效交流的一门“通用语言”。很难想象，一个完全不懂架构设计的AI算法工程师，如何与其他角色顺利合作，并将自己的算法高效地集成到整体系统中。

4、笔者与AI工程师的一次交流情况

• 笔者曾向一位在Android APP上实现人体姿态检测算法的AI工程师提出过这样一个问题：

“在最终的系统中，你的姿态检测代码运行在哪里？是运行在用户的手机上，还是运行在云平台上并作为API服务被APP调用？你训练出来的模型又是部署在哪个设备上？在模型需要更新时会经由何种网络通道传送至目标设备？”
他回答道：“我不知道呀！我实现了算法代码，他们（指其他前、后端工程师）把我的代码拿去用不就行了。”
我接着问：“那你是否想过，如果你的算法代码运行在手机端，你有没有针对手机NPU（Natural Processing
Unit，自然处理单元）来优化你的算法性能？如果你的算法代码运行在云端，你有没有针对云平台上的GPU来调优你的算法？如果你的模型参数众多，每次更新都需要下载数百MB甚至几GB的.pb文件，那么最终用户体验会不会受到影响？你有没有考虑过对模型进行压缩，以提升用户体验？”

• 目前已经有不少AI功能（特别是演示性或娱乐性功能）被集成在Web应用或微信小程序里。就软件执行环境而言，这两者都是相当复杂的情况。算法工程师并不需要真的去编写微信小程序的脚本代码，或真的去学习JavaScript、Node.js、React之类的编程语言，但至少要知道，当一个Web前端或一个微信小程序里需要嵌入一段机器学习算法时，算法代码的实际运行位置究竟有几种选择。否则，我们如何根据实际配置与使用场景进行算法优化，从而获得工程上的最优效果呢？

（二）与AI相关的典型系统架构

• 真实世界里的AI算法，必然被集成在互联网、移动互联网世界里最典型的系统架构中，如下图所示。例如，在今天这个时代，云平台和AI成为技术世界里最重要的两个支柱。云平台提供基础架构，AI提供智能属性，二者越来越密不可分。其实，今天很多顶级的云平台就同时兼有AI平台的身份。Google Cloud提供了Cloud AutoML（Automated Machine Learning，自动机器学习）和TPU资源，Amazon AWS和阿里云提供了智能客服接口、GPU资源，等等。
  
• 笔者把真实世界里与AI相关的系统架构，或者说典型设计模式大致分成五个大类：
  （1）单机或终端系统。
  （2）离线大数据处理任务。
  （3）信息/内容密集型的联机系统。
  （4）事务/交易密集型的联机系统。
  （5）去中心化系统或协作型的任务。
• 下面，我们分别讨论这五类系统的大致特征、典型设计模式，以及它们与AI算法实现或部署方式之间的关系。

1、单机或终端系统

2、离线大数据处理任务

3、信息/内容密集型的联机系统

4、事务/交易密集型的联机系统

5、去中心化系统或协作型的任务

五、总结

• 笔者认为，产业界选拔并判断一个AI算法研究员或AI算法工程师的标准，无外乎以下几点：
  （1）是否对机器学习领域的前沿动态有足够的敏感性，且具备强烈的学习意愿。
  （2）是否具备较强的动手能力，可以快速解决核心的机器学习问题。
  （3）是否有能力根据系统工程或产品设计的要求，灵活选择最适合的技术解决方案。
  （4）在无法同时满足算法性能、系统效率、系统稳定性、系统扩展性等多项要求的时候，能否做出正确的技术或产品取舍。
  （5）是否有足够强的团队协作能力和沟通能力。
  （6）是否对目标领域的用户或客户有足够的理解与认知，并善于将领域认知与技术认知结合起来。
• 创新工场每年举办的DeeCamp训练营，就是要培养善于解决真实世界问题，擅长在产业界完成研发任务的AI生力军。要解决真实世界的问题，我们在知识积累上既需要“专”和“深”，也需要“广”和“博”，笔者希望这一讲的内容能对读者构建完整的知识技能体系有所帮助。

王咏刚《AI的产品化和工程化挑战》相关推荐

1. 王咏刚分享DeeCamp三年成功经验：学生超自主，导师很顶尖，批量培养AI人才不是梦...

   郭一璞 发自 鼎好大厦  量子位 报道 | 公众号 QbitAI 由创新工场主办的AI人才培训项目DeeCamp已经走到了第三年,从第一年的36名学生,到第三年的600名学生,北京.上海.广州.南京四 ...

2. 创新工场CTO王咏刚：人类最后一个独立写作的纪元

   原载:半轻人  作者:王咏刚  量子位 报道 | 公众号 QbitAI 编者按:这是一篇AI科学家给科幻小说写的序,但也可看作一位AI研究者对于AI能做什么.不能做什么,与科幻想象之间还有多少差距的解 ...

3. [ZT]契约式沟通（作者：王咏刚 2004 年6 月）

   契约式沟通 (王咏刚 2004 年6 月) 1 问题引入 在软件开发项目里,除了少数自以为是的家伙以外, 没有人会否认沟通的重要性.但人们往往在重视沟通效果 的同时,忽略了对沟通技巧和沟通方法的学习. ...

4. 揭秘AI 公司盈利“生意经”，竹间智能CEO简仁贤的AI产品化和工程化

   原创:谭婧 2020年上半年,自然语言理解(NLP)赛道的明星企业--追一科技在知乎曝出不少减员信息.这家"腾讯籍"高管创立的企业曾在2019年高调扩张,随之又减员.在漫天疫情之下 ...

5. 海南大学计算机学院张一教授,应用数学专业01级校友：王志刚——海南大学信息科学技术学院教授...

   2004年6月毕业于湖北大学数学与计算机科学学院应用数学系,获理学硕士学位,2012年12月晋升为教授. 研究方向 主要研究方向:不确定理论.数据挖掘.随机分析及其应用 主持的科研项目: 1.海南省自 ...

6. 王慧文的AI大模型创业成功率几何？

   出品 | 何玺 排版 | 叶媛 王慧文迎来强助力. 3月8日,美团创始人王兴在社交媒体发布消息称,个人将参与王慧文创业公司"光年之外"的A轮投资,并出任董事. 01 王兴个人将参与 ...

7. 英语流利说王翌：AI助力教育实现平衡与充分

   文章来源:ATYUN AI平台 2018年2月27日–3月1日,亚布力论坛第十八届年会在黑龙江亚布力举办.本届年会以"新时代的企业家精神--改革开放40年"为主题,吸引了来自艺术. ...

8. 全国电赛K题江苏省二等奖----王澳刚

   2017年TI杯江苏省大学生电子设计大赛   题目:单相用电器分析监测装置 题目编号:K题   参赛队编号:ZJ022 参赛队学校:江苏科技大学 参赛队学生:王澳刚 雷松泽 匡正 指导老师:王宝忠 李 ...

9. 科技部部长王志刚：2050年要成为世界科技强国

   科技部部长王志刚:2050年要成为世界科技强国 [王志刚:2050年要成为世界科技强国]王志刚表示,中国的现代化进程必须把科技创新摆在核心.我国计划在2020年进入创新型国家,2035年进入科技创新型 ...

最新文章

1. OpenCV_图像平滑
2. 滴滴自动驾驶，现在是一个怎样的“富二代”创业项目？
3. 端到端训练 联合训练_曲靖两家银行举行联合军事拓展训练 献礼祖国71周年华诞...
4. python3中numpy函数tile的用法
5. 2018-2019-2 20165209 《网络对抗技术》Exp4：恶意代码分析
6. oracle dbms调度程序,Oracle 调度程序作业( dbms_scheduler )(zt)
7. SpringBoot 2.x 集成Redis
8. Python符号计算入门及隐函数图像绘制
9. 转: 中/英文资料 PKCS #11 函数列表
10. 前台传参到后台出现中文乱码问题
11. mysql explain命令解析_详解MySQL中EXPLAIN解释命令
12. java多线程volatile_java多线程——volatile
13. 计算机专业论文评语,计算机毕业论文评语
14. cocos2d-x游戏开发 《坠入蔚蓝》
15. 财务会计之借贷记账法的【科目方向】和【科目余额方向】分析
16. SpringBoot实现发送电子邮件
17. 街头篮球服务器位置,求街头篮球各个服务器IP地址
18. 利用python计算股票相关指数
19. ARP项添加失败：请求的操作需要提升 ARP项添加失败：拒绝访问
20. php自动加nofollow,WordPress自动给文章添加nofollow属性的实现方法

热门文章

1. 让迅雷下载真正提速的四个实用小技巧
2. 英国电信 云计算还不成熟
3. “专业网络犯罪分子”对英国电信供应商进行 DDoS 攻击
4. 鲜为人知的windows命令
5. 移动APP设计国外资源总汇
6. 台式计算机机箱的作用,如何选购台式电脑机箱？小白装机选购电脑机箱知识指南...
7. python环境-基于go-cqhttp-简易qq聊天机器人
8. Java中class与Class的区别
9. SpringBoot2的Shiro最简配置（两个文件）
10. HTML+CSS3绘制九大行星