IT瘾facebook推荐

Facebook宣布不再使用人脸识别技术将删除超过10亿用户数据

Wed, 03 Nov 2021 10:32:39 CST

11月3日消息:Facebook 今天凌晨宣布，该公司将终止使用人脸识别系统，并将删除超过10亿人的人脸识别模板。数据显示，已有超过三分之一的日活用户（逾6亿个账户）在Facebook上选择使用人脸识别技术。

Facebook人脸识别系统可以自动识别发布在社交媒体的照片和视频中人的面部。据报道，此举是新更名的Meta公司人工智能副总裁Jerome Pesenti在一篇博文中提及，Pesenti表示，Facebook将在未来几周关闭其面部识别系统，删除超过10亿人的个人面部识别数据，「作为公司对于面部识别使用限制的一部分」。

Jerome Pesenti在文章中说：「我们需要权衡面部识别的积极案例和日益增长的社会担忧，尤其是监管机构尚未出台明确规则。」

Facebook 因为推错了 BGP 路由的配置，相当于直接把自己的所有系统从互联网上断开了。没法快速恢复是因为平时通过互联网工作的员工也访问不到。更厉害的是门禁系统也在断开的系统之内，员工的门禁卡失效没法物理进入机房维护。。

Tue, 05 Oct 2021 07:36:51 CST

Facebook 因为推错了 BGP 路由的配置，相当于直接把自己的所有系统从互联网上断开了。没法快速恢复是因为平时通过互联网工作的员工也访问不到。更厉害的是门禁系统也在断开的系统之内，员工的门禁卡失效没法物理进入机房维护。。

想看更多劲爆内容，请下载抽屉新热榜客户端 :
http://dig.chouti.com/qrcode/10036

Facebook的大规模故障代价惨痛使公司直接损失了约6000万美元的收入

Tue, 05 Oct 2021 07:37:29 CST

据报道，Facebook的大规模故障给这个社交网络的财务带来了很大的损失。《财富》和Snopes估计，自从其应用程序（包括Instagram和WhatsApp）在周一美东时间上午8:30左右宕机下线后，这个世界上最大的社交网络已经损失了至少6000万美元的收入。

两家媒体都使用Facebook在发布第二季度财报时提供的数字估算了截至美东时间下午4点的收入损失。在那三个月期间，Facebook报告了约290亿美元的收入。这意味着，Facebook每天大约赚取3.196亿美元，每小时1330万美元，每分钟22万美元，每秒钟3700美元。然后，这些机构使用这些数字，根据故障持续的时间来计算收入损失。

这些估计强调了大规模故障对Facebook广告业务的财务影响。该公司表示，它正在努力恢复其服务，但还没有说是什么原因导致了中断。目前，Facebook对一些人来说已经恢复正常了。

"我们知道有些人在访问我们的应用程序和产品时遇到了麻烦。我们正在努力使事情尽快恢复正常，我们对造成的不便表示歉意，"Facebook在大约六小时前发推文说。

该社交网络表示，截至美国东部时间下午3:30/6:30左右，Facebook的服务正在慢慢恢复。该公司在Twitter上说："对全世界依赖我们的庞大社区的人们和企业来说，我们很抱歉，们一直在努力恢复对我们的应用程序和服务的访问，我们很高兴地报告，它们现在正在恢复在线。谢谢你们的支持。"

收入损失并不是Facebook在周一遇到的唯一财务问题。在社交媒体宕机引发的股票的广泛抛售中，该公司的股票下跌了近5%，至每股326.23美元。(由于受到波及，就连服务保持在线的相关社交网络企业Twitter和Snap的股价都下跌了5%以上）。

Facebook股价的下滑对首席执行官马克-扎克伯格(Mark Zuckerberg)的净资产产生了影响，他的净资产降至1216亿美元。据彭博社报道，他现在低于微软联合创始人比尔·盖茨，是世界上第五位最富有的人。

查看评论

外媒：Facebook有1万名员工在研发AR/VR设备占员工总数近1/5

Mon, 15 Mar 2021 14:56:00 CST

【TechWeb】3月15日消息，据国外媒体报道，Facebook在增强现实（AR）和虚拟现实（VR）上押下重注。据报道，Facebook有近1万名员工（占其全球员工总数的近五分之一）在研发AR和VR设备。

2017年，Facebook的全球员工总数为18770人，其中该公司旗下Oculus VR部门的员工超过1000人，所占比例超过5%。2021年初，该公司在全球雇佣了58604人，约有1万名工程师负责重要的AR和VR开发工作，这一数字几乎占Facebook全球员工总数的20%。

近年来，Facebook制定了一项积极的战略，即打造自己的消费类硬件，以减少对苹果和谷歌的依赖。为了减少对苹果和谷歌的依赖，该公司将全力投入Oculus。

Facebook一直在大力进入虚拟现实领域。2014年，该公司以逾20亿美元收购了虚拟现实游戏公司Oculus Studios。2019年11月，该公司收购了VR音乐游戏《节奏空间》（Beat Saber）的开发商Beat Games。2020年2月份，该公司又收购了虚拟现实游戏开发企业Sanzaru Games。

除了Facebook，其他公司也在开发AR/VR解决方案。比如，苹果可能正在开发多种AR/VR设备，包括AR隐形眼镜和配备8K micro-OLED显示屏的头盔。（小狐狸）

盘点Facebook 、YouTube等主流产品的10大创新设计

Wed, 23 Dec 2020 18:47:25 CST

编辑导读：每个设计师都会有创意灵感缺失、大脑一片空白的状态，这个时候去看看最新的一些设计趋势会是一个寻找灵感的好方法。本文作者梳理盘点了国外主流产品的10大创新设计，希望能帮助解决你设计时遇到的灵感枯竭。

国内的产品设计同质化严重，将众多同类产品放在一起，去除图标和主题色的话，很难区分是哪个App。

设计师的视野如果长期只关注国内，那么设计创新能力很容易被束缚，导致创新能力下降。

应对突发需求，国内没有相对应的竞品，就无法做出可落地的方案。

本篇文章盘点下国外主流产品的10大创新设计，通过本篇文章，希望可以打开视野，提升创新能力。

01 左滑进入聊天界面

Instagram在首页界面，用户左滑进入消息聊天页。这是一种全新的交互形式。

国内的产品，左右滑是切换首页的二级导航。

我第一次使用时不习惯，很容易误操作。当习惯之后，就觉得超级方便。它可以快速地切换到聊天消息页。

为什么Instagram要做这个交互？猜测原因有以下2点：

Instagram发力即时通讯，鼓励用户相互发消息。底部已经有了5个tab，没办法继续增tab。这时候只能想办法找其他流量大的入口。
流量最大的入口毫无疑问是首页。所以Instagram在首页新增手势操作，当用户左滑，就能快速地到达消息聊天页。此方案可以完美的满足业务需求。

02 视频小窗口播放

在YouTube视频详情页，没有视频关闭功能。用户不想看视频时，只能点击播放器左上方的收起箭头。

当用户点击之后，会变成卡片小窗口，进行小窗口播放。如下图所示：

这样设计的好处：

可以让用户边找视频，边观看。尽可能地利用用户时间。
使用户消费更多视频，提升用户的观看效率。

03 推荐视频

YouTube在播放过程中，底部会出现四个视频，用户上滑时全部出现。

用户可以在播放过程中，点击推荐视频观看。

这种设计更加强化推荐视频功能。用户可以在播放过程中，选择更感兴趣的视频。

国内视频产品，在全屏的情况下，无法推荐视频，只能在视频结束后推荐视频。国内这样的好处是可以更聚焦当前视频。

04 筛选订阅视频观看

在订阅内容Tab，用户可以根据标签，进行筛选视频，这种操作可以极大的提升用户查找视频的效率。

像继续观看、未观看内容，这些标签，可以高效，不遗漏地观看订阅up主的视频。

05 提升push打开率

当订阅up主后，push推送没有打开时，会出现消息未打开的图标，用户点击，进入设置页面，进行打开通知设置。

这种设计的好处是：推送设置入口固定展示，用户打开push的概率大大增加。

而push打开率的提升，对提升产品的日活帮助巨大。

06 导航和设置展示在一起

Google Chrome 首页，将用户最常访问的网站和功能项放在一起，如下图所示：

一般来说，国内产品很少将两个不同属性的模块放在一起，这样的话容易被误解为一种类型。

但是为了让用户使用更加方便。Google Chrome将其放在一起，都采用宫格导航的形式，通过图标和背板的不同做了一定程度的区分，用户的体验更加友好。

07 下拉操作

Google Chrome下拉时，展示三个选项，左右滑动选择对应的操作。

这种交互方式，即做到了界面简洁，也做到高效方便使用。

08 为其他app引流

Facebook作为一个超级App，所涉及到的业务庞杂，公司内部各个部门利益复杂。为了业务利益，不同部门组织在不断地博弈。

如下图所示，为了尽可能的给其他业务引流，Facebook底部有6个tab，这在主流产品中是不可思议的存在。

为了给messenger引流，首页右上角增加了一个闪电消息图标，会和messenger App联动，当有新消息时，会出现消息提示。点击跳转到messenger。早期facebook 是将底部一个tab给messenger引流，点击tab，直接跳转到messengerApp。

Facebook的这种导流设计，粗暴高效，短期内使得messenger也成为一个超级app。

09 删除中倒计时

Telegram在删除联系人时，底部会出现倒计时提示，在这个期间，用户可以撤回删除操作。

这种交互设计，使得用户在删除过程中更加有安全感，可以回撤毁灭性操作。

10 一次发多条动态

Twitter在发布动态的时候，可以一次性发送多条，这种设计，可以一次性批量的发送，提升用户效率。

以上就是我发现外国主流产品的创新设计。而这些设计，国内基本没人采用，所以分享出来给大家。

如果大家有其他的发现，欢迎在评论区留言。

#专栏作家#

UX，人人都是产品经理专栏作家。前美团点评高级交互设计师。微信公众号：Echo的设计笔记，欢迎关注

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议

Facebook词向量工具FastText

Mon, 18 Nov 2019 10:48:44 CST

FastText简介

fastText是Facebook于2016年开源的一个词向量计算和文本分类工具，在文本分类任务中，fastText（浅层网络）往往能取得和深度网络相媲美的精度，却在训练时间上比深度网络快许多数量级。在标准的多核CPU上，能够训练10亿词级别语料库的词向量在10分钟之内，能够分类有着30万多类别的50多万句子在1分钟之内。

FastText与Word2Vec

fastText的其中的一个作者是Thomas Mikolov。也正是这个人在谷歌的时候，带领团队在2012年提出了 word2vec代替了one-hot编码，将词表示为一个低维连续嵌入，极大促进了NLP的发展。14年她去了脸书，然后提出了word2vec的改进版：fasttext。所以fastText和word2vec在结构上很相似。

相同之处：

图模型结构很像，都是采用 embedding 向量的形式，得到 word 的隐向量表达。
采用很多相似的优化方法，比如使用 Hierarchical softmax 优化训练和预测中的打分速度。
训练词向量时，两者都是无监督算法。输入层是 context window 内的 term。输出层对应的是每一个 term，计算某 term 的概率最大；
在使用层次softmax的时候，huffman 树叶子节点处是训练语料里所有词的向量。

不同之处：

模型的输出层：word2vec的输出层，对应的是每一个term，计算某term的概率最大；而fasttext的输出层对应的是分类的label。不过不管输出层对应的是什么内容，其对应的vector都不会被保留和使用；
模型的输入层：word2vec的输入层，是 context window 内的term；而fasttext 对应的整个sentence的内容，包括term，也包括 n-gram的内容；
两者本质的不同，体现在 Hierarchical softmax的使用。
- Wordvec的目的是得到词向量，该词向量最终是在输入层得到，输出层对应的Hierarchical softmax也会生成一系列的向量，但最终都被抛弃，不会使用。
- fasttext则充分利用了Hierarchical softmax的分类功能，遍历分类树的所有叶节点，找到概率最大的label（一个或者N个）

FastText的优点：

适合大型数据+高效的训练速度：能够训练模型“在使用标准多核CPU的情况下10分钟内处理超过10亿个词汇”，特别是与深度模型对比，fastText能将训练时间由数天缩短到几秒钟。使用一个标准多核 CPU，得到了在10分钟内训练完超过10亿词汇量模型的结果。此外， fastText还能在五分钟内将50万个句子分成超过30万个类别。
支持多语言表达：利用其语言形态结构，fastText能够被设计用来支持包括英语、德语、西班牙语、法语以及捷克语等多种语言。它还使用了一种简单高效的纳入子字信息的方式，在用于像捷克语这样词态丰富的语言时，这种方式表现得非常好，这也证明了精心设计的字符 n-gram 特征是丰富词汇表征的重要来源。FastText的性能要比时下流行的word2vec工具明显好上不少，也比其他目前最先进的词态词汇表征要好。
fastText专注于文本分类，在许多标准问题上实现当下最好的表现（例如文本倾向性分析或标签预测）。
比word2vec更考虑了相似性，比如 fastText 的词嵌入学习能够考虑 english-born 和 british-born 之间有相同的后缀，但 word2vec 却不能。

模型架构

fastText的架构和word2vec中的CBOW的架构类似，因为它们的作者Tomas Mikolov，而且确实fastText也算是word2vec所衍生出来的。

CBOW的架构

输入的是的上下文2d个词，经过隐藏层后，输出的是。word2vec将上下文关系转化为多分类任务，进而训练逻辑回归模型，这里的类别数量是词库大小。通常的文本数据中，词库少则数万，多则百万，在训练中直接训练多分类逻辑回归并不现实。word2vec中提供了两种针对大规模多分类问题的优化手段，negative sampling 和 hierarchical softmax。在优化中，negative sampling 只更新少量负面类，从而减轻了计算量。hierarchical softmax 将词库表示成前缀树，从树根到叶子的路径可以表示为一系列二分类器，一次多分类计算的复杂度从降低到了树的高度。

fastText模型架构

其中表示一个文本中的n-gram向量，每个特征是词向量的平均值。这和前文中提到的cbow相似，cbow用上下文去预测中心词，而此处用全部的n-gram去预测指定类别。注意：此架构图没有展示词向量的训练过程。可以看到，和CBOW一样，fastText模型也只有三层：输入层、隐含层、输出层（Hierarchical Softmax），输入都是多个经向量表示的单词，输出都是一个特定的target，隐含层都是对多个词向量的叠加平均。

fastText与CBOW的不同点：

CBOW的输入是目标单词的上下文，fastText的输入是多个单词及其n-gram特征，这些特征用来表示单个文档
CBOW的输入单词被one-hot编码过，fastText的输入特征是被embedding过
CBOW的输出是目标词汇，fastText的输出是文档对应的类标

值得注意的是，fastText在输入时，将单词的字符级别的n-gram向量作为额外的特征；在输出时，fastText采用了分层Softmax，大大降低了模型训练时间。

Hierarchical softmax

Softmax回归（Softmax Regression）又被称作多项逻辑回归（multinomial logistic regression），它是逻辑回归在处理多类别任务上的推广。

在逻辑回归中，我们有m个被标注的样本：，其中。因为类标是二元的，所以我们有。我们的假设（hypothesis）有如下形式：

代价函数（cost function）如下：

在Softmax回归中，类标是大于2的，因此在我们的训练集中，。给定一个测试输入x，我们的假设应该输出一个K维的向量，向量内每个元素的值表示x属于当前类别的概率。具体地，假设形式如下：

代价函数如下：

其中是指示函数，即

既然我们说Softmax回归是逻辑回归的推广，那我们是否能够在代价函数上推导出它们的一致性呢？当然可以，于是：

可以看到，逻辑回归是softmax回归在K=2时的特例。你可能也发现了，标准的Softmax回归中，要计算y=j时的Softmax概率：，我们需要对所有的K个概率做归一化，这在很大时非常耗时。于是，分层Softmax诞生了，它的基本思想是使用树的层级结构替代扁平化的标准Softmax，使得在计算时，只需计算一条路径上的所有节点的概率值，无需在意其它的节点。

下图是一个分层Softmax示例：

树的结构是根据类标的频数构造的霍夫曼树。K个不同的类标组成所有的叶子节点，K-1个内部节点作为内部参数，从根节点到某个叶子节点经过的节点和边形成一条路径，路径长度被表示为。于是就可以被写成：

其中：表示sigmoid函数；表示n节点的左孩子；是一个特殊的函数，被定义为：；是中间节点的参数；X是Softmax层的输入。

上图中，高亮的节点和边是从根节点到的路径，路径长度，可以被表示为：

于是，从根节点走到叶子节点，实际上是在做了3次二分类的逻辑回归。通过分层的Softmax，计算复杂度一下从降低到。

N-gram

word2vec把语料库中的每个单词当成原子的，它会为每个单词生成一个向量。这忽略了单词内部的形态特征，比如：“book” 和“books”， “apple” 和“apples”，这两个例子中，两个单词都有较多公共字符，即它们的内部形态类似，但是在传统的word2vec中，这种单词内部形态信息因为它们被转换成不同的id丢失了。

为了克服这个问题，fastText使用了字符级别的n-grams来表示一个单词。对于单词“apple”，假设n的取值为3，则它的trigram有

“<ap”, “app”, “ppl”, “ple”, “le>”

其中，<表示前缀，>表示后缀。于是，我们可以用这些trigram来表示“apple”这个单词，进一步，我们可以用这5个trigram的向量叠加来表示“apple”的词向量。

这带来两点好处：

对于低频词生成的词向量效果会更好。因为它们的n-gram可以和其它词共享。
对于训练词库之外的单词，仍然可以构建它们的词向量。我们可以叠加它们的字符级n-gram向量。

fastText的优化

子空间量化

product quantization是一种保存数据间距离的压缩技术。PQ 用一个码本来近似数据，与传统的 keams 训练码本不同的是， PQ 将数据空间划分为 k 个子空间，并分别用 kmeans 学习子空间码本。数据的近似和重建均在子空间完成，最终拼接成结果。在 fasttext 中，子空间码本大小为 256，可以用 1 byte 表示。子空间的数量在 [2, d/2] 间取值。除了用 PQ 对数据进行量化压缩，fasttext 还提供了对分类系数的 PQ 量化选项。PQ 的优化能够在不影响分类其表现的情况下，将分类模型压缩为原大小的。

裁剪字典内容

fasttext 提供了一个诱导式裁剪字典的算法，保证裁剪后的字典内容覆盖了所有的文章。具体而言，fasttext 存有一个保留字典，并在线处理文章，如果新的文章没有被保留字典涵盖，则从该文章中提取一个 norm 最大的词和其子串加入字典中。字典裁剪能够有效将模型的数量减少，甚至到原有的。

FastText的使用

使用FastText训练词向量

# -*- coding: utf-8 -*-
import jieba
import os
import fasttext


def get_data():
    # 清华大学的新闻分类文本数据集下载：https://thunlp.oss-cn-qingdao.aliyuncs.com/THUCNews.zip
    data_dir = 'D:\\迅雷下载\\THUCNews\\THUCNews\\财经'

    with open("finance_news_cut.txt", "w", encoding='utf-8') as f:
        for file_name in os.listdir(data_dir):
            print(file_name)
            file_path = data_dir + os.sep + file_name
            with open(file_path, 'r', encoding='utf-8') as fr:
                text = fr.read()
                seg_text = jieba.cut(text.replace("\t", " ").replace("\n", " "))
                outline = " ".join(seg_text)
                f.write(outline)
                f.flush()


def train_model():
    model = fasttext.train_unsupervised('finance_news_cut.txt')
    model.save_model("news_fasttext.model.bin")


def test_model():
    model = fasttext.load_model('news_fasttext.model.bin')
    print(model.words)
    print(model.get_word_vector("股票"))
    print(model.get_nearest_neighbors('股票'))


if __name__ == "__main__":
    pass
    # get_data()
    # train_model()
    test_model()

备注：不要使用

pip install FastText

进行安装，否则会出现如下报错：

AttributeError: '_FastText' object has no attribute 'get_nearest_neighbors'

安装流程：

git clone https://github.com/facebookresearch/fastText.git
cd fastText
pip install .

使用FastText进行文本分类

# -*- coding: utf-8 -*-
import jieba
import os
import fasttext


def get_data():
    # 清华大学的新闻分类文本数据集下载：https://thunlp.oss-cn-qingdao.aliyuncs.com/THUCNews.zip
    data_dir = 'D:\\迅雷下载\\THUCNews\\THUCNews'

    # 生成训练数据&测试数据
    with open("news_fasttext_train.txt", "w", encoding='utf-8') as train_f, open("news_fasttext_test.txt", "w",
                                                                                 encoding='utf-8') as test_f:
        for category in os.listdir(data_dir):
            print(category)
            category_path = data_dir + os.sep + category
            count = 0
            for file_name in os.listdir(category_path):
                file_path = data_dir + os.sep + category + os.sep + file_name
                with open(file_path, 'r', encoding='utf-8') as fr:
                    count += 1
                    text = fr.read()
                    seg_text = jieba.cut(text.replace("\t", " ").replace("\n", " "))
                    outline = " ".join(seg_text)
                    outline = outline + "\t__label__" + category + "\n"
                print(count)
                if count < 10000:
                    train_f.write(outline)
                    train_f.flush()
                    continue
                elif count < 20000:
                    test_f.write(outline)
                    test_f.flush()
                    continue
                else:
                    break


def train_model():
    model = fasttext.train_supervised("news_fasttext_train.txt", label_prefix="__label__")
    model.save_model("news_fasttext.model.bin")


def test_model():
    model = fasttext.load_model('news_fasttext.model.bin')
    result = model.test("news_fasttext_test.txt")
    print('precision：', result[1])
    # fasttext只提供全部结果的p值和r值，想要统计不同分类的结果，就需要自己写代码来实现了。
    labels_right = []
    texts = []
    with open("news_fasttext_test.txt", encoding='utf-8') as fr:
        for line in fr:
            line = line.rstrip()
            labels_right.append(line.split("\t")[1].replace("__label__", ""))
            texts.append(line.split("\t")[0])
    labels_predict = [term[0] for term in model.predict(texts)[0]]  # 预测输出结果为二维形式
    text_labels = list(set(labels_right))
    text_predict_labels = list(set(labels_predict))

    A = dict.fromkeys(text_labels, 0)  # 预测正确的各个类的数目
    B = dict.fromkeys(text_labels, 0)  # 测试数据集中各个类的数目
    C = dict.fromkeys(text_predict_labels, 0)  # 预测结果中各个类的数目
    for i in range(0, len(labels_right)):
        B[labels_right[i]] += 1
        C[labels_predict[i]] += 1
        if labels_right[i] == labels_predict[i].replace('__label__', ''):
            A[labels_right[i]] += 1

    # 计算准确率，召回率，F值
    for key in B:
        try:
            r = float(A[key]) / float(B[key])
            p = float(A[key]) / float(C['__label__' + key])
            f = p * r * 2 / (p + r)
            print("%s:\t p:%f\t r:%f\t f:%f" % (key, p, r, f))
        except:
            print("error:", key, "right:", A.get(key, 0), "real:", B.get(key, 0), "predict:", C.get(key, 0))


if __name__ == "__main__":
    pass
    get_data()
    # train_model()
    # test_model()

另外，还可以使用gensim来使用FastText，如：

from gensim.models import FastText

参考链接：

The post Facebook词向量工具FastText appeared first on 标点符.

FBI希望Facebook和Twitter开发威胁预警工具

Tue, 13 Aug 2019 07:01:13 CST

PingWest品玩8月13日讯，据Gizmodo报道，美国联邦调查局（FBI）希望Facebook和Twitter等科技公司开发一种工具，可以监控其社交平台上的各种威胁。近日，FBI发布了一份“征求建议书”，称该机构希望拥有一款“社交媒体早期预警工具”，帮助他们追踪恐怖分子、犯罪组织等对平台的使用情况。

这份建议书显示，FBI计划拥有一款工具，允许所有FBI总部和外地办事处，或通过FBI发布的移动设备随时接入（这款工具），以监测这些社交平台的动态。

这款工具将允许FBI工作人员访问人们的电子邮件地址、电话号码、IP地址、用户ID和相关帐户。还允许他们创建过滤器和自定义警报，能让他们在社交媒体上发生“任务相关”活动时接收通知。

对此，Twitter发言人向Gizmodo表示，Twitter会积极配合执法部门的调查活动，但禁止将应用程序编程接口（API）用于监视用户活动。

转载：Libra：社交帝国Facebook的转型雄心

Mon, 24 Jun 2019 00:48:55 CST

Libra：社交帝国Facebook的转型雄心

原创：徐思彦，陈明艳腾讯研究院 3天前

作者| 徐思彦腾讯研究院高级研究员

陈明艳腾讯研究院助理研究员

北京时间2019年6月18日下午，全球最大社交网络平台Facebook正式发布Libra，一个为全球数十亿人提供简单无国界的数字加密货币和金融基础设施服务的区块链平台。Libra测试网已在Github上开源上线，并发布官网和白皮书，公布项目相关信息。此举在传统互联网和区块链等领域引起巨大轰动，被认为是继2008年比特币诞生以来区块链领域最重磅的事件，纷纷解读Libra的项目细节以及未来对整个区块链和全球金融体系的可能影响。

那么，为什么Facebook要如此大张旗鼓地进军加密货币领域发行Libra？Libra究竟是什么？未来又将何去何从？

一、Facebook为何要发行Libra？

作为“古典”互联网公司中第一个试水加密货币的公司，Facebook此次推出Libra的动机兼具内因和外因的推动。

从白皮书中可知，随着互联网和移动宽带的高速发展，现在几乎只要一部手机就能接触到各式各样低成本的便捷服务。然而，全球仍然有17亿人没有银行账户，无法享受金融服务而且传统的跨境转账繁琐、耗时且成本高。针对传统金融的痛点问题，Libra的诞生是为了让全球所有人，不论贫富，只要有一部智能手机，就能使用方便快捷、成本低廉且安全可靠的金融服务。

这是Facebook描绘的宏伟愿景，是其推出稳定币Libra的出发点之一，但背后仍有更复杂的原因。其中最直接的动机是丰富现有的商业模式，寻求新的增长突破。一直以来，广告收入占Facebook年营收的90%以上，这种单一的盈利模式一旦受到制约，将给Facebook带来根本威胁。尤其是去年爆发的用户隐私泄露丑闻加强了政府对用户数据保护的重视，如果提高了用户对数据的支配权，无疑大大增加了Facebook数据分析的成本，进而动摇其广告收益。

但如果只是为了寻求新的增长突破，坐拥20多亿用户的超级社交帝国可选择开拓的商业模式也很多，比如云计算、游戏、电商等更为传统的互联网商业模式。然而，Facebook选择的是加密数字货币领域里的稳定币为突破口，以Facebook、基金会其他成员以及区块链自身技术的信用作背书，重塑全球支付体系，打造无国界全球货币。

在国内，移动支付可谓家常便饭。移动支付是移动互联网时代深入发展的重要基石之一。而在美国，由于各种历史包袱，移动支付的渗透率却非常低，美国人生活中还是以信用卡和支票为主。这给了腾讯、阿里等中国互联网公司弯道超车的机会，而Libra显然给了Facebook一次弯道反超的机会。

二、Facebook为何选择稳定币？

那为什么Facebook选择的是稳定币而非其他类型的数字货币？首先，就Libra白皮书开篇想解决的跨境支付问题，目前全球的跨境支付总规模在125万亿美元，而数字加密货币有天然的优势，可以以低成本高效率且无时间地点限制的方式便捷实现，倘若Libra打通了整个流通体系，Facebook有望将手续费再将一个数量级。然而，大多数字加密货币价格波动剧烈，难以满足作为货币的稳定性要求。在Facebook之前，数字加密货币市场中也出现了不少有影响力的稳定币，例如USDT、DAI等，主要用于数字加密货币市场的入金和避险。稳定币依靠不同的“稳定机制”能增加不同程度的稳定性，进而增加其货币属性和流通性，并帮助构建商业和金融体系内的价值闭环。

目前，主要有三种“稳定机制”，从稳定币的历史市场行情来看，稳定性效果最好的是法币资产抵押模式（如USDT，GUSD和PAX等），其次是数字资产抵押模式（如DAI和BitUSD等），最差的则是仿央行调控模式（如NuBits）。Facebook此次选择的便是稳定性最好的法币资产抵押模式，但和已运行的稳定币仍有许多区别。其中最大区别是锚定对象，几乎所有采用法币资产抵押模式的稳定币都按1:1比例锚定美元，他们之间的区别主要集中在合规程度和生态应用方面，如资金托管方、银行账户审计、智能合约审计和监管机构等，但Libra显然采用了更艰难也更激进的方式——与多个主流货币（如美元、欧元和日元等）挂钩，锚定一揽子货币，在大大增加Libra稳定性的同时，无疑也增大了项目的推进阻力。

简单来说，Libra是基于区块链发行的一种货币，目前主要面向的是转账、付款和汇款市场，可以在Facebook生态体系以及Uber、Spotify等实际应用场景中流通。区别于Q币等熟悉的由公司发行的代币，Libra与现实资产挂钩的稳定币，而不是一种商品积分体系。区块链的属性把Libra的信用度进一步提高到主权货币水平，让全球结算成为可能。

三、Libra如何运转？

那么，这样一个承载Facebook重塑金融生态愿景的稳定币Libra是如何运转的呢？

“Libra分为三个部分，共同构建一个普惠金融体系：分别是安全、可拓展和可靠的Libra区块链；提供支持其内在价值的储备资产；以及负责治理并促进生态系统发展的Libra协会。”——《Libra白皮书》

Libra区块链目前是一条基于LibraBFT共识机制的联盟链，采用全新设计的编程语言“Move”实现交易逻辑和智能合约，具备吞吐量高、延迟性低、灵活性强和安全性高等特点。鉴于近几年智能合约漏洞等安全事件频发，专为数字资产交易打造的Move无疑是此次发布的一大亮点。法币因为拥有无限法偿能力，在法币上做智能合约是有风险的，而Libra本身没有这个负担。以往智能合约所承诺的类似自从发行奖金，自动还贷等功能用法币或以太坊等数字货币都难以实现。而有了抵押权益代币Libra事情就简单许多，得以实现真正的可编程的货币。除此之外，未来各种金融资产都可以数字化，从而在全球畅通流通，这个想象空间远大于今天的移动支付结算体系。如今移动支付只限于零售端的交易支付和结算，如果加上金融资产的流通和交易，Libra的体量将不可估量。

在储备资产方面，Libra采用近似等额锚定一揽子货币的方式来稳定币价，因此法币兑换通道、储备资产的配置和产生收益的分配也是大众关注的焦点。目前，在法币兑换通道方面，Libra采用授权代理商模式，即用户通过授权的交易所或其他机构买卖Libra，这个过程涉及的KYC验证、交易手续费和监管等问题尚不明确。对于用户充值的法币资产，Libra计划将其投入波动性低的资产中，如银行存款和政府证券等。为了缓解Libra价格波动的可能性和严重性，储备资产的配置倾向于违约率低的政府债券。同时在保证流动性方面，Libra计划将一部分资金用于政府发行的短期证券以满足日常交易量的需求。这种资产配置基本满足Libra求稳的需求，但已动了不少既得利益者的奶酪，是否能挺过各方利益角力而成功开展有待时间检验。当然，关于这个过程产生的收益分配，Libra在白皮书中也有相应计划——优先用于维护项目运行，剩余收益分红给早期贡献的成员和其他投资者。

作为维系整个Libra项目运转核心的Libra协会，是一家总部位于瑞士日内瓦的非营利性会员制国际性机构，其成员是Libra区块链的验证节点，通过理事会投票表决，还可控制新成员的加入、规则的制定、储备资产的管理和监管以及负责其他日常事务。

现阶段Libra协会的成员主要是来自不同领域的28家企业、非营利性组织、多边组织和学术机构，大多集中在互联网、金融和区块链领域，包括风险投资、电子商务、支付、电信和社交等行业巨头，如Mastercard、PayPal、eBay、Uber和Facebook等，成员数量未来有望拓展超100个，争取以强渗透力打通更多商业支付场景。基金会成员天然解决了Libra拉新和场景问题，而随着Libra生态的丰富，其跨国、低成本的便利性也将带来网络效应。毫无疑问，如果围绕Libra的超级商业支付生态圈一旦建立，会给现有的全球支付体系带来剧烈冲击。

随着成员的数量逐渐变多，Libra的治理机制也变得尤为重要。现阶段，每个成员（即验证节点）派一名代表加入Libra协会理事会，有一票投票权，重大决策有2/3以上的赞成票则为通过，这种管理模式在项目初期能高效快速地推动项目发展，但也容易埋下了一系列隐患。尽管Libra称未来将逐步提高去中心化程度，降低准入门槛，5年内开始逐步过渡到非许可治理模式，以提升整个生态系统的弹性，但未来能达到多大程度的去中心化且各方权益和监管如何平衡仍然有待时间验证。

四、Libra的未来会怎样？

至此，Libra的愿景是惊天动地的，但落地之路仍然充满不确定因素。从目前白皮书、官网动态以及外界表现来看，对Libra后续的发展仍然有很大担忧。

从外部因素来看，能否通过国家的监管合规要求，对Libra来说是项艰难考验。首先，数字加密货币的本质已挑战一部分禁止加密货币交易的国家的监管条例，比如中国和伊朗等。其次，Libra的发行和设计机制挑战了国家央行的最重要职能，进而动摇了各国法币的地位，尤其是货币不稳的第三世界国家。再者，目前各国监管机构表达的质疑和担忧还集中在抵押资产的可靠性、数据隐私安全性以及是否满足各国反洗钱、反恐融资等方面的需求。那么，在Libra正式落地之前，与各国监管机构之间的博弈成为Libra团队最为棘手的难题。如何在监管合规的基础上实现商业支付，如何确保用户数据不会被滥用，如何避免Libra成为洗钱等灰色地带的金融工具等问题都是Libra团队需要向监管机构和公众回答的问题。

继4个月前摩根大通宣布将发行“JPM Coin”之后，Facebook带领Libra也强势进入数字加密货币领域，顶级玩家的加入为区块链的发展打开新局面的同时也让赛道间竞争更加激烈。其他行业巨头会如何应对？是顺势加入Libra协会为其献策献力，还是另起炉灶带着新的商业模式和生态弯道超车？这些也给Libra的未来发展带来诸多不确定性。

再从内部因素来看，在治理结构方面，Libra的最终目标是过渡到非许可性治理，逐渐实现去中心化。但前期仍然是联盟链结构，为了平衡各方势力，将企业、非营利性组织、多边组织和学术机构招入其中，同时也将拜占庭容错机制的核心原理融入理事会的决策规则中，但随着Libra的体量不断扩大，涉及的范围不断拓展，面对前所未有的利益诱惑，现有成员是否愿意牺牲自身利益以达到Libra最终目标尚且未知。此外在储备资产的收益分配方面，Libra计划先将收益覆盖系统运行成本，确保低交易费，之后给早期贡献的成员和其他投资者分红，并支持后续的发展。然而，整个分配规则的制定和过程中的监管均由Libra协会负责，而协会成员大多也是早期参与的贡献者，即未来的收益获得者，这种自我监管的方式能否被大众接受也是一个未知数。

小结

种种因素使Libra的落地之路面临重重阻碍，但无论如何，Facebook推出稳定币Libra是一次大胆、开放且有意义的尝试。两年之内，Libra对Facebook自身的意义要远大于对全球货币体系的意义。它为Facebook打开了另一条商业路径，使其能切入在线支付领域，并且使其商业生态能更具网络效应。用户可以在Facebook旗下的Messenger，Instagram，Whatsapp等应用中更快、更方便地进行支付和汇款了，即使这一切对于中国用户来说已经无比熟悉。

对极客来说，Libra也许是向现实世界的妥协。但新技术从发明到大范围爆发型应用往往都是最初的变体。“谁来做”在很多情况下上比“怎么做”更重要。

Libra在白皮书里写道“在全球范围内转移资金应该像发送短信或分享照片一样轻松、划算，甚至安全。”这与比特币最初诞生的初心“一种点对点的电子现金系统”相呼应。只不过，随着时间推移，比特币的通缩属性使其成为一种数字资产，而无法实现其数字现金的目标。现在，Facebook用一种（多）中心化的方式使这个目标继续推进。在Facebook之前，不乏明星团队、学术精英和工程精英尝试过区块链项目，但离真正的爆发都欠缺了必要条件。而晚于业内到达战场的Libra由于Facebook的海量用户、跨国属性和多场景生态的基础在全世界无人出其右，具有强大的后发优势。

从长期来看，巨头入场开启了一个潘多拉的盒子，让虚拟货币成为了数字世界中不可逆的组成元素。一旦全球 Facebook 用户习惯在各种场景中使用Libra，届时人们也不再需要将 Libra 兑换成法币，也不再需要第三方资产支撑。这将为数字加密货币将真正在用户中普及铺平道路，撼动传统的货币体系。数字加密货币将真正在用户中普及，撼动传统的货币体系。这一点上，扎克伯格显示了带领巨头转身的魄力，为Facebook争取到了未来数字货币领域的一张船票，保证Facebook在未来数字经济社会依然是一个重要玩家。

不管成功与否，Libra都已经为未来的更自由、更普惠、全球化的数字货币世界铺下了第一块基石。最终由巨头搭台，多中心化支付清算网络反向推动了诞生于民间、去中心化数字加密货币的普及，并在传统的货币体系中争夺一席定价权。这也是历史一次又一次螺旋上升的有趣之处。

Facebook PM 给产品经理的5点建议

Sat, 22 Jun 2019 18:31:08 CST

萧文翔，高雄人，纽约读书，旧金山工作。目前在脸书Facebook担任产品经理，之前在Dropbox担任增长方面的资深产品经理。以下内容是针对美国软件业的产品经理描述，硬体或其他国家可能有不同的生态。

1. 产品经理在组织里的角色是什么？

简单来说，在顶尖科技公司之中，产品经理扮演着推动产品演进，负责产品从概念到上市，作为所有部门之间的中枢角色。产品经理是在组织结构中，最有 横向合作能力，与所有部门合作，包含销售、营销、产品、研发、工程、客服与财务等等。

图1. 产品经理(PM) 会跟公司多数的部门互动

产品经理职位又具有 纵向深度，订定产品策略，设定愿景与方向，决定公司存败的一大关键。这是一个既具有策略思考能力，又必须负责执行与实际营收成败的角色。

图2. 产品经理参与了制定愿景、订定策略与执行成果的过程

2. 产品经理在做什么？

根据产品的阶段，这个问题有不同的答案。从零到一的过程来讲，产品经理要经过以下过程：

挖掘产品新的商业机会，制订愿景与方向
制定Roadmap ，决定MVP 与功能的优先顺序
赢取上级长官的认同与批准，沟通并取得跨部门的认同
帮助团队执行将产品上架，进行专案管理与制定目标时程
成长产品，提升指标例如使用者数目、月活跃人数或营收

图3. 一个产品可能在任何阶段回到前面任一阶段，形成循环

在不同阶段，产品经理每天做的事情差异很大。在挖掘机会阶段，产品经理多在做研究与深度思考，与用户研究员、设计师与工程师做开放式讨论，以找出方向。

在赢取认同阶段，产品经理常在整理论述，想好与他人谈判时该如何说服，创造互利双赢的情境。他可能与资料分析人员合作，去量化一些商业机会。

在执行阶段，产品经理会帮忙跑会议、制定明确时程、沟通资源调配、决定要砍掉哪些不必要的功能，做取舍。

在成长产品阶段，产品经理要做大量A/B testing，深入了解数据，找出可能成长的方法，不断测试。

如果上面描述还是太简化，不够明确，那我们来举一个例子好了。就以广为人知的Dropbox为例，刚好我也在那任职过。今天想像你跟Drew Houston （Dropbox CEO)开会，他跟你说他希望你带领一个团队做出一个「团队档案分享工具」，身为产品经理的你第一步该做什么？你该开始 活动资源，回答以下问题：

