#模块十：系统设计、业务落地与成本权衡知识点
系统设计题不要从“选哪个大模型”开始，而要从业务闭环开始。一个 LLM 项目至少要先回答六件事：用户是谁、任务是什么、输入输出边界在哪里、失败代价有多高、业务收益如何量化、现有流程中哪些环节必须保留。客服系统、企业知识库、销售助手、代码助手和风控审核看起来都能接入 LLM，但它们的风险模型完全不同：客服更关心首响、解决率和升级人工比例；企业知识问答更关心引用可信度和权限隔离；代码助手更关心可运行性、上下文隐私和回滚成本。需求阶段如果只写“提升回答质量”，后面评测、预算和上线策略都会失焦。
从需求到架构的主链路
一个可落地的 LLM 应用通常拆成接入层、会话层、上下文构造层、模型层、工具层、评测观测层和人工兜底层。接入层负责鉴权、租户隔离、限流、审计和流式连接；会话层维护用户状态、历史摘要和多轮任务进度；上下文构造层决定是否做 RAG、是否读取用户画像、是否拼接业务规则；模型层负责模型路由、参数配置、响应解析和供应商容灾；工具层把搜索、下单、工单、数据库查询等动作封装成受控能力；评测观测层记录输入、检索证据、模型输出、工具调用、延迟、成本与用户反馈；人工兜底层处理低置信、高风险、投诉和合规场景。面试时要把这条链路讲成数据流，而不是堆模块名。
数据层决定系统上限。离线数据包括知识库文档、FAQ、历史工单、人工标注、失败案例和业务规则；在线数据包括用户问题、点击、追问、转人工、满意度、投诉和实际成交。文档进入 RAG 前要做清洗、分块、去重、权限标签、版本号和过期策略；日志进入训练或评测前要脱敏、抽样、标注失败类型。很多项目效果不稳定，并不是模型不够强，而是知识源混乱、同义问题没有归并、文档权限没有进入检索过滤、历史回答无法回放。
模型、检索与工具怎么选
纯 LLM 适合开放写作、总结、改写和低风险推理；RAG 适合知识更新快、答案必须可追溯、企业私有知识较多的场景；Agent 适合需要多步规划和调用外部系统的任务；传统规则加小模型适合路径稳定、可解释性强、风险高或成本极敏感的流程。实际系统往往是混合方案：先用规则过滤非法请求，用小模型做意图识别和风险分级，对常见问题命中缓存或 FAQ，对知识问题走检索和重排，对复杂任务才进入大模型或工具编排。
检索链路要拆开看：query rewrite 负责把口语问题转成可检索表达；embedding 召回负责覆盖率；BM25 或关键词召回补足专名、数字和代码；reranker 提升前几条证据的相关性；上下文压缩控制 token；引用与证据对齐降低幻觉。工具调用则要强调“可控执行”：schema 要清晰，参数要校验，权限要最小化，副作用操作要二次确认，失败要返回结构化错误。不能让模型直接拥有任意数据库查询或生产写权限，否则一次幻觉就可能变成真实业务事故。
成本要拆到账本里
LLM 成本不能只看 API 单价。第一类是 token 成本，包括输入 prompt、历史上下文、检索片段、工具返回和输出 token；输入越长、输出越啰嗦、历史越不裁剪，成本就越线性上涨。第二类是 GPU 或推理服务成本，包括实例租赁、显存占用、KV cache、并发峰值、负载不均和冷启动冗余。第三类是检索成本，包括 embedding 生成、向量库查询、rerank、索引构建、文档增量更新和存储。第四类是人工成本，包括标注、质检、红队、投诉处理、人工兜底和运营维护。第五类是缓存与基础设施成本，包括 prompt cache、prefix cache、embedding cache、检索结果 cache、最终答案 cache、日志存储和监控告警。
降本的顺序应该先看流量和失败分布，而不是全局降模型。高频稳定问题先缓存或 FAQ 化；低价值请求先拒绝或降级；简单意图走小模型；高风险高价值请求才上强模型；长上下文先做摘要、裁剪、检索压缩和结构化状态；输出长度用模板约束；离线批处理替代同步生成；多供应商路由按能力、价格、可用区和延迟动态选择。关键 insight 是：成本优化不是把所有请求变便宜，而是把昂贵计算留给真正影响业务指标的请求。
质量、延迟、安全与可维护性的权衡
质量和延迟经常冲突：更强模型、更多检索、更多重排、更长上下文会提高回答上限，但会增加首 token 延迟和总耗时。流式输出能改善感知延迟，也便于用户中途打断，但不一定降低总 wall-clock；如果后端还要等工具调用或完整审核，流式收益会打折。安全和体验也冲突：越严格的审核、权限过滤和人工复核越安全，但误杀会降低解决率。可维护性和短期效果也冲突：把规则写死在 prompt 里上线快，但版本不可追踪、实验不可复现；配置化 prompt、模型路由、评测集和回滚机制前期更重，长期更可控。
SLA 要分层设计。接入层设置 rate limiting、配额和租户隔离，保护预算和资源；检索层设置超时和降级，向量库不可用时可退到关键词或静态 FAQ；模型层设置 fallback，主模型失败时切到备选模型、小模型摘要或人工工单；工具层设置幂等、重试和熔断，避免重复扣款、重复下单或循环调用。灰度发布时按租户、流量比例、意图类型或风险等级逐步放量；回滚必须能同时回滚 prompt、模型版本、检索索引、工具 schema 和路由规则。只有能回放请求、复现实验、快速关停坏版本，系统才算可运营。
指标体系：模型指标不等于业务指标
离线模型指标包括准确率、拒答率、引用命中率、幻觉率、工具调用成功率、格式遵循率、安全违规率和人工偏好胜率；系统指标包括 p50/p95/p99 延迟、首 token 延迟、超时率、错误率、吞吐、队列长度、缓存命中率、单请求成本和单位 token 成本；业务指标包括自助解决率、转人工率、一次解决率、用户满意度、投诉率、留存、成交、客服人效和合规事故数。面试回答要主动区分这些指标，因为模型在 benchmark 上变好，不代表业务一定变好：如果回答更长导致延迟上升、用户退出增加，业务指标可能下降。
评测应采用“离线集 + 影子流量 + 灰度 AB + 线上监控”的闭环。离线集覆盖高频、长尾、高风险、越权、注入攻击、过期知识和工具失败；影子流量只记录新方案输出不影响用户；灰度 AB 绑定业务指标和成本指标；线上监控把失败样本自动进入复盘队列。不要只看平均分，要看分桶：不同意图、不同知识库、不同租户、不同模型路由、不同文档版本的表现可能完全不同。
常见误区与复盘清单
- 误区一：先接大模型再补工程。 正确做法是先定义业务闭环、失败代价、数据权限和回滚边界，再选模型和架构。
- 误区二：把 RAG 当万能药。 检索只能提供证据，不能自动保证答案正确；分块、召回、重排、压缩、引用对齐和权限过滤都要单独评测。
- 误区三：只优化 prompt。 线上投诉激增时应先看发布变更、流量分布、错误率、延迟、检索命中、模型供应商、工具失败和安全拦截，再定位 prompt。
- 误区四：只看 token 单价。 真正的账本还包括 GPU 闲置、检索重排、日志存储、人工质检、标注、事故处理和供应商切换成本。
- 误区五：没有 fallback 却承诺 SLA。 SLA 必须绑定超时、重试、降级、人工兜底、状态页、告警和回滚演练。
复盘一个 LLM 项目，可以按清单追问：需求是否有可量化业务指标？数据是否脱敏、分权、可追溯？RAG 是否按召回、重排和引用分别评测？工具调用是否有权限、幂等和审计？模型路由是否解释了为什么用强模型、弱模型或供应商切换？成本是否按 token、GPU、检索、人工、缓存拆开？上线是否有灰度、回滚、fallback 和告警？失败样本是否能回放并进入下一轮评测集？如果这些问题答不上来，系统还停留在 demo 层。
面试追问链路
面试官通常会沿着“设计客服系统”继续追问：如果预算砍半怎么做、如果一万并发怎么扩、如果投诉激增怎么排查、如果模型供应商故障怎么兜底、如果知识库泄漏怎么防、如果老板只看业务增长怎么证明价值。回答时可以固定成一条链：先澄清场景和 SLA，再画请求链路；再说明数据、检索、模型、工具和人工兜底；接着给成本账本和降本优先级；然后给评测指标、灰度回滚和监控告警；最后讲 trade-off。优秀答案不是追求“全都上最强模型”，而是能说明每一块为什么存在、何时降级、失败如何发现、成本如何解释、业务指标如何闭环。