十四、系统设计题

这一章是高级岗面试的分水岭。标准答题节奏：先澄清需求边界与规模假设，再给分层总体架构，逐模块展开关键设计，主动讲 trade-off，最后给出演进路线——面试官看的是决策过程，不是组件清单。

137. 设计一个企业级知识库问答系统（RAG），从文档接入、解析、索引到生成、引用的完整方案。

必刷 · 较难

参考答案

第一步 · 澄清需求（主动问或自设假设）：文档规模（如 10 万篇、日增数百篇）、类型（PDF / Word / 网页 / Confluence）、峰值并发（十到百级 QPS）、权限要求（部门隔离）、延迟目标（P95 小于 5 秒）。

第二步 · 总体架构（五层，按数据流叙述）：

• 接入层：文档源适配器（webhook + 定时增量拉取），统一转成任务进队列，解耦解析与索引的速率；
• 解析层：格式适配（PDF 用版面解析工具处理双栏、表格）、结构化抽取（标题层级、表格转 Markdown）、增量处理（chunk 级哈希比对，只重嵌入变化部分）；
• 索引层：语义切分 + 父子块，双路索引——向量库 + 倒排（BM25），元数据带部门权限、文档版本、更新时间；
• 检索生成层（在线）：Query 预处理（多轮改写、指代消解）→ 混合检索（向量 + BM25，RRF 融合）→ Rerank 精排取 top-k → 带引用生成（要求"仅依据资料回答，标注 [n]"）；
• 治理层：评估集回归、bad case 收集、检索与生成指标监控（召回率、忠实度）、Prompt 版本管理。

第三步 · 关键设计点：

• 引用可溯：答案中 [n] 映射回 chunk 及源文档定位（页码 / 锚点），前端可点击溯源——企业场景信任的根基；
• 权限过滤在检索层强制执行：query 携带用户身份做索引 pre-filter，不允许只靠 Prompt 约束；
• 缓存：热点问题的语义缓存可省约两到四成生成成本，按精确匹配 + 向量相似度两级设计；
• 拒答设计：检索相似度低于阈值时明确说"知识库未覆盖"，不硬编。

第四步 · trade-off：chunk 粒度（小块检索准但上下文碎，大块全但噪声多）→ 用父子块折中；索引实时性 vs 系统复杂度；10 万篇量级 pgvector 或 Milvus 单集群都够，按运维能力选，不必过度设计。

第五步 · 演进：千万级文档 → 检索分片 + 多级路由；效果到顶 → 引入 Agentic RAG（模型自主决定补查、改写后重查）；多语言 → 多语 Embedding 或统一翻译层。

面试官可能追问

• 表格和图片在哪个环节处理？检索不到怎么办？
• Rerank 增加多少延迟？什么时候不值得加？
• 这套系统的效果怎么评估？

138. 设计一个能自主完成某复杂任务（如行程规划、周报生成）的 Agent 系统，说明控制流和护栏。

高频 · 较难

参考答案

第一步 · 澄清任务特性：以行程规划为例——需要外部数据（机票 / 酒店 / 天气 API）、多约束（预算 / 时间 / 偏好）、涉及真实交易。核心矛盾是"自主性带来的效率"与"失控风险"，设计全部围绕它展开。

第二步 · 总体架构（五模块）：

• 交互层：需求收集（结构化表单 + 自然语言混合，关键约束显式确认）+ 过程可视（当前步骤、已调工具）+ HITL 确认卡点；
• 规划层：任务拆解为子目标 DAG（查日期 → 比价 → 排程 → 成稿），每个子目标有明确完成判据，支持整体重规划而不只是单步 react；
• 执行层（Agent Loop）：Plan-and-Execute 与 ReAct 混合——先全局规划，执行中局部 react。工具层统一协议：schema 校验、超时、幂等键；
• 记忆层：会话内短期记忆（消息 + 显式状态对象）+ 用户长期偏好（预算档位、禁忌）跨会话复用；
• 护栏层：贯穿全程，见下。

