PyTorch 创始人：开源成功的方法论

  以下文章来源于OneFlow

  来源丨Weights & Biases

  编译丨OneFlow

  翻译丨杨婷、宛子琳

PyTorch 是目前最受欢迎的深度学习框架之一，初始版本于2016年9月由 Adam Paszke、Sam Gross、Soumith Chintala 等人创建，并于2017年在 GitHub 上开源。因其简洁、易用、支持动态计算图且内存使用高效，PyTorch 受到众多开发者的喜爱，并被广泛应用于支持科学研究以及 ChatGPT 等应用的开发。此外，PyTorch 有一个活跃的大型开源社区，提供了丰富的教程、示例代码和问题解答，给予成员帮助和支持。

Soumith Chintala 是 Meta 副总裁以及 PyTorch 的联合创始人。Soumith 对 PyTorch 的发展过程和最终用户体验产生了重要影响，并主导塑造了 PyTorch 开源社区的运营理念。

在本文中，Weights & Biase 创始人 Lukas Biewald 与 Soumith Chintala 讨论了 PyTorch 的内部运作机制、管理开源社区的方法，以及当前流行的其他机器学习库。

Lukas Biewald：还记得我们刚开始创建 Weights and Biases 时，TensorFlow 的发展正势不可挡。当时你是否看到了 TensorFlow 的不足之处？是什么激励了你，让你决定开发一个与之相抗衡的系统？

Soumith Chintala：TensorFlow 于2015年12月发布，当时市面上大约有15到20个深度学习框架，那时 TensorFlow 还未像现在这样占据主导地位。TensorFlow 在混乱的竞争局面中登场，在发布时进行了全面营销。谷歌是当时最好的研究实验室，TensorFlow 利用谷歌云预算进行了大规模营销，以一种其他深度学习框架意料之外的强势方式打入市场。

当时，每个新的深度学习框架都需要一个 shell 脚本来进行编译和安装，缺乏经过精心设计的工程，单元测试可能仅在 HPR 上运行。因此，TensorFlow 具有极大优势，向深度学习框架领域展示出高质量的工程实践。

但 TensorFlow 缺少对开源激励机制的关注以及与开源社区的互动，包括回答低级提问、满足用户各种需求以及及时处理用户发送的 PR 等。

我们认为，与社区互动、向社区提供有效帮助并逐步建立社区的过程在 TensorFlow 中有所欠缺。而与社区互动的方式非常契合 Torch 的理念，我们一直在延续并以更大的规模不断发展这一理念。

Lukas Biewald：你好像在说 PyTorch 的成功与技术水平差异无关，更多的是社区建设和互动，就像有人指出，PyTorch 的及时评估反馈是你们成功的主要原因？ 

Soumith Chintala：我坚信，TensorFlow 是一个在技术方面具有相当高成功率的代表性编程模型，Jax 就是一个最直观的例子，这说明，技术方向并不是导致 TensorFlow 未能达到预期的原因。Jax 在编程模型方面与 TensorFlow 非常类似，只需提前跟踪一个程序，然后在辅助运行时（runtime）运行它，人们使用Jax的体验非常好。

TensorFlow 从 TensorFlow 1.0 升级到 TensorFlow 2.0 的过程中，放弃了符号执行模型，而这可能是 PyTorch 最大的优势之一。如果人们需要从符号执行模型过渡到 Eager 执行模型，那么相比刚刚诞生的 Eager 框架，人们多半会选择 PyTorch ，因为后者在这方面已经发展了好几年，相对成熟。

Lukas Biewald：你们在构建社区方面做得非常出色，在这方面是否有什么窍门？对于试图自己建立社区的人，你有什么建议？

Soumith Chintala：首先，要给予那些工作出色，但并不熟悉的人更多信任，赋予他们更多权力。其次，我们需要认识到，尽管我们曾试图提醒，但很多人对 PyTorch 的发展方向并不完全了解。

