软件邂逅数学之美

2005年，互联网和通信行业乍暖还寒之际，我加入了华为，从软件开发到软件技术和数学算法的突破，一路走来，对软件技术乐此不疲，只源于初心——用软件技术解决业务问题，不断挑战自我，在华为大舞台上慢慢爆发自己的小宇宙。
 

从基层做起，修炼软件内功

        刚入职时，我从最基础的软件开发做起，出于对软件技术的热爱，在开发质量管理、信息安全等业务领域的工具平台的过程中，我总想着用各种软件技术提升易用性和性能，让用户使用得更方便、业务运转得更流畅，而不是让用户和业务委曲求全于工具平台。

记得开发首个大型复杂的Web Service应用平台时，遇到Web Service与Java面向对象融合的技术难题，我深入研究Java虚拟机原理和源代码，研读很多书籍去理解面向对象的原理，并编写大量代码来实践Java面向对象技术，还寻找各种机会与公司内外的软件专家交流学习，陷入了从略懂到不懂，再到懂与不懂的循环与彷徨。我都有点走火入魔了，有一天深夜，我躺在床上，脑袋里全是对象，这些对象犹如金庸武侠小说里的人物，在内存中动态地创建与销毁，随着业务流构建相互关系……此刻，我对Java面向对象技术好像顿悟了。

从此，我对Java和面向对象的理解进入了新的境界，不再害怕它，而是去亲近它，进一步追求Java在软件算法和分布式并行计算方向上的突破。
 

算法技术驱动产品从无到有突破

2011年，业界开始探索和实践如何评估一张网络的用户业务体验到底好不好，我调入产品开发部负责用户体验保障的特性设计和开发。

刚开始自然是边干边学，组建新团队，熟悉新环境，积累新业务，学习新技术，虚心向周边同事学习，并及时总结和交流分享，求知若饥的空杯心态让自己各方面能力迅速得到提升。

我很快发现数据业务用户体验的测量算法还不太成熟，该算法是最基础、也是最难的技术，它通过对TCP流进行建模来评估TCP传输质量和数据业务质量。为了把该算法做到商用要求，我追本溯源，用了3个月潜心研究《TCP/IP详解卷1、卷2、卷3》、HTTP协议和原理，把算法依赖的技术原理彻底吃透后，重新从协议原理上推论该测量算法，再结合实际业务数据和统计算法对该测量算法进行重构，并使用多种软件算法提升了软件模块的性能，经过欧洲某大T首个实验局验证，算法准确率提升了30%，运行速率提升了5+倍，终于达到了商用要求。

2013年初，客户为我们站台，携手成功参展巴展，5月份下了首个商用订单。2013年底，我们团队累计收获X千万美金商用订单，也获得公司金牌团队奖。

随着MBB时代到来，网络规模、用户数量和数据流量都蹭蹭蹭地往上涨，平台所使用的统计分析技术越来越赶不上要处理的数据的爆发式增长，规格和性能遇到了极大的挑战。我开始考虑：如何用更好的算法更快地统计分析海量数据？海量数据的价值究竟是什么？

这些问题和思考再一次推动我向软件算法技术方向突破，于是我来到中央软件院，专注大数据AI应用算法研究和组件开发，通过软件技术、数学和统计算法更快更准地挖掘分析海量数据，为公司产品打造新的竞争力。
 

当AI遭遇大数据算不动，怎么办？

我的首个AI应用算法作品是“小区一体化体验管理”，简单理解就是让运维系统学会如何有效管理无线基站和小区，以及智能分析业务体验恶化原因，比如：是否有些基站需要立刻关注？它所服务用户的业务体验是否恶化了？以及如何快速准确分析恶化原因？……

传统方法是通过人工设置固定门限和规则来发现和分析业务体验恶化及其原因，可一个大城市几千个基站，几万个小区，每个小区的话务及数据流量不一样，门限值按理自然就不一样，就像体检，每个人的体质不一样，对同一指标的反应也是不一样的。

那AI如何让运维系统学会智能管理小区的业务体验呢？可学习对谁来说都不是一件轻松的事情，对机器而言则更为痛苦：一方面苦于海洋之水太浩瀚，动辄几千万、亿级的数据学不过来，学到死机是常态；另一方面就单个个体而言（比如小区），供学习的数据又太少，不足以生成准确可靠的生命体征。

        在小区一体化体验管理中，学习问题原因模型的核心算法是FP-Growth（Spark开源社区的频繁项挖掘算法）。客户最初要求对5000小区百万级数据进行学习和挖掘，我们很快就搞定了，随后数据量增加到4万小区亿级数据量，要求1个月内给出分析报告并向高层汇报。当时采用6台PC服务器，一运行这个300多维*亿级数据就死机和内存溢出。

公司内外部的算法专家建议的方案是降维和减少数据规模，我们也进行了尝试和验证，发现问题原因分析的准确度损失了10%以上，客户反馈无法接受这个结果，认为我们的AI算法仅是婴儿，无法投入大规模网络使用。就像我们去医院看病，好不容易挂了一个专家号，给出的诊断结果却有较大的误诊率，我们理所当然不能接受。

