Spico197 / DocEE

🕹️ A toolkit for document-level event extraction, containing some SOTA model implementations.
https://doc-ee.readthedocs.io/
MIT License
232 stars 36 forks source link

"pred_results"中的classification得分 #74

Closed BudBudding closed 9 months ago

BudBudding commented 10 months ago

Problem

您好,我想问一下 根据脚本run_ptpcg_dueefin.sh跑出来生成的结果 是验证的结果 还是测试的结果哇,我注意到在log里面 他们是相同的。在生成结果json文件里面, image 这里的"classification"能看作是事件类型检测的得分吗?"overall"是论元的的分?

Spico197 commented 10 months ago

嗨您好,这个是测试集结果的。pred_results表示最终的结果,gold_results表示金标实体的预测结果。

您这里看的o2o指单事件单实例的docs下的评测指标。classification是事件检测(分类)结果,overall表示最终的论元评测结果(汇报在论文里的都是这个)。

如果想看验证集结果,还是得到任务的输出文件夹下,有个Output目录,里面有每个epoch结束后评价的dev和test结果。

BudBudding commented 10 months ago

好的好的 十分感谢您的回复!!!针对现有的工作,我想在上面的基础上引入额外的信息,例如新闻time、title之类的,如果加进去的话,好像生成式的事件抽取比抽取式的事件抽取更加适合。在代码里面: def get_event_decode_result_on_batch( self, doc_batch_dict, features=None, use_gold_span=False, heuristic_type=None ): if features is None: raise Exception("Features mush be provided")

    if heuristic_type is None:
        event_idx2entity_idx2field_idx = None
    else:
        # this mapping is used to get span candidates for each event field
        event_idx2entity_idx2field_idx = self.get_event_idx2entity_idx2field_idx()

    batch_eval_results = self.model(
        doc_batch_dict,
        features,
        use_gold_span=use_gold_span,
        train_flag=False,
        event_idx2entity_idx2field_idx=event_idx2entity_idx2field_idx,
        heuristic_type=heuristic_type,
    )

    return batch_eval_results  感觉比较偏向利用id确定实体,更加偏向抽取式事件抽取?关于这个问题,请问您之前有尝试过吗?添加额外的信息来辅助事件抽取或者类似于限制性生成之类的?
Spico197 commented 10 months ago

没有诶,一般来说时间项会作为事件实例中的一个要素,title会直接当做事件文本的一部分。如果这部分对您的业务比较重要的话,您也可以尝试抽取之后单独使用GNN进行建模。生成式的方案在篇章事件抽取上效果不太好,不过因为资源有限,我没尝试更大(比如7B+)的模型,不确定大模型上生成式方案会不会有什么明显的优势。

BudBudding commented 10 months ago

感谢您的回复!您的意思是 我可以利用编码器对我需要的额外信息进行编码后,在GNN解码之前,先进行融合,再统一利用GNN进行建模输出吗?

Spico197 commented 10 months ago

类似GIT的做法,GNN是一个比较容易想到的思路。不过结合时间和标题应该会有其它更多的方案。可能GNN也不一定有效,还是需要您结合实际场景探索。

BudBudding commented 10 months ago

嗨您好,这个是测试集结果的。pred_results表示最终的结果,gold_results表示金标实体的预测结果。

您这里看的o2o指单事件单实例的docs下的评测指标。classification是事件检测(分类)结果,overall表示最终的论元评测结果(汇报在论文里的都是这个)。

如果想看验证集结果,还是得到任务的输出文件夹下,有个Output目录,里面有每个epoch结束后评价的dev和test结果。

您好,我在output里面查看了dev和test的结果,发现两个json文件里面的得分全部都一样,考虑到会不会是因为duee-fin它本身测试集是没有GT的哇?如果,我现在测试集标记了GT,是不是需要将Data/DuEEDate build_data.py里面的"inference=True"进行注释? image

Spico197 commented 10 months ago