Meta 为其投入了大量资源，是其最大的贡献者之一。但 PyTorch 最初源于 Torch 社区，由一群热衷于 Torch 的神经网络爱好者组成。PyTorch 论文的主要作者是 Adam Paszke，我和他在网上相识，当时他正在撰写关于 Torch 的博文。我记得他发表了一两篇博文，详细介绍 Torch 的内部结构，我觉得很酷，于是我们展开了交流。

有天他通过在线聊天平台给我发消息，“我正在波兰找实习，但没有找到合适的机会。” 我回复，“我们在考虑启动 Python Torch 项目，我这里有一个实习名额，你可以来面试看看，如果合适，你可以负责我们之前设想的 PyTorch 项目。”当时，我们以及一些来自 NVIDIA 的 Luca Antiga 等组成了一个来自不同公司的在线团队，共同推进这个项目。于是，Adam Paszke 加入了我们团队，我们和 Sam Gross 全职投入到了该项目，PyTorch 就这样诞生了。

我认为，PyTorch 的 DNA 中天然融入了社区赋权理念，我们从一开始就坚持这一点，并且许多人都参与了 PyTorch 的开发，虽然大家可能在现实中素未谋面，但经过多年的共事，已经成为了线上好友。

在社区建设中，这种信任和模糊感十分重要。显然，你需要对团队成员保持信任，但并非每个人都具备同等的能力，也并非每个人都会成绩斐然。我们这么做，并不是为了追求某种预期的最终目标，而是为了观察发展走向。

Lukas Biewald：我听说很多开源社区都面临一个问题：可能会出现不良氛围，或者在这种高度分散的状态下难以做出决策，你是否遇到过一些棘手的情况，比如某件事需要大家共同解决，但却无法达成一致？

Soumith Chintala：当然。我认为，自己为 PyTorch 带来的最有价值的贡献之一就是塑造了其社区文化，并在社区中构建了有效的激励机制。

在构建社区时，激励机制至关重要。我也确实遇到过一些棘手情况。例如，在过去几年中，Torch 社区最重要的贡献者之一对于使用 Python 方向持有异议。

想象一下，如果你有一位不断高效输出代码的人才，但他对于项目的方向存在不同看法，你该如何应对？你会妥协于他的愿景，还是努力说服他改变想法？很多时候，未来的方向充满了不确定性，很难预测，也没有一个确定的正确答案。你只能根据长远目标和方向做出选择，这同样适用于构建激励机制。

在我看来，很多社区最终走向衰败的原因是他们不敢清除不友善的成员。社区管理员必须采取积极行动，阻止这些人进入社区，但有时难免有漏网之鱼。然而，我们绝不能允许他们在社区内传播不良言论。你必须把社区成员视为家人，与其保持紧密联系，积极进行保护。如果有人行为不当，就应该果断地将他们排除在社区之外。

Lukas Biewald：从一个开源社区中排除某人，这意味着什么？

Soumith Chintala：首先应该大胆直言，让社区成员充分了解规范。第一步是确立明确的规范，告诉成员什么能做，什么不能做。例如，在 PyTorch 开发早期，社区有一位平时表现良好的成员，他在随机频道上发布了一个带有性别歧视色彩的段子，我看到后立即与他进行了沟通，告诉他请不要再发布类似内容。通过这种方式，我们设定了社区基调，向社区成员明确了哪些行为是不被允许的。

在很多社区中，大家不太愿意成为那个强制执行规定的人，因为我们难以把握其中的微妙平衡，如果干涉过于频繁，可能会显得缺乏人情味。但我想强调的是，从一开始我们就强烈推崇一种激励方式，在与人交流时，不妨提出一些问题：如何打造社区？如何扩大社区规模？其中见效最快的方法之一是引入激励制度，为那些做出贡献的人提供金钱或礼物奖励。

