plainify

找对象的过程中,我竟然理解了什么是机器学习!

最近开始了有关机器学习方面知识的学习,自己啃书本的时候一些概念枯燥无味,所以借着做笔记的机会来简单理解其中的一些概念,如有谬误,还望指出。😊 什么是人工智能? 我看过很多博客解释什么是人工智能,我觉得还不如一句话一张图解释的简洁明了。让机器实现原来只有人类才能完成的任务,这个操作就是人工智能。 下图所示就是让机器模拟人各种能力的人工智能领域示意图:(图片我是在逛知乎的时候发现的,地址贴在文末) 什么是机器学习? 在解释什么是机器学习之前,我们先来举一个让每个程序员都头疼的问题: 找对象 作为一个程序员,找对象自然是个非常紧迫的问题,那找对象总要有个要求吧 🤔 啥?活的?能动?骨骼轻奇的我怎么可能只有这两点要求啊 🙊 显然我是希望找一个好的女朋友啊(毕竟要带出去撑场面的啊),所以应该怎么找呢? 爱美之心,人皆有之。长得好看的妹子肯定比长得丑的妹子更优秀啊,所以这时我就有了一个简单的规则了:只挑选长得好看的女生的当女朋友。所以还等什么?快去朋友圈看看哪些漂亮的女生还是单身啊。是不是 So easy? 当!然!不!是! 生活总是充满了艰辛 张无忌的麻麻说过: 当你网恋奔现的时候你会发现,那些朋友圈里的都是照骗,你懵逼了。。。很显然,只看女生照片找对象这个方法是很片面的,找到一个好的女朋友的因素有很多而并不只是根据女生的颜值。 在经过了大量思考(并且参考了众多好友的女朋友)之后,你又得出了一个结论:身材好同时颜值高的女生更容易吸引你。同时身材一般但颜值高的好友中只有一半左右能让你感兴趣。 这时你再带着你得出的结论去找女生的时候,才知道原来妹子已经脱单好久,只是把你当朋友。。。但是心好的妹子为了安慰你便把她的闺蜜推给了你。然后你发现你之前的结论不适用了,所以只能重新开始约朋友圈的妹子。 假设过了好久好久之后,你成功的总结了一个找妹子的经验,找到了一个优秀的另你满意的妹子了,你很开心的和她在一起了。丑媳妇也要见公婆的,终于到了你把女朋友带回家给家长见面的时候了,你爸妈说,这女生太漂亮了,你管不住,坚决反对。 在你爸妈的反对下,你只能选择无奈的和妹子 say goodbye👋。最后的最后你和你爸妈摊牌,然后将你的择偶规则告诉你的家人,在他们的筛选下,你终于找到了符合**“所有”**预期标准属性的女朋友了。 是不是觉得很 dan 疼? 回想一下上述的场景,是不是觉得十分 dan 疼,虽然最终结果是你找到了一个满意的女朋友,但是在找对象的过程中,你需要不断的更换标准(属性),而且每当你需要用一个新的标准(属性)去衡量一个妹子的时候,你只能手动更改你自己的规则。并且你需要了解所有繁杂的影响女朋友质量的因素(比如颜值、身材、贴心程度、可爱程度等等)。如果这些因素足够复杂,你很难手动分类所有类型的女生而做出精确的规则。 并且,不断的和不同的女生谈恋爱、试错不仅浪费时间,名声也不好。说不定还会被扣上一定渣男的帽子。 来类比下? 其实上述就是一个非常不典型的机器学习的例子,我们来类比下: 机器学习(ML) 你可以从朋友圈随机挑选一些女生(假设你的异性缘足够的好)作为样本(training data),然后列出所有女生的属性,比如身高、颜值、身材、学历、工作,等等(features),以及是否贴心、黏人度、孝心,等等(output variables)。将这些抽象化的数据在机器学习算法里运行(classification/regression),则 ML 算法构建一个模型:女生的属性——女生的质量。 然后等到下次你又遇见了一个女生了,你就可以用眼睛扫一下检查女生的属性(身材、颜值等)了(test data),然后提供给 ML 算法,他就会根据之前生成的模型(model)预测这个妹子最终和你走到一起的可能有多大。 其实在机器学习构建模型过程中,内部使用的规则也许和上述例子中类似,但是也有可能是更复杂的规则,不过这些你并不需要关心。 你现在再去找对象就有很大信心了,而且更重要的时候,随着时间你的 ML 算法会自我提升(reinforcement learning),当预测错误的时候(恋爱谈不下去就分手)矫正自身,随着读取更多的 training data 预测也会越来越精准。但是,最流弊的一点在于,你可以利用相同的算法而训练出不同的模型(model),找女朋友可以用这个模型,那找秘书呢?(仿佛发现了什么不得了的事情 🤓,随便你想要训练出什么模型只要你高兴就好 ) 所以说对机器学习的最简单的理解,便是: 使用某种算法来对已有数据进行解析、学习,然后对真实世界中的数据/事件作出决策/预测。 那深度学习又是啥? 深度学习,是实现机器学习的技术。对机器学习来说,特征提取并不简单。特征工程往往需要大量的时间去优化,而此时,深度学习便可以自动学习特征和任务之间的关联,还能从简单特征中提取复杂的特征。 深度学习是机器学习的许多方法之一,其他方法包括决策树学习、归纳逻辑程序设计、聚类、强化学习和贝叶斯网络等。 那深度学习是如何寻找那些复杂特征的呢? 他是通过建立、模拟人脑进行分析学习的神经网络,它模仿人脑的机制来解释数据,如图象、声音、文本。其产生的灵感来自于大脑的结构和功能,即许多神经元的互联。 下图是我在知乎上看见的一个非常有趣的回答: 推荐大家去阅读下这个回答:👇...

