你好!我遇到了一个词义消歧问题,CoreNLP似乎在处理与不同单词共享表面形式的副词时存在困难。例如,“number”(如“数字五”)和“number”(如“他的右侧比左侧更疼”)。在这两个句子中,CoreNLP将标记为名词的“number”解释为“number”(NN);在第二个句子中,它应该将其标记为形容词“numb”(RBR)的副词形式。词形还原器也将“number”/RBRMap到“number”,而不是“numb”,这似乎是问题的一部分。当然,由于错误的标签被分配,任何下游注解也是错误的(依赖关系等)。
我已经尝试了不同的句法结构,但尚未成功找到一种使CoreNLP将“number”标记为RBR而不是NN的表述。
显然,标注器本质上是一个统计模型,它会按照自己的方式进行标注,但另一方面,这个词并不特别奇怪,也没有语法上的歧义,所以我想看看是否有其他人遇到过类似的问题,或者我是否可以采取措施改变标注器的行为。提前感谢您能提供的任何见解!
8条答案
按热度按时间wyyhbhjk1#
我想对
number_RBR
是一个常见用法的观点进行一些反驳。在我们训练数据中,number
有 1053 个用法,其中 1052 个是number_NN
,最后一个是Revolution Number_NNP 9
,我相信根据最新的标注指南,它也应该是nn
。此外,它应该是JJR
,而不是RBR
,对吧?在你的例子中,他右边的numb_JJ
显然是一个形容词。很难想出有意义的例子。然而,在上班路上,我想出了几个。如果我们把这些添加到训练数据中,模型可能会注意到
number
有时是一个形容词......但它将淹没在超过 1000 个名词的例子中,所以我不确定这会有多大区别。对于这些的提议解析:
i5desfxk2#
您好!CoreNLP lemmatizer 已经正确处理了
number_JJR
。uz75evzq3#
首先,非常感谢您快速而周到的回复!
其次,我认为您完全正确,应该是JRJ而不是RBR(这是我的错误,道歉),这确实在训练数据中的统计分布方面有很大的差异,所以我不奇怪标注器会挣扎。然而,出于某种原因,我从您那里看到了不同的行为。例如,在corenlp.run上,它绝对不是将事物标记为JRJ并将其词形还原为“数字”:
在本地运行时,我也得到了相同的结果。
gdrx4gfi4#
哦,我不太清楚。目前除了NN标签之外,它不会标记任何其他标签,因为绝大多数训练样本都是这个标签。我们可以添加一些带有JRJ标签的示例,重新训练模型(这可能需要一段时间),然后也许它会使用那个标签。不过,考虑到有多少NN示例,我对此并不是非常有信心。
8iwquhpp5#
我明白了,谢谢你的澄清。这些建议的解析对我来说看起来不错;我同意它不太可能克服数据中这种程度的词义不平衡,但为词性标注器包含一些额外的例子肯定不会有什么坏处。
c0vxltue6#
哦,而且,现在我被你的评论"also, as a followup, the CoreNLP lemmatizer already properly handles number_JJR"弄糊涂了-据我所知,它肯定没有处理这种情况,而是将其词形还原为"number_NN"。
r9f1avp57#
此外,作为后续,CoreNLP词形还原器已经正确处理了number_JJR。
如果偶然给你的词形还原器
number
加上标签JJR
,它会返回词形numb
。我曾在上面的提交中使用它将这些树转换为UD表示,例如。kuuvgm7e8#
啊哈!现在我明白了,谢谢。所以如果给定了"正确的"PoS标签,词形还原器就知道该怎么处理它了。这很好了解!...
-SB
2023年8月1日 下午3:33 John Bauer @***.***>写道:此外,作为后续行动,CoreNLP词形还原器已经正确地处理了number_JJR。如果你偶然给词形还原器一个带有JJR标签的数字,它会返回lemma number。我用它将这些树转换为上面提交中的UD表示,例如。***@***. < stanfordnlp/handparsed-treebank@c1a405b > — 直接回复此电子邮件,查看GitHub上的评论<#1381 (comment)>,或取消订阅 < https://github.com/notifications/unsubscribe-auth/AAAMVHLP3PYKNLSDXK7G5E3XTF74HANCNFSM6AAAAAA3AC7WJ4 > 。您收到此邮件是因为您是该主题的作者。消息ID:***@***.***>