大模型应用实战场景题库

本页面向真实面试中的“场景设计题”和“项目追问题”。它不是再解释 RAG、Agent、MaaS 的定义，而是把面试官常给的业务场景拆成考察点、答题骨架、扣分点和连续追问。建议和 大模型应用实战高频追问 一起使用：先刷本页场景，再用追问链补细节。

一、场景题答题总模板

遇到开放场景题时，不要急着报技术栈。更稳的顺序是：

1. 确认业务目标：谁用、解决什么流程、指标是什么。
2. 拆链路：输入、权限、检索、工具、状态、生成、审核、输出。
3. 给架构取舍：为什么用 RAG、Agent、工作流、微调或 MaaS。
4. 说失败模式：召回差、工具错、越权、幻觉、延迟、成本。
5. 说治理闭环：评测、日志、监控、灰度、回滚、人工兜底。

一句话模板：

我会先把这个问题拆成业务指标、数据边界、模型链路和上线治理四层。技术上不先选框架，而是先判断事实知识是否变化、流程是否固定、是否有副作用动作、是否需要审计，然后再决定用 RAG、工作流、Agent、微调或模型网关组合。

二、RAG 与知识库场景题

场景 1：企业知识库答非所问，业务说“向量库不行”

题目场景
公司搭了一个企业知识库，用户问“出差报销酒店标准”，系统召回了“差旅申请流程”和“住宿安全须知”，答案看起来相关但没有给出金额标准。业务认为向量库效果差，要求换数据库或换 Embedding 模型。

考察点

• 能否把 RAG 问题拆成数据、切分、召回、排序、生成几个环节。
• 能否避免把所有问题归因到向量库。
• 是否知道关键词、元数据和权限在企业知识库里的重要性。

答题骨架

1. 先看原始文档是否包含“酒店标准”这类结构化信息。
2. 再看解析是否保留表格、地区、职级、时间和版本。
3. 再看 chunk 是否把“标准金额”和“适用条件”切散。
4. 召回层比较向量召回、BM25、混合检索、元数据过滤。
5. 排序层看 Rerank 是否把金额标准排到前面。
6. 生成层检查 Prompt 是否要求按地区/职级回答并引用来源。
7. 建立 bad case 集，用 Recall@K、MRR、引用命中率和人工正确率验证修复。

常见扣分点

• 直接说“换更好的 Embedding”。
• 只讲 Top-K，不看文档解析和表格结构。
• 不提版本、地区、职级、权限等元数据。
• 不用评测集证明优化有效。

连续追问

追问：如果正确文档召回到了，但答案仍然没有金额？
检查正确 chunk 是否被放进最终上下文，是否被噪声片段挤掉，Prompt 是否要求按字段抽取，模型是否忽略表格。可以加 Rerank、上下文压缩、表格结构化和引用覆盖检查。

追问：如果不同地区标准不同怎么办？
不要只靠语义相似度。要把地区、职级、时间、政策版本做成元数据过滤条件，召回时先过滤再排序，答案里显示适用范围。

场景 2：知识库必须支持权限隔离和版本追溯

题目场景
同一套 HR 知识库要给总部、分公司、外包员工、正式员工使用。不同人能看到的政策不同，旧政策要可追溯但不能默认回答。

考察点

• 是否知道权限过滤要在召回前或召回中完成。
• 是否能设计文档版本、生效时间和审计链路。
• 是否能区分“可追溯”和“默认可见”。

答题骨架

1. 文档入库时写入 tenant、department、role、region、version、effective_time、expire_time、acl。
2. 用户请求进入时解析身份和权限上下文。
3. 召回前用 ACL 和元数据做硬过滤。
4. 召回后保留来源、版本、页码、段落 id。
5. 生成时要求引用生效版本，并在旧政策场景显式说明“历史版本”。
6. 审计日志记录用户、query、召回文档、答案、引用、权限过滤结果。

常见扣分点

• 说“生成后再把敏感内容过滤掉”。
• 不记录文档版本和生效时间。
• 不区分用户没有权限和文档不存在。
• 忽略多租户向量索引的数据隔离。

连续追问

追问：向量库按语义召回，怎么做 ACL？
每个向量 chunk 绑定文档权限元数据，检索时带过滤表达式；如果向量库过滤能力弱，可按租户/权限域拆索引或在召回后严格二次过滤，但不能把越权片段送入模型上下文。

追问：旧政策是否要删除？
不一定。旧政策可归档用于审计和历史问题，但默认查询只召回当前有效版本。用户明确问历史政策且有权限时再返回。

场景 3：RAG 支持多跳问题和复杂归因