plainify

从网易云日推浅谈个性化推荐系统--基于内容的协同过滤算法

上篇文章介绍了基于用户的协同过滤算法,该算法在一些网站(如 Facebook)中得到了应用,但该算法有一些缺点。首先,随着网站的用户数目越来越大,计算用户兴趣相似度矩阵将越来越困难,其运算时间复杂度和空间复杂度的增长和用户数的增长近似于平方关系。其次,基于用户的协同过滤很难对推荐结果作出解释。因此,著名的电子商务公司亚马逊提出了另一个算法一基于内容的协同过滤算法。 什么是基于内容的协同过滤算法 在进入本文的正题之前,先打开网易云音乐看下今天的日推: 看了上述的标记,是不是瞬间理解了为啥用网易云听音乐的时候会有上瘾的感觉,因为他给你听的都是你爱听的啊。就跟小时候我妈给我做菜是一样的,今天知道我喜欢吃红烧肉,明天为了照顾我的喜好又为了保证不重样,第二天就给我做了糖醋排骨,久而久之产生了依赖性,体重也开始飙升了。 上述就是 基于内容的协同过滤算法(Item-based collaborative filtering,简称 ItemCF) 在生活中常见的案例,该算法给用户推荐那些和他们之前喜欢的内容相似的内容。比如,该算法会因为你购买过《数据挖掘导论》而给你推荐《机器学习》。不过,ItemCF 算法并不利用内容的内容属性计算内容之间的相似度,它主要通过分析用户的行为记录计算内容之间的相似度。该算法认为,内容 A 和内容 B 具有很大的相似度是因为喜欢内容 A 的用户大都也喜欢内容 B。 事实上,由于人和人之间的差异性远大于内容和内容之间的差异(不然怎么会说你女朋友翻脸比翻书还快呢 🙈),ItemCF 算法算是目前业界应用最多的算法。无论是淘宝首页猜你喜欢,还是网易云音乐、哔哩哔哩、YouTube,其推荐算法的基础都是该算法。 Tips:基于内容的协同过滤算法可以利用用户的历史行为给推荐结果提供推荐解释,比如上图中网易云日推的标签,会告诉你是根据你收藏的某某单曲推荐的。 基于内容的协同过滤算法 如果你理解了我的上一篇文章《从网易云日推浅谈个性化推荐系统(1)–基于用户的协同过滤算法》,那你也很容易就可以联想到想要实现一个基于内容的协同过滤需要有以下两步: 计算内容之间的相似度。 根据内容的相似度和用户的历史行为给用户生成推荐列表。 计算内容之间的相似度 1.确定计算相似度的公式 很显然,步骤(1)的关键就是计算两个内容之间的相似度,亚马逊显示相关内容推荐时的标题是 “Customers Who Bought This Item Also Bought” (购买了该商品的用户也经常购买的其他商品) ,相当于就下了一个定义,根据这个定义,我们可以用下面的公式定义内容的相似度: $$W_{ij}=\frac{\left | N(i)\cap N(j) \right |}{\left | N(i) \right |}$$ 这里,分母$\left | N(i) \right |$是喜欢物品$i$的用户数,而分子$\left | N(i)\cap N(j) \right |$是同时喜欢物品$i$和物品$j$的用户数。因此,上述公式可以理解为喜欢物品$i$的用户中有多少比例的用户也喜欢物品$j$。...

