服务问题的爆发
阿里云连续n个季度实现了三位数的增长！很多人看到光环和利润的时候，不会想象的到云计算背后的服务压力有多大！云计算大大降低了传统IT实施的技术门槛，用户群体迅猛增加。正如王坚博士所说，云计算正在逐渐成为像“水电一样的基础设施”，然而却远远没有成熟到像水电那样简单易用。结果是，门槛的降低、行业的发展带来了售后服务需求量的爆发。与此同时，云产品越来越丰富，功能和架构也越来越复杂。云计算的服务需求本来就远比购买或者财务操作流程要复杂许多，它带着强烈的技术属性，每个客户使用云产品的业务场景也是千变万化。数量和复杂度的叠加，成为了阿里云这样的云计算企业必须要面对的问题！是不是可以通过成千上万的客服坐席来解决呢？抛开成本不谈，如何保证如此大量的客服都具有优秀的服务能力、达到服务标准，还能迅速的跟上产品的演进和更新？阿里云服务必须找到“人海战术”之外的突破口！
人工智能的担忧
人工智能此时就该“舍我其谁”地冲上去了吧？而实际上，疑虑重重，一波三折。人工智能，大数据，机器学习，这些前沿而又高深的技术令人觉得神秘而又憧憬。但在工业界，如何以产品的形态落地依然是个难题。云计算客服需要的机器人，和大众熟悉的机器人DeepBlue 和 AlphaGo，差之千里。人工智能在计算机实验室里有着很长的历史，DeepBlue 和 AlphaGo分别在国际象棋和围棋领域大放异彩，但在商业应用上，它却仍然停留在用人类教会的知识套路，借助更快的计算速度，去代替人类的重复劳动，其核心价值在于在既定的“棋谱”规则下能够“算得快”和“不知疲倦”。
在客服领域，如果服务场景知识体系相对稳定，不需要频繁地依赖人工重新“教”，那么机器人是可以胜任的，但，这显然不是在说云计算。云计算正在以惊人的速度创造新的云产品和云上IT 解决方案，功能和架构也在快速迭代更新。云计算智能服务面临难度更高的考试，必须要“学得快”，而且要尽可能减少对人的依赖！这在人工智能应用领域是一个行业性的难题，原因就是——很难有足够的符合要求的数据来“培养”学习能力，这也成为了智能服务持续运行起来的最大担忧。
云博士破土而出
面对这些疑虑和挑战，阿里云服务团队投入了一支先锋力量作为智能服务的开拓者。任务代号：云博士；任务目标：采用简单易用的问答机器人方式帮助用户智能高效的解决云产品问题。
项目开始没多久，难题就不出意外地接踵而至。云博士团队像打怪兽般的去克服解决了一个有一个棘手问题，杀出一条血路，并愈战愈勇！在这些磨练的过程中，逐渐打磨了产品的强大能力，诞生了最懂云计算的高智商机器人“云博士”！
到底是什么样的优秀品质能让云博士帮助用户解决这些复杂的云计算问题，来稳住阿里云的人工服务？让我们逐渐揭开其神秘的面纱。
1 - 半自动化式的技术数据标记
稍微了解一点人工智能的朋友都知道，要做智能化，首先得有足够数量的训练集用来训练模型。要能解决问题，这个训练集中需要包含大量的问题和答案，通常一个答案需要对应不同表述方式的问题。并且要得到一个好的模型，数据的质量也是至关重要。通用的做法是由人工整理来生成这个知识库。云计算行业的特殊性在这个时候体现出来了：云计算知识库的技术门槛高，需要具备深厚的云计算技术背景的工程师来做，过程中可能还需要实验验证，不像业务型的知识库简单易学可以通过众包的方式来实现。
最开始，服务团队组织了一批售后工程师，利用晚上和周末的时间集中标记数据。但事后发现因为需求量大和知识本身的技术门槛高，人工整理出来的知识库里存在大量的不准确甚至是错误的内容，而且人工的效率也非常低。评测发现，云博士使用这样的初始版基础数据，问题成功解答率远远达不到上线的标准。这不仅意味着这一批人工打标整理出来的数据几乎用不上了，更糟糕的是，它沉重地宣告了这个貌似“通用”的方式对于云计算这样的技术领域行不通。
整整一个月，团队一直反思，人工肯定会存在失误，而如此大量的使用人力，是否反而增加了人工成本？无数次的尝试、争吵和修正方向之后，似乎终于看到了门缝的一丝光。售后工程师在服务客户的过程中，会留下碎片化的记录。在仔细看了大量的这样的记录之后，团队逐渐摸索出一套方法来对这些碎片化的非结构化的记录去做分析，包括去噪、脱敏、段落分解、抽取有用信息、信息聚合等，可以一定比例的自动分析出知识库所需要的内容。这样，程序能实现90%以上的工作量，最后由人工做一些确认即可。相对于传统数据标记，这个确认工作可以明显降低对人的技术门槛要求，也可以节省大量的人工思考、搜索、实验的过程。这是一个离线处理大量非结构化数据的过程，存在诸多技术细节上的难度和结果的不确定性。终于，这种方法被实验论证出可行！就这样，云博士的基础数据在这种半自动化的计算、挖掘以及轻量人工确认的方式中产生了。
2 - 场景化的问答能力，比用户更了解自己的系统
目前我们接触到的机器人基本都是通过知识库来做问答，也就是使用计算模型在基础数据中找到分数最高的几个答案，推送给用户。云博士在上线初期，亦是如此。但很快，我们就发现只通过用户问题的语义分析通常并不能很准确的定位到问题，有时候还会出现答非所问。举个例子，用户问“我的服务器不能登录了，怎么办？”，机器其实并不能理解这句话背后的意思，它只能去分析这句话和它已经学会的知识库里的其他语句所代表的意思差距有多大，然后找到最接近的句子对应的知识点作为答案推荐给用户。而这个问题对应的语义高度接近的句子有很多，对应的答案也有很多，比如：服务器被攻击的处理方法，资源跑满后的优化实践，启动服务器的操作流程等等。为什么会有这么多答案呢？原因是：在云计算的环境下，用户往往只能看到问题的现象，通过问题现象来探索其背后的真正原因，其实中间还缺失了一环，所以面对多个答案时，机器人并不知道该推荐哪个答案。如果只是靠语义的相似度，经常会出现答非所问的尴尬，这也说明机器人并不“懂”用户。
通过团队的不断摸索，和业务同学的不断讨论，我们建立了场景问答。将现象相同的一类问题定义为一个场景，当用户的问题命中一个场景时，收集用户线上的一些运行时数据，来进一步通过决策树对其真实原因进行细致的诊断，为用户提供一个更加适用于当前场景的答案。这时候，当用户再问“我的服务器不能登录了，怎么办？”时，云博士会收集用户的实例欠费、黑洞/清洗、CPU/带宽跑满、运行状态等等一系列数据，如果诊断出用户的实例处于关机状态，则会为用户推荐如何启动查看实例的解决方法；如果诊断出用户的实例欠费了，则会为用户推荐如何续费的解决办法。
基于场景的问答，极大的拓展了基于自然语言理解之外的问答能力，能够对用户系统的运行健康状况和用户行为分析来实现更精准的回答用户问题。做到相同的问题，不同的用户，看到不同的答案，千人千面的服务于云计算的广大用户。
3 - 自我学习、自我更新的运转模式
机器人在线上运转一段时间后，我们发现业务的效果会逐渐变差。显而易见，随着业务的飞速发展，机器人必须要想办法快速的学习新知识点，淘汰旧知识。目前的通常做法是通过人工方式对数据进行全量查看检查，剔除其中的错误并补充新内容。如同基础数据标记一样，这种方式对于云计算行业是行不通的。
半年多的时间，团队探索出一个让云计算智能服务机器人主动“反省”和“学习”的方案。他们保持算法白盒化，将其内部每次执行过程中的关键路径以“日志”的形式记录下来，把机器人每次解答问题的实际效果也记录下来。然后对两者做对比分析，找出机器人知识体系里的错误知识Unkown Unknow（机器人认为正确，但实际错误）和知识盲点Known Unknown（机器人知道自己不会）。此外，机器人还具备了客户行为轨迹和人工服务轨迹分析能力，通过工单数据，每天主动向售后工程师“学习”，来持续补充知识盲点所对应的答案。
在这整套的自学习方案中，也有少量的人工审核的工作。对于云博士产品来说，有一支“人工智能训练师”小组专门来兼职做这些数据的轻量人工审核，来长期辅助机器优化最终的业务效果。
云博士逐渐成长为一支隐形的“售后智能处理组”
随着云博士的加入，开始承担起了阿里云一部分人工服务量，以更方便快捷的方式服务于我们的线上用户。现在云博士已经逐渐成长成为一支日不落的“售后智能处理组”，上线短短数月已经成功帮助使用阿里云的用户实时解答数百万个问题。目前，云博士每天正在帮助数万用户在寻求人工之前自助智能的解决云产品问题。云博士还提供了多样化的服务方式，不仅以PC端、APP端、钉钉群等智能问答机器人的形式随时随地听凭用户调遣、秒级响应，还在用户的工单排队期间提前为大家推荐解决方案。在用户和产品量迅速增长的背景下，阿里云的人工服务量维持稳定，并在小幅持续降低。将来，这支智能处理组的能力还在不断壮大，凭借阿里云的技术优势，更加精准的服务于我们的用户，做到更聪明，更懂用户。
对于阿里云智能服务，可以说，我们现在仅仅是找到了一个方向。除了想办法解决眼前的问题，更重要的，是想今天的每个决定在明年或者更远的时间可能会产生什么价值或是问题，能确保我们选择的这条路可以持续走下去并且越走越宽，能够建立云计算这个行业通用的智能服务解决方案。未来的十年，未来的人工智能会像互联网一样，渗透到每一个场景、每一个设备和每一种服务里。
相关资源：七夕情人节表白HTML源码(两款)
