LLMGuide

主题

L2 工程应用开发 / 后端转型约 23 分钟
初次分级 · 待核实 ↗

大模型应用系统设计面试题 ​

设计完成后，面试官通常会继续问“改模型、改 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、引用命中、用户反馈

数据流 ​

离线链路：

  1. 文档上传或同步。
  2. 解析正文、表格、图片和附件。
  3. 生成 chunk，并绑定文档来源、页码、标题路径、版本和权限。
  4. 写入向量索引、倒排索引和元数据索引。
  5. 抽样质检解析完整率、chunk 可读性、重复率和权限覆盖。

在线链路：

  1. 用户请求进入，解析身份、租户、部门和角色。
  2. query 改写和意图识别，但不能丢失原始问题。
  3. 检索前按 ACL、版本、生效时间做过滤。
  4. 向量 + BM25 多路召回，Rerank 后做二次权限校验。
  5. 生成回答，带引用、适用范围和拒答理由。
  6. 记录 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工具参数准确率、成功率、越权拦截率、回放测试

数据流 ​

  1. 应用将用户请求和上下文传给 Agent 编排层。
  2. 模型根据工具 Schema 生成调用意图和参数。
  3. Tool Gateway 不直接执行，先请求 Policy Engine 校验。
  4. 只读工具可自动执行；写操作进入 prepare/confirm/commit。
  5. 高风险动作需要 approval_id、confirm_token 和 idempotency_key。
  6. 工具返回结构化结果：success、retryable_error、business_id、rollback_handle。
  7. 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 和超时

数据流 ​

  1. 用户输入研究主题和报告目标。
  2. Planner 拆成子问题，例如市场、竞品、政策、风险、结论。
  3. Search Gateway 按来源类型检索资料。
  4. Reader 抽取结构化证据，写入 Evidence Store。
  5. Reviewer 判断证据覆盖是否足够，不足则补检索。
  6. Synthesizer 生成报告，每个关键结论绑定引用。
  7. Reviewer 做二次核验，输出冲突来源和不确定性。

关键指标 ​

  • 关键结论证据覆盖率、引用命中率、过期引用率。
  • 来源可信度分布、冲突证据标注率。
  • 报告人工采纳率、人工修改率。
  • 单报告成本、搜索轮数、生成耗时、失败率。

面试追问 ​

追问：什么时候停止搜索？
结合证据覆盖、来源可信度、冲突数量、搜索轮数、成本和时间预算。证据不足时应输出“不足以判断”，不能硬凑结论。

追问：不同来源冲突怎么办？
不强行合并。展示来源口径、时间、统计范围和可信度差异，在结论里标注不确定性。

追问：如何复现一份报告？
保存搜索 query、来源快照、引用片段、模型版本、Prompt 版本、证据表和最终报告版本。

五、题四：设计 MaaS 模型网关平台 ​

场景 ​

公司多个业务应用直连不同模型 API，成本不可控、Key 管理混乱、日志分散。现在要建设 MaaS 平台，统一模型接入、路由、限流、计费、审计和安全治理。

核心架构 ​

模块职责
Model Registry管理模型能力、上下文、价格、部署位置、合规等级
API Gateway虚拟 Key、认证、限流、配额、租户隔离
Router按场景、成本、延迟、质量、SLA 选择模型
Prompt & Tool Adapter适配不同模型的 Prompt、工具调用和结构化输出
Billingtoken 计量、成本中心、预算、账单和告警
Safety Layer内容安全、PII 脱敏、提示注入检测、拒答策略
Observabilitytrace、TTFT、TPOT、错误率、fallback、route_reason

数据流 ​

  1. 业务应用用虚拟 Key 调 MaaS。
  2. Gateway 鉴权，检查租户、应用、配额和数据级别。
  3. Router 根据任务类型、SLA、模型健康、预算选择模型。
  4. Adapter 转换 Prompt、工具 Schema 和结构化输出约束。
  5. 请求发送到云模型或私有模型。
  6. 返回结果经过安全检查、格式校验和日志计量。
  7. 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 LayervLLM/SGLang/TensorRT-LLM 模型服务
Scheduler动态 batching、优先级队列、长短请求隔离
Model Store模型权重、量化版本、LoRA adapter、版本元数据
Gateway认证、限流、路由、超时、熔断
Cacheprefix cache、语义缓存、热门回答缓存
MonitorGPU、显存、KV Cache、TTFT、TPOT、P95/P99
Release灰度、回滚、A/B、模型兼容性评测

