#模块十：系统设计、业务落地与成本权衡

#109. 设计一个基于 LLM 的客服系统，最核心的模块有哪些？

#标准答案

一个基于 LLM 的客服系统，核心模块至少包括：请求接入层、用户身份与会话管理、知识检索层、模型调用层、工单/业务系统工具集成层、监控评测层、安全治理层，以及人工兜底机制。更具体一点讲，用户请求进来后，系统要先知道这个用户是谁、历史上下文是什么、是否命中已有 FAQ 或缓存；如果进入 LLM 链路，就要先检索知识，再决定是否调用订单、退款、物流等工具，最后把结果输出给用户。

为什么这些模块都重要？因为客服不是一个纯问答场景，而是“信息查询 + 业务执行 + 风险控制”的组合。没有知识检索会胡说，没有工具系统无法真办事，没有人工兜底会在高风险场景失控。所以面试里最好把客服系统讲成业务系统，而不是一个聊天 demo。

#深度解析

1. 客服系统的七层架构图

┌─────────────────────────────────────────────────────────┐
│ 接入层（Gateway）                                        │
│ 负载均衡、限流、鉴权、多租户隔离                         │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 会话管理层（Session）                                    │
│ 用户身份、历史对话、上下文窗口、多轮状态                 │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 意图路由层（Intent Router）                              │
│ FAQ 匹配 → 直接回答 / LLM 路由 → 生成回答 / 人工 → 转接  │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 知识检索层（RAG）                                        │
│ 知识库召回、重排序、上下文组织                           │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 模型调用层（LLM）                                        │
│ Prompt 组装、模型选择、流式输出、失败重试               │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 工具集成层（Tools）                                      │
│ 订单查询、退款、物流、工单创建、用户信息查询             │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 输出治理层（Guardrail）                                  │
│ 安全审查、事实校验、格式约束、敏感操作确认               │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 监控与兜底层（Observability & Escalation）               │
│ 日志、指标、告警、人工兜底、满意度回访                   │
└─────────────────────────────────────────────────────────┘

2. 各模块的关键设计决策

3. 客服系统的特殊挑战

4. 典型客服系统的数据流

用户："我的订单为什么还没发货？"
    │
    ├── 意图路由：判断为"物流查询"
    │
    ├── 会话管理：提取用户身份、关联订单号
    │
    ├── 工具调用：查询订单系统
    │       └── 返回：订单 #12345，状态"仓库处理中"
    │
    ├── 知识检索：查询"发货延迟"相关 FAQ
    │       └── 返回：延迟原因、预计时间
    │
    ├── LLM 生成：综合工具和知识，生成回答
    │       └── "您的订单 #12345 正在仓库处理中，
    │            预计明天发货。 delay 原因是..."
    │
    ├── Guardrail：检查是否有敏感信息泄露
    │
    └── 输出给用户

5. 面试官常见深挖追问

• "客服系统里，LLM 回答错了导致用户损失（如错误退款），责任怎么划分？"
  • 答：这是系统设计的核心问题。技术上：1）高风险操作（退款、改单）必须人工确认或规则引擎校验，不能由 LLM 直接执行；2）LLM 只生成"建议"，执行层独立校验；3）所有操作留痕审计。责任上：系统设计者需确保"机器不拥有最终决策权"，LLM 是助手而非代理。如果因为 guardrail 缺失导致错误执行，是系统架构缺陷。

• "如果客服系统的 LLM 回答质量下降，怎么快速定位是哪个模块的问题？"
  • 答：分层排查。1）先看意图路由日志：问题是否被正确分类？如果路由错了，后续全错；2）检查工具调用：返回数据是否正确？如果工具返回错误数据，LLM 会基于错误信息回答；3）检查知识检索：召回的文档是否相关？4）看 LLM 输入的完整 prompt：上下文组织是否有问题？5）对比相同 prompt 在不同模型上的输出，判断是模型能力问题还是 prompt 问题。每层都有独立日志是快速定位的关键。

#110. 如何降低 LLM API 成本？

#标准答案

降低 LLM API 成本，最重要的原则不是“统一换小模型”，而是让昂贵算力只花在真正值得的请求上。常见方法包括：做模型分级路由，让简单请求走小模型；做缓存，减少重复问答；压缩上下文和历史消息，减少无效 token；提升 RAG 精度，避免把大量噪声文档塞进 prompt；让小模型先做分类、过滤、改写，难题再升级到大模型。

更成熟的回答还会提到失败重试优化和流量分层：不要对每次失败都机械重试最贵模型，也不要让低价值用户请求和高价值任务共用同一高成本链路。这样回答会显得你理解成本治理是架构问题，而不是只会说“换便宜接口”。

#深度解析

1. LLM API 成本的构成分析

总成本 = 输入 token 成本 + 输出 token 成本 + 重试成本 + 缓存未命中成本

