第 06 章 系统设计题

本章导读：系统设计面试考的不是背架构图，而是能否在约束下做出一致的设计决策。本章用统一框架拆解 8 道大模型相关系统设计题，从需求澄清到容量估算、架构、模块、评估、取舍逐层展开。

所有每秒查询数（Queries Per Second, QPS）、词元（token）速率、图形处理器（Graphics Processing Unit, GPU）数与存储均为量级估算，假设写在每道题内。

实际面试应先与面试官对齐假设，再给出计算过程，最后落到架构与取舍。

核心要点：

• 先澄清功能与非功能需求，再动笔画架构；没有约束的架构图没有意义。
• 容量估算要写出公式、假设与单位，先算平均值，再用峰值系数放大。
• 大模型系统的瓶颈通常在上游模型配额、GPU 显存与解码吞吐，而不是 Web 层。
• 先做同步主链路，再把计费、评测、日志等非关键路径异步化。
• 多租户系统必须同时考虑数据隔离、配额隔离与故障隔离。
• 评估体系要与架构同时设计，离线黄金集、在线指标与人工复核缺一不可。
• 每个设计都要主动说出取舍与失效模式，并给出降级与回滚方案。

容量估算通用公式

\[QPS_{avg} = \frac{DAU \times F}{86400}, \qquad QPS_{peak} = k \times QPS_{avg}\]

\[T_{day} = QPS_{avg} \times 86400 \times (T_{in}+T_{out})\]

\[N_{GPU} = \left\lceil \frac{QPS_{peak}\times T_{out}}{R_{eff}} \right\rceil\]

其中 \(DAU\) 为日活用户数（Daily Active Users, DAU），\(F\) 为每人每日请求次数，\(k\) 为峰值系数（通常 3 至 10），\(T_{in}\) 与 \(T_{out}\) 为单次输入与输出 token 数，\(R_{eff}\) 为单机有效输出 token 速率，\(\lceil \cdot \rceil\) 为向上取整。存储按“原始数据 + 索引膨胀 1.5 至 2 倍 + 副本与日志”累加。

统一答题框架

步骤	要回答的问题	常见失分点
需求与容量	谁用、规模多大、峰值多少、GPU 与存储多少	只给结论，不给假设与计算
架构与模块	请求如何流动，最难的三到五个模块怎么实现	组件堆砌，没有数据流与深度
数据与评估	数据如何流转，离线与在线指标是什么	只谈模型，不谈评估
取舍与风险	为什么这样选，故障与降级怎么办	声称没有缺点

题目 1：企业级文档问答系统（万级文档、权限隔离）

1.1 需求澄清

类别	需求	量化目标
功能	自然语言问答、多轮追问、答案带原文引用	引用可定位到章节，支持 5 轮
功能	按部门/项目/密级隔离，支持增量更新与删除	越权召回为 0，新文档 10 分钟内可检索
非功能	2 万员工，日活 2,000，人均 5 问	1 万请求/日，可用性 99.9%
非功能	端到端 P95 8 秒、首 token 2 秒、数据不出域	审计日志保留 180 天

明确不做：不执行写操作；无依据时拒答；扫描件低置信度必须提示。

1.2 容量估算

假设：1 万份文档 × 30 页 × 500 token；分块 500、重叠 50；每次输入 8,000、输出 600 token；峰值系数 5。

• 文档 \(1.5\times10^8\) token，分块 \(1.5\times10^8/450\approx3.3\times10^5\)；平均 QPS \(10^4/86400\approx0.116\)，峰值 0.58，并发约 5，按 20 预留突发。
• 日 token：输入 \(8\times10^7\)、输出 \(6\times10^6\)；峰值预填充 4,640 token/s、解码 348 token/s。
• GPU：70B 单机有效解码 800 token/s、预填充 2 万 token/s，1 台够用，按高可用部署 2 台 8 卡机、16 张 GPU。
• 存储：向量 1.4 GB、分层可导航小世界图（Hierarchical Navigable Small World, HNSW）索引约 2 GB、原文 225 MB、原始文件 20 GB，含版本与日志 200 GB 以内；走 API 约 250 元/日。

