理解偏倚:可靠结果的先决条件

简介:


0?wx_fmt=gif

◆ ◆ 

前言


事实证明用数据从事一些非常合理的事情是非常容易的,比如求合,做切片,求均值等,而得出的答案却有2000%的错误!在这篇文章中,我想通过使用一些非常简单,直观的图片来说明为什么是这样的。为了解决这个问题,我们用由Judea Pearl(其他提出者之一)提出的框架来设计一个非常棒的通用模型。


除了满足我们的好奇心(无法估量的价值),我们会慢慢明白为什么设计这个精准模型这么有价值。就某种情况而言,毕竟我们真正感兴趣的是一个变量对另一个变量的影响。当然,你也会问,是否你真的需要一个这样的模型来帮你计算出结果,或者只是需要把所有的数据丢给最新的机器学习模型去处理,然后等着获取结果就可以了?


◆ ◆ 

什么是偏倚?


关于因果关系的系列文章在文章的第二部分(第一部分在这里),我们将在第二部分学习所有关于偏倚的知识。任何时候只要你想测量某些东西,你就会遇到偏倚,也就是你得到的结果与真实的误差。一般来说偏倚是指一切测量值对真值的偏离。比如,你想测量一个广告的投资回报率,你测量的是人们搜索广告点击量增长了1198%,而不是测量得实际5%投资回报率。比如,你想测量学校招生过程中的性别歧视情况,你的测量的结果是男性更占优势,然而实际情况是女性病没有占优势得那么明显。


什么原因导致了偏倚?我们如何去纠正它,我们如何去用图表示出影响偏差的因子?要回答这些问题,我们从一些教科书中的例子开始讲,比如下雨和人行道之间关系的例子。我们在文末会回过头来谈论关于“灾祸”的例子,并且将这个例子和一个叫“线上活动偏倚”相比较。


◆ ◆ 

关于潮湿的人行道的故事


Judea Pearl在他论述悖论的文章中通篇用了一个简单且直观的例子。这里,我们引用他举的例子,主要是因为这个例子直观明了,接着再谈论其他一些我们更关注的例子。



0?wx_fmt=png

1

人行道是如何变湿的。上面的圆圈表示“潮湿”;下面的圆圈左边表示“雨水”;右边表示“喷水装置”。


在这个例子中,我们检测的是什么原因导致湿着的人行道。我们有一个喷水装置,这个定时洒水装置会在设置的时间点喷水弄湿人行道。我们当然也知道,任何时候只要下雨,人行道就会变湿。我们每天记录这三个变量,并得出了一个有效的数据组。我们得出的图解总结一个通用的模型,而且它也表明了一种合理性的检查方式,我们可以通过检查了解下雨是否和正在洒水的喷水装置有关联。当我们基于所假设的数据组这么检查时,我们发现事情并没有什么问题。每件事情看起来都是对的。


现在我们回过头来考虑之前已经思考过的问题,如果我知道(1)人行道是湿的,并且我知道(2)并没有下雨。那这样的话,这告诉我了什么?有没有告诉我喷水装置是开着的呢?


如果我们把人行道是湿着的一个理由去掉(我们知道并没有下雨),那么其它的解释就变得更有可能。如果你知道人行道是湿的,又了解到天并没有下雨,这时你就知道洒水装置是开着的。在我们知道人行道是湿着的情况下,洒水装置和雨水,这两个变量在数据上变得相互依赖。让我们花些时间来试图明白是怎么一回事,这会有什么不好的影响。


如果我们把数据只限制于人行道是湿着的那么几天,我们会发现下雨与开了喷水装置之间是负相关的。这个情况发生的原因,我们已经提及过,那就是,如果人行道是湿的,而且没有下雨,那么喷水装置就可能被打开了。如果人行道是湿的,而喷水装置没有打开,那么就可能是下雨了。即便这两者之间在原先的数据上没有关联,但是在这些被限制了条件的数据中这些数据是负相关的。


这个情况的出现是因为我们不是单纯地无拘束地在检验,而是在我们已经一部分地了解了世界是如何运行的。如果“人行道是湿的”并且“天没有下雨”,那么,“喷水装置就可能是开着的”。像这样的陈述句“如果”被称为“条件性”陈述。当我们对已知的某些事物进行推理(把这部分是放在在“如果”之后,“就”之前),那么,这部分就是我们所说的“条件性”认知。我们会明白那个条件的意思而却没有意识到它会制造偏倚,这个偏倚甚至是会带来极端错误的结论的。


事实上,一般情况下这样的影响会发生,你也可以根据这些图来考虑它。当我们假设两个原因产生一个共同的影响,那么这两个原因之间就会发生关联,即便它们本来没有任何联系!这个悖论被称为“伯克森悖论”(Berkson’s paradox)。看这图表,我们比较容发现共同效应,即从所产生的影响向上找寻变量,以共同结果的产生这一条件为基础,其所有的上游变量可以变得相互依赖。