我认为，当动机源于内在自驱力时，开源项目通常会运行得非常顺利。因此，我一直秉持着一个指导原则，至少在社区达到临界规模前要遵循：不要依赖外在动机来建立社区，因为一旦你取消了激励措施，那么社区将很难长久维持。要弄清楚人们是否会自发参与，这才是最重要的，也是吸引人们参与社区的关键所在。

Lukas Biewald：你多次提及了激励的重要性，同时也指出了哪些激励方式并不适用。但我猜测你也有意识地采用了特定的激励方式，以催生你所期望的行为。

Soumith Chintala：通常情况下，人们只会对特定类型的优质工作或辛勤付出给予认可，而在随后的时间里，继续关注和认可这些贡献才是真正重要的。

PyTorch 社区的许多贡献者任职于各大公司，很多时候他们所在公司的激励机制并不足以充分认可他们的付出。有时，我会直接给某位贡献者的上司写推荐信，希望推动社区成员的晋升，甚至不限于我所在的公司，我会向他们所在公司的领导解释该贡献者所面临的挑战和他们的出色表现，以帮助他们得到应有的认可。

各种形式的认可都非常重要，这些认可能够激励人们坚持自己想做的事。同时，社区成员们也有自己的生活，他们会受到社交和外部因素的影响，因此，我们应该努力去支持和帮助他们。

Lukas Biewald：记得在 PyTorch 0.3 和0.4版本时，实际上是我首次将 PyTorch 与 Weights & Biases 进行整合。那时 PyTorch 似乎经历了大量的破坏性 API 变更，我一直在思考，回头来看，这究竟是不是一个明智的计划，它是否鼓励你们勇敢向前迈进，还是说一切仅仅是无心之举呢？

Soumith Chintala：在我看来，这是一个相对的问题。人们常常把 PyTorch 与 Tensorflow 和 MXNet 进行比较，他们会说，“我用 PyTorch 0.2 编写的代码到今天仍然可以运行”等等。因此，我们一直认为 PyTorch 在处理破坏性变更（Breaking changes）方面表现出色，在项目内部，团队成员也充满激情，并且非常注意避免破坏用户的代码。

我们坚信，即使是用户代码中的错误也是我们的问题。一旦用户出现问题，我们将尽全力修复和解决。

Lukas Biewald：在开发 PyTorch 时，你们如何衡量成功与否，或者说你们关注哪些具体指标？虽然你曾提到不关注无关紧要的指标，比如 GitHub 的 star 数或者性能基准测试，但你们是否会通过具体的指标来衡量成功？或者说你们是靠直觉，并没有具体标准？

Soumith Chintala： 我们认为，指标是帮助我们衡量成功的一种方式。在产品开发过程中，很多人会过早地制定指标，他们认为优化或测量指标能给他们提供一条客观且稳妥的成功之路，这在构建性能产品或明显可测量的产品时可能有效，但就 PyTorch 而言，我们的目标是为用户提供更好的体验，用户体验具有高度主观性，就我所知，目前还没有一种得到普遍认可且有效的用户体验衡量指标。

因此，在最初开发 PyTorch 的两到三年间，我们使用了一些信号来进行衡量，比如下载量和引用 PyTorch 的研究论文数量，但我们的产品迭代主要取决于收集到的用户反馈。我个人每天会阅读500条来自论坛和 Twitter 的信息，并尽量回复。我们会与客户直接互动，积极交流。我们有一个由六人组成的优秀团队，他们会与我们的高价值客户或者对 PyTorch 生态系统带来巨大价值的客户保持紧密联系。这个过程能够帮助我们不断迭代、改进产品，并确保我们朝着正确的方向行进。

对我来说，我们使用的指标更多是一种保证，检查我们是否还在正确轨道上，但实际上，我们并不以这些指标来指导开发周期，也并不用它来激励我们向成功迈进。

Lukas Biewald：当你们规划发展路线时，如何选取用户意见呢？你们会采纳或忽略何种意见？