1.3 高层架构

员工 → 单点登录（Single Sign-On, SSO）/网关 → 问答服务 → 查询改写 → 混合检索（BM25 + 向量）
     → 权限预过滤 → 重排 → 提示词 → 大模型（流式）→ 引用校验 → 返回
文档源 → 连接器 → 解析/光学字符识别（Optical Character Recognition, OCR）→ 分块 → 向量化 → 索引；访问控制列表（Access Control List, ACL）与元数据入库
旁路：语义缓存、评测集、反馈队列、审计

1.4 关键模块

模块	设计要点
解析分块	保留标题与表格结构，按语义边界切分，表格单独成块
权限	ACL 写入 chunk 元数据，检索前过滤，缓存键含权限摘要
检索重排	BM25 + 向量各取 50，RRF 融合，Cross-Encoder 精排取 6
生成与索引	强制逐条引用，无支撑则拒答；增量索引用变更数据捕获（Change Data Capture, CDC）+ 墓碑

1.5 数据与评估

• 黄金集 300 条、挑战集 100 条，覆盖跨文档、表格、冲突信息与拒答。
• 离线看 Recall@10、MRR、忠实度、引用精确率；在线看采纳率、负反馈、零结果率、越权事件；每次变更跑全量回归。

1.6 取舍与风险

• 先过滤后检索：后过滤简单但可能把敏感片段送进模型，选择检索前过滤并接受索引复杂度。
• 主要风险：OCR 错误、权限同步延迟、文档过期、文档内提示词注入；用置信度提示、定时同步、更新时间展示与内容隔离缓解。

1.7 面试官可能追问

• 表格和扫描件怎么处理？版面分析保留单元格关系；扫描件走 OCR，低置信度提示“识别可能有误”。
• 如何证明权限隔离有效？跨部门负样本自动化测试，记录每次 ACL 决策，越权即阻断并告警。

题目 2：高并发大模型 API 网关（多模型路由、限流、计费）

2.1 需求澄清

类别	需求	量化目标
功能	兼容主流 API、流式输出、多供应商路由与回退	单供应商故障不影响整体
功能	租户级每分钟请求数（RPM）/每分钟 token 数（TPM）/并发限流、用量计量与账单	账单误差低于 0.1%
非功能	峰值 1,000 QPS，平均 300 QPS	网关自身 P99 开销低于 50 ms
非功能	可用性 99.95%，密钥托管与审计	多可用区部署，密钥不落日志

2.2 容量估算

假设：70% 短请求输入 1,000、输出 300 token，30% 长请求输入 8,000、输出 1,000 token；峰值 1,000 QPS。

• 平均输入 \(0.7\times1000+0.3\times8000=3,100\)，平均输出 \(0.7\times300+0.3\times1000=510\) token。
• 峰值 token：预填充 \(1000\times3100=3.1\times10^6\) token/s；解码 \(1000\times510=5.1\times10^5\) token/s。
• 若全部自部署，70B 单机有效解码 2,000 token/s，需 255 台 8 卡机、约 2,040 张 GPU；因此采用多供应商 + 部分自部署，网关只做路由与配额。
• 网关 Pod 单机 200 QPS，1,000 QPS 需 5 个，按 2 倍冗余 10 至 12 个；Redis 限流约 3,000 次/秒，3 分片；Kafka 1,000 事件/秒。
• 存储：日志 10 KB/请求约 864 GB/日，采样 10% 后 86 GB/日、30 天 2.6 TB；账单 8,640 万条/日、一年约 6 TB；出口带宽约 80 Mbps。

2.3 高层架构

客户端 → Web 应用防火墙（Web Application Firewall, WAF）/CDN → 负载均衡 → 网关集群
  ├─ 认证与租户解析 → 限流/配额（Redis + 本地桶）
  ├─ 路由与熔断 → 供应商适配器 → 上游模型
  └─ 流式转发（Server-Sent Events, SSE）→ 客户端；用量事件 → Kafka → 计费 → ClickHouse
