数据科学家“恐怖故事”

大数据文摘出品

编译：张秋玥、蒋宝尚

文字语音转换圈内流传这么一则真假未知的故事：一个研究者花了数月(甚至数年)调整他/她的语音生成模型，使其语音样本听起来效果非常好。最后他们发现，他们从头到尾都误用同一语音文件进行训练，最终模型只是完全符合该语音文件特征所以才拥有如此流畅的语音样本输出。这个故事到现在都让人不寒而栗。

想象一下另一则恐怖故事：你是个小实习生，，老板让你搭建一个判断识别“Yes”与“No”的语音识别分类器。你有这些音频文件：yes1.wav，no1.wav，yes2.wav，no2.wav，yes3.wav等等。你建好了分类器，效果也很好。就在你要展示工作成果之前，你发现这个模型唯一在做的事情就是通过读取文件名里的yes或者no来预测结果，压根不会听文件里面的音频。你吓傻了，大哭一场，准备跑路。

这就是本文作者Vincent Vanhoucke所经历的恐怖故事，完全真实，这些小事故也决定了这位Google首席科学家的职业生涯。

以下是他以第一人称讲述的更多小故事，让我们看看能够从中得到哪些经验：

那是我作为研究者的第一份工作。任务很明确，提供了大量数据以及优秀的预测准确度标准来评估模型效果。模型的基准结果很强，我最后甚至和一位客户一起在生产实践中部署了这个模型。

我有试图根据我觉得很聪明很厉害的方法来改进模型表现指标——它没有很完美但每一天都在进步。我都能看到我脑子里慢慢形成的一篇优秀学术论文啦。生活真美好。

这算是一项产业研究，所以在开始撰写论文之前我还需要通过最后一项测试：使用真实顾客数据来评估模型，以便于快速在生产实践中部署改进方案。在真实数据集上我的模型达成了零精确度成就。我可是一直在提高我觉得超级厉害的表现指标来着。

八成是出了bug，要不就是真实顾客数据质量很糟糕——我脑子这么想着，觉得没多大关系就急着开始上手写论文了。但实际上我又并没有办法完全放下这个糟糕结果，所以我就开始研究到底是怎么回事。我最后发现的是全世界数据科学家共同的噩梦：准确度就是零，这一点毫无疑问。我其他所有的准确度数据都是所谓的“幽灵”数字。我简直不敢信：这些数字看起来超可信啊，它们比基准高但并没有高到不可能的地步。

人们常说，灾难一般不会“成单”出现，而是在有两件事一起出错时，因为我们总体来说很擅长预判并改正单个失误。为了完全了解到底是什么样几乎不可能发生的系列事件导致了这些看似可信的精确度数字的出现，我必须得从细节开始分析。

模型目标是改善用来识别人名的语法数据结构。比如说，假如你叫“Robert Moore”，语音识别系统可能将会把你的名字编译成为一个语音图，大致看起来像是某种正则表达式：“/(ˈɹɑb.əɹt|ˈbob|ˈɹɑb) mʊɹ/”——它还兼容类似于“Rob”或“Bob”的昵称呢。我的任务是生成更好的语音图。我的数据被存储为键值对数据库的形式：

record { 
key (string): “robert_moore” 
value (Grammar): /(ˈɹɑb.əɹt|ˈbob|ˈɹɑb)mʊɹ/ 
} 

这里有一个bug：有些我的语法数据结构里用到的语音符号并不会被发音引擎识别。系统尝试把语法数据结构编译为一个应当代表正则表达式的图像对象，但它失败了。在层层代码的深处，有人曾尝试将系统变得对于这些失败更加稳健：毕竟，只要可能，你永远不希望系统在生产实践中突然垮掉嘛。那段代码看起来类似于这样：

Graph* graph = compile(record->value); 
if (!graph) { // Failed to compile. 
graph = compile(record->key); // （什么鬼？？？） 
} 

这可真的让我大吃一惊措手不及：怎么会有人觉得只要一条数据库记录损坏了就代表这条记录的键包含真正的负载?而且这怎么可能可行嘛?“值”就是一条序列化的型语法，“键”就只是一串字符而已。再深挖一点——看，更“稳健”的在这里：

Grammar* grammar = parse(record); 
if (!grammar) { // Failed to parse. 
grammar = parse(pronounce(record)); // （啥？？？） 
} 

如果数据不是我们预想的类型，我们就会尽量提取那条记录的内容为单词进行发音。为什么不呢，反正已经毫无希望了嘛。而且，发音生成是一项非常耗时耗计算力的操作。想象一下，不管出于什么原因，一大串没有任何意义的垃圾字符(包括对于拒绝服务的报复性操作)突然被输入到系统里，这对于系统意味着什么。系统将会立刻过载，而非“逐渐失败”。

你可能已经意识到接下来要发生什么了。我的数据的键都是用户的真名，比如“robert_moore”。发音引擎很容易就将其近似于“/ˈɹɑb.əɹt mʊɹ/.”。所以，我的数据的问题直接来自于决定模型评估标准的事实。

理论上来说这就与我在前文提到的根据文件名预测音频是yes还是no一个道理。我没预料到的是，发音模型的随机试验看起来确实改善了结果。然而，那其实只是取决于每次实验中未编译成功的数据比例而已。我的模型失败次数越多，生成的错误就更多，真实键值使用的更多，我的模型精确度就越好。至于解锁零精确度成就的真实数据?那个数据库里的键都是乱七八糟的字符串，看起来类似于“h4a7n6ks2l”这种发音模型?

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!