输入成本驱动因素：
    ├── 上下文长度（历史对话、RAG 文档）
    ├── 系统 prompt 长度
    └── 用户输入长度

输出成本驱动因素：
    ├── 回答长度（verbosity）
    ├── 生成步数（每个 token 都计费）
    └── 失败重试次数

典型价格参考（GPT-4 级别）：

• 输入：$10 / 1M tokens
• 输出：$30 / 1M tokens
• 一个含 3K 输入 + 500 输出 token 的请求 ≈ $0.045

2. 成本优化策略矩阵

3. 模型路由的决策框架

请求进入
    │
    ├── 意图分类（轻量模型/规则）
    │       ├── 简单 FAQ → GPT-3.5 / 开源 7B
    │       ├── 复杂推理 → GPT-4
    │       ├── 创意生成 → GPT-4 / Claude
    │       └── 代码生成 → 专用代码模型
    │
    └── 置信度评估
            ├── 高置信度 → 直接用分类结果路由
            └── 低置信度 → 默认走大模型（保守策略）

4. 缓存策略的精细化设计

5. 面试官常见深挖追问

• "成本优化会不会损害用户体验？怎么平衡？"
  • 答：会，所以需要"分层优化"而非"一刀切"。1）对高价值用户/任务保持大模型，低价值场景用小模型；2）缓存只用于事实性问题，创意/推理问题不走缓存；3）模型路由设置置信度阈值，不确定时保守用大模型；4）A/B 测试验证优化后的用户满意度，确保成本下降不以满意度崩溃为代价。关键是：成本优化是渐进过程，每步都要监测业务指标。

• "如果老板要求成本降 50%，但效果不能降，你会怎么做？"
  • 答：三板斧。1）路由优化：分析请求分布，把 60% 的简单请求切到小模型（降本 40%）；2）缓存建设：对 Top 20% 高频 query 做语义缓存（降本 15%）；3）上下文瘦身：优化 RAG 策略，减少每请求 30% 的输入 token（降本 10%）。合计降本 50%+，效果影响通过 A/B 测试控制在 <2% 满意度下降。如果仍不够，考虑自托管开源模型处理简单任务。

#111. 流式输出的价值是什么？

#标准答案

流式输出最大的价值，是显著改善用户体感。即使总完成时间没变，只要用户能更早看到首 token 或首段结果，等待焦虑就会明显下降，产品会显得“更快、更活”。这对长回答、搜索辅助、代码解释、客服对话尤其重要。

从产品角度看，流式输出还方便用户中途打断、追问或提前获得部分可用信息，因此它不只是时延优化技巧，也是交互设计手段。面试里如果能把“首 token 延迟”和“总完成时间”区分开，会更专业，也更接近真实产品指标，因为很多用户感知主要由前者决定而不是由完整生成结束时间决定，这一点在客服和搜索类产品里尤其明显。

#深度解析

1. 流式输出 vs 非流式：用户感知差异

2. 流式输出的技术实现原理

非流式：
用户输入 → 模型生成完整回答 → 一次性返回
    └── 用户等待：预填充 + 全部解码时间

流式：
用户输入 → 模型开始生成
    └── 首 token 到达用户：仅预填充时间
    └── 后续 token：随生成实时推送
    └── 用户感知延迟 = 预填充时间（通常 0.5-2s）

关键：流式不减少总 token 生成时间，但把"等待完整结果"变成"边看边等"。

3. 流式输出的产品价值

4. 流式输出的技术挑战

5. 面试官常见深挖追问

• "流式输出能不能降低服务器成本？"
  • 答：不能降低生成成本（总 token 数一样），但可能降低连接成本。非流式需要保持连接直到完整生成结束（可能 10-30s），流式连接虽然更长但数据持续流动，可减少连接超时重试。真正降低成本的是：流式让用户更快判断是否需要继续，从而降低平均生成长度（用户提前打断）。但这是间接效果，不是流式本身降低成本。

• "流式输出的首 token 延迟由什么决定？怎么优化？"
  • 答：首 token 延迟 = 预填充时间（prompt 处理 + 第一个 token 生成）。优化方法：1）缩短 prompt（上下文压缩）；2）使用更快的模型或小模型做首 token；3） speculative decoding 加速首 token；4）预热（保持模型常驻显存，避免冷启动）；5）对于已知问题类型，预生成常见开头（如"根据您的查询..."）再流式后续内容。

#112. 模型路由通常想解决什么问题？

#标准答案

模型路由要解决的核心问题，是不同请求并不值得同样昂贵的模型和同样慢的链路。简单问答、模板任务、低风险请求，完全没必要一律走最大模型；而复杂推理、高价值客户、高风险任务，又不能随便降配。模型路由就是把“请求特征”和“模型能力/成本”匹配起来。