要理解本文的剩余部分不一定需要明白以下两句话的意思,但对任何一位对此感兴趣的人,我们可以用数学术语来解释。喷水装置和雨水是各自独立的变量,但是基于特定条件,它们两者会相关联。条件独立性并不意味着变量就是独立的,同样,变量是独立的也并不意味着基于条件变得独立。


现在,我们就可以明白同样的结构是如何产生偏倚,且这属于在实验中是很容易产生的一种现象。


◆ ◆ 

数学呆子是不是不善于社交?


假设,你正在申请一个工作,只要你有非常好的社交技能(而且专业能力上也还过得去),或是你有非常好的专业技能(且社交能力还算合格),这个公司都会雇佣你。你可能这两者都有,但是拥有这两个非常好的技能中其中一个是必要条件。这看起来有点像图2中的样子,看着,是不是觉得熟悉?



0?wx_fmt=png

2

如何被雇佣。上面的圆圈表示“被雇佣”;下面的圆圈左边表示“社交的”,右边表示“专业的”。


在公司里看到这些同事的时候,你只会意识到这些人是已被雇佣,很可能,你自己都没有意识到他们是社交或者专业技术不错的这个前提背景,你已经假设了里每一个人都被雇佣的事实(想想:人行道是湿着的)。在这样的背景下,认识一个有很好社交能力的人,那么这个人就不太可能有32个赞的专业能力(反之亦然),然而这两者放在整个人群中去考虑,是没有关联的。


这样的结果将真实的偏差引进了实验中。假设你正在网上做在线调研(即便是随机的AB测试),你会默认这位被测试者已经访问过你的网站。假设你正在大学做个调查,你会默认在学校的每一位同学都已入学.这种默认可能产生了偏倚。基于这种条件下产生的偏倚,被称为“选择偏差”。但这种情况更糟糕的是,即便我们是以已经被雇佣比如职务名称或者部门(比如,我们调研一个部门里所有成员)作为先决条件,也同样产生偏倚。那是因为,从下游的影响出发去假设条件也会产生偏倚。


从这些例子,你得出这样一个结论:条件假设是一个非常可怕的事情。不幸的是,也存在着一些案例表明,条件假设事实上纠正了偏倚,然而这样的偏倚是你即便不假设条件,你也会有的偏倚。


◆ ◆ 

那怎么办呢?淡定


事实证明,图画是关键。之前我们谈论的偏倚是由不同的原因产生相同的结果造成的(箭头的方向是同时指向结果的)。现在我们把箭头的方向调转一下,讨论由相同的原因产生不同影响的过程中引起的偏倚(箭头的方向从条件分开指向不同的原因)。


0?wx_fmt=jpeg

3


考虑上一次提到过的灾祸的例子(简化版),图3描述了“灾祸”可能导致交通问题,也可能导致报警系统响个不停(直到没有电源)。但这两个原因是互相独立的。


即使交通问题和报警系统响个不停不存在因果关系,但他们两个之间确实存在相关性!如果有灾祸,就会导致交通问题,我的报警系统也会一直响。拔出报警系统不会对车外的交通产生影响,就像由于体育比赛导致的交通堵塞也不会让我车内的报警系统响个不停。这是一个伪相关,并且是由一个共同的原因导致的,是灾祸导致了交通和报警系统的问题。


我们应该怎么做才能解决这个伪相关?答案就在于条件!如果数据中没有灾祸这个条件,报警系统会不会停和有没有交通问题根本是没有关联。同理,如果我知道有灾祸发生而且报警系统没有停,并没有给我额外的关于有没有交通问题的信息(因为我已经知道了已经有一个灾祸),我们同样是无法判断说是否有交通问题。


◆ ◆ 

现实生活中的偏倚


由共同的原因导致的偏倚叫做混杂,并且在现实世界中这才是普遍现象。这正是在介绍部分我们提到的2000%偏倚的原因。真实的情况看起来更像图4。这也是为什么单纯地把目标根据某种属性(例如:文章类别)分组并比较平均值(例如:每篇文章的分享数)是不对的。


0?wx_fmt=jpeg

4


这幅图表达的是我们想知道人们有没有在网上搜索某种商品。我们想知道一条广告有多么有效,所以我们就想探知看一条广告和搜索相关商品这两个行为的因果关系。不幸的是这两个行为有一个共同的原因。如果你是一个活跃的互联网用户,那你有更高的可能性会看广告,同时也有更高的可能性会搜索商品(与你是否看到广告无关)。这类偏倚叫做活动偏倚,并且如果你没有把这种偏倚考虑在内的话,得到的关于广告有效性的结果会比真实情况大200倍左右。


