太有限了。说你正在分析图像，寻找狗的图片。可能只有特征值的某个子集指示它是否是狗的图片，并且该像素的其余值或图像的该片段指示另一个类。你不能画一条线来定义这样一组复杂的关系。非线性模型更强大，但同时他们更难训练。再次，你从优化理论遇到了那些硬的问题。这就是为什么很长一段时间我们认为神经网络不够好，因为他们会过度配合，或者他们太强大。我们不能做精确，保证优化。这就是为什么他们（暂时）从现场消失。
DB：在神经网络理论中，有多个分支和方法来计算机学习。你能总结一些关键的方法吗？
RZ：到目前为止，最成功的方法是监督方法，其中使用称为反向传播的旧算法来构建具有许多不同输出的神经网络。
让我们看看已经变得非常受欢迎的称为卷积神经网络的神经网络构造。这个想法是，机器学习研究者构建一个由多个层构成的模型，每个层以不同的方式处理来自前一层的连接。
在第一个图层中，您有一个窗口，用于在图像上滑动修补程序，该窗口将成为该图层的输入。这称为卷积层，因为补丁“卷积”，它与自身重叠。然后几种不同类型的层。每个都有不同的属性，几乎所有的都引入非线性。
最后一层有10,000个潜在神经元输出;那些激活中的每一个对应于识别图像的特定标签。第一类可能是猫;第二类可能是汽车;等等，所有的10,000类ImageNet有。如果第一个神经元正在触发10,000的最大值，则输入被识别为属于第一类，即猫。
监督方法的缺点是，您必须在训练时对图像应用标签。这是一辆车。这是一个动物园。等等。
DB：对。和无人监管的方法？
RZ：不太受欢迎的方法涉及“自动编码器”，这是无监督的神经网络。这里神经网络不用于分类图像，而是压缩它。你按照我刚才描述的方式读取图像，通过识别补丁并将像素馈入卷积层。然后还有几个其他层，包括与其他层相比非常小的中间层。它有相对少的神经元。基本上你正在阅读的图像，经历瓶颈，然后出来的另一边，并试图重建图像。
这个训练不需要标签，因为你正在做的是将图像放在神经网络的两端，并训练网络，使图像合适，特别是在中间层。一旦你这样做，你拥有一个知道如何压缩图像的神经网络。它有效地给你的功能，你可以使用在其他分类器。所以如果你只有一点点标记的训练数据，没有问题 - 你总是有很多的图像。将这些图像视为未标记的训练数据。您可以使用图像构建自动编码器，然后从自动编码器中拉出一个很好的适合使用一点点训练数据的功能，以找到您的自动编码的神经网络中易受特定模式的神经元。
DB：什么让你进入Spark？你在哪里看到那套技术？
RZ：我知道Spark的创始人Matei Zaharia，因为我们都是滑铁卢的本科生。我们实际上同时在Google上实习。他正在研究开发人员生产力工具，与大数据完全无关。他在谷歌工作，从来没有触摸过MapReduce，这是我的焦点 - 有趣的给他，他结束了。
然后Matei去了Facebook，在那里他在Hadoop工作，取得了巨大的成功。在那段时间里，我一直在考虑分发机器学习，没有一个框架出来 - 包括Hadoop - 看起来令人兴奋，我建立在顶部，因为我知道从我的时间在谷歌什么是真正可能的。
DB：告诉我们Spark是什么，它是如何工作的，以及为什么它对分布式机器学习特别有用。
RZ：Spark是一个集群计算环境，它给你一个分布式向量，其工作方式类似于在单个机器上用于编程的向量。你不能用一个普通的向量做你能做的一切;例如，您没有通过索引进行任意随机访问。但是你可以，例如，相交两个向量;你可以联合;你可以排序。你可以做一些你期望从一个普通的向量。
Spark使机器学习变得容易的一个原因是，它通过尽可能多地保留数据的一些重要部分而不写入磁盘来工作。在分布式环境中，获取故障恢复能力的典型方法是写入磁盘，使用HDFS通过网络复制磁盘三次。
什么使得这适合机器学习是数据可以进入内存并留在那里。如果它不适合内存，这也很好。它将根据需要被打开和关闭磁盘。但关键是它可以适应内存，它会留在那里。这有益于任何将经历数据的过程 - 这是大多数机器学习。几乎每个机器学习算法都需要经过数十倍，如果不是几百倍。
DB：Spark和MapReduce在哪里？是否有一个地方为他们的不同种类的工作负载和工作？
RZ：要清楚，Hadoop作为一个生态系统将会茁壮成长，并在很长一段时间。我不认为Hadoop生态系统的MapReduce组件也是如此。
关于MapReduce，要回答你的问题，不，我不这么认为。我老实地认为，如果你开始一个新的工作负荷，从MapReduce开始是没有意义的，除非你有一个现有的库，你需要维护。除此之外，没有理由。现在做MapReduce是一种愚蠢的事情：这是Assembly和C ++的区别。如果你可以编写C ++，编写汇编代码是没有意义的。
DB：Spark在哪里？
RZ：Spark本身现在很稳定。 在现在和未来几年发生的最大的变化和改进是在图书馆。 机器学习库，图形处理库，SQL库和流式库都正在快速开发，每个单独的一个都至少有一个令人兴奋的路线图。 这些都是我想要的功能，很高兴看到它们可以很容易实现。 我也对社区驱动的贡献感到兴奋，这些贡献不够普遍，不足以放入Spark本身，但是支持Spark作为一个社区驱动的套件在http://spark-packages.org。 我认为这些也将对用户的长尾部非常有帮助。
随着时间的推移，我认为Spark将成为事实上的分发引擎，我们可以在其上构建机器学习算法，特别是规模。