因此它的本质，是在效果、成本、时延之间做动态折中。一个成熟系统通常还会把风险等级、SLA、历史成功率、工具需求等一起纳入路由，而不是只按问题长度粗暴切分。换句话说，路由本身就是一种资源调度策略，也是在把大模型能力当稀缺资源分配，而不是默认所有请求都值得最贵推理。

#深度解析

1. 模型路由的三维决策空间

                    效果 ↑
                         │
    小模型 ──────────────┼─────────────→ 大模型
    (快/便宜/效果一般)   │    (慢/贵/效果好)
                         │
    ←────── 成本 ────────┼──────── 时延 ──────→

路由决策不是单维度的"简单/复杂"，而是综合考虑：

• 效果维度：任务对准确率的敏感度
• 成本维度：模型调用费用
• 时延维度：用户可接受的等待时间

2. 路由策略的分类

3. 路由系统的典型架构

请求进入
    │
    ├── 特征提取
    │       ├── 文本特征（长度、语言、领域关键词）
    │       ├── 用户特征（等级、历史偏好）
    │       └── 上下文特征（时间、并发量）
    │
    ├── 路由决策
    │       ├── 规则引擎（快速过滤）
    │       └── ML 模型（复杂判断）
    │
    ├── 模型选择
    │       ├── 简单任务 → GPT-3.5 / 开源 7B
    │       ├── 标准任务 → GPT-4 / Claude
    │       ├── 复杂推理 → GPT-4o / 专用模型
    │       └── 创意生成 → Claude / Gemini
    │
    └── 后评估
            └── 记录路由决策 + 实际效果
            └── 用于优化路由策略

4. 路由决策的常见特征

5. 面试官常见深挖追问

• "路由错误把复杂请求分给简单模型，导致效果差，怎么处理？"
  • 答：三层防护。1）保守策略：不确定时默认走大模型（宁可过度分配也不漏配）；2）降级检测：简单模型输出后做质量评估（如置信度、格式校验），不达标时升级到大模型重试；3）反馈学习：收集路由错误样本，持续优化路由模型。关键是把路由错误的影响限制在"多花了成本"而不是"损害了体验"。

• "模型路由和模型ensemble有什么区别？"
  • 答：路由是"选一个"，ensemble 是"用多个"。路由：根据请求特征选择最合适的单一模型，成本低但可能错过其他模型的优势；ensemble：多个模型同时生成，综合结果（如投票、排序），效果通常更好但成本翻倍。实践中可以先路由到候选模型子集，再在小范围内 ensemble，平衡成本和效果。

#113. 什么是 rate limiting，它为什么对 LLM 服务特别重要？

#标准答案

rate limiting 就是对请求频率、并发规模或资源消耗做限制，防止某个用户、某类流量或某个异常模式把系统拖垮。对 LLM 服务尤其重要，因为模型调用成本高、时延长、资源敏感，一旦被恶意刷接口、脚本误调或突发流量打爆，损失会比普通 Web 服务大得多。

它的意义不仅是防止系统过载，也是在做成本治理和风险控制。比如高成本工具调用、长上下文推理、批量生成任务，都需要更细粒度的速率限制，而不是只看 QPS。很多时候限流策略本身就是保障 SLA 的一部分，也是避免异常流量拖垮全局服务、影响高价值请求的手段。

#深度解析

1. Rate Limiting 的多维粒度

2. LLM 服务限流的特殊挑战

3. 限流算法对比

4. 生产级限流策略

请求到达
    │
    ├── 第一层：全局限流（保护系统）
    │       └── 超过总容量 → 直接拒绝 + 建议重试时间
    │
    ├── 第二层：用户限流（公平使用）
    │       └── 超过用户配额 → 降级服务 / 排队 / 收费升级
    │
    ├── 第三层：功能限流（成本控制）
    │       └── 高成本功能（如代码生成）→ 单独限制
    │
    ├── 第四层：模型限流（资源保护）
    │       └── 特定模型过载 → 路由到其他模型
    │
    └── 第五层：应急限流（异常处理）
            └── 检测到攻击模式 → IP 封禁 / 验证码

5. 面试官常见深挖追问

• "限流和降级有什么区别？什么时候限流，什么时候降级？"
  • 答：限流是"拒绝服务"，降级是"降低服务质量但仍服务"。限流场景：用户配额用完、系统整体过载、检测到恶意流量。降级场景：模型过载时切到小模型、长上下文请求缩短处理、复杂任务简化流程。原则是：对"坏用户"限流，对"好用户"降级。好用户遇到系统压力时，宁可效果差一点也要继续服务；坏用户（滥用者）直接拒绝。

• "如果一个用户的合法请求被限流了，怎么处理才能不流失用户？"
  • 答：分层处理。1）提示：明确告知用户当前配额和重置时间；2）排队：高价值用户进入优先队列而非直接拒绝；3）降级：提供免费的小模型替代方案；4）引导：提示升级套餐获得更多配额；5）缓冲：允许少量超限（如 10% burst），避免严格限制误伤。关键是让用户感受到"系统在合理管理资源"而不是"系统在拒绝我"。