现行的档案分享在团队里有哪些问题？
有哪些不同种类的团队？
这些团队种类与他们的使用者问题具有怎么样的商业价值？
有什么科技与商业趋势在驱动档案分享行为的改变？

以上用一个问题来概括的话就是：「现行的团队档案分享的用户与商业情况是怎么样？」

回答这个问题可以帮助找出 产品新的商业机会，并且制订愿景 ☀️ 与方向。

回到Dropbox 例子，我们可能发现的情况是

团队管理者没有办法控制每个人的帐号。
团队有分成全职员工、半职员工、约聘人员等，他们有不同的存取限制。
如果Dropbox 可以帮助团队管理者由中央控管使用者帐号，就会有更多团队愿意订阅Dropbox。
团队档案协作越来越频繁，部分因为越来越多团队散布在不同城市。还有越来越多公司聘用约聘人员，团队成员变动频繁，所以中央控管使用者帐号越来越重要。

因此新的愿景就是帮助团队管理者由中央控管使用者帐号，让管理者更容易新增、删除以及变更团队成员。

这个非常简单的例子虽然到此结束，但现实生活中产品经理的路还很长。从愿景到认同，再进入制定roadmap、执行与优化，每个阶段都考验产品经理多面向的能力。

3. 如何衡量产品经理？

…你的工作不是写出一个漂亮的策略而已，还要推动它，让每个人理解、接受与认同，并且执行、缴出成果、分析后判断是个成功，你的工作才算完成。

…产品经理必须是 推动者(enabler)，你无法自己成功，必须与所有团队的人一起成功。

在我待过的四家公司里，衡量产品经理的方式在原则上雷同，但实践上有些差异。原则上就是 「成果」与「影响力」👊。影响力是指如何对更多同事、对更多项目有更多的正面影响，让同事的工作与项目因为这个产品经理的存在而变得更容易更好。成果是指如何透过影响力，达到最佳的成果，完成目标。

你可以从上面章节看出，产品经理在不同阶段有很不一样的角色与贡献。但不管是哪个阶段，产品经理都要优化他的 「影响力」，以达到最佳的 「成果」。我认为这个衡量方式深深反应了产品经理做事的原则与处理事务的观点。

也就是说，一个产品经理不会问：「这件事情该不该是我做？」而是该问： 「我应该做哪件事情以最大化团队成果？」

图4. Servant leadership 的概念对于产品经理很受用！

以下举个例子来看看：

今天团队如果没有数据分析师，你就要适时跳下去做数据分析
今天团队如果没有设计师，你就要适时跳下去划一些mockup（然后其他设计师看不下去可能就会来帮忙了🤦‍♂️）
昨天会议记绿没有人整理，你就要适时整理
明天跟Director 开会的简报没有做，你就要推动负责人做，或者自己跳下来做
你发现很多其他团队都来问你的团队这一季要做什么，你就要适时建立team wiki page 做好沟通
你觉得团队在做的事情与愿景和策略不合，你应该要推动大家发现这件事，然后修正方向

换个方式讲，好的产品经理要努力产生乘法效应，而非只是加法效应。即使人事上而言，产品经理常常不直接管人，你不能只有独立贡献者的态度，凡事要以帮助团队为出发点。

举例而言，你的工作不是写出一个漂亮的策略而已，还要推动它，让每个人理解、接受与认同，并且执行、缴出成果、分析后判断是成功，你的工作才算完成。

什么样的事情有乘法效应呢？就是那些不只是自己适用，还可以套用到团队其他成员的事情。举例而言：

建立好的开会流程与帮助讨论流畅，你帮助了所有参与会议的人
制定明确的分工方式，让团队成员知道自己该做什么

因为专注在影响力，产品经理努力放大 组织性的杠杆作用。所谓组织性的杠杆作用，是指如何善用组织里各个部门的专长与合作关系，让其更协调运作，造成一加一等于二的效果。

对于产品经理来讲，成功必须仰赖他人，唯有帮助其他人成功，你才有成功的机会。所以产品经理必须是 推动者，你无法自己成功，必须与所有团队的人一起成功。

4. 产品经理需要具备什么能力？

一个好的产品经理对于合作的态度不会只是「一次性交易」，而是「伙伴关系」🤝。

产品经理需要很多面向的能力，在我待过的多数公司里面，都认为以下是必备能力：

跨部门协作
产品策略思考
专案执行
分析思考
谈判
技术理解
领导与鼓舞人心

依据产品在不同阶段与不同领域，产品经理需要贡献不同的能力。

就我自己经验而言，不管在任何时期，你都会需要 跨部门协作、谈判与技术理解能力。因为产品经理透过与他人协作产生影响力，进而推动成果。在协作过程中，产品经理被期待要做谈判的角色。当团队资源不足，需要调动其他团队资源时，你会是推动这个谈判进行的人。

一个好的产品经理对于合作的态度不会只是「一次性交易」，而是「伙伴关系」。坏的产品经理只是要求其他部门提供他所想要的资源，利用完后就结束关系。好的产品经理要往长线想，试着跟所有人建立「伙伴关系」，创造互利双赢机会。

产品经理也需要跟工程师紧密合作，如果没有 深刻的技术理解能力，是无法理解产品与有效作出判断的。

在产品初期，你会要多做 产品策略思考，为团队订出方向。

在执行阶段，你会参与 专案执行，有时大型公司会有一个角色是技术专案经理，这个角色被期待要能够推动大型专案，通常横跨多个营业单位。

在产品上架优化阶段，你必须有 分析思考能力，去订定指标，帮助其他人分析资料，提供洞见等。

图5.产品经理需要多面向的能力，如：跨部门协作、谈判与技术理解能力

最后是 领导与鼓舞人心的能力。这一点很有趣，因为产品经理虽然有经理头衔，但并非人事主管（除非你是一个产品经理管理其他的产品经理）。因此，产品经理必须要在没有实质人事权力之下，推动事情，影响别人的工作。

这就考验你的领导与鼓舞人心能力了，真正的领导者不应该只靠头衔，而是透过解释与沟通，推动决策，让其他人了解与认同某个决策或产品方向，进而自动自发改变自己工作内容，往同一个方向前进。

5. 你适合做产品经理吗？

这个问题只是想抛出来给读者思考，对我来讲 「适合」有两层含义：一是你是否具备这个能力，二是你是否喜欢这个角色。

产品经理是一个高压的工作，身为资讯传递的交点，你的效率会影响整个团队的进展。你虽然常与他人协作，但常常一个团队里只有一个产品经理的角色，因此你有时会有孤军奋斗的感觉。

产品经理重沟通协调，在美国做这样的角色，需要高度的语言能力以及文化适应能力。你是否愿意花时间培养这些能力，也是一个考量。

必备能力这么五花八门，你可能想，谁可以样样都精通？的确，成功的产品经理通常有他自己的超能力，也是他个人的品牌。例如一个专做机器学习相关产品的产品经理，可能技术底子非常深厚，本身是机器学习博士等。

我曾经做了三年的增长产品经理工作，特别重视数据分析能力，培养了对各种机会都会直觉地做市场大小估计。

某些产品经理是华尔街来的，他们可能就直接成为某一个金融科技商品的产品经理，因为他们很了解这个领域。领域知识成为这些人的差异化方法，他们的个人品牌。

有些人很有个人风采，讲话幽默风趣，容易成为所有人的焦点，也是一种类型的产品经理。

就我自己观察，如果你是一个凡事很有主见，很有思考框架的人，也许你会适合。或者你是一个对沟通协调很有热诚，让所有人都有最新消息，并且推动取得共识的人，也许你也会很适合。

当然，没有什么人比那种视产品经理为最大职涯目标，很笃定要成为产品经理的人还有更适合了。你的意愿程度是最大的因素。

对我而言， 产品经理最大的成就感来自于「舍我其谁的Ownership 」。产品经理负责的事情涵盖了所有产品面向，而且终极的衡量标准是产品的成功与团队的成功。在这样的职责下，自然会产生一种「我要为一切负责，舍我其谁」的责任感。这其实带来了难以抗拒的成就感，我觉得很容易让人上瘾！

Facebook开源移动端深度学习加速框架，比TensorFlow Lite快一倍

Sat, 29 Dec 2018 00:00:00 CST

方栗子发自凹非寺
量子位出品 | 公众号 QbitAI

Facebook发布了一个开源框架，叫 QNNPACK，是手机端神经网络计算的加速包。

官方表示，它可以 成倍提升神经网络的推理效率，几乎比 TensorFlow Lite快一倍。

这个框架，能够为很多运算加速，比如 DW卷积 (Depthwise Convolution) ，许多先进的架构里面都用得到。

目前，QNNPACK已经是 PyTorch 1.0的一部分，在Caffe2里就能直接使用。

其实，Facebook手机应用里面，已经部署了这个QNNPACK。也就是说，数以亿计的手机都在用了。

从哪个角度加速？

QNNPACK，这个名字眼熟么？

两年前，Facebook就推出过一个加速包，叫做 NNPACK，Caffe2Go用的就是它。

基于Winograd变换和傅里叶变换，有效减少卷积计算里的乘加运算 ( Multiply-Add) 。这样一来，3x3卷积可以只比1x1慢一倍，而不会慢8倍。

不过，世界变化很快。现在的计算机视觉 (CV) 神经网络里，用到的很多卷积类型， 已经沾不到NNPACK的光：

比如，1x1卷积，分组卷积 (Grouped Convolution) ，Strided Convolution，扩张卷积 (Dilated Convolution) ，DW卷积 (DepthWise Convolution) ，适用于精度/存储带宽受到限制的 (移动端等) 场景。

而CV神经网络，大部分推理时间，都花在卷积和全连接运算上。

这样的运算，和 矩阵乘法密切相关：

大内核的卷积，可以分解成im2col和一个矩阵乘法。

所以，有高效的矩阵乘法，才能有高效的卷积网络。

于是，QNNPACK出世了。

怎样加速矩阵乘法？

矩阵乘法，A x B = C。C里面的每一个元素，都可以看成 A中某行和 B中某列的点乘。

但直接在点乘基础上计算的话，一点也不快，会受到存储带宽的限制。

如果，能同时计算 A中多行和 B中多列的点乘，即 MRxNR，就能给运算速度带来猛烈的提升。

不需要太多，这样细小的改变就够了。

节省内存和缓存

模型训练，可能更需要高精度。但在训练完成后，推理部分对精度的需求可能就没有那么高了。

低精度的计算，有时对推理的 准确性不会产生明显的影响。

而这样的运算，不需要太大存储，并节省能源，有助于把AI部署在移动端。

QNNPACK用的线性量化 (Linear Quantization) 方案，与安卓的神经网络API兼容。

它假设量化值q[i]是用8比特的无符号整数 (Unsigned Integers) 来表示的，以及q[i]与真实值r[i]相关，关系如下：

与其他库不同，QNNPACK把矩阵A、B都放进一级缓存 (L1 Cache) ，目标是把所有对运算过程并不非常必要的内存转换 (Memory Transformations) 都删掉。

QNNPACK可以在一次微内核调用 (Microkernel Call) 里，处理A和B。

不需要在微内核之外，累积32位的中间结果，QNNPACK把32位的中间值融合进微内核，然后写出8位值，节省了存储带宽和缓存。

赢了TensorFlow Lite

开发团队用谷歌的视觉框架MobileNetV2里面的 图像分类模型来测试。

拿 TensorFlow Lite做对手，和 QNNPACK比了一场。

结果是，QNNPACK比TensorFlow Lite几乎快一倍，不论是在高端智能机，还是普通智能机身上。

所以，各位也去试一下？

GitHub项目页：
https://github.com/pytorch/QNNPACK

博客原文：
https://code.fb.com/ml-applications/qnnpack/

— 完—

加入社群

量子位AI社群开始招募啦，欢迎对AI感兴趣的同学，在量子位公众号（QbitAI）对话界面回复关键字“交流群”，获取入群方式；

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

进专业群请在量子位公众号（QbitAI）对话界面回复关键字“专业群”，获取入群方式。（专业群审核较严，敬请谅解）

活动策划招聘

量子位正在招聘活动策划，将负责不同领域维度的线上线下相关活动策划、执行。欢迎聪明靠谱的小伙伴加入，并希望你能有一些活动策划或运营的相关经验。相关细节，请在量子位公众号(QbitAI)对话界面，回复“招聘”两个字。

量子位 QbitAI · 头条号签约作者

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

Facebook 开源首个全卷积语音识别工具包 wav2letter++

Wed, 26 Dec 2018 18:04:00 CST

雷锋网 AI 科技评论按：近日，Facebook 人工智能研究院 ( FAIR ) 宣布开源首个全卷积语音识别工具包 wav2letter++。系统基于全卷积方法进行语音识别，训练语音识别端到端神经网络的速度是其他框架的 2 倍多。他们在博客中对此次开源进行了详细介绍。

由于端到端语音识别技术能够轻易扩展至多种语言，同时能在多变的环境下保证识别质量，因此被普遍认为是一种高效且稳定的语音识别技术。虽说递归卷积神经网络在处理具有远程依赖性的建模任务上很占优势，如语言建模、机器翻译和语音合成等，然而在端到端语音识别任务上，循环架构才是业内的主流。

有鉴于此，Facebook 人工智能研究院 (FAIR) 的语音小组上周推出首个全卷积语音识别系统，该系统完全由卷积层组成，取消了特征提取步骤，仅凭端到端训练对音频波形中的转录文字进行预测，再通过外部卷积语言模型对文字进行解码。随后 Facebook 宣布开源 wav2letter ++——这种高性能框架的出现，让端到端语音识别技术得以实现快速迭代，为技术将来的优化工作和模型调优打下夯实的基础。

与 wav2letter++ 一同宣布开源的，还有机器学习库 Flashlight。Flashlight 是建立在 C++基础之上的机器学习库，使用了 ArrayFire 张量库，并以 C++进行实时编译，目标是最大化 CPU 与 GPU 后端的效率和规模，而 wave2letter ++工具包建立在 Flashlight 基础上，同样使用 C++进行编写，以 ArrayFire 作为张量库。

这里着重介绍一下 ArrayFire，它可以在 CUDA GPU 和 CPU 支持的多种后端上被执行，支持多种音频文件格式（如 wav、flac 等），此外还支持多种功能类型，其中包括原始音频、线性缩放功率谱、log 梅尔谱 (MFSC) 和 MFCCs 等。

Github 开源地址：

https://github.com/facebookresearch/wav2letter/