plainify

从网易云日推浅谈个性化推荐系统--基于用户的协同过滤算法

这是 2019 年的第一篇文章,因为最近导师给了一个新的任务,有关某 app 的个性化推荐的,正好自己也是第一次学习这方面的知识,便想着汇总整理下。前人栽树,后人乘凉,因为篇幅原因,这一部分准备分开来叙述,本篇主要和大家介绍基于用户的协同过滤算法,希望可以对大家有所帮助,如有谬误,还望指正! 什么是个性化推荐系统? 其实个性化推荐系统早已渗透进我们的生活了,网易云音乐的“每日推荐”,淘宝的”猜你喜欢“,这些都是生活中非常常见的个性化推荐的案例。如今,随着大数据的发展,个性化推荐早已涉及诸多领域,比如电子商务(京东淘宝)、电影和电视网站(youtube)、个性化音乐网络电台(网易云音乐)、社交网络(QQ)、个性化阅读(微信读书)、基于位置的个性化服务(美团)等。推荐算法的本质是通过一定的方式将用户和物品联系起来,而不同的推荐系统也会根据实际情况采取不同的推荐方式。 一般来说一个完整的推荐系统一般包括以下三个参与方: 被推荐对象 推荐物品的提供者 提供推荐系统的网站 以网易云音乐的日推为例: 首先,推荐系统需要满足用户的需求,给用户推荐那些令他们感兴趣的音乐。其次,推荐系统要尽量让各个歌手的歌都能够被推荐给对其感兴趣的用户,而不是只推荐几个大流量歌手的歌。最后, 好的推荐系统设计,能够让推荐系统本身收集到高质量的用户反馈,不断完善推荐的质量,增加用户和网站的交互,提高网站的收入。如下图所示: 什么是好的推荐系统? 想要评判一个东西好不好,一定要有个标准。那么推荐系统好坏的标准是什么呢?试想一下为什么大家都喜欢网易云音乐的每日推荐而不喜欢今日头条的每日推送呢?最直观的感受就是网易云的日推歌曲你爱听,而头条的推送你很讨厌。所以说预测准确度是推荐系统领域的重要指标(没有之一)。 好的推荐系统不仅仅能够准确预测用户的行为,而且能够扩展用户的视野,帮助用户发现那些他们可能会感兴趣,但却不那么容易发现的东西(比如网易云音乐经常给你推送那些非常好听但是比较冷门的歌曲)。同时,推荐系统还要能够帮助商家将那些被埋没在长尾中的好商品介绍给可能会对它们感兴趣的用户。 协同过滤(Collaborative Filtering) 为了让推荐结果符合用户口味,我们需要深入了解用户。如何才能了解一个人呢?《论语·公冶长》中说“听其言,观其行”,也就是说可以通过用户留下的文字和行为了解用户兴趣和需求。 实现个性化推荐的最理想情况是用户能主动告诉系统他喜欢什么,比如很久之前注册网易云音乐的时候会让用户选择喜欢什么类型的歌曲,但这种方法有 3 个缺点:首先,现在的自然语言理解技术很难理解用户用来描述兴趣的自然语言;其次,用户的兴趣是不断变化的,但用户不会不停地更新兴趣描述;最后,很多时候用户并不知道自己喜欢什么,或者很难用语言描述自己喜欢什么。 因此,我们需要通过算法自动发掘用户行为数据,从用户的行为中推测出用户的兴趣,从而给用户推荐满足他们兴趣的物品。 基于用户行为分析的推荐算法是个性化推荐系统的重要算法,学术界一般将这种类型的算法称为协同过滤算法(Collaborative Filtering Algorithm)。顾名思义,协同过滤就是指用户可以齐心协力,通过不断地和网站互动,使自己的推荐列表能够不断过滤掉自己不感兴趣的物品,从而越来越满足自己的需求。 既然是基于用户的行为分析,就必须要将用户的行为表示出来,下表给出了一种用户行为的表示方式(当然,在不同的系统中,每个用户所产生的行为也是不一样的),它将个用户行为表示为 6 部分,即产生行为的用户和行为的对象、行为的种类、产生行为的上下文、行为的内容和权重。 表示 备注 user id 产生行为的用户的唯一标识 item id 产生行为的对象的唯一标识 behavior type 行为的种类(比如说是点赞还是收藏) context 产生行为的上下文,包括时间和地点等信息 behavior weight 行为的权重(如果是听歌的行为,那么权重可以是听歌时常) behavior content 行为的内容(如果是评论行为,那么就是评论的文本) 随着学术界的大佬们对协同过滤算法的深入研究,他们提出了很多方法,比如基于邻域的方法(neighborhood-based)、隐语义模型(latent factor model)、基于图的随机游走算法(random walk on graph) 等。在这些方法中,最著名的、在业界得到最广泛应用的算法是基于邻域的方法,而基于邻域的方法主要包含下面两种算法:...

