Laurent Mazare 谈 Python、OCaml 与机器学习

Ron Minsky 与 Laurent Mazare 讨论 Python 和 OCaml 在 Jane Street 如何配合。虽然公司以使用 OCaml 闻名，Python 对数据分析和机器学习也很重要，两种语言都连接到共享基础设施。

Mazare 的职业生涯始于 LexiFi，使用 OCaml 为金融合约及其收益建模。在 Goldman Sachs，他使用内部脚本语言 Slang；2013 年，他加入 Jane Street，用 OCaml 开发交易系统。

后来，他在 DeepMind 工作了一年，主要使用 Python 和 TensorFlow，并尝试将 Swift 用于机器学习，之后回到 Jane Street，更专注于研究。如今，他在 Python 和 OCaml 上花费的时间大致相当，但工作方式很不一样。

他的开源项目包括 PyTorch 的 OCaml 和 Rust 绑定，使这两种语言能够使用 GPU 计算和自动微分。他还为 Rust 的 Clippy 作出过贡献，并参与 OCaml 的绑定和数据框相关项目。

Mazare 使用 Python 笔记本开展研究。笔记本让他运行一个单元、检查结果、修改代码后再次运行。绘图库让他可以在紧密的反馈循环中轻松比较算法输出与直觉，并调查意外结果。

他的 OCaml 工作通常涉及对生产至关重要的开发。他见过一些任务在部署多年后仍然运行。他认为，这种韧性既来自语言特性，也来自工程实践：测试、显式处理错误和关注边界情况。

Minsky 将语言、生态和组织实践区分开来。Mazare 说，Python 已成为机器学习和数据分析事实上的常用环境，拥有丰富的绘图库、教程，以及主要框架优先提供的 Python 接口。庞大的生态又会吸引更多用户。

OCaml 的库较少，尽管 Mazare 认为其中很多质量很高。绑定可以弥补差距：OCaml 可以调用 Python 的 Matplotlib 绘图，也可以使用 TensorFlow 和 PyTorch 的绑定。Minsky 强调，可视化让笔记本中的探索性工作特别有吸引力。

Mazare 认为两个环境都能提供快速反馈，但方式不同：笔记本展示数据上的运行结果，而 OCaml 构建系统会在代码变化时报告类型不匹配。在 Python 中，研究人员更依赖实验；在 OCaml 中，类型检查器会在执行前提供额外反馈。

Minsky 指出，OCaml 也可以通过 expect tests 支持探索工作。代码和捕获的输出放在一起；测试重新生成输出，开发者可以接受变化。他用这种循环进行网页抓取等任务，但它没有笔记本的图形组件。

Mazare 同意 expect tests 具有交互性，但认为它们通常侧重于长期代码中的边界情况。笔记本实验则可能只求在特定数据集上工作，以后再也不会运行。目标不同，值得为通用性付出的成本也不同。

Minsky 问，如果 OCaml 拥有同样好的笔记本、可视化、编辑器支持和库，Python 是否仍有优势。Mazare 说这很难判断，但动态类型可能有用：为整数编写的小算法可能无需修改运算符就能用于浮点数。

鸭子类型还允许算法处理提供所需方法的不同对象。这种灵活性以放弃一些保证为代价：程序员从相关输入的实验中获得信心，但错误可能直到运行时才出现。

Minsky 说，静态类型为不同执行情况建立属性保证，但获得这些保证需要让代码符合类型系统。OCaml 的类型推断让这一协调过程相对轻量；对于一次性探索研究，完全跳过这一步仍可能很有吸引力。

Mazare 起初把类型描述为证明代码正确。Minsky 缩小了这一说法的范围：类型系统证明的是某些属性，而不是整体正确性。这些属性可以消除大类错误，但不能取代所有其他推理和测试。

数值代码是类型帮助可能较少的一个例子。矩阵或浮点值可能类型正确，却代表错误的计算；一次分解可能收敛不佳，或产生略逊于最优的答案。发现这些问题往往需要检查数据和结果。

Mazare 指出，即使判断一个浮点值是否会成为 NaN 也很困难。实验可以发现手头数据的问题，但在数值程序中检查每一种可能的输入，可能会带来过多负担。