第三步 · 控制流与护栏（题眼）：

• 资源预算：单次任务最大步数（如 15 步）、最大 Token 消耗、最大工具调用次数，超限终止并输出已完成部分；
• 循环检测：连续 N 步调用相同工具且参数相似 → 判定死循环，熔断该工具并注入反思提示，仍失败则降级；
• 写操作 HITL：只读工具（查价、查天气）自主执行；写操作（下单、发邮件）必须暂停等人工确认，确认后从断点恢复——状态持久化是前提；
• 结果校验：结构化输出过校验器（预算不超、时间不重叠），失败带错误信息重生成；
• 出口设计：正常完成 / 超限终止 / 用户中止 / 校验失败降级，四种出口都要有体面的用户呈现。

第四步 · trade-off：自主性按操作可逆性分级——可逆放开、不可逆卡死；规划开销（先规划省 Token 但前期延迟高，纯 react 快但易跑偏）；周报类结果可校验性强、护栏可弱，行程类涉及交易、护栏必须硬。

第五步 · 演进：任务更复杂 → 拆多 Agent（规划者 + 执行者 + 审查者）；用历史人工通过率数据逐步放宽 HITL 范围。

面试官可能追问

• 怎么防止 Agent 死循环？具体机制是什么？
• 暂停等确认期间服务重启了，怎么恢复？
• 这个 Agent 的好坏怎么评估？（轨迹 + 结果双层）

139. 设计一个支持 10 万 DAU 的智能客服系统，包含人工协同和会话兜底。

中频 · 较难

参考答案

第一步 · 规模推算（先算后设计）：10 万 DAU，按 20%~30% 咨询渗透率、人均 3~5 轮，日请求约 10 万~15 万次，集中在工作时段，峰值 QPS 约 10~30（量级估算）。单次 LLM 调用 2~5 秒，按利特尔法则（并发 = QPS × 平均时长），稳态在途请求达百级——这是容量设计的核心约束，也是与传统服务最大的不同。

第二步 · 总体架构（五层）：

• 接入层：多渠道接入（App / 网页 / 电话转写），SSE / WebSocket 长连接，会话粘性路由（同一会话落同一实例，本地缓存上下文）；
• 编排层：意图分流——高频标准问题（物流、退款进度）优先走确定性接口直查数据，LLM 只做表达润色，可消化约一半流量；其余走 LLM 通道；
• LLM 服务层：RAG 问答 + 对话管理（历史压缩、多轮改写）；模型用"小模型 + 大模型"分层，简单问题路由到小模型，难题升级；
• 人工协同层：转接决策引擎（低置信 / 情绪信号 / 多轮失败 / 用户主动）→ 排队与技能组路由 → 坐席工作台（AI 实时推荐回答、自动摘要）。转接必须携带上下文摘要，禁止用户复述；
• 兜底治理层：降级链路（LLM 超时限流 → FAQ 精确匹配 → 标准话术）；全链路监控；bad case 回流标注。

第三步 · 关键设计点：

• 会话状态：Redis 存活跃会话上下文（TTL 对齐会话生命周期），持久层存完整轨迹供审计；
• 排队体验：高峰期给排队位次预估 + 留言 / 回呼兜底，避免无限等待；
• 坐席辅助而非替代：AI 推荐答案由坐席一键采用或修改，采纳率既是效率指标也是质量反馈源；
• 指标体系：FCR（一次解决率）、转人工率、转人工后 24 小时内再进线率、CSAT、坐席人效。

第四步 · trade-off：自研 vs 云客服套件（自研可控但周期长）；小模型先行省成本但路由错误伤体验，要配路由准确率监控；10 万 DAU 规模建议机器人独立解决率 50%~70%、其余丝滑转出，不追求全自动。

第五步 · 演进：从工单和会话自动沉淀新 FAQ；坐席采纳数据反哺微调；语音通道接入。