题目场景
用户问：“为什么华东区上季度的客诉率上升，和新客服政策有没有关系？”答案需要结合客诉数据、政策文档、客服工单和时间线。

考察点

• 是否能判断普通 RAG 不一定够。
• 是否能拆子问题、跨数据源检索、处理因果表达。
• 是否能避免模型过度归因。

答题骨架

1. 把问题拆成：客诉率是否上升、上升在哪些类目、政策何时变化、变化影响哪些流程。
2. 结构化数据走 SQL/BI Tool，非结构化政策和工单走 RAG。
3. 时间线对齐：政策发布时间、上线范围、客诉变化窗口。
4. 让模型生成“可能相关”而非直接断言因果。
5. 输出证据：指标趋势、工单主题、政策条款、反例或干扰因素。
6. 高风险结论交给人工分析确认。

常见扣分点

• 让模型凭检索片段直接判断因果。
• 不区分相关性和因果性。
• 把结构化统计也塞给向量库。
• 不提数据口径和时间窗口。

连续追问

追问：GraphRAG 是否适合？
如果问题涉及实体关系、组织结构、政策影响链路，GraphRAG 有价值；如果只是查文档条款，普通 RAG 更简单。要按问题形态选择，不是默认上复杂方案。

追问：模型给出强因果结论怎么办？
Prompt 和输出 Schema 要限制结论级别，例如“已证实、强相关、弱相关、证据不足”。涉及经营决策时应提供证据和不确定性，不让模型替代数据分析结论。

三、Agent 与工具调用场景题

场景 4：订单 Copilot 要能查订单、改地址、申请退款

题目场景
客服希望 AI 根据用户描述自动查询订单、判断物流状态、改收货地址、申请退款，并生成客服回复。

考察点

• 是否区分查询类工具和有副作用工具。
• 是否知道高风险动作需要确认、幂等和补偿。
• 是否能把 Agent 和业务工作流结合。

答题骨架

1. 意图识别：查物流、改地址、退款、投诉可多意图拆分。
2. 参数抽取：订单号、用户身份、商品、金额、地址、原因。
3. 查询类工具可自动执行，但要鉴权。
4. 改地址、退款等副作用动作必须走规则校验和人工/用户确认。
5. 所有副作用工具带 idempotency_key、operation_id、状态查询接口。
6. Agent 输出建议动作，业务服务执行最终动作。
7. 记录全链路 trace：参数、工具返回、确认人、执行结果。

常见扣分点

• 让模型直接决定退款。
• 忽略接口超时后的重复调用风险。
• 不提订单状态机和业务规则。
• 不区分工具参数合法和业务语义正确。

连续追问

追问：改地址接口超时，但实际成功了怎么办？
恢复时先用 operation_id 查询操作状态，不直接重放。幂等键保证重复请求不会产生第二次副作用。必要时设计补偿流程和人工核验。

追问：用户一句话有多个诉求怎么办？
先拆任务并排序。例如“查物流并改地址”要先查物流和订单状态，确认仍可修改后再进入改地址确认节点。

场景 5：DeepResearch Agent 生成行业研究报告

题目场景
产品经理要求做一个 DeepResearch Agent，输入“分析某行业机会”，输出带引用的研究报告，要求覆盖市场规模、竞争格局、政策风险和投资建议。

考察点

• 是否能设计长任务、多轮检索、证据治理和停止条件。
• 是否能处理来源冲突、引用失效和成本预算。
• 是否知道报告生成不能等同于一次 RAG 问答。

答题骨架

1. 任务规划：拆成市场、竞品、政策、风险、结论几个子问题。
2. 信息获取：搜索、企业内库、数据库、公告、研报摘要多源检索。
3. 来源治理：来源类型、发布时间、可信度、是否一手资料。
4. 证据归并：去重、冲突标注、时间线整理。
5. 报告生成：结构化大纲、段落引用、结论置信度。
6. 停止条件：搜索轮数、证据覆盖、成本预算、时间预算。
7. 审计复现：保存 query、来源快照、引用、模型版本。

常见扣分点

• 只说“联网搜索后总结”。
• 不处理来源冲突。
• 不记录证据快照，导致报告不可复现。
• 不设置成本和停止条件。

连续追问

追问：两个权威来源数据冲突怎么办？
不要强行平均或选一个。要展示来源、口径、时间、统计范围差异，并在结论中说明不确定性。必要时让人工选择口径。

追问：如何避免报告很长但没有价值？
先定义读者和决策问题，报告围绕结论和证据组织。用“结论、依据、风险、待验证问题”结构，而不是堆搜索摘要。

场景 6：多 Agent 协作做故障排查