在 Facebook 对外发布论文中，wav2letter++被拿来与其他主流开源语音识别系统进行对比，发现 wav2letter++训练语音识别端到端神经网络速度是其他框架的 2 倍还多。其使用了 1 亿个参数的模型测试，使用从 1~64 个 GPU，且训练时间是线性变化的。

图片来源：Facebook

上面为系统的网络结构图，主要由 4 个部分组成：

可学习前端（Learnable front end）：这部分包含宽度为 2 的卷积（用于模拟预加重流程）和宽度为 25 ms 的复卷积。在计算完平方模数后，由低通滤波器和步长执行抽取任务。最后应用于 log-compression 和 per-channel mean-variance normalization 上。

声学模型：这是一款带有门线性单元（GLU）的卷积神经网络，负责处理可学习前端的输出内容。基于自动分割准则，该模型在字母预测任务上进行训练。

语言模型：该卷积语言模型一共包含 14 个卷积残差块，并将门线性单元作为激活函数，主要用来对集束搜索解码器中语言模型的预备转录内容进行评分。

集束搜索解码器（Beam-search decoder）：根据声学模型的输出内容生成词序列。

想深入了解系统背后运作原理感的同学，可以自行查阅完整内容：

https://arxiv.org/abs/1812.07625

wav2letter++: The Fastest Open-source Speech Recognition System

via https://opensource.fb.com/

雷锋网 AI 科技评论雷锋网

Facebook 发布无梯度优化开源工具 Nevergrad

Sun, 23 Dec 2018 10:07:13 CST

大多数机器学习任务——从自然语言处理、图像分类到翻译以及大量其他任务，都依赖于无梯度优化来调整模型中的参数和/或超参数。为了使得参数/超参数的调整更快、更简单，Facebook 创建了一个名叫 Nevergrad（ https://github.com/facebookresearch/nevergrad）的 Python 3 库，并将它开源发布。Nevergrad 提供了许多不依赖梯度计算的优化算法，并将其呈现在标准的问答 Python 框架中。此外，Nevergrad 还包括了测试和评估工具。

Nevergrad 现已对外开放，人工智能研究者和其他无梯度优化相关工作者马上就可以利用它来协助自己的工作。这一平台不仅能够让他们实现最先进的算法和方法，能够比较它们在不同设置中的表现，还将帮助机器学习科学家为特定的使用实例找到最佳优化器。在 Facebook 人工智能研究院（FAIR），研究者正将 Nevergrad 应用于强化学习、图像生成以及其他领域的各类项目中，例如，它可以代替参数扫描来帮助更好地调优机器学习模型。

这个库包含了各种不同的优化器，例如：

差分进化算法（Differential evolution）

序列二次规划（Sequential quadratic programming）

FastGA

协方差矩阵自适应（Covariance matrix adaptation）

噪声管理的总体控制方法（Population control methods for noise management）

粒子群优化算法（Particle swarm optimization）

在此之前，使用这些算法往往需要研究者自己编写算法的实现，这就让他们很难在各种不同的最新方法之间进行比较，有时候甚至完全无法比较。现在，AI 开发者通过使用 Nevergrad，可以轻易地在特定的机器学习问题上对不同方法进行测试，然后对结果进行比较。或者，他们也可以使用众所周知的基准来评估——与当前最先进的方法相比，新的无梯度优化方法怎么样。

Nevergrad 中所包含的无梯度优化方法可用于各类机器学习问题，例如：

多模态问题，比如说拥有多个局部极小值的问题。（如用于语言建模的深度学习超参数化。）

病态问题，通常在优化多个具有完全不同的动态特性的变量的时候，该问题就会出现（如，未对特定问题进行调整的丢弃和学习率）。

可分离或旋转问题，其中包括部分旋转问题。

部分可分离问题，可以考虑通过几个变量块来解决这类问题。示例包括深度学习或其他设计形式的架构搜索，以及多任务网络的参数化。

离散的、连续的或混合的问题。这些问题可以包括电力系统（因为有些发电站具有可调连续输出，而其他发电站则具有连续或半连续输出）或者要求同时选择每层的学习速率、权值衰减以及非线性类型的神经网络任务。

有噪声的问题，即针对这一问题，函数被完全相同的参数调用时可以返回不同结果，例如强化学习中的不同关卡。

在机器学习中，Nevergrad 可用于调整参数，例如学习率、动量、权值衰减（或许每一层）、dropout（丢弃）算法、深度网络每个部分的层参数及其他等。更为普遍地，非梯度方法同样被用于电网管理（ https://www.sciencedirect.com/science/article/pii/S0142061597000409）、航空（https://www.sciencedirect.com/science/article/pii/S0142061597000409）、镜头设计（https://www.researchgate.net/publication/222434804_Human-competitive_lens_system_design_with_evolution_strategies）以及许多其他的科学和工程应用中。

为什么有无梯度优化的需求

在某些场景中，例如在神经网络权重优化中，以分析法去计算函数的梯度是简单的。然而，在其他场景中，例如当计算函数 f 的速度慢，或者域不连续的时候，函数的梯度就无法预估出来。在这些应用实例中，无梯度方法提供了解决方案。

一个简单的无梯度解决方案是随机搜索，它由随机采样大量的搜索点、对每个搜索点进行评估、选择最佳搜索点三个步骤组成。随机搜索在许多简单场景中表现很好，但在高维场景中却表现不佳。通常被用于机器学习参数调整的网格搜索，也面临类似的限制。不过，也还有许多替代方法：其中一些来自应用数学，如序列二次规划，它对模拟器的二次近似进行更新；贝叶斯优化也建立目标函数模型，其中包括不确定性模型；进化计算包含大量关于选择、变异以及混合有前景的变体的工作。

这个示例展示了进化算法如何运行。在函数空间中采样搜索点，并选择最佳点的群落，然后在已有点的周围推荐出新的点来尝试优化当前的点群落。

使用 Nevergrad 生成算法基准

Facebook 研究团队使用了 Nevergrad 实现几个基准测试，来展示特定算法在特定情况下的表现最佳。这些众所周知的示例对应着各种不同设置（多峰或非多峰，噪声或非噪声，离散或非离散，病态或非病态），并展示了如何使用 Nevergrad 来确定最佳优化算法。

在每个基准测试中，Facebook 研究团队对不同的 X 值进行了独立实验。这确保了在几个 X 值上的各个方法之间的一致排序在统计上是显著的。除了下面的两个基准示例，这里（ https://github.com/facebookresearch/nevergrad/blob/master/docs/benchmarks.md）还有一份更全面的清单，并附上了如何使用简单的命令行重新运行这些基准的指南。

这个图展示了一个噪声优化示例

这个示例展示了使用 pcCMSA-ES 噪声管理原理（ https://homepages.fhv.at/hgb/New-Papers/PPSN16_HB16.pdf）的 TBPSA 如何在表现上胜过几种替代方案。Facebook 研究团队在这里只将 TBPSA 与算法的一个有限示例进行了对比，不过，比起其他的方法，它的表现同样更好。

Nevergrad 平台还可以执行在很多机器学习场景中都会出现的离散目标函数。这些场景包括，举例来说，在一组有限的选项中进行选择（例如神经网络中的激活函数）和在层的各个类型中进行选择（例如，决定在网络中的某些位置是否需要跳过连接）。

现有的替代平台（Bbob 和 Cutest）并不包含任何离散的基准。Nevergrad 可以执行经过 softmax 函数（将离散问题转换成有噪声的连续问题）或连续变量离散化进行处理了的离散域。

Facebook 研究团队注意到在这个场景中，FastGA（ https://arxiv.org/abs/1703.03334）的表现最好。DoubleFastGA 对应的是 1/dim 和 (dim-1)/dim 之间的突变率，而不对应 1/dim 和 1/2。这是因为原始范围对应于二进制域，而在这里，他们考虑的是任意域。在几种场景中，简单一致的突变率混合（ https://arxiv.org/abs/1606.05551）表现良好。

为研究者和机器学习科学家扩展工具箱

Faacebook 将会持续为 Nevergrad 增加功能，从而帮助研究者创建和评估新算法。最初的版本拥有基本的人工测试功能，不过 Facebook 计划为其增加更多功能，其中包括表示物理模型的功能。在应用方面，他们将继续让 Nevergrad 变得更易用，并尝试用它来对无法很好地确定梯度的 PyTorch 增强学习模型中的参数进行优化。Nevergrad 还可以帮助 A/B 测试以及作业调度等其他任务进行参数扫描。

本文转载自雷锋网： https://www.leiphone.com/news/201812/rgkaTCByuAG1lGiK.html

作者：丛末

原标题：Facebook 发布无梯度优化开源工具 Nevergrad，可应用于各类机器学习问题

微软，Facebook上班是不是工资高还一天特闲？

Sat, 08 Dec 2018 00:00:00 CST

两个都呆过，有资格说吧。

总体答案：微软相对闲，FB相对忙，跟国内比应该都是偏轻松。但是具体情况也都决定于：（1）组；（2）个人；（3）产品。

先说微软。微软打酱油的组很多，因为微软太大了，利润也很高，企业又臃肿，所以酱油组的确舒服。举例：当时有人转组到我们这里，因为之前的组实在太闲了，老板1:1常年取消，偶尔来一次也都在谈滑雪等娱乐，老板最怕他问职业发展和技术问题。

但微软忙组也很多。我当时在的组就比较忙，还经常加班。其实这也是个“幸存者偏差”：忙的不会上知乎，上知乎的一般都是不忙的，所以大家看到的都是不忙的，会以为整体不忙。

比如轮子哥等可能是不换组，所以一天的活也许一个小时就能干完。要知道新工程师一年，老工程师3-6个月，基本上能了解大部分组内的东西，所以一旦干久了比如2年以上，东西都熟得要命，尤其要是这部分还是自己写的，找什么文件直接function name都记得，噼里啪啦几个字母一个search直接找到要改的位置，新人看傻了，从问问题到找到要改的代码不超过10秒，亲身经历。

也看个人追求和产品。比如你在微软想跳槽，那就不闲了，光刷题得累半死吧，亲身经历上班人感觉都是飘着的；有些人不跳槽，在外边接私活、卖房子、偷偷创业，自然上班也不会太闲，因为时间少啊得赶紧干活。每个产品release周期不一样，release前忙成狗，release后闲成看门狗。online的部分始终在开发，还有oncall，所以其实跟其他主流互联网FLAG他们没太大区别。

此外，微软的组织是传统企业型的，各个组较为孤立。好处是范围明确，互相不干扰、可以研究得很深入；坏处是个人成长到一定阶段就停止成长了，反正组里的东西都会了，剩下的主要是政治和情商了。

而且，美国的普遍趋势是Lead/Manager比较忙，因为需要大量与人打交道的工作；码农只领稀饭钱，也就肯干工程师的活，不需要太多跟人打交道，所以根本不累。

再说Facebook。Facebook比微软整体上累很多。

但也分组，我现在所在的组不忙。但比如跟revenue相关的组、Ads相关的组就忙成狗。加班能加出抑郁症，里面人才无数。Facebook主要是自治程度比较高，就是说得自己找活，自己负责，自己找解决方案，自己推销，这样下来其实挺累的，因为各个方面都要兼顾到，再加上oncall以及随时随地看手机的公司文化，当然个人成长也快。

所以Facebook的感觉的确是累和压力大，但是是另一种舒服：成长性好，前景光明，人际关系简单，可以集中精力做东西学习等。FB出去的一般很多startup也较为喜欢，因为人原话：“Google出来的都有混的，但FB纯混是不行的。”

FB也开人，但也没那么恐怖。毕竟刷过题的、能过面试的一般不会实力太弱，还是能生存下来的；有时候是态度问题或是倒霉背锅，就再刷题走人呗，也没什么大不了。

Facebook转组容易，又有很多成长机会，就看你个人愿意利用这些时间上知乎还是去学习了。又是一个幸存者偏差。

最后的最后，上知乎不意味着闲着。码工有不少碎片时间。比如微软做desktop的，编译一下至少30-60秒，这时间很短，但够在知乎上写一条短的了，或是看一个长回答。轮子哥的回答都特别短，明显是碎片时间积累的，有人闲得慌可以写个script扫、分析轮子哥的发帖时间和长度，估计能看出轮子哥什么时候在工作干活。

这种看似“不干正事”其实反而提高码工的效率。行话叫做“Context Switch”，换一个主题，其实休息了脑子，毕竟码工长期高效率用脑，一天下来很累。用那么30秒-5分钟休息一下，只有好处没坏处。

在芝加哥接触过Trading Company，他们的Trader六个屏幕，有的人有一个屏幕专门放弱智动画片，就是减压、增效、放松。

有人可能说为什么这么多打酱油的、不玩命的，赚钱却不比国内少并且公司技术还很好？我觉得FB、微软牛，不是因为跟着喝汤的普通小码工厉害，而是里面有一批中高层（FB 6级以上、微软Principle以上）的技术天才和技术痴，这些人不上知乎，不愁吃穿，但就是真爱软件这行，我见过一天工作12小时的，是真感兴趣没人逼迫。他们一个决定、一个框架，解决很多很多问题，所以其实就是一只威猛的狮子带领一群懒洋洋的绵羊。

但也别小看这些懒洋洋的绵羊，毕竟听话，忠诚，素质也不错，帮着狮子摇旗呐喊出工出力壮声势，有些绵羊能成长为下一代的狮子，大多数绵羊碌碌无为。Google招人很喜欢懒但是强的绵羊，招进来养着，某种意义上防止这些强绵羊因为生计问题被社会逼迫成为狼甚至狮子，最后开发出各种神奇的新东西跟Google过不去。

工作几年能看出来，程序员这行蛮看passion（热情）的：比如在下，为了生计改行计算机，认真学习工作，能当合格甚至优秀的码工，但是想成为狮子却是路漫漫甚至不可能，也因为资质问题。

好在，我帝生活水平较高，普通程序员也能过上有房有车有旅行的不错生活，不享受干嘛。我上知乎最大的感受就是国内太拼了、太狠了，我的直觉一直以为华为本科毕业生起薪就得70万+一年，否则谁肯那么干活。

facebook-faiss库 - YiLiang - CSDN博客

Fri, 12 Oct 2018 10:59:12 CST

三月初，Facebook AI Research（FAIR）开源了一个名为 Faiss 的库，Faiss 主要用于有效的相似性搜索（Similarity Search）和稠密矢量聚类（Clustering of dense vectors），包含了在任何大小的矢量集合里进行搜索的算法。Faiss 上矢量集合的大小甚至可以大到装不进 RAM。这个库基本上是用 C++ 实现的，带有可选的通过 CUDA 提供的 GPU 支持，以及一个可选的 Python 接口。

通过 Faiss 进行相似性搜索时，10 亿图像数据库上的一次查询仅耗时 17.7 微秒，速度较之前提升了 8.5 倍，且准确度也有所提升。

除图片检索外，相似性搜索还有更广阔的运用场景。例如，通过搜索数据库来判断某一罪行是否属于较严重的犯罪形式，或有重罪趋势；通过搜索和成功店铺所在地相似的人口特征和环境特征，来寻找零售商新店的最佳位置；通过相似城市的搜索，来衡量所在城市薪资水平是否合理等。

日前，Facebook 发布了一份关于 Faiss 原理的介绍，36氪对此进行了编译和整理，具体内容如下：

关于相似性搜索

传统的数据库由包含符号信息的结构化表格组成。举例来说，一个图片集合的呈现方式是一个列表，这个列表的每一行都有一张索引照片，同时包含图像标识、描述语句等信息。每一行的信息也可以连接其他表格，如一张包含人物的照片可以连接到姓名表上。

大部分 AI 工具都会生成高维矢量，如以 word2vec 为代表的文字嵌入工具，和用于深度学习训练的 CNN 描述符（Convolutional Neural Net）等。在这篇文章中，我们将阐述为什么高维矢量数据比固定符号数据更强大且灵活。不过，使用 SQL 查询的传统数据库并不适用这些新型表述方式：首先，海量的多媒体信息流创造了数十亿矢量；其次，更重要的一点是，找到类似的条目意味着要找到类似的高维矢量，这对标准的查询语言来说是极其低效甚至是不可能的。

如何应用矢量表述？

让我们假设你现在有一张建筑的照片，这个建筑是某个中型城市的市政府，但你已经记不清名字了，然后你想在整个图片集合中找到这个建筑的其他所有照片。这种情况下使用传统的 SQL 语句来完成关键字查询是不可能的，因为你已经忘记了这个城市的名字。

相似性搜索此刻却能派上用场，图片的矢量描述是为了针对相似图片制造出相似的矢量，这些矢量被定义为临近欧几里得空间的向量。

矢量描述的另一个应用是分类。假设你需要一个分类器来判定一个图像集合中哪些图片代表的是小雏菊。分类器的训练是一个比较知名的过程：该算法会输入雏菊图像和非雏菊图像（如汽车、绵羊、玫瑰、向日葵等）。如果分类器是线性的，则会输出一个分类矢量，

所以，针对相似性搜索和分类，我们需要进行如下操作：

给定一个查询矢量，回到欧几里德空间中最接近这个矢量的数据库对象列表。
给定一个查询矢量，回到有最高向量点积德数据库对象列表。

有一个挑战是，我们希望这些操作可以以数十亿矢量的规模来运行。

软件包

目前投入应用的软件工具还不足以支持上述数据研究的进行。传统的 SQL 数据库系统不切实际，因为它们是针对 hash-based searches 或 1D interval searches 而优化的。相似性搜索功能在 OpenCV 这类工具包中受到的扩展性限制较大，一些针对“小”数据集（比如仅 100 万个矢量）的相似性搜索算法库也是如此。

Faiss 是一个打破了以上提到的所有限制的算法库，其优点有：

Faiss 提供了多种相似性搜索方法，可以针对不同的使用方法，进行跨度较大的功能取舍。
Faiss 针对内存使用和速度进行了优化。
Faiss 为最相关的索引方法提供了先进的 GPU 实现方案。

评估相似性搜索

一旦矢量被学习机器提取（从图像、视频、文档等），就可以被输入到相似性搜索库中。

我们拥有一个作为参考的暴力算法，能精确而详尽地计算出所有相似性，并且返回到最相似的元素列表中。这提供了一个“黄金标准”参考结果列表。但值得注意的是，高效实施暴力算法并不容易，并且暴力算法经常会影响到系统其他组件的效果。

如果我们愿意牺牲一部分精确度，相似性搜索的速度可以提高几个数量级，但是会偏离参考结果。例如，将图像相似性搜索的第一和第二个结果交换，可能没有什么太大影响，因为它们都是给定查询的正确结果。加速搜索涉及一些数据集合的预处理，我们将这项操作称之为“索引”。

这使我们确定了三个感兴趣的研究指标：

速度

在整个数据库中寻找 10 个（或其他数字）最相近的矢量需要花费多长时间？最好的情况是比暴力算法耗时短，否则索引就没有任何意义了。

内存用量

这个方法需要多少 RAM？比传统矢量多还是少？Faiss 仅支持在 RAM 搜索，因为磁盘数据库的数量级要慢一些，即使是 SSD。

准确度

返回的结果列表和暴力搜索结果的匹配度如何？准确度可以通过对结果列表中优先返回最邻近单位的检索数量进行评估，或者是通过衡量 10 个最先返回的最邻近单位的平均分数来评估（这种方法被称为“10－intersection”）。

我们通常会评估固定内存使用速度和精度之间的关联。Faiss 采用的是压缩原始矢量的方法，因为这是扩展到十亿级矢量数据库的唯一方法：以每个矢量占用 32 字节计，当规模达到 10 亿矢量后，这些矢量会占据大量的存储空间。

大部分索引库包含约 100 万个矢量，我们认为这个规模很小。比如说， nmslib 拥有非常有效的算法，速度比 Faiss 快，但同时需要更多的存储空间。

评估十亿个矢量

工程界中对于这种规模的数据集并没有一个完善的标准，我们比较了一些研究结果，并进行评估。

Deep1B 是一个有 10 亿张照片的图像库，我们在这上面评估精度。每张照片都被卷积神经网络（CNN）处理过，且 CNN 中的一个激活图（activation map）会被当作图像描述符（descriptor）。这些矢量可以和欧氏距离进行比较，以量化图像之间的相似度。

Deep1B 有一个小的图像检索库，且处理了这些图像的暴力算法提供了一个真实的相似性搜索结果。因此，如果我们运行搜索算法，我们可以评估结果中的 1-recall@1。

选择索引

为了评估，我们把内存空间大小限定为 30GB RAM。这个内存空间约束我们选择索引方法和参数。在 Faiss 中，索引方法具体表现为一个字符串，如：OPQ20_80,IMI2x14,PQ20。

这个字符串指示了用于矢量预处理的具体步骤（OPQ20_80），一个指示数据库应该如何被分割的选择机制（IMI2x14），以及一个指示产品量化编码矢量的编码组件（PQ20），这个编码组件会产生成 20 字节的代码。因此，内存使用（包括间接使用）低于 30 GB RAM。

我们知道这听起来有点“太技术”，因此 Faiss 的开发文件会提供相应的指导，即如何根据你的需求来提供最合适的索引类型。

一旦确定了索引类型，检索就开始了。这个算法会处理 10 亿个矢量，并将这些矢量置于所一个索引中。索引可以存储在磁盘上，或者立即使用，同时索引中的搜索、添加/删除可以交叉输入。

在索引中检索

索引就绪后，可以设置一组搜索事件参数来调整检索方法。为了评估，我们使用单线程进行搜索。由于内存使用量已经被固定，我们需要优化精确度和搜索时间之间的权衡。这也意味着，我们要能在尽可能少的时间内，使 1-recall@1 达到 40%。

幸好，Faiss 有一个自动调节机制，可以扫描参数空间，并收集提供最佳操作点的空间，也就是在给定精度的情况下最好的潜在搜索时间，反之亦然。在 Deep1B 中，操作点可以进行可视化，如下图所示：

在这个量化表中，我们可以看到，使 1-recall@1 达到 40％的查询时间少于 2 微秒/矢量，或者将时间限定为 0.5 微秒，我们可以达到 30%。2 微秒的检索时间意味着在一个单核上每秒查询 500 次（500 QPS）。

这个结果可以和这个领域中最先进的研究结果进行比较。Babenko 和 Lempitsky 于 2016 年撰写了一篇名为 “ Efficient Indexing of Billion-Scale Datasets of Deep Descriptors” 的论文，论文中提到，使用 Deep1B 时，他们需要花费 20 微秒来使 1-recall@1 达到 45%。

用 GPU（图形处理器）处理十亿级数据集

许多的研究都在致力于 GPU 的实施，在原生多 GPU 的支持下，产生了令人惊讶的单机性能。GPU 的实施可以看作是对应 CPU 的替代，使用 GPU 时你甚至不需要知道 CUDA API。Faiss 支持所有 2012 年后发布的英伟达 GPU（开普勒，计算能力 3.5+）。

我们希望将 roofline model 作为指导，它指出，开发者应尽可能让内存带宽或浮点单位饱和。Faiss GPU 在单个 GPU 上的速度比相应的 Faiss CPU 快 5－10倍。如果是使用新的帕斯卡级硬件，如英伟达 P100，那么速度会快 20 倍以上。

以下是一些性能方面的数字：

通过相似索引，可以在 35 分钟内（包括索引构建时间），在四路 Maxwell Titan X GPU 上构建一个简单的 k-nearest-neighbor 图（k=10），基于 YFCC100M 数据集合 9500 万图像的 128D CNN 描述符，以及 0.8 的10-intersection。
十亿矢量的 k-nearest-neighbor 图也已实现。开发者可以在 Deep1B 数据集上创建强力的 k-nearest-neighbor 图（k=10），0.65 的 10-intersection 在四路 Maxwell Titan X GPU 下需要 12 个小时。而 0.8 的 10-intersection 在八路帕斯卡 P100-PCle GPU 上也需要 12 个小时。画质较低的图可以在五小时内通过 Titan X 生成。
其他方面的性能也非常惊人。例如，构建上述 Deep1B 索引需要用 k-means 聚类生成 262,144 个几何中心和 6710 万 120-dim 矢量。在 25 E－M 次迭代下，四路 Titan X GPU（12.6 tflp/s）需要花 139 分钟处理，八路帕斯卡 P100 GPU（40 tflop/s）则需花 43.8 分钟。要注意的是聚类的训练集并不需要和 GPU 显存匹配，因为数据会按需及时导入到 GPU 中，不会影响性能。

其他技术

基于诸多研究成果和大量工程技术，Facebook AI Research 团队自 2015 年开始研发 Faiss。针对 Faiss， Facebook 选择优化几项基础技术，尤其是在 CPU 方面，Facebook 大量运用了如下技术：

多线程充分利用多核性能，并在多路 GPU 上进行并行搜索；
运用 matrix/matrix 乘法在 BLAS 算法库中进行高效、精确的距离计算。如果没有 BLAS，高效的暴力算法很难呈现最优效果。BLAS/LAPACK 是 Faiss 必备的前提软件；
机器 SIMD 矢量化和 popcount 被用于加速孤立向量的距离计算。

GPU 方面

由于典型的 CPU 算法（如 heap selection）并不适用于 GPU，此前应用在相似性搜索上的 GPU 和 k-selection（寻找 k-minimum 或 k-maximum 因素）一直存在性能方面的问题。对 Faiss GPU 来说，我们设计了文献记载中已知的最快的小 k-selection 算法（k<=1024）。所有的中间状态都被保存在寄存器中，这样有助于提升其速度。它能将输入的数据以 single pass 的方式进行 k-select，运行潜在峰值性能的 55%，这取决于峰值 GPU 的显存带宽。由于其状态仅保留在寄存器文件中，并且能和其他内核一起使用，从而能进行快速准确的相似搜索算法。

研究领域中，许多人把注意力放在高效的平铺策略和面向相似性搜索的内核执行上。Multi-GPU 支持由分片或复制数据来提供，开发者不会受到单 GPU 显存大小的限制。半精度浮点支持（float 16）也有提供，使得开发者可以在支持的 GPU 上进行完整的 float 16 运算。float 16 这样的编码矢量能在几乎不损失精度的情况下提高速度。

总之，连续不断的超量因素在实施中非常重要，Faiss 做了许多关注工程细节的痛苦的工作。

Faiss上手

Faiss 以 C++ 实现，支持 Python。想要上手，需要从 GitHub 上获取 Faiss，编译后将 Faiss 模块导入到 Python 中。Faiss 与 numpy 完全集成，所有的函数都是用 numpy 数组来实现的（in float32）

Facebook 的 NewsFeed 之死：所有社交媒体都逃不脱的宿命？ | 人人都是产品经理

Thu, 09 Aug 2018 22:49:05 CST

编者按：每一个经常使用社交媒体（Facebook）的人都会发现，当好友达到一定程度之后，NewsFeed（在国内，可以看做是微信朋友圈）就会爆炸。爆炸之后，该怎么做呢？Facebook的做法是让算法帮你“打理”NewsFeed，这背后存在什么问题？会有什么影响？著名分析师Benedict Evans在最近的博客文章中讨论了关于NewsFeed的话题，并从NewsFeed背后的转变谈到了社交应用的发展历程。

