题干与适用场景
平台接收文字、图片、音频和视频，用户希望发布后很快可见；平台又必须在高风险内容造成大范围传播前处理它。请设计上传预筛、异步深度分析、人工审核、申诉、发布后复查和策略迭代。题目不要求你训练模型，但要说明模型输出如何进入可审计的业务决策。
公开系统设计面经把这类题拆成多层流水线、置信度分段、人审队列和申诉流程。为了让容量可复算，先采用一组面试假设：每小时 1,000,000 次上传，平均约 278 次/秒，峰值按 10 倍约 2,778 次/秒；同步预筛给发布链路增加不超过 100 毫秒，人工团队每天最多处理 100,000 个案件。真实数值应由面试官给定后替换。
面试官考察点
面试官会看你能否把“审核”拆成不同延迟和风险等级的决策，而不是只画一个分类器。强回答会区分立即阻断、先发布后复查和送人工的路径，按政策类别设置不同阈值，记录模型版本与证据，并说明错误判定如何纠正。
系统设计评分还包括峰值容量、队列积压、重复任务、模型不可用、对抗性输入、审核员安全、申诉时限和租户或地区隔离。只谈准确率却没有安全默认、回放证据和运营指标，无法支撑线上治理。
回答前需要澄清的问题
哪些内容必须阻断
确认是所有内容都要发布前审核，还是只有明显高风险类别必须同步阻断。若只允许约 100 毫秒的同步预算，视频深度分析应转为异步；若监管要求某类别零延迟下架，就要为该类别保留更重的同步检查。
错误成本如何排序
询问误杀合法表达与漏放高危内容哪一个代价更高，以及是否按国家、年龄或内容类别变化。答案决定每类阈值、是否宁可送人工、以及自动动作能否直接删除。
审核和证据需要保留多久
确认申诉期限、监管取证、媒体存储和个人信息删除要求。若必须复盘当时的判断，系统要保存策略版本、模型版本、输入摘要、分数、证据引用和审核员动作，而不是只存最终标签。
模型和人工的容量边界
询问模型不可用时是否允许降级发布、人工每日容量和最长等待时间。容量不足时应降低低风险流量或延迟非关键任务，不能让队列无限增长并悄悄放过高风险内容。
30 秒回答框架
“我会把路径分成同步预筛和异步深审。上传时先做哈希命中、轻量分类和基础策略校验；明确高风险直接阻断，中间置信度进入按风险和预计曝光排序的人审队列，低风险先发布但保留发布后复查。每个决定记录模型、策略、证据和版本，申诉交给不同审核员。容量上按峰值 2,778 次/秒扩展预筛，异步队列用租户和风险类别隔离，监控漏放、误杀、积压年龄、曝光时间和审核员负载；模型或队列故障时采用安全默认和明确的人工兜底。”
分步骤深入解答
第一步：拆分同步与异步决策
入口接收内容后写入不可变的 contentId 和媒体引用。同步层只做快速哈希匹配、格式与大小检查、轻量文本或图像模型和地区策略。明确高危结果阻断；可疑但不确定的结果进入 PENDING_REVIEW；低风险结果允许发布并携带后续复查标记。视频抽帧、音频转写和多模型融合放到异步流水线，避免把深度分析时间塞进发布请求。
第二步：按类别而不是全局分数动作
不要用一个全局阈值处理所有政策类别。对高危类别可以设置较低的自动阻断门槛，并把临界样本送人审；对语境依赖强的类别，扩大人工区间，减少误杀。阈值配置必须带策略版本和生效地区，决策事件保存原始分数及阈值，后续才能解释为什么采取了某个动作。
第三步：设计可扩展的审核队列
把审核任务写入持久队列，按风险等级、预计曝光量、用户举报和截止时间计算优先级。每个任务带租户或地区、内容版本、策略版本和租约；审核员领取后短暂锁定，超时自动回队列。队列按类别和地区分片，避免一个热门类别耗尽所有人工容量；当积压年龄超过阈值时，降低低风险异步任务的准入并报警。
第四步：让申诉和反馈可回放
申诉创建新案件，不覆盖原始决定。复核员看到当时的证据、策略和模型版本，并拥有与初审不同的权限；推翻决定会恢复内容或保留限制，同时生成审计事件。抽样人工结果、申诉翻转和新出现的规避样本进入评估集，但不能未经审核直接回灌训练，以免把错误标签放大。
第五步：观测风险、体验和成本
即时指标包括预筛延迟、每类阻断率、异步队列长度与年龄、模型错误率、审核吞吐和服务错误。成熟标签到达后，再按类别和地区计算精确率、召回率、误杀、漏放、申诉翻转率。还要看高风险内容的曝光次数乘以在线时长、审核员平均暴露量和单位内容成本；只看模型准确率无法发现治理失效。
第六步：覆盖故障和对抗性输入
模型超时或不可用时，保留哈希命中和规则阻断；对未知风险的内容进入受限发布或人工路径，不能把“无结果”当成安全。对重编码图片、变形文字、重复上传和故意制造队列的攻击设置速率限制、内容去重和资源配额。所有自动动作都要能按 contentId 重放，便于事故调查和规则回滚。
高质量示范回答
我先确认发布链路的同步预算和高风险类别。假设平均 278 次/秒、峰值 2,778 次/秒，我会把同步路径限制在哈希、格式、轻量模型和地区规则，目标是不超过 100 毫秒。明确高危内容立即拒绝；中间区间进入持久人审队列；低风险内容先发布，但标记为可被异步复查。视频和音频的深层分析通过队列和 worker 执行，不能阻塞所有用户的发布。
阈值按政策类别配置，而不是把一个分数用于所有风险。每次决定保存 contentId、内容版本、模型与策略版本、分数、证据摘要和动作。人审任务按预计曝光量、风险、举报和截止时间排序，使用租约防止重复领取；积压时先保护高风险队列。审核员确认或推翻决定都会产生不可变事件，申诉由不同审核员处理并引用原始证据。
我会监控预筛延迟、队列年龄、每类误杀和漏放、曝光时间、申诉翻转、人工容量和单位成本。模型故障时仍执行哈希和规则阻断，对未知结果采用受限发布或人工兜底。模型、政策和地区变更都先离线回放，再小范围灰度；这样系统的目标是可解释、可回滚和持续降低风险，而不是只追求一个离线准确率。
常见错误
- 所有内容都同步跑重模型 → 视频和音频延迟拖垮发布链路 → 同步只做快速预筛，深度分析异步化。
- 所有类别共用一个阈值 → 高危漏放或语境类误杀无法同时避免 → 按政策类别和地区配置阈值，并保留人工区间。
- 模型返回空结果就自动放行 → 模型超时会变成无审计的漏放 → 保留规则和哈希阻断，对未知结果走受限发布或人工兜底。
- 只存最终标签 → 申诉时无法重建当时依据 → 保存内容版本、模型/策略版本、分数、证据和动作事件。
- 队列按先到先得 → 热门或低价值流量可能饿死高风险案件 → 按风险、预计曝光和截止时间排序，并隔离队列容量。
追问及应对
追问一：人工审核只覆盖总量的 1% 是否足够？
比例本身不是目标。AWS 文档以其图像和视频流程为例，说明机器筛选后人工可能只需查看约 1%–5%；你的系统仍应按类别召回、漏放后果、积压年龄和曝光时间验证，而不能把该范围当成普遍保证。若高风险类别漏放，宁可扩大人工区间或降低发布准入。
追问二：审核队列积压到一天怎么办？
先按风险和预计曝光重新排序，暂停低价值批量任务，扩大高风险审核容量并提升告警。对已经发布的内容运行发布后复查和限流；不能通过静默丢弃任务来降低积压数字。若仍无法满足高风险截止时间，应收紧发布策略并向业务暴露容量不足。
追问三：用户申诉成功后如何防止模型再次误杀？
保存申诉前后的策略和模型版本，将翻转案例按类别加入独立评估集，并检查是否存在地区、语言或群体偏差。修订阈值或规则后先回放历史样本，再灰度发布；申诉结果不能直接当作未经审核的训练标签。
追问四：模型供应商切换时如何保证可追溯？
为每个模型适配器定义统一输出和版本标识，保存原始供应商结果摘要与映射规则。新模型先在固定回放集和人工盲评中比较每类误杀、漏放、延迟和成本，再按地区或流量灰度；出现异常时按策略版本回滚到旧适配器。