题目场景
线上 LLM 应用延迟突然升高，系统希望多个 Agent 分别分析日志、指标、配置变更和用户反馈，最后给出排障报告。

考察点

• 是否能给多 Agent 明确角色和共享状态。
• 是否知道多 Agent 不等于并行聊天。
• 是否能处理冲突结论和成本控制。

答题骨架

1. Supervisor 负责拆任务和终止判断。
2. Metrics Agent 看 TTFT、TPOT、P95/P99、GPU、队列。
3. Logs Agent 看错误码、重试、超时、fallback、工具调用。
4. Change Agent 看模型、Prompt、路由、部署、索引更新。
5. Report Agent 汇总证据，Reviewer 检查结论和引用。
6. 共享 state 保存证据、假设、已排除项和最终结论。
7. 设置最大轮数和成本预算，避免互相追问循环。

常见扣分点

• 把每个 Agent 说成泛泛的“专家”。
• 不设计共享状态和仲裁机制。
• 不记录证据来源。
• 不限制循环和 token 成本。

连续追问

追问：两个 Agent 结论冲突怎么办？
Supervisor 不按角色权威拍脑袋，而是要求每个结论绑定证据、指标和时间线。证据不足时输出待确认假设，而不是强行给结论。

追问：为什么不用单 Agent？
如果任务简单，单 Agent 更好。多 Agent 适合证据源多、职责可并行、需要互审的任务。多 Agent 的收益必须超过协作开销。

四、Prompt、工作流与低代码平台场景题

场景 7：Dify 原型效果好，准备给全公司使用

题目场景
业务团队用 Dify 做了一个合同问答机器人，试用效果不错，老板要求下周给全公司开放。

考察点

• 是否能从 PoC 思维切换到生产治理。
• 是否知道低代码平台上线前要补权限、评测、监控和版本。
• 是否能判断哪些能力继续留在平台，哪些要后端化。

答题骨架

1. 先做上线风险分级：合同属于高风险知识场景。
2. 检查知识库权限、合同版本、敏感字段脱敏。
3. 建立评测集：常见问题、边界问题、恶意问题、无答案问题。
4. 加引用、拒答、免责声明和人工转接。
5. 配置日志、token 成本、延迟、失败率、反馈入口。
6. 小范围灰度，按部门或用户组逐步开放。
7. 核心链路可沉淀到后端服务，Dify 保留运营配置。

常见扣分点

• 说“Dify 发布一下就行”。
• 不提合同权限和敏感信息。
• 没有灰度和回滚。
• 不建立评测集。

连续追问

追问：哪些情况必须后端化？
涉及复杂权限、高并发、强审计、跨系统事务、定制检索算法、企业统一网关时，应把核心链路后端化。平台可继续做 Prompt 配置和业务试验。

追问：业务方改了 Prompt 导致错误答案怎么办？
Prompt 变更要版本化、审批、自动回归和灰度。线上答案要记录 Prompt 版本，否则无法追责和回滚。

场景 8：结构化输出经常破格式

题目场景
系统要求模型输出 JSON，用于后续创建工单。但线上经常出现字段缺失、枚举值乱写、把解释文本混进 JSON 的问题。

考察点

• 是否知道结构化输出是工程契约。
• 是否能从 Schema、Prompt、模型能力、重试和降级几层处理。
• 是否能考虑业务后果。

答题骨架

1. 定义严格 Schema：字段类型、枚举、必填、范围、默认值。
2. Prompt 中明确只输出 JSON，并提供正反例。
3. 使用原生 structured output、function calling 或框架解析器。
4. 解析失败时返回错误信息重试一次，避免无限重试。
5. 关键字段缺失时进入澄清或人工队列。
6. 后端必须再次校验，不信任模型输出。
7. 记录解析失败率并进入回归集。

常见扣分点

• 用正则硬切 JSON。
• 无限重试直到成功。
• 后端直接执行模型给的字段。
• 不统计解析失败率。

连续追问

追问：字段类型对了但业务语义错了怎么办？
类型校验只能保证格式，不保证业务正确。要在业务层校验状态、权限、金额、库存、用户身份等语义规则。

追问：为什么不同模型格式遵循差异很大？
模型训练数据、指令遵循能力、解码参数、上下文复杂度都会影响格式稳定性。上线要把模型版本纳入结构化输出回归测试。

场景 9：Prompt 改动导致线上质量波动

题目场景
团队为了修一个 bad case 改了系统 Prompt，结果这个 case 变好了，但客服整体采纳率下降。

考察点

• 是否知道 Prompt 也需要工程化发布流程。
• 是否能区分局部优化和整体退化。
• 是否能用日志沉淀回归集。