数据流 ​

  1. 请求进入 Gateway，带应用、租户、模型、SLA。
  2. Router 判断在线交互、批量离线、长上下文或高风险任务。
  3. Scheduler 分配队列和 GPU 池。
  4. Serving Layer 执行 prefill 和 decode。
  5. 流式返回结果，同时记录 token、延迟、错误和显存指标。
  6. 监控发现异常后触发降级、限流或回滚。

关键指标 ​

  • 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 OrchestratorSFT、LoRA、QLoRA、DPO 任务编排
Experiment Tracker记录超参、基座、adapter、数据版本、指标
Eval Center事实、格式、拒答、安全、业务 golden set
Model Registry管理 base model、adapter、量化版本和状态
Deployment合并/热加载 LoRA、灰度、路由、回滚
Feedback Loop线上 bad case 回流评测集或训练集

数据流 ​

  1. 线上日志和专家样本进入 Dataset Hub。
  2. 数据脱敏、去重、纠错、标注，划分 train/val/test。
  3. Training Orchestrator 启动训练任务。
  4. Eval Center 对比基座、Prompt/RAG 方案和微调模型。
  5. 通过门禁后进入 Model Registry。
  6. 灰度部署到目标场景，记录线上反馈。
  7. 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 入库

数据流 ​

  1. 从线上日志、人工反馈、事故复盘和业务样本收集 case。
  2. 对 case 打标签：场景、风险、期望行为、数据权限。
  3. Eval Runner 对不同模型、Prompt、RAG 配置和工具版本回放。
  4. Metrics Engine 计算质量、安全、成本和延迟指标。
  5. 低于门禁的版本不能发布。
  6. 上线后持续抽样，发现退化自动告警。

关键指标 ​

  • 正确率、引用支持率、拒答正确率、格式遵循率。
  • 工具选择准确率、参数正确率、越权拦截率。
  • 提示注入通过率、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、召回文档和工具调用

数据流 ​

  1. 每次请求生成 trace_id。
  2. RAG、模型、工具、评测、用户反馈都上报事件。
  3. 数据进入实时指标和离线数仓。
  4. Dashboard 展示趋势和分桶指标。
  5. 异常告警触发负责人排查。
  6. 工程师从指标下钻到具体 bad case 和链路。

关键指标 ​

  • 业务：采纳率、自动解决率、转人工率、处理时长、满意度。
  • 质量：正确率、拒答、引用、工具成功、bad case 数量。
  • 成本：token、模型单价、重试、fallback、缓存命中。
  • 性能：TTFT、TPOT、P95/P99、错误率。
  • 安全：越权拦截、提示注入、敏感输出、审计覆盖。

面试追问 ​

追问：管理层看什么，研发看什么？
管理层看业务价值、成本和风险趋势；研发看 trace、版本、召回、Prompt、模型、工具和错误码。

追问：如何定位成本异常？
按应用、租户、模型、Prompt 版本、路由策略、输入输出 token、重试和缓存命中分解。

追问：如何避免只做漂亮看板？
看板必须能下钻到 case 和 trace，并能触发评测、回滚、限流或负责人处理动作。

十、题九：设计多模态文档 RAG 系统 ​

场景 ​

投研、法务或财务团队上传财报、招股书、合同、扫描版 PDF 和图片资料，用户希望询问“过去三年毛利率变化依据是什么”“合同附件价格表第 3 行如何解释”。系统要理解表格、图表、页码、脚注和扫描件。

核心架构 ​

模块职责
Document Classifier判断页面类型：正文、表格、图表、扫描页、附件
OCR/VLM ParserOCR、版面分析、图表说明生成、图片理解
Table Extractor保留行列关系、表头、单位、页码和附件路径
Visual Retriever页面级视觉 embedding 或 ColPali 类视觉检索
Text Retriever文本 chunk、BM25、向量检索、元数据过滤
Evidence Aligner把答案字段对齐到页码、表格行、图表编号
Review Queue低置信 OCR、关键金额、法律条款人工复核

数据流 ​

  1. 文档入库后按页面类型分流。
  2. 文本页走结构化解析，表格页保留行列和单位，图表页生成 caption 或视觉向量。
  3. 每个证据单元绑定文档名、版本、页码、区域坐标、表格行列、附件名。
  4. 查询时先判断是文本条款、表格数值、图表理解还是跨页汇总。
  5. 路由到文本检索、表格检索或视觉检索。
  6. 生成答案时要求引用到页码、表格行或图表编号。
  7. 低置信或高风险字段进入人工复核。

