​OPPO 对话式 AI 助手小布演进之路

​导读：本文将介绍 OPPO 对话式 AI 助手小布的技术演进之路，以及小布对话技术团队在这一过程中的思考和实践。

本次分享主要包含以下四个部分:

• 第一部分，简单回顾 AI 助手的发展历史，让大家更有代入感
• 第二部分，介绍小布产品，让大家对小布的业务背景有基本了解
• 第三部分，介绍小布近四年来发展演进的情况，以及在此过程中研发团队的思考和实践方案
• 第四部分，对未来进行展望，也希望和大家有更多的交流

分享嘉宾｜杨振宇博士 OPPO小布智能中心 认知计算技术负责人

编辑整理｜田育珍 猿辅导

出品社区｜DataFun

01

AI 助手历史回顾

第一部分，首先回顾一下 AI 助手的发展历史。

这里引用了清华大学黄民烈老师分享的总结材料，他也是小布学术顾问委员会的核心成员之一。

从上图中可以看到，对话助手的发展历史非常悠久。早在 1966 年 MIT 开发了基于规则驱动的系统，面向心理咨询场景。2011 年，苹果发布了 Siri，在工业界引起了广泛关注，是一个重要里程碑。微软 2014 年推出小冰，主打智能聊天，后续也扩充了各种好玩的技能。近几年随着大规模训练技术的发展，谷歌、Facebook、百度等头部玩家都发布了基于大规模预训练的端到端对话模型，将开放域对话的能力水平推向新高度。目前在一些产品上，大模型的聊天水平在特定场景下已经不逊于人类表现，非常惊艳。

AI助手这个方向的用户和从业者很容易受科幻大片的影响，在心里种下超能 AI助手的影子。前一段时间还在和同事讨论这个问题，比如很早很早之前有一部美剧叫《霹雳游侠》，男主有一辆特别厉害的车，拥有堪称完美的自动驾驶和AI助理功能，男主角和他的车一起穿梭在各种险境之中惩奸除恶，特别让人羡慕。然后另外两个典型的超级 AI 助理大家应该都非常熟悉了，钢铁侠的贾维斯和超能特战队的大白。这些科幻片虽然夸张，但还是非常清晰地描绘了 AI 助手这个方向的梦想。

与此同时，这也会带来一些麻烦，用户全被科幻片教育了，然后当发现梦想和现实的巨大差距的时候，都忍不住骂一句“智障”！这也是在这个方向经常要面对的尴尬，但是梦想一定会实现的，而且随着近几年技术的高速发展让它变得越来越可期待。

--

02

小布的诞生

接下来对小布助手的背景进行介绍。

小布助手是面向 OPPO 集团公司下的 3 个品牌手机和 IoT 设备打造的新一代AI助手。你完全可以把它类比成苹果设备上的Siri，只不过它目前是专门为 OPPO 自家的设备服务的。

那么小布助手能帮用户做什么呢？通过小布助手，我们希望能够在用户和设备之间建立一种对话式的连接，让用户使用设备和服务更方便。目前小布已经支持的技能包括操作控制类的、影音娱乐类的、生活服务类的、信息查询类的、智能聊天等，覆盖了行业内常见的所有对话技能。

这是小布的成长记录。

最早这个产品是 2019 年开始上线，先是手机，然后是手表、电视等更多设备。在去年 2 月份月活突破 1 个亿，这是一个非常重要的里程碑。然后去年 10 月份，开始往多模态方向发展。到今年 8 月份的时候，我们发布了一个大版本 4.0，有更多的新功能上线。

这是目前小布助手的核心数据。

庞大的用户规模是这个产品的主要特征之一，目前已经覆盖了 3 亿的用户，最新月活也达到 1.4 亿，每个月有 30 亿次以上的交互量。

当然，这么大的用户量和交互量也给技术的工作带来了很多挑战，后面会详细介绍。

--

03

小布的演进

这部分重点介绍过往几年在打造小布助手的过程中我们有哪些思考，以及针对这些思考所做的具体实践。

1. 小布演进的思路

针对小布的用户，我们的产品经理做过很多调研、访谈和分析。数据表明用户的需求是非常多样的，覆盖了很多差异化的场景。如果将需求从基础到高阶的方式分层，可以分为三个层次：