答题骨架

1. Prompt 变更必须绑定版本、变更原因和影响范围。
2. bad case 先分类：召回、格式、拒答、业务规则还是语气。
3. 建 golden set：高频、长尾、边界、安全、历史 bad case。
4. 离线评测通过后小流量灰度。
5. 线上观察采纳率、拒答率、投诉率、转人工率和成本。
6. 发现退化时快速回滚 Prompt 版本。

常见扣分点

• 用一个 case 的成功证明整体提升。
• 不记录 Prompt 版本。
• 不跑安全和拒答回归。
• 不区分 Prompt 问题和检索问题。

连续追问

追问：线上日志哪些样本必须进入 golden set？
高频 query、业务高风险 query、投诉样本、人工改写样本、模型拒答样本、结构化解析失败样本、提示注入样本都应优先进入。

追问：模型升级后 Prompt 要不要重测？
必须重测。不同模型对同一 Prompt 的格式遵循、拒答边界、工具调用倾向可能不同，模型升级等同于核心依赖变更。

五、微调、MaaS 与部署场景题

场景 10：业务坚持“微调一下就好了”

题目场景
客服机器人回答不稳定，有时语气不符合公司风格，有时又答错政策。业务方要求直接做 LoRA 微调。

考察点

• 是否能判断微调、RAG、Prompt 各自边界。
• 是否能要求 baseline 和数据条件。
• 是否知道微调不能解决频繁变化的事实知识。

答题骨架

1. 先拆 bad case：事实错、召回错、格式错、语气错、拒答错。
2. 事实错优先修 RAG 和知识库版本。
3. 格式错优先结构化输出和 Prompt。
4. 语气、稳定表达、领域术语可考虑 SFT/LoRA。
5. 微调前准备高质量训练集、验证集、测试集和安全集。
6. 和基座、Prompt、RAG 方案做 A/B 对比。
7. 上线时保留回滚和路由策略。

常见扣分点

• 把微调当成万能补丁。
• 不要求业务提供样本和标注标准。
• 不做基线对比。
• 不评估微调后的安全和拒答能力。

连续追问

追问：微调数据从线上日志来，怎么处理？
先脱敏、去重、纠错、过滤低质量样本，再由专家标注或审核。错误回答不能直接进训练集，bad case 先进入评测集，修正稳定后再进入训练。

追问：基座模型升级后 LoRA 能直接复用吗？
不能默认复用。LoRA 和基座模型强绑定，升级后要做兼容性评测，必要时重新训练或重新合并。

场景 11：应用从直连模型迁移到 MaaS 平台

题目场景
公司多个应用直连 OpenAI、通义、DeepSeek，现在要求统一接入内部 MaaS 平台，支持虚拟 Key、模型路由、fallback、计费和审计。

考察点

• 是否能说清应用侧迁移最小改动。
• 是否知道模型 fallback 会影响输出契约。
• 是否能设计验收集和灰度策略。

答题骨架

1. 抽象统一 LLM Client，隔离 provider 差异。
2. 配置虚拟 Key、租户、应用、预算、SLA。
3. 把模型名、温度、max token、工具 Schema、输出 Schema 纳入配置。
4. 准备 golden set 验证 JSON、工具调用、拒答、安全、长上下文。
5. fallback 模型必须通过输出契约兼容测试。
6. 小流量灰度，监控质量、延迟、错误率、成本。
7. 日志记录 provider、model、route_reason、fallback_reason。

常见扣分点

• 以为换 base_url 就完成迁移。
• 不验证 fallback 后的输出格式。
• 不记录路由原因。
• 不和业务 SLA、预算绑定。

连续追问

追问：业务申请接入 MaaS 要填哪些信息？
场景类型、数据敏感级别、峰值流量、SLA、预算、模型偏好、是否需要工具调用、是否需要私有化、评测集和负责人。

追问：fallback 到弱模型导致质量下降怎么办？
fallback 不能只按可用性触发，还要按任务风险分级。高风险任务可宁可失败或转人工，不应该静默降级到不兼容模型。

场景 12：LLM 服务压测通过但线上很慢

题目场景
压测报告显示 tokens/s 很高，但上线后用户反馈首字等待很久，高峰期偶发超时。

考察点

• 是否知道 tokens/s 不是唯一指标。
• 是否能区分 TTFT、TPOT、排队、上下文长度和重试。
• 是否能从真实流量分布做容量规划。

答题骨架

