第三方舆情收集与质量闭环建设

第三方舆情收集与质量闭环建设 2016-07-04 {{allComments.length}} 2123 干货分享

【案例背景】

      软件研发过程经历了三个阶段，从瀑布式开发、至敏捷、至精益，不同研发理念背后对质量有着不同诉求。

      在硬件性能依据摩尔定律爆发式增长的八九十年代，高级语言面世，微机普及，软件需求爆发式增长。当时的实践发现，面临复杂大型软件工程，往往项目失败率高，因而有强烈的对软件工程理论的诉求，瀑布开发模式走上了历史舞台。这种模式下，对测试团队的诉求是交付完美吻合规格说明（specification）的软件产品，核心待解决的问题是用较低成本高效覆盖测试点，因而在这个时代各种测试设计方法得以长足的进步。

      之后随着零零年前后互联网的起伏，互联网企业为了快速响应用户多变的诉求，软件工程的核心诉求发生了变化，从严格按图纸施工的瀑布式开发，转而追求质量与效率的平衡。在这个时期，“敏捷模式”大行其道，为了实现敏捷而持续集成，为了实习持续集成而自动化，多半测试团队在风风火火地进行自动化改造，各种工具平台应运而生，直至今日。

      敏捷的基础上提出的精益理念，构建了从产品到用户的闭环，所谓小步快跑，产品需要第一时间被用户见到，收集用户的数据和观点，从而不断修正产品形态。一次境外会议上听到一句挺有意思的话：If you release a product that doesn’t embarrassed you, it only means that you could release sooner. （如果你发布的产品很完美，不令你感到尴尬，只能说明产品发布得太晚了）。精益模式在用户用脚投票的互联网行业中尤为适用，著名的Facebook即采用类似的方式研发产品。收集用户对新增功能的反馈，并将反馈融入产品迭代过程中，是一件对互联网产品越来越重要的事。

      弯弯绕绕赘述了冗长的背景，让我们切入正题。获取用户反馈，除了从用户行为分析入手外，主动收集用户投诉（客服途径、产品的反馈表单）和被动获取用户反馈信息，都是协同产品迭代的重要补充。本次分享讲述了百度建立反馈体系与质量闭环的过程，详细讲述第三方舆情反馈的架构实践要点与细节。期望对有类似诉求的企业和团队，提供参考经验。

一、解决方案综述

      整体工程架构，讲分为三个部分展开描述，分别是数据抓取、数据清洗、数据输出。数据抓取面临的困难是应对第三方数据源的格式变更与屏蔽策略，在多变的内外部环境下确保数据流时效性，是工程实践过程中较困难的方面。数据清洗主要解决抓取反馈数据的精粹提纯，怎样平衡时延、准召、成本，是这个部分需要讨论的话题。数据输出解决的问题是平衡好一个基础架构与业务之间的关系，我们看到不少同类系统，最终深陷于各种多样需求难以自拔，在这里我们会给出一些解答思路。整体架构见下图。