• 第一层主要解决效率问题，希望能方便、快捷地帮助用户完成日常的简单任务。比如：系统的操作控制、定闹钟、设置日程等。注重工作效率的用户会比较喜欢这类的功能。
• 第二层中除了简单的操作之外，希望系统可以更智能，更好地了解用户的习惯、偏好，知道用户对哪些内容感兴趣。除了被动的交互之外，希望系统可以给用户主动的推送。
• 在第三层希望系统跟人一样，像之前提到的拟人化的交互，满足用户的情感需求。比如，在用户比较郁闷的时候可以陪用户聊聊天；甚至可以成为用户的知心朋友，在用户不开心的时候给他一些宽慰和鼓励。

这其中有些需求是当下技术完全可以做到的，也有一些很难做好。受科幻片的影响，有不少用户对机器人的预期很高，这也为构建用户满意的产品带来很大挑战。

小布的演进思路，大致可以理解成从技能建设到反智障，再从反智障到懂用户这样的路径。最基础的是你得有足够丰富的技能，能帮用户做各种各样的事，特别是得能支持刚需的场景。然后是得让用户感受到智能性，不能有太多的低级缺陷，不能太“智障”。最后还得让用户觉得你懂他，给他提供的服务是适合他的，也能和他聊得下去，建立某种情感链接。

后面的内容主要围绕小布的技能建设、反智障的方案、让小布更懂用户这几部分展开。

2. 小布演进-技能建设

上图是小布目前已有的技能概况。目前小布有 300 多个技能，对应 2500 多个细分意图。从技能维度来看，技能量不算多。但真实场景中，技能对应的用户量会呈现非常明显的头部效应，这 300 多个技能已经覆盖了 95% 以上的用户需求。我们希望通过开放平台的形式让更多开发者以低成本的方式自助接入和建设更多技能。

从技能类别来看，主要包含指令型、信息获取类、知识依赖类、聊天类、文字游戏类等。

• 在手机上，指令类的技能相对刚需，它可以解决用户对效率的诉求，对用户帮助很大。比如用户在手机上安装了很多 APP、或手机的一些入口比较深的设置项，通过语音直达的方式可以方便用户更快速触达功能点。
• 在电视类设备上，音乐、影视点播技能比较刚需。一方面，遥控器会容易找不到；另外，遥控器输入法一般都不太好用，输入比较费劲。语音的方式对于找片、搜片会特别方便。
• 开放域的聊天和知识问答的交互量很大，难度也比较高。用户的需求会比较发散，范围也比较广。这部分就会比较难处理，后面也会介绍这部分的工作。

接下来介绍一下在技能建设过程中面临的难点。特别是在叠加规模效应以后，会让问题变得更加棘手。举几个例子：

• 第一个是语义理解。这个问题目前还没有完美的解决方案，当面临大量用户口语化的表达时，总会出现各种各样的 Badcase，这一点相信长期做 NLP 技术研发的伙伴可能都有体会。
• 第二个是开放域对话范围比较广。这里主要是指聊天和知识问答。对于聊天，用户希望你能解闷，还希望你能安慰人，甚至希望你能陪它玩；知识问答包含的领域也很广，什么问题都可能被问到，比如以小布为例，每个月能收集到的不重样的问题得到千万级以上，非常的发散和长尾。
• 第三个是效果优化高度依赖人工。对话交互不像搜索、推荐场景，可以快速收集高质量的反馈数据形成闭环，高效完成优化。有一句调侃AI的玩笑，“有多少人工，就有多少智能”。虽然是玩笑调侃，但在对话的场景中也部分反应了目前的真实现状。
• 第四个对于海量用户，需要考虑模型的应用成本。目前模型的参数量像是打开了潘多拉魔盒，参数量扶摇直上，量级从亿级到十亿、百亿、万亿级别。但应用这些模型进行推理的成本是很高的。如果这些问题未能得到解决，应用复杂模型的成本还是非常高的。

前面提到的这些是我们体会比较深的在技能建设中需要解决的难题。针对其中的部分问题，我也会着重介绍一下小布在演进过程中积累的一些实践方案。

