模型越强，Jane Street 为什么越重视那些「笨功夫」
2026 年 9 月，量化交易公司 Jane Street 在官方播客 Signals and Threads 中，邀请另类数据团队负责人 Eric Mannes，谈这支团队怎样形成，以及数据工程怎样把杂乱的外部数据送进量化研究和交易流程。Eric 在 Jane Street 工作十余年，早期做大宗商品交易；这一次，他把讨论从模型往前推了一步，落到数据在进入模型之前经历的采集、解释、时点处理和验证。
这期节目的标题叫 Wrestling the World into Rows，直译过来，大致是「把现实世界摁进一行行表格」。这个说法很贴切。现实世界不按数据库的 schema 生长，也不会主动告诉研究员，某个数字究竟代表一家公司、一个证券，还是一个不断变化的消费者样本。
Eric 给出的判断也有一点反直觉。模型能力越强，高质量数据的价值越高；模型越会找规律，研究团队越要确认它找到的不是时间穿越留下的痕迹。AI 没有替数据工程收尾，反而把它推到了更靠前的位置。
这支团队从交易台的临时工作里长出来
Jane Street 很早就在使用外部数据，但早期没有专门的 Alternative Data 团队。
某个 trading desk 想研究一套新数据，通常是谁有空谁来做。trader、developer 或 trading desk operations engineer 把文件接进来，放进共享文件系统的某个角落，或者塞进某个数据库。不同 desk 各做一遍，命名、清洗和维护方式也各不相同。
Eric 在播客里估计，这样做出来的结果可能只有理想状态的 60%。这不是严谨测算，更像参与者对当时状态的概括，但问题很清楚，数据很难用，也无法复用。麻烦还不只在工程效率。
当处理一套数据的成本高到研究员不愿碰它，一些交易想法甚至没有机会进入回测。研究边界看上去由模型划定，实际上也被数据抵达研究环境的难度悄悄划了一刀。
Eric 和少量开发人员从小项目做起。他们挑出基础却难用的数据集，处理成研究员更容易调用的形态，再看使用量和交易价值是否真的出现。小范围有效，就继续做；有人开始依赖，就再扩大。
Jane Street 没有先画一张宏大的数据平台蓝图，而是让真实使用一点点证明集中化团队有没有必要。
| 阶段 | 组织方式 | 当时的主要问题 | 变化的含义 |
|---|---|---|---|
| 早期 | 各 trading desk 自行采集和清洗 | 重复建设，标准不一，数据散落 | 外部数据仍被当作单个研究项目的配料 |
| 团队萌芽 | Eric、少量 dev 与少量 data engineer 从具体数据集做起 | 先证明数据变得好用后是否有人使用 | 数据工程由临时劳动变成共享能力 |
| 2023 年 | Jane Street 有 1 名 data engineer | 专业角色刚刚成形 | 「可信数据集」成为可以被专职交付的产品 |
| 2026 年 | data engineer 已超过 20 人，团队仍在招聘 | 数据域和使用场景继续扩张 | 数据可用性被视为研究产能的一部分 |
从无专门团队，到 2023 年的 1 人，再到 2026 年的 20 多人，人数增长当然醒目。但更有信息量的变化，是岗位定义。
- 在 Eric 的区分里，software engineer 的产品主要是软件、系统和服务；
- data engineer 的产品则是一套值得信任的数据集。
两者都会写代码，后者却必须继续追问，字段是什么意思，供应商怎样生成它，研究员准备怎样使用它，哪一部分现实被这个数字漏掉了。代码只是中间物。
把现实变成表格，最难的不是写入数据库
公司财务数据看起来已经足够传统，离卫星图片、网页流量这些另类数据很远。
但 Eric 用它说明，连最普通的表格也藏着定义问题。
把 SEC filing 变成量化研究可调用的数据时，绕不开一个看似幼稚的问题，什么算一家公司？
现实里有 dual-listed company、多种 share class、不同 listing，也有 legal entity 和经济实体之间的不完全重合。一条财务记录究竟应该映射到哪个公司、哪类证券、哪个 ISIN，答案不会从原始文件里自动跳出来。
到了信用卡消费 panel，问题更明显。它比「数 Walmart 停车场里的车」更接近真实消费，却仍不是全体消费者的随机样本。信用合作社客户和 Chase Sapphire Reserve 持卡人的收入、地域与消费习惯可能不同；样本中的人也会进出。
如果 panel 总消费额上涨，可能是消费者花得更多，也可能只是样本里多了人。同一个数字，两种世界。
数据清洗要处理空值、格式和重复，也要调查数据生成过程。少了后面这一步，表格可以非常整齐，却不一定回答研究员以为它在回答的问题。
Jane Street 招聘 data engineer 时强调好奇心和调查过程。系统复杂度或许低于部分软件工程岗位，但数据与业务并不简单。候选人面对陌生数据时，能否分清已知、假设和待验证事项，比迅速写出一大段代码更贴近这份工作。
供应商把历史修对了，回测却可能因此做错
另类数据供应商会补缺失值、纠正分类、重新映射 merchant，也会修改字段的计算方式。
这些 revision 对数据库质量通常是好事。可回测关心的并不只是「今天看来哪个值最准确」，它还要回答「当时究竟能知道什么」。
假设一批 2023 年的交易记录在 2025 年被供应商纠正。研究员今天用修订后的历史去测试 2023 年的策略，得到的是一段更干净的过去，却不一定是 2023 年真实可用的过去。Eric 把这种回测称作带着时间机器做模拟。
偏差就在这里进入系统。vendor revision 本身没有错，错误发生在后来得到的信息被悄悄放回原来的历史日期，并被模型当成当时已知。
Jane Street 的做法，是尽量保存每次实际收到的数据，也保存自己收到它的时间。供应商时间戳仍有用，但内部接收时间提供了另一层证据。此后无论怎样变换数据，研究团队都能尝试重建某个历史时点的可知信息集。
这就是 point-in-time 的要害。
| 数据处理问题 | 常见的方便做法 | point-in-time 做法 | 对回测的影响 |
|---|---|---|---|
| 历史记录被修订 | 旧值直接被新值覆盖 | 保存每个版本及其接收时间 | 避免把后来修正带回过去 |
| 事件日期与可知日期不同 | 按数据描述的期间对齐 | 按公开、接收或可交易时间对齐 | 避免提前使用尚未发布的信息 |
| 供应商映射变化 | 只保留当前 merchant 或证券映射 | 保留映射沿时间的变化 | 防止未来分类渗入历史样本 |
| 文本交给最新 LLM 处理 | 默认模型只读到了输入文本 | 检查模型训练截止与历史知识污染 | 降低模型自身携带未来信息的风险 |
这并非 2026 年才有的原则。量化研究长期警惕 look-ahead bias，财务和宏观数据库也早已讨论 vintage data 与修订记录。另类数据把时点问题带到更多非标准数据里，LLM 又把模型自身的知识截止日期拉进同一场审计。
过去，point-in-time 常被当作数据库的一项质量要求。现在，它越来越像研究结果能否成立的边界条件。
模型中心和数据工程中心，稀缺人力放在哪里
过去几年，量化与 AI 讨论很容易落到更大的 neural network、更多算力和更自动化的特征提取。
这套思路并没有错。更强的模型确实能处理更多变量，也让原本依赖人工规则和复杂正则表达式的文本抽取变得便宜。
Jane Street 没有否定模型，而是补上一块经常被低估的成本。模型中心的研究观把数据视为准备好的输入，主要竞争发生在架构、训练和算力上。数据工程中心的研究观把输入视为长期维护的研究产品，竞争发生在语义理解、版本保存、时点一致性和验证上。
两种路线可以并存，差别在于稀缺人力放在哪里。模型能做的事更多以后，Jane Street 没有缩减数据工程角色，反而在三年内把这个岗位从 1 人扩到 20 多人。仅凭一个团队的变化，不能推出整个行业都应照搬；它至少说明，在 Jane Street 的研究流程里，模型进步没有消除数据工作的回报。
一个简单模型可能看不见数据里微弱的泄漏。一个表达能力更强的 neural network，却可能迅速抓住它，并把未来信息、异常 revision 或样本变化留下的痕迹包装成漂亮的预测关系。回测的 Sharpe 可以很好看。实盘却无法复制，因为真实交易没有时间机器。
Eric 因此判断，模型越强，清洗高质量数据的价值越大。这里的「清洗」包括核对 timestamp、回填字段、样本构成和变换过程是否看见未来。
LLM 又把问题推了一层。它能从非结构化文本提取 feature，也可能已经从训练语料中知道后来发生的事。播客里用了 Enron 作例子，一个最新模型在处理旧财报时，可能携带财报发布时尚不存在的后见知识。
于是，研究团队面对两种时间泄漏。一种藏在数据版本里，另一种可能藏在模型参数里。前者要求保存数据的历史版本，后者要求审视模型本身在那个历史任务上是否真的处于 point-in-time 状态。
模型越聪明，审计它知道什么就越困难。
生成变便宜以后，验证成了新的拥堵点
Eric 并不否认 LLM 对 data engineer 的帮助。熟悉数据域的人可以用它更快写代码、做分析、尝试转换，因为这些人知道目标是什么，也有能力判断输出是否合理。同一套工具也让错误代码和错误分析更便宜。
过去，生产一条数据管道很慢，很多错误还没来得及生成；现在，代码、特征和回测可以成批出现，检查每一个结果是否可信的速度却没有同比提高。播客把它概括为 verification bottleneck。
这不是一句泛泛的「人仍然重要」。它指向几项很具体的判断工作，记录是否符合现实含义，供应商是否改过历史，样本变化能否解释信号，模型发现的是经济关系还是处理痕迹。生成与验证的成本曲线开始分叉。
当生成继续降价，研究团队的产能上限会越来越取决于验证，而不是取决于能否再多写一段代码、再多造一个 feature。
团队演进和模型竞赛，都把压力推向验证
回看团队演进，Jane Street 先由各 desk 顺手维护数据，后来改由专职团队集中处理，到 2026 年已有 20 多名 data engineer。
团队扩张不只因为数据量变大，公司也逐渐确认，数据可用性会决定哪些想法有资格被研究。
- 同一时期，行业模型能力快速上涨，非结构化信息更容易被转成特征；
- vendor revision、样本偏差和 look-ahead bias 却没有消失。
更强的模型还提高了利用这些瑕疵的能力。
数据工程在这套流程里像一套研究证据系统。它保存信息当时的样子，记录数据怎样变化，让回测回答「那时是否真的做得到」，而不只看「现在重算是否很好看」。
因此，20 多人的增长可以理解为两种扩充，ETL 产能增加了，机构辨认错误证据的能力也增加了。这是根据播客所呈现实践作出的推断，并非 Jane Street 对团队规模的正式归因。
Eric 的判断未必适用于所有数据、所有模型和所有交易周期。若数据稳定、定义清晰、几乎不修订，point-in-time 的工程负担会轻一些；若任务高度依赖文本、财报、宏观修订或持续变化的消费者样本，这份负担就会明显加重。
但节目留下的那个问题很难绕开。
当机器越来越会从历史里找规律，我们保存的究竟是历史，还是后来整理过的历史？
模型能捕捉更多模式以后，研究结果是否可靠，越来越依赖数据工程能否证明这些模式在当时已经存在。