配置中心下发路由、价格表与灰度比例；Prometheus/Grafana 监控

2.4 关键模块

模块	设计要点
认证限流	API Key 哈希存储；令牌桶控 RPM、滑动窗口控 TPM、信号量控并发，Redis Lua 保证原子性
路由熔断	按健康度、延迟、价格、租户等级加权；连续失败熔断，主备与降级模型
协议适配	统一内部请求模型，适配不同供应商字段、错误码与流式格式
计费对账	幂等键防重；按 usage 计量；价格表版本化；与供应商账单逐日对账

2.5 数据与评估

• 路由质量看成功率、P99、单位请求成本、回退率、供应商 429 率；计费差异率低于 0.1%。
• 压测覆盖单 Pod 基准、集群扩展、Redis 故障、上游 5xx 与超时；用真实流量回放比较路由策略。

2.6 取舍与风险

• 同步扣费准确但增加延迟，选择预扣配额 + 异步结算；精确限流与本地近似限流结合。
• 无脑重试会放大故障，只对幂等请求重试并设预算；多供应商、密钥托管、缓存隔离防主要风险。

2.7 面试官可能追问

• 如何防止一个租户打垮网关？租户级并发与 TPM 隔离，热点租户单独分片；必要时排队而不是直接拒绝。
• 流式响应如何计费？按预估上限预扣，结束后按实际 usage 多退少补，异常断流按已生成 token 结算。

题目 3：代码助手（IDE 插件、补全、低延迟）

3.1 需求澄清

类别	需求	量化目标
功能	行级/片段补全、函数与单测生成、代码解释	结果可编译，支持主流语言
功能	仓库上下文、许可证与密钥扫描	阻断高风险片段
非功能	5 万研发，日活 1.5 万，人均 150 次补全	225 万次/日
非功能	补全首个 token 延迟（Time to First Token, TTFT）P95 低于 150 ms、总 P95 低于 400 ms	代码可不出域

3.2 容量估算

假设：每次补全输入 1,500、输出 60 token；峰值系数 8；7B 模型做行级补全，70B 做对话与复杂生成。

• 平均 QPS \(2.25\times10^6/86400\approx26\)，峰值 208 QPS。
• 日 token：输入 \(3.375\times10^9\)、输出 \(1.35\times10^8\)；峰值预填充 312k token/s、解码 12.5k token/s。
• GPU：7B 低延迟下单机有效解码 2,000 token/s，需 7 台 8 卡机；70B 对话 2 台；加高可用共 12 台 8 卡机、96 张 GPU。
• 延迟预算：网络 30 + 认证 10 + 上下文 30 + 排队 20 + 预填充 40 + 解码 60 ≈ 190 ms，满足 P95 400 ms。
• 存储：1 万活跃仓库 × 200 MB = 2 TB；10 亿行代码每 100 行一块得 1,000 万块，向量 40 GB、索引 60 GB。

3.3 高层架构

IDE 插件 → 本地上下文（抽象语法树（Abstract Syntax Tree, AST）、最近编辑、打开文件）→ 网关（认证/配额/路由）
        → 上下文服务（仓库索引/符号检索）→ 小模型补全或大模型生成
        → 后处理（格式化、去重、许可证/密钥扫描）→ IDE
索引：代码托管 → 解析 → 分块 → 向量化；遥测只传指标与脱敏片段

3.4 关键模块

模块	设计要点
上下文	用 AST 取作用域、导入、类型定义；按 token 预算裁剪，优先最近编辑与相关符号
低延迟	量化、连续批处理、前缀缓存、推测解码；行级补全只生成单候选
安全	许可证相似度、密钥正则与熵检测、危险 API 黑名单
降级	网络异常切本地小模型或关闭补全；企业可配置代码不出域

3.5 数据与评估

• 离线看 pass@1、编译通过率、单测通过率、编辑距离；在线看采纳率、采纳后保留率、TTFT P95、崩溃率。
• 评估集按语言、框架、仓库规模分层，用隐藏测试防污染；A/B 以“采纳且 24 小时未回退”为主指标。

3.6 取舍与风险