庆幸的是,实验可以帮忙减轻这个问题。如果你随机挑选谁会看到这条广告,也就相当于打破了互联网活跃度和看到这条广告之间的关系。换句话说,你把图中连接活跃看到广告的那条线移除了。这其实是一个需要有独立的帖子来更深入探讨的概念,当然在以后我们会做的!


你同样也可以通过设立条件来移除偏倚,但这取决于用来衡量活动的标准好不好。实验总是首选,退而求其次便是设立条件。我也会在以后的帖子中更深入的讨论设立条件的不同办法。现在我们只是有一个大概的结论。


◆ ◆ 

到底我们要不要设置条件呢?


之前的论述表明:当你给一个共同的结果设置条件,或是没有给一个共同的起因设置条件,偏倚就会产生,反之亦然。根据后门准则我们知道在给定一个很完整的世界蓝图的时候,什么应该设置条件,什么不该设置条件。


有两个标准:(1)不给共同的结果设置条件,(2)给共同的起因设置条件。这就奠定了我们应用后门准则作为解决方案的基础,但是正如刚刚提到的,了解一个很完整的世界蓝图是一个很重要的前提。


这就给我们留下一个值得思考的问题:如何才能做到科学。


如果我们努力构建一个世界蓝图,并找到正确的事情加以条件,这样我们就可以预估到任何我们想要的结果了么?这个世界是基本上静止的,并且这个蓝图变化的很慢,足以让我们用之上的方法么?还是说永远都会是一个一次性的实验,每一次当我们有需要的时候才会重新预估结果?如果我们采用后一种办法,从行动的角度来看还是可行的。


你应该会已经发现了,这种给正确的变量设置条件的办法与通常我们把所有数据一股脑的放进机器学习的办法形成鲜明对比。这也是一个值得更深入探讨的话题。


事实证明,如果你真的想要一个预测模型,可能应用后门法则会比使用所有历史数据进行机器学习的办法更好。你可以自己多多去尝试,只是要注意不要把各种结果和影响放进模型里面,这也是干预观察不同的地方。当然,就这点也值得另外一篇文章来深入探讨。


原文发布时间为:2016-08-16

本文来自云栖社区合作伙伴“大数据文摘”,了解相关信息可以关注“BigDataDigest”微信公众号

相关文章
|
1月前
|
存储 测试技术 C++
P2P网络下分布式文件共享场景的测试
P2P网络下分布式文件共享场景的测试
29 6
|
1月前
|
存储 缓存 负载均衡
软件容错技术和方法在系统中的具体应用
软件容错技术和方法在系统中的具体应用
35 0
|
11月前
|
存储 安全 网络安全
【可靠性工程】Microsoft 可靠性模式
【可靠性工程】Microsoft 可靠性模式
|
11月前
|
API UED
【可靠性工程】GCP 可靠性核心原则
【可靠性工程】GCP 可靠性核心原则
|
测试技术 数据库
【可靠性测试】什么是可靠性测试:定义、方法和工具
可靠性定义为在特定环境中指定时间段内无故障软件运行的概率。 执行可靠性测试是为了确保软件是可靠的,它满足其目的,在给定的环境中指定的时间量,并能够呈现无故障运行。
|
Dragonfly Kubernetes Cloud Native
如何保证软件交付过程的标准化|学习笔记
快速学习如何保证软件交付过程的标准化
523 0
如何保证软件交付过程的标准化|学习笔记
|
Dragonfly 运维 Cloud Native
如何保证软件交付过程的标准化 | 学习笔记
快速学习如何保证软件交付过程的标准化
223 0
如何保证软件交付过程的标准化 | 学习笔记
|
安全 测试技术
构建可靠系统的原则与实践
随着阿里技术的发展,我们的技术系统越来越成为社会的基础设施,对于这些系统的可靠性要求也就越来越高。但是实际上很多的基础的产品和系统确仍然会出现一些稳定性问题,那么如何才能构建可靠的系统呢?是不是制定非常严格而细致的规则就可以做出可靠的系统呢? # 航空业的教训 在回答这个问题之前,我们先来看看对于系统可靠性要求非常高的航空业是怎么做的?美国的FAA是在航空安全领域事实上的权威,为了保证航空
13122 0
|
存储 监控 关系型数据库
开源EDR(OSSEC)基础篇- 02 -部署环境与安装方式
上一篇介绍了OSSEC设计的定位以及产品输出的能力,在对OSSEC安全功能有个大体印象的前提下,我们接着开始实践OSSEC的安装和部署,本篇重点的重点是帮助初次接触或者对OSSEC不熟悉的同学,无痛安装,并能够用最短的时间在所服务的企业内部真正的使用起来
6457 0