面对客户的质疑和高商用标准，我选择死磕该技术难题，想再一次在进度压力和难关面前挑战自己的极限。我在2周内争分夺秒地深入剖析FP-Growth算法原理、数学公式和源代码内核，经过不断地推理和论证，终于抓住了这个算法的本质，我兴奋地发现——频繁项挖掘中隐藏了关联关系，立刻设计了全新的数学公式计算关联规则，将传统方法从百亿级空间搜索频繁项及次数来计算关联规则，改进为在FP树(频繁树)中直接存储频繁项的关联关系和次数，计算频繁项的同时完成关联规则计算，复杂度从指数降低为常数，并很快完成了推理论证。

接着在FP-Growth源代码上仅增加了50行Scala代码就实现了高并行软件算法，大幅降低Spark的shuffle（可以理解为降低多个服务器之间数据传输吞吐量和时延），并行加速比提升好几倍，用3台同样的服务器15分钟完成300多维*亿级数据的关联规则学习，性能提升了60多倍，不损失任何准确率，该算法也申请了1个国际专利和发表了1篇论文。

4万小区的分析报告获得客户高层认可，要求立刻转入准商用，经过2个月的验证，发现问题和解决问题的准确率达到了90+%，时间周期从1周缩短至2小时，运维成本降低38%，超出客户期望，客户高度评价这是“首个最接地气的大数据分析场景”，客户也因此获得集团的创新一等奖，接待了来自全球15+个大T的参观。

这一次，我很幸运亲自体验了软件和数学完美结合的突破为产品带来的商业价值，也坚定了我向软件算法、数学算法、分布式并行计算紧密结合的方向持续突破。
 

软件与数学“联姻”挑战AI应用量产难题

近几年运营商数字化和智能化转型过程中，业务推荐、流量预测、应用模式识别、网络智能优化等AI应用的需求量越来越多，例如：我们经常收到运营商的客服电话“您好，根据您的业务使用习惯，我们觉得您更适合XXX套餐……”，结果发现她推荐的很不适合，无奈地婉拒了。其实，我们的消费历史数据都在运营商数据库中，那运营商如何运用这些数据快速构建推荐算法，精准地为每个用户推荐套餐呢？

传统交付模式都是case by case地交付，每个AI应用算法都需要算法专家花几个月的时间去研究和开发，尤其是特征工程和模型构建的技术难度大且非常耗时，还要匹配工具平台的版本节奏，整个交付周期特别长，有时会遇到客户搁置交付或取消交付的尴尬局面。

我再次脑洞大开：如果在某些业务领域能够实现特征工程自动化、算法模型自动选择和参数自动调优，部署到云上，业务人员能简单快速构建和交付专家级的AI应用，那就太酷了！例如：上面提到的套餐推荐场景，运营商把历史消费和套餐相关数据输入到云上，云自动训练推荐算法模型并给出推荐结果，帮助客服人员精准和高效地为用户推荐套餐。

其中，传统机器学习的特征工程自动化技术是个业界难题——随着特征数量和数据规模的增加，特征变换空间和最优特征搜索空间呈指数级增长，更快更优的搜索和优化技术亟待挑战。我和多位博士一起研究了业界大量论文和研究成果，与业界多位教授和专家进行了深入研讨，结合电信业务和数据特征，找到了一些关键问题的突破口，并将其抽象为统计、优化、数学建模和求解问题，然后与业界顶级数学和运筹优化领域的教授合作，共同挑战和突破该业界难题。

经过半年的研究和突破，特征工程自动化技术取得了阶段性成果，我们发现了电信业务领域的数据关键共性点，构建了学习数据特征和规律的算法，以及信息熵上限近似模型，探索了更快更准搜索最优特征的算法，同时基于Spark分布式并行与Java多线程并行实现了该算法的高并行软件模块，将Spark序列化技术与Java面向对象深度融合提升算法软件加速比，经实验室验证，比业界算法的准确性普遍高5%以上，运行速度快7+倍，经某运营商客户Beta局验证，App用户推荐转换率提升近10倍。

我们团队和分布式与并行软件实验室正在进一步突破特征工程自动化技术，挑战更高的准确率和运行速度，同时将该技术迁移到更多传统行业的销量预测、库存预测、精准营销、信用评分、欺诈检测、用户挽留、智能推荐等AI应用场景，降低AI应用门槛和缩短TTM，我们的目标是让业务人员在云上简单、轻松、快速构建和交付专家级AI应用，提高AI应用产能，支撑传统行业数字化和智能化转型。

 追求探索更准更快的AI应用算法技术团队
 

        十三年来，在数字化与智能化的洪流中，一步一个脚印，始终用做产品的情怀做技术的leader，坚持把软件技术与数学算法紧密结合突破AI应用算法，打造产品商业价值和竞争力，这也是我今后持续追求的梦想。 

本文为《华为人》版权所有，未经允许不得转载。如需转载请联系编辑部hwrb@huawei.com