#114. 线上服务为什么需要缓存？哪些地方可以缓存？

#标准答案

线上服务需要缓存，因为很多成本其实花在重复计算上。相同或高度相似的问题、相同的系统 prompt 前缀、重复文档的 embedding、重复的 RAG 召回结果，都可能一遍又一遍地被算。如果不缓存，系统会白白消耗 token、GPU 和外部 API 费用。

可缓存的地方很多：最终问答结果、检索结果、embedding、常用系统前缀、工具查询结果、甚至多轮对话中的 prefix cache。高分回答通常会补一句：缓存不是越 aggressive 越好，还要考虑时效性、用户隔离、权限边界和失效策略。

#深度解析

1. LLM 系统的缓存层次架构

用户请求
    │
    ├── L1: 结果缓存（Redis/Memcached）
    │       └── 精确/语义匹配，命中则直接返回
    │       └── 延迟：~1ms
    │
    ├── L2: Embedding 缓存
    │       └── 相同 query/文档的 embedding 复用
    │       └── 延迟：~5ms
    │
    ├── L3: 检索缓存
    │       └── 相同 query 的 RAG 召回结果复用
    │       └── 延迟：~10ms
    │
    ├── L4: Prefix Cache（vLLM 等）
    │       └── 共享系统 prompt 的 KV Cache
    │       └── 延迟：节省预填充时间
    │
    └── L5: 模型输出缓存
            └── 相同输入的生成结果复用
            └── 延迟：~500ms-5s（避免重新生成）

2. 各缓存层的详细设计

3. 缓存设计的关键权衡

4. Prefix Cache 的技术原理

系统 prompt（共享前缀）
    ↓
用户 A 提问："什么是 LLM？"
    └── KV Cache: [系统 prompt KV] + [A 的问题 KV]

用户 B 提问："什么是 Transformer？"
    └── 复用 [系统 prompt KV]，只计算 [B 的问题 KV]
    └── 节省：系统 prompt 的预填充时间

vLLM 的 Prefix Cache 通过 block table 管理，相同前缀的 block 可以共享（copy-on-write），在多轮对话和高并发场景下显著降低 TTFT。

5. 面试官常见深挖追问

• "缓存命中率 30% 算高还是低？怎么提升？"
  • 答：30% 对结果缓存是中等水平。提升方法：1）语义缓存：用 embedding 相似度而非精确匹配，捕捉同义表达；2）模板化：把常见问题抽象为模板（如"{产品}的价格是多少"），提高匹配泛化；3）预热：系统启动时预加载高频查询；4）组合缓存：缓存 RAG 检索结果而非最终回答，让 LLM 基于相同证据回答不同问题。语义缓存通常能把命中率从 30% 提升到 50%+。

• "缓存和一致性怎么平衡？比如知识库更新了，缓存怎么办？"
  • 答：多级失效策略。1）主动失效：知识库更新时，发消息清空相关缓存条目；2）TTL 过期：设置合理过期时间（如 FAQ 24h，实时数据 5min）；3）版本号：缓存 key 包含知识库版本号，更新后自动隔离旧缓存；4）校验抽样：定期抽样检查缓存结果与重新计算的结果是否一致。关键是"最终一致性"——允许短暂不一致，但确保在可接受时间内收敛。

#115. 设计一个支持 1 万并发用户 的企业知识问答系统，你会怎么拆架构？

#标准答案

这种系统更像一个完整平台，而不是单个模型接口。一个稳妥架构通常包括：网关层负责接入、鉴权和限流；查询理解层负责意图识别、改写和任务分流；RAG 检索层负责知识召回与重排；模型路由层负责选择模型和推理链路；缓存层负责减少重复计算；异步日志与评测层负责记录请求、做坏例分析；安全审核层负责权限与内容治理；人工兜底层负责高风险或低置信度场景。

为什么要这么拆？因为 1 万并发 下，瓶颈不只在模型推理，还在接入、检索、缓存、工具调用和观测。面试里最好再补一句：架构目标不是“让模型尽量聪明”，而是“在大并发下仍可控、可降级、可回滚”。

#深度解析

1. 万级并发系统的分层架构

┌─────────────────────────────────────────────────────────┐
│ CDN / WAF（边缘层）                                      │
│ 静态资源、DDoS 防护、地理就近接入                        │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ API Gateway（网关层）                                    │
│ 鉴权、限流、路由、负载均衡、SSL 终止                     │
│ 技术：Kong / Nginx / AWS API Gateway                     │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 查询理解服务（Query Understanding）                      │
│ 意图识别、Query Rewrite、敏感词过滤、任务分流            │
│ 技术：轻量 BERT / 规则引擎                               │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 检索服务集群（RAG Retrieval）                            │
│ Embedding 服务、向量数据库、重排序                       │
│ 技术：Milvus / Pinecone + Cross-Encoder                │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 模型推理集群（Inference）                                │
│ 多模型部署、自动扩缩容、批处理                           │
│ 技术：vLLM / TGI + K8s HPA                               │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 业务服务层（Business Logic）                             │
│ 工具调用、业务系统对接、结果组装                         │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 数据层（Data & Cache）                                   │
│ 知识库、缓存、日志、监控系统                             │
└─────────────────────────────────────────────────────────┘

