FDE 系统设计：在客户约束下设计 AI 系统

FDE 系统设计不是教科书式的分布式系统。你要在客户的 VPC、数据驻留规则、SSO、严格的延迟或成本预算以及评测计划的约束下进行设计。下面是一个在受监管 VPC 中部署 RAG 的实战案例。

作者：LUKAS HOFFMANN · FDEINTERVIEWS 编辑部 · 更新于 2026 年 6 月 21 日 · 阅读时长 11 分钟

练习这些内容：系统设计问题 · RAG 与 Agent 设计问题 · ML 基础设施问题 · 必知的 FDE 问题

FDE 系统设计要求你设计一个能在某个特定客户环境中运行的 AI 系统，而不是一个假设的互联网规模服务。决定你设计的约束包括：部署边界（通常是私有 VPC 或气隙隔离网络）、数据驻留与合规规则、身份与SSO、客户设定的固定延迟或成本预算，以及一个在系统上线前证明其有效的评测计划。教科书式的分布式系统面试看重分片和吞吐量，而这一轮看重的是契合度：一个能通过客户安全审查、在其预算内运行、并且可被衡量的设计。下面先讲有哪些不同之处，随后给出一个部署在受监管 VPC 中的 RAG 系统的实战案例。

它与教科书式面试有何不同

标准的系统设计面试是一道扩展性练习。为十亿条链接设计一个短链接服务，为十亿用户设计一个信息流，为全球 API 设计一个限流器。隐含的目标是吞吐量，而约束是你自己编造出来以证明自己架构合理性的。

FDE 面试则恰恰相反。约束由客户提供，而且很少与规模有关。一家银行部署内部助手可能只有几千个用户，负载微不足道。难点在别处：数据不能离开他们的网络，每次查询都必须遵守其身份提供商已经实施的权限模型，法务团队需要知道每个字节存储在哪里，而安全审查一句话就能否掉你的设计。你的工作就是从这些壁垒出发进行反向设计。

几乎每一场 FDE 设计面试都会出现五类约束。在画出任何一个框之前，先学会逐一询问。

这就是为什么对于 FDE 来说，系统设计和 RAG 与 Agent 设计这两个类别重叠得如此之多。架构只是答案的一半，另一半是部署和验证。

实战案例：受监管 VPC 中的 RAG 助手

以下是客户会这样表述的需求：“我们是一家受监管的金融服务公司。我们想要一个内部助手，让分析师可以基于我们的研究文档和申报文件进行提问。我们的安全团队不允许任何数据离开我们的 AWS VPC，而且回答必须遵守谁有权查看哪些文档的规定。我们需要在几秒钟内得到答案，并且我们的合规团队需要先签字批准，才能让系统接触真实用户。”

克制住直接做架构设计的冲动。先确认约束条件，因为每一条约束都会排除一些选项。

• 边界。 这是一个私有 VPC，不是物理隔离的，所以你可以通过代理进行受控的出站访问。这意味着如果客户的安全团队批准数据处理协议，托管模型 API 是可行的，但你应该把设计做成：如果他们说不行，本地部署模型可以作为即插即用的备选方案。永远要准备好这个备选方案。
• 数据驻留。 所有内容都留在他们的 AWS 账户和区域内。所以向量数据库、文档存储、嵌入服务和日志都位于 VPC 内部。任何数据都不经过第三方 SaaS。
• 身份。 他们使用 Okta。回答必须遵守现有的文档权限，所以访问控制不能是最后才补上的事后考虑。
• 预算。 端到端几秒钟。这是你的硬性延迟预算，它限制了你能够承受多少次检索和重排序的轮次。
• 评估。 合规团队必须签字批准，这意味着一份有文档记录的评估计划是交付物的一部分，而不是可有可无的东西。

架构

向面试官展示请求路径，并将每一跳与一条约束关联起来。

查询通过 Okta SSO 背后的应用 API 进入。用户的身份和组成员信息随请求一起传递，因为检索必须具备访问感知能力。检索器查询向量数据库，但在候选内容到达模型之前，先按访问控制列表进行过滤。这是候选人最容易遗漏的部分：如果你在检索之后才过滤，或者更糟，依赖提示词告诉模型不要泄露受限内容，那你就构建了一个数据泄露漏洞。过滤应该放在检索层，由 Okta 提供的同一套组声明来强制执行。

检索到的文本块经过重排序器以提升精确率，然后送入模型，模型生成带有引用来源文档的答案。引用在这里有双重重要性：分析师需要核实，合规团队需要审计追踪。每个请求和响应都写入 VPC 内部的审计日志。

花好延迟预算

端到端只有几秒钟的时间，把算术大声算出来。对热向量索引的检索很快，大约几十毫秒。用交叉编码器重排器对几十个候选做重排会占一小段。生成占大头，取决于模型和答案长度。如果预算紧张，可调的杠杆有：重排更少的候选、使用更小或蒸馏后的模型，或者流式输出前几个 token，这样即使总时间不变，感知延迟也会下降。能说出这些杠杆以及你会按什么顺序拉动它们，就是资深水平的信号。