1. 看 TTFT、TPOT、P95/P99、goodput、错误率、超时率。
2. 按输入长度、输出长度、并发、租户、场景分桶。
3. 检查排队、动态 batching、KV Cache、GPU 利用率、显存碎片。
4. 检查是否有 Prompt 变长、RAG Top-K 变大、重试风暴。
5. 用真实日志抽样压测，而不是固定短 prompt。
6. 设置限流、熔断、降级、小模型路由和缓存。

常见扣分点

• 只看平均延迟。
• 把离线压测等同线上表现。
• 不看输入输出 token 分布。
• 不看重试和 fallback。

连续追问

追问：P95 TTFT 差但平均 token/s 高，能上线吗？
对交互式应用通常不能。首字等待直接影响体验，P95 差说明长尾用户不可接受。离线报告类任务可以更关注总耗时。

追问：成本突然翻倍怎么排查？
按流量、token 长度、模型路由、重试次数、缓存命中、RAG Top-K、Agent 工具循环、Prompt 版本逐层拆解。

六、安全、评测与上线治理场景题

场景 13：Agent 工具调用出现越权风险

题目场景
用户让 Agent “帮我导出客户名单”，Agent 通过 MCP 工具发现有导出接口，并尝试调用。用户本人没有导出权限。

考察点

• 是否知道工具发现不等于工具授权。
• 是否能设计用户权限、工具权限和动作权限。
• 是否能记录审计和拒绝原因。

答题骨架

1. MCP 工具列表可按用户权限动态暴露，或调用时强校验。
2. 每个工具定义 scope、risk_level、required_role、confirmation_required。
3. 模型只生成调用意图，服务端执行前做权限校验。
4. 高风险工具需要二次确认或审批。
5. 拒绝时返回合规解释，不泄露敏感接口细节。
6. 审计记录用户、工具、参数、权限判断、拒绝原因。

常见扣分点

• 只靠 Prompt 禁止越权。
• 工具列表对所有用户完全一致。
• 不审计被拒绝的调用。
• 不区分读权限和导出权限。

连续追问

追问：检索文档诱导模型调用导出工具怎么办？
检索内容只作为证据，不作为指令。工具调用必须经过系统策略和用户授权校验。中间轨迹里出现诱导调用也要判定为安全失败。

追问：管理员能否绕过所有限制？
也不应该。管理员动作仍要审计，高风险批量导出要二次确认和水印，必要时审批。

场景 14：上线后怎么证明 AI 应用真的有效

题目场景
老板问：“这个 AI 项目花了这么多钱，到底有没有产生价值？要不要继续投？”

考察点

• 是否能把技术指标转成业务指标。
• 是否能做上线前后对比和分层分析。
• 是否知道采纳率低不一定是模型问题。

答题骨架

1. 定义业务指标：处理时长、一次解决率、转人工率、采纳率、投诉率、成本。
2. 定义质量指标：正确率、引用命中、拒答正确、格式遵循、工具成功率。
3. 定义成本指标：单次 token 成本、GPU 成本、人工节省、维护成本。
4. 做 A/B 或灰度对比，避免只看上线后绝对值。
5. 分析不采纳原因：模型错、证据不足、流程入口差、用户不信任。
6. 给出继续投入、收缩范围或改造链路的建议。

常见扣分点

• 只说“用户反馈不错”。
• 只展示 Demo，不展示线上数据。
• 不计算成本。
• 不区分模型问题和产品流程问题。

连续追问

追问：用户不采纳 AI 建议，怎么判断原因？
看人工改写内容、用户反馈、点击行为、任务完成时间和 bad case 分类。若建议正确但不采纳，可能是入口、信任、流程或 UI 问题；若建议错误，才是模型或检索问题。

追问：如何防止指标被刷好看？
指标要组合看。比如采纳率上升但投诉率也上升，说明可能过度自动化；成本下降但转人工率上升，说明质量可能变差。要保留人工抽检。

七、生产事故加压题

这一节是更接近资深面试官的“事故复盘题”。它考察的不是你会不会背技术名词，而是能不能在质量、成本、权限、延迟、业务风险之间做判断。

场景 15：RAG 改版后 Recall 上升但投诉变多

题目场景
团队把 Top-K 从 10 提到 80，又加了 query rewrite。离线 Recall@K 提升明显，但线上答案更啰嗦、引用更差，P95 延迟翻倍。

考察点

• 是否知道 Recall 不是唯一目标。
• 是否能同时看 Context Precision、Faithfulness、引用准确性和延迟成本。
• 是否能用灰度和分场景评测做发布决策。

答题骨架