二、数据抓取

      第三方舆情的数据源囊括：微博、百度贴吧、各大应用商店、新闻、搜索、论坛，主要设计考虑以下三方面需求。1）应对多数据源的格式变更，可低成本维护；2）应对突发事件与需求，可快速大量回溯；3）应对数据源的屏蔽策略，可自适应调整。

      百度主打搜索引擎，有着深厚的数据抓取积累。我们利用大多数浏览器自带的节点定位功能，能便捷地获取一个网页中任意节点的DOM结构。单一抓取进程应能以该结构作为配置快速提取希望获得的元素信息，这样，我们就能以统一的程序，通过参数传入方式，抓取任意页面中的任意内容。每一个抓取进程将被“调度器（scheduler）”分配待抓取的链接列表与对应配置，独立工作，互不干扰，并自有延迟与异常处理。当一个抓取进程长时无返回，或返回失败时，调度端将相应任务分配于其它IP段的新起抓取进程再度重试，只至最终成功、或多次尝试后仍失败。外部数据源的屏蔽策略与网页结构升级经常会导致抓取失败，此时，系统应及时检测问题，由人工介入干预。由于采用了标准配置项，介入工作只需确定抓取失败的页面仍能打开，重新定位到变更后的元素节点，测试配置后重新抓取，这项工作可由无技术经验的产品人员、实习生、外包来担负，极大程度降低了维护成本。综上，是抓取逻辑的简要描述，也顺带回答了第一个问题，通过工程设计的解耦与隔离，大量新增和变更的数据源维护变得简单快捷。

        设计中更值得注意的部分是应对两类异常，突增吞吐、数据源屏蔽。在很多情况下数据源的抓取任务会积压，可能是某一重要业务应老板要求要回溯半年来的数据，可能是某一产品在活动期间数据量突增，可能是系统故障或触发屏蔽导致大量抓取任务延迟。在这里，我们描述下“调度器”部分的工作原理。“调度器”在抓取系统的边界限制下，分配系统的资源，主要是带宽资源、IP资源、账号（某些抓取需登录状态）资源。在任务密集无法完全完成的前提下，优先让高优任务插队，并在插队完成后的间隙，填充次优任务，以此类推。例如某一高优任务需抓取某一数据源，但限于抓取频次，带宽仍有富余，这时会依据富余量填充剩余任务，使抓取吞吐尽量饱和。另，系统也应支持扩容，以便填补新增硬件资源，以及轮休被暂时屏蔽的IP段。

      接着谈一下屏蔽策略相关内容，通常网站对某账号或IP封禁的主因无非是保护内容与防攻击。简单的禁封策略，只是一个计数归并，在一分钟、五分钟、十五分钟、一小时的时间窗内，同一账户或IP地址访问次数多过一定的阈值，往往被认为非用户行为，此时会引导手机号验证等动作，若抓取系统无容错仍坚持机械重试，会被永久禁封，需人工沟通后解禁。较复杂的策略主要是离线的异点分析，某个数值，可以是访问间隔的方差，可以是单位时间的访问次数的方差，可以是访问链接类型的分布，通过统计方法，识别出离群点，随机加以屏蔽认证。前者我们会做一个隔离的测试资源，对新数据源逐渐逼近上限，反解出策略配置，使得抓取变得高效；后者没有太好的办法，但所幸绝大多数数据源不会使用这种过于麻烦的方式。应对屏蔽策略的方案是，不熟悉的数据源需隔离测试一段时间，以免影响主系统抓取使用的IP段；发现被屏蔽及时停止抓取以免被进一步拉黑；提前准备多套备案，确保数据在各种情况下均能到位。

      最后谈一下备案策略。我们会留出足够的闲置的IP段与账号，供屏蔽时及时更替。终极备案是利用众测，在用户客户端抓取后传回。“众测”提供客户端，用户可在使用个人电脑或手机时打开共享资源，并以资源使用情况获得付费。我们的抓取终端的某个版本是可以运行在任意用户设备，抓取频率与访问方式很难被屏蔽策略捕获，唯一的问题是这一方式获得的数据单条成本较高，但作为备案是合适的。回顾下最初的设计，抓取端和调度分离可独立工作，在这里显出了设计优势。

三、数据清洗

      数据清洗分为三个阶段：数据过滤，数据相关性，数据情感标签。还有一个部分涉及到观点汇聚，因为较复杂，不在这里展开。

      数据过滤主要针对各类营销文案进行屏蔽，尤其是不少产品或活动，会在设计中鼓励用户自动在“微博”等媒体上留下分享痕迹。这些痕迹不是自然的用户反馈，且数量较大，会干扰舆情分析。转化为算法问题，有一个很大的字符串列表，找到这次字符串中出现频次高于某阈值的子字符串。这个算法时间复杂度明显非一阶，不具备可扩展性，我们的优化方案是抽样聚类后提取出模板，然后用O(N)的方法对全文本进行过滤。另一种过滤相对很简单，过滤掉字数较少的“顶”、“赞”这类的灌水。

      数据相关性主要是消除二义数据，例如百度糯米团购，简称糯米团，是百度的一个重要战略产品，但与小吃“糯米团”、以及某明星宝宝的昵称“糯米”，是重合的，需依据上下文进行分类。情感分析部分，主要涉及到反语识别与语境识别，这里举几个例子。“百度地图能靠谱点么？”，这明显是负面的情感，但可能因为产品名（百度地图）和关键字（靠谱）被识别成正面情感。“百度新闻上说，华东地区出现大面积机房故障”，这和百度新闻这个产品是无关的，但可能因关键字（机房故障）被误识别为负面信息。机器学习中的切词、分词、文本分类，原本就是一个独立领域，在这里不展开介绍算法和策略，而主要介绍支撑数据清洗的工程架构。

      数据从抓取后以原始数据方式存储，系统自动进行处理，处理的中间数据，会随机抽出百分之一至五的样本数据，供人工抽检。每个数据源针对每个产品形态，均有一个“准召率”阈值。当数据质量高于阈值时，将直接进入下一环节直至最终供用户消费；而当数据质量较低时，触发另一分支，将发起全量数据的人工标注，并以人工标注的数据回馈到机器学习的模型训练中，以提升下一轮数据清洗的质量。业务线仅需设定接受的准确率下限，从数据生成到模型的自行优化训练，是一个自动的过程，从而极大程度降低了维护成本。