在我结婚的时候，我未婚妻和我都非常确定我们将会有一个漂亮的、安静的婚礼——而不是一个大型的、奢侈的有数百人参加的派对。我们只邀请了亲密的家人和朋友。然后，我们列出了一份关于“亲密的家人和朋友”的名单……随后便意识到为什么人们的婚礼上会出现100或200人了。因为，你认识的人比你想象的要多得多。

之所以会想到这一点，是因为Facebook给出的一个说法：平均下来，每个用户每天至少能够从他们的NewsFeed中看到1500条内容。就像200人的婚礼一样，这看起来很荒谬。但事实证明，在过去的几年里，你会增加200到300个好友。如果你已经添加了300个好友，并且他们每个人每天都会发一些照片，看一些新闻报道，或者发表几次评论。那么，根据乘法法则，你的NewsFeed中每天都会出现超过1000个新的内容。

这是两个因素的结合——邓巴数字(Dunbar’s number，一个经验法则，意味着你可能已经认识了几百人，并在Facebook上认识他们)和“扎克伯格定律”(Zuckerberg’s law，随着时间的推移，人们会倾向于在社交媒体上分享越来越多的信息)。把这两者结合起来，你就会变得超负荷。

更进一步说，在我看来，扎克伯格定律实际上是关于社交媒体平台不断演变的关注者模式的一种观察，在这种模式下，分享某样东西到你自己的Feed中，并不等于把它发送给任何特定的人。你不会经常把关于你的孩子或狗的10张照片发给你通讯录中的每个人。同样，大多数人( 50岁以下)也不会把他们看到的每一篇有趣或让人愤怒的新闻报道发给他们通讯录中的每个人。但是，这种不对称的Feed会使这些内容的发布变得正常，而不是粗鲁无礼。因为你把它发布到了“你的”Feed中，而不是明确地发送给某个人，所以发布大量的内容和不太重要的东西是可以的。反过来，这又把我们带到了公地悲剧中——我们当然可以发布内容，但通过发布内容，我们会使彼此的Feed变得超负荷。Facebook的成长团队在这方面做得太好了。

Facebook有50％工程工作，都是努力把更多噪音加到NewsFeed中，其余的50%用于设计筛选机制。

——本尼迪克特·埃文斯（@ BenedictEvans）2013年3月7日

这种超负荷意味着，现在要求按时间顺序对NewsFeed进行排序是没有意义的。如果你的NewsFeed中每天会产生1500或3000条内容，按时间顺序对Feed进行排序，实际上就是放弃之前可以浏览的内容了。除非你的朋友在最后一个小时发布了这些内容，否则这些内容根本没有任何逻辑顺序。与其说这是按时间顺序排列的，不如说它是随机抽样的。在随机抽样中，随机生成器只是你自己打开应用程序的时间。在过去的5年里，我交的300个人中，有哪一个人在16 : 32到17 : 03之间发了内容？与此同时，给我们比较详细的手动控制和过滤器页没有多大意义——整个科技行业的历史告诉我们，普通人永远不会使用它们，即使它们有用。

从而，这导致Facebook不可阻挡地走向了“算法Feed”的逻辑。这实际上只是技术术语——用算法来找出你最想从哪些人那里看到东西，以及你最想看到什么样的东西，然后将这些内容排序，在你的NewsFeed中呈现出来，而不是按照发布时间（随机）进行排序。它应该能够确定你的亲密朋友是谁，以及你通常点击的东西是什么。这种逻辑似乎是不可避免的，因为它能够有效地减少信息超负荷，提高人们从NewsFeed中获取信息的效率。

尽管这种方法看起来不可避免，但它有两个问题。首先，让训练算法的样本变得“正确”，是非常困难的，并且还会受到各种概念挑战的困扰。但是第二，即使它打造出了一个成功的NewsFeed，它仍然只是一个基于特定样本的算法规则。

先来看看第一个问题，在获得算法驱动的NewsFeed样本的“正确”方面存在着一系列问题。其中大部分已经在过去几年详细讨论过了。人们(俄罗斯人、游戏开发商)有很多动机试图去操纵Feed。他们会利用人们似乎希望看到风险过度拟合、循环和过滤泡沫的信号。人们的欲望发生了变化，他们厌倦了一些事情，所以Facebook必须不断地改变算法组合以反映这一点。Facebook必须对人们似乎想要什么、以及什么样的指标似乎能捕捉到这一点做出主观判断，而这些判断都不是静态的，甚至在原则上都不是完美的。所以，Facebook会浏览用户行为。

在这里，将NewsFeed遇到的挑战和谷歌在搜索结果上遇到的挑战相比较是有用的。谷歌必须找出最好的10个结果来展示给用户，这个过程中，要用各种指标来判断哪个结果最符合用户的需要，就像NewsFeed所做的那样——它不能仅仅通过一些客观的指标来向你展示结果，比如日期或者文件大小。同样，它也可以提供复杂的手工控制和过滤器来让你筛选结果，但像Facebook一样，它必须在没有这些控制的情况下把事情做好，因为大多数人都不会碰那些用来筛选的东西。当然，和Facebook一样，也有人试图操纵这个系统。不过，与Facebook不同的是，谷歌有明确的意图——因为你会告诉它你想看到什么。因此，如果谷歌向我展示了我所说的我想要的内容，它就成功了，即使我“本不应该”搜索到这个内容。Facebook没有这样的直接信号，有些东西是“不应该”给我看的，哪怕我叔叔确实分享了它们。但这些东西到底是什么呢？谁来决定？权重又是什么样的呢？

这是对算法正确性的挑战，但也存在第二个问题——它始终是从样本中得来的。Facebook已经做了大量的开发、推广和“增长黑客”工作，以便将更多的内容添加到Feed中，并使其无障碍地分享出去。现在，我可以获得的内容要比我可以看到的内容多得多。它试图向我展示一个基于算法的样本，这个样本比“最近45分钟内发布的内容”要好。它可能成功，或者可能不会成功，但仍然存在这样的问题——人们是否还想要一个样本？

这里的一个基本问题是，如果Feed的算法关注的是“我想看什么？”，那么它就不能关注“我的朋友想要（或需要）我看什么？”有时候这是一回事——我和我的朋友都希望我看到他们今晚要举行派对。但是，如果每个Feed都是一个样本，那么用户无法知道谁会看到他们发布的内容。事实上，从概念上来说，人们可能会认为他们没有办法知道是否有人会看到这篇文章。当然，Facebook的参与团队不会让这种情况发生——如果我觉得自己像是在“荒野中大喊大叫”，我就会离开（这是Twitter的新用户问题之一）。所以，会有足够多的朋友看到我的内容，并给我反馈，以便推动着继续发布内容。但是，如果某件事情真的很重要，为什么要把它放在Facebook上呢？

我想有人可能会说，这是Facebook的NewsFeed系统参与度降低的部分原因，也是人与人之间的聊天明显增长的部分原因(最明显的是WhatsApp、iMessage、FB Messenger和Instagram——Facebook拥有其中三个)。1 : 1聊天的社交动态可以更有效地防止超负荷，哪怕对方疯狂地分享一些东西，但这些东西只会出现在你们的对话框里，如果你感觉到很厌烦，你可以拉黑，或者静音。

同时，你可能会提到Snap发明的 Stories 功能和Facebook跟着“发明”的Stories功能，这也是一种解决信息超负载问题的方法：通过将你想要共享的内容捆绑到一个单元中而不是许多单独的项目中。即使你这么做了，仍然可以向许多人分享，而且Feed也更易于管理了。尽管你仍然不对称地分享事物，但你和你的朋友之间不应该有一种算法。也就是说，Stories可能意味着你分享更多的东西，但通过将它们捆绑成一件东西，你可以减轻朋友的负担，并减少对过滤器的需求。将结构放入内容中，而不是显示内容。

显然，从NewsFeed到消息传递的背后，显然还有其他趋势。消息传递可以更私密，社会压力更小，并且更有趣。Snapchat的Stories并不是一个永久的记录，也没有太大的压力来展示你完美的一面。贴纸和过滤器比Facebook的僵硬的蓝色盒子更有趣，更自然。

值得注意的是，尽管这些系统看起来像减少了分享内容超负荷，但是你确实需要群组聊天。还有很多团体。如果你有10个WhatsApp组，每个组有50人，那么人们就可以很自由的分享内容。然后你会想，也许应该有一个屏幕，在我所有的小组中都应该有一个新帖子的 feed。你可以称之为“NewsFeed”。也许它应该得到一些情报，来显示你最关心的内容……

所有社交应用程序都在增长，直到你需要一个NewsFeed

所有的NewsFeed都在增长，直到你需要一个算法驱动的NewsFeed

所有算法驱动的NewsFeed都在增长，直到你厌倦了看不到东西/看到错误的东西，并转而使用不那么超负荷的、更小的新应用程序

然后，新应用程序也在增长，直到你需要一个NewsFeed

……

——本尼迪克特·埃文斯（@ BenedictEvans）2018年1月22日

悲观主义者可能会说，这看起来像是刀耕火种的农业，或者是老笑话“没有人再去那里了——那里太拥挤了”。也就是说，对于社会而言，梅特卡夫定律（Metcalfe’s Law）看起来更像是钟形曲线。我不知道下一个产品是什么(毕竟我没有创建Snap)。但是像这样的技术往往是循环往复的——我们从一种表达方式转向另一种表达方式，然后再回来，我们可能是在远离Feed。

最后，任何这样的变化都会对分享创建的流量产生影响。“点赞”按钮让你可以无障碍地把你想要的任何网页发布到你的feed中，然后把它推给你的朋友(某些任意计算的百分比)，很多人都在纠结这个按钮能带来多少流量，以及Facebook如何移动并降低Feed的排名。但是, 今天分享 Stories 的链接是不一样的，你在WhatsApp或iMessage小组中与5个朋友分享的链接只会被他们看到，Facebook也没有办法让这更多或更少的人看到它们。另一方面，“WhatsApp转发”可以获取这样的链接，并在全国范围内传播，如果Facebook真的愿意的话，它最终可以在整个网站上删除一个链接或整个源，对于一个 P2P 消息应用程序来说，这是非常不同的。也就是说，许多媒体公司呼吁在NewsFeed中“提升”自己的权重，让人们吃自己的“绿色食品”，并在Facebook上取消“假新闻”链接——至少从理论上来说, 在 Facebook 上是可能的。但是，这在iMessage中是不可能的——使用端到端加密，苹果都不知道你在分享什么。

原文链接： https://www.ben-evans.com/benedictevans/2018/4/2/the-death-of-the-newsfeed

译者：chiming，由36氪编译组出品。编辑：郝鹏程

译文地址：http://36kr.com/p/5127519.html?from=authorlatest

题图来自 Pexels，基于 CC0 协议

人民日报发布 Twitter 和 Facebook 欢迎 Google 回归

Tue, 07 Aug 2018 13:00:00 CST

刚得到消息，人民日报在 Twitter 和 Facebook 上发文，欢迎 Google 回归中国，不过要遵守中国法律。这是上周 the Intercept 放出消息 Google 将要回归之后，人民日报首次做出的回应，也是非常重要的肯定。
尽管像上篇讲的，国外民众对 Google 的此举非常有意见。但国内政府和 Google 双方都非常有意愿，毕竟各自都有强烈的需求。
国内面对的是 Android 市场的混乱，以及中文搜索的混乱。
而 Google 想要的是国内的巨大市场。
我认为这是双赢的机会，是肯定会发生。去年跟 Google 的朋友交流，就透露出已经开始了各种接触。
以下是人民日报在 Facebook 上发表的长文。用 Google 翻译得到的结果基本看不出来机翻的痕迹。

Facebook 扩大内容核查范围，机器学习+全方位审核打击假新闻

Sun, 24 Jun 2018 17:47:41 CST

6 月 22 日早晨，Facebook 宣布将扩大其内容核查范围，以打击社交网络上面的虚假新闻和恶作剧消息，并通过相应的打击措施和技术手段，尽量减少虚假新闻带来的恶劣影响。

Facebook 在博文中透露，虚假新闻以及恶意篡改内容在一些国家已经成为常态，这使得读者难以判别信息的真假，甚至难以判别与新闻事件相关的图片或视频是否真实。Facebook 还将与第三方视觉机构专家进行合作，把事实核查的部分扩展到图片和视频。与此同时，还会将发布在 Facebook 平台上的上具有误导性的照片进行标记，以提醒用户信息的准确性和真实性。

当一些 Facebook 用户在试图分享虚假新闻时，Facebook 会弹出提示，提醒用户此消息已被证实为虚假信息并显示官方辟谣链接，当用户点击提示链接时，还可以看到被标记的可疑内容以及原新闻报道。该博文中提到，每天有超过 10 亿张图片、视频等内容被上传至社交平台，庞大的工作量使得人工审核小组难以完成任务。因此 Facebook 将引入机器学习机制，通过 AI 来识别在网络上被揭穿的虚假信息，该工具可以帮助公司找到那些正在被传播但已经被证实为假信息的链接。

Facebook 的产品经理 Tessa Lyons 解释说：AI 会标记剽窃的文本、可疑的广告以及恶意针对其他用户的信息。因为这些信息一般会在不同的域名以不同的形式发布，一旦有一个虚假新闻被揭穿，机器就会标记这个新闻的关键信息并加入到后台的识别库之中，以便之后 AI 识别类似信息。

时至今日，Facebook 表示已经将内容审查计划扩展到全球 14 个国家，对于图片和视频的核查也已扩展到 4 个国家，公司计划在年底将其扩展到更多国家。Facebook 表示在公司的努力下，事实核查制度使得社交媒体上的虚假新闻减少了 80%。

自 2016 年 12 月起，Facebook 就开始加大力度打击虚假新闻，其中原因是在美国总统大选期间，大量的虚假新闻在社交平台上传播，Facebook 因为没有尽力阻止虚假新闻传播而备受指责。随后 Facebook 又与德国、法国等媒体机构合作，以避免虚假新闻被上传到社交平台而造成的不利影响。

在打击虚假消息和假新闻的道路上，Facebook 已经努力了一年半的时间，公司表示接下来会进一步完善虚假账户、虚假信息以及相关的问责制度。并称：「打击虚假信息这个项目永远没有尽头，我们需要做的还有很多。」

然而该举措在有效打击假新闻的同时，却也引起了一些用户对于 Facebook 核查图片和视频的担忧，他们担心 Facebook 此举侵犯到自己的个人信息安全以及隐私。有些用户质疑：事件的真实性由谁来界定？审查的范围是否涉及个人隐私？这个功能会不会被政府用来监视用户的个人想法？

近几个月以来，Facebook 因为数据隐私方面受到了用户与社会的谴责。今年早些时候，政治咨询公司 Cambridge Analytica 非法访问了数百万 Facebook 用户的个人信息，并用于非正当途径。此后，Facebook 经历了欧洲和美国的多轮质疑。现在该公司承诺在处理用户数据方面将有更大的透明度。

头图来源：视觉中国

参考：

Facebook expands its fact-checking tools but says its work 『will never be finished』

Facebook Expanding Fact-Checking Project to Combat Fake News

Facebook Wants to Use Machine Learning to Stop Hoaxes and Fake News

[原]Facebook如何运用机器学习进行亿级用户数据处理

Tue, 23 Jan 2018 14:33:26 CST

编译 | 刘畅、尚岩奇、林椿眄
审校 | reason_W

2017年末，Facebook应用机器学习组发布最新论文，对整个Facebook的机器学习软硬件架构进行了介绍。纵览全文，我们也可以从中对Facebook各产品的机器学习策略一窥究竟。论文中涉及到机器学习在全球规模(上亿级数据处理)上的全新挑战，并给出了Facebook的应对策略和解决思路，对相关行业和研究极其有意义。

摘要

机器学习在Facebook的众多产品和服务中都有着举足轻重的地位。本文将详细介绍Facebook在机器学习方面的软硬件基础架构，如何来满足其全球规模的运算需求。

Facebook的机器学习需求极其繁杂：需要运行大量不同的机器学习模型。这种复杂性已经深深刻在Facebook系统堆栈的所有层面上。此外，Facebook存储的所有数据，有相当大一部分会流经机器学习管道，这样的数据载荷为Facebook的分布式高性能训练流带来巨大的压力。

计算需求也非常紧张，在保持用于训练的GPU/CPU平台的同时平衡出大量CPU容量用于实时推理，也带来了异常紧张的。这些问题及其他难题的解决，仍有待我们在跨越机器学习算法、软件和硬件设计上持久而不懈的努力。

引言

Facebook的使命是“为人类构建社交关系赋能，让世界联系更加紧密”。截至2017年12月，Facebook已经连接了全球超过20亿的人口。同时，过去几年来，机器学习同样在这样一种全球尺度的实际问题上进行着一场革命，包括在机器学习算法创新方面的良性循环，用于模型训练的海量数据以及高性能计算机体系结构的进步。

在Facebook上，机器学习几乎在提升用户体验的所有层面都发挥着关键作用，包括诸如新闻推送语音和文本翻译以及照片和实时视频分类的排名等服务。

Facebook在这些服务中用到了各种各样的机器学习算法，包括支持向量机，梯度boosted决策树和许多类型的神经网络。本文将介绍Facebook的数据中心架构支持机器学习需求的几个重要层面。其架构包括了内部的“ML-as-a-Service”流，开源机器学习框架，和分布式训练算法。

从硬件角度来看，Facebook利用了大量的CPU和GPU平台来训练模型，以便在所需的服务延迟时间内支持模型的训练频率。对于机器学习推理过程，Facebook主要依靠CPU来处理所有主要的服务，而其中神经网络排名服务（比如新闻推送）占据着所有计算负载的大头。

Facebook所存储的海量数据中，有一大部分要流经机器学习管道，并且为了提高模型质量，这一部分的数据量还在随着时间推移不断增加。提供机器学习服务所需的大量数据成为了Facebook的数据中心将要在全球规模上面临的挑战。

目前已有的可被用来向模型高效地提供数据的技术有，数据反馈和训练的解耦操作，数据/计算协同定位和网络优化。与此同时，Facebook公司这样大的计算和数据规模自身还带来了一个独特的机会。在每天的负载周期内，非高峰期都会空闲出大量可以用来进行分布式训练算法的CPU。

Facebook的计算集群（fleet）涉及到数十个数据中心，这样大的规模还提供了一种容灾能力。及时交付新的机器学习模型对于Facebook业务的运营是非常重要的，为了保证这一点，容灾规划也至关重要。

展望未来，Facebook希望看到其现有的和新的服务中的机器学习使用频率快速增长。当然，这种增长也将为负责这些服务架构的团队在全球规模的拓展性上带来更加严峻的挑战。尽管在现有平台上优化基础架构对公司是一个重大的机遇，但我们仍然在积极评估和摸索新的硬件解决方案，同时保持对于算法创新的关注。

本文（Facebook对机器学习的看法）的主要内容包括：

机器学习正在被广泛应用在Facebook几乎所有的服务，而计算机视觉只占资源需求的一小部分。
Facebook所需的大量机器学习算法极其繁杂，包括但不限于神经网络
我们的机器学习管道正在处理海量的数据，而这会带来计算节点之外的工程和效率方面的挑战。
Facebook目前的推理过程主要依靠CPU，训练过程则是同时依靠CPU和GPU。但是从性能功耗比的角度来看，应当不断对新的硬件解决方案进行摸索和评估。
全球用户用来使用Facebook的设备每天都可达数亿台，而这会就会提供大量可以用于机器学习任务的机器，例如用来进行大规模的分布式训练。

Facebook的机器学习

机器学习（ML）是指利用一系列输入来建立一个可调模型，并利用该模型创建一种表示，预测或其他形式的有用信号的应用实例。

图1 Facebook的机器学习流程和架构示例

图1所示的流程由以下步骤组成，交替执行：

建立模型的训练阶段。这个阶段通常离线运行。
在应用中运行训练模型的推理阶段，并进行（一组）实时预测。这个阶段是在线执行的。

模型进行训练的频率要比推理少得多——推理的时间规模虽然在不断变化，但一般在几天左右。训练也需要相当长的时间来完成，通常是几个小时或几天。同时，根据产品实际需求不同，在线推理阶段每天可能运行达数十万次，而且一般需要实时进行。在某些情况下，特别是对于推荐系统，还需要以这样连续的方式在线进行额外的训练。

在Facebook，机器学习的一个显著特征就是有可用于模型训练的海量数据。这个数据的规模会带来很多涉及到整个机器学习架构的影响。

使用机器学习的主要服务

消息推送

消息推送排名算法能够使用户在每次访问Facebook时，最先看到对他们来讲最重要的事情。一般模型会通过训练来确定影响内容排序的各种用户和环境因素。之后，当用户访问Facebook时，该模型会从数千个候选中生成一个最佳推送，它是一个图像和其他内容的个性化集合，以及所选内容的最佳排序。

广告系统利用机器学习来确定向特定用户显示什么样的广告。通过对广告模型进行训练，我们可以了解用户特征，用户上下文，以前的互动和广告属性，进而学习预测用户在网站上最可能点击的广告。之后，当用户访问Facebook时，我们将输入传递进训练好的模型运行，就能立马确定要显示哪些广告。

搜索

搜索会针对各种垂直类型（例如，视频，照片，人物，活动等）启动一系列特定的子搜索进程。分类器层在各类垂直类型的搜索之前运行，以预测要搜索的是垂直类型中的哪一个，否则这样的垂直类型搜索将是无效的。分类器本身和各种垂直搜索都包含一个训练的离线阶段，和一个运行模型并执行分类和搜索功能的在线阶段。

Sigma

Sigma是一个分类和异常检测通用框架，用于监测各种内部应用，包括站点的完整性，垃圾邮件检测，支付，注册，未经授权的员工访问以及事件推荐。Sigma包含了在生产中每天都要运行的数百个不同的模型，并且每个模型都会被训练来检测异常或更一般地分类内容。

Lumos

Lumos能够从图像及其内容中提取出高级属性和映射关系，使算法能够自动理解它们。这些数据可以用作其他产品和服务的输入，比如通过文本的形式。

Facer

Facer是Facebook的人脸检测和识别框架。给定一张图像，它首先会寻找该图像中所有的人脸。然后通过运行针对特定用户的人脸识别算法，来确定图中的人脸是否是该用户的好友。Facebook通过该服务为用户推荐想要在照片中标记的好友。

语言翻译

语言翻译是涉及Facebook内容的国际化交流的服务。Facebook支持超过45种语言之间的源语言或目标语言翻译，这意味着Facebook支持2000多个翻译方向，比如英语到西班牙语，阿拉伯语到英语。通过这2000多个翻译通道，Facebook每天提供4.5B字的翻译服务，通过翻译用户的消息推送，Facebook每天可为全球6亿人减轻语言障碍。目前，每种语言对方向都有其自己的模型，但是我们也正在考虑多语言模型[6]。

语音识别

语音识别是将音频流转换成文本的服务。它可以为视频自动填补字幕。目前，大部分流媒体都是英文的，但在未来其他语言的识别也将得到支持。另外，非语言的音频文件也可以用类似的系统（更简单的模型）来检测。

除了上面提到的主要产品之外，还有更多的长尾服务也利用了各种形式的机器学习。 Facebook产品和服务的长尾数量达数百个。

机器学习模型

所有基于机器学习的服务都使用“特征”（或输入）来产生量化的输出。Facebook使用的机器学习算法包括Logistic回归（LR），支持向量机（SVM），梯度提升决策树（GBDT）和深度神经网络（DNN）。

LR和SVM在训练和预测方面非常有效。GBDT可以通过增加计算资源来提高准确性。DNN是最具表达力的，能够提供最高的准确性，但利用的资源也是最多的（在计算量上，至少比LR和SVM等线性模型高出一个数量级）。

这三种模型的自由参数都在变得越来越多，必须通过使用带标签的输入示例来优化预测的准确性。

在深度神经网络中，有三类经常使用的网络：多层感知器（MLP），卷积神经网络（CNN）和递归神经网络（RNN / LSTM）。MLP网络通常运行在结构化输入特征（通常是排名）上，RNN / LSTM网络一般用来处理时域的数据，即用作序列处理器（通常是语言处理），相对的CNNs则是一种处理用来空间数据的工具（通常是图像处理）。表I显示了这些机器学习模型类型和产品/服务之间的映射关系。

表1 利用机器学习算法的产品或服务

Facebook中的ML-as-a-Service

为了简化在产品中应用机器学习的任务，我们构建了一些内部平台和工具包，包括FBLearner，Caffe2和PyTorch。FBLearner是三种工具（FBLearner Feature Store，FBLearner Flow，FBLearner Predictor）的套装，其中每种工具分别负责机器学习管道上不同的部分。正如前面图1显示的那样，它利用了一种内部作业调度程序在GPU和CPU的共享资源池上分配资源和调度作业。Facebook大多数机器学习模型的训练过程都是在FBLearner平台上进行的。这些工具和平台被设计来帮助机器学习工程师提高效率，从而能够专注于算法创新。

FBLearner Feature Store。任何机器学习建模任务的起点是收集和生成特征。 FBLearner Feature Store本质上是一系列特征生成器的目录，其特征生成器可以用于训练和实时预测，当然它也可以作为多个团队可以用来共享和寻找特征的公共空间（market place）。这样以个特征列表对于刚开始使用机器学习的团队来说是一个很好的平台，同时也有助于在现有模型中应用新特征。
FBLearner Flow是Facebook用于训练模型的机器学习平台。Flow是一个管道管理系统，它会执行一个可以描述模型训练和/或评估所需步骤及其所需资源的工作流程（workflow）。这个工作流程由离散单元或操作符（operators）构成，每个单元都有输入和输出。操作符之间的连接会通过跟踪一个操作符到下一个操作符的数据流自动推理，Flow则通过处理调度和资源管理来执行工作流程。Flow还拥有一个可以用于实验管理的工具和一个简单的用户界面，这个界面可以跟踪每个workflow或实验生成的所有构件和指标，从而方便对比和管理这些实验。
FBLearner Predictor是Facebook内部的推理引擎，它可以使用在Flow中训练的模型来提供实时的预测。Predictor可以用作多租户服务，也可以用作集成在特定产品的后端服务中的库。Facebook的很多产品团队都在使用Predictor，而其中许多团队都需要低延迟解决方案。Flow和Predictor之间的直接集成还有助于运行在线的实验以及在生产中管理多个版本的模型。

深度学习框架

我们在Facebook上利用了两种截然不同的协同框架来进行深度学习：针对研究优化的PyTorch和针对生产优化的Caffe2。

Caffe2是Facebook的内部生产框架，它用于训练和部署大规模的机器学习模型。Caffe2专注于产品所需的几个关键特性：性能，跨平台支持和基本的机器学习算法，如卷积神经网络（CNN），递归神经网络（RNN）和多层感知器（MLP）。这些网络都具有稀疏或密集的连接以及高达数百亿的参数。该框架的设计采用模块化方法，在所有后端实现（CPU，GPU和加速器）之间共享统一的图表示。为了在不同平台上实现最佳的运行时间，Caffe2还抽象了包括cuDNN，MKL和Meta在内的第三方库。
PyTorch是Facebook在AI研究领域的首选框架。它的前端注重灵活性、调试以及动态神经网络，能够快速进行实验。由于依赖于Python来执行，它并没有针对生产和移动端部署进行优化。当研究项目产生了有价值的结果时，模型就需要转移到生产上。过去，在生产环境中，我们通过使用其他框架重写产品环境的训练管道来完成模型转移。最近Facebook开始构建ONNX工具链来简化这个转移过程。比如，动态神经网络虽然被用于尖端的人工智能研究，但这些模型需要更长的时间才能被应用于产品中。通过解耦框架，我们避免了的为满足性能而设计更复杂的执行引擎（比如Caffe2）的需求。此外，相比模型速度，研究人员在进行研究时更看重其灵活性。举个栗子，在模型探索阶段，性能下降30％是可以容忍的，尤其是在它具有易测验和模型可视化的优点时。但是相同的方法并不适合于生产。这种取舍原则在PyTorch和Caffe2的框架设计中也可以看到，PyTorch提供了良好的默认参数和合理的性能，而Caffe2可以选择使用异步图执行，量化权重和多个专用后端等特性来达到最佳性能。

