Noyan Tokgozoglu：Optiver 如何构建快速且可衡量的 AI 平台

我是 Optiver AI 工程负责人 Noyan Tokgozoglu。我们是一家做市商，使用自有资金促进交易，通过数据和模型作出决策。公司每天完成超过 1000 万笔交易，为超过 100 万种金融工具定价，并在全球运营中每日处理 PB 级数据。

在传统科技企业，一项产品变更可能需要数周才能积累用户参与数据，还需要数个季度才能体现营收影响。在 Optiver，面向交易员或量化研究员的变更可能数小时内就反映到盈亏上，尽管一些金融工具和决策的周期更长。

快速反馈有两面。错过市场机会可能代价高昂，因此我们需要快速行动并有效衡量。这种环境塑造了我们构建的 AI 平台：速度重要，但同样重要的是知道新模型或技术是否真正创造价值。

平台原则包括快速行动、模块化和在每一层进行衡量。模型、工具和智能体模式变化很快，我们需要评估有用的新发展，并在不重建整个技术栈的情况下接入。外部基准不够，因为我们的内部数据和使用场景分布不同。

交易员能力强、自主性高，因此平台应提供自助服务，同时设置合理默认值。我们的 AI 工程师也会与交易团队坐在一起，学习其工作流程并帮助直接应用 AI。前置部署工作中的经验随后会回到共享平台。

安全同样重要，因为智能体在我们的技术栈中错误行动可能造成严重后果。公司每个人都以某种方式使用 AI。基础设施和 GPU 部署在本地；第三方模型推理是一个例外，并通过零数据保留等协议进行约束。

平台通过推理网关接入第三方和自托管模型。网关负责请求路由、成本衡量、预算和供应商切换。如果一家供应商不可用，另一家可以帮助维持服务；停机直接影响业务，因此这一点很重要。

上层是拥有已注册技能、插件和工具的智能体，以及团队知识和记忆。智能体网关提供共享层，让人与智能体沟通、编排工作，并管理身份。不同团队可以将自己的上下文带入系统。

用户界面与平台本身同样重要。我们构建了会话网页界面、供团队配置和共享使用方式的智能体工作台，以及全公司可用的个人助手。如果用户不会使用或不愿使用，平台价值就很有限。

我们的一个目标是在新的前沿模型公开当天，将它用于生产工作流——前提是它确实有用。我们与交易团队收集内部黄金测试集，开展基准测试并分享结果和建议，让用户判断模型对自身工作是否有价值。

新模型发布还需要网关支持、接口、成本管理，有时也需要更新运行框架。上线并非结束：全球化公司需要全天候支持、不同地区的轮值，以及关于测试结果、表现和使用方式的持续沟通。

我们希望在模型和运行框架之间保有选择，包括在隔离环境中运行本地工作负载。第三方供应商与自托管模型都通过推理网关接入。我们记录模型交互，并将其送入评估系统。

元运行框架层让团队能够跨不同框架配置使用体验，并连接自己的知识库。我们也会随着时间从运行轨迹中提取更多知识。团队可以在平台上部署和管理智能体，也可以通过网页门户、IDE 等界面访问。

AI 使用量和支出大幅增加，尤其是在重要模型发布前后。我展示的图只是示意，没有具体支出数字。我们相信更多使用能够创造价值，但希望把钱花得更明智，提高每个 token 的回报。

一个问题是默认上下文过多。在新会话中，有些配置在用户开始工作前就加载约 20 万个或更多 token，因为团队不断加入 MCP 工具和背景信息。完全自助但不关注默认设置，可能变得非常昂贵。

我们增加了 MCP 工具搜索，让智能体选择通过命令行包装器使用工具，并检查缓存失效和缓存时长。我们还与团队合作优化运行框架，例如在合适时将庞大系统提示中的内容移入知识库。

让成本可见也有帮助。团队可以自行设置提醒和限额，获得信息和自主权后，许多团队会选择合理的边界。我们也在特定任务中使用本地部署的开放模型，但不假定它们适合所有场景。

我们正在探索模型路由，以及让更强的模型制定计划、由较小模型执行部分任务的分工。有效的知识检索也能减少不必要的上下文。目标不只是减少 token，而是让投入创造更多价值。

为了贴合用户实际工作方式，我们观察到人们已经在使用定制运行框架和临时网页界面。于是我们构建了共享网页门户，支持会话、聊天和产物，既适配自己的基础设施，也能按照自己的节奏迭代。

现在交易员也会为自己的工作流贡献代码，门户增加了协作文档编辑等功能。我们正朝共享房间发展，让用户在同一处与自己的智能体及其他已部署智能体协作，并通过 Slack 客户端在移动中访问。

在问答环节，我表示我们的知识库方案仍不完美。Markdown 和向量搜索各有优势和局限，因此我们采用混合方法，也希望探索图数据库等选择。记忆和检索仍需要继续研究。

为什么自行构建，而不是完全依赖供应商方案？本地部署要求让一些产品难以使用，而过度依赖单一供应商可能让我们的速度受制于对方。我并不认为这种做法适合所有人；我们的特殊条件和工程能力使它对我们可行。

评估还有一个难题：工具所处的世界可能已与智能体最初运行时不同。交易回测数据库通常可以按时间点查询；要重建 Slack 或其他服务的历史状态，则可能困难得多。

我们尝试评估每次工具调用能否按原时间点回放，以及对此有多大信心，并在重新评估时使用 MCP 工具代理。结果仍不完美；重建世界状态是一个尚未完全解决的问题。

当团队组合智能体时，简单合并所有能力可能带来复杂性和技术债。对于小改动，我们可以更新智能体版本；对于更广泛的工作，我们越来越倾向于让智能体分别承担可衡量的明确任务，再通过共享网关通信。

这会变成一个编排问题，但能够保留更清晰的生命周期管理和评估。一个臃肿的大型智能体可能某项能力变好、另一项变差，使整个系统难以调整。