• 本地模型隐私好但能力弱，云端能力强但有泄露风险；采用本地补全 + 云端复杂任务的混合模式。
• 上下文越多越准但延迟与成本上升；主要风险是不可编译、版权污染、密钥泄露，用编译校验、许可证与密钥扫描缓解。

3.7 面试官可能追问

• 如何在 150 ms 内完成补全？小模型 + 量化 + 前缀缓存 + 单候选 + 边缘节点，必要时牺牲上下文长度。
• 如何利用仓库上下文而不上传全部代码？本地建符号索引，只上传脱敏的签名、类型与相关片段。

题目 4：多轮智能客服（含转人工、工单）

4.1 需求澄清

类别	需求	量化目标
功能	售前咨询、订单查询、退换货、投诉，多轮槽位填充	覆盖 Top 50 意图，支持 10 轮
功能	调用订单/物流/退款工具，转人工与工单	工具成功率 99%，越权操作为 0
非功能	1,000 万月活，日会话 30 万，均 5 轮	150 万消息/日
非功能	首响 P95 1.5 秒、端到端 P95 5 秒、可用性 99.95%	自助解决率 60% 以上

4.2 容量估算

假设：每轮输入 3,000、输出 150 token；峰值系数 5；转人工率 15%，人均处理 5 分钟。

• 平均 QPS \(1.5\times10^6/86400\approx17.4\)，峰值 87 QPS。
• 日 token：输入 \(4.5\times10^9\)、输出 \(2.25\times10^8\)；峰值预填充 261k token/s、解码 13k token/s。
• GPU：70B 单机有效解码 2,000 token/s，需 7 台 8 卡机；嵌入与重排 2 台；按高可用共 12 台 8 卡机、96 张 GPU。
• 人工：\(30\text{ 万}\times15\%=4.5\) 万会话/日，并发 \(4.5\times10^4\times300/86400\approx156\)，峰值 780，按 75% 利用率约 1,040 坐席。
• 存储：消息 3 GB/日、一年 1.1 TB；工单 225 MB/日、一年 82 GB；若含录音，日增约 900 GB，需分层。

4.3 高层架构

用户 → 渠道接入 → 会话编排器
  ├─ 意图识别与槽位填充 → 知识检索 → 大模型生成
  ├─ 业务工具（订单/物流/退款）→ 策略引擎（权限、金额、风控）
  └─ 转人工 → 坐席工作台 → 工单系统
旁路：会话存储、实时质检、知识缺口挖掘、满意度回访

4.4 关键模块

模块	设计要点
会话编排	状态机保证流程可控，大模型负责理解与措辞；状态持久化支持断点续聊
意图槽位	小模型分类 + 规则兜底；低置信度主动澄清，不猜测
工具调用	白名单、参数校验、幂等键、超时补偿；退款设金额上限与二次确认
转人工	明确触发条件，携带摘要、已尝试方案、订单上下文与置信度；工单自动分类去重

4.5 数据与评估

• 业务看自助解决率、转人工率、一次解决率、平均处理时长、客户满意度（Customer Satisfaction, CSAT）、重复咨询率；模型看意图准确率、槽位 F1、工具成功率、违规承诺率。
• 离线用历史会话回放，在线灰度 A/B；转人工原因是错误分类的主要来源，红队覆盖诱导退款与越权查单。

4.6 取舍与风险

• 高风险流程用状态机，开放咨询用大模型；高频标准问题用模板保证一致性，长尾用检索生成。
• 转人工阈值高则体验差、低则人力贵，用置信度与风险双阈值；主要风险是越权承诺、错误退款、隐私泄露。

4.7 面试官可能追问

• 如何降低转人工率？先分析原因，补齐知识、优化意图与槽位、允许自助修改订单，而不是一味调低阈值。
• 如何保证退款安全？金额分级审批、收款账户校验、二次确认、幂等键、全链路审计。

题目 5：日活百万的 AI 搜索/问答产品

5.1 需求澄清