之前提到的系统开关、APP 控制都可以通过指令型技能完成。这类技能的特点是用户 Query 的本身包含了比较丰富的语义信息和信号，有比较强的信息输入将其结构化为意图和槽位。此外，意图和槽位之间也有比较强的关联关系。我们采取了融合规则和多任务深度学习的方案。一方面，通过规则降低一些计算量的开销。算法对于标准问法的识别准确率是非常高的。另一方面，引入多任务的深度学习模型也会兼顾意图和槽位的关联。这也是一个经典的解决方案，可以很好的解决误差累计的问题，能够取得更好的效果。

结合小布实际的业务经验，使用数据驱动优化和比较完善的规则校验，再加深度学习的方式在指令型的技能上基本可以做到 95% 以上甚至更高的的召准率。

第二类是知识依赖型的技能，比如刚刚提到的音乐、影视等技能。单从用户 Query很难判断该 Query 属于哪个技能。这类 Query 包含的实体信息有它自己的知识属性，在判定知识所属的类别之后，才能准确判定该 Query 所对应的技能。

比如，用户说“你帮我放个原子弹”或“你帮我放个炸弹”。没有背景信息的话，很难判断对应的技能。“原子弹”和“炸弹”都是歌曲的名字。针对这些问题，我们采用了先做实体识别和链接，后做意图识别判断的方案，这样可以有效的融合知识，最终获得更精准的结果。

接下来介绍两个开放域的场景。

开放域知识问答场景占到小布交互量的 15% 左右，属于比较刚需的场景。知识问答可以看成搜索引擎的一种终极形态的期望。它可以直接给用户简短精准的答案，这也是用户使用它的原因之一。针对这种开放域的知识问答问题，我们将其拆分为几个不同的场景进行处理。

• 第一种是相对比较封闭的问题，比如：星座、交通限行相关的问题。这类问题目前是通过定制技能来解决的，效果相对也会更可控一些。
• 第二类是事实型的比较客观的开放型问题，比如：问东京奥运会金牌得主是谁？这种我们是通过自建的知识图谱，以及对一些结构化问题的解析转化成图谱来实现。这种方式的优点是可以把答案做的特别精准。目前系统支持简单的单跳和复杂的多跳场景。
• 第三种最复杂，属于既开放又比较长尾的问题。目前通过检索式、结合知识库的方式来解决。在这种情况下，知识库的构建就非常重要。除了人工构建，我们采用一些半自动化挖掘的方案，比如基于语义理解的一些方案。从去年开始，我们也引入了一些基于生成式大模型的方案探索，希望更高效的构建知识库，且产生的知识库的内容也更优质。

另外一个开放域的场景是聊天。在手机设备上，智能聊天是占比最高的需求。一方面是因为用户喜欢调侃语音助手，尤其是一些新用户。另一方面，聊天贯穿在对话的整个过程中，在某种程度上是对话的润滑剂。有部分用户会有倾诉的需求，不方便跟周围的人说。他们希望把小布当做树洞，通过这种更安全的方式来沟通。

针对聊天场景，我们使用了检索式、生成式以及记忆的方式融合的方案。检索式大家比较熟悉，需要注意的是随着近几年预训练模型的发展，在检索匹配的时候我们引入了比较多的基于预训练大模型的方案，希望可以把语义表征学习的更好一些，使得检索更精准。因为检索的范围是有限的，要把开放域做的比较好，生成式已经必不可少。这里我们采用了 UniLM 和 1vN 建模的模型，从而生成可控且相关的高质量的回复。这里比较大的风险在于生成式的安全性。针对这个问题，我们做了很多 Query 安全性、答案安全性、Query 和答案组合安全性的控制机制。

为了让聊天变得更有趣、有用，我们特别研发了记忆的能力，希望在聊天的过程中记住一些用户主动提供、或用户提到的一些信息，从而影响未来聊天的内容。目前小布已经支持记忆很多信息，比如：位置、节日、纪念日等，这部分的范围也在逐步扩大。

3. 小布演进-反智障

接下来介绍一下对话助手建设不得不面对的问题，即：如何让AI助手表现得不那么智障。这里面的主要问题就是：对于任何一个很小的低级错误，在实际用户体验中都可能会被放大，尤其是小布这种用户体量非常大的 C端产品。要在行业中存活下来，让系统具有反智障的能力是非常重要的。