Minsky 将快速探索与长时间模型训练作比较：GPU 工作数天后才发现一个小错误，代价很高。Mazare 说，研究人员通常会先用较小规模端到端试运行，包括输出模型和检查点，但未测试到的分支仍可能在之后失败。

类型检查器可以在长任务运行前发现错误，例如在需要文件名的地方传入整数。Mazare 提议分工：Python 仍适合快速迭代数值模型，更有韧性的基础设施则处理正式训练和生产问题。

生产基础设施必须考虑机器不可用、文件系统问题和普通编程错误等故障。用 OCaml 重写 Python 模型可能带来速度和保证，但会产生可能逐渐不一致的两套实现；从 OCaml 调用 Python 是另一种选择。

在公司维护独立实现的场景中，生成的模型可以同时包含权重和样例输入、输出。OCaml 部署使用保存的权重运行样例，并检查结果是否一致，以此进行实际的一致性验证。

Mazare 介绍了用于互操作的开源库 PyML。它可以从 OCaml 调用 Python，例如使用 Matplotlib；但 Jane Street 经常反向使用它：Python 笔记本需要访问 OCaml 服务，以获取市场数据、其他数据和执行操作。

OCaml 代码可以编译成由 Python 加载的共享库。启动 OCaml 运行时会注册可供 Python 调用的函数，从而只需编写很少的 Python 代码就能提供包装接口。这减轻了不每天使用 Python 的 OCaml 开发者的负担。

Minsky 将此与 Ecaml 作比较：它让公司用 OCaml 编写 Emacs 扩展，同时与 Emacs Lisp 交互。两种方法都在运行时之间反复传递控制权；类似工作也用于 Vim。Mazare 说，大量交替调用能够透明地运行，令人惊叹。

互操作也带来内存管理风险。OCaml 使用追踪式垃圾回收器；Python 主要使用引用计数，并使用回收器处理循环。跨越两个运行时的循环，即使整体对象已不再有用，在每个回收器看来仍可能可达。

Mazare 描述了一个跨运行时循环，它浪费了数十兆字节内存，直到被发现并修复。Minsky 说 Ecaml 也遇到过同类问题。任何一个回收器都无法独自完整看到这个循环，因此这是互操作中的根本难题。

谈到如何选择语言，Mazare 倾向于为需要持续数周或数月的代码以及符号操作选择 OCaml。语法扩展就是一个例子：类型和模式匹配有助于确保程序处理语言中不同的语法情况。

Minsky 将例子扩展到编译器之外。包括交易系统在内的许多系统都有包含大量可能情况的组合结构。穷尽模式匹配可以帮助开发者在代码中考虑每一种情况。

跨语言共享计算也是在 Python 中暴露 OCaml 的一个理由。Minsky 说，团队可以只实现一次核心计算，获得效率优势，并在两个环境中复用，而无需维护两个版本。Mazare 补充说，共享代码必须经受作者未曾预料的用法。

对于一次性脚本，投入精力处理所有情况可能不值得。但对于许多人在不同场景中调用的库，类型系统推动开发者考虑不同情况，这可能值得付出努力，不过测试仍然重要。

Minsky 认为类型和测试相互增强，而不是互相替代。静态约束可以让行为更加固定，因此对关键情况的测试可能比仅靠测试约束行为的代码带来更广泛的信心。

他问 Jane Street 是否应该改进 Python 的测试和工具。Mazare 说，公司正在学习，增加类型注解和自动生成文档，并重新建立 OCaml 领域经过多年打磨的实践。他承认，公司的 Python 实践当时还不如专门使用 Python 的组织成熟。

Mazare 认为，当 Python 主要用于连接经过充分测试的 OCaml 组件时，交付的 Python 层可能很小，但连接层本身仍需测试。Minsky 提醒，即使很短的程序也可能包含令人意外的错误。

Python 的数值生态也可能隐藏棘手的边界情况。Mazare 提到 NumPy 和 pandas：它们功能强大，让分析迅速，但库的意外行为可能悄悄产生错误的模拟结果。较大的错误可能让人找到一个已知陷阱；较小的错误则可能永远不被发现。

