95% 的难题：AI、聊天交易与人工复核

Chloe Casale 脚穿护具来到节目中。此前她参加了 Mongol Derby，这是一场为期十天、全程 1000 公里的耐力赛马。骑手要根据 GPS 坐标穿越草原，大约每隔 35 至 40 公里更换随机分配的马匹。

她从小接触马匹，也曾在牧场工作，但不是竞技骑手。她参加一所训练营时，原本只期待一次冒险，并没想到会获得参赛资格；入选后，她决定参加比赛。

Casale 说，一个马镫反复撞击她的小腿。她试图用袜子缓冲，却限制了脚踝活动，并促成了一处应力性骨折。最后一天，她的腿已经无法承重，但仍设法上马，骑完了剩下的 60 公里。

她说，43 名出发者中有 23 人完赛，其他人退赛的原因包括热衰竭和受伤。她为完成比赛感到自豪，但认为参加一次就够了。

她对工程的兴趣始于想弄明白汽车如何运作。高中时她选修了汽车技术课程，起初以为自己可能成为汽车修理工或机械工程师。

大学时，朋友和她打了 20 美元的赌，说她无法通过计算机科学入门课。编写简单的 Java 程序让她觉得像魔法：几条指令就能做出游戏。她爱上了编程，并转到应用计算数学专业，以便四年内毕业。

大学毕业后，她加入 Palantir，担任前线部署工程师。她的工作不是为许多客户构建同一个产品，而是与单个客户合作，了解其问题，调整现有软件并补建缺失的部分。

这项工作还包括在客户需求可能对其他人也有用时，告知产品团队。Casale 喜欢与用户交谈，并说有时最简单的解决办法是一封邮件，而不是写更多代码。

在 Palantir 工作近五年后，她希望接受新挑战。她申请 Jane Street 时并不懂交易、OCaml 或函数式编程，但面试过程中投入的细心让她印象深刻。

她在 Jane Street 的大多数面试都有两位面试官参加。Minsky 说，第二位观察者有助于面试官比较印象并改进技巧；Casale 说，多花一位工程师的时间虽然昂贵，但她仍认为第二种视角很有价值。

她在 Palantir 以纽约为工作基地，但大量时间都在多个国家的客户现场度过。一段在伦敦的经历让她决定下一份工作回到那里：她喜欢这座城市，也觉得它没有纽约那么紧张。

在 Jane Street，Casale 为销售交易员构建工具。销售交易员维护与基金等客户的关系，将请求带回公司，并与负责定价和管理相关头寸的交易员合作。

Minsky 将 Jane Street 更广泛的角色描述为提供流动性：向一方买入，再卖给另一方。与销售交易员不同，自营交易员可能更专注于定价、策略、风险管理，以及判断交易是否有利可图。

客户可能希望完成一笔大额交易，而交易所在合适价格下难以满足。例如，一家调整投资组合的养老基金想买入的 ETF 数量，可能超过市场上有吸引力价格的可用挂单。

Minsky 解释说，做市商报价时知道部分交易对手可能掌握更好的信息。这种风险可能促使他们报出更小的数量或更宽的买卖价差。Casale 说，了解客户及其交易意图可能改变这种判断。

Minsky 说，对于流动性不足的 ETF，公司可以利用其底层证券进行定价，并通过这些证券管理产生的风险敞口。客户因此可以更简单地完成大额交易，而不必自行建立这项能力。

Casale 对客户仍然使用聊天工具、有时还用电话感到惊讶。询价请求例如会问某家公司愿意以什么价格交易 100 股 Apple 股票；客户可以向多家公司询价，再从报价中选择。

专门的报价平台提供结构化消息，但可能需要接入并支付费用。对于一年只交易几次的客户，通过已有系统发一条消息可能更加实际。

结构化表单也可能过于僵硬。客户可能还不知道交易数量，或不愿透露数量，但平台却要求填写该字段。聊天可以适应这些变化。

在大语言模型出现之前，有些格式规则的聊天消息就可以通过针对交易对手定制的规则进行解析。Casale 说，即使请求自动进入内部系统，销售交易员仍会关注聊天，并可能发送最终报价。

自动提取可以提高速度并减少手动输入错误。与重新输入所有细节相比，人工将解析结果与原消息进行核对可能更快，也可能更不容易出错。

不同客户对响应时间有不同期望。Casale 说，有的请求需要在 20 秒内进入内部系统，有的需要在 5 秒内，而另一些客户预计在一小时内收到报价即可。

速度要求可能源于真正有时效性的交易，也可能来自个人工作流程：有人只是希望完成一项请求后再开始下一项。Casale 与销售交易员合作，帮助他们询问并解答客户真正需要什么。