2. 各层的关键设计参数

3. 容量规划估算

假设 1 万并发用户，平均每个用户每 10 秒发起 1 次请求：

峰值 QPS = 10,000 / 10 = 1,000 QPS

模型推理层：
    ├── 单 GPU（A100）处理能力：~50-100 QPS（取决于模型和序列长度）
    ├── 需要 GPU 数：1,000 / 75 ≈ 14 张 A100
    ├── 考虑峰值冗余（2x）：28 张 A100
    └── 成本：~$50-100K/月（云）

检索层：
    ├── 单次检索延迟：~50ms
    ├── 并发需求：1,000 QPS
    ├── 向量数据库：3-5 个分片节点
    └── Embedding 服务：4-8 个实例

4. 高并发下的关键保障机制

5. 面试官常见深挖追问

• "1 万并发下，如果模型推理层成为瓶颈，怎么扩展？"
  • 答：三层扩展。1）垂直扩展：升级 GPU（A100 → H100），单机处理能力提升 2-3 倍；2）水平扩展：增加模型实例数，负载均衡分发请求；3）效率优化：continuous batching、speculative decoding、量化，单机吞吐量提升 2-4 倍。通常先优化效率（成本低），再水平扩展（弹性好），最后垂直扩展（最直接但最贵）。

• "万级并发下，如何保证知识库更新后所有用户看到最新内容？"
  • 答：最终一致性策略。1）知识库更新走 CI/CD 流水线，自动触发索引重建；2）向量数据库支持在线更新，新文档立即入库，旧文档标记失效；3）缓存层设置 TTL（如 5 分钟），保证最长 5 分钟内刷新；4）对于紧急更新（如错误信息修正），主动推送失效消息到缓存层。不要求所有用户实时看到最新内容，但确保在分钟级收敛。

#116. 如果老板要求“效果尽量好，但预算砍一半”，你会从哪些地方动刀？

#标准答案

第一步不是立刻砍模型，而是先看成本到底花在哪：是大量简单请求都走了大模型，还是 RAG 上下文太长，还是重复请求太多，还是工具链路重试太频繁。只有先做成本拆账，后面的优化才不会瞎砍。

真正动刀时，通常优先做模型分级路由、缓存、上下文压缩、无效请求过滤、RAG 提效和高成本链路瘦身。原则是优先砍“无效昂贵计算”，而不是一刀切把效果核心链路也砍坏。这样回答比直接说“换小模型”更像工程负责人视角，也更符合真实降本顺序，因为先优化浪费项通常最安全、对效果副作用也最小，后续再考虑是否需要调整主模型规格与服务层资源配置。

#深度解析

1. 成本拆解：钱到底花在哪？

总成本 100%
    ├── 模型推理成本（通常 40-60%）
    │       ├── 大模型调用（GPT-4 级别）
    │       └── 小模型调用（GPT-3.5 级别）
    ├── 上下文/token 成本（20-30%）
    │       ├── 系统 prompt
    │       ├── RAG 文档
    │       └── 历史对话
    ├── 检索成本（5-15%）
    │       ├── Embedding 计算
    │       └── 向量数据库查询
    ├── 外部工具成本（5-20%）
    │       ├── API 调用
    │       └── 数据库查询
    └── 基础设施成本（10-20%）
            ├── GPU/CPU 实例
            ├── 存储
            └── 带宽

2. 降本措施的优先级与效果

原则：先砍浪费，再砍规格，最后砍功能。

3. 效果保护的降本策略

策略 1: 分层服务
    ├── VIP 用户 → 大模型（效果优先）
    ├── 普通用户 → 小模型（成本优先）
    └── 免费用户 → 缓存/小模型（极致降本）

策略 2: 动态降级
    ├── 高峰期：小模型 + 缓存
    ├── 低峰期：大模型 + 全功能
    └── 应急：只保留核心功能

策略 3: 效果监控闭环
    ├── 降本后 A/B 测试
    ├── 监控用户满意度、任务完成率
    └── 如果效果下降 >5%，回滚或调整

4. 具体场景的降本方案

5. 面试官常见深挖追问

