上一篇文章我们探讨了如何使用大语言模型进行实体关系的抽取。本篇文章我们将进一步探索这个话题。比较一下国内外几款知名大模型在相同的实体关系提取任务下的表现。由于精力有限,我们无法全面测试各模型的实体关系抽取能力,因此,看到的效果以及分析的结论,也仅限于在该任务下的探讨,不能作为各大模型在该方面能力的结论。这次我们选中用于实验的大模型如下:
国外:ChatGPT3.5(OpenAI)、Bard(Google)、Llama2-13B(Facebook)
国内:文心一言(百度)、通义千问(阿里)、混元(腾讯)
为了避免出现在第一篇文章中的现象,即GPT 3.5(Old)模型在回答问题时,超过了我的提示预期,给我带来了巨大的惊喜,所以这次我调整了大语言模型的“提示”信息,在信息中明确加入了对“账号平台”的抽取,如下:
请帮我抽取“####”后内容中的黑客组织及其账号与账号平台,并输出为json格式
####
ATW 组织发布的“ATW-对华战争”帖
2021 年 10 月,ATW 组织开始频繁活动,不断在电报群组(https://t.me/s/ATW2022,Email:[email protected],备份 Email:[email protected])、推特(@_AgainstTheWest,https://mobile.twitter.com/_AgainstTheWest)、Breadched(账号:AgainstTheWest)等境外社交平台开设新账号,扩大宣传途径,并表现出较明显的亲美西方政治倾向,多次声明“攻击目标是俄罗斯、白俄罗斯和中国、伊朗、朝鲜”、“愿意与美国、欧盟政府共享所有文件”、“愿受雇于相关机构”。
后续实验中,输入给所有大语言模型的“提示”全部一致,即都是上面的这段信息内容。
{
"黑客组织": "ATW 组织",
"账号信息": [{
"平台": "电报群组",
"链接": "https://t.me/s/ATW2022"
},{
"平台": "电子邮件",
"地址": "[email protected]"
},{
"平台": "备份电子邮件",
"地址": "[email protected]"
},{
"平台": "推特",
"账号": "@_AgainstTheWest",
"链接": "https://mobile.twitter.com/_AgainstTheWest"
},{
"平台": "Breadched",
"账号": "AgainstTheWest"
}]
}
从上面的输出可以看到,与本系列前一篇文章中GPT3.5的输出内容一致。完整的按照我们的提示抽取出了黑客组织、账号平台以及账号信息。并且为抽取出的账号信息,做了更明确的定义。如:“[email protected]”被理解为“地址”;“ https://t.me/s/ATW2022”被理解为链接。笔者在设定黑客组织的账号模型时,认为域名、电话、邮箱、应用账号等都可被视为账号。因为这些信息在不同的应用场景下,都的确代表了一种身份。所以ChatGPT给出的答案笔者是很认同的。
我们进一步分析其识别能力,有两个细节需要注意。一个是其将“电报群组(Telegram)”的相关账号信息拆解成了三个平台;另一个是其为“推特”平台识别出了两个账号。在仔细体会了ChatGPT的输出后,笔者觉得在初次处理这组数据时,笔者可能更倾向于将电报群组账号,邮件账号以及备份邮件账号写成类似“推特”的样子,就是一个账号平台下有三个账号。估计这样的数据组织方式也会是相当一部分工程师的选择。但是认真考虑ChatGPT的答案,你会发现它的分法非常合理。因为邮件地址一定是一类特殊账号,其本质是有别于“电报群组”账号的,所以为邮件地址单独定义账号平台是更合理的选择。至于文本中邮件地址出现在“电报群组”相关上下文的位置,笔者则认为更多是为了表达这些邮箱地址是通过“电报群组”的账号关联获得的。另外,ChatGPT抽取了“推特”中的url信息,相信有相当一部分工程师,在接受到我们输入给ChatGPT同样的需求时,是不会将url提取出来作为账号信息的。但是仔细分析输入文本,我们认为ChatGPT将url识别为一种账号是合理的。
ChatGPT的答案也并非无懈可击。由于其对账号做了更精准的描述,其Json格式以账号分类作为字段名,在我们没有掌握ChatGPT的全账号分类前,我们无法使用通过固定字段名获取账号的方式,只能通过遍历Json对象的方式来解析获取各类账号。数据解析的复杂度比通过固定字段名称访问要大一些。但整体而言,ChatGPT提供的识别能力相较与其带来的处理复杂度,是可完全被接受的。
鉴于ChatGPT给出的出色回答。我们将在后续大模型的答案分析中,以此的作为比较的基础。
{
"组织": "ATW",
"账号": [{
"平台": "电报",
"账号": "https://t.me/s/ATW2022"
},{
"平台": "电子邮件",
"账号": "[email protected]"
},{
"平台": "电子邮件",
"账号": "[email protected]"
},{
"平台": "推特",
"账号": "@_AgainstTheWest"
},{
"平台": "Breadched",
"账号": "AgainstTheWest"
}]
}
从Bard的结果看,其与ChatGPT的输出非常接近。更好的一处结果是,其将两个邮件地址的账号平台统一成了“电子邮件”。一处明显的不足是,其没有抽取出推特的url。一处中性的变化是,其所有的账号类信息的字段名,都是“账号”,这更有利于后续的解析处理,但账号的类型识别又需要处理时采用类似模式识别来解决了。
{
"organization": "ATW",
"accounts": [{
"name": "AgainstTheWest",
"platform": "Telegram",
"url": "https://t.me/s/ATW2022",
"email": "[email protected]",
"backup_email": "[email protected]"
},{
"name": "@_AgainstTheWest",
"platform": "Twitter",
"url": "https://mobile.twitter.com/_AgainstTheWest"
}],
"platforms": [
"Telegram",
"Twitter"
]
}
如果我们没有看到过上面两个例子。第一次看到Llama2的结果,还是会认为数据组织的结构是不错的。除了少识别了一个账号平台外,其它信息基本都按要求识别出来了。但有了上面两个先入为主的例子,我们会认为其答案的条例性相对弱一些,没有帮助我们提升数据组织的认知。再有,其输出全部为英文,没有中文。正确的将“电报群组”翻译为了“Telegram”。
{
"黑客组织": "ATW",
"账号平台": [{
"平台名称": "电报群组",
"账号信息": [{
"账号": "ATW2022",
"链接": "https://t.me/s/ATW2022"
},{
"账号": "[email protected]",
"链接": "Email:[email protected]"
},{
"账号": "[email protected]",
"链接": "备份 Email:[email protected]"
}]
},{
"平台名称": "推特",
"账号信息": [{
"账号": "@_AgainstTheWest",
"链接": "https://mobile.twitter.com/_AgainstTheWest"
}]
},{
"平台名称": "Breadched",
"账号信息": {
"账号": "AgainstTheWest",
"链接": "账号:AgainstTheWest"
}}]
}
文心一言的回答整体结构与Llama2相似,但是它没有漏掉任何信息,所有信息都识别到了。甚至感觉其对自己的输出做了强制对齐,它为每一个账号信息数据都加入了一个以“链接”命名的字段,用于存放链接账号。只是这个信息对齐略显生硬。
{
"黑客组织": {
"名称": "ATW 组织",
"政治倾向": "亲美西方"
},
"电报群组": [
"https://t.me/s/ATW2022"
],
"电子邮件": [
],
"推特": [
"@_AgainstTheWest",
"https://mobile.twitter.com/_AgainstTheWest"
],
"Breadched": [
"AgainstTheWest"
]
}
通义千问的回答中多了一个“政治倾向”的信息输出,这个信息是我们在提问时没有要求的。从答案看,通义千问各要素的提取以及账号平台的划分与ChatGPT、Bard一致。但是与ChatGPT相比,其账号没有进一步的分类,这使得如果需要更细致的处理账号,需要后续通过处理程序进行模式识别来解决。需要额外提到的是,通义千问的Json结构是最简练的。
{
"黑客组织": "ATW",
"账号平台": [
"电报群组",
"推特",
"Breadched"
],
"账号": [
"AgainstTheWest@Breadched"
],
"宣传倾向": "亲美西方政治"
}
以上答案不是通过混元模型的试用界面获得的,当输入测试的提示时,混元会直接告诉你它不支持这种任务。最后,笔者是通过调用混元模型的API接口获得的实验结果。从输出结果上看,其采用了一种更笼统的数据组织方式。最大的问题是[email protected]这个账号信息并不存在,是它的一种幻觉。
一个花絮是,腾讯的售后在笔者申请试用混元后,回访笔者希望用混元的什么能力。笔者回答希望试用它的实体关系识别能力。对方明确对笔者说到,目前混元在这部分能力比较弱。这次强拉“混元”上台,主要还是因为在国内进行比较,“BAT”少了谁家都不太合适。目前的测试情况的确如售后所言,“混元”目前不太支持这个类型的任务,期待“混元”后续的版本迎头赶上吧。
从我们实验的效果看,除混元、Llama2外,其它四个大语言模型基本都能够识别出我们所要求的信息。输出格式的差异可以通过后续的处理程序对齐。信息抽取的有效性让我们充分看到了大语言模型在实体关系抽取这类作业上能力。它将为我们打通一些我们之前无法企及的应用效果的道路。