语言模型让解析较少结构化的消息成为可能，包括格式不统一或含有错字的消息。但 Casale 担心，其非确定性行为会让人难以知道输出何时会出错。

她假设准确率为 95%：如果人工复核者连续看到大量正确结果，就可能习惯性地批准，从而漏掉其余错误。一个大部分时候都出错的解析器则有另一种问题：交易员可能停止使用它。

Minsky 建议故意插入错误，测试复核者能否发现。Casale 说她提出过这个想法，但交易员并不热衷。她更愿意探索不完全依赖人工的检查方式，例如比较两个使用独立提示词得到的解析结果。

延迟也是一个限制。有些交易对手需要极快的响应，而模型完成任务的时间难以保证；另一些对手方则可能允许更多推理时间。加入对话历史可能改善上下文，但也可能让推理更慢。

Casale 说，他们基于模型的解析工作仍处于早期阶段：目前的重点是让提示词产生正确结果，即使模型需要一些时间，也暂不优先优化专用推理硬件。

她举了一个假设的失败案例：一条购买 Apple 股票的请求被解析成 Tesla，错误报价在没有上下文的情况下发出，双方都表示交易完成。交易对手可能会注意到不合理的报价，但错误也可能造成损失，或引发一场关于撤销交易的棘手对话。

Minsky 说，即使双方都表示成交，明显错误有时仍可纠正。Casale 指出，发现错误时价格可能已经变化，交易员必须权衡自身义务和客户关系。

一项防护措施是明确列出交易内容的确认信息：证券、数量、价格、结算日期及其他相关条款。即使最初解析错误，交易对手仍有另一次发现差异的机会。

Minsky 区分了这种确认信息与模型自由生成的输出：确定性系统可以展示实际用于定价的条款。Casale 与交易员合作，了解哪些信息能让确认内容没有歧义，特别是在复杂期权交易中。

在界面方面，Casale 区分了 Bonsai 和 Webs：前者是适合大型应用的 OCaml Web 框架，后者用于较轻量的数据视图和看板。临时视图不一定值得专门构建一套完整界面。

她把 Webs 描述为一个共享计算图，也是一种围绕表格数据构建界面的方式。Minsky 解释说，传入数据会逐步变化，系统只需重新计算依赖这些变化的部分，而不是重新运行所有计算。

Webs 起源于一个交易台的定价电子表格。Minsky 说，后来的系统扩大了同一基本思路的规模，并让计算能够协作：用户可以使用其他人已经贡献的数据和计算，在其基础上构建新视图。

Casale 说，随着用户贡献自己的视图，Webs 越来越有用。招聘团队已经开始使用它，集成的 AI 编程助手能帮助招聘人员创建视图并检查数据，而不必每次查询都请开发人员帮忙。

Minsky 补充说，Webs 视图可以立即部署到共享系统。Casale 将其与交易员快速生成的 AI HTML 页面作对比：交易员可以先用页面测试想法，再决定工具是否值得更持久地实现。

原型可以保持为简单的只读页面，也可以迁入 Webs 供其他人复用；如果它对交易很重要且需要专门界面，还可以发展成定制的 Bonsai 应用。投入多少生产工作取决于用途和后果。

Casale 说，如果一个只读看板只是检查客户是否停止交易，不会影响交易或监管报告，那么使用生成代码的风险相对较低。如果这些前提发生变化，她希望开发人员检查代码及其获取的数据。

Minsky 问，什么能防止未经阅读的生成代码做出意外行为。他认为浏览器沙箱和网络访问控制是有用的边界，同时指出完整程序或共享的 Webs 实例可能拥有不同权限。

Casale 不认为安全方面的权衡已经得到解决。AI 生成的代码越多，需要审查的内容也越多；审查者可能疲劳，尤其是在他们是第一个检查某段代码的开发者时。

Minsky 介绍了正在考虑的方案：用单独文档定义允许的行为，通过检查来执行这些限制，或使用独立模型会话对照规范审查变更。定义边界的那份简短文档仍然需要人工审阅。

Casale 说，她的销售团队有一个相关流程：构建应用的人先写明应用要做什么，然后由一个技能同时审查描述和应用，建议是否需要开发人员检查。它并非总是正确，也可能比较保守，但有助于对不断增加的工作进行初步分流。

Minsky 说，公司已开始招聘形式化方法方面的人才，这些方法可以证明程序的某些性质。他认为这在部分场景有用，但随着模型能力变化，确定合适的防护组合仍很困难。

Casale 比较了交易台开发者和前线部署工程师的工作。在 Jane Street，她和她支持的交易员都在同一家公司工作，因此更容易公开讨论成本、优先事项和取舍。

