谁是真凶?《CSI:犯罪现场调查》正帮助AI提高断案能力

问耕 编译整理
量子位 出品 | 公众号 QbitAI

曾经的王牌美剧《CSI:犯罪现场调查》,现在成了AI用来提高断案推理能力的试验场。

这部剧集厉不厉害?据说已成为美国警方的必备学习教材,连英国苏格兰场、日本警卫厅以及法国警局都视之为反恐教材。

爱丁堡大学的一个研究团队,把《CSI:犯罪现场调查》剧集脚本变成自然语言的训练数据集,输入一个LSTM模型。他们的目标是帮助机器更好的进行自然语言理解,以及训练与之相关的复杂推理能力。

之所以选定这部剧集,原因很简单。《CSI:犯罪现场调查》有着严格的公式化剧本,完全可以被预测。

“每一集都提出了同样的基本问题(即谁是凶手),而罪犯被抓住时自然就给出了答案”,研究人员表示。剧集中的调查人员会对犯罪现场进行研究,找到无可辩驳的证据,抽丝剥茧的把真凶揭露出来。

所以,“谁是真凶”就变成了一个简单的序列标签问题。

研究人员假设这个AI模型和人类一样,从剧集中获得一系列的信息输入,包括文本、视频或者音频,并能据此推测凶手。

结果表现

AI真的可以找到凶手么?

《CSI:犯罪现场调查》数据集上的实验表明,多模态表示对于自然语言理解非常重要。另外,增量推理策略是准确找到真凶的关键。

研究人员希望模型的预测能力,最终可以超越人类。

上图是目前这套系统的评估表现。人类的平均预测精度接近85%,而AI的准确率超过60%。这是一个让研究人员欢欣鼓舞的成绩。

不过作为对比的人类样本还很小(只有三个)。另外与LSTM模型相比,人类的预测精度更高,但通常更为谨慎。AI看剧本会在大约第190句话时猜测真凶,而人类通常在第300句话时才第一次作出判断。

目前还有一些情景,会让AI有点摸不清头脑。例如在数据集中包括一些自杀案件,对这类情况AI还不能很好的处理。与之相比,在三分之二的情况下,人类最终能够意识到案件其实没有其他凶手参与。

研究人员会继续研究如何改善这方面的情况。

不知道以后会不会有人用“狄仁杰”系列训练AI呢?“元芳……”

模型架构

推理任务的顺序特性,适用于循环网络建模。研究人员采用的架构,是把单向的LSTM网络与一个softmax输出层相结合。

模型被喂给一系列(可能是多模态)的输入,每个输入对应于脚本中的一个句子,并且指定一个标签l,直来表示句子中提到了罪犯(l=1)或者没有(l=0)。这是个增量模型,每个标签的决策仅与之前的输入信息有关。

上图概述了罪犯预测任务。图像、音频和文本等输入模型中,每个模态都映射成一个特征表示,融合之后传递给LSTM。然后LSTM来判断其中是否提及罪犯,并给l赋予1或者0的数值。

这张图显示的就是两个时间步长的LSTM模型输入/输出结构。

这个模型的核心,是一个单项LSTM网络。LSTM对于一系列多模态输入的计算,采用了如下的方式:

另外,多模态融合采用了如下的方式:

研究人员还比较了几种不同的模型架构。

相关下载

论文

摘要:《CSI:犯罪现场调查》是近似真实世界自然年语言理解和与之相关复杂推理的理想试验台。我们把犯罪剧集作为一个新的推理任务,利用每个事件提出相同的基本问题(即凶手)这一事实,最后找到真凶时自然就能获得答案。我们基于《CSI:犯罪现场调查》开发了一个新的数据集,将寻找真凶变成一个序列标签问题,并开发了一个从多模态数据中学习的LSTM模型。实验结果表明,增量推理策略是进行准确猜测以及从文本、视觉和声音输入融合表示中学习的关键。

论文地址:

https://arxiv.org/pdf/1710.11601.pdf

素材

研究人员把部分研究素材也在网上公开了。

GitHub地址:

https://github.com/EdinburghNLP/csi-corpus

加入社群

量子位AI社群11群开始招募啦,欢迎对AI感兴趣的同学,加小助手微信qbitbot4入群;


此外,量子位专业细分群(自动驾驶、CV、NLP、机器学习等)正在招募,面向正在从事相关领域的工程师及研究人员。


进群请加小助手微信号qbitbot4,并务必备注相应群的关键词~通过审核后我们将邀请进群。(专业群审核较严,敬请谅解)

诚挚招聘

量子位正在招募编辑/记者,工作地点在北京中关村。期待有才气、有热情的同学加入我们!相关细节,请在量子位公众号(QbitAI)对话界面,回复“招聘”两个字。

量子位 QbitAI

վ'ᴗ' ի 追踪AI技术和产品新动态


hardfault_handler(硬件错误处理函数)是一种常见的嵌入式系统中的异常处理机制,用于处理当发生特定的硬件错误时,保护系统免受崩溃或不可预测行为的影响。然而,硬件错误的原因往往是复杂而多样的,因此很难将hardfault_handler的故障归咎于一个单一的真凶。 硬件错误可能的来源包括但不限于内存出错、指令错误、算术错误、栈溢出、总线错误等。这些错误的发生可能是由于硬件故障、电压噪声、电磁干扰、程序设计错误等多种因素的综合作用。 在嵌入式系统中,除了硬件错误之外,软件程序错误也可能导致hardfault_handler的触发。例如,非法指令、空指针引用、数组越界、递归溢出等等。这些软件错误可能是由于编程错误、内存管理错误、数据类型不匹配等原因造成的。 因此,将hardfault_handler的真凶归结于一个单一的因素是不准确的。硬件错误的发生可能是由多重因素引起的,这需要进行详细的故障分析和排除。在排查硬件错误时,可以进行硬件测试、检查电路连接、测量电压和电流等方法;而在排查软件错误时,可以通过调试、日志记录、代码审查等手段来找出程序中的错误。 总之,hardfault_handler的真凶往往是硬件错误和软件错误的综合结果,需要综合多方面的因素来进行分析和解决。通过合理的硬件设计和软件编程,可以减少硬件错误和软件错误的发生,提高系统的稳定性和可靠性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值