Minsky 将其与电子表格分析作比较：网格展示中间计算并支持快速可视化，但自动类型推断可能产生危险后果。他提到名称被解释成日期以及股票代码可能被误读的情况，说明看似合理的数值错误可能一直未被察觉。

Mazare 从偏爱 Linux 的角度拿 Excel 开玩笑，但他很佩服熟练的交易员能通过快捷键从 Bloomberg 提取数据、绘图并迅速分享结果。用 OCaml 重现这样的分析可能需要数小时。Excel 的响应式重算也是一项优势。

在他看来，Python 处于电子表格和生产代码之间：它能够处理更大的数据集和更多计算，但失去了让人一眼检查全部数据的能力。数据太大而无法直接查看时，分析人员通常依赖摘要和极值。

Minsky 强调了正确性方面的区别。Excel 跟踪依赖图，在数值变化时重新计算受影响的单元格。Python 笔记本允许用户单独重新运行单元，因此显示的结果可能反映不同执行状态，不一定彼此一致。

Mazare 说，笔记本的可变状态和乱序执行会让人难以重建结果是如何得到的。重新运行全部内容可能成本很高，但如果一个结论无法从头重现，那确实是问题。

他们讨论了替代方案。Mazare 说，Polynote 让状态更加明确，并尝试恢复某个单元的上下文，但深层修改和别名可能超出这一模型的处理范围。Julia 的实验性 Pluto 跟踪依赖并重新运行相关单元，面对长时间计算时则存在权衡。

Minsky 建议，当单元发生变化时，界面至少可以标明哪些结果已经过时，即使用户选择不立即重新运行昂贵的计算。让显示结果的可靠性可见，将是有用的改进。

话题转向 Swift 和可微分编程。Mazare 解释梯度下降：模型有参数和损失函数，梯度引导参数更新，趋向局部最小值。Minsky 将这一过程比作球向山下滚动，只是扩展到许多维度。

对于拥有数百万参数的模型，用数值方法估算梯度的成本很高。TensorFlow 和 PyTorch 构建计算图并对其求导；另一种方式是由编译器根据程序的操作生成梯度，前提是它知道如何对这些操作求导。

Minsky 将自动微分解释为把求导规则应用到程序，包括控制流。Mazare 指出，分支和递归会带来挑战，但许多现代机器学习模型使用的操作可以求导并组合。

Swift 起源于 Apple，是 Objective-C 的继任语言。Mazare 说，Chris Lattner 探索了几种用于机器学习的语言，并选择 Swift 制作原型；Swift 的编译特性、类型和函数式特征使它成为有趣的实验环境。

该编译器项目旨在识别适合 CPU、GPU 或 TPU 的计算，并管理它们的内存之间的数据移动。开发者可以为函数添加注解，让编译器生成反向传播过程，前提是该函数使用的操作支持微分。

Mazare 对比了 Swift 较偏函数式的风格和 Python 的动态可变状态：纯函数的导数更容易推理。他指出，Python 框架也可以编译带注解的函数及其反向过程，因此两者的区别并非绝对的限制。

另一个考虑是内存管理。大型张量可能占据大量 GPU 内存，及时释放因而很有价值。Mazare 说，Swift 和 Python 一样采用的引用计数有助于快速释放资源，而追踪式垃圾回收不一定会在需要稀缺 GPU 内存时运行。

Minsky 指出，垃圾回收可能不太适合管理普通堆之外的稀缺资源，例如文件描述符或 GPU 内存。他讨论了 OCaml 类型检查资源管理的探索性工作：在需要时显式跟踪资源，在其他地方默认使用垃圾回收。

Mazare 将他的 Rust PyTorch 绑定与 OCaml 代码作比较：Rust 的所有权机制有助于释放张量，而他在 OCaml 代码中会在每次训练循环触发垃圾回收来回收资源。能对选定的值进行更精确控制会很有用。

Minsky 强调，所提议的 OCaml 方法是未来工作，而不是已完成的能力。两人都认为资源管理仍是活跃的设计领域：一个结合便利默认机制与稀缺资源精确跟踪的系统，可能带来好处，而不必在所有地方施加同样的负担。