add docs
This commit is contained in:
loujie0822
parent
03d1f9576a
commit
c53f501057
18
README.md
18
README.md
@ -26,12 +26,10 @@ $ cd DeepIE
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 主要算法介绍
|
||||
|
||||
- 实体抽取/事件段落抽取/事件主体抽取
|
||||
- 实体识别。以面向中文电子病历的医疗识别为例，主要做法有
|
||||
-
|
||||
- 实体链接
|
||||
-
|
||||
- 关系抽取
|
||||
@ -53,10 +51,18 @@ $ cd DeepIE
|
||||
|
||||
|
||||
|
||||
## TODO计划
|
||||
## TODO任务排期
|
||||
|
||||
| 日期 | 任务 | 完成情况 |
|
||||
| ----------- | --------------------------- | -------- |
|
||||
| 1月7日-10日 | 基本框架设计 | |
|
||||
| 1月9日 | 实体/事件抽取技术总结1 | |
|
||||
| 1月10日 | 实体/实体-关系抽取codes开发 | |
|
||||
| 1月10日 | | |
|
||||
|
||||
|
||||
|
||||
|
||||
- [ ] 1月7日-10日，基本框架设计
|
||||
- [ ] 1月7日-10日，add 实体抽取/实体-关系联合抽取代码
|
||||
|
||||
## 开发要点
|
||||
|
||||
|
||||
@ -1,9 +1,29 @@
|
||||
# 事件抽取技术总结
|
||||
|
||||
事件抽取任务定义
|
||||
### 1. 事件抽取任务定义
|
||||
|
||||
不同于目标明确、结构简单的实体识别和关系分类，事件抽取是一件更加复杂的任务。事件之间的差异性使得在开放域中进行任意事件的抽取一个极具挑战性的难题。本文重点关注特定领域的事件抽取任务。
|
||||
|
||||
事件抽取的主要任务就是在已知「事件类型」的前提下，从句中抽取事件的各个元素，并判别「事件元素」的角色。
|
||||
事件抽取的主要任务就是在**已知「事件类型」的前提下，从句中抽取事件的各个元素（论元），并判别事件元素的角色（论元角色）**。事件抽取的子任务包括（以ACE2005中采用的事件标注标准为例）：
|
||||
|
||||
- 识别
|
||||
- **触发词识别**：即识别事件类型。触发词能够清晰表明某类事件的发生，例如“出生”、“离职”等。
|
||||
- **事件元素抽取与角色分类**：事件元素的角色通常由两部分组成：事件参与者和事件属性。事件参与者是事件的必要部分，通常是命名实体的人名和组织机构名。事件属性包括通用事件属性和事件相关属性。
|
||||
- **事件整体特性**：除了事件类型和事件元素之外，事件的整体特性也经常被作为信息抽取的对象。例如：极性（正面/负面）、语态（确定/未知）、泛型（具体/普遍）、时态（过去/现在/将来/未知）。
|
||||
|
||||
|
||||
|
||||
### 2.事件抽取方法
|
||||
|
||||
#### 2.1 管道式的抽取方法
|
||||
|
||||
- 事件类型识别（触发词识别）：超过95%的触发词都是单个词，可转化为词的分类问题。但由于大部分词都不是触发词，因此会面临严重的数据不平衡。为了缓解这一问题，可以采用两步策略：1）训练一个2分类分类器，过滤掉非触发词；2）训练一个多类别分类器，判断触发词属于哪一事件类型。
|
||||
- 事件元素抽取与角色分类：通常假定候选实体给定，需要对每一个候选实体进行角色分类，由于大量实体不属于任何角色，应注意数据不平衡问题；除了形式化为36类的多分类问题外，可以根据具体的事件类型进行多分类建模。
|
||||
|
||||
#### 2.2 联合事件的抽取方法
|
||||
|
||||
- 结构感知器：TODO补充
|
||||
- 构建DAG依存路径
|
||||
|
||||
实体链接
|
||||
|
||||
http://pelhans.com/2019/12/29/recall/
|
||||
@ -36,11 +36,22 @@
|
||||
|
||||
3. 事件段落抽取
|
||||
|
||||
-
|
||||
|
||||
|
||||
|
||||
-
|
||||
- 自上向下：先抽取事件段落，从相应的事件段落抽取事件实体和关系
|
||||
- 优点：
|
||||
- 模式集中，利于学习。同一类别的事件段落模式集中、相对集中，利于学习。
|
||||
- 简化问题，避免冗余计算。同一类别实体提及可能会存在不同的事件中，先抽取对应的事件段落可以缓解实体冗余的问题。例如，病灶位置存在不同的事件段落中，只做影像事件的病灶关系抽取时需要遍历所有的病灶位置，而采取上述方法，可以避免冗余计算。
|
||||
- 一定程度上缓解了类别不平衡问题。例如，某些label实体在长文本分布中不平衡，从较短文本的事件段落中抽取该label实体时可缓解不平衡问题。
|
||||
- 可回溯、可解释。子任务抽取实体，可以回溯到上级的事件段落，具备可解释性。
|
||||
- 易于维护、迭代。label事件/实体之间解耦，易于单独维护。
|
||||
- 缺点：
|
||||
- 适合于父子关系清晰的场景，可能会丢失兄弟关系。
|
||||
- 级联任务，误差积累，后续模块不能影响前续模块的决策过程。
|
||||
- 自下而上：先抽取事件主体，再进行关系抽取事件属性，最终组合group构建一个“事件”。⚠️：1）这里区别于传统的事件抽取，不过可将事件主体看作触发词，同时将事件属性看作事件元素。2）这里不去对比传统的实体-关系抽取做法，即先抽取实体再进行关系识别，因为这种做法计算冗余。3）这里考虑Joint方式。
|
||||
- 优点：
|
||||
- 直接构建事件抽取逻辑，天然考虑兄弟关系。
|
||||
- 丢弃多实体维度抽取的方式，转化为事件主体-属性抽取，最大程度避免实体抽取对下游关系误差传播，同时避免实体对之间的冗余计算。
|
||||
- 将级联任务转化为Joint方式进行学习 ，后续模块可以影响前续模块的决策过程。
|
||||
-
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user