类别	需求	量化目标
功能	自然语言提问，返回生成答案与来源，支持多步推理	答案可追溯，支持 3 步以内
功能	时效性、多样性、去重与安全过滤	索引日级更新，热点小时级
非功能	100 万日活，人均 6 次查询	600 万查询/日，可用性 99.9%
非功能	P95 首 token 1.5 秒、端到端 3 秒	无答案时降级为链接列表

5.2 容量估算

假设：每次输入 4,000、输出 300 token；20% 查询二次检索；峰值系数 4；60% 请求由缓存或小模型处理。

• 平均 QPS \(6\times10^6/86400\approx69\)，峰值 278 QPS。
• 日 token：输入 \(2.4\times10^{10}\)、输出 \(1.8\times10^9\)；峰值预填充 1.11M token/s、解码 83k token/s。
• GPU：全走 70B 按单机 2,000 token/s 需 42 台 8 卡机；级联后 40% 走大模型需 17 台，加冗余 24 台、192 张 GPU；嵌入与重排 6 台。
• 索引：1,000 万文档 × 5,000 token = 500 亿 token；倒排索引约 100 GB；5,000 万块向量 200 GB、HNSW 约 300 GB；原文 10 TB。
• 日志 \(6\times10^6\times5\text{ KB}=30\) GB/日、月约 1 TB；热查询缓存 1 TB。

5.3 高层架构

用户 → CDN/边缘缓存 → 查询理解（纠错、意图、时效）→ 检索
  ├─ BM25 + 向量 → 倒数排名融合（Reciprocal Rank Fusion, RRF）→ 重排 → 片段选择与去重
  ├─ 答案生成（流式）→ 引用与安全过滤 → 返回
  └─ 降级：无答案返回链接列表
索引：抓取 → 解析 → 去重 → 质量过滤 → 分块 → 向量化

5.4 关键模块

模块	设计要点
查询理解	纠错、同义扩展、时间敏感识别、是否需要多步推理
混合检索	BM25 保证精确匹配，向量保证语义召回，RRF 融合
重排生成	Cross-Encoder 对前 50 排序；答案强制引用，冲突信息并列展示
缓存安全	精确 + 语义缓存，时效 query 短 TTL；输入风控、输出审核、危险领域白名单

5.5 数据与评估

• 离线看答案正确率、引用准确率、覆盖率、时效性、多样性、拒答率；在线看点击、停留、满意度、重复查询、零结果率、P95。
• 1,000 条人工标注 query 做黄金集，按领域与时效分层；同时看“答案对不对”和“引用是否支持答案”。

5.6 取舍与风险

• 生成答案体验好但责任大，采用“答案 + 来源 + 可展开原文”；全量索引贵，按热度与质量分层。
• 缓存降本但可能返回旧信息，按时效标签设 TTL；主要风险是错误信息扩散、版权、时效性与热点打垮系统。

5.7 面试官可能追问

• 如何保证答案时效？索引分层更新，时效 query 走实时检索，答案标注数据时间。
• 如何处理争议性问题？并列多来源、标注立场、不给出单一结论，必要时只返回链接。

题目 6：大模型训练平台（数据、训练、评测、部署）

6.1 需求澄清

类别	需求	量化目标
功能	数据接入/清洗/tokenize/版本管理，单机与分布式训练	支持 70B 级模型，实验可复现
功能	超参搜索、实验跟踪、模型登记、评测与部署	发布前必须过质量门禁
非功能	100 名研究员、1,000 张 GPU、30 个并发作业	GPU 利用率 70% 以上
非功能	故障后 10 分钟内恢复训练	高优作业等待小于 1 小时

6.2 容量估算

假设：训练 70B 模型、2 万亿 token；GPU 为 H100 级，BF16 峰值约 1,000 TFLOPS，有效算力 40% 即 400 TFLOPS；检查点 1.1 TB，保留 10 份，20 个活跃实验；30 个并发作业以中小作业为主，70B 训练按配额排队。