Soumith Chintala：我们基本上会从各种渠道汇总反馈意见，包括论坛、Twitter、 Slack 等直接进行重要互动。在规划期间，大约每六个月，我们会对所有反馈进行综合排序，按照反馈的关注度加权排序，然后进行决策。另外，我们会询问团队成员，了解他们的期望。我们拥有一支由 PyTorch 团队工程师组成的团队，会询问他们愿意投入精力去做哪些事。通常情况下，这种匹配效果还不错。

对于一些有趣但排名靠后的功能，我们可能会考虑开发这些功能；但对于需求量低且排名靠后的功能，我们就不会选择进行开发。所以，功能开发与否也有一部分取决于该功能是否新颖有趣，这会帮助我们自然地进行选择。这是我们处理大多数功能决策的一般方法。

另外，我们还有一部分深层策略，例如推出会显著改变产品的功能，比如现在需要推出 Torch 编译等功能。这些功能通常不会来自用户反馈。我们有一个自然的管理层次结构，其中有一些核心维护者，在讨论策略时，我们会根据行业变化趋势来决定如何以及何时进行调整。

Lukas Biewald：你们如何看待构建在 PyTorch 之上的库，比如 fast.ai 或者 Lightning ？你们是否会尽量避免推出与其重复的功能并与它们合作？

Soumith Chintala：我们的工作原则是尽量提高效率，减少工作量。我们坚信要为社区赋能，同时也想从社区中分一杯羹，因为我们还处于发展阶段，还很“饿”。与社区规模相比，我们团队的规模并不是很大，所以除非激励机制完全不一致，否则采取其他策略对团队自身是不明智的。

通常情况下，当我们考虑采取某个方向时，我们首先会确保社区中没有其他人对此感兴趣；如果社区中有人对此感兴趣，我们会观察一段时间，判断他们会成功还是失败。我们通常会选择社区不感兴趣但却有大量社区成员感兴趣的方向，这种社区和成员兴趣的不对称性对我们来说是最理想的发展方向。

因此，我们与 fast.ai、Lightning 以及社区中其他利益相关者密切合作，为他们提供赋能，挖掘他们的潜力。这样做对我们来说大有益处，他们做得越多，我们需要做的就越少。因为我们有成千上万个待处理问题，不可能将其全部完成。这就是我们对建立在 PyTorch 之上的库的看法。

Lukas Biewald：你们是如何与 Facebook AI Research (FAIR) 合作的？FAIR 能得到什么好处？为什么他们会投资？除了开发 PyTorch，你们还做了哪些事？

Soumith Chintala：Meta 之所以投资 PyTorch 并保持其开源，主要是因为 PyTorch 庞大的生态系统。通过使用与行业中其他人相同的工具，Meta 能够更快地迭代自己的 AI 工作。例如，当有新的 AI 工作开发出来时，很大一部分是在 PyTorch 中运行的，因此，像 Google 这些企业内部的应用科学家需要将其转换为 TensorFlow，并进行适当测试，这些大企业倾向于使用自己构建的工具，但是使用 PyTorch 这些与行业中其他人相同的工具有助于加速应用过程。

此外，PyTorch 作为一个流行工具，使得 Meta 在开展新项目时能够从其他人的工作中受益，同时也能吸引一些人才。然而，人才招聘只是整体利益中的一小部分，最主要的还是 PyTorch 庞大生态系统所带来的好处。

Lukas Biewald：从这个角度来看，成为标准对 PyTorch 来说肯定非常重要，除了你不断提到的构建最高质量、最有用的库之外，你们是否还做了其他措施，推动 PyTorch 成为增长最快的标准深度学习框架？

Soumith Chintala：一般来说，如果你试图成为标准，往往很难实现这个目标；但如果你致力于构建最优秀的产品，成为标准的可能性会更大。很明显，除非存在两个或多个意识形态有显著差异但都非常成功的项目，这样才会导致多个标准的并存。

老实说，我们努力做的唯一一件事就是构建最卓越的科学计算框架，当然我们也希望这可以帮助我们在其他方面取得成效，比如成为标准。然而，一开始我们并未将成为标准作为最初目标。

