"pred_results"中的classification得分

[BudBudding]

Problem

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

[Spico197]

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

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

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

[BudBudding]

好的好的 十分感谢您的回复！！！针对现有的工作，我想在上面的基础上引入额外的信息，例如新闻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]

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

[BudBudding]

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

[Spico197]

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

[BudBudding]

嗨您好，这个是测试集结果的。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"进行注释？

[Spico197]

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

[BudBudding]

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

[Spico197]

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

[BudBudding]

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

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

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

[Spico197]

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

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

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

[WindSearcher]

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

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

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

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

[Spico197]

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

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

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

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

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

[WindSearcher]

应该

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

[BudBudding]

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

[WindSearcher]

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

原始实体怎么说

[BudBudding]

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

原始实体怎么说

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

[WindSearcher]

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

[BudBudding]

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

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

[WindSearcher]

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

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

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

[BudBudding]

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

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

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

蒸馏UIE？加油加油 引入新的方法！

[WindSearcher]

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

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

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

蒸馏UIE？加油加油 引入新的方法！

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

[Spico197]

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

[WindSearcher]

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

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

[WindSearcher]

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

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

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

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