plainify

做小偷也要会动态规划——轻松解决"01背包问题"

前言 小偷不可怕,就怕小偷有文化,更怕小偷学过动态规划。 正文 白玉汤曾是江湖上赫赫有名的盗圣,奈何岁月不饶人,上了年纪后腿脚便不利索了,无奈一身的本领却没有个传承之人。这天,一位少年前来拜师学艺,希望白玉汤能在偷盗一事上指点一二。白玉汤见这少年骨骼清奇,内心有收其为徒的想法,便出了下面这道题考考少年: 话说地主金馆长家有个专门藏金银财宝的房间,潜入后发现可偷之物太多,奈何自身负重能力有限,你的包只能承重 20kg 的物品,而且每个物品的价值又都不一样,那么问题来了,将哪些物品装入背包才能不虚此行,使价值总和最大呢?物品重量和其价值的关系如下: 编号 重量(w) 价值(v) 1 2 3 2 3 4 3 4 5 4 5 8 5 9 10 少年一看,这不就是一道“01 背包问题吗”,说完便在地上做出了如下分析: 设我们的背包里面的物品价值为 b,给背包添加两个参数:k 和 c,即 b(k,c),那么 b(k,c)又表示什么什么意思呢? k 表示你面对的物品编号,即 1~5, c 表示你面对 k 号物品时,背包的剩余容量 b(k,c)表示面对 k 号物品,并作出拿或不拿的选择之后,背包里面的物品总价值 举个例子,b(2,20)表示的是,在你的背包容量为 20 的情况下,当你面对 2 号物品时并作出拿或者不拿的选择后,背包中物品的总价值。...

2018-08-14 211 words 1 min
plainify

人人都是 LSP?—— 种子与文件下载的相爱相杀