嗨您好,抱歉是我没有解释清楚。DuEE-fin的测试集结果是需要提交到线上评测系统之后才能看到的。线下的dev和test其实都是dev(默认设置测试集文件位置就是开发集文件位置)。如果线下有标注测试集,那么保证它和开发集的格式相同,再使用开发集的build方法就可以了。

BudBudding commented 10 months ago

那 就是按照 上面说的,格式一样的话,将将Data/DuEEDate build_data.py里面关于test的"inference=True"进行注释,然后再利用脚本跑一遍,出来的就是test结果吗

Spico197 commented 10 months ago

嗯啊是的。如果想要提交到线上平台看结果的话,我们也提供了相关的处理脚本,可以在README里看看。

BudBudding commented 10 months ago

类似GIT的做法,GNN是一个比较容易想到的思路。不过结合时间和标题应该会有其它更多的方案。可能GNN也不一定有效,还是需要您结合实际场景探索。

哈哈,是的,我发现在实体点乘前给实体融合各种特征,会让整体的效果降下来。感觉只有在点乘之后去加特征,毕竟角色分类还是存在一些问题的。

实体点乘的时候,不是已经到构建图的时候嘛?如果 不在前面 融合其他特征的话,等图构建出来了,那岂不是 很难再融特征进去了哇

Spico197 commented 10 months ago

类似GIT的做法,GNN是一个比较容易想到的思路。不过结合时间和标题应该会有其它更多的方案。可能GNN也不一定有效,还是需要您结合实际场景探索。

哈哈,是的,我发现在实体点乘前给实体融合各种特征,会让整体的效果降下来。感觉只有在点乘之后去加特征,毕竟角色分类还是存在一些问题的。

这个结论有意思,直觉上点乘之前融特征应该会对构图有帮助。可能在点乘之前需要再经过lstm之类的编码器在实体层面把特征融一下。

WindSearcher commented 10 months ago

类似GIT的做法,GNN是一个比较容易想到的思路。不过结合时间和标题应该会有其它更多的方案。可能GNN也不一定有效,还是需要您结合实际场景探索。

哈哈,是的,我发现在实体点乘前给实体融合各种特征,会让整体的效果降下来。感觉只有在点乘之后去加特征,毕竟角色分类还是存在一些问题的。

这个结论有意思,直觉上点乘之前融特征应该会对构图有帮助。可能在点乘之前需要再经过lstm之类的编码器在实体层面把特征融一下。

不保证我的代码有没有问题呢,不过点乘前原本就已经经过了lstm编码,不知道大佬之前加这个的目的是啥勒

Spico197 commented 10 months ago

类似GIT的做法,GNN是一个比较容易想到的思路。不过结合时间和标题应该会有其它更多的方案。可能GNN也不一定有效,还是需要您结合实际场景探索。

哈哈,是的,我发现在实体点乘前给实体融合各种特征,会让整体的效果降下来。感觉只有在点乘之后去加特征,毕竟角色分类还是存在一些问题的。

这个结论有意思,直觉上点乘之前融特征应该会对构图有帮助。可能在点乘之前需要再经过lstm之类的编码器在实体层面把特征融一下。

不保证我的代码有没有问题呢,不过点乘前原本就已经经过了lstm编码,不知道大佬之前加这个的目的是啥勒

其实就是做个融合,我发现这样的效果会更好一点,可以在论文里找到关于 EntLSTM 的消融实验。

image

WindSearcher commented 10 months ago

应该

嗷嗷,感觉只有点乘后加了。对实体做lstm感觉给这些实体加上了序列关系(相互之间有依赖)

BudBudding commented 10 months ago

请问 大佬们,有没有尝试过在实体点乘时候,将最原始的实体加进去 一起点乘?因为我发现,PTPCG它的recall偏低,会不会是由于一些论元当做了触发词,导致原论元识别出错

WindSearcher commented 10 months ago

请问 大佬们,有没有尝试过在实体点乘时候,将最原始的实体加进去 一起点乘?因为我发现,PTPCG它的recall偏低,会不会是由于一些论元当做了触发词,导致原论元识别出错