虽然FBLearner平台本身不限制使用什么框架，无论是Caffe2，TensorFlow，PyTorch还是其他的框架都可以，但我们的AI软件平台（AI Software Platform）团队为了让FBLearner能够很好地与Caffe2集成还是进行了特定优化。总的来说，分离研究和生产框架（分别是PyTorch和Caffe2）使我们能够在两边灵活运作，减少约束数量的同时还能增加新特性。

ONNX. 深度学习工具生态系统在整个行业还处于初级阶段。对于不同的问题子集，不同的工具有着不同的优势，并且在灵活性，性能和支持平台方面有着不同的折衷，这就跟我们之前对PyTorch和Caffe2所描述的权衡一样。因此，在不同的框架或平台之间交换训练模型的需求很大。为了弥补这个缺陷，2017年末，Facebook与几个合作伙伴共同推出了开放式神经网络交换（Open Neural Network Exchange , ONNX）。ONNX是一种以标准方式表示深度学习模型的格式，以便在不同的框架和供应商优化库之间实现互操作。同时，它能满足在不同的框架或平台之间交换训练好的模型的需求。ONNX被设计为一种开放的规范，允许框架作者和硬件供应商为其做出贡献，并拥有框架和库之间的各种转换器。Facebook正在努力使ONNX成为所有这些工具之间的协作伙伴，而不是一种具有排他性的官方标准。

在Facebook内部，ONNX是我们将研究模型从PyTorch环境转移到Caffe2中的高性能生产环境的主要手段，它可以实现对模型的自动捕捉和固定部分的转换。

在Facebook内部，ONNX是我们将研究模型从PyTorch环境转移到Caffe2中的高性能生产环境的主要手段。 ONNX提供了自动捕捉和转换模型的静态部分的能力。我们有一个额外的工具链，通过将它们映射到Caffe2中的控制流原函数或者以C ++作为自定义操作符重新实现它们，会有助于将模型从Python转移到动态图。

机器学习的资源需求

鉴于机器学习在训练和推理（inference）的阶段的资源要求、频率和持续时长不同，我们将分别讨论这两个阶段的细节和资源应用。

Facebook硬件资源概况

Facebook的基础架构部门（Facebook Infrastructure）很早之前就开始为主要软件服务构建的高效平台，包括针对每种主要工作负载的资源要求定制的服务器、存储以及网络支持。

图2 基于CPU的计算服务器。单插槽服务器底座上有4个Monolake服务器卡，双插槽服务器底座还一个双插槽服务器，因此在2U机箱中共有三个双插槽服务器。所以在2U形式的组合中共有12个服务器。

当前Facebook提供约八种主要的计算和存储架构，对应八种主要服务。这些主要架构类型足以满足Facebook主要服务的资源要求。例如，图2中展示了一个可以容纳三个计算Sleds模块的2U机架，这些模块可支持两种服务器类型。其中一种Sled模块是单插槽CPU服务器（1xCPU），多用于Web层——一种主要看重吞吐量的无状态服务，因此可以使用能效更高的CPU（Broadwell-D处理器）；它的DRAM（32GB）以及主板硬盘或闪存较少。

另一种Sled模块是较大的双插槽CPU服务器（2x高功率Broadwell-EP或Skylake SP CPU），它配有大量的DRAM ，常用于涉及大量计算和存储的服务。

图3 搭载8个GPU的Big Basin GPU服务器（3U机架）

由于我们训练的神经网络越来越大，并且越来越深，我们开发出了Big Basin GPU服务器（如图3所示），这是我们2017年最新的GPU服务器。最初的Big Basin GPU服务器配置了八个互相连接的NVIDIA Tesla P100 GPU加速器，它使用NVIDIA NVLink形成了一个八CPU混合立方网格，后来，这种设计经过改进之后又应用到了V100 GPU上。

Big Basin是早前的Big Sur GPU的继承者，后者是Facebook数据中心首个广泛应用的高性能AI计算平台，用于支持于2015年开发并通过开放计算项目（Open Compute Project）发布的NVIDIA M40 GPU。

与Big Sur相比，V100 Big Basin每瓦电可实现的性能更高，这得益于单精度浮点运算单元——每个GPU的运算速度从7 teraflops（每秒万亿次浮点运算）增加到了15.7 teraflops，以及可提供900GB/s的带宽的高带宽显存（HBM2）。这种新的架构还使得半精度运算的速度快了一倍，进一步提高了运算吞吐量。

由于Big Basin的运算吞吐量更大，而且显存也从12 GB增加到了16 GB，因此它可以用来训练比先前模型大30%的模型。高带宽NVLink互连GPU通信还强化了分布式训练。在使用ResNet-50图像分类模型进行的测试中，Big Basin的运算吞吐量比Big Sur要高出300%，借助它我们可以以更快的速度训练比以往更复杂的模型。

Facebook通过开放计算项目（Open Compute Project）公布了所有这些计算服务器的设计以及几种存储平台。

离线训练的资源需求

当前，不同的产品会使用不同的计算资源来完成各自的离线训练步骤。有些产品（例如Lumos）在GPU上完成所有的训练。其他产品（例如Sigama）则在双插槽 CPU计算服务器完成所有的训练。诸如Facer这样的产品采用双阶段训练流程，先在GPU上以很小的频率（几个月一次）队通用的面部检测和识别模型进行训练，然后在数千个1xCPU服务器上以很高的频率对每个用户的模型进行特定训练。

在本部分，我们将围绕机器学习训练平台、训练频率和持续时长，具体介绍多种服务的细节，并在表II中进行了总结。另外，我们还讨论了数据集的趋势以及这些趋势对计算、内存、存储和网络架构的意义。

计算类型和相对数据来源的位置。离线训练既可以在CPU上完成，也可以在GPU上完成，这取决于服务本身。虽然在多数情况下，在GPU上训练出的模型在性能上要比在CPU上训练的模型好，但是CPU强大的现成运算能力使得它成为了一个非常有用的平台。这一点在每天的非高峰期中尤为明显，因为在这期间CPU资源本来就无法得到利用，后面的图4会对此进行说明。下面我们给出了服务和计算资源训练模型的对应关系：
在GPU上训练模型的服务: Lumos、语音识别、语言翻译
在CPU上训练模型的服务：News Feed、Sigma
在GPU和CPU上训练模型的服务：Facer （在GPU上每几年训练一次的通用模型，此类模型较为稳定；在1xCPU上训练的用户特定的模型，此类模型可以用于处理新图像数据）、搜索（利用多个独立的垂直搜索引擎，使用可以进行预测的分类器启动最合适的垂直搜索引擎）。

目前，GPU主要被用于离线训练，而不是向用户提供实时数据。因为大多数GPU架构都针对运算吞吐量进行了优化，以克服延迟劣势。同时由于训练过程严重依赖从大型数据生成库中获取的数据，考虑到性能和带宽方面的原因，GPU必须靠近数据来源。由于训练模型所使用的数据量增长的相当快，GPU是否靠近数据来源变得越来越重要。

内存、存储和网络：从内存储器容量的角度看，CPU和GPU平台都能为训练提供充足的存储容量。即使对于Facer这样的应用，也可以在1xCPU上用32GB RAM训练用户特定的SVM模型。如果可以尽可能地利用高效平台以及多余的存储容量，则平台的总体训练效率会非常优秀。

表II 不同服务的离线训练的频率、持续时长和资源

机器学习系统依赖于使用实例数据的训练。Facebook 使用了机器学习数据管道中的大量数据。这使得计算资源趋向于靠近数据库。

随着时间的推移，大多数服务会显示出利用累积的用户数据的趋势，这将导致这些服务更加依赖Facebook的其他服务，并且需要更大的网络带宽来获取数据。因此，只有在数据源所在地或附近部署巨大的存储，以便从偏远的区域大规模转移数据，从而避免为了等待获取更多样本数据而关停训练管道。

在部署训练机器的位置时，我们也可以使用这种方法来避免训练机群给附近的存储资源造成过大的压力。

不同的服务在离线训练期间使用的数据量有很大的差别。几乎所有服务的训练数据集都呈现出持续增长甚至大幅增长的趋势。例如，有些服务在ROI降低之前会使用数百万行数据，其他服务则使用数百亿行数据（100多TB），并且只受到资源的限制。

扩展（Scaling）考虑和分布式训练：训练神经网络的过程包含使用随机梯度下降法（SGD）对参数权重进行优化。这种方法用于拟合神经网络，通过评价标记实例的小子集（即“batch” 或“mini-batch”）来迭代更新权重。在数据并行中，网络会生成多个模型副本（并行实例），以并行的处理多批数据。

当使用一台机器训练模型时，模型越大或更深都会带来更好的训练效果，准确度也会更高，但是训练此类模型往往需要处理更多的样本。当使用一台机器进行训练时，我们可以通过增加模型副本的数量并在多个GPU上执行数据并行，来最大化训练效果。

当训练所需的数据量随时间增加，硬件限制会导致总体训练延迟和收敛时间增加。不过，我们可以使用分布式训练来克服这些硬件限制，减少延迟。这个研究领域在Facebook和整个AI研究界相当热门。

一种普遍的假设是，在不同机器上实现数据并行需要使用一种专门的互连机制。但是，在我们对分布式训练的研究中，我们发现基于以太网(Ethernet)的网络就可以提供近似线性的扩展能力。能否实现近似线性的扩展，与模型的大小和网络带宽有密切的关系。

如果网络带宽太小，执行参数同步所花的时间比执行梯度计算所花的时间还多，在不同机器上进行数据并行所带来的优势也会大打折扣。使用50G的以太网NIC，我们可以用Big Basin服务器扩展视觉模型的训练，而且机器间的同步完全不会造成问题。

在所有情况下，更新都需要使用同步（每个副本都看到相同状态），一致性（每个副本生成正确更新）和性能（子线性缩放）的技术来与其他副本共享，这可能会影响训练质量。例如，翻译服务目前就不能在不降低模型质量的情况下进行大批量的小批量（mini-batches）训练。

相反，如果使用特定的超参数设置，我们就可以在非常大的mini-batch数据集上训练图像分类模型，并且可以扩展到256个以上的GPU上。

实验证明，在Facebook的某个大型服务中，在5倍的机器上执行数据并行可以实现4倍的训练效率（例如：训练一组训练时间超过4天的模型，以前总共可以训练100个不同模型的机器集群现在每天只能训练同样的20个模型，训练效率降低了20%，但是潜在的工程进度等待时间从4天减少到了1天）。

如果模型变得超级大，这时候就可以使用并行训练，对模型的层进行分组和分布，以优化训练效率，各机器间可以传递激活单元。优化可能与网络带宽、延迟或平衡内部机器限制有关。这会增加模型的端对端延迟，因此，每一时步（time step）内原始性能的增强通常与步长（step）质量的下降有关。这可能会进一步降低模型在每个步长的准确度。各步长准确度的下降最终会累积起来，这样我们就可以得出并行处理的最佳步长数量。

DNN模型本身的设计使得它只能在一台机器上运行，在推理阶段，在机器间分割模型图通常会导致机器与机器进行大量的沟通。但是Facebook的主要服务会不断地权衡扩展模型的利与弊。这些考虑可以决定网络容量需求的变化。

表 III 在线推理服务的资源要求

在线推理的资源需求

在完成离线训练之后的线推理步骤中，我们需要将模型载入到机器中，使用实时输入运行模型来生成网站流量的实时结果。

接下来我们将讨论，一种实际应用中的在线推理模型——广告排名模型。这种模型可以筛选成千上万条广告，在消息推送中显示排在1至5名的广告。这个过程是通过对依次减小的广告子集进行逐步复杂的排名运算循环（passes）来实现的。

每一轮运算都会用到类似于多层感知模型（MLP）的模型，这种模型包含稀疏嵌入层，每一轮运算都会缩小广告的数量。稀疏嵌入层需要大量的内存，因此当进行到靠后的运算时，模型的超参数数量更多，它将在独立于MLP运算轮的一个服务器上运行。

从计算的角度上看，绝大多数在线推理都是在大量1xCPU（单插槽）或2xCPU（双插槽）上运行的。由于1xCPU对Facebook的服务而言性能更高，而且性价比更高，因此Facebook提倡尽可能使用1xCPU服务器训练模型。

随着高性能移动硬件的诞生，Facebook甚至可以在用户的移动设备上直接运行某些模型，来改进延迟和降低通信成本。但是，某些需要大量计算和内存资源的服务仍然需要使用2xCPU才能实现最佳性能。

不同的产品在得出在线推理的结果时拥有不同的延迟要求。在某些情况下，得出的数据可能“十分优秀” ，也可能会在向用户返回初步快速评估后被重新输入到模型中。例如，在某些情况中将某个内容分类为合格是可以接受的，但是当运行更加复杂的模型时这个初步的分类结果就会被推翻。

广告排名和消息推送之类的模型配置有稳定的SLA，可以向用户推送合适的内容。这些SLA决定着模型的复杂性和依赖性，因此如果拥有更加强大的计算能力，我们就可以训练出更加先进的模型。

机器学习数据计算

除了资源需求外，在数据中心部署机器学习时还需要考虑一些重要的因素，包括对重要数据的需求以及面对自然灾害的可靠性。

从获取数据到模型

Facebook公司的许多机器学习模型，成功的主要因素就是广泛而高质量的可用数据。快速处理并将这些数据提供给机器学习模型的能力能够确保我们部署快速有效的离线训练。

对于复杂的机器学习应用程序，如广告和排名，每个训练任务所需的数据量都超过数百TB大小。此外，复杂的预处理逻辑的使用能确保数据被清理并归一化，以便高效地迁移和更轻松地学习。这些操作对资源的要求非常高，特别对存储量，网络和CPU的需求。

作为一个通用的解决方案，我们尝试对训练工作量中的数据进行解耦。这两个工作量都有非常显著的特点。一方面，它非常复杂，具有临时的，依赖业务性的，且变化快等特点。另一方面，训练工作量通常是固定的（例如GEMM），稳定的（核心业务相对较少），高度优化，且更偏爱于“干净”的环境下工作（例如，独占高速缓存使用和最小线程争夺）。

为了优化这两者，我们在物理上对不同的机器的不同工作负载进行隔离。数据处理机器，又名“readers”，从存储器中读取数据，处理和压缩它们，然后将结果反馈给一个叫做“trainers”的训练机器。另一方面，trainers只专注于快速有效地执行任务。readers和trainers可以分布以便提供更灵活性和可扩展性的应用。此外，我们还优化了不同工作负荷的机器配置。

另一个重要的优化指标是网络使用。训练过程产生的数据流量非常重要的，并且有时候会突然产生。如果没有智能化处理的话，这很容易就会导致网络设备的饱和，甚至干扰到其他服务。为了解决这些问题，我们采用压缩优化，调度算法，数据/计算布局等等操作。

利用规模

作为一家为用户提供服务的全球性公司，Facebook必须保持大量服务器的设计能够满足在任何时间段内的峰值工作负载。如图所示，由于用户活动的变化取决于日常负荷以及特殊事件（例如地区节假日）期间的峰值，因此大量的服务器在特定的时间段内通常是闲置的。

这就释放了非高峰时段内大量可用的计算资源。利用这些可能的异构资源，以弹性方式合理分配给各种任务。这是Facebook目前正努力探索的一大机会。对于机器学习应用程序，这提供了将可扩展的分布式训练机制的优势应用到大量的异构资源（例如具有不同RAM分配的CPU和GPU平台）的机会。但是，这也会带来一些挑战。在这些低利用率的时期，大量可用的计算资源将从根本上导致分布式训练方法的不同。

调度程序首先必须正确地平衡跨越异构硬件的负载，这样主机就不必为了同步性而等待其他进程的执行。当训练跨越多个主机时，调度程序还必须要考虑网络拓扑结构和同步所需的成本。如果处理不当，机架内或机架间同步所产生的流量可能会很大，这将极大地降低训练的速度和质量。

例如，在1xCPU设计中，四个1xCPU主机共享一个50G的网卡。如果全部四台主机同时尝试与其他主机的梯度进行同步，那么共享的网卡很快就会成为瓶颈，这会导致数据包下降和请求超时。因此，网络之间需要用一个共同的设计拓扑和调度程序，以便在非高峰时段有效地利用闲置的服务器。另外，这样的算法还必须具备能够提供检查指向停止及随着负荷变化重新开始训练的能力。

灾难后恢复能力

能够无缝地处理Facebook一部分全球计算，存储和网络足迹的损失，一直是Facebook基础设施的一个长期目标。Facebook的灾难恢复小组会定期在内部进行演习，找出并补救全球基础设施中最薄弱的环节和软件堆栈。干扰行动包括在几乎没有任何通知情况下，进行整个数据中心离线处理以确认我们全球数据中心的损失对业务造成最小的干扰值。

对于机器学习的训练和推理部分，容灾的重要性是不言而喻的。尽管驱动几个关键性项目的推理过程十分重要这一观点以并不让人意外，但在注意到几个关键产品的可测量退化之前发现其对频繁训练的依赖性依然是一个的惊喜。

下文讨论了三种主要产品频繁机器学习训练的重要性，并讨论为适应这种频繁的训练所需要的基础架构支持，以及这一切是如何耦合到灾难后恢复性的。

如果不训练模型会发生什么？我们分析了三个利用机器学习训练的关键性服务，以确定那些不能频繁执行操作来训练更新模型（包括广告，新闻）和社区诚信所带来的影响。我们的目标是理解在失去训练模型能力的一个星期，一个月，六个月时间内所带来的影响。

第一个明显的影响是工程师的效率，因为机器学习的进度通常与频繁的实验相关。虽然许多模型可以在CPU上进行训练，但是在GPU上训练往往能够显著地提升模型性能。这些加速效果能够让模型迭代时间更快，以及并带来探索更多想法的能力。因此，GPU的损失将导致这些工程师生产力下降。

此外，我们确定了这个问题对Facebook产品的重大影响，特别是对频繁刷新其模型的产品。我们总结了这些产品使用旧模型时出现的问题。

社交安全：创造一个安全的地方让人们分享和连接是Facebook的核心使命。迅速而准确地检测攻击性内容是这项任务的核心。我们的社交安全团队十分依赖使用机器学习技术来检测攻击性的内容文字，图像和视频。攻击性内容检测是一种垃圾邮件检测的专门形式。对抗者会不断地寻找新的、创新性的方法来绕过我们的标识符，向我们的用户展示令人反感的内容。Facebook经常训练模型去学习这些新的模式。每次训练迭代都要花费几天的时间来生成用于检测令人反感的图像的精确模型。我们正在继续推动使用分布式训练技术来更快地训练模型的边界，但是不完全的训练会导致内容退化。
消息推送：我们的发现并不令人惊讶，像消息推送样的产品对机器学习和频繁的模型训练依赖很大。在用户每次访问我们网站的过程中，为其确定最相关的内容，非常依赖先进的机器学习算法来正确查找和排列内容。与其他一些产品不同，Feed排名的学习方式分两步进行：离线步骤是在CPU / GPU上训练最佳模型，在线步骤则是在CPU上进行的持续在线训练。陈旧的消息推送模式对消息质量有着可量化的影响。消息推送团队不断在他们的排名模型上进行创新，并让模型模拟自身，进行几小时的不间断的训练，以此来推进模型的进步。而如果数据中心离线一个星期，带来的训练过程的损失计算就可能会阻碍团队探索新的能力模型和新的参数的进度。
广告：最令人惊讶的是频繁的广告排名模式的训练的重要性。寻找和展示合适的广告极其依赖机器学习及其创新。为了强调这种依赖的重要性，我们了解到，利用过时的机器模型的影响是以小时为单位来衡量的。换句话说，使用一个旧的模型比使用一个仅训练一个小时的模型要糟糕得多。

总的来说，我们的调查强调了机器学习训练对于许多Facebook产品与服务的重要性。在日益增长的工作负荷面前，容灾工作不应该被低估。

容灾架构支持：上图展示了Facebook数据中心的基础架构在全球的分布情况。如果我们关注在训练和推理过程中CPU资源的可用性，那么我们将有充足的计算适应能力来应对几乎每个地区的服务器的损失需求。为GPU资源提供平等冗余的重要性最初被低估了。然而，利用GPU进行训练的初始工作量主要是计算机视觉应用程序和训练这些模型所需的数据，这些训练数据在全球范围内都能被复制得到。当GPUs刚开始被部署到Facebook的基础设施中时，对单一区域进行可管理性操作似乎是明智的选择，直到设计成熟，我们都可以基于他们的服务和维护要求来建立内部的专业知识。这两个因素的结果就是我们将所有生产GPU物理隔离到了另一个数据中心区域。

然而，在那之后会发生了几个关键的变化。由于越来越多的产品采用深度学习技术，包括排名，推荐和内容理解等，GPU计算和大数据的重要性将增加。此外，计算数据托管并复杂化是朝向一个巨型区域战略枢纽的存储方式。大型地区的概念意味着少数数据中心地区将容纳Facebook的大部分数据。顺便说一下，该地区所有的GPU群并没有驻留在大型存储区域。

因此，除了共同定位数据计算的重要性之外，思考什么可能情况将使我们完全失去了搭载GPU的区域，就变得尤为重要。而这个考虑的结果驱使我们为机器学习训练部署多样化GPU的物理位置。

未来的设计方向：硬件、软件和算法

随着模型复杂度和数据集规模的增长，机器学习的计算需求也随之增加。机器学习工作负载反映了许多影响硬件选择的算法和数值的属性。

我们知道，卷积和中等尺寸的矩阵乘法是深度学习前馈和后向过程的关键计算内核。在批处理量较大的情况下，每个参数权重都会被更经常地重用，因此必须进行这些内核在算术强度（每个被访问内存字节的计算操作次数）方面的改进。提高算术强度通常会提高底层硬件的效率，因此在延迟的限制之内，以更大的数据批量运行是可取的做法。计算机器学习负载的上下限将有助于更宽的SIMD单元的使用，及专门的卷积或矩阵乘法引擎、专门的协处理器的部署。

在某些情况下，对每个节点使用小批量数据，在并发查询低的实时推理中或在训练过程中扩展到大量的节点的情况，也是必需的。小的batch规模通常会有较低的算术强度（例如，全连接层中矩阵的矢量乘法运算，本质上是有带宽限制的）。当完整模型不适合片上SRAM单元或最后一级缓存时，这种small batch数据可能会降低几个常见情况的性能。

这个问题可以通过模型压缩，量化和高带宽内存来缓解。模型压缩可以通过和/或量化稀疏来实现。训练期间的稀疏修剪连接（Sparsification prunes connections）会导致一个更小的模型。量化使用定点整数或更窄的浮点格式来压缩模型，而不是用于加权和激活的FP32（单精度浮点）。目前已经有一些使用8位或16位的常用网络，被证明了相当的准确性。还有一些正在进行的研究工作是使用1或2位对模型权重进行压缩。除了减少内存占用量外，修剪和量化还可以通过降低带宽来加速底层硬件，并且允许硬件架构在使用固定点数进行操作时具有更高的计算速率，这比运行FP32值更有效。

缩短训练时间，加快模型传递需要分布式训练。正如在第四节B中讨论的那样，分布式训练需要对网络拓扑结构和调度进行仔细的协同设计，以有效利用硬件并实现良好的训练和质量。正如第III部分B节中描述的，分布式训练中最广泛使用的并行性形式是数据并行性，，这需要同步所有节点的梯度下降，要么同步要么异步。同步SGD需要全部减少操作（all-reduce operation）。当使用递归加倍（和减半）执行时，全部减少操作呈现出来的一个有趣的属性是带宽需求随着递归级别呈指数级下降。

这鼓励了我们进行分层系统的设计，其中的节点在层次结构的底部形成超节点连接（例如，通过高带宽点实现点到点的连接或高位开关）；在层次结构的顶部，超节点通过较慢的网络（例如，以太网）连接。换句话说，异步SGD（不等待其他节点处理批处理）更难，通常需要通过共享参数服务器完成; 节点将其更新发送到参数服务器，该服务器聚合并将其分发回节点。为减少更新的陈旧程度并减轻参数服务器的压力，混合设计可能是个好的思路。在这样的一个设计中，异步更新发生在超节点内具有高带宽和低延迟连接性的本地节点，而同步更新发生在超节点之间。进一步增加扩展性需要增加批量的大小而不是以牺牲收敛性为代价。不管是在Facebook内部还是外部，这都是一个很活跃的算法研究领域。

正如第II部分所描述的，在Facebook上我们的使命是为那些基于机器学习的应用程序构建高性能，节能的机器学习系统。我们正在不断评估和构建新颖的硬件解决方案，并保持算法的变化及其对系统潜在影响的关注。

结论

基于机器学习的工作负载重要性的增加正在影响到系统堆栈的所有部分。对此，计算机体系结构社区如何做出最好的应对策略以及由此产生的挑战将成为大家越来越关注的一个话题。虽然以前我们已经围绕有效地处理ML训练和推理的必要计算进行了大量工作，但是考虑到解决方案在应用到大规模数据时将出现挑战，情况就会发生改变。

在Facebook，我们发现了几个关键因素，这些因素在规模化以及驱动数据中心基础架构的设计决策时非常重要：数据与计算机协同定位的重要性，处理各种机器学习工作负载（不仅仅是计算机视觉）的重要性，由非高峰期的每日循环产生的剩余容量而带来的机会。我们在设计包含定制设计的，易于使用的开源硬件的端到端解决方案，以及平衡性能和可用性的开源软件生态系统时，考虑了上述每一个因素。这些解决方案现在正在服务超过21亿人的大规模机器学习工作负载提供强大的动力，同时也体现了相关专家在跨越机器学习算法和系统设计方面所付出的努力。

原文： https://research.fb.com/wp-content/uploads/2017/12/hpca-2018-facebook.pdf

作者：qq_40027052 发表于 2018/01/23 14:33:26 原文链接 https://blog.csdn.net/qq_40027052/article/details/80133727

阅读：0

Facebook 开源 Detectron

Tue, 23 Jan 2018 20:58:52 CST

Facebook 在 Apache 2.0 许可证下开源了它的目标识别平台 Detectron，源代码托管在 GitHub 上。Detectron 用 Python 开发，基于 Caffe2 深度学习框架。Facebook 同时公开了超过 70 个预先训练的模型。Detectron 项目始于 2016 年，实现了一系列最新的目标识别算法如 Mask R-CNN，该软件平台在社交巨人的视觉感知系统的进步上扮演了重要角色。Facebook 官方博客公布了一幅目标识别的示意图（如图）。

