Jane Street如何为OCaml打造专属AI编程工具链

引言：当顶级量化交易公司遇上LLM

Jane Street，全球最知名的量化交易公司之一，其AI Assistance团队负责人John Crepezzi在近期分享中详细介绍了他们如何将大语言模型应用于内部开发工具。这个分享之所以引人注目，不仅因为Jane Street的技术实力，更因为他们面临着一个独特的挑战——整个公司的技术栈建立在OCaml这门极其小众的编程语言之上。

这意味着市面上所有现成的AI编程工具对他们来说几乎不可用，他们必须从头构建整套AI辅助开发体系。这个过程中积累的经验，对于任何想要在非主流技术栈中应用LLM的团队都极具参考价值。

为什么现成的AI编程工具不适用

OCaml语言的特殊性

OCaml（Objective Caml）诞生于1996年，由法国国家信息与自动化研究所（INRIA）开发，是ML语言家族的重要成员。它融合了函数式编程、命令式编程和面向对象编程三种范式，以其强大的静态类型系统、类型推断能力和高性能运行时著称。OCaml的类型系统能在编译期捕获大量运行时错误，这对金融交易系统的正确性保障至关重要。

Jane Street选择OCaml并非偶然——该公司从2003年前后开始大规模采用OCaml，认为其类型安全性和表达能力能有效降低交易系统中的逻辑错误风险。Jane Street也因此成为OCaml最重要的工业级用户和贡献者，维护着Core、Async等被广泛使用的OCaml开源库。这门语言主要用于定理证明、形式验证和编程语言开发，而Jane Street将它用于几乎所有场景：Web应用通过JS of OCaml转译为JavaScript，Vim插件通过VCaml转译为VimScript，甚至FPGA代码也用HardCaml库编写。

模型对OCaml的支持极差，原因很简单——训练数据太少。John直言，Jane Street内部的OCaml代码量很可能超过了全世界其他地方OCaml代码的总和。

自建工具生态的集成代价

除了语言本身，Jane Street还构建了完整的自有工具链：自研构建系统、分布式构建环境、代码审查系统Iron（类似PR系统）、基于Mercurial的巨型monorepo，而且67%的员工使用Emacs。

Monorepo（单一代码仓库）是将公司所有项目代码存放在同一个版本控制仓库中的工程实践，被Google、Meta、Twitter等科技巨头广泛采用。相比多仓库模式，Monorepo的优势在于跨项目重构更容易、依赖关系更透明、代码复用更便捷。Jane Street选择Mercurial（Hg）而非Git，部分原因正是Mercurial在大规模仓库管理上的历史优势以及更好的扩展性支持。在AI辅助开发的语境下，Monorepo意味着模型需要理解跨越数百万行代码的依赖关系，这对上下文窗口的利用策略提出了更高要求，也是RAG（检索增强生成）在代码场景中价值凸显的重要原因。这些技术选型让外部AI编程工具的集成变得异常困难。

从Meta论文到自训练模型

Code Compose论文的启发

Jane Street的信心来自Meta发表的Code Compose论文。该论文发表于2023年，详细描述了如何为Hack语言构建代码补全系统，展示了为Hack语言微调模型的成果。Hack是Meta于2014年推出的编程语言，基于PHP演化而来，专为Meta的大规模服务端开发设计，引入了渐进式类型系统。Hack几乎只在Meta内部使用，这与OCaml在Jane Street的处境高度相似——都是"单一大客户"语言，公共训练数据极度匮乏。Code Compose的核心贡献在于证明了通过企业内部代码进行领域特定微调，可以显著提升模型在小众语言上的表现。值得一提的是，Hack本身就是用OCaml实现的，两种语言之间存在一种有趣的技术渊源。

然而，团队很快发现"拿模型看一堆代码就能学会"这种想法过于天真。要获得好的效果，必须让模型看到大量与目标任务形状一致的训练样本。

明确目标：生成可应用的Diff

团队设定了清晰的目标：用户在编辑器中输入自然语言描述，模型生成可能涉及多文件的diff。这些diff需要能够干净地应用，并且有较高概率通过类型检查。目标范围控制在100行以内。

训练数据的形状为：上下文 + 提示词 + diff。问题是，如何大规模获取这样的数据？

工作区快照：训练数据的创新获取方式

Feature和Commit为何不够用

最直觉的数据来源是代码审查系统中的Feature（类似PR）。它有人类编写的描述和对应的代码变更。但问题在于：Feature描述的写法与编辑器中的指令完全不同（前者是多段落的正式描述，后者是"修复那个错误"这样的简短指令），而且Feature通常有500-1000行变更，远超目标范围。

Commit也不理想——Jane Street的commit主要用作开发过程中的检查点，没有有意义的描述，也不是隔离的变更。

工作区快照方案的核心设计

最终方案是工作区快照（Workspace Snapshotting）。系统每20秒对开发者的工作站进行一次快照，同时记录构建状态。通过识别特定模式，团队可以提取高质量训练数据：

• 绿-红-绿模式：开发者做了一个隔离的修改（从正常状态到破坏构建再到修复）
• 红-绿模式：开发者遇到错误并修复，可用于训练模型从错误中恢复