• "如果砍了 50% 预算后，核心指标掉了 10%，怎么办？"
  • 答：先定位是哪项措施导致的。1）分析指标下降的具体表现：是准确率降了？还是用户满意度降了？还是特定场景出问题？2）回溯最近实施的降本措施，逐一隔离验证；3）如果是模型降级导致，考虑"部分恢复"——只把高风险/高价值场景恢复大模型，其他场景保持小模型；4）如果是缓存导致信息过时，缩短缓存 TTL；5）最终目标：找到"效果损失最小"和"成本降低最大"的帕累托最优。

• "自托管开源模型 vs 调 API，成本差距有多大？"
  • 答：差距显著但非简单替代。以处理 1M tokens 为例：GPT-4 API ≈ $30；自托管 Llama-3-70B（A100 单卡）≈ $3-5（电费+折旧）。但自托管有额外成本：1）运维人力；2）GPU 闲置成本（API 按量付费，自托管需预留容量）；3）效果差距（开源模型通常弱于顶尖闭源模型）。综合看，简单任务自托管可省 60-80%，复杂任务可能省 30-50% 但效果有损失。通常混合策略：简单任务自托管，复杂任务 API。

#117. 如何做一个 LLM gateway，把请求路由到不同模型、不同供应商或不同规格实例？

#标准答案

LLM gateway 的核心，是把不同模型和不同供应商封装到统一入口后，再根据策略做路由与治理。它通常需要统一协议层、鉴权与限流、模型元数据管理、路由策略、失败回退、成本统计、日志与监控，以及版本和灰度控制。否则一旦模型和供应商一多，业务方会被接入细节淹没。

路由依据也不应只看“哪个模型最强”，而要综合任务类型、风险等级、延迟要求、预算、可用区、历史成功率和合规要求。高分回答一般会强调：gateway 的价值不只是转发请求，而是把模型治理和供应商治理抽象成统一控制面，这样业务层才不会和底层供应商强绑定。

#深度解析

1. LLM Gateway 的核心功能模块

┌─────────────────────────────────────────────────────────┐
│ 统一 API 接口（OpenAI-compatible / Custom）              │
│ 业务方只需调用一个端点                                   │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 治理层                                                   │
│ ├── 鉴权（API Key / OAuth）                              │
│ ├── 限流（Rate Limiting）                                │
│ ├── 计费（Cost Tracking）                                │
│ └── 审计（Audit Log）                                    │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 路由层（Routing）                                        │
│ ├── 模型选择（GPT-4 / Claude / Llama）                   │
│ ├── 供应商选择（OpenAI / Anthropic / Azure）             │
│ ├── 地域路由（就近 / 合规）                               │
│ └── 版本路由（模型版本 A/B）                             │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 弹性层（Resilience）                                     │
│ ├── 失败重试（Retry with backoff）                       │
│ ├── 熔断降级（Circuit Breaker）                          │
│ ├── 超时控制（Timeout）                                  │
│ └──  fallback（主供应商失败切备用）                       │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 供应商适配层                                             │
│ 统一不同供应商的 API 差异                                │
└─────────────────────────────────────────────────────────┘

2. 路由策略的设计

3. 多供应商治理的关键问题

4. Gateway 的技术实现

# 伪代码示例
class LLMGateway:
    def route(self, request):
        # 1. 鉴权
        user = authenticate(request.api_key)

        # 2. 限流检查
        if not self.rate_limiter.allow(user):
            return RateLimitError()

        # 3. 路由决策
        strategy = self.select_strategy(request)
        provider = strategy.choose_provider(request)
        model = strategy.choose_model(request)

        # 4. 调用供应商
        try:
            response = provider.call(model, request)
        except ProviderError:
            # 5. Failover
            fallback = strategy.get_fallback()
            response = fallback.call(model, request)

        # 6. 记录日志和计费
        self.log(request, response, provider, model)
        self.charge(user, response.tokens)

        return response

5. 面试官常见深挖追问

• "如果两个供应商的同一模型效果有差异，Gateway 怎么处理？"
  • 答：建立"效果基准测试"。1）定期用同一批测试集评测各供应商的同规格模型；2）建立效果评分卡（准确率、延迟、可用性）；3）路由时参考评分卡，优先选择评分高的供应商；4）对效果差异大的场景（如特定语言、特定领域），建立"领域-供应商"映射表。关键是不要假设"同名模型效果相同"，要持续监控和验证。

• "Gateway 本身成为单点故障怎么办？"
  • 答：多层高可用设计。1）Gateway 服务本身多实例部署，前置负载均衡；2）Gateway 状态（如限流计数）存储在分布式缓存（Redis Cluster），单实例故障不丢失状态；3）路由配置存储在配置中心（如 Consul），支持动态更新；4）最极端情况，客户端支持直连供应商的 fallback 机制。Gateway 是基础设施，其可用性要求高于业务服务。

#118. 你如何设计 prompt 管理、版本管理、AB 实验和回滚？

#标准答案

prompt 不应该散落在代码里当匿名字符串，而应该配置化、版本化管理。每次改 prompt，都应有版本号、变更说明、适用场景和依赖模型记录；同时支持灰度发布，让一小部分流量先验证效果，而不是全量直接切换。