关键指标 ​

  • OCR 字符准确率、表格字段抽取准确率、图表问答准确率。
  • 视觉检索 Hit Rate、页码定位准确率、引用粒度达标率。
  • 关键字段人工复核率、低置信拒答正确率。
  • VLM 成本、P95 延迟、单文档索引耗时。

面试追问 ​

追问：什么时候用 OCR + 文本 RAG，什么时候用视觉检索？
可文本化且结构稳定的文档优先 OCR + 文本 RAG；复杂版面、图表、扫描质量差或需要页面视觉布局时考虑视觉检索。

追问：表格被切碎后怎么恢复语义？
表格不应按普通段落切分。需要保留表头、行列、单位、页码、附件路径，并把单元格与上下文标题绑定。

追问：图表结论和正文描述冲突怎么办？
输出冲突来源和口径差异，不让模型强行合并。高风险结论进入人工复核。

十一、题十：设计 GraphRAG 企业关系分析系统 ​

场景 ​

风控或战略团队需要分析企业、股东、高管、项目、合同、诉讼、供应商之间的关系，支持“某供应商和高风险主体有哪些间接关联”这类多跳问题。

核心架构 ​

模块职责
Entity Extractor抽取企业、人、项目、合同、案件等实体
Relation Extractor抽取持股、任职、交易、诉讼、供应关系
Entity Resolution别名、重名、统一社会信用代码、同名人消歧
Graph Store存储实体、关系、时间、置信度和来源
Community Summary社区发现、子图摘要、全局关系摘要
Graph Retriever邻域检索、路径搜索、多跳查询、社区检索
Evidence Binder每条边绑定原文证据和来源

数据流 ​

  1. 从公告、工商数据、合同、新闻和内部文档抽取实体关系。
  2. 实体消歧后写入图数据库，每条边绑定来源片段。
  3. 对大图做社区检测和摘要。
  4. 查询时识别实体、关系类型和跳数约束。
  5. 局部问题走邻域子图，多跳问题走路径搜索，全局问题走社区摘要。
  6. 生成结论时展示关系路径、证据来源和置信度。

关键指标 ​

  • 实体识别准确率、实体消歧准确率、关系抽取准确率。
  • 多跳路径召回率、路径可解释性、证据覆盖率。
  • 图更新延迟、社区摘要新鲜度、错误关系修复周期。

面试追问 ​

追问：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记录写入、读取、删除和注入原因

数据流 ​

  1. 对话和工具结果先进入短期状态。
  2. 会话结束或用户显式要求时生成候选记忆。
  3. Memory Gate 检查是否稳定、是否敏感、是否与旧记忆冲突。
  4. 通过后写入长期记忆，并绑定用户、团队、项目和来源。
  5. 新任务开始时按 query 和权限召回相关记忆。
  6. 记忆注入到专门 memory 区块，不能覆盖系统指令和安全策略。
  7. 用户删除记忆后，同步从检索索引、缓存和可生成上下文中移除。

关键指标 ​

  • Memory Recall、误写率、冲突率、过期记忆注入率。
  • 敏感记忆误存率、跨用户误注入率、用户删除成功率。
  • 记忆检索延迟、注入 token 占比、用户采纳率。

面试追问 ​

追问：为什么不能把所有聊天记录都写进向量库？
聊天里有临时指令、错误信息、敏感数据和过期上下文。长期记忆必须经过写入门禁和用户控制。

追问：本轮指令和旧记忆冲突时谁优先？
系统策略最高，本轮明确指令优先于旧记忆，安全合规规则优先于用户偏好。

追问：用户删除记忆后怎么办？
删除长期存储、向量索引和可生成缓存；审计日志按合规要求保留摘要，但不能继续用于个性化生成。

十三、题十二：设计 Dify 工作流生产化治理平台 ​

场景 ​

业务团队用 Dify 搭出合同问答、审批前置检查、运营文案生成等 PoC，效果不错。公司希望把这些工作流纳入统一生产治理，而不是让每个业务随意发布。

核心架构 ​

模块职责
App Catalog记录 Dify 应用、负责人、风险等级、使用范围
Version ManagerWorkflow、Prompt、知识库、工具配置版本
Eval Runner发布前运行 golden set、安全集、权限集
Tool Proxy统一工具鉴权、限流、审计和密钥管理
Release Gate审批、灰度、回滚、变更记录
Runtime Collector节点延迟、token、命中文档、工具调用、输出
Migration Layer将高风险链路迁移到后端服务或 LangGraph