对于描述部分，团队用LLM生成详细的变更描述，然后逐步精简到人类在编辑器中实际会写的长度。这种方法巧妙地将日常开发活动转化为了结构化的训练数据。

强化学习与代码评估服务

定义"好代码"的标准

训练的第二阶段是强化学习，需要定义"好代码"的标准：

1. 能解析：通过OCaml解析器
2. 能类型检查：静态类型系统验证通过
3. 能编译并通过测试：终极标准

将强化学习（RL）应用于代码生成是近年来LLM领域的重要进展。与依赖人工标注偏好的RLHF（基于人类反馈的强化学习）不同，代码领域存在天然的可验证奖励信号——编译器和测试套件的通过与否是客观的二元判断，无需人工介入。这种方法被称为基于执行反馈的强化学习，OpenAI的Codex、DeepMind的AlphaCode等研究都验证了执行反馈对代码生成质量的显著提升作用。这种"可验证奖励"的思路也正在被推广到数学证明、逻辑推理等其他可形式化验证的领域。

CES：代码评估服务架构

团队构建了Code Evaluation Service（CES），其核心设计是预热构建——在某个revision上保持绿色构建状态，然后让worker不断接收模型生成的diff，应用后检查构建是否仍为绿色。通过维护预热的构建环境，将原本需要数分钟的冷启动构建压缩到秒级响应，使得大规模RL训练循环成为可能。这个反馈循环持续数月运行，逐步提升模型生成可编译、可通过测试的代码的能力。

同样的基础设施也用于评估——保留部分RL数据作为测试集，持续监控模型表现。

训练过程中的深刻教训

训练可能产生灾难性但搞笑的结果。团队曾训练一个代码审查模型，投入数月精力后，第一次提交代码让它审查，模型回复了"I'll do it tomorrow"（我明天再做）。原因很简单——训练数据中包含大量人类审查者的真实回复，而人类确实会这么说。这个案例深刻说明了建立有意义的评估体系的重要性。

AID架构：多编辑器统一的AI开发环境

架构设计原则

面对三个编辑器（NeoVim、VS Code、Emacs）的支持需求，团队确立了三个原则：

1. 不重复造轮子：上下文构建和提示策略只写一次
2. 保持灵活性：能随时切换模型或提示策略
3. 可度量：收集延迟、diff应用成功率等指标

AID Sidecar服务的实现

Sidecar（边车）是一种源自微服务和云原生领域的架构模式，最初在Kubernetes等容器编排系统中广泛应用。其核心思想是将辅助功能从主应用中剥离，以独立进程的形式运行在主应用旁边，通过本地IPC（进程间通信）或HTTP接口交互。这种模式的优势在于：主应用无需感知辅助逻辑的实现细节，辅助服务可以独立更新部署，不同技术栈的主应用可以共享同一个辅助服务。在AI编程工具领域，GitHub Copilot的语言服务器、Cursor的后端服务都采用了类似思路。

最终架构是一个名为AID（AI Development Environment）的Sidecar服务，运行在开发者本地机器上。AID负责所有重活——构建提示词、组织上下文、查看构建状态、与LLM通信。各编辑器只需实现薄薄的UI层。

这种架构的优势显而易见：更新AID时无需重启编辑器，只需重启sidecar服务即可让所有人获得最新版本。团队还能进行A/B测试——将50%的用户路由到一个模型，另外50%到另一个模型，比较接受率。

因编辑器而异的交互体验

在VS Code中，AID呈现为侧边栏界面，类似Copilot但支持多个候选结果。而在Emacs中，考虑到用户习惯在文本缓冲区中工作，团队将整个AI交互体验构建为一个Markdown缓冲区——用户可以像操作普通文件一样移动、复制、编辑，通过快捷键追加新内容。

关键经验与未来方向

Jane Street的AI工程实践揭示了几个重要原则：

• 数据获取需要创造力：工作区快照是一个巧妙的解决方案，将日常开发活动转化为高质量训练数据
• 可验证性是关键：利用编译器和测试作为强化学习的奖励信号，比人工标注更可靠且可扩展
• 架构的可插拔性：在LLM快速迭代的时代，保持系统各层的解耦至关重要
• 评估先行：没有可靠的评估体系，训练投入可能完全浪费

团队目前还在探索RAG在编辑器中的新应用方式、大规模多Agent工作流、以及推理模型的深度集成。核心方法论始终不变：保持可插拔、打好基础、让公司其他团队能通过领域特定工具扩展平台能力。

核心要点

• Jane Street因使用OCaml这门极小众语言，市面AI编程工具几乎不可用，必须自建整套LLM辅助开发体系
• 团队通过工作区快照（每20秒采集一次）结合构建状态变化来自动生成高质量训练数据，解决了传统PR/Commit数据不适配的问题
• 构建了代码评估服务CES，利用编译器和测试作为强化学习的奖励信号，持续数月对齐模型生成可编译代码的能力
• 设计了AID（AI Development Environment）sidecar架构，一次编写核心逻辑即可支持VS Code、Emacs、NeoVim三个编辑器
• 核心工程哲学：保持可插拔性、建立可靠评估体系、让LLM的快速迭代能以最小成本传导到所有终端用户