OpenAI FDE 面试：语义搜索带回家作业、60 分钟评审和允许用 AI 的编程轮

打开招聘人员的邮件，题目是：基于 Amazon 商品数据构建一个语义搜索系统，供 ChatGPT 调用。一位 OpenAI 前线部署工程师（FDE）候选人在 Aced 上回忆，自己拿到的正是这道题，有一周时间做出一个真正能跑起来的东西。

这只是一个人的经历，不是标准题目，介绍这套流程的各方说法也不完全一致。但 Aced（前身为 Exponent）的指南有一点值得记住：把带回家作业当成交付给真实客户的产品来做。

题目是一份小合同，不是一场考试

首先要弄清时限，因为各方说法不同。Aced 的指南说，大约有一周时间提交能运行的代码、一个运行中的应用和一段视频讲解。Gaijineer 和 The Forward Deployed 描述的则是大约五小时的作业：用 OpenAI 的 API 做一个真实可用的东西，再配一段视频。

连 Aced 自己都给了两个数字：它的 FDE 面试概览（下文 60 分钟评审的出处）说作业大约五小时，而专讲 OpenAI 的指南说大约一周。可能是流程变了，也可能各团队做法不同，所以两个数字都别当成定规。

因此，实际的建议是：直接问招聘人员截止时间和需要提交的内容，就像开工前先和客户确定范围一样。Final Round AI 的说法是，视频要像面对客户那样介绍这个应用。

评分标准比任何技术技巧都重要。拿到 Amazon 题目的那位候选人说，评分更看重能否讲清决策，并把决策和客户需求对应起来。

Final Round AI 说得更直接：讲不清自己做了什么的工程师，过不了这一关。评审跑不起来、看不明白的作品，再漂亮的检索技巧也救不回来。

从用户输入的内容出发，而不是从架构图出发

Perspective AI 建议从客户要完成的任务（job-to-be-done）出发，而不是从参考架构出发。假设你拿到了 Amazon 这道题。先别急着打开 notebook，写下 ChatGPT 用户可能输入的三条查询：“适合经常坐飞机的人、100 美元以内的降噪耳机”“送给喜欢恐龙的 5 岁孩子的礼物”“不会发黄的 iPhone 15 手机壳”。

这三条查询马上暴露出两类信号。语义部分（“经常坐飞机的人”“喜欢恐龙”）适合交给 embedding。硬性约束（“100 美元以内”“iPhone 15”）应该走元数据过滤，因为 embedding 不擅长比较数字。这正是之后你需要解释的那类决策。

接下来是商品怎么表示。一条商品记录通常有标题、品牌、类目、几行卖点，可能还有评论。最简单又站得住的做法是：每个商品一段短文本，价格和类目保留为过滤字段：

def product_to_text(p):
    # 每个商品一个文档；价格保持结构化，用于过滤
    lines = [p["title"], f"Brand: {p['brand']}", f"Category: {p['category']}"]
    lines += p.get("bullets", [])[:5]
    return "\n".join(lines)

def search(query, max_price=None, k=5):
    q_vec = embed(query)
    candidates = [p for p in products if max_price is None or p["price"] <= max_price]
    return top_k_by_cosine(q_vec, candidates, k)

分块策略就在这里起作用。如果把长描述切成多个块，就得把结果重新合并到商品层面。不合并的话，同一件商品可能占掉前五名中的三个位置。

加入评论能带来“整趟航班戴着耳朵都不疼”这样的日常表达，但也会带来噪声。加不加都可以，只要说得出理由。

最后是度量。假设你自己写了 30 条查询，每条事先标好哪些商品算正确答案。如果有 21 条查询的前五个结果里至少有一个正确商品，hit@5 就是 70%。这很适合作为评审的开场白：“第一版命中率 70%。加了价格过滤后提升到多少，原因是什么，如下。”

带进评审的是决策日志

Aced 描述的是一场 60 分钟的评审，把作品展示和深入的技术追问结合在一起。你先讲设计选择，再回答关于 RAG、微调与提示词之间的取舍、护栏和评测的追问。

Aced 的指南还提到，面试官会看设计是不是从客户的真实需求出发。

据 Aced 介绍，这一环节的常见问题是：为什么选这种方案，在哪些地方决定不走另一条路？最好的准备是一份决策日志，记下每个技术选择源自哪条用户需求。模板可以是这样：

决策	放弃的方案	理由（从用户需求角度）	何时改变
每个商品一个文档	把描述切成多个块	用户要的是一组不同的商品，不是文本段落	长描述稀释了 embedding 时
价格作为硬过滤条件	把价格写进 embedding 文本	“100 美元以内”是约束，不是提示	几乎不会
暂不加入评论	把评论追加到文档中	第一版保持简单，先度量再加	评测显示日常用语查询漏召回时

最后一列最有价值。被问到“如果客户有一千万件商品呢？”，你不必临场发挥，因为改变主意的条件早已写好。再针对 Aced 列出的话题补几行，比如为什么暂时不需要微调，哪条护栏能拦住价格不符的结果。

允许用 AI 的编程轮：考的是你怎么用工具

拿到 Amazon 题目的候选人只简单提到，连编程筛选都允许用 AI，没有细说规则。Aced 的指南说得更明确：可以使用 AI 工具，所以要共享屏幕，边写边讲思路。

所有候选人的工具都一样时，面试官唯一能观察到的就是你怎么思考。边写边说大概是这样：

“在让 AI 写任何东西之前，先确认一点：输入可能是空数组吗？现在让它先写一版……这一行用了 sort，所以是 n log n，对这道题可以接受。我再加一个重复元素的测试，这种情况很容易漏掉。”

这里的建议是：让面试官看到你认真阅读 AI 生成的代码，自己写测试，在运行前就发现 bug。把输出一贴、默默等结果，等于浪费了展示思考过程的机会。

让好作品落选的错误

一个常见错误是优化错了方向：花三天做一个精巧的 reranker，却没有 README，没有一行就能运行的命令，也没有评测集。按 Aced 的建议，把它当作交付给客户的产品来看，这样的作品还不如一个有测试、有度量的简单系统。

另一个错误是视频讲解一上来就放架构图。应该先展示用户的查询和结果，再讲背后的实现。永远不要用“因为教程就是这么做的”来回答“为什么”。决策日志的意义，就是让你永远不必这样说。

即使从没去 OpenAI 面试，这些准备也不会白费。一个带评测、决策日志和五分钟视频的搜索项目，适合放进任何 FDE 岗位的作品集。

写进简历时，用一行话写清数字和一个假设的客户，例如“为 200 件商品构建语义搜索，加入价格过滤后 hit@5 从 70% 提升到 X%”，而不只是罗列“RAG、embeddings”。

本周练习：用大约五小时重做 Amazon 这道题。这是 Gaijineer、The Forward Deployed 和 Aced 概览给出的基准，而不是那位候选人拿到的一周。然后请朋友扮演客户，对你连续追问整整 60 分钟。答不上来的问题，直接写进“何时改变”那一列。