面试官可能追问

• 峰值 QPS 怎么估的？LLM 服务怎么扩容？
• 会话上下文存哪？服务重启会不会丢？
• "机器人分流"的真实收益怎么衡量？

140. 设计一个多租户的 LLM 网关平台：计费、限流、路由、审计怎么做？

中频 · 较难

参考答案

第一步 · 澄清定位：内部平台型系统——多个业务方（租户）经统一网关访问多家模型 API，解决成本分摊、公平性、稳定性、审计合规四件事。规模假设：租户数十到数百，总峰值千级 QPS。

第二步 · 总体架构（四层）：

• 接入层：统一 API（兼容 OpenAI 协议降低接入成本）、租户鉴权（API Key → 租户身份）、请求校验；
• 路由层：租户配置的路由规则 → 模型选择（指定模型 / 按任务路由 / 成本优先）→ 供应商选择（同模型多供应商互备）。故障转移：健康检查 + 错误率熔断，主供应商失败自动切备用并留痕；
• 执行层：流式透传、统一重试（注意 LLM 调用不幂等，重试的计费口径要明确）、异步计费埋点（调用前预检配额，调用后按实际 usage 结算）；
• 数据层：计费账本、审计日志、用量分析。

第三步 · 四大核心机制：

• 计费：两级配额——租户级月度预算（软限告警 / 硬限拒绝）+ Key 级上限。Token 以供应商返回的 usage 为准，流式请求在最后一个 chunk 拿到 usage 再入账。每条记录带 trace_id 可与供应商账单对账。预付费用 Redis 原子计数实时扣减 + 定期落库；Prompt Caching 的折扣价按供应商规则分摊到租户；
• 限流：多维度分层——租户级 QPS / RPM、昂贵模型的并发上限、全局并发（保护供应商配额）。令牌桶或滑动窗口实现，超限返回 429 + Retry-After 便于业务方编程退避；配额分级保障小租户不被头部租户挤占；
• 路由：静态（租户指定）+ 动态（健康度、成本、延迟加权）；供应商密钥只存在网关侧的密钥服务（KMS 加密），业务方永不接触；
• 审计：全量记元数据（租户、模型、Token 数、延迟、结果码）；正文按与租户约定的留存策略处理——默认只留元数据，涉敏场景脱敏后留存。日志追加写、不可篡改，留存期按合规要求（常见半年到两年以上）。

第四步 · trade-off：网关多一跳增加毫秒级延迟，换来管控与复用，值得；计费实时性（实时扣减精确但重，准异步结算轻但有超用风险）——常见做法是预检余额 + 异步结算 + 超用容忍额度；起步可用 LiteLLM 这类开源网关，深度定制再自研。

第五步 · 演进：语义缓存下沉到网关（跨租户严格隔离）、租户自助配置面板、模型效果数据回流辅助选型。

面试官可能追问

• 流式请求的计费怎么保证准确、不丢账？
• 供应商把网关限流了，网关怎么自保？
• 审计要记 Prompt 正文吗？合规和成本怎么平衡？

141. 设计一个 AI 搜索引擎：查询理解、多路检索、生成、引用、去重的完整链路。

低频 · 较难

参考答案

第一步 · 澄清边界：AI 搜索 = 传统搜索 + 生成式摘要，用户要"答案 + 可信来源"。规模假设：日千万级查询（讲清量级即可）。核心矛盾：生成质量取决于检索质量，而检索要在大规模语料上做到低延迟。

第二步 · 完整链路（按查询生命周期叙述）：