Lukas Biewald：芯片在其中扮演了什么角色？PyTorch 是如何与硬件供应商相互协作？

Soumith Chintala：我们将自己视为两类客户的供应商，一类是前端使用 PyTorch 的用户，他们通过 PyTorch 表达自己的数学思想以完成工作；另一类是后端客户，即服务器端和边缘端的硬件供应商客户，他们努力使自己的硬件在 PyTorch 的抽象层下良好运行。如果运行成功，他们将自动获得数百万客户的认可。

我们在现有平台上（例如 NVIDIA GPU 和 CPU）的工作很大一部分是性能调优，例如，新 GPU 的性能特性发生了变化，因此我们必须更新内部代码和传递方式，以提高性能。而在新平台上（如 AMD、Mac GPU 或 TPU 等其他加速器）的工作主要是功能补全，因为 PyTorch 的 API 非常庞大，约有一千个 API 函数，再加上是否使用量化张量、常规张量以及其他各种分布式功能，这使得维护 PyTorch 的后端平稳需要投入大量工作。所以在与新供应商（TPU、AMD GPU 和 Apple 等）合作时，我们经历了大量从零开始的工作。

Lukas Biewald：可以看出，你对一些新的框架如 JAX、Tinygrad、GGML 等非常感兴趣，你比较欣赏哪些方面的技术创新？

Soumith Chintala：JAX 试图成为一个纯函数图整合框架，利用其纯函数特性使用户能够进行功能强大的函数转换，就像函数编程者使用 map 和 reduce 等函数式转换。JAX 将这一功能开发到了极致，我认为它的理念可能是“函数式深度学习”。

JAX 在验证和挖掘众多优秀想法方面十分出色，它推翻了很多不太实用的想法，这些经验有助于我们从多方面了解自身的发展方向。

GGML 和 Tinygrad 稍有不同。GGML 采用了全面垂直一体化方法，他们的思路是，如果我们只需要为 LLaMA 构建一个框架，它只有一个生命周期，那我们该如何将这个想法推向极致？

他们正在从事一些相当有趣的探索，例如研究量化在何种情况下有效，探究用户的偏好以及在 Mac 等设备上性能的基准等等。这些都是非常有用的信息，通过 GGML 能够快速验证这些想法，帮助我们更好地了解和指导自己的工作。

关于 Tinygrad，正如 Jihad 所说，我们认同复杂指令集，然而，对于深度学习而言，简化指令集已经足够，因为不太需要涉及控制流和其他因素。虽然我们不完全认同这一观点，但这个方向值得探索，可能会取得令人惊喜的成果。或许他会构建一个出色的 AMD 后端，或者在未来的开发中我们会看到它的应用。因此，我非常欣赏开发者选择与我们不同的道路并积极探索。

总之，我对竞争保持着密切关注，尤其是良性竞争，这不仅对用户有益，对我们自身也十分有益，它激励我们不断进步。例如开发 JAX 时，我们积极参与其中，试图向他们提供有益建议，告诉他们该做什么，不该做什么。

JAX 发布时，我们努力向用户宣扬其优点，树立其声誉，并用我们的个人账号转发相关内容等。我认为，JAX 正在探索一种很有趣理念方向，我相信其间会涌现很多其他优秀想法，即便我们可能不会直接采用 JAX 模式，但它也将帮助我们形成自己的认知并获得启示。

Lukas Biewald：据我观察，特别是在最近一段时间内，Weights & Biases 的发展呈现出一种趋势：从过去传统的机器学习研究者和机器学习工程师逐渐偏向软件开发，他们对机器学习有一定了解，但更专注于底层技术性框架，更注重底层实现。你是否在自己的项目中也观察到了这种趋势？