• 训练算力 \(C=6ND=6\times7\times10^{10}\times2\times10^{12}=8.4\times10^{23}\) 浮点运算次数（Floating Point Operations, FLOPs）。
• GPU 秒 \(8.4\times10^{23}/4\times10^{14}=2.1\times10^9\)，即约 24,300 GPU·天；1,000 卡 × 70% 利用率约 35 天/次。
• 显存：70B BF16 权重 140 GB、Adam 状态 840 GB、梯度 140 GB，加激活至少跨 64 张 GPU 全分片。
• 存储：原始数据 100 TB、tokenize 后 8 TB、检查点 \(1.1\times10\times20=220\) TB、日志 50 TB，热存约 500 TB、冷存 2 PB。
• 检查点 1.1 TB 在 60 秒内写完需 18 GB/s，并行文件系统按 200 GB/s 设计。
• 训练吞吐 \(2\times10^{12}/(35\times86400)\approx6.6\times10^5\) token/s，折合每卡约 660 token/s；平台控制面按 50 QPS、评测推理按 20 QPS 估算。

6.3 高层架构

研究员 → 门户/API → 配额与审批 → 调度器（Kubernetes + Gang Scheduling）
  ├─ 训练作业（PyTorchJob）→ GPU 池；数据服务 → 并行文件系统/对象存储
  ├─ 实验跟踪与日志 → 时序库/对象存储；评测服务 → 推理集群
  └─ 模型登记 → 部署服务 → 推理网关
身份、审计、计费、告警贯穿全链路

6.4 关键模块

模块	设计要点
调度	配额、优先级、抢占、gang scheduling，避免半分配死锁
训练容错	集合通信与拓扑感知；定期异步检查点、失败自动重启、弹性扩缩容
数据版本	内容寻址存储，记录数据、代码、配置、随机种子四元组
评测部署	基准集 + 业务集 + 人工盲评；模型转换、量化、灰度、回滚

6.5 数据与评估

• 平台看 GPU 利用率、模型算力利用率（Model FLOPs Utilization, MFU）、作业等待、故障恢复、检查点成功率；模型看 loss、基准分数、业务评测、人工胜率。
• 每次训练记录数据版本与代码 commit；发布门禁要求能力不回归、安全评测通过、推理成本在预算内。

6.6 取舍与风险

• 高优抢占提升利用率但伤害长任务，采用配额 + 可抢占低优队列；检查点频繁占带宽，稀疏则恢复慢。
• 物理隔离安全但利用率低，逻辑隔离加配额是折中；主要风险是 GPU 故障、网络拥塞、数据污染与实验不可复现。

6.7 面试官可能追问

• 1,000 张卡训练 70B 要多久？按 2 万亿 token、40% MFU 约 35 天，实际受通信与故障影响更长。
• 如何提高 MFU？优化并行策略、增大 batch、重叠通信与计算、使用 FlashAttention 与混合精度。

题目 7：多模态图文审核系统

7.1 需求澄清

类别	需求	量化目标
功能	图片、视频、文本的涉黄、暴恐、违规检测	高风险召回 95% 以上
功能	光学字符识别（Optical Character Recognition, OCR）、语音识别（Automatic Speech Recognition, ASR）、分级处置、申诉复审	24 小时内响应申诉
非功能	1 亿日活，日帖子 2,000 万	峰值 1,155 帖/秒（约 1.2k QPS）
非功能	图片审核 P95 低于 500 ms，误杀率低于 2%	日志留存 6 个月

7.2 容量估算

假设：图片 80%、视频 10%、文本 10%；图片 1 MB、视频 10 MB；峰值系数 5；10% 升级多模态大模型；人工复核 1%。

• 平均 \(2\times10^7/86400\approx231\) 帖/秒，峰值 1,155 帖/秒；图片 924 张/秒、视频 116 条/秒。
• 存储：图片 16 TB/日、视频 20 TB/日、文本 4 GB/日，合计约 36 TB/日；30 天约 1.1 PB，一年冷存约 13 PB。
• GPU：快筛 200 张/秒需 5 张卡；视频 10 帧/条共 1,160 帧/秒需 6 张；多模态大模型 116 条/秒 × 1,000 token ÷ 2,000 token/s ≈ 58 张；合计约 70 张，按冗余 90 张。
• 人工：20 万条/日 × 30 秒 ÷ 8 小时 ÷ 0.8 ≈ 260 人；峰值用队列削峰，按 300 至 350 人配置，高危队列优先。
• 队列：1,155 帖/秒 × 200 ms ≈ 231 并发，按 3 倍冗余 700 并发。