AB 实验则要和明确指标绑定，比如成功率、用户满意度、成本、时延、人工转接率，而不是只凭主观感觉。回滚能力同样关键：一旦指标恶化，要能快速切回上一个稳定版本。所以这题的关键不是“会写 prompt”，而是会把 prompt 当成正式生产资产来治理，而不是临时经验或散落脚本，并且让变更可审计、可回放。

#深度解析

1. Prompt 管理的系统化方案

Prompt 仓库（Git / 配置中心）
    │
    ├── 目录结构
    │       ├── prompts/
    │       │       ├── customer_service/
    │       │       │       ├── v1.0.0.yaml
    │       │       │       ├── v1.1.0.yaml
    │       │       │       └── v1.2.0_beta.yaml
    │       │       └── code_generation/
    │       │               └── v2.0.0.yaml
    │       └── templates/
    │               └── common_prefix.yaml
    │
    └── 每个 prompt 文件的元数据
            ├── version: "1.2.0"
            ├── model: "gpt-4-turbo"
            ├── temperature: 0.7
            ├── description: "客服场景主 prompt"
            ├── author: "zhangsan"
            ├── created: "2026-01-15"
            └── tags: ["客服", "中文", "正式版"]

2. 版本管理策略

3. AB 实验设计

实验设计
    ├── 假设：新 prompt v1.2 比 v1.1 用户满意度高 5%
    ├── 指标
    │       ├── 主要指标：用户满意度、任务完成率
    │       ├── 次要指标：成本、延迟、人工转接率
    │       └── 护栏指标：错误率、安全事件数
    ├── 流量分配
    │       ├── 对照组：50% 流量走 v1.1
    │       └── 实验组：50% 流量走 v1.2
    ├── 实验时长
    │       └── 至少 1 周（覆盖不同日期模式）
    └── 成功标准
            └── 主要指标提升显著（p < 0.05）且护栏指标无恶化

4. 回滚机制

回滚实现：配置中心保存最近 N 个稳定版本，切换时只需修改版本号指针，无需重新部署服务。

5. 面试官常见深挖追问

• "Prompt 版本多了以后，怎么管理依赖关系？比如 prompt A 引用了 prompt B 的公共前缀。"
  • 答：用"模板继承"机制。1）公共部分（如系统角色定义）做成基础模板；2）业务 prompt 通过"继承+覆盖"引用基础模板；3）版本管理时，基础模板升级会自动影响所有继承者，但继承者可以选择锁定基础模板版本。类似于软件包管理（如 npm 的 dependency），明确声明依赖的版本范围，避免"隐式依赖导致意外变更"。

• "AB 实验中，如果实验组效果比对照组好，但成本高 30%，怎么决策？"
  • 答：这取决于业务目标。1）如果是高价值场景（如付费用户），且满意度提升带来留存/付费增长 > 成本增加，选择上线；2）如果是普通场景，需要评估 ROI：每单位成本提升带来的效果增益是否值得；3）可以考虑"分层策略"：只对高价值用户启用新 prompt，普通用户保持原方案。AB 实验的结论不是"好就上"，而是"在约束条件下是否值得上"。

#119. 如果线上投诉激增，你会先看哪些指标，先排查哪几层？

#标准答案

先不要陷进单个案例，而要先看系统性指标有没有突变：流量是否异常、错误率和超时是否飙升、平均时延是否拉长、成本是否突然升高、模型路由是否变了、RAG 命中率是否下降、工具成功率是否变差、安全拦截是否突然增多。先找“什么时候开始出问题”和“哪一层一起变化”。

然后再按链路逐层排查：接入层、检索层、模型层、工具层、输出层。最后再抽具体 bad case 做深挖，确认是新 prompt 引入的问题、路由变更的问题、知识库更新的问题，还是供应商质量波动。这样回答体现的是系统化排障，而不是凭感觉猜，也更符合真实事故处理流程。

#深度解析

1. 投诉激增的"黄金 5 分钟"排查法

第 1 分钟：看大盘
    ├── 流量是否异常突增？（DDoS / 推广活动）
    ├── 错误率是否飙升？（系统性故障）
    └── 时延是否拉长？（资源瓶颈）

第 2 分钟：看分层
    ├── 接入层：QPS、并发、限流触发次数
    ├── 检索层：RAG 召回率、检索延迟
    ├── 模型层：模型错误率、路由分布、供应商状态
    ├── 工具层：工具成功率、外部 API 状态
    └── 输出层：安全拦截率、格式错误率

第 3 分钟：看变更
    ├── 最近 24h 是否有发布？（代码 / prompt / 模型）
    ├── 是否有配置变更？（路由规则 / 阈值）
    └── 供应商是否有异常？（Status Page）

