#十、系统设计、业务落地与成本权衡
#代表笔试题
- 设计一个基于 LLM 的客服系统，最核心的模块有哪些？
- 如何降低 LLM API 成本？
- 流式输出的价值是什么？
- 模型路由（model routing）通常想解决什么问题？
- 什么是 rate limiting，它为什么对 LLM 服务特别重要？
- 线上服务为什么需要缓存？哪些地方可以缓存？
#就地速答
- 问：设计一个基于 LLM 的客服系统，最核心的模块有哪些？
答：一个基于 LLM 的客服系统，核心模块至少包括：请求接入层、用户身份与会话管理、知识检索层、模型调用层、工单/业务系统工具集成层、监控评测层、安全治理层，以及人工兜底机制。更具体一点讲，用户请求进来后，系统要先知道这个用户是谁、历史上下文是什么、是否命中已有 FAQ 或缓存；如果进入 LLM 链路，就要先检索知识，再决定是否调用订单、退款、物流等工具，最后把结果输出给用户。详见后文“### 109. 设计一个基于 LLM 的客服系统，最核心的模块有哪些？”。
- 问：如何降低 LLM API 成本？
答：降低 LLM API 成本，最重要的原则不是“统一换小模型”，而是让昂贵算力只花在真正值得的请求上。常见方法包括：做模型分级路由，让简单请求走小模型；做缓存，减少重复问答；压缩上下文和历史消息，减少无效 token；提升 RAG 精度，避免把大量噪声文档塞进 prompt；让小模型先做分类、过滤、改写，难题再升级到大模型。详见后文“### 110. 如何降低 LLM API 成本？”。
- 问：流式输出的价值是什么？
答：流式输出最大的价值，是显著改善用户体感。即使总完成时间没变，只要用户能更早看到首 token 或首段结果，等待焦虑就会明显下降，产品会显得“更快、更活”。这对长回答、搜索辅助、代码解释、客服对话尤其重要。详见后文“### 111. 流式输出的价值是什么？”。
- 问：模型路由（model routing）通常想解决什么问题？
答：模型路由要解决的核心问题，是不同请求并不值得同样昂贵的模型和同样慢的链路。简单问答、模板任务、低风险请求，完全没必要一律走最大模型；而复杂推理、高价值客户、高风险任务，又不能随便降配。模型路由就是把“请求特征”和“模型能力/成本”匹配起来。详见后文“### 112. 模型路由通常想解决什么问题？”。
- 问：什么是 rate limiting，它为什么对 LLM 服务特别重要？
答：rate limiting 就是对请求频率、并发规模或资源消耗做限制，防止某个用户、某类流量或某个异常模式把系统拖垮。对 LLM 服务尤其重要，因为模型调用成本高、时延长、资源敏感，一旦被恶意刷接口、脚本误调或突发流量打爆，损失会比普通 Web 服务大得多。详见后文“### 113. 什么是 rate limiting，它为什么对 LLM 服务特别重要？”。
- 问：线上服务为什么需要缓存？哪些地方可以缓存？
答：线上服务需要缓存，因为很多成本其实花在重复计算上。相同或高度相似的问题、相同的系统 prompt 前缀、重复文档的 embedding、重复的 RAG 召回结果，都可能一遍又一遍地被算。如果不缓存，系统会白白消耗 token、GPU 和外部 API 费用。详见后文“### 114. 线上服务为什么需要缓存？哪些地方可以缓存？”。
#代表面试题
- 设计一个支持
1 万并发用户的企业知识问答系统，你会怎么拆架构？ - 如果老板要求“效果尽量好，但预算砍一半”，你会从哪些地方动刀？
- 如何做一个 LLM gateway，把请求路由到不同模型、不同供应商或不同规格实例？
- 你如何设计 prompt 管理、版本管理、AB 实验和回滚？
- 如果线上投诉激增，你会先看哪些指标，先排查哪几层？
- 你如何判断某个业务应该上纯 LLM、RAG、Agent，还是传统规则 + 小模型？
#就地速答
- 问：设计一个支持
1 万并发用户的企业知识问答系统，你会怎么拆架构？答：这种系统更像一个完整平台，而不是单个模型接口。一个稳妥架构通常包括：网关层负责接入、鉴权和限流；查询理解层负责意图识别、改写和任务分流；RAG 检索层负责知识召回与重排；模型路由层负责选择模型和推理链路；缓存层负责减少重复计算；异步日志与评测层负责记录请求、做坏例分析；安全审核层负责权限与内容治理；人工兜底层负责高风险或低置信度场景。详见后文“### 115. 设计一个支持
1 万并发用户的企业知识问答系统，你会怎么拆架构？”。 - 问：如果老板要求“效果尽量好，但预算砍一半”，你会从哪些地方动刀？
答：第一步不是立刻砍模型，而是先看成本到底花在哪：是大量简单请求都走了大模型，还是 RAG 上下文太长，还是重复请求太多，还是工具链路重试太频繁。只有先做成本拆账，后面的优化才不会瞎砍。详见后文“### 116. 如果老板要求“效果尽量好，但预算砍一半”，你会从哪些地方动刀？”。
- 问：如何做一个 LLM gateway，把请求路由到不同模型、不同供应商或不同规格实例？
答：LLM gateway 的核心，是把不同模型和不同供应商封装到统一入口后，再根据策略做路由与治理。它通常需要统一协议层、鉴权与限流、模型元数据管理、路由策略、失败回退、成本统计、日志与监控，以及版本和灰度控制。否则一旦模型和供应商一多，业务方会被接入细节淹没。详见后文“### 117. 如何做一个 LLM gateway，把请求路由到不同模型、不同供应商或不同规格实例？”。
- 问：你如何设计 prompt 管理、版本管理、AB 实验和回滚？
答：prompt 不应该散落在代码里当匿名字符串，而应该配置化、版本化管理。每次改 prompt，都应有版本号、变更说明、适用场景和依赖模型记录；同时支持灰度发布，让一小部分流量先验证效果，而不是全量直接切换。详见后文“### 118. 你如何设计 prompt 管理、版本管理、AB 实验和回滚？”。
- 问：如果线上投诉激增，你会先看哪些指标，先排查哪几层？
答：先不要陷进单个案例，而要先看系统性指标有没有突变：流量是否异常、错误率和超时是否飙升、平均时延是否拉长、成本是否突然升高、模型路由是否变了、RAG 命中率是否下降、工具成功率是否变差、安全拦截是否突然增多。先找“什么时候开始出问题”和“哪一层一起变化”。详见后文“### 119. 如果线上投诉激增，你会先看哪些指标，先排查哪几层？”。
- 问：你如何判断某个业务应该上纯 LLM、RAG、Agent，还是传统规则 + 小模型？
答：判断一个业务适合哪种方案，核心不是看技术热度，而是看任务本质。若流程稳定、规则清晰、容错低、调用频繁，传统规则加小模型通常更稳、更便宜；若核心问题是知识频繁更新、需要可追溯证据，RAG 更合适；若任务需要多步决策、调用外部工具并根据反馈持续推进，才更像 Agent；若只是开放式生成或简单问答，纯 LLM 可能已经够用。详见后文“### 120. 你如何判断某个业务应该上纯 LLM、RAG、Agent，还是传统规则 + 小模型？”。
#这一块真正考什么
- 是否能把“模型能力”转化成“业务系统能力”。
- 是否有成本、延迟、稳定性、可维护性意识。
#作答抓手
系统设计题最好的结构通常是：目标与约束 -> 核心链路 -> 关键模块 -> 监控与容错 -> 成本与优化。