Soumith Chintala：是的，我们目前观察到的一个流行趋势是，很多用户甚至并不知道他们在使用 PyTorch，他们只知道自己正在使用被打包的 Mac 应用或者通过 Hugging Face 等提供的稳定扩展功能。因此，我们正在认真思考这一点，实际上，这也是我们目前正在解决的关键问题之一。

我认为这与以杠杆效应的角度来思考整件事有关。我们的客户主要分为两部分，一是硬件供应商，二是用户。关于硬件供应商，NVIDIA 一直处于主导地位，虽然我们也尽力帮助其他供应商，但他们的市场份额相对较小。在用户方面，PyTorch 则一直保持相对平衡，没有单一的主导用户群。然而，现在出现了一个新的用户群，他们的规模迅速扩大，甚至不直接使用我们的 API。从战略角度来看，我不认为这会对我们的产品构成生存威胁，但从杠杆动态变化的角度来看，这对 PyTorch 至关重要。

如果一个前端应用要求我们更改 API，但这与我们的理念不一致，我们却没有反向杠杆来回绝他们。因为正如我之前所说，PyTorch 非常务实，致力于为用户服务，虽然也有一些基本的方法论原则，但在很大程度上它们都非常低级，除此之外，我们做决策时都以务实为导向。所以我主要担心你刚才谈到的这一方面，但目前我还没有解决方案可供分享。我们正在积极思考如何应对这个问题。

Lukas Biewald：对于开源模型和闭源模型，这是一个一直备受争议的话题。可以看到 Stability.ai 开源了许多模型，同时也有许多人转向了 HuggingFace。然而，在进行语言模型提示工程时，大多数客户仍在使用 GPT-4、Anthropic 和  Cohere 等模型。这种情况有可能改变吗？

Soumith Chintala：显然，我对这种现象存在偏见，我将成年后的大部分时间用在了开源领域，甚至在我工作之前，也一直将开源视为兴趣所在。我从开源中获得了一种解放，一种透明度和一种赋权感。如果没有开源，当时我在印度与父亲共用一台性能较低的笔记本电脑时，可能不会像现在这样有能力完成一些任务，因为我们当时无法购买昂贵的软件。

开源和盗版二者间只有一个具有合法地位，这是事实。所以为什么还要开源呢？这是个常见问题，还有类似于“为什么要将自己的产品无偿分享出去？”或者“为什么不利用它来赚更多的钱？”等问题，这些问题都是可以理解的。开源确实能够带来收益，但如果不考虑知识产权，很明显，一些大模型可能会因为安全性和可靠性等问题而被认为不适合部署。

这是一个有关价值取向的争论，取决于你更看重什么。如果你认为赋予人们更多权力更加重要，比如让尼日利亚的孩子能够访问这个模型，并在当地按照自己的意愿进行创作，那么短期内可能会导致模型的垃圾信息激增。

如果你认为权衡开源的利弊更为重要，即使可能带来轻微的负面影响；或者坚信“开源会导致灾难，人工智能会造成人员伤亡”等观点，这确实取决于个人信仰。这并不是一个确定的结果，你无法准确估计事件发生的概率，所以人们会用他们认为正确的方式做决策。

我相信，当前这一代甚至下一代的AI模型不会对人类构成任何危险，并且开源利大于弊，因此我赞同开源。

我深信，社会具备强大的适应能力，这种能力是一个不断重复的过程。每当出现颠覆性变革时，总有一部分人认为社会即将崩溃，而另一部分人则坚信我们能够平稳度过。事实上，社会几乎总是能够非常出色地适应变化。无论是印刷术、工业革命还是互联网等技术变革，人们往往低估了社会适应新事物的能力。这就是我的观点，尽管这种观点可能在某些地方并不受欢迎。

Lukas Biewald：关于机器学习，你认为哪些方面被低估了？ 

Soumith Chintala：在当前机器学习受到高度关注的情况下，我们很难找到其被低估的领域。但我认为，人们应该投入更多的时间构建一种系统，将80年代的符号推理系统与我们今天所看到的端到端神经网络系统相结合。这种符号推理系统在90年代很受欢迎，在21世纪初也产出了大量成果。许多人在80年代和70年代末就因这些方向性系统研究获得了图灵奖。