原始实体怎么说

BudBudding commented 10 months ago

请问 大佬们,有没有尝试过在实体点乘时候,将最原始的实体加进去 一起点乘?因为我发现,PTPCG它的recall偏低,会不会是由于一些论元当做了触发词,导致原论元识别出错

原始实体怎么说

就是还没将实体,分成论元角色? 我也不知道 这样可不可行

WindSearcher commented 10 months ago

其实,我还在考虑知识蒸馏,目前这块的任务挺费资源的,但好像事件抽取这块没有知识蒸馏的论文。估计只能从基于feature的知识蒸馏入手。不知道大佬觉得可行否。

BudBudding commented 10 months ago

其实,我还在考虑知识蒸馏,目前这块的任务挺费资源的,但好像事件抽取这块没有知识蒸馏的论文。估计只能从基于feature的知识蒸馏入手。不知道大佬觉得可行否。

感觉现在类型判断是分类任务,论元是抽取任务。蒸馏的话,感觉现在好像没有那么大的事件抽取教师模型吧?

WindSearcher commented 10 months ago

其实,我还在考虑知识蒸馏,目前这块的任务挺费资源的,但好像事件抽取这块没有知识蒸馏的论文。估计只能从基于feature的知识蒸馏入手。不知道大佬觉得可行否。

感觉现在类型判断是分类任务,论元是抽取任务。蒸馏的话,感觉现在好像没有那么大的事件抽取教师模型吧?

把整体的几个任务一起蒸馏,现在这块的方法显存占用还是挺大的,训练也慢

BudBudding commented 10 months ago

其实,我还在考虑知识蒸馏,目前这块的任务挺费资源的,但好像事件抽取这块没有知识蒸馏的论文。估计只能从基于feature的知识蒸馏入手。不知道大佬觉得可行否。

感觉现在类型判断是分类任务,论元是抽取任务。蒸馏的话,感觉现在好像没有那么大的事件抽取教师模型吧?

把整体的几个任务一起蒸馏,现在这块的方法显存占用还是挺大的,训练也慢

蒸馏UIE?加油加油 引入新的方法!

WindSearcher commented 10 months ago

其实,我还在考虑知识蒸馏,目前这块的任务挺费资源的,但好像事件抽取这块没有知识蒸馏的论文。估计只能从基于feature的知识蒸馏入手。不知道大佬觉得可行否。

感觉现在类型判断是分类任务,论元是抽取任务。蒸馏的话,感觉现在好像没有那么大的事件抽取教师模型吧?

把整体的几个任务一起蒸馏,现在这块的方法显存占用还是挺大的,训练也慢

蒸馏UIE?加油加油 引入新的方法!

想法而已,能不能行还不一定

Spico197 commented 10 months ago

知识蒸馏的话,可以考虑把所有的任务统一一下,然后做成类似UIE那种Schema-Guided的范式,这样就可以用其它数据集训练得到教师模型了。

WindSearcher commented 10 months ago

知识蒸馏的话,可以考虑把所有的任务统一一下,然后做成类似UIE那种Schema-Guided的范式,这样就可以用其它数据集训练得到教师模型了。

其实基于伪标签也可以蒸馏,毕竟未标注的数据很多,再加上一些样本选择策略

WindSearcher commented 10 months ago

类似GIT的做法,GNN是一个比较容易想到的思路。不过结合时间和标题应该会有其它更多的方案。可能GNN也不一定有效,还是需要您结合实际场景探索。

哈哈,是的,我发现在实体点乘前给实体融合各种特征,会让整体的效果降下来。感觉只有在点乘之后去加特征,毕竟角色分类还是存在一些问题的。

这个结论有意思,直觉上点乘之前融特征应该会对构图有帮助。可能在点乘之前需要再经过lstm之类的编码器在实体层面把特征融一下。

点乘之前融特征是有用的,只不过需要注意一些操作