7.3 高层架构

上传 → CDN/对象存储 → 消息队列 → 预处理（抽帧、OCR、ASR）
  → 哈希匹配 → 快筛模型 → 策略引擎
  ├─ 通过 → 发布；拒绝 → 通知与申诉
  └─ 可疑 → 多模态大模型 → 人工复核 → 处置
旁路：特征库、策略配置、审核日志、模型评估

7.4 关键模块

模块	设计要点
预处理	视频抽关键帧、音频转写、图片压缩；失败降级人工
哈希匹配	MD5 精确匹配 + 感知哈希近重复，拦截已知违规
快筛与大模型	轻量分类器高召回，阈值偏保守；大模型输出类别、置信度、证据区域
策略与复核	按地区/年龄/场景配置规则；分级队列展示原图、理由与相似案例；申诉反向标注

7.5 数据与评估

• 看高风险召回、误杀率、类目精确率、人工复核率、复核时长、申诉翻转率；评估集覆盖长尾、对抗样本与图文歧义。
• 线上用分层抽样估计真实召回，不能只看置信度；红队持续构造绕过样本。

7.6 取舍与风险

• 高风险召回优先，用人工复核降低误杀；快筛便宜但弱，大模型强但贵，级联是折中。
• 抽帧多则成本高、少则漏检，按视频时长与场景变化自适应；主要风险是对抗样本、长尾、隐私与审核员心理负担。

7.7 面试官可能追问

• 如何估计真实召回？从全量随机抽样人工标注，结合模型分数做分层抽样估计。
• 视频审核如何降本？先抽关键帧与音频，命中可疑再全量抽帧；静态场景减少帧数。

题目 8：Agent 平台（工具市场、沙箱、可观测）

8.1 需求澄清

类别	需求	量化目标
功能	Agent 创建、版本、发布、回滚，多步规划与执行	支持 20 步以内
功能	工具市场、鉴权、计费、评级，沙箱执行与人工审批	租户隔离，无越权
非功能	10 万开发者、1 万个 Agent、100 万次运行/日	峰值 58 次运行/秒、大语言模型（Large Language Model, LLM）调用 580 次/秒
非功能	工具调用 P95 低于 1 秒，沙箱逃逸为 0	全链路 trace 可回放

8.2 容量估算

假设：每次运行 10 步，每步输入 2,000、输出 300 token；60% 步骤走小模型；每次运行 20 次工具调用；沙箱平均 60 秒；峰值系数 5。

• 平均运行 \(10^6/86400\approx11.6\) 次/秒，峰值 58 次/秒；LLM 调用 1,000 万次/日，平均 116 次/秒、峰值 580 次/秒。
• 日 token：输入 \(2\times10^{10}\)、输出 \(3\times10^9\)；峰值预填充 1.16M token/s、解码 174k token/s。
• GPU：全走 70B 需 87 台 8 卡机；60% 小模型分流后 70B 约 35 台，加小模型与冗余共 50 台 8 卡机、400 张 GPU。
• 工具调用 2,000 万次/日，平均 231 次/秒、峰值 1,155 次/秒；沙箱 \(10^6\times60=6\times10^7\) 容器·秒/日，平均 694 并发、峰值 3,470，按 4,000 容器池设计。
• 存储：trace 30 GB/日、30 天 900 GB；产物 1 TB/日、30 天 30 TB；元数据与日志 5 TB。

8.3 高层架构

开发者 → 门户 → Agent 注册/版本 → 编排服务（规划、状态机、重试）
  ├─ 模型网关 → 多模型路由
  ├─ 工具网关 → 鉴权、限流、审计 → 第三方 API
  ├─ 沙箱池 → 代码/浏览器执行；人工审批 → 审批队列
  └─ 可观测 → trace/日志/指标 → 回放
