据报道的 OpenAI 系统设计面试题，涵盖企业级 RAG、GPU 视频流水线、支付、国际象棋和 Slack 等，并说明每一轮考察的重点。
作者：The Forward Deployed 编辑团队已审核
本题库涵盖据报道 OpenAI 软件、机器学习和基础设施岗位的系统设计题池。前沿部署工程师的面试流程有其独特的形式，详见 OpenAI FDE 面试指南。当你的面试流程包含系统设计环节，或者你在权衡 OpenAI 的工程岗位与 FDE 岗位时，请使用本页面。下面每道题都链接到完整的分析与解答。在打开题目之前，请先口头作答。
这些题目分为两大类。第一类是 AI 产品：检索、流式传输、GPU 调度和训练数据。第二类是经典的分布式系统题池，面试官会针对一两个组件考察深度。请按照 AI 系统设计案例 中的方法，在计时条件下口头作答每道题。
AI 产品与机器学习系统题
设计一个基于公司内部文档的企业级助手
一家公司上传其内部 wiki、工单和共享网盘。员工提问并获得带来源引用的答案。请为多租户场景设计整个系统，并对每份文档实施权限控制。
这一轮会深入考察检索：分块、稠密检索与稀疏检索的对比、重排序阶段，以及如何让每个答案始终关联其来源。权限是陷阱所在。用户绝不能看到自己无权打开的文档中的段落，因此要在检索时强制执行访问控制，并在生成之前进行过滤。当候选人只按单轮对话设计而忽略对话历史，或者没有提供评测方案时，也会失分。
请结合 RAG 与向量搜索、评测 和 安全与合规 进行准备。
说明你会如何训练和使用用于搜索的文本嵌入模型
这是一轮口头问答。有搜索背景的面试官会询问嵌入模型是如何学习的，然后沿着从查询到排序结果的检索流程追问。
要能凭记忆写出对比损失并解释每一项。追问围绕负样本展开。为什么批内负样本是免费的？更大的批次为什么有帮助？什么时候因为批内负样本太简单而需要挖掘难负样本？然后比较逐点、逐对和逐列表重排序。在问题到来之前就要准备好逐列表方法的权衡；据报道，在这里回答含糊是失掉这一轮的常见原因。
设计一个所有历史记录都保留在浏览器中的聊天界面
用户登录、发送消息，并逐 token 观察答案流式输出。服务器不存储任何聊天历史。刷新页面即开始新对话。
这是一轮前端与全栈面试。面试官希望你在服务端推送事件（SSE）和 WebSocket 之间做出有理有据的选择，并给出一条流中途断开的处理方案。展示你如何渲染新 token 而不重新渲染整个对话记录。然后涵盖基于 token 的登录、浏览器存储限制，以及模型 API 失败时的重试。成本与延迟涵盖了流式传输和首 token 时间。
设计一个可调参数并保存预设的模型游乐场
用户输入提示词，调整 temperature 等设置，并看到补全内容流式输出。他们可以把提示词及其设置保存为预设，之后再次运行。你是唯一的开发者，所以每个技术决策都由你来辩护。
先讲产品解决的问题。然后是数据模型：用户、预设，以及每个预设冻结的设置。其余部分是浏览器、后端和模型 API 之间的数据流，画在共享白板上。展示状态在 UI 中的存放位置，以及用户在两个标签页中编辑同一预设时会发生什么。提示词与结构化输出帮助你论证哪些设置应属于预设。
为超大规模受众设计一个实时 AI 功能
先选定传输方式，然后为它辩护。题目要求大规模流式回答，包括准入控制、排队、过载行为，以及围绕模型调用的成本限制。
把每个后端决策与用户看到的内容联系起来。当你丢弃负载时，屏幕上显示什么？当流失败时，客户端如何恢复，丢失的 token 由谁买单？画出从提交到准入、模型执行、流式传输、取消和错误恢复的请求生命周期。然后在十倍流量下重新设计。准备一个包含故障的生产故事、调试路径以及你做出的权衡。将成本与延迟与可观测性搭配使用。
在有限的 GPU 资源池上设计一个视频生成服务
客户端提交一个提示词，几分钟后得到一个视频。GPU 稀缺，数量会变化，而且工作节点可能在任务中途消失。
API 必须是异步的：立即返回一个持久化的任务 ID，并暴露状态、进度和取消。这一轮的大部分内容是调度与故障处理。租约和心跳会把死掉工作节点的任务送回队列。检查点限制了抢占所摧毁的工作量。准入控制在队列很长时给出诚实的预计完成时间。大声做容量计算，因为每秒任务数乘以每个任务的分钟数就得出峰值所需的工作节点数。元数据部分很小。GPU 容量占主导，所以把时间花在那里。参见部署和成本与延迟。
从一个巨大的无标注语料库中挖掘新的、有用的示例
一道规格说明很简略的 ML 设计题。在超大规模无标注数据集中发现新颖信息，或找出所有包含给定物体的图像。其中一个变体使用医疗数据，要求找出高信号量的训练样本。
规格简略是有意为之。你的首要任务是用可度量的方式定义“新颖”和“有用”。然后围绕这个定义构建过滤和检索流水线：嵌入向量、去重，以及一个用于检查精确率的小型标注样本。这个样本的做法与评测中的黄金集（golden set）如出一辙。
分布式系统类问题
题库的其余部分都是熟悉的领域。面试官通常会选择一两个组件深入追问。一个给每个模块平均分配时间的模板会耗尽时间。
为一家咖啡店设计支付系统，或题目实际所说的任何场景
标题写的是支付。但问题往往会收窄到某个具体场景：店内点单、在线结账，或从商户到支付服务商的链路。动笔之前先读两遍题目。一个常见的失误是针对更窄的问题交出一份精致但泛泛的支付设计。
无论落在哪个场景，被考察的核心都一样。每个请求都要有幂等键，确保重试不会重复扣款。一个从授权（authorized）到捕获（captured）再到结算（settled）的状态机，预授权会过期。一个复式记账账本。可安全重放的 Webhook 处理器，因为服务商也会重试。咖啡店版本还要加上下单时的预授权、可能因小费而与预授权金额不同的最终扣款，以及每夜结算批处理。指出让批处理查询变廉价的索引，并给批处理任务分配自己的幂等令牌。涉及钱的部分保持强一致性。写出带键和索引的真实表结构；含糊的存储方案会丢分。
设计一个在线国际象棋平台
按等级匹配对手，通过 WebSocket 实时传输走子，以及一个由服务器掌控的时钟。屏幕上的计时器只是显示。
时钟是最有意思的部分。存储上一步的时间戳和每位玩家的剩余时间，其余按需计算；把每一秒都写进数据库是经典的错误。处理重连、认输、求和，以及用走子序号让每步棋幂等，从而应对重复提交的走子。匹配系统会随玩家等待时间加长而放宽等级窗口。
设计一个基于浏览器的云端 IDE
用户可以编辑文件、运行命令并实时查看终端输出，本地无需安装任何东西。其中一个轮换题目会把浏览器换成通过 SSH 访问一整批主机。
首要的是隔离：一个用户永远无法访问另一个用户的文件或进程。其次是沙箱生命周期：通过预热池实现快速启动、空闲时关闭，以及决定哪些内容在重启后保留。终端输出必须流式传输得足够快，让打字感觉像在本地一样。尽早询问会话是持续几分钟还是几小时，因为答案会改变生命周期设计。
设计一个多租户 CI/CD 系统
一次 git push 触发仓库中定义的工作流。任务按顺序在容器中运行，每个任务必须恰好执行一次，即使发生崩溃也是如此。用户可以实时查看状态和日志。
恰好一次是整场面试的核心。坦率地说明队列提供的是至少一次投递。通过租约、 fencing token 和幂等的任务状态转换，最终效果才成为恰好一次。然后展示系统如何检测崩溃的 worker 并重新分配其任务而不产生第二次运行。租户隔离涵盖计算资源、密钥和公平调度，确保一个繁忙的租户不会饿死其他租户。
设计一个 Webhook 投递系统
客户为事件类型注册回调 URL。系统以极高的吞吐量将每个事件投递到正确的 URL，且每个事件必须至少到达一次。
先设计 API 和数据模型。然后是重试路径：带抖动的指数退避、死信队列，以及客户可查询的投递日志。隔离是需要追问的关键点。一个客户的缓慢或失效的端点不能拖慢其他所有投递，因此要对队列进行分区或限制每个端点的并发数。对每个载荷进行签名，让接收方可以验证，并包含事件 ID 以便他们去重。
设计 Slack
私信和频道、每个用户多台设备、通知，以及工作区隔离。先从私信开始，再逐步扩展到频道。
先写入消息和每个接收者的收件箱条目，然后发布以实现实时投递。持久化写入保证投递；发布/订阅层提供速度。大型频道会改变扇出方式。超过一定规模后，每个频道只发布一次，由各网关投递给其本地成员。在被问到之前主动覆盖多设备场景，使用每设备游标在重连时找出缺口。准备好对比 Redis pub/sub 与 Kafka 作为传输层，并解释为什么用户数据和消息数据放在不同的服务中。
设计一个附近地点搜索
在高读取流量和严格的延迟预算下，查找用户附近的兴趣点，覆盖全球任意位置。变体可能要求精确的 K 近邻结果、分片索引，或对商家信息的快速更新。地理索引是核心。精确解释 geohash 或四叉树，对比两者，并处理最近结果位于相邻单元格的情况。然后对索引进行分片并缓存热点区域。
设计一个分布式填字游戏求解器
给定一个包含约一百个空格的大型网格和一本约一百万词的词典，找到一个有效填充。面试官并不期待巧妙的算法。先快速说明单台机器无法搜索整个空间。然后设计一个作业系统：将搜索树拆分为任务，用约束检查尽早剪掉死分支，把工作从卡住的 worker 上转移走，并在任一 worker 找到解后让所有 worker 停止。
设计 Google 日历
用户创建活动，并在多个设备上按日、周、月或年查看。两个难点是每种视图的快速范围查询和近实时同步。重复活动是深度考察点：存储规则，读取时展开，并将对单次活动的编辑视为例外。
设计一个 URL 短链接服务
这是题库的热身题。涵盖密钥生成，包括计数器加 base62 编码，或带冲突处理的哈希。然后是读多写少的重定向路径和热门链接缓存。深度来自全球读取和滥用防控。
贯穿整个题库的通用要点
上面几乎每道题都考察两个习惯。在选择组件之前，大声做容量估算。写出具体的 schema 和 API，包括键、索引和请求格式。AI 题目还增加第三个习惯：说明你如何知道系统有效，并给出一个真正可运行的评测。想了解 FDE 流程如何在有真实客户参与的情况下考察这些技能，请回到 OpenAI FDE 面试指南。
常见问题
OpenAI 会问哪些系统设计问题？
据反馈的题目涵盖 AI 产品和经典分布式系统。AI 方面包括基于检索、embedding 和重排序设计的企业文档助手、流式聊天界面、模型 playground，以及稀缺 GPU 上的视频生成流水线。经典方面包括带冻结和结算的支付、在线国际象棋、云 IDE、多租户 CI/CD、webhook 投递、Slack 和附近地点搜索。题库会轮换，请与招聘人员确认轮次形式。
OpenAI 的 FDE 流程会使用这些题目吗？
FDE 流程有自己的形式：基于 OpenAI API 的带回家作业、技术深挖，以及开放的客户方案设计轮。本页的题目据反馈来自工程系统设计轮，但它们同样能锻炼 FDE 设计轮所考察的技能。参见 OpenAI FDE 面试指南。
我应该如何练习 OpenAI 的系统设计题目？
选一道题，设个计时器，然后大声作答。先做容量估算，再写数据结构和 API，然后深入题目中最难的那个组件。AI System Design Cases 上的答题框架和 AI 面试官同样适用于这些题目。