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

#代表笔试题

这一章考的不是“会不会调一个模型接口”，而是能不能把 LLM 放进真实业务系统里，做成可上线、可回滚、可观测、成本可控的产品。笔试常见问题会问：设计一个 LLM 客服系统需要哪些模块，如何降低 API 成本，流式输出有什么价值，模型路由解决什么问题，为什么要 rate limiting，以及线上服务哪些地方可以缓存。回答时不要只列“前端、后端、数据库、模型”这种通用架构，而要把 LLM 项目拆成八层：需求 -> 数据 -> 模型 -> 检索/工具 -> 评测 -> 部署 -> 监控 -> 成本。

需求层先明确业务目标、用户群体、使用场景和不能失败的边界。例如企业知识问答的目标可能不是“回答得像人”，而是减少人工工单、缩短新人查资料时间、提升答案可追溯性。数据层要回答知识从哪里来、如何清洗、如何切块、如何更新、权限如何继承，以及历史对话是否能作为训练或评测数据。模型层要决定用通用 API、私有化部署、微调模型、小模型分类器，还是多模型路由。检索/工具层负责把模型接到企业知识库、搜索、数据库、订单系统、工单系统和权限系统。评测层定义离线集、线上反馈、人工抽检和回归测试。部署层处理网关、限流、队列、流式返回、灰度发布和弹性扩缩容。监控层跟踪质量、延迟、错误、安全和成本。成本层则把每次请求到底花在哪里拆清楚。

成本拆解要具体。第一是 token 成本，包括输入 token、输出 token、长上下文、system prompt、历史对话、检索片段和工具调用结果；很多项目的浪费来自把无关上下文全部塞进 prompt。第二是 GPU 或推理实例成本，包括显存占用、批处理效率、KV cache、峰值容量预留和多副本高可用。第三是检索成本，包括 embedding 生成、向量库存储、召回、重排、全文索引和知识库增量更新。第四是人工标注与审核成本，包括构造 golden set、偏好标注、badcase 归因、安全审核和业务专家复核。第五是缓存成本，缓存本身需要存储、失效策略、权限校验和命中率监控，但它能显著降低重复问答、相同检索结果、固定 prompt 模板和 embedding 的开销。

#代表面试题

面试题通常会把系统放进约束里，例如“设计一个支持 1 万并发用户 的企业知识问答系统”“预算砍一半怎么办”“如何做 LLM gateway”“prompt 如何版本管理、AB 实验和回滚”“线上投诉激增先看什么”。一个稳妥答案可以按链路展开：用户请求进入网关，网关做鉴权、租户隔离、限流、trace id 和请求分类；轻量分类器判断是否需要 RAG、工具调用、人工转接或直接拒答；检索服务根据用户权限召回文档，必要时重排和压缩上下文；编排层组装 prompt、选择模型、调用工具；模型服务以流式方式返回；后处理层做引用校验、安全过滤、格式修正和日志采样；最后把反馈、成本、延迟和失败原因写入观测系统。

模型路由是这类系统的核心抓手。简单问题走便宜小模型或缓存，复杂推理走强模型；高风险问题走更保守的模型、强检索和人工复核；供应商异常时切到备用供应商；内部模型置信度低时 fallback 到“无法确认 + 给出处 + 转人工”。这里的关键不是“模型越多越好”，而是路由规则必须可解释、可回放、可评测。否则线上效果变差时，很难判断是召回问题、prompt 版本问题、模型漂移问题，还是路由误判。

灰度和回滚要像传统工程一样严肃。prompt、chunk 策略、embedding 模型、重排模型、工具 schema、主模型版本都应该有版本号和配置中心。新版本先在离线评测集过关，再对内部用户或低风险流量灰度，观察业务指标和模型指标，最后逐步放量。回滚不能只回滚代码，还要能回滚 prompt、索引、路由策略和模型配置。fallback 也要预先设计：超时时返回缓存答案或精简答案，检索失败时提示知识库不可用，模型失败时切供应商，工具调用失败时降级为只读问答，安全风险过高时拒答或转人工。

SLA 需要同时覆盖可用性、延迟和质量。可用性可以用成功率、5xx、超时率衡量；延迟要拆成网关、检索、重排、模型首 token、完整输出、工具调用等阶段，并关注 P95/P99，而不是只看平均值；质量要用命中率、引用准确率、解决率、人工接管率、投诉率和 badcase 复现率衡量。对于客服、医疗、金融、法务等场景，还要单独定义安全 SLA，例如敏感信息泄露率、越权访问率、错误建议率和高风险拒答覆盖率。

#这一块真正考什么