Lukas Biewald：将机器学习应用于现实世界的最大挑战是什么？

Soumith Chintala：人们总是高估了机器学习在解决问题时发挥的作用。虽然机器学习可能会解决问题中最具挑战性的部分，但往往只占整个问题的一小部分。人们经常会惊讶地发现，AI 并不是一个简单的魔法工具，只需一挥手就能解决所有问题。

AI 的大部分进展，无论是研究还是应用，都涉及构建损失函数，必须非常仔细，否则它就无法按照你期望的方式工作。损失函数，或者所谓的反馈循环在指导方向上扮演着重要角色，它的影响力相当大，效果常常让人吃惊，但它往往被严重低估。

Lukas Biewald：听说你正在开展家务机器人项目。

Soumith Chintala：大约12年前，我开始涉足机器人领域，在此投入了几年的研究。然后在2019年和2020年左右重新开始关注机器人领域。这个决定源自一个非常简单的动机，我不喜欢做家务，因此我想将这些琐碎的任务自动化。但我逐渐认识到，实现家务活的自动化并不容易，这是一个值得深入研究的问题。

我的动机非常单纯。我认为，机器人在某种程度上拥有强大的力量：如果你也喜欢偷懒，可能也会得到很好的结果。我每周花半天的时间与纽约大学的 Lerrel Pinto 教授以及一群学生一起探索这一领域。机器人大致可以概括为：肌肉和骨骼（即构建硬件）、构建大脑和传感器（主要是构建智能）以及与人类交流。如果机器人拥有智能，就可以完成各类任务，但是，机器人是否能够与人类进行有效的交流呢？这是一个值得探讨的问题。 

机器人学作为一门基础学科，关键问题在于能否制造出机器人，这其中涉及脑科学，即如何使机器推理和观察世界。我在这方面提供了一些帮助，主要是因为许多人都在从事这个领域的工作，特别是在深度学习和机器人学的交叉领域。此外，还有与人类互动的部分，我并不仅仅指学术角度上的人机交互（HCI、HRI）。

更多是从产品方面来看待这一问题，就像你第一次使用 iPhone 时，一切都是如此自然流畅，无需特意学习，类似于这种与机器人进行交流的方式，已经有很多人在这个领域进行深入研究和探索。

因此，我更专注于这方面的工作，致力于通过手势和动作的组合，迅速教导机器。我对这个领域非常感兴趣，机器人距离现实应用还有很长的路要走。

我预计，大约七年内，能够在家中实现某些人机交互流程的自动化，尽管这并不是一个能够适用于各类环境的通用解决方案。也许到那时候，会有更多的资本注入其中。我认为，这个领域将从依赖政府拨款支持的研究项目逐渐转变为一个能够实现更大规模应用的新兴产业。时间会揭示答案，这个过程会非常有趣。

*原文链接：

https://www.youtube.com/watch?v=2wprKvXnErE

  转载自丨OneFlow

  编辑丨朱奇玉

开源社简介

开源社（英文名称为“KAIYUANSHE”）成立于 2014 年，是由志愿贡献于开源事业的个人志愿者，依 “贡献、共识、共治” 原则所组成的开源社区。开源社始终维持 “厂商中立、公益、非营利” 的理念，以 “立足中国、贡献全球，推动开源成为新时代的生活方式” 为愿景，以 “开源治理、国际接轨、社区发展、项目孵化” 为使命，旨在共创健康可持续发展的开源生态体系。

开源社积极与支持开源的社区、高校、企业以及政府相关单位紧密合作，同时也是全球开源协议认证组织 - OSI 在中国的首个成员。

自2016年起连续举办中国开源年会（COSCon），持续发布《中国开源年度报告》，联合发起了“中国开源先锋榜”、“中国开源码力榜”等，在海内外产生了广泛的影响力。