模型决策

这是面试官在等待的分岔点。如果安全团队批准在数据处理协议下使用经 VPC 路由的托管模型 API，你就能获得接近零运维的前沿模型质量，那就应该选它。如果他们拒绝，你就在 VPC 内的 GPU 上自托管一个开放权重模型，用 vLLM 之类的工具来提供吞吐量，并诚实地估算硬件规模。直白地说出权衡：自托管用模型质量和运维便利换取完全控制权和更容易的合规故事。错误的答案是默默选一个。正确的答案是做出决定，并说出会改变决定的条件。

评测计划不是可选项

受监管的客户不会让一个影响分析师的系统凭感觉上线。为评测计划预留真实的时间，因为在这一轮中，正是它让你通过合规审查。

构建一个由客户自己的领域专家标注、包含已知正确答案的代表性问题黄金集。分别衡量检索质量（是否召回了正确的文档）和答案质量（生成的答案是否忠实且正确），因为它们失败的原因不同，修复方法也不同。设定发布前必须达到的门控指标，并在每次变更时运行自动化评测套件，以便捕捉回归。对于受监管的客户，还要增加一项针对他们最担心的失败的检查：系统是否曾经向用户展示过其无权查看的文档。这个数字应该是零，而且你要能证明这一点。让评测可复现的 ML 基础设施工作，正是把演示变成部署的关键。

如何练习这一轮

拿任何一个 RAG 或 Agent 设计，重新运行五次，每次附加一个不同的客户约束：物理隔离、亚秒级延迟、极小的 GPU 预算、跨两个区域的严格数据驻留、必须集成的现有身份提供商。架构每次都应该改变，而能够解释为什么正是这项技能。先从系统设计和 RAG 与 Agent 题库开始，然后用必知题集检验你的直觉。

一句话版本

从客户的实际限制出发倒推设计，而不是从一块干净的白板出发正向设计。先问清楚数据存在哪里、谁能看到它、预算是多少、以及你将如何证明系统有效，然后构建一个能同时满足这四点的最小系统。这才是企业安全团队真正会批准的设计。

把它转化为面试题。思考这背后的真实问题和概念：

常见问题

常规的系统设计循环优化的是规模：数据库分片、每秒处理一百万次写入、设计全球信息流。而 FDE 版本优化的是单个客户的现实情况。难点在于部署环境（私有 VPC 或物理隔离网络）、数据驻留与合规、身份认证与 SSO、客户设定的固定延迟或成本预算，以及证明系统有效的评测方案。契合度比规模更重要。

你需要的是可用的熟练度，而不是深度。你应该能够推理如何在客户的 VPC 内部署、为什么物理隔离网络无法调用托管模型 API、SSO 和 SCIM 能带来什么，以及一个托管向量数据库大致的运行成本。你不需要背诵 etcd 的内部实现。关键信号是你的设计能否经受住真实企业环境的考验。

考察的是你在画架构图之前是否先询问约束条件。先确认数据存在哪里、谁能看到它、延迟预算是多少、成功如何衡量，然后再做设计的候选人，会让人觉得他真正在客户现场部署过软件。而直接跳到架构设计的候选人，则让人觉得他只做过从零开始的新项目。

假设没有对外互联网连接。这就排除了调用托管模型 API 的可能，所以你应该提出一个在网络内部运行的模型（客户 GPU 上的开源权重模型，用 vLLM 之类的工具提供服务）、一个自托管的向量数据库，以及一个同样在本地运行的评测框架。然后说出权衡：你用前沿模型的质量和零运维的便利换取了控制力和合规性，并且要诚实地估算硬件规模。

讨论 (5)

让我豁然开朗的一点是：在常规的设计面试中，延迟是你尽量去最小化的东西。而在 FDE 面试中，延迟是客户交给你的一个数字，你必须在这个数字之下运行。“工作时间内的回答必须在两秒内返回”这一条，就完全改变了你是否用得起重排序器或第二轮检索。要把这个预算当作硬性输入，而不是以后再优化的东西。

没错。预算是一个设计约束，而高手的做法是把算术当场算出来。如果你有端到端两秒的预算，检索加重排序会占掉一部分，生成占掉剩下的部分，这样你就能论证流式输出首 token 是否可以接受。这道算术题就是他们想要的答案。

提问：在设计面试中，我到底应该花多少篇幅谈评测？我总觉得我应该是在画架构图，而评测部分感觉像是事后才想起来的东西。

这不是事后补充，而是区分资深候选人的关键部分。没有评测计划的设计只是一个演示。请为它预留真正的时间：黄金数据集是什么，哪些指标决定发布门槛，谁来标注数据，如何发现回归问题。在受监管的客户那里，评测计划也是通过合规审查的关键。

有一个值得点名的陷阱：你提出了一个漂亮的托管方案，面试官却回答“他们的安全团队绝不会允许数据离开 VPC。”如果没有准备好备选方案，这一轮就会卡在那里。请提前准备好设计的本地部署版本，因为受监管的客户一定会把你逼到这一步。