• 查询理解层：query 纠错与归一、意图分类（导航型直接放行不生成、信息型进生成链路）、query 扩展（同义改写多路召回）、时效性识别（"今天""最新"类 query 提升新鲜度权重）。这层毫秒级完成，用小模型；
• 多路检索层：倒排（BM25，精确匹配强项）+ 向量（语义匹配）+ 时效通道（新闻索引）+ 垂直通道（天气、比分等结构化数据直接返回卡片，不进生成）。RRF 或加权融合，粗排取百级候选；
• 精排与去重：Rerank 精排到十级。去重三层：URL 归一化（去跟踪参数、镜像域名归并）→ 内容级相似度聚类（同一事件多篇报道归并，选权威源做代表）→ 生成时的来源多样性约束（避免全引一家）。"内容聚类 + 代表选择"是 AI 搜索区别于普通 RAG 的关键一环；
• 生成层：top 结果的标题 + 摘要 + 关键正文段注入 Prompt，生成综述 + 要点 + 内联引用 [1][2] 的结构化答案。来源分歧大时明示"各方说法不一"，不强行给单一结论；检索分数低、来源少时退化为传统结果列表，不生成摘要；
• 治理层：索引分层（实时 / 小时 / 天级）保障新鲜度、站点权威度进排序、安全过滤（高危内容不进摘要）、热点查询的答案级缓存（注意时效 TTL）。

第三步 · 关键设计点：延迟预算——传统搜索全链路几百毫秒，加生成后端到端 2~3 秒可接受，策略是先流式出检索结果占位、摘要流式追加，优化感知延迟；每个 [n] 必须真实对应一条检索结果，生成后校验引用编号合法性，杜绝编造引用。

第四步 · trade-off：生成摘要提升体验但引入幻觉风险 → 严格接地 + 引用校验收敛；全量索引实时化成本高 → 按查询热度分层；自建检索 vs 复用现有搜索基建——多数团队现实选择是后者 + 生成层。

第五步 · 演进：个性化（历史查询加权）、多模态（图片视频进摘要）、对话式追问（搜索会话化，上下文继承）。

面试官可能追问

• 怎么判断一个 query 该不该生成摘要？
• 多个来源结论矛盾时，生成策略怎么定？
• 答案缓存的时效性怎么控制？

142. 设计一个代码生成 Agent：仓库级上下文理解、代码库检索、安全执行沙箱怎么做？

低频 · 较难

参考答案

第一步 · 澄清任务范围：给定自然语言需求或 issue，产出可运行的代码改动（不是行级补全）。核心挑战：仓库上下文远超窗口、代码正确性要求高、执行不可信代码有安全风险。

第二步 · 总体架构（四模块）：

• 上下文构建：静态分析先行——解析仓库得到符号表（类 / 函数签名）、依赖图、目录结构地图（压缩到千级 Token 常驻上下文）。按需求做检索：向量检索相似代码 + 关键标识符倒排查询 + import 链扩展，多路融合后按 Token 预算装箱。签名、调用约定等元信息比正文省 Token 且信息密度高——优先给签名、按需给实现；
• 代码库检索：按语法单元（函数 / 类）切分而非固定行数；Embedding 用代码专用模型；查询侧"需求 → 关键词 + 语义"双路。检索结果附调用关系（这个函数被谁调用），改接口时能评估影响面；
• 生成与修复循环（Agent Loop）：规划（定位要改的文件和函数）→ 生成 diff → 执行验证 → 按报错 / 测试失败修复，循环有上限。验证信号分三级：编译 / lint（秒级最快反馈）→ 单元测试（分钟级）→ 行为验证（有测试用例的任务）。报错回传要截断聚焦（只给相关栈帧），否则浪费上下文；
• 安全执行沙箱：模型生成的代码必须在隔离环境执行，绝不在宿主机直接跑。方案：容器级隔离——每任务独立容器，CPU / 内存 / 进程数 / 时长限额，禁外网或仅白名单域名，文件系统只写工作区，用后即毁；更重的用 microVM（Firecracker、gVisor），更轻的用 WASM（适合纯计算但依赖受限）。镜像预装常用语言工具链加速冷启动；再叠一层静态检测（网络调用、文件越界、fork 炸弹）做前置护栏。