针对反智障，我们的第一个抓手是技术升级，因为它可以带来大影响面的效果提升。前面提到小布诞生的比较晚，在 2018、2019 年这个时间阶段，当时深度学习在 NLP 领域的应用已经非常成熟，所以小布的技术体系也是以深度学习为主。因为小布的整个技术没有传统的历史包袱，技术升级也会相对容易一些。这几年预训练的发展给技术升级带来了红利，我们也建设了从一亿到十亿的大参数模型的落地，从而促进小布在语言理解、泛化能力的提升，避免比较低级的问题。

模型包含多任务解码的设计，从而对下游的适配性更强。另外，在通用语料的基础上，我们叠加了特定领域对话的语料对模型进行持续的预训练。此外，我们考虑了知识增强这个方向，使得模型对知识有更好的理解。在知识增强这个方面我们也会考虑用户提到的实体相关的信息，将实体的信息关联到实体相关的百科内容中，让模型在知识理解做的更好。

这里重点介绍一下面对大量用户产生的交互流量如何控制大模型落地成本。否则，技术升级只能作为试点技术，不能进行大规模的推广。针对这一问题，我们引入了统一表征的落地方案。在实际应用时，骨干网络只计算一次。在下游应用时，骨干网络的计算结果只需要微调少数的层次，就可以在效果没有太大损失的情况下取的差不多的收益。这其实就是构造大模型的一次推理，同时解决下游 N 个任务运用的问题。计算量大概可以节约75%左右，这样模型落地就不会有太大的问题。这也是我们的预训练和提升反智障能力在工程落地方面做的重点事项。

在大模型实际落地应用的效果方面，为意图识别方向带来 2% 的质量提升；在知识问答方向带来的提升更大，有 4%。我们也会关注模型在同行业的竞争力，整体效果还是比较满意的，特别是限制在可以工业化大规模应用，参数在十亿级以下规模的体量下，模型的效果是很好的。

第二个反智障的举措是自主缺陷发现与优化。在实际的工业应用中，AI 助手的交互环境是非常复杂的，这会给语音识别和语义理解带来很大的挑战。对这类问题应对的不好，就会让用户觉得助手很不智能。另一方面，尽管没有特别好的方式来获得直接的用户反馈，我们希望将 Case 收集更加自动化，全部依赖人工会导致效率低下。之前做过数据统计，尽管小布有内外部多个人工收集渠道，但半年时间只积累了几百个 Case，这对产品优化是远远不够的。迫切需要探索新的技术，比如半自动化、自动化的技术让缺陷的发现和修复变得高效。

这里举两个收益比较大的实践案例：

• 第一个是结合语音语义联合的无效交互的拒识。用户在使用小布助手的时候，背景通常不是特别安静的，这里面会有很多环境噪音带来的无效输入。如果不对这类噪音进行识别和处理，就会导致助手的响应不可预期。因为噪声对应的意图是不真实的，不管做出什么样的响应都是不合适的。此外，在很多情况下，通过噪声识别出来的文字，人类都很难理解其对应的意图，机器去理解和响应就更困难了。因此，考虑从源头对噪音数据进行识别，并拒绝噪音数据。针对这一问题，我们引入语音 ASR 识别的文本信息作为输入进行联合建模，更精准的过滤无效输入。我们尝试过单独文本的方案，受限于数据的损失，单独文本与多模态联合建模效果有较大的差距。
• 第二个是自动化语义缺陷挖掘与修复。希望综合利用语义、非语义的信号，自动识别出助手回答错的问题，通过半自动化、自动化的方式让缺陷修复更加高效。我们设计了全套缺陷挖掘和优化的流程，借助半监督、主动学习的优化手段，挖掘召回存在误判的 Case，推进其进行校验和优化，这可以让系统进入良性循环。目前覆盖 85% 以上的技能，覆盖意图识别问题量的 48%，这种方式比人工优化效率高了两个数量级。

4. 小布演进-懂用户

以上是反智障的一些工作。第三部分是怎么更好的懂用户，这是最难的，也是未来最有想象空间的。懂用户包括，懂用户的属性、用户的行为以及用户的情感。希望通过懂用户给用户带来更贴心的产品体验，认为这个助手是为他打造的。同时，通过提升用户对助手的信任感，增加用户粘性。有了用户的信任感和粘性后，未来助手才会有更大的发展潜力。