1. 不只看 Recall@K，同时看 MRR、Context Precision、Faithfulness、Citation Support、拒答质量、P95 延迟和单问成本。
2. 按问题类型拆分：条款查询、长尾问题、多跳问题、冲突问题、无答案问题、权限问题。
3. 检查 Top-K 变大是否引入噪声，query rewrite 是否偏离原意。
4. 调整 rerank_top_n、上下文压缩和引用覆盖校验。
5. 高风险场景先不全量切，使用灰度、线上抽检和人工评审。

常见扣分点

• 认为 Recall 高就一定更好。
• 忽略用户体验和成本。
• 不拆检索质量和生成质量。
• 没有线上灰度和回滚。

场景 16：合同 RAG 对表格和附件回答错误

题目场景
法务合同助手能检索 PDF 合同，但涉及价格表、附件、扫描章页时经常答错，引用也无法精确到条款或页码。

考察点

• 富文档解析、表格结构保留、OCR 置信度。
• 引用粒度是否能支撑法务场景。
• 混合检索和人工复核边界。

答题骨架

1. 文档解析先分类型：正文、表格、图片、扫描页、附件、签章页。
2. 表格保留表头、行列关系、页码、附件名、条款路径，不能按普通段落粗切。
3. OCR 结果记录置信度，低置信度进入人工复核或拒答。
4. 条款号、金额、日期走关键词和元数据检索，语义问题走向量检索。
5. 答案必须引用合同名、版本、页码、条款号或表格行。

常见扣分点

• 只说换 Embedding。
• 引用只到文档级。
• 忽略附件层级和表格结构。
• 不处理 OCR 低置信度。

场景 17：Prompt 改版后拒答率飙升

题目场景
业务人员把客服助手的 system prompt 改得更谨慎。上线后投诉下降一点，但拒答率从 8% 升到 35%，转人工率明显上升。

考察点

• Prompt 版本化和回归测试。
• 拒答正确率和业务可用性的平衡。
• 线上止血、灰度、回滚流程。

答题骨架

1. 先回滚或缩小灰度范围，避免继续扩大影响。
2. 对比新旧 Prompt、模型版本、RAG 上下文和拒答规则。
3. 把 bad case 分成证据不足、权限不足、误判风险、Prompt 过度保守。
4. 用 golden set 分别评估正确回答率、拒答正确率、投诉率、转人工率。
5. 把“必须拒答”和“可以保守回答”的边界写成规则和示例。

常见扣分点

• 只说把 Prompt 写清楚。
• 只看安全指标，不看正常问题误拒率。
• 允许业务人员直接改线上 Prompt。
• 没有版本和回滚。

场景 18：合同抽取 JSON 合法但业务入库错误

题目场景
合同审阅系统能稳定输出合法 JSON，但金额单位、付款日期、主体名称经常错，导致下游审批流误触发。

考察点

• 结构化输出的语法正确、Schema 正确和事实正确三层差异。
• 字段级证据和业务校验。
• Schema 版本演进和旧 trace 回放。

答题骨架

1. 合法 JSON 只保证语法，不保证字段语义和事实正确。
2. 关键字段要带 evidence、页码、原文片段和置信度。
3. 金额、日期、主体、币种、税率做规则或数据库校验。
4. 没有证据的字段返回 null 或进入人工队列，不能让模型猜。
5. Schema 版本化，旧 trace 按旧 Schema 回放。

常见扣分点

• 把 JSON Mode 当成事实保证。
• 没有字段级准确率评测。
• 直接把模型输出写入业务库。
• 对缺失字段让模型补猜。

场景 19：Dify 工作流成本一周翻三倍

题目场景
运营内容助手用 Dify Workflow 串起选题、检索、生成、合规检查和人工审核。上线一周后 token 成本翻三倍，但内容产量没有明显增加。

考察点

• 节点级成本观测。
• 循环、重试、上下文膨胀和模型路由。
• 预算阈值和熔断。

答题骨架

1. 按 app、租户、用户、节点、模型拆成本。
2. 检查 Top-K 是否变大、历史上下文是否膨胀、某节点是否换成高价模型。
3. 检查工具失败是否触发重试，条件分支是否形成循环。
4. 短期加预算阈值、限流、熔断和异常 Key 冻结。
5. 中期做节点级 token 报表、上下文裁剪、缓存和模型分层路由。

常见扣分点

• 只说换便宜模型。
• 没有节点级 trace。
• 不区分调用量上涨和单次请求变贵。
• 没有预算上限。

场景 20：报销审核哪些 gate 不能交给 LLM

题目场景
公司要做报销审核助手：用户上传发票、行程单和说明，系统自动判断是否合规并发起审批。面试官问哪些节点可以用 LLM，哪些必须用规则或后端服务。