这一块真正考的是系统权衡能力：你是否能把“模型能力”转化为“业务系统能力”，并清楚说明每个设计选择牺牲了什么。质量、延迟、安全和可维护性经常相互拉扯。更大的模型通常质量更好，但成本更高、延迟更长、供应商锁定更强；更长上下文能减少信息缺失，但 token 成本上涨，注意力被噪声稀释，首 token 变慢；更强的安全过滤能降低风险，但可能误伤正常请求；更复杂的 Agent 能处理多步任务，但调试难度、失败面和状态管理成本都会上升；更激进的缓存能降低成本和延迟，但可能带来陈旧答案、权限污染和个性化错误。

业务指标和模型指标必须区分。模型指标回答“模型在测试集上好不好”，例如准确率、召回率、faithfulness、引用命中率、toxicity、拒答准确率、工具调用成功率。业务指标回答“系统有没有创造业务价值”，例如工单解决率、人工客服节省时长、平均处理时长、转化率、留存率、用户满意度、单次会话成本、合规事件数。一个模型离线准确率提升 3%，如果主要提升的是低价值问题，线上未必有价值；反过来，模型指标不变，但通过缓存、路由、引用展示和转人工策略降低了投诉率，也可能是更好的业务方案。

常见误区有五类。第一，把 LLM 当数据库，要求它凭空记住企业事实，而不是用 RAG、权限和引用保证可追溯。第二，只优化 prompt，不建设评测集、badcase 库和回归测试，导致每次改动都靠感觉。第三，只看模型单次调用成本，忽略人工标注、知识维护、重排、GPU 空转、峰值容量和安全审核。第四，为了展示“智能”过早上 Agent，实际业务只需要规则、小模型分类和 RAG。第五，没有灰度、回滚和 fallback，把一次 prompt 或索引更新变成线上全量事故。

好的回答还要体现可维护性意识。知识库更新要有增量索引、版本标记和回放能力；prompt 要模板化、参数化、可审计；工具调用要有 schema 校验、超时、重试、幂等和权限边界；日志要能从一次投诉追溯到用户问题、检索结果、prompt 版本、模型版本、输出、安全策略和成本明细。否则系统上线初期看起来能跑，进入真实业务后会很快变成无法解释、无法定位、无法优化的黑盒。

#作答抓手

系统设计题最好的结构通常是：目标与约束 -> 核心链路 -> 关键模块 -> 监控与容错 -> 成本与优化。先问清业务目标、用户规模、数据来源、权限要求、可接受延迟、错误代价和预算上限；再画主链路，说明请求如何经过网关、分类、检索、编排、模型、工具、后处理和反馈；然后逐层说明设计选择。每一层都要能回答“为什么这么做”“不用它会怎样”“失败时怎么降级”。

#追问链路

如果被追问“预算砍一半怎么办”，不要直接说换小模型。更成熟的顺序是：先做用量分析，找高频重复问题、长 prompt、低价值场景和异常流量；再做缓存，包括答案缓存、检索缓存、embedding 缓存、prompt prefix cache 和工具结果缓存；然后做上下文压缩、chunk 优化和重排，只把真正相关内容送进模型；再做模型路由，让简单请求走小模型，复杂请求走大模型；最后才考虑蒸馏、量化、私有化部署或改业务流程。因为降低成本不能牺牲关键业务 SLA，也不能把风险转嫁给用户。

如果被追问“线上投诉激增怎么排查”，按漏斗查：先看是否是全局可用性问题，例如供应商异常、超时、限流、索引服务故障；再看是否是某个版本引起，例如 prompt、模型、索引、重排、工具 schema 或安全策略刚发布；然后抽样投诉会话，比较检索结果是否相关、引用是否支持结论、模型是否编造、工具是否返回错误、后处理是否误拦截；最后把 badcase 归类进评测集，决定是修数据、修检索、修 prompt、修路由、修工具，还是需要人工流程兜底。

如果被追问“纯 LLM、RAG、Agent、规则应该怎么选”，可以用任务风险和外部状态来判断。开放闲聊或低风险改写可以用纯 LLM；需要回答企业事实、政策、文档和可追溯知识时优先 RAG；需要跨系统执行动作、查询订单、创建工单、调用计算器或多步规划时才考虑 Agent/工具编排；高频、确定、可枚举、强合规的流程应优先规则或传统系统。优秀的方案往往不是单一路线，而是规则兜底、小模型分类、RAG 提供证据、强模型处理复杂表达、人工处理高风险边界。

最后可以用一句话收束：LLM 系统设计的重点不是把模型接进去，而是把需求、数据、模型、检索、工具、评测、部署、监控和成本连成闭环；上线前能评测，上线中能灰度，上线后能观测，出问题能回滚，预算变化时能分层降级，这才是业务落地能力。