小布在懂用户方面还在持续的发展中，目前覆盖基本属性，针对这些属性小布也可以做到记忆、提醒和影响后续部分对话交互的过程。整体还需要进一步的深入挖掘，这也是我们未来发展的重点方向之一。

此外，在懂用户行为方面，我们也已经做了一些探索和实践。比如，我们发现有些用户在需求未满足时会通过换不同的说法、澄清的方式希望助手更理解自己；有些用户会在小布犯错的时候骂他，给小布负向反馈；也有用户会在小布很好完成任务时给小布正向的激励反馈，对小布说谢谢或夸赞。我们了解到不同用户的行为后，也针对不同的用户行为做反馈，提升小布的理解能力。

针对反复澄清的用户，我们实现了自动化离线学习外加在线澄清的方案用来实现和满足用户需求。通过澄清的方式，猜测用户意图，最终帮助用户达成诉求。这不仅对当前用户是有效的，对相似的用户场景也是通用的。

针对用户的批评和表扬，我们也制定了小布的口碑满意度体系，降低用户对小布的不满，提升用户满意度。

懂用户另外一个重要的维度是和用户共情。针对这一方向，小布做了一些情感引擎和情感理解的工作，识别和跟踪用户的情感变化，为用户提供情感关怀方面的交互。目前还处于比较初级的阶段。总的来说，在技术层面上理解用户情感是相对可控的。但如何在理解的基础上交互让用户感受更好，这一课题还需要更多的探索。

此外，在理解用户的潜在需求方面，我们也希望有更多的工作落地。比如，用户反馈被打了或者被批评了。我们希望可以通过交互的方式深刻的挖到背后的原因，结合原因再使用交互的方式去满足用户的潜在需求，从而对用户有一些疏导。

--

04

未来展望

以上就是小布演进过程中，我们做的思考和实践。AI 助手目前在非常高速的发展中，如果大家关注到一些顶级会议论文研究方向的分布，会发现对话助手相关的研究是非常活跃的。这里对未来 AI 助手的未来方向做一个简单的展望。

首先，AI 助手覆盖的设备载体越来越丰富。从用户角度来看，拥有多设备的用户也越来越普遍。在做好单设备体验的同时，我们相信多端融合也会是 AI 助手的趋势之一。通过 AI 助手实现更好的跨端协同智能，在协同体验 AI 助手会有更强的竞争力。

在产品形态层面，目前产品已经从传统的语音、语义的方式转向多模态数字人的方向演进，目前多模态也是必然的发展趋势。小布在多模态虚拟人方向也有一些落地，如：虚拟人直播带货、播报天气、播报新闻。实际上也吸引了很多用户的关注，虚拟人的交互方式天然让用户的感知更明显。

除了外在表现，我们认为内在的灵魂同样重要。完美的 AI 助手需要有情感，有记忆，有观点。助手需要逐渐成长，值得信赖。所以我们认为人格化也是未来的趋势。

除了刚提到的技能建设的基础体验，以及反智障、懂用户这种持续的提升之外，我们希望小布助手在理论上有持续的发展。比如，借助于情感引擎、拟人对话能力等各方面的技术，给用户提供有自我的 AI 助手，成为用户贴心的伙伴。

最后想说一下，在 AI 助手这个方向，经历了从早期的客服机器人到全能型智能助手，再到多模态虚拟机器人的变化。AI 助手在车载、电视、智能家居等各个场景上被越来越广泛的应用和接纳。随着设备互联互通逐渐成熟，智能助手也慢慢迎来了自己最好的发展机会。在这些复合场景下，AI 助手的价值能够带来更好的体验。相信未来在万物互融的场景下，AI 助手会发展的越来越好。

以上就是 OPPO 对话式AI 助手小布技术演进之路的分享，非常感谢大家的时间！期待与大家一起交流！

--

05

问答环节

Q1：怎么用模型做好跨域的多任务指令？比如，播放周杰伦的双截棍，并调大一点声音。

A1：我们做过一些探索，但后来发现这种说法比较长，用户实际表达时会有一些难度，覆盖面不是很多。但从技术来看，这个问题是有意义的。我们探索过两种不同的方案：

