大模型应用系统设计面试题
设计完成后，面试官通常会继续问“改模型、改 Prompt、改知识库如何保证不把问题带到线上”。这部分请接着使用 LLM 评测与发布门禁实战 回答版本化、离线门禁、灰度中止和回滚闭环。
若岗位偏 Java/Spring 后端，还应进一步说明 AI Orchestrator、SSE/WebFlux、领域事务、Tool Gateway 与异步 Job 的边界，见 Java / Spring AI 生产架构系统设计面试题。
本页面向大模型应用岗、Agent 工程岗、Java AI 工程岗和 AI Infra 岗的系统设计面试。它不重复“RAG 是什么、Agent 是什么”，而是训练你在白板上从业务目标、架构模块、数据流、权限、评测、成本和降级几个维度讲清一个可上线系统。
一、系统设计题通用答题框架
大模型系统设计题最怕两种回答：一种是直接报框架名，“用 LangChain + Milvus + GPT”；另一种是只画模型调用链，没有业务边界、权限和指标。更稳的结构如下：
| 步骤 | 你要说清楚什么 | 面试官想听什么 |
|---|---|---|
| 业务目标 | 谁用、解决什么流程、成功指标是什么 | 不是为了套技术，而是服务业务结果 |
| 范围边界 | 哪些自动化，哪些转人工，哪些不做 | 知道模型能力边界和风险边界 |
| 核心模块 | 接入层、编排层、检索层、工具层、模型层、评测监控 | 能拆成可维护的工程模块 |
| 数据流 | 请求如何经过权限、检索、工具、生成、校验、输出 | 能讲清在线链路和离线链路 |
| 质量指标 | 正确率、召回、忠实度、工具成功率、采纳率 | 不是靠主观感觉判断好坏 |
| 生产治理 | 日志、Trace、灰度、回滚、审计、成本、SLA | 能把 Demo 变成生产系统 |
一句话开场模板：
我会先把这个系统拆成在线请求链路、离线数据链路和运营治理链路。在线链路保证用户体验和权限安全，离线链路保证知识与评测持续更新，治理链路负责质量、成本、审计和回滚。
二、题一：设计企业级私有知识库 RAG 系统
场景
公司有制度文档、产品手册、合同模板、客服工单和 Wiki，希望做一个企业知识库助手。要求支持多部门权限、文档版本、引用溯源、无答案拒答和运营反馈。
核心架构
| 模块 | 职责 |
|---|---|
| 文档接入层 | 接入 PDF、Word、网页、Wiki、飞书、数据库导出 |
| 解析清洗层 | 标题层级、表格、附件、OCR、去噪、页码保留 |
| 索引构建层 | chunk、Embedding、BM25、元数据、摘要索引、父子索引 |
| 权限层 | tenant、department、role、doc_acl、version、effective_time |
| 检索层 | query rewrite、混合检索、元数据过滤、Rerank、上下文压缩 |
| 生成层 | 证据约束回答、引用编号、拒答、结构化输出 |
| 评测运营层 | bad case、Recall@K、faithfulness、引用命中、用户反馈 |
数据流
离线链路：
- 文档上传或同步。
- 解析正文、表格、图片和附件。
- 生成 chunk，并绑定文档来源、页码、标题路径、版本和权限。
- 写入向量索引、倒排索引和元数据索引。
- 抽样质检解析完整率、chunk 可读性、重复率和权限覆盖。
在线链路：
- 用户请求进入，解析身份、租户、部门和角色。
- query 改写和意图识别，但不能丢失原始问题。
- 检索前按 ACL、版本、生效时间做过滤。
- 向量 + BM25 多路召回，Rerank 后做二次权限校验。
- 生成回答，带引用、适用范围和拒答理由。
- 记录 query、召回列表、引用、答案、模型版本和用户反馈。
关键指标
- 数据侧：解析成功率、表格保真率、chunk 重复率、索引延迟。
- 检索侧：Recall@K、MRR、Context Precision、权限误召回率。
- 生成侧：faithfulness、引用命中率、无答案拒答正确率。
- 业务侧：问题解决率、转人工率、用户采纳率、投诉率。
- 成本侧：单问 token、Rerank 成本、索引重建成本、P95 延迟。
面试追问
追问：权限过滤放在哪里？
召回前或召回中必须做硬过滤，Rerank 和上下文构建前再二次校验。不能把越权内容送进模型后再要求模型不要泄露。
追问：表格和附件怎么处理？
表格保留行列关系、表头、页码和附件名。金额、条款号、日期适合关键词和元数据检索，语义问题适合向量检索。低置信 OCR 要拒答或人工复核。
追问：答案有引用但仍然错怎么办？
引用存在不代表结论被证据支持。要做引用覆盖检查、关键字段证据检查、冲突证据提示和人工抽检。
三、题二：设计 Agent 工具执行平台
场景
公司希望统一接入订单、CRM、工单、知识库、邮件、审批等工具，让不同 AI 应用可以安全调用。要求支持 Function Calling、MCP Server、工具权限、人工确认、幂等和审计。
核心架构
| 模块 | 职责 |
|---|---|
| Tool Registry | 管理工具名称、描述、Schema、版本、风险等级 |
| Policy Engine | 校验用户、租户、角色、资源、动作和风险 |
| Tool Gateway | 统一执行工具、超时、重试、熔断、限流 |
| Approval Service | 高风险动作的人审、二次确认、审批记录 |
| State Store | 保存 Agent 状态、checkpoint、operation_id |
| Audit Log | 记录工具调用、参数摘要、策略判断、结果 |
| Evaluation | 工具参数准确率、成功率、越权拦截率、回放测试 |
数据流
- 应用将用户请求和上下文传给 Agent 编排层。
- 模型根据工具 Schema 生成调用意图和参数。
- Tool Gateway 不直接执行，先请求 Policy Engine 校验。
- 只读工具可自动执行；写操作进入 prepare/confirm/commit。
- 高风险动作需要 approval_id、confirm_token 和 idempotency_key。
- 工具返回结构化结果：success、retryable_error、business_id、rollback_handle。
- Agent 根据 observation 更新状态，并决定继续、停止或转人工。
关键指标
- 工具选择准确率、参数填充准确率、工具成功率。
- 高风险动作确认率、越权拦截率、重复执行率。
- 工具 P95/P99 延迟、超时率、重试率。
- 人工接管率、错误动作率、审计回放成功率。
面试追问
追问：Function Calling 是否等于安全调用？
不是。Function Calling 只是把自然语言转成结构化参数，真正的权限、业务状态和副作用控制必须在服务端执行。
追问：服务重启后如何避免重复创建工单？
写操作必须有 idempotency_key 和 operation_id。checkpoint 恢复时先查询操作状态，不能盲目重放工具。
追问：MCP Server 工具 Schema 升级怎么办？
工具 Schema 要版本化，旧 trace 绑定旧 Schema。上线前跑回放测试，必要时做兼容层或迁移脚本。
四、题三：设计 DeepResearch 报告生成系统
场景
投研、法务或战略团队希望输入一个开放问题，系统自动拆解任务、搜索资料、筛选证据、生成带引用的长报告。要求来源可信、可复现、可控成本。
核心架构
| 模块 | 职责 |
|---|---|
| Planner | 拆分研究问题、生成子任务和搜索计划 |
| Search Gateway | 接入 Web、企业知识库、数据库、公告、研报 |
| Evidence Store | 保存来源、时间、作者、可信级别、引用片段 |
| Reader | 抽取观点、事实、数字、时间线和冲突信息 |
| Synthesizer | 生成大纲、段落、结论、风险和待验证问题 |
| Reviewer | 检查引用覆盖、时效、冲突、事实一致性 |
| Budget Controller | 控制搜索轮数、模型成本、token 和超时 |
数据流
- 用户输入研究主题和报告目标。
- Planner 拆成子问题，例如市场、竞品、政策、风险、结论。
- Search Gateway 按来源类型检索资料。
- Reader 抽取结构化证据，写入 Evidence Store。
- Reviewer 判断证据覆盖是否足够，不足则补检索。
- Synthesizer 生成报告，每个关键结论绑定引用。
- Reviewer 做二次核验，输出冲突来源和不确定性。
关键指标
- 关键结论证据覆盖率、引用命中率、过期引用率。
- 来源可信度分布、冲突证据标注率。
- 报告人工采纳率、人工修改率。
- 单报告成本、搜索轮数、生成耗时、失败率。
面试追问
追问：什么时候停止搜索？
结合证据覆盖、来源可信度、冲突数量、搜索轮数、成本和时间预算。证据不足时应输出“不足以判断”，不能硬凑结论。
追问：不同来源冲突怎么办？
不强行合并。展示来源口径、时间、统计范围和可信度差异，在结论里标注不确定性。
追问：如何复现一份报告？
保存搜索 query、来源快照、引用片段、模型版本、Prompt 版本、证据表和最终报告版本。
五、题四：设计 MaaS 模型网关平台
场景
公司多个业务应用直连不同模型 API，成本不可控、Key 管理混乱、日志分散。现在要建设 MaaS 平台，统一模型接入、路由、限流、计费、审计和安全治理。
核心架构
| 模块 | 职责 |
|---|---|
| Model Registry | 管理模型能力、上下文、价格、部署位置、合规等级 |
| API Gateway | 虚拟 Key、认证、限流、配额、租户隔离 |
| Router | 按场景、成本、延迟、质量、SLA 选择模型 |
| Prompt & Tool Adapter | 适配不同模型的 Prompt、工具调用和结构化输出 |
| Billing | token 计量、成本中心、预算、账单和告警 |
| Safety Layer | 内容安全、PII 脱敏、提示注入检测、拒答策略 |
| Observability | trace、TTFT、TPOT、错误率、fallback、route_reason |
数据流
- 业务应用用虚拟 Key 调 MaaS。
- Gateway 鉴权，检查租户、应用、配额和数据级别。
- Router 根据任务类型、SLA、模型健康、预算选择模型。
- Adapter 转换 Prompt、工具 Schema 和结构化输出约束。
- 请求发送到云模型或私有模型。
- 返回结果经过安全检查、格式校验和日志计量。
- Billing 汇总成本，Observability 生成质量和性能报告。
关键指标
- 平台侧：可用性、错误率、fallback 率、限流命中率。
- 性能侧：TTFT、TPOT、P95/P99、goodput。
- 成本侧：单应用成本、token 分布、预算超限率、缓存命中率。
- 质量侧：结构化输出成功率、工具调用兼容率、拒答正确率。
面试追问
追问：新模型榜单高，能否全量切？
不能。要按业务 golden set 验证 JSON、tool calling、拒答、长上下文、安全和成本，先影子流量，再低风险灰度。
追问：fallback 到备用模型后写错业务状态怎么办？
fallback 不是只要能回答。高风险工具调用 fallback 后可转人工或只读模式，不能静默执行。备用模型也要通过输出契约测试。
追问：账单突然涨 4 倍怎么排查？
按应用、租户、模型、Prompt 版本、路由策略拆输入 token、输出 token、调用量、重试、fallback、缓存命中和 RAG Top-K。
六、题五：设计大模型推理服务平台
场景
企业要私有化部署 Qwen/DeepSeek 等开源模型，服务在线客服、内部 Copilot 和离线报告生成。要求低延迟、高并发、成本可控、支持灰度和监控。
核心架构
| 模块 | 职责 |
|---|---|
| Serving Layer | vLLM/SGLang/TensorRT-LLM 模型服务 |
| Scheduler | 动态 batching、优先级队列、长短请求隔离 |
| Model Store | 模型权重、量化版本、LoRA adapter、版本元数据 |
| Gateway | 认证、限流、路由、超时、熔断 |
| Cache | prefix cache、语义缓存、热门回答缓存 |
| Monitor | GPU、显存、KV Cache、TTFT、TPOT、P95/P99 |
| Release | 灰度、回滚、A/B、模型兼容性评测 |
数据流
- 请求进入 Gateway，带应用、租户、模型、SLA。
- Router 判断在线交互、批量离线、长上下文或高风险任务。
- Scheduler 分配队列和 GPU 池。
- Serving Layer 执行 prefill 和 decode。
- 流式返回结果，同时记录 token、延迟、错误和显存指标。
- 监控发现异常后触发降级、限流或回滚。
关键指标
- TTFT、TPOT、P95/P99、吞吐、goodput。
- GPU 利用率、显存占用、KV Cache 使用率、OOM。
- 请求长度分布、排队时间、超时率、失败率。
- 单 token 成本、单请求成本、缓存命中率。
面试追问
追问：tokens/s 很高但用户说慢，为什么？
可能 TTFT 很差、排队时间长、长尾请求多或流式首字慢。交互式应用更关注 TTFT 和 P95/P99，不只看平均吞吐。
追问：在线客服和离线报告能否共用 GPU 池？
可以共享底层平台，但建议分队列、分优先级，必要时分 GPU 池。离线长上下文不能挤占在线 SLA。
追问：量化后怎么验收？
不仅看吞吐和显存，还要测结构化输出、拒答、安全、工具调用、长上下文和高风险业务集。保留 FP16 回滚路径。
七、题六：设计模型微调与评测平台
场景
公司希望支持业务团队基于历史工单、专家标注和 bad case 做 SFT/LoRA/QLoRA/DPO，并能统一管理数据、训练、评测、部署和回滚。
核心架构
| 模块 | 职责 |
|---|---|
| Dataset Hub | 数据接入、脱敏、去重、标注、版本管理 |
| Training Orchestrator | SFT、LoRA、QLoRA、DPO 任务编排 |
| Experiment Tracker | 记录超参、基座、adapter、数据版本、指标 |
| Eval Center | 事实、格式、拒答、安全、业务 golden set |
| Model Registry | 管理 base model、adapter、量化版本和状态 |
| Deployment | 合并/热加载 LoRA、灰度、路由、回滚 |
| Feedback Loop | 线上 bad case 回流评测集或训练集 |
数据流
- 线上日志和专家样本进入 Dataset Hub。
- 数据脱敏、去重、纠错、标注，划分 train/val/test。
- Training Orchestrator 启动训练任务。
- Eval Center 对比基座、Prompt/RAG 方案和微调模型。
- 通过门禁后进入 Model Registry。
- 灰度部署到目标场景，记录线上反馈。
- bad case 先进入评测集，稳定修正后再进入训练集。
关键指标
- 数据侧：重复率、脱敏覆盖率、标注一致性、泄漏风险。
- 训练侧：loss、训练成本、收敛稳定性、adapter 大小。
- 评测侧：任务准确率、格式遵循、拒答正确率、幻觉率。
- 线上侧：采纳率、投诉率、延迟、成本、回滚次数。
面试追问
追问：线上日志能直接做 SFT 数据吗？
不能。要脱敏、去重、纠错、过滤低质量样本，并由专家审核。错误回答不能直接训练进去。
追问：微调后事实正确率下降怎么办？
先判断是否把动态知识训练进权重。动态事实应优先走 RAG 和版本过滤，LoRA 更适合稳定风格、格式和领域表达。
追问：一个基座挂多个 LoRA 怎么管理？
请求显式绑定 tenant、app、task、adapter 和版本。缓存 key 包含 base model、adapter、Prompt 版本，异常可回滚到上一版 adapter 或基座。
八、题七：设计 LLMOps 质量与安全评测系统
场景
企业有多个 LLM 应用，质量和安全靠人工感觉判断，线上经常出现幻觉、越权、格式错、工具误调用。希望建设统一评测系统。
核心架构
| 模块 | 职责 |
|---|---|
| Case Repository | 管理 golden set、bad case、对抗样本、业务样本 |
| Eval Runner | 离线批量评测、回放 trace、模型对比 |
| Metrics Engine | 正确率、faithfulness、引用、拒答、工具成功率 |
| Judge Layer | 规则评测、人工评测、LLM-as-a-Judge |
| Safety Suite | 提示注入、越权、PII 泄露、敏感输出 |
| Report & Gate | 发布门禁、趋势报告、退化告警 |
| Feedback Loop | 线上日志抽样、人工标注、case 入库 |
数据流
- 从线上日志、人工反馈、事故复盘和业务样本收集 case。
- 对 case 打标签：场景、风险、期望行为、数据权限。
- Eval Runner 对不同模型、Prompt、RAG 配置和工具版本回放。
- Metrics Engine 计算质量、安全、成本和延迟指标。
- 低于门禁的版本不能发布。
- 上线后持续抽样，发现退化自动告警。
关键指标
- 正确率、引用支持率、拒答正确率、格式遵循率。
- 工具选择准确率、参数正确率、越权拦截率。
- 提示注入通过率、PII 泄露率、安全误拒率。
- 版本退化率、bad case 修复周期、线上投诉率。
面试追问
追问：LLM-as-a-Judge 能完全替代人工吗？
不能。它适合规模化初筛和趋势比较，高风险样本仍需人工标注。Judge 本身也要校准和抽检。
追问：bad case 直接进训练集吗？
不直接。bad case 先进入评测集和复盘流程，确认修正答案稳定、标注标准清晰后才可能进入训练集。
追问：如何评估 Agent 中间过程？
不能只看最终答案。要评估工具选择、参数、权限判断、中间状态、是否发生越权动作和是否进入循环。
九、题八：设计企业 AI 应用运营驾驶舱
场景
公司已经上线多个 AI 应用：客服助手、HR 知识库、销售 Copilot、投研 Agent。管理层希望看到质量、成本、风险和业务价值，研发希望快速定位问题。
核心架构
| 模块 | 职责 |
|---|---|
| Event Collector | 收集请求、模型、检索、工具、反馈、成本事件 |
| Trace Store | 保存链路 trace、版本、输入输出摘要 |
| Metrics Warehouse | 按应用、租户、模型、版本聚合指标 |
| Dashboard | 质量、成本、延迟、安全、业务价值看板 |
| Alerting | 成本异常、质量退化、错误率、越权风险告警 |
| Drilldown | 从指标下钻到 case、trace、召回文档和工具调用 |
数据流
- 每次请求生成 trace_id。
- RAG、模型、工具、评测、用户反馈都上报事件。
- 数据进入实时指标和离线数仓。
- Dashboard 展示趋势和分桶指标。
- 异常告警触发负责人排查。
- 工程师从指标下钻到具体 bad case 和链路。
关键指标
- 业务：采纳率、自动解决率、转人工率、处理时长、满意度。
- 质量：正确率、拒答、引用、工具成功、bad case 数量。
- 成本：token、模型单价、重试、fallback、缓存命中。
- 性能：TTFT、TPOT、P95/P99、错误率。
- 安全：越权拦截、提示注入、敏感输出、审计覆盖。
面试追问
追问：管理层看什么，研发看什么？
管理层看业务价值、成本和风险趋势；研发看 trace、版本、召回、Prompt、模型、工具和错误码。
追问：如何定位成本异常？
按应用、租户、模型、Prompt 版本、路由策略、输入输出 token、重试和缓存命中分解。
追问：如何避免只做漂亮看板？
看板必须能下钻到 case 和 trace，并能触发评测、回滚、限流或负责人处理动作。
十、题九：设计多模态文档 RAG 系统
场景
投研、法务或财务团队上传财报、招股书、合同、扫描版 PDF 和图片资料，用户希望询问“过去三年毛利率变化依据是什么”“合同附件价格表第 3 行如何解释”。系统要理解表格、图表、页码、脚注和扫描件。
核心架构
| 模块 | 职责 |
|---|---|
| Document Classifier | 判断页面类型：正文、表格、图表、扫描页、附件 |
| OCR/VLM Parser | OCR、版面分析、图表说明生成、图片理解 |
| Table Extractor | 保留行列关系、表头、单位、页码和附件路径 |
| Visual Retriever | 页面级视觉 embedding 或 ColPali 类视觉检索 |
| Text Retriever | 文本 chunk、BM25、向量检索、元数据过滤 |
| Evidence Aligner | 把答案字段对齐到页码、表格行、图表编号 |
| Review Queue | 低置信 OCR、关键金额、法律条款人工复核 |
数据流
- 文档入库后按页面类型分流。
- 文本页走结构化解析，表格页保留行列和单位，图表页生成 caption 或视觉向量。
- 每个证据单元绑定文档名、版本、页码、区域坐标、表格行列、附件名。
- 查询时先判断是文本条款、表格数值、图表理解还是跨页汇总。
- 路由到文本检索、表格检索或视觉检索。
- 生成答案时要求引用到页码、表格行或图表编号。
- 低置信或高风险字段进入人工复核。
关键指标
- OCR 字符准确率、表格字段抽取准确率、图表问答准确率。
- 视觉检索 Hit Rate、页码定位准确率、引用粒度达标率。
- 关键字段人工复核率、低置信拒答正确率。
- VLM 成本、P95 延迟、单文档索引耗时。
面试追问
追问：什么时候用 OCR + 文本 RAG，什么时候用视觉检索？
可文本化且结构稳定的文档优先 OCR + 文本 RAG；复杂版面、图表、扫描质量差或需要页面视觉布局时考虑视觉检索。
追问：表格被切碎后怎么恢复语义？
表格不应按普通段落切分。需要保留表头、行列、单位、页码、附件路径，并把单元格与上下文标题绑定。
追问：图表结论和正文描述冲突怎么办？
输出冲突来源和口径差异，不让模型强行合并。高风险结论进入人工复核。
十一、题十：设计 GraphRAG 企业关系分析系统
场景
风控或战略团队需要分析企业、股东、高管、项目、合同、诉讼、供应商之间的关系，支持“某供应商和高风险主体有哪些间接关联”这类多跳问题。
核心架构
| 模块 | 职责 |
|---|---|
| Entity Extractor | 抽取企业、人、项目、合同、案件等实体 |
| Relation Extractor | 抽取持股、任职、交易、诉讼、供应关系 |
| Entity Resolution | 别名、重名、统一社会信用代码、同名人消歧 |
| Graph Store | 存储实体、关系、时间、置信度和来源 |
| Community Summary | 社区发现、子图摘要、全局关系摘要 |
| Graph Retriever | 邻域检索、路径搜索、多跳查询、社区检索 |
| Evidence Binder | 每条边绑定原文证据和来源 |
数据流
- 从公告、工商数据、合同、新闻和内部文档抽取实体关系。
- 实体消歧后写入图数据库，每条边绑定来源片段。
- 对大图做社区检测和摘要。
- 查询时识别实体、关系类型和跳数约束。
- 局部问题走邻域子图，多跳问题走路径搜索，全局问题走社区摘要。
- 生成结论时展示关系路径、证据来源和置信度。
关键指标
- 实体识别准确率、实体消歧准确率、关系抽取准确率。
- 多跳路径召回率、路径可解释性、证据覆盖率。
- 图更新延迟、社区摘要新鲜度、错误关系修复周期。
面试追问
追问：GraphRAG 什么时候比普通 RAG 值得？
当问题核心是实体关系、多跳路径、网络结构或全局社区摘要时值得。普通文档问答不必上 GraphRAG。
追问：如何防止模型把相关说成因果？
关系类型和结论级别要受控，输出“关联、交易、任职、疑似、证据不足”等标签，不把路径关联解释成因果。
追问：图上的边如何绑定证据？
每条边保存来源文档、页码、原文片段、抽取模型、置信度和更新时间，答案引用边时回填证据。
十二、题十一：设计带长期记忆的团队 Agent 助理
场景
企业要做一个工作助理，能记住用户偏好、项目背景、会议结论和常用流程，帮助查询资料、生成待办和准备周报，但不能错误记忆或泄露跨团队信息。
核心架构
| 模块 | 职责 |
|---|---|
| Short-term State | 保存当前任务目标、工具结果、临时上下文 |
| Memory Extractor | 从对话和工具结果抽取候选长期记忆 |
| Memory Gate | 判断稳定性、敏感性、冲突、权限和 TTL |
| Memory Store | 存储 owner、scope、source、confidence、expires_at |
| Memory Retriever | 按用户、项目、任务和时间召回记忆 |
| User Control | 查看、编辑、删除、禁用记忆 |
| Audit | 记录写入、读取、删除和注入原因 |
数据流
- 对话和工具结果先进入短期状态。
- 会话结束或用户显式要求时生成候选记忆。
- Memory Gate 检查是否稳定、是否敏感、是否与旧记忆冲突。
- 通过后写入长期记忆，并绑定用户、团队、项目和来源。
- 新任务开始时按 query 和权限召回相关记忆。
- 记忆注入到专门 memory 区块，不能覆盖系统指令和安全策略。
- 用户删除记忆后，同步从检索索引、缓存和可生成上下文中移除。
关键指标
- Memory Recall、误写率、冲突率、过期记忆注入率。
- 敏感记忆误存率、跨用户误注入率、用户删除成功率。
- 记忆检索延迟、注入 token 占比、用户采纳率。
面试追问
追问：为什么不能把所有聊天记录都写进向量库？
聊天里有临时指令、错误信息、敏感数据和过期上下文。长期记忆必须经过写入门禁和用户控制。
追问：本轮指令和旧记忆冲突时谁优先？
系统策略最高，本轮明确指令优先于旧记忆，安全合规规则优先于用户偏好。
追问：用户删除记忆后怎么办？
删除长期存储、向量索引和可生成缓存；审计日志按合规要求保留摘要，但不能继续用于个性化生成。
十三、题十二：设计 Dify 工作流生产化治理平台
场景
业务团队用 Dify 搭出合同问答、审批前置检查、运营文案生成等 PoC，效果不错。公司希望把这些工作流纳入统一生产治理，而不是让每个业务随意发布。
核心架构
| 模块 | 职责 |
|---|---|
| App Catalog | 记录 Dify 应用、负责人、风险等级、使用范围 |
| Version Manager | Workflow、Prompt、知识库、工具配置版本 |
| Eval Runner | 发布前运行 golden set、安全集、权限集 |
| Tool Proxy | 统一工具鉴权、限流、审计和密钥管理 |
| Release Gate | 审批、灰度、回滚、变更记录 |
| Runtime Collector | 节点延迟、token、命中文档、工具调用、输出 |
| Migration Layer | 将高风险链路迁移到后端服务或 LangGraph |
数据流
- 业务在 Dify 创建应用。
- 平台登记 app、workflow、prompt、knowledge、tool 版本。
- 发布前跑评测集和权限集。
- 通过审批后按部门或用户组灰度。
- 运行时采集节点级日志、成本、工具调用和用户反馈。
- 质量或成本异常时回滚到上个版本。
- 复杂状态机或高危写操作迁移到后端服务。
关键指标
- 评测集通过率、Prompt 回归退化率、节点失败率。
- 节点 P95 延迟、单流程 token 成本、知识库命中率。
- 工具调用成功率、灰度回滚次数、人工修正率。
面试追问
追问：Dify 为什么不一定适合核心生产链路？
核心链路常需要复杂权限、强审计、高并发、事务一致性和深度定制评测，低代码平台适合 PoC 和运营配置，但不应承载全部风险。
追问：哪些能力可以留在 Dify？
低风险问答、Prompt 配置、运营工作流、业务试验可保留；高风险工具执行、复杂状态机、统一权限和审计建议后端化。
追问：Dify Tool 节点的鉴权在哪里做？
服务端 Tool Proxy 或业务服务中做硬校验，不能只依赖 Dify 画布配置。
十四、题十三：设计 LLM 成本治理与 FinOps 平台
场景
公司模型调用规模快速增长，外部 API、私有化 GPU、RAG、Agent 和微调模型都有成本。管理层希望看清谁在花钱、为什么花钱、是否有效，并能设置预算、告警和优化策略。
核心架构
| 模块 | 职责 |
|---|---|
| Cost Collector | 采集 Gateway、推理集群、RAG、Agent、训练任务成本事件 |
| Token Metering | input/output token、cache、fallback、retry、route_type |
| Cost Warehouse | 按租户、应用、模型、场景、版本聚合 |
| Budget Engine | 部门预算、项目预算、日/月额度、审批流 |
| Optimization Engine | 缓存建议、小模型路由、错峰、量化、上下文压缩 |
| Alert & Policy | 异常告警、预算熔断、降级策略 |
| ROI Dashboard | 成本、质量、采纳率、自动解决率联动分析 |
数据流
- 每次模型调用生成 cost_event。
- cost_event 记录 tenant、app、model、prompt_version、tokens、unit_price、cache_status。
- 私有化推理补充 GPU 小时、goodput、空闲率和摊销成本。
- 成本数据进入仓库，按部门、应用、模型、场景聚合。
- Budget Engine 判断是否超预算、是否需要审批或熔断。
- Optimization Engine 根据高成本模式生成治理建议。
- Dashboard 同时展示成本、质量和业务价值。
关键指标
- 每应用/部门/租户成本、每百万有效 token 成本。
- output token 占比、缓存命中率、fallback/retry 成本占比。
- 预算使用率、超预算拦截率、异常成本发现时延。
- 每解决工单成本、每采纳建议成本、成本优化后质量退化率。
面试追问
追问：为什么 output token 成本通常更关键？
输出 token 生成更慢，直接影响 decode 时长和推理成本；很多账单也按输入输出不同价格计费。
追问：成本治理为什么不能简单要求业务少用模型？
目标是单位业务价值更高，不是压制使用。要结合质量、效率、采纳率和人工节省判断。
追问：缓存降本如何避免越权？
缓存 key 必须包含 tenant、用户权限、模型、Prompt、知识库版本和安全策略，不能跨权限复用答案。
十五、题十四：设计混合云模型路由与合规治理平台
场景
企业同时使用外部模型 API、国内云模型、私有化 vLLM 集群和行业专用模型。不同业务有不同数据等级：公开数据、内部数据、个人信息、金融敏感数据。平台需要在成本、效果、延迟和合规之间自动选择通道。
核心架构
| 模块 | 职责 |
|---|---|
| Data Classifier | 识别数据等级、PII、行业敏感字段 |
| Compliance Policy Engine | 数据出境、租户规则、审批策略 |
| Model Channel Registry | 外部 API、国内云、私有化、专线、禁用场景 |
| Routing Engine | 合规优先，再按质量、延迟、成本选模型 |
| Redaction Layer | PII 脱敏、日志脱敏、字段屏蔽 |
| Audit Store | 请求摘要、策略命中、审批记录、模型通道 |
| Eval & Drift | 不同通道质量、成本、拒答和格式兼容性评测 |
数据流
- 请求进入平台后先做租户识别和数据分类。
- Policy Engine 判断能否出境、能否走外部 API、是否要审批。
- Redaction Layer 对允许脱敏后外发的字段做处理。
- Routing Engine 在合规可用通道中选择模型。
- 模型响应经过安全检查和格式校验后返回业务。
- Audit Store 记录策略版本、模型通道、脱敏动作和审批结果。
- 定期用评测集比较不同通道的质量、延迟、成本和误拒率。
关键指标
- 合规策略命中率、违规外发拦截率。
- PII 检出率、脱敏覆盖率、日志脱敏完整率。
- 各通道成本、延迟、质量、可用性。
- 审批时长、人工介入率、策略误拦率。
面试追问
追问：合规路由应该在模型调用前还是调用后做？
必须在调用前做，避免敏感数据已经外发。调用后只能做输出审查，不能弥补输入外发。
追问：脱敏后调用外部模型如何证明不影响业务质量？
准备脱敏前后对比评测集，验证字段遮蔽后任务准确率、拒答和格式是否满足要求。
追问：审计日志保存原文还是摘要？
按数据等级决定。高敏场景保存脱敏摘要、哈希、策略命中和必要证据，避免日志本身成为泄露源。
十六、系统设计题收尾话术
面试回答最后可以用这段收束：
我会把这个系统当成一个长期运营的工程系统，而不是一次模型调用。上线前用 golden set 和灰度验证质量，上线后用 trace、指标和 bad case 驱动迭代。RAG 负责证据，Agent 负责动态步骤，工具层负责确定性执行，MaaS 负责模型治理，评测和监控负责持续守住质量、成本和安全边界。