搜狐黑客马拉松2019

发表于 | 分类于 | 评论数： | 阅读次数：

作为打酱油的角色参与了搜狐黑客马拉松2019，用一天的时间设计并实现了一个叫Trace的资讯类产品，尝试利用机器从海量文本中挖掘事件相关新闻并结合事件发生的先后逻辑进行时间线梳理。一个人负责算法部分，半天查阅相关文献，半天实现功能，累到吐血。虽然最终没得奖，但是收获颇丰。
一个人一天的demo和一个真正落地的线上系统有着本质的差异，这是两种完全不同的状态，hackaton可以用很简单粗狂的模式进行开发，但是后者却不可能。感谢这一天时光，让一个迷茫的后端工程师对算法又重燃了兴趣。

梳理产品需求

灵感

灵感来源于生活，最近经常发生热点事件的反转。在这个信息大爆炸的时代，假如我们没有对一个事件进行及时的追踪，就很有可能导致跟不上事件的进度，无法对事件的起源、经过、反转有一个全局的视角。

竞品

我们对一个名为“后续”的app进行了竞品分析，发现如下的问题：

  1. 内容同质：本质只是内容聚合
  2. 逻辑缺失：时间线仅是文章发布的时间线
  3. 人工干预：事件线索由人工梳理
  4. 本质问题：技术瓶颈

产品定位

定位：利用机器从海量文本中挖掘事件相关新闻并结合事件发生的先后逻辑进行时间线梳理的资讯类产品
应用场景：在选定事件后对其进行追溯及跟踪
优点

  1. 在海量的信息中迅速为用户梳理出事件逻辑；
  2. 智能追踪事件后续发展

设计技术架构

根据产品定位，我们拆分成四步子问题：

  1. 有哪些新闻
  2. 有哪些事件
  3. 哪些新闻属于哪些事件
  4. 事件中新闻的筛选和排序

完成这个产品实际就是对这四个子问题分别给出尽量精确的答案，否则每个步骤的积累误差会导致糟糕的结果。

探索与解决方案

下面让我们来解决这四个问题，技术方案只看了半天的文献，由于只有我一个人去回答这四个问题，所以以下解决方案是经过一定权衡的，不代表业界的正常方法。甚至也不能说是主流的解决方案，只能说是带着问题脑补的四个子系统。

一、有哪些新闻

我们选取了搜狐娱乐频道一级二级优质账号发文，范围是从年初至今，共有87240篇。选取优质账号是为了使事件相关的文章内容尽可能优质；限定娱乐频道是为了让我们的想法在一个领域限定的语境下能work，同时娱乐圈的新闻有着高频的时间线，同时不那么严肃，不至于产生新闻事故。
首先第一个想法是去做文章的摘要生成，有以下三点原因：

1
2
3
是因为文本的内容特别多，所以做摘要之后能更好地统一文本的长度，方便之后的处理。  
使用文本摘要代表文章能加快之后的匹配速度。  
搜狐文章里生成的摘有长度限制，质量也不高，基本不可用。

下面来动手生成文本摘要：

  1. 分词使用pkuseg分词工具（Xu Sun，2012）
  2. 选用在微博训练集上训练的分词模型，对娱乐相关文本准确度更好
  3. 用户词典选用明星姓名
  4. 长文本摘要生成使用TextRank（mihalcea，2004）

于是这个摘要就描述了这篇文章

二、有哪些事件

事件的抽取属于一个很难的问题，这方面的研究也很多。一开始我们的野心很大，打算做事件的自动提取，就是从文本中由机器无中生有地抽取出事件。实际上，我们试图完成的子问题，叫做主题发现（topic discovery）。
很自然地我想到类似对话系统中的“填表”解决方案，于是想尝试文本级的事件抽取，从文本中找到特定类别的事件，然后进行填表；后来看到LDA可以做主题生成，于是想用LDA生成主题然后再加入一些人工干预，把主题总结出来。实际上后面这种解决方案的人工干预过多，同时生成的事件还不够热点，这时候能不能使用挖掘搜索日志的方式来就行热点事件的生成呢？
于是我盯上了微博的搜索结果，无中生有主题的方案感觉很难，而且由于缺乏知识图谱相关的系统也做不到很好的效果。于是退而求其次，我提出了一个“人工维护事件的最小线索+关键词扩张”的方案，企图用最小的人工干预来描述事件。
下面来动手生成事件的关键词组：

  1. 人工给出例如：“张丹峰出轨经纪人”, “最强大脑”, “范冰冰阴阳合同逃税案”等
  2. 作为关键字在微博中进行搜索，限定媒体账号，选取最热的十篇生成描述事件的关键词

于是这一组关键词就描述了这个事件

三、哪些新闻属于哪些事件

这个问题其实就是计算文本相似度的问题，我们采用了doc2vec的方法

  1. 第一步中生成的摘要文本作为训练集, 使用doc2vec生成文本的向量
  2. 再用爬取的文本去匹配出相似度高的新闻

四、事件中新闻的筛选和排序

实际上要完成的子任务就是事件的时序关系识别，但是这一块依赖于事理图谱。我们由于缺乏领域的相关数据所以采用了一种非主流的解决方案：

  • 聚类分析，生成最相似新闻的几个集合
  • 规则筛选，最相关的新闻（同一个集合内）只保留热度最高的