在 Palantir，她也非常关心客户的问题，但商业关系会影响对话：她的雇主希望销售软件，客户则希望完成自己的工作。她说，详细理解工作流程是两种岗位的共同点。

在 Palantir，前线部署工程师需要把可复用的发现反馈给中央产品团队。在 Jane Street，Casale 花更多时间服务自己的交易台，由多个团队提供不同组件，而非围绕一个核心产品工作。

她团队的聊天转报价工具说明了这一挑战。该工具服务销售交易员很长一段时间后，团队才意识到自营交易台也面临类似问题，并将服务推广给他们。

Casale 说，有些工程师擅长面向用户的工作，另一些则擅长将反复出现的需求转化为共享产品。她的团队已经开始围绕这些优势组织工作，同时让成员有机会学习更广泛的技能。

她认为，不同交易台有时会在意识到可以共享之前，分别构建相似工具。Minsky 提到了一个相关但不同的案例：Webs 由一个交易台先行构建，之后才实现通用化；持续改进本地工具的价值，也意味着更早推广它存在机会成本。

Minsky 指出，Palantir 为前线部署、产品工程等不同方向招聘人员，而 Jane Street 倾向于先招优秀通才，再决定他们适合哪里。Casale 说，这改变了她对招聘的看法。

Casale 比较了 Jane Street 多次形式相近的面试，与 Palantir 分别考察不同能力侧面的方式。前者希望对候选人的广泛软件开发能力建立信心；后者既想发现一个人特别擅长的领域，也要求其在其他方面具备足够能力。

Minsky 说，Jane Street 的一场面试仍能展现多种特质：编码习惯、沟通能力、倾听能力，以及对自身不确定性的准确判断。他回忆说，公司早期仅仅提出困难的智力题，并不总能找出日后表现出色的同事。

Casale 描述了 Palantir 的一种学习面试：先教候选人一门虚构的编程语言，再请他们用它解决问题。面试官会向候选人说明，目标是观察他们如何学习以及如何利用面试官的帮助。

其他面试可能要求候选人根据客户提交的错误报告调试现有程序，或拆解一个开放式的大型设计问题。每场都可能体现沟通和解决问题的能力，但主要围绕一项特定技能组织。

Casale 说，聚焦单项能力可以发现某个人在一件事上非常出色、但在其他方面只是够用的情况。她担心，宽泛的流程可能漏掉特别擅长与用户交谈、拆解用户问题的候选人。

Minsky 认为这种方法有两个风险：雇主选择的能力侧面可能不对应实际有用的岗位；而单次面试的测量存在噪声，可能漏掉有能力的人，也可能高估某项技能。Casale 同意这个流程有噪声。

招聘实验的反馈周期也很长。Casale 估计，改变流程后，从招聘、入职到观察新员工表现，可能要约一年半才能评估这个决定。

Minsky 担心通才流程可能低估专才。例如，性能工程师在面试中被要求优先编写简单代码，尽管深入思考性能是他们工作的核心；他们的习惯可能被误认为不听从指示。

Casale 说，有经验的候选人会带来职业生涯中养成的习惯，面试官必须分辨哪些习惯对 Jane Street 有用、哪些容易改变、哪些可能妨碍成功。背景差异和各地区候选人群体的不同，让标准化更加困难。

Minsky 将招聘比作在路灯下找丢失的钥匙，因为那里看得见。一种流程可能稳定地找到优秀人才，但未必是唯一方法；不断成长的组织必须持续检验如何扩大搜索范围。

Casale 说，她起初担心对有经验候选人与校园候选人的评估过于相似。她认为公司可能漏掉能以不同方式取得成功的人，同时她仍然重视让员工能够调换团队的通才文化。

Minsky 看重重组团队、让人员转向新问题的灵活性。共同的技术选择有助于此，不过即使同时支持 OCaml 和 Python 也需要投入，并可能影响工程师在项目间转换的难易程度。

公司也有很有价值的专才，包括硬件和前端工程师。Casale 喜欢前端工作，因为微小的改进就能立即影响用户；Minsky 认为，设计灵活且高性能的界面是一项具有挑战性的工作。

如果只能改变一件事，Casale 希望让每位候选人——尤其是有经验的应聘者——至少参加一场针对其背景中明显优势而选定的面试。性能专家可能得到一道性能问题，前首席技术官则可能得到高层管理或设计问题。

她不会用这种做法取代通才流程，也不会仅凭某项专长录用候选人。她的目标是给候选人机会展示广泛面试可能隐藏的能力，并在判断他们是否能够成功时纳入这些证据。