• 方案1：对用户的query进行解耦，把它进行改写。即：把复合指令拆解为多个单指令，单个进行解决。
• 方案2：端到端的方案，在任务设计时，考虑到多种意图和槽位耦合的情况。在建模时提取query中包含的信息的意图和槽位。基于结构化的信息，寻求最优化的路径，覆盖满足组合的指令。

主持人：小度、谷歌之前也遇到同样的问题，这个主要的难点是很多意图组合在一起后语料会比较稀疏。

Q2：意图识别时如何区分闲聊和任务型对话？

A2：任务型的query是比较好区分的，因为很多任务型的对话是封闭的。闲聊的边界非常难确定，我们现在采用的方案是由前置的自然语言理解模块（NLU）对任务和闲聊分别做识别。任务型的判定会更精准一些；闲聊的对寒暄这类高频的闲聊会更准确一些，但我们希望它的召回更强一些。两个方面都做识别后，后置会去做融合排序，结合一些先验的经验，比如：我们天然认为任务型判断更精准一些，因此任务型的判定优先级会更高。在融合排序时，会将判定优先给到任务型。当任务型未覆盖时，有一些会流转到闲聊进行兜底意图识别。当然，像寒暄类的高精准识别的闲聊，可以和任务类型意图的判定做置信度竞争，避免数据分类太偏向任务型。

主持人：在小度实践中比较难的其实不是闲聊和任务，而是闲聊和信息问答。这两个都是开放域的对话，区分会更加困难。目前小度闲聊中有生成式的回答，什么类型的问答都能接住。这会导致闲聊型和信息问答更难区分。

Q3：在检索式召回中，是否需要对领域的内容进行finetune?在缺乏反馈的情况下，是否有好的冷启动的方案？

A3：目前小布在知识问答和闲聊场景都有用到检索召回。根据我们的实践经验来看，是需要finetune的，需要做一些特定数据的增强。

预训练可以让冷启动的成本更低。预训练没有标注的语料成本不是很高，加上这些语料对解锁语义表征能起到很好的作用。

Q4：当前是否主要依赖于数据标注？

A4：非常坦率来讲，确实依赖数据标注。但我相信未来的方向，包括我们现在做的一些尝试，都已经在往依赖标注数据比较少的方式前进。这么做一方面是由于标注成本，另一方面也是因为标注不能解决所有的问题。整个系统的迭代会随着系统的深入和技能的增加，意图打架以及边界不清晰的现象会越来越难解。另外一个比较好的趋势是预训练会降低对标注数据的依赖。

总结一下就是，目前对标注的依赖还很重；但到了深水区，标注不能解决所有的问题。因此还需要探索新的方案，像今天分享提到的自主的发现一些缺陷、一些隐式的信号，并对其进行修复。

主持人：这里我也给大家一些信心。大家有一个共识：冷启动的类目，尤其是没上到线上的类目，确实比较依赖数据的标注。我们很多大模型会有很多pretrain迁移学习，但到了当前特别的领域下，会依赖数据标注。

但目前小布、小度包括业内的一些公司都会去做一些自学习的探索。很多发布到线上的，对人工的标注会依赖的比较少，这部分可以通过用户的反馈来学习。这还是可以给大家一些信心的。

Q5：针对跨任务多轮指代消解，有没有好的方案？比如，先询问我的会议是哪天？机器人回答之后，用户再接着问，那天的天气怎么样？

A5：针对多轮指代有两种策略：

• 第一种是结合上下文，用深度学习端到端的方式做指代消解。这个在前几年好像效果没那么好。但根据我们的实践、借鉴行业经验、学术论文，我们发现端到端的指代消解在当前的时间节点已经做的蛮不错了，可以把当前的query还原成上下文无关的query进行处理。可以用端到端指代消解的方案大胆的进行尝试。我的经验觉得这种方式已经非常可行了，我们也有实际的上线。
• 另外一种是根据状态信息做一些继承和切换，可以知道当前query结构化之后需要哪些信息，这些信息是否可以从前文的交互内容中找到并填充到query中。这种方式会更偏向于规则和策略。

我会更偏向于前一种方式，经过近一两年的实践，我觉得这个问题已经不太大了。

今天的分享就到这里，谢谢大家。

｜分享嘉宾｜

｜DataFun新媒体矩阵｜

｜关于DataFun｜

专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章800+，百万+阅读，15万+精准粉丝。