60 TB 数据：Facebook 是如何大规模使用 Apache Spark 的

Sun, 24 Dec 2017 20:00:05 CST

标签： facebook spark

Facebook 经常使用数据驱动的分析方法来做决策。在过去的几年，用户和产品的增长已经需要我们的分析工程师一次查询就要操作数十 TB 大小的数据集。我们的一些批量分析执行在古老的 Hive 平台（ Apache Hive 由 Facebook 贡献于 2009 年）和 Corona 上——这是我们定制的 MapReduce 实现。Facebook 还不断增加其对 Presto 的用量，用于对几个包括 Hive 在内的内部数据存储的 ANSI-SQL 查询。我们也支持其他分析类型，比如图数据库处理graph processing和机器学习（ Apache Giraph）和流（例如： Puma、 Swift 和 Stylus）。

同时 Facebook 的各种产品涵盖了广泛的分析领域，我们与开源社区不断保持沟通，以便共享我们的经验并从其他人那里学习。 Apache Spark 于 2009 年在加州大学伯克利分校的 AMPLab 由 Matei Zaharia 发起，后来在2013 年贡献给 Apache。它是目前增长最快的数据处理平台之一，由于它能支持流、批量、命令式（RDD）、声明式（SQL）、图数据库和机器学习等用例，而且所有这些都内置在相同的 API 和底层计算引擎中。Spark 可以有效地利用更大量级的内存，优化整个流水线（pipeline）中的代码，并跨任务重用 JVM 以获得更好的性能。最近我们感觉 Spark 已经成熟，我们可以在一些批量处理用例方面把它与 Hive 相比较。在这篇文章其余的部分，我们讲述了在扩展 Spark 来替代我们一个 Hive 工作任务时的所得到经验和学习到的教训。

用例：实体排名的特征准备

Facebook 会以多种方式做实时的实体（entity）排名。对于一些在线服务平台，原始特征值是由 Hive 线下生成的，然后将数据加载到实时关联查询系统。我们在几年前建立的基于 Hive 的老式基础设施属于计算资源密集型，且很难维护，因为其流水线被划分成数百个较小的 Hive 任务。为了可以使用更加新的特征数据和提升可管理性，我们拿一个现有的流水线试着将其迁移至 Spark。

以前的 Hive 实现

基于 Hive 的流水线由三个逻辑阶段（stage）组成，每个阶段对应由 entity_id 划分的数百个较小的 Hive 作业，因为在每个阶段运行大型 Hive 作业（job）不太可靠，并受到每个作业的最大任务（task）数量的限制。

这三个逻辑阶段可以总结如下：

过滤出非产品的特征和噪点。
在每个（entity_id, target_id）对上进行聚合。
将表格分割成 N 个分片，并通过自定义二进制文件管理每个分片，以生成用于在线查询的自定义索引文件。

基于 Hive 的流水线建立该索引大概要三天完成。它也难于管理，因为该流水线包含上百个分片的作业，使监控也变得困难。同时也没有好的方法来估算流水线进度或计算剩余时间。考虑到 Hive 流水线的上述限制，我们决定建立一个更快、更易于管理的 Spark 流水线。

Spark 实现

全量的调试会很慢，有挑战，而且是资源密集型的。我们从转换基于 Hive 流水线的最资源密集型的第二阶段开始。我们以一个 50GB 的压缩输入例子开始，然后逐渐扩展到 300GB、1TB，然后到 20TB。在每次规模增长时，我们都解决了性能和稳定性问题，但是实验到 20TB 时，我们发现了最大的改善机会。

运行 20TB 的输入时，我们发现，由于大量的任务导致我们生成了太多输出文件（每个大小在 100MB 左右）。在 10 小时的作业运行时中，有三分之一是用在将文件从阶段目录移动到 HDFS 中的最终目录。起初，我们考虑两个方案：要么改善 HDFS 中的批量重命名来支持我们的用例，或者配置 Spark 生成更少的输出文件（这很难，由于在这一步有大量的任务 — 70000 个）。我们退一步来看这个问题，考虑第三种方案。由于我们在流水线的第二步中生成的 tmp_table2 表是临时的，仅用于存储流水线的中间输出，所以对于 TB 级数据的单一读取作业任务，我们基本上是在压缩、序列化和复制三个副本。相反，我们更进一步：移除两个临时表并整合 Hive 过程的所有三个部分到一个单独的 Spark 作业，读取 60TB 的压缩数据然后对 90TB 的数据执行重排（shuffle）和排序（sort）。最终的 Spark 作业如下：

对于我们的作业如何规划 Spark？

当然，为如此大的流水线运行一个单独的 Spark 任务，第一次尝试没有成功，甚至是第十次尝试也没有。据我们所知，从重排（shuffle）的数据大小来说，这是现实世界最大的 Spark 作业（ Databrick 的 PB 级排序是以合成数据来说）。我们对核心 Spark 基础架构和我们的应用程序进行了许多改进和优化使这个作业得以运行。这种努力的优势在于，许多这些改进适用于 Spark 的其他大型作业任务，我们将所有的工作回馈给开源 Apache Spark 项目 - 有关详细信息请参阅 JIRA。下面，我们将重点讲述将实体排名流水线之一部署到生产环境所做的重大改进。

可靠性修复

处理频繁的节点重启

为了可靠地执行长时间运行作业，我们希望系统能够容错并可以从故障中恢复（主要是由于平时的维护或软件错误导致的机器重启所引发的）。虽然 Spark 设计为可以容忍机器重启，但我们发现它在足够强健到可以处理常见故障之前还有各种错误/问题需要解决。

使 PipedRDD 稳健的 获取（fetch）失败（SPARK-13793）：PipedRDD 以前的实现不够强大，无法处理由于节点重启而导致的获取失败，并且只要出现获取失败，该作业就会失败。我们在 PipedRDD 中进行了更改，优雅的处理获取失败，使该作业可以从这种类型的获取失败中恢复。
可配置的最大获取失败次数（SPARK-13369）：对于这种长时间运行的作业，由于机器重启而引起的获取失败概率显着增加。在 Spark 中每个阶段的最大允许的获取失败次数是硬编码的，因此，当达到最大数量时该作业将失败。我们做了一个改变，使它是可配置的，并且在这个用例中将其从 4 增长到 20，从而使作业更稳健。
减少集群重启混乱：长时间运行作业应该可以在集群重启后存留，所以我们不用等着处理完成。Spark 的可重启的重排（shuffle）服务功能可以使我们在节点重启后保留重排（shuffle）文件。最重要的是，我们在 Spark 驱动程序中实现了一项功能，可以暂停执行任务调度，所以不会由于集群重启而导致的过多的任务失败，从而导致作业失败。

其他的可靠性修复

响应迟钝的驱动程序（SPARK-13279）：在添加任务时，由于 O(N ^ 2) 复杂度的操作，Spark 驱动程序被卡住，导致该作业最终被卡住和死亡。我们通过删除不必要的 O(N ^ 2) 操作来修复问题。
过多的驱动 推测（speculation）：我们发现，Spark 驱动程序在管理大量任务时花费了大量的时间推测。在短期内，我们禁止这个作业的推测。在长期，我们正在努力改变 Spark 驱动程序，以减少推测时间。
由于大型缓冲区的整数溢出导致的 TimSort 问题（SPARK-13850）：我们发现 Spark 的不安全内存操作有一个漏洞，导致 TimSort 中的内存损坏。感谢 Databricks 的人解决了这个问题，这使我们能够在大内存缓冲区中运行。
调整重排（shuffle）服务来处理大量连接：在重排阶段，我们看到许多执行程序在尝试连接重排服务时超时。增加 Netty 服务器的线程（spark.shuffle.io.serverThreads）和积压（spark.shuffle.io.backLog）的数量解决了这个问题。
修复 Spark 执行程序 OOM（SPARK-13958）（deal maker）：首先在每个主机上打包超过四个聚合（reduce）任务是很困难的。Spark 执行程序会内存溢出，因为排序程序（sorter）中存在导致无限增长的指针数组的漏洞。当不再有可用的内存用于指针数组增长时，我们通过强制将数据溢出到磁盘来修复问题。因此，现在我们可以每主机运行 24 个任务，而不会内存溢出。

性能改进

在实施上述可靠性改进后，我们能够可靠地运行 Spark 作业了。基于这一点，我们将精力转向与性能相关的项目，以充分发挥 Spark 的作用。我们使用 Spark 的指标和几个分析器来查找一些性能瓶颈。

我们用来查找性能瓶颈的工具

Spark UI 指标：Spark UI 可以很好地了解在特定阶段所花费的时间。每个任务的执行时间被分为子阶段，以便更容易地找到作业中的瓶颈。
Jstack：Spark UI 还在执行程序进程上提供了一个按需分配的 jstack 函数，可用于中查找热点代码。
Spark 的 Linux Perf / 火焰图（Flame Graph）支持：尽管上述两个工具非常方便，但它们并不提供同时在数百台机器上运行的作业的 CPU 分析的聚合视图。在每个作业的基础上，我们添加了支持 Perf 分析（通过 libperfagent 的 Java 符号），并可以自定义采样的持续时间/频率。使用我们的内部指标收集框架，将分析样本聚合并显示为整个执行程序的火焰图。

性能优化

修复 排序程序（sorter）中的内存泄漏（SPARK-14363）（30％速度提升）：我们发现了一个问题，当任务释放所有内存页时指针数组却未被释放。因此，大量的内存未被使用，并导致频繁的溢出和执行程序 OOM。我们现在进行了改变，正确地释放内存，并使大的分类运行更有效。我们注意到，这一变化后 CPU 改善了 30％。
Snappy 优化（SPARK-14277）（10％速度提升）：有个 JNI 方法（Snappy.ArrayCopy）在每一行被读取/写入时都会被调用。我们发现了这个问题，Snappy 的行为被改为使用非 JNI 的 System.ArrayCopy 代替。这一改变节约了大约 10％的 CPU。
减少重排的写入延迟（SPARK-5581）（高达 50％的速度提升）：在映射（map）方面，当将重排数据写入磁盘时，映射任务为每个分区打开并关闭相同的文件。我们做了一个修复，以避免不必要的打开/关闭，对于大量写入重排分区的作业来说，我们观察到高达 50％的 CPU 提升。
解决由于获取失败导致的重复任务运行问题（SPARK-14649）：当获取失败发生时，Spark 驱动程序会重新提交已运行的任务，导致性能下降。我们通过避免重新运行运行的任务来解决这个问题，我们看到当获取失败发生时该作业会更加稳定。
可配置 PipedRDD 的缓冲区大小（SPARK-14542）（10％速度提升）：在使用 PipedRDD 时，我们发现将数据从分类程序传输到管道进程的默认缓冲区的大小太小，我们的作业要花费超过 10％的时间复制数据。我们使缓冲区大小可配置，以避免这个瓶颈。
缓存索引文件以加速重排获取（SPARK-15074）：我们观察到重排服务经常成为瓶颈，减少程序（reducer）花费 10％至 15％的时间等待获取映射（map）数据。通过深入了解问题，我们发现，重排服务为每个重排获取打开/关闭重排索引文件。我们进行了更改以缓存索引信息，以便我们可以避免文件打开/关闭，并重新使用该索引信息以便后续获取。这个变化将总的重排时间减少了 50％。
降低重排字节写入指标的更新频率（SPARK-15569）（高达 20％的速度提升）：使用 Spark 的 Linux Perf 集成，我们发现大约 20％的 CPU 时间正在花费探测和更新写入的重排字节写入指标上。
可配置排序程序（sorter）的初始缓冲区大小（SPARK-15958）（高达 5％的速度提升）：排序程序（sorter）的默认初始缓冲区大小太小（4 KB），我们发现它对于大型工作负载而言非常小 - 所以我们在缓冲区耗尽和内容复制上浪费了大量的时间。我们做了一个更改，使缓冲区大小可配置，并且缓冲区大小为 64 MB，我们可以避免大量的数据复制，使作业的速度提高约 5％。
配置任务数量：由于我们的输入大小为 60T，每个 HDFS 块大小为 256M，因此我们为该作业产生了超过 250,000 个任务。尽管我们能够以如此多的任务来运行 Spark 作业，但是我们发现，当任务数量过高时，性能会下降。我们引入了一个配置参数，使映射（map）输入大小可配置，因此我们可以通过将输入分割大小设置为 2 GB 来将该数量减少 8 倍。

在所有这些可靠性和性能改进之后，我们很高兴地报告，我们为我们的实体排名系统之一构建和部署了一个更快、更易于管理的流水线，并且我们提供了在 Spark 中运行其他类似作业的能力。

Spark 流水线与 Hive 流水线性能对比

我们使用以下性能指标来比较 Spark 流水线与 Hive 流水线。请注意，这些数字并不是在查询或作业级别的直接比较 Spark 与 Hive ，而是比较使用灵活的计算引擎（例如 Spark）构建优化的流水线，而不是比较仅在查询/作业级别（如 Hive）操作的计算引擎。

CPU 时间：这是从系统角度看 CPU 使用。例如，你在一个 32 核机器上使用 50% 的 CPU 10 秒运行一个单进程任务，然后你的 CPU 时间应该是 32 * 0.5 * 10 = 160 CPU 秒。

CPU 预留时间：这是从资源管理框架的角度来看 CPU 预留。例如，如果我们保留 32 位机器 10 秒钟来运行作业，则CPU 预留时间为 32 * 10 = 320 CPU 秒。CPU 时间与 CPU 预留时间的比率反映了我们如何在集群上利用预留的CPU 资源。当准确时，与 CPU 时间相比，预留时间在运行相同工作负载时可以更好地比较执行引擎。例如，如果一个进程需要 1 个 CPU 的时间才能运行，但是必须保留 100 个 CPU 秒，则该指标的效率要低于需要 10 个 CPU 秒而仅保留 10 个 CPU 秒来执行相同的工作量的进程。我们还计算内存预留时间，但不包括在这里，因为其数字类似于 CPU 预留时间，因为在同一硬件上运行实验，而在 Spark 和 Hive 的情况下，我们不会将数据缓存在内存中。Spark 有能力在内存中缓存数据，但是由于我们的集群内存限制，我们决定类似与 Hive 一样工作在核心外部。

等待时间：端到端的工作流失时间。

结论和未来工作

Facebook 的性能和可扩展的分析在产品开发中给予了协助。Apache Spark 提供了将各种分析用例统一为单一 API 和高效计算引擎的独特功能。我们挑战了 Spark，来将一个分解成数百个 Hive 作业的流水线替换成一个 Spark 作业。通过一系列的性能和可靠性改进之后，我们可以将 Spark 扩大到处理我们在生产中的实体排名数据处理用例之一。在这个特殊用例中，我们展示了 Spark 可以可靠地重排和排序 90 TB+ 的中间数据，并在一个单一作业中运行了 25 万个任务。与旧的基于 Hive 的流水线相比，基于 Spark 的流水线产生了显着的性能改进（4.5-6 倍 CPU，3-4 倍资源预留和大约 5 倍的延迟），并且已经投入使用了几个月。

虽然本文详细介绍了我们 Spark 最具挑战性的用例，越来越多的客户团队已将 Spark 工作负载部署到生产中。性能、可维护性和灵活性是继续推动更多用例到 Spark 的优势。 Facebook 很高兴成为 Spark 开源社区的一部分，并将共同开发 Spark 充分发挥其潜力。

您可能还对下面的文章感兴趣：

Spark性能优化——和shuffle搏斗 [2016-06-06 23:43:17]
Spark的性能调优 [2016-02-06 23:58:32]
一步一步教你怎样给Apache Spark贡献代码 [2014-10-15 22:43:22]
Spark：一个高效的分布式计算系统 [2013-09-15 22:40:29]
Spark随谈——开发指南（译） [2012-07-27 14:22:18]

九个问题，搞清楚Facebook的广告系统是如何运作的

Tue, 17 Oct 2017 12:39:01 CST

根据国外的科技媒体报道，谷歌和 Facebook 几乎合占全球数字广告市场的半壁江山。谷歌自是不消多说，它的搜索引擎业务有着极为庞大的用户群体，依靠搜索广告和与网页内容相关的广告，它被称为新时代的“印钞机”。但是，Facebook 则不相同，它是一个社交媒体网络服务平台，虽然用户众多，但在它的应用场景中，广告变现并不占优势。它是怎样做到在广告业务上与谷歌分庭抗礼呢？近日， The New York Times 发表了一篇文章介绍了 Facebook 的广告系统的运作方式，由 36 氪编译。

Facebook 的广告比其他广告更特殊吗？

Facebook 的主要广告系统，可以直接插入到作为其社交网络的主要界面的动态消息流（News Feed）之中。这个广告系统的创建是为了达到一种效果，让广告可以像互联网公司所谓的“有机内容”一样，能够有效地吸引用户的注意力。

实际上，广告的形式往往和“有机内容”一样，只是背后有金钱交易。宾夕法尼亚大学沃顿商学院市场营销学教授 Ron Berman 说：“这是一种广告销售机制，但广告本身并不是真正的广告，而是一种内容。”他对 Facebook 广告系统在内的在线广告业务颇有研究。

过去 10 年，Facebook 作为一种重要力量，促进了在线广告领域缓慢发生了重大的变化。随着越来越多的人将在线活动从个人电脑转移到移动手机上，广告和“有机内容”之间的界限越来越模糊，尤其是在 Instagram、Twitter 和 Facebook 等流行的社交网络服务上。

为什么手机会促进这种改变？

最直接的原因在于，移动手机在屏幕上提供的广告空间更小。通常只有一个信息栏的空间，来同时容纳广告和其他内容。所以，就出现了这种广告进入更为显著位置的结果。

可以拿谷歌的搜索引擎做个例子。如果用户在笔记本电脑上输入“三星”一词，三星的广告很可能会出现在屏幕上方，超过谷歌给出的搜索结果列表。当你在普通的智能手机上做同样的事情，这则广告可能会占据整个屏幕。

为了应对这种屏幕的限制，Facebook 采取了一个更加“深入”的解决办法。它创造了一个新的广告系统，使广告成为在移动电话屏幕上占据主导地位的 News Feed 的一个组成部分。

Facebook 的广告到底是什么？

简单来说，就是由企业和其他组织在社交网络上建立起来的 Facebook 页面。Facebook 允许企业和其他广告商根据特定兴趣和行为，将页面直接送达到与他们没有任何关联的用户的 News Feed 中。

随着这些页面的出现，人们可以对它们发表评论，并“喜欢（Like）”它们，就像信息流中显示的其他内容一样。如果人们点击“Like”按钮，这些页面将继续显示在他们的信息流中，以及他们 Facebook“好友”的信息流中。

客户投放的广告能有多精准？

在 Facebook 上，人们会自我描述，留下各种各样的数字面包屑（bread crumbs ）来显示他们的兴趣。根据 Facebook 官方的介绍，主要数据来源为：用户在 Facebook 分享的信息（例如：您点赞的主页）来自用户 Facebook 帐户的其他个人信息（例如：年龄、性别、位置和访问 Facebook 所用的设备等）广告主和市场营销合作伙伴向我们分享的关于用户的信息，如用户的电子邮箱用户在 Facebook 之外的网站和应用中的活动。然后 Facebook 将这些数据与它收集的其他数据进行匹配。

Facebook 的广告系统提供了基于地理位置、个人兴趣、特征和行为的方法，包括在其他互联网服务上的活动，甚至在线下的活动。广告主可以根据政治立场来“命中”目标用户;他们有多大可能参与政治内容;他们是否喜欢慢跑、远足或打猎;他们喜欢什么样的啤酒;诸如此类的信息。

如果广告主提供了一个电子邮件地址列表，Facebook 可以尝试将这些地址所有者作为目标。它还可以做“相似匹配”。在这种情况下，Facebook 的算法会向被认为与这些地址所有者类似的用户提供广告。

这一切是怎么发生的？

考虑到有许多广告主的出价，与谷歌和其他公司一样，Facebook 对每一个广告投放进行实时的“数字拍卖”。广告主可能会出价 2 美元在特定情况下投放广告。然后，Facebook 对这些报价进行了权衡，看广告是否与这种特定的情况有关。如果广告是相关的，那么广告主就不没有必要出太高的价格去赢得拍卖。

与其他在线网站提供的类似服务不同，Facebook 并不仅仅只考虑广告与其他广告的相关性。它还会考虑广告与其他内容的相关性如何，会根据其与“有机内容”的竞争程度来选择广告。

广告和内容难道不应该分开吗？

谷歌表示，提供“有机内容”和广告管理的团队是分开的，而且独立的技术。“有机内容”的推荐算法不考虑广告，反之亦然。

Facebook 的安排略有不同，因为广告招标也考虑了与“有机内容”的契合度。此外，广告还会通过算法和管理员来审核，以确定广告是否违反了公司的政策。Facebook 最近表示，它将在审查广告的团队中再增加 1000 名版主。

Instagram 和 Twitter 呢？

从 2015 年秋天开始，Facebook 的广告引擎也开始在 Instagram 上推送广告。Twitter 与这些服务略有不同，但基础的逻辑是相似的。Twitter 的广告，仅仅是企业和其他公司付费，在符合特定标准的人的信息流中发布内容。

Facebook 中广告与常规内容没有分离吗？

正如这些公司所指出的那样，付费广告是广告或“赞助”或“推广”的内容。Facebook 的高管们补充说，广告通常也包括一些行动呼吁，比如“Liking”。

Facebook 负责广告产品的副总裁 Rob Goldman 在一份声明中表示，管理广告的用户和管理广告的人可以协调自己的工作，但在目标和政策各不相同的组织中工作。

“我们的目标是，在 Facebook 上投放广告，对用户来说，和他们从朋友和家人那里看到的帖子一样有用，”Goldman 说，“但我们也希望用户知道他们在看的内容是广告，所以我们清楚地把这些内容标记为‘赞助’。”

但是，广告和“有机内容”之间的界限已经变得模糊，这可能是不明显的。例如，如果你“Like”一个广告，来自同一个账户的帖子会自动出现在你的信息流中，没有付费推广，也没有“赞助”标签。

Berman 说，这些帖子不仅仅是免费的广告，还包括人们认为更可信的东西，而且 Facebook 更有可能在这些人的“朋友”的信息流中分享。在 Facebook 这样的服务上，广告的效果远远超出了广告主的付费范围。

还有哪些细节需要注意？

Berman 表示，当前已经发表的学术研究，包括他自己的一项研究表明，人们更有可能分享耸人听闻的内容，因为这些会让用户产生情感反应。其中可能包括与枪支管制、同性恋权利或种族关系相关的帖子。

如果一个广告商发布了一个被广泛分享或者“Like”的广告，将会有跟多的免费广告被投放。这意味着下一个广告的成本会下降。就目前而言，这种循环还在继续。

本文链接

开源 | 微软、Facebook联手打造AI生态系统ONNX

Fri, 08 Sep 2017 20:49:02 CST

编者按：今日，微软和Facebook宣布将推出Open Neural Network Exchange（ONNX，开放神经网络交换）格式，这是一个用于表示深度学习模型的标准，可使模型在不同框架之间进行迁移。

ONNX是迈向开放生态系统的第一步，AI开发人员可以轻松地在最先进的工具之间转换，并选择最适合他们的组合。ONNX的应用能够弥合实验和生产过程中框架特征不一致产生的差异，让AI开发人员可以选择符合项目当前阶段的框架并实现自主切换。本文转载自公众号“新智元”。英文原文链接：https://www.microsoft.com/en-us/cognitive-toolkit/blog/2017/09/microsoft-facebook-create-open-ecosystem-ai-model-interoperability/

微软一直以来坚持一个信念：将AI传递给更多的人，让每个人都能够亲身感受到技术进步带来的便利。因此，我们为大家提供很多行之有效的平台和工具，包括微软认知工具包，构建深层神经网络的开源框架，以促进AI的普及进程。我们还积极与其他组织展开合作，共同探讨行业问题、寻求解决方案。

今天，我们高兴地宣布，微软和Facebook一起推出Open Neural Network Exchange (ONNX，开放神经网络交换) 格式。 ONNX为AI框架生态系统中的互操作性和创新提供了共享的模型表征。Cognitive Toolkit、Caffe2和PyTorch都将支持ONNX。微软和Facebook共同开发了ONNX这一开源项目，并希望社区能够帮助其不断进化。

什么是ONNX表征？

Cognitive Toolkit和其他框架提供了使开发人员更容易构建和运行用来表征神经网络的计算图的界面。虽然它们提供的功能类似，但是每个框架都有自己的格式对这些图进行表征。 ONNX表征有以下主要优点：

框架互操作性：开发人员可以更轻松地在框架间转换，并为手头的任务选择最佳工具。每个框架都针对具体特性进行了优化，如快速训练，支持灵活的网络架构，在移动设备上进行推理等等。许多时候，研发过程中最重要的特性与生产环节最重要的特性是不同的。这导致开发人员在框架之间进行模型转换时，会因框架使用不正确或明显延迟而使得效率降低。使用ONNX表征的框架简化了这一点，使得开发人员更加灵活。

共享优化：硬件供应商对神经网络性能的优化可以通过定位ONNX表征来同时影响多个框架。优化经常需要被分别整合进入每个框架，这一过程很费时间。ONNX 表征使得优化更容易实现，从而覆盖更多开发人员。

ONNX技术总结

ONNX提供了可扩展计算图模型的定义，以及内置运算器和标准数据类型的定义。起初，我们专注于推理所需的能力（评估）。

每个计算数据流图被构造为形成非循环图的节点列表。节点具有一个或多个输入和输出。每个节点是对一个运算器的调用。该图还包含记录其目的、作者等信息的元数据。

运算器在图外部实现，但是内置运算器的集合在框架之间是可移植的。支持ONNX的每个框架都将提供这些运算器在适用数据类型上的实现。

ONNX的可用性

ONNX代码和文档的初始版本现在已经在GitHub（https://github.com/onnx/onnx）上开源。我们将积极开展基于ONNX的工作，即将推出的Cognitive Toolkit新版本将支持ONNX。我们还计划和Facebook一道，提供部署参考、示例、工具等。

ONNX表征形成了开放生态系统的基础，使AI更容易获取并富有价值。开发人员可以为其任务选择合适的框架，框架作者可以专注于创新，硬件供应商可以简化优化流程。我们希望社区能够支持ONNX，以实现这一令人兴奋的愿景。

来自Facebook的一些MySQL运维经验

Sun, 21 May 2017 00:12:18 CST

1. 概要

每台机器都使用多实例的模型。每个机器放多个实例，每个实例放多个DB。

一些信息可以参考： https://www.youtube.com/watch?v=UBHcmP2TSvk

多实例之间没有进行资源隔离，这么做是让每个实例都能发挥最大性能。

目前大部分核心业务已切换成MyRocks引擎，在机器硬件配置不变的情况，约可节省一半机器。

放在MyRocks上的核心业务主要有：Feed、Post、社交图谱等读写混合业务。

MyRocks项目地址：https://github.com/facebook/mysql-5.6

另外，MariaDB 10.2版本也即将整合MyRocks引擎。

2. 高可用机制

采用基于GTID的一主多从结构，外加一个基于lossless semi-sync机制的mysqlbinlog实现的binlog server（可以理解为MySQL 5.7的loss zero replication）。

基于多数派实现自动选主。