筛选之后，就能避免由于重复发文导致的时间线混乱，变成简单的聚合阅读的产品。

马后炮调研

由于黑马一天的时间能做的事情太少了，于是这个章节用来总结黑马大赛之后的调研，用来跟踪学术界/业界正规的解决方案。算是一种不甘心，因为脑补出来的方法实在是太幼稚了。
事件是一种重要的知识，近年来，越来越多的工作关注于从开放域或领域文本中抽取结构化事件知识。同时，除了本身就很困难的事件抽取任务之外，近年来，越来越多的研究者开始关注于事件的推理工作中（事理推理，事件时序关系推理，事件 common sense level 的 intent 和 reaction 推理）。
这两个工作对应于我们这个小项目的第二和第四问都是很难的问题。

事件抽取

后期经过调研，发现事件抽取的基本任务都可以用以下几个方面概括：

1
2
3
4
事件触发词检测 Event (trigger) detection
事件触发词分类 Event trigger typing （一般和detection一起做，归结为detection的一部分）
事件元素识别 Event Argument Identification
事件元素角色识别 Event Argument Role Identification

从 An Overview of Event Extraction from Text [F Hogenboom .etc ] 中可以总结出事件抽取方法主要有以下几种：

  • Expert knowledge driven approaches(pattern-based approaches): 这个类别的方法主要是借助大量的已有的事件 patterns，比较适合于领域的事件抽取，将文本中的句子和已有的事件 patterns 进行匹配。同时使用词汇+语法 patterns 和词汇+语法 patterns 来进行 patterns 制作。这种方式往往能够抽取出准确度较高的事件表达，但是这种方式比较费时费力，并且有领域局限性。
  • Data-driven approaches (Machine Learningapproaches): Data driven 的方法借助machine learning 的相关算法，以及深度模型来进行触发词判断等。具体来说，使用SVM，ME，CNN，RNN等方法来判断句子中某个词是否是触发词，重点都是在如何学习文本中 sentence 的表示，来提高判断准确度。另外，也要用 AMR 进行事件本体结构构件，并达到基于事件元素角色、基于事件上下文的自动语义标注。这种方式的好处在于相对需要人力较少，并且可以做开放域文本的抽取，但准确率自然不算高。
  • Hybrid event extraction approaches，简言之，就是在做 event detection 的过程使用 pattern based 方法，在做 event typing 的时候要使用 machine learning 的一些方法提高模型的泛化能力，从而在减少人力的情况下尽量做到精准。基本现在近年的工作都是以这种方法作为基础的思想，并且在事件表示，事件学习结构上下足功夫来对事件抽取的各个具体难题进行一一解决。

先有事件模板，然后事件在确定了 trigger 类型之后，应该根据这些模板来进行填槽（slots）。这其实有点像我之前脑补的填表解决方案。
由于我们做的项目其实就是属于领域的事件抽取，所以特别适用于第一种方法。

事件推理

就目前来看，事件方向相关的研究还是以事件抽取为主流任务，当前大多都是在模型的框架和优化方面进行研究。同时，事件推理的相关工作有众多领域并且没有一个主流的事件推理方向。近年来，越来越多的工作关注于事件的各个方面的推理，比如

  • 事件因果关系推理 ( Event causality inference )
  • 脚本事件推理 ( Script event prediction )
  • 常识级别事件产生的意图和反应推理 ( common sense level event intent , reaction inference )
  • 周期性事件时间推理 ( recurrent event inference )

这些任务大多都是在已经有抽取到的事件语句（或从知识库中可以得到的事件片段等），挖掘事件在时间维度、顺承或依赖关系维度的特征，从文本或者知识库中获取先验知识来支撑推理。这些事件推理的工作不外乎推理事件之间的相互关系，比如时序关系、因果关系等等。传统的方法都是基于统计的方法，现在的方法也基本都是以神经网络为主。

补漏

NLP这一块由于没有系统学习过，好多名词都看不太懂，在做技术调研的时候特别困难。所以下一阶段的学习任务以CS224n为主，希望能对NLP相关问题能快速地给出解决方案。

总结

人口和时间的劣势是一方面，技术难度也是一方面，评委的专业程度对我们更是致命打击。由于评委对该领域有深入的研究，所以能很快抓住整个系统的瓶颈点，抛出了一个又一个的灵魂拷问：

  1. 怎么处理bad case？
  2. 查找事件的关联新闻时，怎么设置阈值？
  3. 事件中的新闻怎么进行排序？
    ···

我们短时间内脑补的解决方案当然不能让深耕于此的评委满意，不出意外地我都没能给出很有说服力的答案。于是只能以仅仅跑通整个流程来作为我们最简单的目标。
一个人一天的demo和一个真正落地的线上系统有着本质的差异，这是两种完全不同的状态，hackaton可以用很简单粗狂的模式进行开发，但是后者却不可能。感谢这一天时光，让一个迷茫的后端工程师对算法又重燃了兴趣。
在马拉松当天，Keras的作者François Chollet恰巧发了一个推：

90% of the time, when an engineer (or researcher) uses X to solve Y, it’s a case of “I kind of know X” rather than “I have evidence that X is an appropriate solution in this case

大致就是说大部分工程师只是手上有锤子，看见任何类似钉子的东西都想锤一下。假使我们的武器库不够丰富，能做的事情就慢慢出现了局限性。多做，多思考，多总结，要走的路还很长。

Buy Me a Coffee