考察点

• LLM 和确定性规则的边界。
• 低容错流程的人审设计。
• 财务风险和审计。

答题骨架

1. LLM 适合做 OCR 后的信息归一、摘要、异常解释、材料缺失提示。
2. 金额、发票真伪、预算科目、重复报销、审批权限、政策生效日期必须由规则、数据库或第三方服务校验。
3. 高风险或低置信度进入人工审核。
4. 工作流要有 validator、error code、审计日志和可回放 trace。
5. 指标看自动通过率、人工节省、误放率、误拦率。

常见扣分点

• 让模型直接决定合规或不合规。
• 忽略金额和权限硬校验。
• 只追求自动化率。
• 不讨论误放带来的财务风险。

场景 21：微调模型上线后事实正确率下降

题目场景
公司给客服模型做 LoRA 微调，目标是统一语气和输出格式。上线后格式稳定了，但政策类问题错误率上升，尤其是新政策和地区差异问题。

考察点

• 行为模式适合进权重，动态事实应走 RAG。
• 微调前后的回归评估。
• base model、LoRA、Prompt、知识库版本的绑定。

答题骨架

1. 按 bad case 分类：语气、格式、事实、拒答、地区和版本错误。
2. 动态政策错误优先修 RAG、元数据和版本过滤。
3. 对比基座、Prompt-only、RAG-only、LoRA+RAG 的结果。
4. 检查训练集是否把旧政策或错误回答训练进去了。
5. LoRA 只用于目标场景，避免所有请求默认走微调模型。
6. 记录 base_model_version、lora_version、prompt_version、kb_version。

常见扣分点

• 说再加数据继续训。
• 把事实错误归因成模型不够大。
• 只看格式遵循率，不看事实忠实度。
• 没有灰度和路由回滚。

场景 22：多 LoRA 服务出现错配和延迟问题

题目场景
平台用同一个 14B 基座服务多个业务 LoRA：客服、法务、HR。上线后某些租户偶发命中错误 adapter，高峰期 LoRA 热加载导致 P95 延迟升高。

考察点

• 多 LoRA 服务化和多租户隔离。
• Adapter 选择是请求级路由策略，不是模型自动判断。
• 性能、隔离、回滚和审计。

答题骨架

1. 每个请求显式绑定 tenant、app、task、lora_adapter、version。
2. Adapter 选择由 MaaS 路由策略决定。
3. 高频 adapter 预热，低频 adapter 冷加载或独立池。
4. 监控 adapter 加载耗时、命中率、P95/P99、显存占用和错误路由。
5. 多租户缓存 key 包含 tenant、base model、adapter、Prompt 版本。
6. Adapter 灰度发布，异常时回滚到上一版 adapter 或基座路径。

常见扣分点

• 只说 vLLM 支持 LoRA 热加载。
• 语义缓存跨 adapter 复用答案。
• 忽略 adapter 错配是生产事故。
• 没有版本审计和回滚。

场景 23：新模型榜单高，业务要求全量切

题目场景
新推理模型在公开榜单和内部少量样例上表现更好。业务要求把客服、投研、代码助手都切过去，平台担心工具调用、JSON 输出、成本和合规风险。

考察点

• 模型上架流程。
• 业务 golden set 和能力标签。
• 榜单分数与业务可用性的差异。

答题骨架

1. 建模型目录：能力、上下文、价格、部署位置、合规等级、禁用场景。
2. 按业务切片跑 golden set，而不是只看总分。
3. 覆盖 JSON、tool calling、拒答、长上下文、安全和引用格式。
4. 对比旧模型质量、TTFT、TPOT、成本、错误率和投诉率。
5. 先影子流量，再低风险租户灰度，再扩大场景。
6. 路由策略记录 route_reason，支持一键回旧模型。

常见扣分点

• 用公开榜单替代业务验收。
• 不测工具调用和结构化输出兼容性。
• 不看 output token 成本变化。
• 没有模型下线和应用通知机制。

场景 24：长上下文请求拖垮在线推理服务

题目场景
同一个 vLLM 集群同时服务在线客服和离线报告生成。某天离线任务开始提交 32K 长上下文请求，在线客服 TTFT 飙升，部分请求 OOM。

考察点

• Prefill、Decode、KV Cache 和长短请求隔离。
• 在线与离线 SLA 的资源隔离。
• 真实长度分布下的容量规划。

答题骨架