第 4 分钟：看关联
    ├── 投诉类型分布（技术问题？体验问题？）
    ├── 用户群体（新用户？老用户？特定地区？）
    └── 时间模式（突发？渐进？周期性？）

第 5 分钟：定位根因
    └── 确认是变更导致 → 回滚
    └── 确认是外部依赖 → 降级 / failover
    └── 确认是容量不足 → 扩容
    └── 确认是未知问题 → 启动应急小组

2. 关键指标的异常模式识别

3. 逐层排查清单

4. 事故响应的分级处理

5. 面试官常见深挖追问

• "如果所有指标都正常，但投诉确实在增加，可能是什么原因？"
  • 答：这是最难排查的"隐式故障"。可能原因：1）效果漂移：模型输出风格变化，用户不适应（如从正式变口语化）；2）竞品效应：竞品推出新功能，用户预期提高；3）样本偏差：投诉来自特定群体（如新用户），整体指标被老用户"平均"掉了；4）情绪累积：小问题长期未修复，用户忍耐到达阈值。排查方法：1）分层分析（新老用户、不同地区）；2）人工抽样 bad case；3）对比投诉前后输出样本的差异；4）用户调研。

• "排查时如何区分'供应商问题'和'我们自己的问题'？"
  • 答：快速验证三步法。1）直连测试：绕过我们自己的系统，直接调用供应商 API 测试相同输入，如果问题复现 → 供应商问题；2）多供应商对比：同一输入发给多个供应商，如果只有一家出问题 → 该供应商问题；3）历史对比：对比该供应商历史输出和当前输出，如果风格/质量突变 → 供应商模型更新导致。自己的问题通常有变更记录可追踪，供应商问题需要去供应商 status page 确认。

#120. 你如何判断某个业务应该上纯 LLM、RAG、Agent，还是传统规则 + 小模型？

#标准答案

判断一个业务适合哪种方案，核心不是看技术热度，而是看任务本质。若流程稳定、规则清晰、容错低、调用频繁，传统规则加小模型通常更稳、更便宜；若核心问题是知识频繁更新、需要可追溯证据，RAG 更合适；若任务需要多步决策、调用外部工具并根据反馈持续推进，才更像 Agent；若只是开放式生成或简单问答，纯 LLM 可能已经够用。

现实里很多系统最后不是四选一，而是混合：规则负责边界和兜底，小模型负责分类和过滤，RAG 负责知识，Agent 负责复杂执行。面试里这样答，说明你能把技术选型建立在业务约束上，而不是追风口。

#深度解析

1. 技术选型的四维决策框架

                    知识确定性
                        ↑
    规则+小模型 ←───────┼───────→ RAG
    （流程固定）         │      （知识需更新）
                        │
    简单性 ←────────────┼──────── 复杂性
                        │
    纯 LLM ←────────────┼───────→ Agent
    （开放式问答）       │      （多步决策+工具）
                        ↓
                    任务开放性

2. 四种方案的能力边界对比

3. 典型场景的选型决策

4. 混合架构的设计原则

用户请求
    │
    ├── 第一层：规则过滤
    │       ├── 黑名单/敏感词 → 直接拒绝
    │       ├── 简单模板匹配 → 直接回答
    │       └── 无法规则处理 → 进入下一层
    │
    ├── 第二层：意图分类（小模型）
    │       ├── FAQ 类 → RAG 检索回答
    │       ├── 闲聊类 → 纯 LLM 生成
    │       └── 业务操作类 → Agent 处理
    │
    └── 第三层：各方案执行
            ├── RAG：检索 → 生成 → 引用校验
            ├── LLM：直接生成
            └── Agent：规划 → 工具调用 → 执行

5. 选型常见陷阱

6. 面试官常见深挖追问

• "如果一个业务现在用规则，但老板想上 LLM，你怎么说服他？"
  • 答：不是说服不上，而是评估是否值得。1）量化当前规则的覆盖率和维护成本——如果规则已经覆盖 95% 场景且维护成本可控，上 LLM 的收益有限；2）识别规则无法处理的场景（如开放式问答、语义理解），这些才是 LLM 的价值点；3）提案"渐进式迁移"：先在小模型/LLM 处理规则覆盖不了的场景，逐步扩展；4）给出 ROI 估算：投入成本 vs 预期收益（用户满意度提升、人工介入减少）。用数据说话，而不是用技术热度说服。

• "四选一之后，怎么判断要不要升级或降级？"
  • 答：建立"方案健康度"指标。1）规则+小模型：规则膨胀度（规则数/月增速 > 20% 说明该升级）、覆盖率；2）纯 LLM：幻觉率、用户满意度；3）RAG：检索准确率、答案忠实度；4）Agent：任务完成率、平均步数、工具成功率。当当前方案的健康度指标持续恶化，且瓶颈无法通过调优解决时，考虑升级。反之，如果上层方案维护成本过高、但效果提升有限，考虑降级。