前言 世界上根本没有 LSP,又或者,人人都是 LSP。 说起种子,你会想到什么? 是农民伯伯春天播下,秋天就会收获果实的东西?还是以.torrent结尾的文件? 如果是前者,那你一定是一个热爱大自然的人。如果是后者,你一定是一个“热爱生活”的人。 不过今天我们要聊的不是大自然的那个种子,而是 LSP 们喜闻乐见的这个种子。 P2P 与 BitTorrent 协议 所谓“种子”(或者叫种子文件),其实就是以.torrent结尾的文件,而他之所以叫种子,是因为这个文件里包含了你需要获取的文件的相关信息。就和自然界中的种子一样,包含了日后形成一颗果实所需要的最基本的成分。 而这个.torrent后缀其实指的是支持 BitTorrent 协议的文件。BitTorrent 简称 BT,俗称比特流。看到这,想必你已经有些印象了吧,我们常说的 BT 种子和种子其实是一种东西。 那么这个 BitTorrent 协议是什么? 不急,在介绍 BitTorrent 之前,先让我们梦回高中课堂,回想一下以前抄作业的时光。 抄作业的例子 如上图所示,学霸在写完作业后,要把作业借给同学抄,但是一次只能借给一个人,且其他人只能抄学霸的作业,那么如果想要让学霸在内的 7 个人都写完作业,取决与学霸写作业的速度和每个同学抄作业的速度。我们知道,这样的效率一定是很低下的,所以聪明的学霸想出了第二个办法。如下图所示: 学霸的办法就是,把作业分成几块,让每个人抄不同的部分,比如 A 抄单选题、B 抄多选题、C 抄填空题……然后每个人再把自己抄到的作业和其他人抄到的作业互换,这样,所有人都可以在规定时间内把所有的作业都抄完了,以此实现效率的提升。 P2P 与文件下载 之所以要先提抄作业这个事情,是因为这两种方案和下载文件颇为相似。 传统的文件下载就和上面的第一种方案类似,如上图所示,客户端向服务器发送“我要下文件”,服务器便将文件再发给客户端,这是一个很常见的场景,在这个场景中,客户端下载文件的速率取决于两个因素:服务器的上传带宽和客户端的下载带宽。带宽是指在单位时间(一般指的是 1 秒钟)内能传输的数据量。 而一旦需要下载的文件数量是多个时,下载的总时间便受到下载数量 N 的限制,即越多的人下载某一个文件时,理论上所需要的下载时间就越长,如下图所示: 这种用户体验显然是很糟糕的,那么有没有什么好的方法解决这个问题呢?这就要请出我们本期的“天降猛男”——P2P**(peer-to-peer)**。 这里的 P2P,和点对点(point-to-point)的协议程序不同,它是用户群对用户群(peer-to-peer),当然也不是我们前几年经常听见的暴雷的 P2P(互联网金融点对点借贷平台)。 本文所说的 P2P 是一种架构模式,就和我们之前说过的 C/S(客户端/服务端)架构类似。 在 P2P 模式中,服务和资源分布化,资源不集中存储在某些设备上,而是分散存储在运行 P2P 程序的设备上,每一个对等方都可以为其他对等方提供服务。 还是拿抄作业这个例子来说,学霸的第二个方案就是一个很典型的 P2P 模式。他将自己的作业分成填空、选择、单选、多选等部分,然后分别送给 6 个人,这样当每个人都有自己的一部分副本后,就可以不用再找学霸本人要作业了,直接找其他拥有和自己副本不同的人索取然后互换资源即可。...

plainify

什么是SLA