三、数据输出

      数据经由清洗，进入“反馈数据仓库”。数据仓库是一个逻辑上multi-key-multi-value的存储，主要用来筛选的条件有时间，产品线，数据源，是否相关，有无情感倾向，是否经过清洗。这些条件作为key，任意组合下，能实时地获取反馈内容。仓库中的数据除了来自第三方数据源，也有一部分来自产品内嵌的反馈，产品通过调用API或SDK嵌入该功能后，将在支线流程中与用户交互，主动获取用户的反馈。

      之所以在清洗后用数据仓库的形态桥接，是出于以下设计考虑。一方面，我们构建的系统应当停留在基础架构或工具（infrastructure）的角度服务业务，而不应深入为某些业务定制开发，这需要在技术能力构建与业务需求之间清晰地划出一条界限。仓库中的数据充分结构化便于二次加工，且兼顾灵活性，是针对各业务个性化需求的架构选择。另一方面，数据仓库的技术选型有利于充分整合公司现有数据和技术资源。例如为了估算流失损益，希望挖掘负面反馈的用户的流失率，这需要与产品自有的用户行为日志合并，数据仓库是满足此类需求的最为便利的工具。且仓库背后有完善的监控、运维、BI、Ad-Hoc查询等成熟工具体系，便于复用。

      仓库基础上，我们建设了实时索引，将标记完成清洗的数据增量发布。下游用户可通过标准API形式访问，指定返回条目、时间窗口、产品线、数据源、情感、标签、关键字等信息，可获得相应反馈。由于对反馈的内容文本进行倒排索引，用户可以方便地以“百度图片”+“色情”的搜索组合，获得用户在一定时间内在微博、贴吧、论坛等各渠道的相关反馈，非常方便。基于这一便利的访问形式，除了我们提供的标准平台外，公司内还出现了不少基于这份数据二次开发的平台，形成了以反馈数据为核心的质量闭环生态。

四、应用场景简述

      第三方舆情系统主要针对三类场景：舆情监控、竞品分析、问题召回。这三类场景是层层递进关系，针对这几类场景分别举例说明。

      舆情监控是最容易理解的应用场景，例如今年夏季频发的百度搜索流量劫持，这类问题当影响流量比较较低时很难在服务器端发现。当用户针对该问题的负面反馈显著增高时，我们是能通过第三方反馈数据发现这一问题的。此外，舆情监控常用于了解产品阶段性状态，例如糯米在砸200亿开拓市场时做了几次贴现活动，由于是一次性活动无历史数据比对，舆情反馈是衡量效果的有力手段。

      竞品分析是为了辨识产品与市场主线产品的竞争优势劣势，这也是第三方舆情收集的优势；毕竟，内嵌在产品线的反馈数据无法覆盖第三方产品。例如，通过用户负面反馈比例，我们发现和美团、点评相比，百度糯米团购的退款流程存在更高比例的负面问题。这些结论对产品决策非常重要。

      最后，继上一章节，我们产出的数据支撑了很多业务线的质量问题闭环。经常会发现用户快速传播一些错误的搜索结果，例如搜索“就不上图了”，会出现大量色情图片结果，这些问题很难在测试与监控环节发现，反馈是应对的有利武器。在这些问题散布之前，我们的系统就能及时捕获，并提供给产品线进行处理。由用户扩散、发现、处理的流程，可以短至小时级别。百度有专职的风控、市场、品牌类部门，每个业务线也有负责运营的产品经理。我们的数据为这些岗位提供了有力的技术保障。

五、总结

      测试团队首要关注的是质量。我们听到的大多数实践与分享，集中在协助团队提升研发过程质量与程序质量，对“产品质量提升”这一环节，很多团队未开始介入。采集第三方舆情，提供分析，促成相应迭代，构建质量闭环这条路，是测试团队值得尝试的一个新方向。希望分享能抛砖引玉，引发更多的碰撞与思考。

如果你看的意犹未尽，如果你想随时随地充实自己，请扫描以下二维码，关注我们的公众账号，可以获取更多技术类干货，还有精彩活动与你分享~

分享到：

大咖招募

欢迎App研发/测试方面的大牛来投稿，开设专栏。我们提供丰厚的稿酬，预约个人专访，帮助建立个人技术品牌！

我要评论

请后参与评论

提交

0"> 评论（{{allComments.length}}）

{{comment.create_time.substr(0,16)}}

showComments.length" ng-click="showAll()">显示所有评论

(此文不代表本网站观点，仅代表作者言论，由此文引发的各种争议，本网站声明免责,也不承担连带责任。)