1. 拆指标：排队时间、TTFT、TPOT、KV 占用、OOM、goodput。
2. 判断长 prompt 是否占用 Prefill 计算和 KV Cache。
3. 在线客服与离线报告分队列、分优先级，必要时分 GPU 池。
4. 超长请求做准入控制、排队、降级或异步任务化。
5. 使用 chunked prefill、prefix cache、KV 量化或长短请求隔离。
6. 容量规划用真实长度分布和 SLA goodput，不用短 prompt 压测。

常见扣分点

• 只说扩 GPU。
• 把 tokens/s 高当成线上可用。
• 不看 KV Cache 随上下文和并发增长。
• 让离线批处理挤占在线 SLA。

场景 25：Fallback 成功返回但业务状态写错

题目场景
主模型超时后 MaaS fallback 到备用模型。备用模型没有严格遵守工具参数格式，把订单状态字段填成自然语言，后端兼容层误解析，导致错误工单创建。

考察点

• Fallback 不只是可用性问题，也是输出契约问题。
• 工具 Schema、业务校验和降级边界。
• 什么时候宁可失败也不静默降级。

答题骨架

1. Fallback 链路必须进入 golden set，覆盖工具调用和 JSON Schema。
2. 备用模型要验证参数类型、枚举值、必填字段和拒答边界。
3. 后端不能信任模型输出，业务层做状态机和权限校验。
4. 高风险动作 fallback 后可转人工或只读模式，不静默执行。
5. 日志记录主模型错误、fallback_reason、备用模型和 Schema 版本。
6. 出事后回滚路由策略，并把 trace 加入回归集。

常见扣分点

• 认为 fallback 只要能回答即可。
• 用正则硬解析错误字段。
• 不区分只读查询和有副作用工具。
• 不记录 fallback 命中后的质量指标。

场景 26：量化后成本降了，但输出和拒答变差

题目场景
私有化部署为了降成本，把 FP16 模型换成 W4A16 量化版本。压测显示吞吐提升、显存下降，但线上 JSON 解析失败率和敏感问题误答率上升。

考察点

• 量化上线要验效果、性能、稳定性三类门禁。
• 性能优化可能伤害模型行为。
• 成本节省要和质量损失一起决策。

答题骨架

1. 跑真实业务评测集，不只看 PPL 或少量样例。
2. 对比 FP16 基线：格式遵循、拒答、安全、长上下文、工具调用。
3. 性能看 TTFT、TPOT、goodput、显存和成本。
4. 稳定性看长压、不同长度分布、并发波动和 OOM。
5. 高风险场景走 FP16 或强模型，低风险场景走量化模型。
6. 记录 model_precision 和量化配置，支持快速回滚。

常见扣分点

• 只用吞吐提升证明可上线。
• 不测结构化输出和安全拒答。
• 不保留 FP16 回滚路径。
• 忽略量化对边界行为的影响。

场景 27：AI 客服上线后没人用

题目场景
你答辩一个 AI 客服项目，技术上用了 RAG、Prompt、Dify 和后端工具，但上线两个月后，一线客服仍然绕开系统。

考察点

• AI 项目不是 Demo 成功就等于业务成功。
• 组织采纳、流程嵌入和 ROI 指标。
• 从失败项目里做复盘。

答题骨架

1. 拆原因：答案质量、响应速度、入口体验、工作流割裂、考核冲突、人工兜底成本。
2. 补埋点：使用率、首答解决率、转人工率、平均处理时长、点踩原因。
3. 访谈一线客服，找真实阻塞点。
4. 把 AI 从额外系统嵌入客服工作台。
5. 优先做高频、低风险、能节省时间的场景。
6. 用 A/B 或灰度证明处理时长下降且满意度不恶化。

常见扣分点

• 只讲模型准确率。
• 不承认组织和流程问题。
• 没有 ROI 和使用率指标。
• 把失败归因给用户不愿意用新东西。

八、面试前自测清单

拿到任何场景题，至少回答出下面 10 个问题：

1. 这个业务场景的目标指标是什么？
2. 哪些数据是实时的，哪些数据是文档型的？
3. 需要 RAG、Agent、工作流、微调还是 MaaS？
4. 哪些动作有副作用，需要确认、幂等和补偿？
5. 权限过滤发生在召回前、工具前还是输出后？
6. 最容易出错的 3 类 bad case 是什么？
7. 你用哪些离线和在线指标证明效果？
8. 线上日志如何进入评测集或训练集？
9. 成本、延迟和质量冲突时怎么分层路由？
10. 出事故后如何回滚、复盘和审计？

继续阅读

• 大模型应用实战知识体系
• 大模型应用实战高频追问
• 大模型应用系统设计面试题
• 大模型应用线上排障手册
• 分岗位面试真题
• RAG 基础与流程
• Agent 基础与框架
• 推理部署与成本治理高频问答