[RFC]: Issues in Token Classificaiton Task

[wj-Mcat]

Abstract

Token Classification任务本质上是一个序列标注的任务，主要是给文本中的token打上不同的标签。可是不同的分词工具对文本的词切分情况不一致，其中就包括将一个词切成多个subword的情况，例如："2019" -> ["20", "##19"]，此时2019对应的标签B/I/O需要如何变化？在解码器（如CRF）中是否需要计算["20", "##19"]两个token的损失？还是只需要计算第一个？这个RFC我们就来讨论讨论这些问题。

Problem

在Token Classification的任务当中，tokens和labels的长度必须是一致的，可是存在一些情况会导致其不一致：

当数据集中已经给出tokens和labels的数据，如tokens=["I", "love", "\xa0", "chinaaaaa"] , labels = ["O", "O", "O", "B"]
当token经过tokenizer之后，由于\0ax会变成空字符串，chinaaaaa会变成china, ##a, ##a, ##a, ##a等token，这个时候就会出现问题.

在以上例子当中，总结而言有三个问题：

• tokens中有脏数据，比如说\xa0（空格字符）在经过tokenizer之后会判定为空哥被删掉。
• tokens中有sub-tokens的情况，此时总长度可能会增加，此时原始token对应的标签该如何变化。例如："chinaaaaa"对应的标签是"B-country"，那经过分词之后的china, ##a, ##a, ##a, ##a等token的标签应该对应成什么？
• 如果sub-tokens数量过多，在计算loss时，对应标签（B-country）的权重可能会变大（如果都##a对应标签也是B-country），此时会影响模型的效果，此时该如何解决呢？

Solution

针对于以上面临的三个问题，在此我给出以下解决方案，在座的小伙伴们也可以一起来贡献出自己的思考。

问题一：无效字符被删除

最简单的做法就是无视，直接删掉即可。可是在实际的项目当中，有时候需要将结果对齐原始文本中的字符，此时如果删掉了token在计算上而言会比较麻烦。不过也是可以通过offset mapping来解决。所以，优点是简单粗暴，缺点是后处理麻烦。

保守一点的做法就是保留。可是这类的特殊字符如果仍然保留需要被处理成来处理，所以在文本语义上的计算会造成一定的干扰，最后导致文本的预测效果不太好。优点是：后处理稍微简单点，缺点是容易影响语义计算。

针对于此问题，我个人的看法是支持第一个方法。

问题二：sub-tokens的标签重复规则

由于解码阶段有不同的解码策略，如BIO、BIOSE、IOB、BILOU、BMEWO、BMEWO等，是不是眼花缭乱。那针对于不同的解码策略可能需要处理的方法不一样。

最简单粗暴的方法就是：直接将sub-tokens的标签重复n-1次。然后在计算标签损失的时候，将这些重复的标签给忽略掉，所以需要有一个logit mask的向量。

问题三：重复的标签计算

就像在上面提到的，重复的标签只需要使用logit-mask来忽略对应的计算即可，当然这种方法也是借鉴huggingface transformer的处理方法。

References

• Token Classification with W-NUT Emerging Entities
• Token classification

---

欢迎各位参与到此讨论当中来。

[ZeyuChen]

和huggingface的策略保持一致的话有没有什么不足呢？

[wj-Mcat]

在框架层面不需要做调整，因为交叉熵损失函数中本身包含ignore_index参数，只需要在数据预处理的时候设置一下就行了。如

在huggingface当中，china, ##a, ##a, ##a, ##a 标签对应的label-id是[3（B-Country）, -100, -100, -100, -100]，在标签最后计算时，-100对应的label会直接被忽略掉。

所以，我认为需要调整的地方为：

1. 调整部分数据集预处理的方式，以处理tokens数量变长以及sub-tokens label的问题，比如：cote数据集。
2. 参考HuggingFace文档在paddlenlp文档中添加针对于此类情况的数据预处理解决方案和代码脚本。

[ZeyuChen]

所以可以直接用hf的策略 也就是你的第三个方案是吧？

[wj-Mcat]

嗯嗯，是可以的。