软件的复杂性带来的问题 工作一年多了,在涉及到跨部门合作的时候往往就是最痛苦的时候,其实道理很简单,刚开始,我们的组织和产品如左图,一切都比较简单,为了业务的发展,通过人工快速吃到技术和产品的红利,很多事情人工能掌控,有事吼一声,开个会就解决了,也运转得很好。 但随着慢慢发展,组织和产品就如右图,彼此连接依赖越来越复杂,为了整体的高速运转,对每个部件的稳定性越来越高,越来越精密,发展到一定程度,人力已经无法掌控,任何一个组件出异常都有可能牵一发而动全身,影响全局。每个部件的稳定性和精密程度决定了整体的工程质量,也决定了整体的发展速度。 那么,为了解决这样的问题,我们可以采取什么样的手段? 从汽车的发展到软件系统的建设 他山之石可以攻玉,软件系统虽然日益复杂,但和汽车建造无本质区别。软件编写完成后是要交付出去的,这就跟一辆车建造好后是要卖给别人一样,闭门造车无疑是自嗨。那么车主在买车的时候会考虑什么? 把时钟拨回到100多年前,贵族们在买车时,车能跑起来就万事大吉了;后来出“车祸”的人越来越多,开车变成了一件危险的事情,于是车企就开始了各种测试(例如碰撞测试);再后来,为了方便车主关心自己车子的状况,越来越多的车撞上了「仪表盘」;到了现在,没有仪表盘的汽车没有几个人敢开,因为你对车的健康、速度等状态一无所知,和闭着眼睛走路没什么区别。 如今,你再去买车,你会关心百里加速耗时多少,油耗多少,制动距离等等**「指标」,因为这些「指标」**让我们对最终交付给我们的车辆能提供的服务有一个明确的认识和期望,开车的时候心里更踏实。 软件系统的交付(代码->安装包->镜像) 回到软件系统,软件工程的本质就是为了解决软件系统的复杂性,而其中一个part就是就是交付过程的复杂性。 代码交付 一开始,我们会选择把代码+配置文档交给业务方,然后由业务方自己去打包、配置运行环境并进行部署和运行。这种交付手段可想而知:流程复杂且不可控,加之开发环境与生产环境的差异,上线前往往需要烧香拜佛,更多的不是技术问题而是玄学问题。 安装包交付 于是在代码的基础上更进一步,交付二进制的安装包或者将配置部署过程脚本化,实现了部署和运行的规范化。这种方式解决了流程复杂和重复的问题,但是仍然不能解决环境不一致的问题,因为宿主环境是你无法预先确定的。 镜像交付 再后来,开发者直接将代码及其依赖的环境(OS、三方库、配置等)完整地打包进虚拟机镜像,实现了一键部署和运行。这种方式既解决了流程问题,也解决了环境问题,主要问题在于虚拟机是一种比较重的技术,比较耗费资源和部署时间。而容器的出现,才真正改变了软件交付的形式,镜像将代码和环境全部打包,容器了确定镜像、部署流程与配置,实现一键部署和运行。 这种方式实现了 “一处编译,处处运行” 的美好愿景(同样愿景的Java还必须依赖JVM,而容器直接与OS交互,是真真的实现了这个愿景),并且比虚拟机更轻量高效,是目前软件交付的事实标准。 我们需要交付的究竟是什么? 类比上文说的汽车的交付,软件系统交付的究竟是什么?是代码吗?功能代码是模棱两可的,谁也不知道到底正确与否,交付质量全凭价值观保证。 客户需要的,其实是你交付的系统能做到什么,不能做到什么,你的系统是否达到我的期许,如果没达到我的期许,又该怎么解决问题。这就是系统开发者与客户之间的「约定」,在软件系统中称为服务等级协议,即SLA(Service Level Agreement)。 那么回到一开始的那个问题,为什么在涉及到跨部门合作的时候往往就是最痛苦的时候,本质上在于双方的SLA不对等,我认为你这个服务的提供方应该要给我提供这些能力,但是服务方却觉得这根本不是我的职责,我为什么要帮你解决问题。 升华一下,亲密关系也是如此,事先没有约定好你想要的和对方能给予的,吵架便也是家常便饭了。 SLA(Service Level Agreement) 前面铺垫了这么多,总算是来到本文的主角了。 SLA,是服务供应商与客户之间的服务等级协议,它定义了服务供应商应保证的服务质量,以及在服务不达标情况下的服务赔偿。SLA在定义上又细分为SLI、SLO与SLA。 SLI,服务质量指标,服务的某项质量的一个具体的量化指标。 SLO,服务质量目标,服务的某项SLI的具体目标值,或者目标范围。 SLA,服务质量协议,描述在服务不达SLO情况下的后果。 现在大家对于SLA的讨论更多是围绕着云服务厂商展开的,其实很好理解,云原生时代,云服务厂商就是最大的服务提供方,而用来确保服务双方达成一致的SLA,自然会更加重视。 云计算的最终愿景是**“让计算资源和公共基础设施一样,按照使用者的规模提供随用量变化的弹性经济模式!”** 虽然SLA常见于公司与外部供应商之间,但事实上SLA也可以用于公司内部两个部门,两个产品之间。公司内部可能不会涉及到服务赔偿,因此内部SLA更关注于SLO的达标情况。 一个实例快速了解SLI、SLO 给你承诺的男人不一定可靠,但连承诺都不给的男人一定不可靠。 男孩对女孩说:以后你发消息,我一定秒回,间隔时间超过xx分钟,我就给你送礼物 SLA中的对服务类型、质量时间条款的条文规定 可是女孩每次发消息的时候,男孩不是在洗澡就是在打游戏,每次都超过约定的时间 可用性低于条文中所规定的值 于是为了哄女孩开心,男孩只能道歉+送礼物 服务商所需提供的赔偿 久而久之,女孩终于忍受不了男孩的行为,选择删除好友。 客户更换服务商 在上面这个SLA的例子中,SLO(指标)就是男孩给出的秒回承诺,秒回(≈0ms)就是SLI(指标),「超过规定时间就送礼物」是未达标的后果,因此SLA又可以抽象成👇 SLA = SLO + 后果...