第三步 · 关键设计点：输出 diff 粒度（只改必要行，降低 review 成本）；执行环境确定性（固定依赖版本，避免"我机器上能跑"）；人类 review 卡点——Agent 负责写和自修，产出 PR 必须过人审和 CI，合并决策留给人（HITL）。

第四步 · trade-off：沙箱安全级别 vs 启动延迟（重量级隔离更安全但冷启动秒到十秒级，用预热池缓解）；自修轮数（多轮提升成功率但 Token 成本线性涨，经验上 3~5 轮后边际收益骤降）；上下文装箱比例（塞满窗口贵且 Lost in the Middle，精选两三成相关内容效果常更好）。

第五步 · 演进：issue → 测试 → 修复的全自动闭环、跨仓库依赖感知、从单文件改动到跨模块重构。

面试官可能追问

• 沙箱里生成的代码要访问数据库或内网服务怎么办？
• 上下文装不下大仓库时，优先级怎么排？
• 生成代码的质量怎么评估？

143. 设计一套 LLM 应用的全链路评估与监控平台：数据采集、指标体系、告警、回归。

低频 · 较难

参考答案

第一步 · 澄清定位：给多个 LLM 应用团队共用的平台，解决"效果不可见、迭代不可比、故障不可知"三个问题。核心难点：LLM 应用没有标准答案，评估本身是概率性的。

第二步 · 总体架构（四层）：

• 数据采集层：SDK 埋点，上报 trace——每次请求的完整链路（Prompt、检索片段、工具调用、模型输出、延迟、Token 数、用户反馈），trace_id 贯穿全链路支持回放。采样策略：元数据全量 + 正文按比例采样，平衡成本与覆盖率；用户显式反馈（点赞点踩、采纳、编辑后重提交）是最高价值信号，产品上要埋好。协议上兼容 OpenTelemetry 语义约定；
• 存储计算层：trace 存 OLAP 型存储（按 trace_id 关联查询），评估任务异步跑批（LLM as Judge），指标预聚合；
• 指标层（三层体系）：系统指标（确定性、实时）——可用性、P95 延迟、TTFT、错误率、Token 成本、限流拒绝率；质量指标（评估式、小时级）——忠实度 / 幻觉率（Judge + 抽样人工校准）、检索召回率（有标注集时）、拒答率、人工接管率；业务指标（离线 T+1）——解决率、采纳率、CSAT。三层必须能下钻关联：业务指标跌 → 定位质量指标 → 定位具体 trace；
• 应用层：按应用 / 版本 / 模型维度的对比看板、bad case 管理（标记 → 归因 → 转入评估集）、回归测试（发布前自动跑评估集与基线对比，防"改好一处改坏三处"）、告警。

第三步 · 告警设计（分层，防告警疲劳）：

• 规则告警（秒到分钟级）：错误率超阈值、P95 超标、Token 用量环比激增；
• 统计告警（小时级）：质量指标漂移——Judge 评分分布偏移、拒答率突增、输出长度分布变化。分布漂移往往是上游模型悄悄变更或 Prompt 被误改的信号；
• 闭环：告警附带典型 trace 样本，一键转 bad case 工单。

第四步 · 关键设计点：LLM as Judge 本身要治理——定期用人工标注对齐 Judge 一致性，Judge 的 Prompt 版本化管理；评估集版本化并定期从真实流量抽样补充，同时去重防泄漏；回归基线固定模型 + 固定采样参数，遵守单一变量原则。

第五步 · trade-off：采样率（全量贵、采样漏问题）；Judge 模型选型（大模型准但贵、小模型便宜但噪声大）——常见配比是全量小模型初筛 + 疑难样本大模型复评 + 每日定量人工金标；实时性（实时评估贵且抖动大，多数质量指标小时级足够）。

面试官可能追问

• LLM as Judge 不可靠怎么办？怎么校准？
• 怎么发现"上游模型偷偷更新导致效果下降"？
• 评估集怎么防污染、防过拟合？