基于配置中心实现切换，未使用VIP。

在认为semi-sync复制可保证主从数据一致性的假设前提下，发生故障切换时，利用上述的binlog server中的日志进行补全后再选新主、切换。

若个别情况下由于特殊原因，出现从库全部挂掉的情况，会将全部请求切到主库，由它扛起所有的业务服务压力。

某个从库挂掉时，可以动态摘除。

3. 备份机制

所有的备份都是基于mysqldump实现，之所以采用mysqldump逻辑备份好处有：

无需备份索引，只备份数据；
备份文件压缩比高，更节省磁盘空间；
改进了mysqldump，备份过程中还进行额外压缩；

上面提到，因为采用多实例、多DB结构，备份时可以多DB并行备份。当然了，也会控制并行备份的数量，避免影响在线业务性能。

备份放在集中存储（HDFS）上，据说已达EB级别容量。

关于备份的作用定位：

供数据分析环境拉数据
供灾难恢复

4. 如何快速部署从库

可使用xtrabackup在现有存活的SLAVE实例上备份，也可在主库上发起备份，再利用WDT（或者是BT）协议传输到异地，用于拉起从库。

关于WDT项目：https://github.com/facebook/wdt

5. 高度自动化

面对大规模的数据库实例，手工处理完全不现实。目前在facebook主要是利用Python开发内部DB运维平台，所以Python技能方面要求比较高。

采用他们自已的osc工具执行Online DDL（也是本次DTCC大会上lulu的分享主题），它最早用PHP开发，虽早已开源，但实在不好用，所以几乎只在内部使用。这个工具不同于pt-osc，相对来说更有优势，比如可以避免使用pt-osc最常遇到的主从数据延迟问题。

项目地址： https://github.com/facebookincubator/OnlineSchemaChange

6. 团队结构及技能树

DBA团队更多的是负责私有DB云平台的建设。

Schema设计及DB拆分等由性能优化团队负责。

在线表结构变更：数据库资源申请由质量服务团队负责，做到资源的合理分布、分配，如果某个业务只需要个位数级别的DB实例，可以自行在私有DB云平台中申请部署，当数量比较大时，需要先经过质量服务团队评估通过。

数据库资源申请由质量服务团队负责，做到资源的合理分布、分配。如果某个业务需要小量DB实例，可以自行在私有DB云平台中申请部署；当数量比较大时，需要先经过质量服务团队评估通过才可以。

文章来自微信公众号：云DB

Facebook提出全新CNN机器翻译：准确度超越谷歌而且还快九倍（已开源）

Thu, 11 May 2017 08:00:00 CST

选自code.facebook

作者：Jonas Gehring、Michael Auli、David Grangier、Denis Yarats、Yann N. Dauphin

机器之心编译

参与：吴攀、微胖、蒋思源

去年谷歌在机器翻译上取得了连续不断的突破，参阅《重磅 | 谷歌翻译整合神经网络：机器翻译实现颠覆性突破》和《重磅 | 谷歌神经机器翻译再突破：实现高质量多语言翻译和 zero-shot 翻译》。谷歌的方法用到了文本处理惯用的循环神经网络。近日，Facebook 也宣布在神经机器翻译上取得了重大进展，在超过了去年谷歌研究的水平的同时还实现了显著的速度提升。而和谷歌的方法不一样，Facebook 的方法采用了一种完全基于卷积神经网络的架构。机器之心对 Facebook 博客上的介绍文章进行编译，同时在文末附上了该研究论文的摘要介绍，另外该研究的相关源代码和模型也已经在 GitHub 上开源。

论文地址：https://s3.amazonaws.com/fairseq/papers/convolutional-sequence-to-sequence-learning.pdf
GitHub 项目地址：https://github.com/facebookresearch/fairseq

Facebook 的使命是让世界更加开放和互联，让每个人都能以自己偏好的语言享受视频和博文——当然，准确度和速度要尽可能最高。因此，语言翻译就显得很重要了。

今天，FAIR 团队推出了一项研究成果：使用一种全新的卷积神经网络（CNN）进行语言翻译，结果以 9 倍于以往循环神经网络（CNN）的速度实现了目前最高准确率。[1] 另外，你可以在 GitHub 开源许可下下载到 FAIR 序列模型工具包（fairseq）源代码和训练过的系统，研究人员可以打造用于翻译、文本摘要以及针对其他任务的定制化模型。

为什么是 CNN？

几十年前，最初由 Yann LeCun 开发的 CNN 已经成功用于多个机器学习领域，比如图像处理。不过，对于文本应用来说，因为 RNN 的高准确度，其已经当仁不让地成为了被最广泛采用的技术和语言翻译的最佳选择。

尽管历史表明，在语言翻译任务上，RNN 胜过 CNN，但其内在设计是有局限性，只要看看它是如何处理信息的就能明白这一点。计算机的翻译办法是：阅读某种语言句子，然后预测在另一种语言中相同含义的语词排列顺序。RNN 运行严格遵照从左到右或者从右到左的顺序，一次处理一个单词。这一运行方式并不天然地契合驱动现代机器学习系统的高度并行的 GPU 硬件。由于每个单词必须等到网络处理完前一个单词，因此计算并不是完全并行的。对比之下，CNN 能够同时计算所有元素，充分利用了 GPU 的并行，计算也因此更高效。CNN 的另一个优势就是以分层的方式处理信息，因此，捕捉数据中的复杂关系也更容易些。

在之前的研究中，被用于翻译任务的 CNN 的表现并不比 RNN 出色。然而，鉴于 CNN 架构潜力，FAIR 开始研究将 CNN 用于翻译，结果发现了一种翻译模型设计，该设计能够让 CNN 的翻译效果也很出色。鉴于 CNN 更加出色的计算效率，CNN 还有望扩大翻译规模，将世界上 6,500 多种语言（世界语言种类大约为 6,900 多种——译者注）纳入翻译范围。

在速度上达到当前最佳

我们的研究结果表明，与 RNN [2] 相比，我们的系统在由机器翻译协会（WMT）提供的广泛使用的公共基准数据集上达到了新的最佳效果。特别是，CNN 模型在 WMT 2014 英语-法语任务（该度量标准被广泛用于判断机器翻译的准确度）上超过了之前最佳结果 1.5 BLEU。我们的模型在 WMT 2014 英语-德语任务上提高了 0.5 BLEU，在 WMT 2016 英语-罗马尼亚语上提高了 1.8 BLEU。

对于实际应用，神经机器翻译的一个考量因素是我们为系统提供一个句子后，它到底需要多长时间进行翻译。FAIR CNN 模型在计算上十分高效，它要比强 RNN 系统快九倍左右。许多研究聚焦于量化权重或浓缩（distillation）等方法来加速神经网络，而它们同样也可被用于本 CNN 模型，甚至提速的效果还要大些，表现出了显著的未来潜力。

利用多跳注意（multi-hop attention）和门控（gating）来改善翻译效果

在我们模型架构中，一个明显不同的组件就是多跳注意，这个机制就像人类翻译句子时会分解句子结构：不是看一眼句子接着头也不回地翻译整个句子，这个网络会反复「回瞥（glimpse）」句子，选择接下来翻译哪个单词，这点和人类更像：写句子时，偶然回过头来看一下关键词。[3] 多跳注意是这一机制的增强版本，可以让神经网络多次「回瞥」，以生成更好的翻译效果。多次「回瞥」也会彼此依存。比如，头次「回瞥」关注动词，那么，第二次「回瞥」就会与助动词有关。

在下图中，我们给出了该系统读取法语短语（编码）并输出其英语翻译（解码）的情形。我们首先使用一个 CNN 运行其编码器以为每个法语词创建一个向量，同时完成计算。接下来，其解码器 CNN 会一次得到一个英语词。在每一步，该注意都会「回瞥」原法语句子来确定翻译句子中最相关的下一个英语词。解码器中有两个所谓的层，下面的动画给出了每层中注意完成的方式。绿线的强度表示了该网络对每个法语词的关注度。当该网络被训练时，其一直可以提供翻译，同时也可以完成对英语词的计算。

我们的系统另一方面是门控（gating），其控制了神经网络中的信息流。在每一个神经网络中，信息流也就是通过隐藏单元的数据。我们的门控机制将具体控制哪些信息应该需要传递到下一个神经元中，以便产生一个优良的翻译效果。例如，当预测下一个词时，神经网络会考虑迄今为止完成的翻译。而门控允许放大翻译中一个特定的方面或取得广义的概览，这一切都取决于神经网络在当前语境中认为哪个是适当。

未来开发

这种方法是一种可选的机器翻译架构，也为其它文本处理任务开启了新的大门。比如说，在对话系统中的多跳注意（multi-hop attention）让神经网络可以关注到对话中距离较远的部分（比如两个分开的事实），然后将它们联系到一起以便更好地对复杂问题作出响应。

以下为相关论文的摘要介绍：

论文：卷积序列到序列学习（Convolutional Sequence to Sequence Learning）

序列到序列学习（sequence to sequence learning）的普遍方法是通过循环神经网络将一个输入序列映射到一个可变长度的输出序列。我们引入了一种完全基于卷积神经网络的架构。相比于循环模型，其在训练阶段中所有元素上的计算都是完全并行的，且其优化更简单，因为非线性的数量是固定的且独立于输入的长度。我们使用门控线性单元简化了梯度传播（gradient propagation），而且我们为每个解码器层都装备了一的单独的注意模块（attention module）。我们在 WMT'14 英语-德语翻译和 WMT'14 英语-法语翻译上的准确度表现都超过了 Wu et al. (2016) 的深度 LSTM 设置，且在 GPU 和 CPU 上的速度都实现了一个数量级的提升。

图 1：训练中批处理（batching）的图示。顶部是英语源句子被编码，同时我们为 4 个德语目标词计算所有的注意值（中间）。我们的注意只是解码器上下文表征（底部左侧）和编码器表征之间的点积。我们为解码器上下文增加了由该注意模块计算出来的条件输入（中部右侧），其可以预测目标词（底部右侧）。S 型和乘法框表示门控线性单元。

博客文章参考文献

[1] Convolutional Sequence to Sequence Learning. Jonas Gehring, Michael Auli, David Grangier, Denis Yarats, Yann N. Dauphin.（即本论文）

[2] Google‘s Neural Machine Translation System: Bridging the Gap between Human and Machine Translation. Yonghui Wu, Mike Schuster, Zhifeng Chen, Quoc V. Le, Mohammad Norouzi, Wolfgang Macherey, Maxim Krikun, Yuan Cao, Qin Gao, Klaus Macherey, Jeff Klingner, Apurva Shah, Melvin Johnson, Xiaobing Liu, Łukasz Kaiser, Stephan Gouws, Yoshikiyo Kato, Taku Kudo, Hideto Kazawa, Keith Stevens, George Kurian, Nishant Patil, Wei Wang, Cliff Young, Jason Smith, Jason Riesa, Alex Rudnick, Oriol Vinyals, Greg Corrado, Macduff Hughes, Jeffrey Dean. Technical Report, 2016. 参考机器之心文章《重磅 | 谷歌翻译整合神经网络：机器翻译实现颠覆性突破（附论文）》

[3] Neural Machine Translation by Jointly Learning to Align and Translate. Dzmitry Bahdanau, Kyunghyun Cho, Yoshua Bengio. International Conference on Learning Representations, 2015. 地址：https://arxiv.org/abs/1409.0473

原文链接：https://code.facebook.com/posts/1978007565818999/a-novel-approach-to-neural-machine-translation/

点击阅读原文，报名参与机器之心 GMIS 2017 ↓↓↓

深度解读Facebook刚开源的beringei时序数据库

Mon, 13 Feb 2017 08:00:00 CST

文 | 云行

摘要： Facebook最近开源了beringei时序数据库，其是用来解决其内部监控数据存储和查询需求的数据库，特点是读写速度快。beringei在压缩算法上有哪些独到之处?本文中阿里云数据库高级专家叶翔将为大家深度解读。

Facebook最近开源了beringei时序数据库。beringei是用来解决其内部监控数据存储和查询需求的数据库，其特点是读写速度快，属于内存数据库。

beringei是如何做到的呢，其压缩算法上有哪些独到之处?

阿里云数据库高级专家叶翔借着源代码和论文，对beringei原理进行了解读，同时也介绍了它在Facebook的应用情况。

End.

转载请注明来自36大数据（36dsj.com)： 36大数据» 深度解读Facebook刚开源的beringei时序数据库

贾扬清：Caffe2go是Facebook机器学习产品的核心将开源

Thu, 10 Nov 2016 10:42:50 CST

Caffe 作者，Facebook 研究科学家贾扬清 11 月 8 日在 Facebook 官方网站上发文，介绍了他在 Facebook 最新的机器学习研究成果——Caffe2go。这一款规模更小但训练速度更快、对计算性能要求较低的机器学习框架使得在手机上运行并训练神经网络模型成为可能。Caffe2go 已经成为 Facebook 机器学习的核心技术。贾扬清在文章中写道：我们将会在接下来的几个月内，部分开源这一 AI 框架。

贾扬清：Caffe 作者，现任 Facebook 研究科学家，曾在 Google Brain 工作。在 AI 领域有数年的研究经历。在 UC Berkeley 获得计算机科学博士学位，在清华大学获得硕士和本科学位。对两款流行的深度学习框架做过贡献：Caffe 的作者，TensorFlow 的作者之一。

工作经历：2016 年 2 月从 Google 离职，加入 Facebook，致力于前沿 AI 研究和平台开发。2013 年 12 月到 2016 年 2 月在 Google Brain 担任研究科学家，致力于前沿的深度学习研究和工程，参与了 ImgeNet2014 比赛、移动端深度学习、Google 下一代 AI 平台 TensorFlow 开发、基于深度学习的产品开发和产品咨询等。

文，贾扬清/Peter Vajda

随着视频成为越来越流行的社交方式，我们希望为每个人提供最先进的创作工具来表现自己。我们最近开始在 Facebook 应用程序上测试一个新的创意效果相机，可以帮助人们即时把视频转换成艺术作品风格。这种技术被称为“风格转移”（style transfer）。它能从一种绘画风格中提取艺术性特质，例如梵高画的风格，并将其应用到其他图像和视频中。这种诡计在技术上难以实现的原因在于，它通常需要把内容发送到数据中心，然后在大型计算机服务器上进行处理。但现在，我们在移动设备上开发了一个新的深度学习平台，首次实现了实时的捕获、分析，和像素处理——这一最先进的技术只在手上就能实现。这个成熟的深度学习系统叫 Caffe2Go，它的框架现在已经嵌入我们的手机 app 中。通过把用于处理图像和视频的 AI 模型压缩 100 倍，我们能够在 iOS 和 Android 设备上高效运行各种深度神经网络。最终，我们能够为一些移动设备提供的 AI 推断所需时间不及1/20 秒，也就是 50 毫秒——人眨一下眼睛需要1/3 秒，也就是 300 毫秒。

这个相机中的风格转移工具是两种技术的结合：Caffe2go 运行库和风格转移模型。由于我们的 AI 团队同时研究算法和大规模系统，他们开发的新模型完美实现了这两种追求，使风格转移既质量高又快速。这两种技术的结合能让你在举起手机拍摄视频时，感觉拿着梵高的画笔。

这项工作开始于三个月前，当时还没有人做这样的研究：将基于 AI 的风格转移技术视作一个创造性工具，让它在人们的移动设备上实时运行。跨产品、技术和研究团队的一群人参与进这个项目。Facebook AI 研究团队的 Justin Johnson 是有关该技术的一篇基础研究论文的作者，为这个项目做了一些前期研究。我们的应用机器学习团队一直致力于开发一个可以在移动设备上运行的 AI 平台。相机产品团队对用户的需求非常了解。还有另外许多人也为此作出了贡献，这些团队为在移动设备上运行高度优化的神经网络制作了一流的解决方案。

Caffe2Go：更轻便，更快

人工智能已经对计算机科学产生了深远的影响，但它大部分局限于大型数据中心，这些数据中心往往远离实际使用以 AI 为动力的服务的人。因此，任何标榜能“实时”用 AI 处理某物的技术仍然受到延迟的影响，因为数据必须发送到数据中心，以在 GPU 上运行。我们也认为让人们随身带着超级计算机是不切实际的，因此我们试图找到一种方法，让 AI 能在最无处不在的设备——智能手机上的 CPU 上工作。

手机能够实时地看、说、理解，而无需连接到远程服务器，但它们也有局限性。虽然近年来手机的计算能力有了显著的提升，每秒能够执行数十亿次数学运算，但它们仍受到诸如功率、存储器、计算能力等的各种资源限制，需要更聪明的软件设计。因此，对机器学习系统来说，手机既是机会也是挑战。

我们应对这个挑战的方案是设计一个非常轻量级，而且模块化的框架。为此，我们在开源 Caffe2 项目之上利用 Unix 原理。这确保了连接组件的核心框架非常轻量，而且能够附加多个模块——包括专门为移动设备进行的优化。我们使用一个精益算法框架，允许工程师将抽象运算描述为一个有向无环图（DAG），同时确保图中可以执行的这些节点的输入和输出没有被强加限制。这让我们的工程团队能够在不同平台上实现并优化模块，同时能轻松地把这些模块连接起来。当 DAG 实际运行时，它能利用各种硬件功能最快地实现具现化。

由于速度是计算密集型移动应用程序的核心，尤其是图像和视频应用，框架设计的轻量能让我们为已定义的运算符执行平台特定的优化。一个著名的例子是 Caffe2 集成在我们的移动运行库中的名为 NNPack 的库。利用移动 CPU 的 NEON 功能，我们能显著提高移动计算的速度。在 iOS 设备上，我们还开始集成加速功能，例如 Metal 语言。所有这些都是通过模块化设计完成的，无需改变常规模型定义。因此，算法端和运行库端能够安全地彼此依赖，不需要担心任何潜在的不兼容性。

友好的开发环境

Caffe2 也是我们的第一个具有产业实力的深度学习平台，可以在四个平台上用同样的代码集全速运行：服务器 CPU，GPU，iOS 和 Android。由于模块化设计，框架可以使用相同的语言，但要分别在各个平台上优化。这是一个对开发者隐藏的实现细节，例如，框架可以在手机（iOS 和 Android）的 NNPack 和服务器 GPU 的 CUDNN 之间选择。因此，开发者可以专业于算法的工作，而不用研究怎样运行卷积。

开发者还能从最新的设计部署中获益。从开发者的角度看，缩减手机的运行时间是一个难题，因为手机的工具链并不像台式机和服务器那样强大。我们通过压缩神经网络以匹配硬件来解决这一问题。Caffe2go 中一个序列化的网络在手机和服务器上都能实现相同的输出。最终，我们能把主要的工作转移到服务器环境中，模型训练、性能观察、用户体验研究等。如果一切进展顺利，我们仅需要设置一个按钮，就能再转移到手机环境中。

风格转换模型训练

风格转换的概念并不新鲜，最早提出是在 2015 年 8 月的一篇会议论文 A Neural Algorithm for Artistic Style。但是，当时的技术处理速度极慢并且要求强大的服务器。论文发表后的几个月，圈内的研究员提升了这一技术并且把速度提升了好几个维度，但是，对计算能力依然有很高的要求。

Caffe2go 把这一 AI 处理过程变得更快，并且在手持设备上就能完成。但是，风格转化模型依然要进行优化，来保证体验可以实时进行，同时保持好质量、高分辨率的图像。

有效模型尺寸优化

传统的风格转化研究模型（即使是前馈变量）都是很大的（指的是参数的数量），并且很慢。我们的目标是创建一个风格转换应用，能运行新的、更小的同时更有效的模型，来生成高质量的视频，视频能达到 20FPS，能在 iphone6 或以上的设备中运行，并且避免掉帧。

我们采用了三个主要的方法，来缩减模型的尺寸，我们对卷积层数量进行了优化（这是处理过程最消耗时间的部分），也对每一层的宽度进行了优化，在处理过程中，我们还调整了空间分辨率。通过调整需要处理的图像特征数量，或者调整单独的处理行为所需要的时间，卷积网络层的数量和它们的宽度能在独立的层级使用，进而调整处理所需要的时间。

对于空间分辨率，我们能调整实际的尺寸，也就是在中间层中被处理的那些。通过使用早期池化（缩减被处理的图像的尺寸）以及后来的去卷积（在处理后放大图像），我们能加速处理时间，因为系统需要处理的信息变少了。我们还发现，有了这些技术，我们能极大地缩减训练网络的宽度和深度，同时又能确保图像质量维持在合理的水平。

手机上进行神经网络训练

图像的质量是非常主观的，并且非常难以衡量，特别是在风格迁移之类的任务上。所以，我们开发了可视化工具，其中包括A/B测试，训练了不同的模型，来保证我们能得到最佳的图像质量结果。我们使用的由 FBLearner Flow 支持的大型 GPU 集群，让我们可以实现这一目标，因为我们可以快速地扫过大范围的超参数，比如模型架构、内容/风格权重和缩减采样，进而发现一个经过良好训练的回馈风格，能够满足我们的性能目标，同时又切实保持并提升了图片的质量。

还有很多提升质量的方法，比如，采用即时的标准化而不是常用的分批标准化，能够在许多风格上产生有益影响。比如，卷积层中避免零填充（zero padding）进而减少棋盘效应（人工痕迹），或者，在风格或者内容图片上采用不同的预训练和后处理过滤层。

风格转化技术中实现的速度和质量优化结果在 Caffe 2 框架上运行，能够打造一个手机上的实时图像处理系统。

Caffe2go 是 Facebook 机器学习产品的核心，将开源

Caffe2go ，加上研究工具链比如 Torch 组成了 Facebook 机器学习产品的核心。因为其大小、速度和灵活性上的优势，我们正在 Facebook 的 stack 中全面推广 Caffe2go。

我们也非常乐意与整个研究社区分享我们的软件和设计，这样我们就能更好地学习如何利用不同硬件平台和算法设计的独有特性，这对于跨平台机器学习系统来说尤为重要。我们将会在接下来的几个月内，部分开源这一 AI 框架。

随着我们不断进步，你可以想象，可以在（移动）设备上运行的实时 AI 技术将能帮助这个世界变得更加开放，让人与人之间的联系得以加强，特别是在无障碍和教育等领域。可以拿在手上的智能设备将会持续地改变我们对智能的定义。拥有像 Caffe2go 这样敏捷、轻便的学习系统，我们一定会带来更多美妙的 AI 和 AR 体验，比如，在拍下一个视频后，你可以立即把它转换成梵高的风格。

原文： code.facebook.com

本文链接

[转][转]Facebook 开源的快速文本分类器 FastText

Thu, 16 Mar 2017 23:11:45 CST

比深度学习快几个数量级，详解Facebook最新开源工具——fastText

导读：Facebook声称fastText比其他学习方法要快得多，能够训练模型“在使用标准多核CPU的情况下10分钟内处理超过10亿个词汇”，特别是与深度模型对比，fastText能将训练时间由数天缩短到几秒钟。

Facebook FAIR实验室在最新博客中宣布将开源资料库fastText，声称相比深度模型，fastText能将训练时间由数天缩短到几秒钟。

| 使用fastText实现更快、更好的文本分类

理解人们交谈时的内容，或者敲打文章时的内容——这对于人工智能研究者来说是最大的技术挑战之一，但是也确实是关键的一个需求。自动文本处理在日常计算机使用中相当关键，在网页搜索和内容排名以及垃圾内容分类中占重要组成部分。且当它运行的时候你完全感受不到它。随着在线数据总量越来越大，需要有更灵活的工具来更好的理解这些大型数据集，来提供更加精准的分类结果。

为了满足这个需求，Facebook FAIR实验室开源了fastText。fastText是一个资料库，能针对文本表达和分类帮助建立量化的解决方案。关于fastText具体实现原理，Facebook另外发表了两篇相关论文，两篇论文具体信息如下：

Bag of Tricks for Efficient Text Classification（高效文本分类技巧）

Enriching Word Vectors with Subword Information（使用子字信息丰富词汇向量）

fastText结合了自然语言处理和机器学习中最成功的理念。这些包括了使用词袋以及 n-gram 袋表征语句，还有使用子字（subword）信息，并通过隐藏表征在类别间共享信息。我们另外采用了一个softmax层级（利用了类别不均衡分布的优势）来加速运算过程。这些不同概念被用于两个不同任务：

有效文本分类

学习词向量表征

举例来说：fastText能够学会“男孩”、“女孩”、“男人”、“女人”指代的是特定的性别，并且能够将这些数值存在相关文档中。然后，当某个程序在提出一个用户请求（假设是“我女友现在在儿？”），它能够马上在fastText生成的文档中进行查找并且理解用户想要问的是有关女性的问题。

| fastText对于文本分类的实现过程

在文本处理领域中深度神经网络近来大受欢迎，但是它们训练以及测试过程十分缓慢，这也限制了它们在大数据集上的应用。

fastText能够解决这个问题，其实现过程如下所示：

对于有大量类别的数据集，fastText使用了一个分层分类器（而非扁平式架构）。不同的类别被整合进树形结构中（想象下二叉树而非 list）。

考虑到线性以及多种类别的对数模型，这大大减少了训练复杂性和测试文本分类器的时间。fastText 也利用了类别（class）不均衡这个事实（一些类别出现次数比其他的更多），通过使用 Huffman 算法建立用于表征类别的树形结构。因此，频繁出现类别的树形结构的深度要比不频繁出现类别的树形结构的深度要小，这也使得进一步的计算效率更高。

Huffman 算法

fastText 另外使用了一个低维度向量来对文本进行表征，通过总结对应文本中出现的词向量进行获得。在 fastText 中一个低维度向量与每个单词都相关。隐藏表征在不同类别所有分类器中进行共享，使得文本信息在不同类别中能够共同使用。这类表征被称为词袋（bag of words）（此处忽视词序）。在 fastText中也使用向量表征单词 n-gram来将局部词序考虑在内，这对很多文本分类问题来说十分重要。

实验表明 fastText 在准确率上与深度学习分类器具有同等水平，特别是在训练和评估速率上要高出几个数量级。使用 fastText能够将训练时间从几天降至几秒，并且在许多标准问题上实现当下最好的表现（例如文本倾向性分析或标签预测）。

FastText与基于深度学习方法的Char-CNN以及VDCNN对比

| fastText也可作为专业工具

文本分类对于商业界来说非常重要。垃圾邮件或钓鱼邮件过滤器可能就是最典型的例子。现在已经有能为一般分类问题（例如 Vowpal Wabbit 或 libSVM）设计模型的工具，但是 fastText 专注于文本分类。这使得在特别大型的数据集上，它能够被快速训练。我们使用一个标准多核 CPU，得到了在10分钟内训练完超过10亿词汇量模型的结果。此外， fastText还能在五分钟内将50万个句子分成超过30万个类别。

| fastText对于许多语言都通用

除了文本分类以外，fastText也能被用来学习词汇向量表征。利用其语言形态结构，fastText能够被设计用来支持包括英语、德语、西班牙语、法语以及捷克语等多种语言。它还使用了一种简单高效的纳入子字信息的方式，在用于像捷克语这样词态丰富的语言时，这种方式表现得非常好，这也证明了精心设计的字符 n-gram 特征是丰富词汇表征的重要来源。FastText的性能要比时下流行的word2vec工具明显好上不少，也比其他目前最先进的词态词汇表征要好。