数据流 ​

  1. 业务在 Dify 创建应用。
  2. 平台登记 app、workflow、prompt、knowledge、tool 版本。
  3. 发布前跑评测集和权限集。
  4. 通过审批后按部门或用户组灰度。
  5. 运行时采集节点级日志、成本、工具调用和用户反馈。
  6. 质量或成本异常时回滚到上个版本。
  7. 复杂状态机或高危写操作迁移到后端服务。

关键指标 ​

  • 评测集通过率、Prompt 回归退化率、节点失败率。
  • 节点 P95 延迟、单流程 token 成本、知识库命中率。
  • 工具调用成功率、灰度回滚次数、人工修正率。

面试追问 ​

追问：Dify 为什么不一定适合核心生产链路？
核心链路常需要复杂权限、强审计、高并发、事务一致性和深度定制评测，低代码平台适合 PoC 和运营配置，但不应承载全部风险。

追问：哪些能力可以留在 Dify？
低风险问答、Prompt 配置、运营工作流、业务试验可保留；高风险工具执行、复杂状态机、统一权限和审计建议后端化。

追问：Dify Tool 节点的鉴权在哪里做？
服务端 Tool Proxy 或业务服务中做硬校验，不能只依赖 Dify 画布配置。

十四、题十三：设计 LLM 成本治理与 FinOps 平台 ​

场景 ​

公司模型调用规模快速增长，外部 API、私有化 GPU、RAG、Agent 和微调模型都有成本。管理层希望看清谁在花钱、为什么花钱、是否有效，并能设置预算、告警和优化策略。

核心架构 ​

模块职责
Cost Collector采集 Gateway、推理集群、RAG、Agent、训练任务成本事件
Token Meteringinput/output token、cache、fallback、retry、route_type
Cost Warehouse按租户、应用、模型、场景、版本聚合
Budget Engine部门预算、项目预算、日/月额度、审批流
Optimization Engine缓存建议、小模型路由、错峰、量化、上下文压缩
Alert & Policy异常告警、预算熔断、降级策略
ROI Dashboard成本、质量、采纳率、自动解决率联动分析

数据流 ​

  1. 每次模型调用生成 cost_event。
  2. cost_event 记录 tenant、app、model、prompt_version、tokens、unit_price、cache_status。
  3. 私有化推理补充 GPU 小时、goodput、空闲率和摊销成本。
  4. 成本数据进入仓库，按部门、应用、模型、场景聚合。
  5. Budget Engine 判断是否超预算、是否需要审批或熔断。
  6. Optimization Engine 根据高成本模式生成治理建议。
  7. 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 LayerPII 脱敏、日志脱敏、字段屏蔽
Audit Store请求摘要、策略命中、审批记录、模型通道
Eval & Drift不同通道质量、成本、拒答和格式兼容性评测

数据流 ​

  1. 请求进入平台后先做租户识别和数据分类。
  2. Policy Engine 判断能否出境、能否走外部 API、是否要审批。
  3. Redaction Layer 对允许脱敏后外发的字段做处理。
  4. Routing Engine 在合规可用通道中选择模型。
  5. 模型响应经过安全检查和格式校验后返回业务。
  6. Audit Store 记录策略版本、模型通道、脱敏动作和审批结果。
  7. 定期用评测集比较不同通道的质量、延迟、成本和误拒率。

关键指标 ​

  • 合规策略命中率、违规外发拦截率。
  • PII 检出率、脱敏覆盖率、日志脱敏完整率。
  • 各通道成本、延迟、质量、可用性。
  • 审批时长、人工介入率、策略误拦率。

面试追问 ​

追问：合规路由应该在模型调用前还是调用后做？
必须在调用前做，避免敏感数据已经外发。调用后只能做输出审查，不能弥补输入外发。

追问：脱敏后调用外部模型如何证明不影响业务质量？
准备脱敏前后对比评测集，验证字段遮蔽后任务准确率、拒答和格式是否满足要求。

追问：审计日志保存原文还是摘要？
按数据等级决定。高敏场景保存脱敏摘要、哈希、策略命中和必要证据，避免日志本身成为泄露源。

十六、系统设计题收尾话术 ​

面试回答最后可以用这段收束：

我会把这个系统当成一个长期运营的工程系统，而不是一次模型调用。上线前用 golden set 和灰度验证质量，上线后用 trace、指标和 bad case 驱动迭代。RAG 负责证据，Agent 负责动态步骤，工具层负责确定性执行，MaaS 负责模型治理，评测和监控负责持续守住质量、成本和安全边界。

继续阅读 ​

基于 MIT 许可发布

Copyright © 2026 Meko1 · 大模型面试指南