事件图谱构建初步
2024年4月27日
复现Doc2EDAG
由于一开始没有什么头绪,所以先尝试复现别人的代码。
https://github.com/Spico197/DocEE
download Data.zip from the original repo: https://github.com/dolphin-zs/Doc2EDAG
然后把解压的文件放到DocEE的Data文件夹里。
1 |
|
1 |
|
由于我是在服务器上跑的,如果不想先下载到电脑然后再传上去的话就需要想到一些不用vpn也能链接github和huggingface的方法。
对于github,我采用先导入到gitee,然后再从gitee克隆。
对于huggingface,我使用国内镜像站。
1 |
|
我复现论文中的实验竟然要两天,由于我在此期间已经实现了更简单的方法,所以就先不管这些现有项目了。
GPT对构建事件图谱的一些意见
GPT4的意见:
事件图谱构建方案:
1 |
|
1 |
|
基于大模型的极简事件图谱构建
这不一定是一个好方案,但是实现起来很简单。由于我能力有限,不能在有限的时间内看懂别人的论文并修改他们的代码来用作我们项目的一部分,所以我在想如何快速作出一个简单易行又有成效的方法。
我对构建事件图谱的本质作了一些思考。构建事件图谱像是一个提取、整体有用信息的一个过程,把杂乱的非结构化文本信息转化为结构化的图信息。这个和知识蒸馏的过程有点像,大模型从知识蒸馏中来,本身又具有了知识蒸馏的能力。我就有个大胆的想法: 用大模型一步到位直接构建事件图谱 。
Prompt
经过一番打磨和探索,我得出下面这个可以引导大模型从文章等文本信息中提取事件和实体以及识别其中各种关系的prompt,其输出是 结构化的图信息 ,我们可以用图形库来可视化这些图。
1 |
|
经过在GPT3.5的测试,这个prompt设计得应该还是比较好的。不过发现了一个问题就是通过一篇文章构建的事件图谱已经足够复杂, 如果在很多文章进行构建,还要考虑更多的问题 。这个问题对应到事件图谱构建中大概就是事件共指解析,或者还要涉及到“实体公指解析”。不过也可以看到,直接用****大模型 就解决了事件抽取和事件关系两个最关键的问题 。
事件图谱设计思路
总体分析
上面大模型从文本提取出结构化图信息只是事件图谱的一部分。它的确是能够从一篇文章中构建出一个事件图谱,但是这个并不是我们想要的。这个项目最终要做的是利用事件图谱的技术来实现对舆情信息的分析和把握。
从需求文档出发,先看 事件图谱模块 ,我们要实现 搜索事件,并根据搜索的输入给出对应事件的图谱 。
就单从这个的实现来看,我们有静态预分析和动态生成两种方法。静态预分析是指系统后台自动地将所有的文本转化为结构化的图信息,并且将这些处理好的图信息存储在数据库中,如果有请求则从数据库中检索出相应的信息。动态生成是指只有当遇到请求,才检索出相应的文本再动态地生成事件图谱。当然,这两种方法不是对立的,可以结合到一起,而且有必要结合到一起。可以从下面两个角度看:
把事件图谱模块放到整个系统的需求和设计中看 ,它不但自己形成一个独立模块,而且 它是其他功能实现的重要基础 。其他以事件为单位的功能,多多少少都要事件图谱提供事件信息。所以,静态预分析是必要的。
从事件图谱模块的现实运作来看 ,从所有的数据中进行充分完整的预处理可能是无法实现的(由于算力、存储等限制),在静态预分析的基础上实现某些动态生成是必要的。
Pipeline
Pipeline of Network Hot-spot Detection System
下面的事件图谱pipeline主要是基于以上文档,基于具体实现作了一些调整。
1~2:静态预分析
3:动态生成
- 对于每一篇文章/帖子/新闻等,利用大模型转化为结构化的图信息。
- 对于结构化的图信息,利用embedding计算余弦相似度来实现事件和实体的聚类(事件/实体共指解析),在此基础上 构建高层的事件图和实体图 。
- 用户可以从事件图列表中检索对应的事件,从该事件对应的事件图中提取所有的子图,综合利用这些子图的信息来构建一个事件图谱(TODO,这里有待细化)。
step1具体实现
数据预处理
这里假设已经爬取到了文本信息,实际上文本信息可能有质量高低之差,比如标题的质量比正文的质量要高。但是经过一些考察,这些并没有确定的趋向,因此采用“大一统”的方法可能是最好的,也就是直接把标题和正文拼接起来给大模型处理。
可以直接保留(不用交给大模型)的有效信息大概是爬取的url和发布时间。
此外,爬取的数据并不总是整洁的,所以需要进行一定的清洗,比如对于下面的这种就需要去除掉:
还有需要去除的是和中山大学无关的一些文本。
大模型****处理
将预处理后的文本信息输入给大模型,最终得到结构化的图信息。
prompt:
1 |
|
example:
通义千问的回答:
1 |
|
GPT3.5的回答(这次事件分析有点太细):
1 |
|
图信息存储
我们可以采用图数据库来存储这些图结构的信息,这样可以有更高的可靠性、效率。
从入手难度来看,MongoDB是最容易的(以存储json文档的方式使用)。但是前两个是更专业的图数据库,和知识图谱紧密联系(这可能会带来一些benefit)。
图信息存储 Tugraph
TuGraph是支持大数据量、低延迟查找和快速图分析功能的高效图数据库。
由于TuGraph只支持linux,所以不妨用docker快速部署。
1 |
|
有亿点大。
运行容器:
1 |
|
不知道为啥8000的新ui打不开,只能用lagecy的
图模式设计与prompt改进
模式设计
改进的json格式:
1 |
|
mistral7B的回答:
1 |
|
ChatGPT3.5的回答:
1 |
|
Cypher是neoj4的查询语言,相关文档可以查看:Introduction - Cypher Manual
事件聚类和Embedding
这个非常新鲜热辣的embedding模型。
但是发现效果并不好,然后发现了另外一个向量嵌入模型,感觉在中文的效果甩了mxbai-embed-large几条街。
聚类之后,需要调用大模型得出抽象事件的名称、描述和日期。
事件聚类prompt设计如下:
1 |
|
1 |
|
实体聚类
同样地,实体也需要进行聚类。
1 |
|
图计算分析
根据图模式定义,以及Tugraph图计算平台的支持,可以采用以下策略来进行事件舆情分析:
- 社区发现 :
- 利用社区检测算法识别“实体”和“事件”节点的社区结构。这可以帮助您发现紧密相关的实体群组和事件群组,从而分析哪些实体或事件经常被一起提及,形成热点话题或舆论焦点。
- 中心性分析 :
- 对“事件”、“实体”和“文档”节点应用中心性算法,找出影响力最大的事件、最关键的实体和最具代表性的文档。例如,使用度中心性衡量哪些事件或实体关联最多,使用介数中心性识别信息流通的关键节点。
- 路径与连通性分析 :
- 分析“事件_事件”、“事件_实体”、“实体_实体”边,找出事件间的传播路径和实体间的关系网。这有助于理解舆情的扩散模式和影响路径。
- 短路检测与关键路径分析 :
- 确定信息在不同实体和事件间传播的最短路径,识别信息传播的主要渠道和关键节点,对于快速响应和控制舆情走向至关重要。
- 模式匹配与子图挖掘 :
- 搜索特定的模式,如特定类型的关系链(如“事件-实体-文档”)或者特定的事件-实体组合,这些模式可能对应于典型的舆情演变轨迹或公众反应模式。
- 基于图的 机器学习 :
- 利用“抽象事件”和“抽象实体”的embedding属性,结合图神经网络(GNN)技术,对事件和实体进行更深层次的特征学习,预测舆情发展趋势,进行情感分析或分类。
- 时间序列分析 :
- 结合“文档”节点的时间戳,分析舆情随时间的变化趋势,识别舆情爆发的时间点、持续时间以及衰退模式。
- 来源分析 :
- 通过“来源”边,追踪舆情信息的最初来源和主要传播媒介,评估不同信息源的影响力和可信度。
抽象节点
我们需要根据聚类的结果,将同一个事件指向同一个抽象事件节点,同一个实体指向同一个抽象实体节点。
前端实现
为了减少开发成本,我们决定直接采用tugraph自带的开源前端tugraph-web。在我们自己的网站进行相关操作的时候自动跳转到tugraph并执行相关语句。