计费与配额贯穿；工具市场提供 schema、服务等级协议（Service Level Agreement, SLA）、价格与评级

8.4 关键模块

模块	设计要点
Agent 定义	声明式配置：模型、提示词、工具、知识、策略；版本不可变
编排	状态机 + 大模型规划；每步保存状态，支持重试、断点续跑与最大步数
工具网关	JSON Schema 校验、OAuth 凭证托管、超时、幂等、配额、审计
沙箱与可观测	强隔离、默认无外网、CPU/内存/时长限额；每步一个 span，记录 token、成本与耗时

8.5 数据与评估

• 平台看运行成功率、步骤成功率、工具错误率、P95、单次成本、沙箱启动、trace 完整率；Agent 看任务完成率、人工接管率、平均步数、越权拦截率。
• 每个 Agent 上线前跑回归集；线上回放与人工抽检，重点看“看似完成但实际错误”；安全评估覆盖提示词注入、参数注入、沙箱逃逸。

8.6 取舍与风险

• 开放任务用规划，高风险任务用固定流程加人工审批；共享沙箱利用率高，关键租户独立资源池。
• 主要风险是工具滥用、凭证泄露、无限循环、成本失控、沙箱逃逸；用配额、预算上限、最大步数、凭证隔离与强隔离缓解。

8.7 面试官可能追问

• 如何防止 Agent 无限循环？设置最大步数、预算、无进展检测与重复工具调用检测。
• 沙箱如何防逃逸？最小权限、无外网、只读文件系统、内核隔离、定期漏洞扫描。

面试高频问题

1. 系统设计面试应该怎样开场？

参考回答要点：

• 先用两分钟澄清用户、核心场景、规模与硬约束，复述给面试官确认。
• 明确哪些功能做、哪些不做，避免后面无限扩张。

• 给出容量假设与峰值系数，说明后续架构会围绕这些数字展开。

• 没有真实数据时如何做容量估算？

参考回答要点：

• 用“用户数 × 使用频率 × 单次 token”自顶向下估算，再用同类产品交叉验证。
• 明确平均与峰值系数，通常取 3 至 10 倍，并说明依据。

• 把假设写成表格，主动说“如果这个数变化，结论会怎样”。

• 如何在效果、延迟与成本之间取舍？

参考回答要点：

• 先定义质量下限与延迟上限，再在约束内最小化成本。
• 用缓存、小模型、大模型、人工逐层级联，非关键路径异步化。

• 用灰度验证真实收益，不靠离线指标拍板。

• 多租户系统如何做隔离？

参考回答要点：

• 数据隔离：行级权限或独立库表，密钥按租户加密。
• 配额隔离：RPM、TPM、并发、存储分别限额，防止噪声邻居。

• 故障隔离：关键租户独立资源池，熔断与降级按租户生效。

• 如何设计灰度与回滚？

参考回答要点：

• 按用户或租户切分，保证同一用户始终命中同一版本。
• 先内部、再低风险客户、再全量；每步设观察窗口与止损指标。

• 新旧链路并行，保留一键切回与数据兼容方案。

• 如何评估检索增强生成（Retrieval-Augmented Generation, RAG）或 Agent 的端到端质量？

参考回答要点：

• 拆成检索、推理、工具调用、生成四段，分别设指标。
• 黄金集覆盖高频、长尾、拒答与对抗；挑战集持续更新。

• 在线看采纳率、人工接管率、重复提问与负反馈。

• 上游模型不稳定时怎么办？

参考回答要点：

• 多供应商与多模型路由，设置健康检查与熔断。
• 只对幂等请求重试，设置重试预算与指数退避，避免放大故障。

• 准备降级模型、缓存答案与静态兜底文案。

• 如何回答“为什么不直接用现成产品”？

参考回答要点：

• 从数据边界、权限体系、业务流程集成与单位经济模型四个维度比较。
• 现成产品适合通用场景，自建适合深度集成、强合规或大规模摊薄成本。
• 给出 build vs buy 的成本曲线与时间成本，而不是只谈技术。

本文档为面试复习资料，商业与合规信息请以最新官方规定为准。