不同语言下FastText与当下最先进的词汇表征进行比较

fastText具体代码实现过程

fastText基于Mac OS或者Linux系统构筑，使用 C++11 的特性。需要python 2.6 或者更高版本支持，以及numpy & scipy等软件支持。

示例：

$ git clone https://github.com/facebookresearch/fastText.git
$ cd fastText
$ make
$ ./fasttext supervised
Empty input or output path.

The following arguments are mandatory:
-input training file path
-output output file path

The following arguments are optional:
-lr learning rate [0.05]
-dim size of word vectors [100]
-ws size of the context window [5]
-epoch number of epochs [5]
-minCount minimal number of word occurences [1]
-neg number of negatives sampled [5]
-wordNgrams max length of word ngram [1]
-loss loss function {ns, hs, softmax} [ns]
-bucket number of buckets [2000000]
-minn min length of char ngram [3]
-maxn max length of char ngram [6]
-thread number of threads [12]
-verbose how often to print to stdout [10000]
-t sampling threshold [0.0001]
-label labels prefix [__label__]

总结：Facebook FAIR实验室最新开源工具fastText能将训练时间由数天缩短到几秒钟，相较于基于深度学习的模型方法，在保证同等精度的前提下fastText速度上快了几个数量级。此外，fastText还能作为文本分类在实际应用中的专业工具，特别是对于大型数据集能实现相当快的训练速度。另外因其自身语言形态结构，fastText还能支持包括英语、德语、西班牙语、法语以及捷克语等多种语言。

PS : 本文由雷锋网(公众号：雷锋网)编译，未经许可拒绝转载！

via Facebook research blog

开源：http://www.leiphone.com/news/201608/y8rhWEglraduqcOC.html?_t_t_t=0.7006332677551208

Facebook 开源的快速文本分类器 FastTex

FastText是Facebook开发的一款快速文本分类器，提供简单而高效的文本分类和表征学习的方法，性能比肩深度学习而且速度更快。

1. fastText 原理

fastText 方法包含三部分：模型架构、层次 Softmax 和 N-gram 特征。下面我们一一介绍。

1.1 模型架构

fastText 模型架构如下图所示。fastText 模型输入一个词的序列（一段文本或者一句话)，输出这个词序列属于不同类别的概率。序列中的词和词组组成特征向量，特征向量通过线性变换映射到中间层，中间层再映射到标签。fastText 在预测标签时使用了非线性激活函数，但在中间层不使用非线性激活函数。

fastText 模型架构和 Word2Vec 中的 CBOW 模型很类似。不同之处在于，fastText 预测标签，而 CBOW 模型预测中间词。

1.2 层次 Softmax

在某些文本分类任务中类别很多，计算线性分类器的复杂度高。为了改善运行时间，fastText 模型使用了层次 Softmax 技巧。层次 Softmax 技巧建立在哈弗曼编码的基础上，对标签进行编码，能够极大地缩小模型预测目标的数量。具体细节参见文章。

1.3 N-gram 特征

fastText 可以用于文本分类和句子分类。不管是文本分类还是句子分类，我们常用的特征是词袋模型。但词袋模型不能考虑词之间的顺序，因此 fastText 还加入了 N-gram 特征。“我爱她” 这句话中的词袋模型特征是 “我”，“爱”, “她”。这些特征和句子 “她爱我” 的特征是一样的。如果加入 2-Ngram，第一句话的特征还有 “我-爱” 和 “爱-她”，这两句话 “我爱她” 和 “她爱我” 就能区别开来了。当然啦，为了提高效率，我们需要过滤掉低频的 N-gram。

2. fastText VS Tagspace

Mikolov 在 fastTetxt 的论文中报告了两个实验，其中一个实验和 Tagspace 模型进行对比。实验是在 YFCC100M 数据集上进行的, YFCC100M 数据集包含将近 1 亿张图片以及摘要、标题和标签。实验使用摘要和标题去预测标签。Tagspace 模型是建立在 Wsabie 模型的基础上的。Wsabie 模型除了利用 CNN 抽取特征之外，还提出了一个带权近似配对排序 (Weighted Approximate-Rank Pairwise, WARP) 损失函数用于处理预测目标数量巨大的问题。

上面就是实验结果，从实验结果来看 fastText 能够取得比 Tagspace 好的效果，并拥有无以伦比的训练测试速度。但严格来说，这个实验对 Tagspace 有些不公平。YFCC100M 数据集是关于多标记分类的，即需要模型能从多个类别里预测出多个类。Tagspace 确实是做多标记分类的；但 fastText 只能做多类别分类，从多个类别里预测出一个类。而评价指标 prec@1 只评价一个预测结果，刚好能够评价多类别分类。

4. 总结

Facebook Research 已经在 Github 上公布了 fastText 的项目代码。不过这个项目其实是有两部分组成的，一部分是这篇文章介绍的 fastText 文本分类，另一部分是词嵌入学习。按论文来说只有文本分类部分才是 fastText，但也有人把这两部分合在一起称为 fastText，比如这篇文章 Comparison of FastText and Word2Vec 。fastText 的词嵌入学习比 word2vec 考虑了词组成的相似性。比如 fastText 的词嵌入学习能够考虑 english-born 和 british-born 之间有相同的后缀，但 word2vec 却不能。fastText 的词嵌入学习的具体原理可以参照论文。

部分内容出自：科技控

从NLP到“自然语言理解”，Facebook如何让Messenger更懂人类？

Fri, 21 Apr 2017 21:43:00 CST

雷锋网按：Facebook的AML和FAIR团队合作进行自然语言处理对自然语言理解进行着合作研究。在2017年4月19日举办的F8开发者大会上，Facebook向公众介绍了他们的研究进展、自然语言理解在Facebook产品中的应用，并且介绍了平民化的自然语言理解平台CLUE，希望依靠大家的力量，继续丰富自然语言理解的应用。

演讲者：Facebook工程主管Benoit Dumoulin，技术项目主管Aparna Lakshmiratan。雷锋网AI科技评论听译。

（首先上台的是Benoit）大家好，我是Benoit，我是Facebook自然语言理解团队的负责人。

我们团队隶属于AML（applied machine learning，机器学习应用小组）。今天我想给大家讲讲几个我们团队最近的工作成果，讲讲我们正在研究什么，同时也会讲到我们遇到、并且正在努力解决的问题和挑战。等一下我还会请一个同事上台来介绍一个有意思的产品，其中就用到了我们团队开发的技术。

Facebook为什么需要自然语言理解？

进入正题，当你打开Facebook之后，你肯定会用到文字。文字是重要的沟通方式，Facebook的每个产品里面都能看到文字，Instagram，Messenger，Whatsapp等等，文字真的到处都是。而你每天在Facebook看到的或者写下的文字，是没有任何要求，任何人都可以随意发挥的，不需要戏剧化或者怎样。所以如果我们能够理解这些文字，那我们就肯定可以让每个用户的使用感受都得到提升。

理由是这样的，拿我自己举例吧，其实我是法国裔加拿大人，在蒙特利尔长大的（观众喝彩），（笑）。那我呢，工作是科学家，业余时间喜欢冰球，所以当我每天打开Facebook的时候，我想看到我朋友们的新动向、想跟他们聊天；我也想知道最新的冰球比赛结果如何，你看现在就有一场，我挺关心我喜欢的俱乐部怎么样了——不告诉你们叫什么（笑）。同时呢，除了看这些新闻，我还需要关注机器学习方面的动向，我得知道下一场会议在什么时候、都有谁会去、我的朋友们去不去、是谁组织的、有没有什么优秀论文等等，各种各样的事情。为了达到这样的目的呢，我们就需要想办法理解这些文字内容，然后根据我的兴趣进行匹配。

我们经常提到“自然语言理解”和“内容识别”，要表达什么意思呢？简单说就是能给别人解释——一段文字经过算法处理以后，我们能够做出结论或者进行引申。在我们能做的事情里面，最基本的之一就是给文字分类。

比如（右边）这段内容是我发的，把它输到机器里，就能训练它如何把内容分类成为话题，然后就能跟别人解释了，“哦，这段内容是关于厨艺的。” （左边）还有一段关于篮球的内容是我的朋友Jole发的，不过如果你仔细看一下文字的话，你就会发现它也是关于厨艺的，只是不那么明显。不过不用担心，我们训练的机器也可以处理这样的内容。

我们当然还能做更棒的，更深入地理解一段话，区分出其中的实体。这是另一个朋友的动态，要去看演出，这个乐队我没怎么听说过。当你仔细看一下文字部分就会发现，名字挺逗，乐队名字是“Muckbucket Sunshine”，演出地点是“BOM BOM ROOM”。那如果这种时候我们能区分出实体，知道了是哪个乐队、在哪个场馆演出，然后就可以把它匹配给喜欢音乐的人；然后呢，我们不需要把所有音乐相关的信息都推荐给他们，只需要推荐跟这个乐队或者这个场馆相关的就可以了。我们所讲的“内容识别”大概就是这样。

对于Messenger，你们在听过昨天的演讲、参加一些活动以后就会知道，一旦能够理解文字内容了，就可以做一些很有趣的事情。比如这段对话，我和我的两个朋友打算一起出去喝酒。区分一下实体的话，就是我们要去palo alto，时间也能看得出来。这里我想强调一下，人类可以很容易地理解这段对话，实际上我们3个人用了3种不同的方式来表达时间。

Facebook的目标和方法

所以我们的目标就是设计和训练人工智能，让它们对文字内容的理解准确度达到人类水平，确实是这样。这个目标其实挺难达到的，我试着跟你们解释一下，Facebook上面的文字完全是自由地书写的，没有任何限制，用户们想怎么写就怎么写，对不对。

我们打算怎样达到这个目标呢，不是什么秘密，我们用了深度学习的方法。我们最重要的方法之一是来自这篇论文的。它的名字叫《从零开始进行文本理解》（《Text understanding from scratch》），是几年前公开的，其中介绍了可以用深度学习，就是只需一个标准的网络模型就能进行语言识别，并且解决大多数在其中遇到的问题。我们跟Facebook的研究团队一起研究了这篇论文，然后我们就决定建立一个能够支持论文中这样的算法的平台。

这是我们在Facebook建的这个平台建好以后的样子，我们把它叫做Deep Text，是帮我们达成文本识别方面目标的秘密武器。我们把这个平台建立得可以灵活切换，还可以升级拓展。我们每天会拿很多文本给它训练或者处理。它需要支持多种语言，如果你参与了之前的演讲，你一定明白我们有很多用其它语言的用户，他们同样会用不同的语言创造很多内容，我们也需要理解。还有，这个方面有许许多多的问题需要解决，我们希望这个平台能够以无缝的方式解决许多种不同的问题。

我刚才解释过的内容分类、实体识别和区分只是众多待解决问题中的几个，我们还可以做很多别的事情。我等下还会说一个叫做“文本相似性”的，也是能够很自然地用这样的平台解决的。现在我们回过头来再讲一下Deep Text，看看它是怎么解决文本分类的问题的。

刚才说过Deep Text用到了深度学习，其中很有意思的一点就是单词是以向量的形式表示的。我们在向量空间里表示这些词，这样一来，语义学上相似的词也就会处在更接近的位置上；不怎么相似的词就会离得很远。这里是一张这种表示方法的示意图，里面的蓝色和粉色点就是单词。可以看到，几个球类运动的名称挨得比较近，其它概念性的词虽然也跟运动相关，但是离得就要远一些。

我们实际的措施，基本上是基于卷积网络的，这是一种很自然的吸收组合上下文的方法。这里的“上下文”是指，如果你单独拿一个词出来，它可能会有好多种含义，但是当这个词在句子中、有上下文的时候，那这个词的意思就会变得明确得多。这就是我们这种方法可以很自然地做到这件事的原因。基本上你也自己能做一个话题或者分类识别器，就用这样的网络。

刚才我提到了文本相似性，它可以很好地说明我们这个平台的灵活性。关于文本相似性，我们就拿上一页的那种网络，然后把它拓展成了一个复杂得多的模型，像这样。在这里我们要做的是，用一侧的网络对一份文本内容进行分析建模，我们把这种模型叫做“双塔模型”，如果你是业内人士的话，你肯定明白我是什么意思。所以你用一侧的网络对一条文本进行建模，用另一侧的网络对另一条文本进行建模，然后再用一个函数对语义区别大的进行惩罚。

有了这样的方法，我们就可以做很厉害的事情了。比如这个，我不是喜欢冰球嘛，那么有了这样的模型，如果有一个我喜欢的动态，那这个模型就可以学会找到更多的语义类似的动态，然后我就可以看到更多自己喜欢的东西。这个模型挺厉害的，我们在很多Facebook的产品中都用到了这个模型。

这是我们当前所做的，对于未来，我们想要做得更好。这是我们在通往与人类类似的文本识别准确率路上的小目标之一，我们可以把文字和图片或者视频进行联合识别。还是回到我朋友Jole的这个动态，文字部分是很隐晦的，但是这张图片非常好理解。所以如果把两者加以结合，让图片和文字里面的信息都发挥作用，建立一个联合识别的模型，就肯定会对这份内容有很好的理解。

以上就是我们最近在做的事情，我们也一直努力做出更好的成果。那么我就讲到这里，下面我会邀请我的同事上台，她会继续给大家讲一些的实际产品，其中就用到了我们团队开发的技术。

（Benoit走下讲台，观众鼓掌，Aparna走上讲台）

谢谢Benoit，我是Aparna，我来跟大家讲讲目前Deep Text是如何运用在真实的Facebook产品中的。我不知道大家有没有想过，实际上人们会用Facebook的群组做各种各样的事情，尤其是用它来买卖东西。

自然语言理解已经在改善用户体验

大概一年之前，群组的商务团队找到我们，让我们帮忙看看有没有办法知道一个动态是不是关于卖东西的；如果真的要卖东西，我们能不能帮用户更好地达成他的目标，来给用户更好的使用体验。这其中的难点是，当用户想要卖东西的时候，我们不想给用户发动态的方式加上任何束缚，我们还是希望用户用自然语言、自由地表达，但是我们还是要能够识别出用户想要卖东西的意愿。当我们有了Deep Text以后，我们就可以做一个高精确度的分类器，它可以阅读用户的动态，看看用户有没有卖东西的打算。而且它还可以识别得更深，就像刚才Benoit说的那样，识别文本中的实体，在这个场景下就可以是产品名称、价格、主要特性，然后我们就可以给用户提供很有吸引力的使用体验。

再举一个例子，社交推荐，我在自己的Facebook上都经常会使用这个功能。借助Deep Text，我们可以观察用户的动态，如果你在让你朋友帮忙推荐东西的，比如好吃的饭馆、好玩的活动，又比如这个例子里，想找一个靠谱的理发店。我们能做的就是，用Deep Text判断用户想要做什么样的事情，一旦判断出来，接下来的事情会给用户很棒的体验，当你的朋友给出建议以后，评论会分类，找出其中的实体，更重要的是把找到的实体链接到Facebook的地址簿里，然后展示成美观的地图，方便用户互动，最终达成自己的目标。

最后再说一个应用的话，你们可能在昨天的演讲里已经听过了，那就是Messenger中的M建议。当M觉得它能够帮助你做什么的时候，它就会自动在你的聊天中跳出来。它吸引人的地方，就是缩短了从“想做”到“做成”之间的距离。所以M可以帮忙做很多你想要做的事情。比如，当M发现你要去哪里的时候，它可以帮你叫一辆车，看你喜欢Uber还是lift，而且可以不用离开Messenger界面就叫到车。现在这段视频就演示了当M发现用户打算叫外卖，只要点一下，就可以用一种新的体验叫到外卖。

而且你还会发现这种体验是共享化的，对话里的每个人都可以参与这个点餐的过程。点好以后仍然通过M就可以完成付款。所以这些事情都可以不用离开Messenger界面就可以搞定，而随着M变得越来越智能，我们也希望有更多类似这样的建议可以给更多的用户意愿带来方便。

接下来我想讲讲，当我们在研发这些产品的时候都遇到了一些什么样的困难。

第一个困难是，很难批量复制机器学习所需要的专家。大多数时候，我们团队的机器学习专家和产品团队的工程师一起合作，做出这些非常高准确度的分类器。但是你会注意到，在我提到的这些应用例子里，我们还想给很多很多别的用户意愿做出分类器，还有很多很多的实体我们想要识别提取，但是很明显，我们没办法像批量化建立功能一样地让机器专家们也批量化。

第二个问题是重复使用性，我们AML团队很看重这件事。回想一下前面我举的两个例子，其中有一个提取地址的功能，我们会觉得这个功能既要用在Messenger的M建议功能里，也要用在社交推荐里是很自然的事情。所以我们也在想如何才能建立一个平台，让不同的程序都能共享和重复使用这个平台的模型、特性以及数据，这样它们就都可以找到突破口，避免开发的时候要每次重复做类似的工作。

第三个难点你们应该都理解，机器学习的关键是数据，高质量的有标签数据；要获得这样的数据，大家可能都知道，不仅仅是难，而且还很费钱。所以我们也在想 如何优化标签，让我们在训练这些分类器和提取器的时候尽可能提高标签的使用效率。

介绍一个平台给你认识一下吧，它叫做CLUE

这几点就把我们引向了CLUE。CLUE是一个语言识别引擎，是一个自助式的平台。

而CLUE做的事情，是让机器学习变得民主化，它用优秀的人工智能和漂亮的用户界面吸引着人们进入，这样Facebook的每个用户，不一定非要是机器学习专家，都可以到CLUE里面用最先进的自然语言理解技术建立一个实体提取器和内容分类器。 这样，当任何的新应用需要的时候，都可以由CLUE这个统一的入口来建立提取器和分类器。

第二个方面是，CLUE是建立于Deep Text和Facebook的AI开发平台FB LearnerFlow2和Caffe2之上的，相信你们今天已经听说过它们了。对Facebook整体来说，这些怕平台极大地提高了灵活性，让人们可以共享和重复使用模型、数据和特性。

第三个方面是对标签效率的提升。CLUE使用了“主动学习”功能，这个功能在机器学习社区经常可以见到，让它可以为获取到的标签做出优化，让分类器只学习它还需要学习的、还没有弄明白的标签。

接下来，我会站在一个想要运用CLUE的工程师的角度，利用它自助式的设计，建立一个分类器，就比如叫外卖的吧。那么你首先需要做的事情是收集一些数据，你需要先给分类器一些正确的样本，比如能表现出叫外卖意愿的短语或者句子。你可以看到，CLUE提供了一个非常平易近人的用户界面，带有一些关键词搜索来提示你，方便你输入带有这种意愿的语句。

在这个例子里，“我想吃赛百味或者汉堡王”就带有叫外卖的意愿，算是一个不错的开始。你可以添加许多这样的确实具有意愿的句子，来达成你的目标。正确和不正确的样本都行，当你开始收集以后，你需要做的就是给他们加标签。

同样地，CLUE有一个美观的用户界面来让你做这件事。你不仅可以标出哪些有意愿，哪些没意愿，而像Benoit前面说的那样，还可以给实体加标签。对我们这个例子来讲，“赛百味”和“汉堡王”都是值得加标签的内容，可以帮助你达成你的目标。

当你添加好标签以后，CLUE就会自动地在后台训练出一个分类器。在你添加标签的过程中，你就已经得到了一个可以使用的分类器了。如果你才刚刚开始的话，效果可能还不是很好，但是毕竟有一个了。然后你就可以看看分类器运行的状况如何。

CLUE支持多种可视化方式，比如召回率曲线、AUC曲线等等，很多种图形供你选择。现在你还可以监控你的分类器运行状况如何，来看看你计划的任务完成得如何。

你还可以用CLUE做一件厉害的事情，就是你可以用这种初始状态的分类器去分类真实的Facebook信息流，看看结果如何。我来演示一下要怎么做，在用这个分类器对真实的信息流分类以后，可能很多东西已经分类对了，但是更重要的是，能看到有哪些东西分类错了。

在这个例子里，CLUE就告诉你，你的分类器好像有点弄混了，分不清“能送上门吗”和“我们端着面条说吧”。这就可以提示你如何改进数据和标签，给分类器更正这些错误，给怎样得到越来越好的结果指明了方向。

这就是我前面提到过的主动学习循环。随着你调整好了你的模型，当你对结果满意的时候，就可以点一下CLUE里面的“部署”按钮，就这么简单。点一下按钮，你的分类器就可以部署到所有的数据中心里，这样，只要有需要的Facebook产品团队都可以到其中选择、并把你的分类器应用到他们的程序中。

算上Deep Text和CLUE，我们使用在Facebook产品里面的模型已经超过了200个。这里面很厉害的事情是，不仅机器学习的专家们使用这些模型，Facebook里不同产品团队的科学家和工程师也在用这些模型。

在这场演讲的开头，Benoit说我们真正的目标是通过各种各样的应用，借助数百万计的内容把人和人连接起来。今天的Facebook已经做得很好的事情，是通过利用社交信息流，借助你朋友们所说的话、所做的事把你和内容连接起来。我们很想要拓展这件事情，想要把你和这世界中你感兴趣的数百万计的内容也连接起来。即便今天说了这么多，其实我们也只是刚刚开始，为了让AI能够达到这些目标、提供这些新的用户体验，还有很多的事情等待我们去做。谢谢大家！

雷锋网AI科技评论听译

via Natural Language Understanding @Facebook

Facebook是用PHP构建的大型系统吗？

Fri, 18 Sep 2015 23:44:00 CST

想要构筑一个大型系统，如果你不像Facebook那么有钱、任性还能折腾，如果你的团队规模有限，如果你想要节约成本，如果你想要降低人员流动带来的影响，如果你要减小HR的压力，如果你希望员工可以在工作告一段落后可以在不同的项目/团队间进行转岗，那么尽量让团队使用少的技术/语言是一个很好的选择，PHP会是这个不二之选吗？

我们来看看号称“一直”使用PHP做为“主要”开发语言的Facebook这些年都折腾出了什么：

HipHop 将PHP代码转换为C++代码，之后由C++编译器进行编译，代码不再运行在PHP虚拟机上。2010年Facebook性能问题开始凸显时，已经拥有数百万行的PHP代码，上千名PHP工程师，如果改用其他语言（非不想实不能！）根本不现实，所以成立了一个小组花费18个月开发了HipHop，这种事情显然不是什么公司都能干的。
HHVM ：准备替代HipHop的PHP虚拟机技术，为了纪念早先的PHP代码转换工具HipHop ，命名为HipHop Virtual Machine
Hack：可以在HHVM虚拟机上运行的PHP改进语言，实现了一些静态语言特性
Cassandra：分布式存储系统 Java 已开源
Scribe：日志系统 C/C++ 已开源
Haystack/F4：高性能图片存储与检索系统 C/C++ 闭源
Thrift： Facebook为了PHP可以调用后端服务开发的跨语言RPC框架，事实上只有Java版本的实现最完整，PHP使用的是C++的版本做了个简单的API引入功能有限，想要进行扩展难免要使用C++进行开发,Thrift编译器为C++实现已开源

Facebook使用的其他不是自己开发的开源技术就不多说了，至少如果需要在Hadoop下用MapReduce进行大数据统计处理，就不要指望可以用PHP了。

最后引用文章《看三名工程师如何重建Facebook基础》的最后几段：

在有了“HipHop虚拟机”以后，Facebook能以大多数开发者永远都想象不到的速度运行PHP代码。但是，仍旧有人质疑为何这家公司要这么走极端。长期开发者、编程权威人士大卫·波拉克（David Pollack）就不认同Facebook坚持使用PHP语言的作法。“PHP语言用来构建一个应急网站是最好的。对我来说，Facebook能利用这种语言构建像Facebook网站那样强大而灵活的网站确实令人印象深刻，但我不认为PHP是构建一个网站的最好方法，这就像是住在新泽西州的人非要把这个州称作‘花园州’一样。”

就连亚当斯也承认，虽然他曾宣称动态语言能让开发者更具生产力，但这种说法在某些情况下也值得商榷。埃文斯也承认，虽然PHP这样的语言或许能在短期内提高生产力，但从长期来看则会带来更多困难。

当然，Facebook之所以还在坚持使用PHP语言，在很大程度上是因为用另一种语言来重新编写整个网站的代码是一项更加庞大的任务。Facebook将此称为“遗留问题”（The Legacy Problem）。“到最后，总有一天网站的规模会大到不重写不行的地步。”帕洛斯基说道。

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

Facebook内部高效工作PPT指南

Tue, 15 Sep 2015 11:53:01 CST

Facebook 内部分享：不论你如何富有，你都赚不到更多的时间，你也回不到过去。没有那么多的假如，只有指针滴答的时光飞逝和你应该好好把握的现在，以下25张PPT的分享将为您带来时间价值管理的技巧。

1、时间常有，时间优先。

2、时间总会有的：每天只计划 4～5 小时真正的工作。

3、当你在状态时，就多干点；不然就好好休息：有时候会连着几天不是工作状态，有时在工作状态时却又能天天忙活 12 小时，这都很正常的。

4、重视你的时间，并使其值得重视：你的时间值 1000 美元/小时，你得动起来。

5、不要多任务，这只会消耗注意力；保持专注，一心一用。

6、养成工作习惯，并持之以恒，你的身体会适应的。

7、在有限的时间内，我们总是非常专注并且有效率。

8、进入工作状态的最佳方式就是工作，从小任务开始做起，让工作运转起来。

9、迭代工作，期待完美收工会令人窒息：“做完事情，要胜于完美收工” Facebook 办公室墙壁上贴的箴言。动手做，胜过任何完美的想象。

10、工作时间越长，并不等于效率越高。

11、按重要性工作，提高效率。

12、有会议就尽早安排，用于准备会议的时间往往都浪费掉了。

13、把会议和沟通 (邮件或电话) 结合，创造不间断工作时间：一个小会，也会毁了一个下午，因为它会把下午撕成两个较小的时间段，以至于啥也干不成。PS：当看到一个程序员冥思苦想时，不要过去打扰，甚至一句问候都是多余的。

14、一整天保持相同的工作环境。在项目/客户之间切换，会效率低。

15、工作—放松—工作=高效(番茄工作法)—拖延症—高效。

16、把不切实际的任务分割成合理的小任务，只要每天都完成小任务，你就会越来越接近那个大目标了。

17、从来没有两个任务会有相同的优先级，总会有个更重要，仔细考虑待办事情列表。

18、必须清楚白天必须完成的那件事，是什么。“Only ever work on the thing that will have the biggest impact” 只去做那件有着最大影响的事情。—— Jason Cohen

19、把任务按时间分段，就能感觉它快被搞定了。

20、授权并擅用他人的力量。—君子善假于物(人)也，如果某件事其他人也可以做到八成，那就给他做！

21、把昨天翻过去，只考虑今天和明天昨天的全垒打赢不了今天的比赛。—好汉不提当年勇。

22、给所有事情都设定一个期限。不要让工作无期限地进行下去。

23、针对时间紧或有压力的任务，设置结束时间，万事皆可终结

24、多记，多做笔记

25、进入高效状态后，记下任何分散你注意力的东西比如Google搜索词、灵光乍现的想法、新点子等等。如果你把它们记下来，它就不会再蹦来蹦去了。

26、休息，休息一下～