费米推理——理科生的脑筋急转弯

文:「边缘琐事丶」 | 图:Pixabay ##前言 先问大家几个问题: 下午两点半有多少人在刷朋友圈? 北京有多少加油站? 芝加哥有多少调音师? 胡同口的煎饼摊子一年能卖多少个煎饼? 产品或市场方向的面试中,时不时会出现这些匪夷所思的问题,而面试官只给你几分钟的时间进行思考,让你做出合理的分析,并且给出答案。 作为一个产品小白,初次面对这样的问题真是无从下手。之后搜罗了不少文章,也留下了一些思考,写了点东西就迫不及待地想大家分享一下。 定义 这类问题被称为“费米问题”,英文名“Fermi Problem”,维基百科的词条是这么描述的: In physics or engineering education, a Fermi problem, Fermi quiz, Fermi question, Fermi estimate, or order estimation is an estimation problem designed to teach dimensional analysis, approximation, and such a problem is usually a back-of-the-envelope calculation. 它往往被设计用于考察一个人多维度思考的逻辑思维能力,而回答它时,因为题述给出的已知条件几乎不存在,所以又可以看出一个人的知识面是否广泛,把它放在面试中可以说是再合适不过了。 这个问题真的有标准答案嘛? 估算问题,怎么可能有标准答案嘛! 这个问题答案显然是开放的,因为题述几乎不存在什么已知条件,所以我们并不需要去纠结给出的那个数字正确与否,而应该把更多的目光放在推理过程。 起源 在解决现在我们面试中碰到的费米问题之前,我们不妨先看看古人是怎么思考的。 众所周知,学术界存在的那些XX问题,基本上就是XX提出的。费米问题起源于**“费米悖论”**,那是1951年的一天……一个叫费米的人,仰望星空,问了一句:“外星人都在哪呢?” 银河系中有数十亿和太阳类似的恒星,其中很多比太阳系古老10亿年以上。其中一些恒星可能会有类似地球的行星,它们很可能也会孕育智慧生命。其中部分智慧生命可能会发展出星际飞行的科技。即使以我们现在能够想象的科技飞行,它们也能够在一百万年内飞遍整个星系。 但是,为什么我们在太空中没有看见一个智慧生命的影子呢? 一拍脑子想出来的问题,众说纷纭。一直到1961年,弗兰克·德雷克成名之作诞生——“宇宙文明方程式”。 其中:...