强模型直连与本地模型 + RAG + Prompt 优化，应如何按成本、延迟、安全和效果取舍？｜快手后端开发面经解析

60 秒回答模板

我不会先说哪种方案一定更好，而是先看业务约束。如果任务依赖强推理、复杂泛化、多语言或长链路规划，且数据可以外发、成本可接受，强模型直连通常上线更快、效果上限更高。如果任务主要依赖企业私有知识、数据敏感、响应 SLA 可控、调用量大且问题域稳定，本地模型 + RAG + Prompt 优化可能更适合，因为知识可控、数据边界清楚、长期边际成本可能更低。但本地方案不是免费午餐，它要维护文档解析、切分、embedding、向量库、rerank、权限、新鲜度、提示词和模型服务。评估时我会用同一批真实任务比较正确率、幻觉、覆盖率、延迟 P95/P99、单次成本、峰值容量、安全边界和故障降级。实际架构常是混合路由：敏感或高频标准问题走本地 RAG，复杂推理或低置信样本升级到强模型，并保留回退、审计和持续评测。

考点 决策矩阵

难度 真实面经题

回答目标 讲清模型架构取舍

深入解析

先看任务和约束

这个选择不是模型参数大小的简单比较，而是业务目标、数据边界、成本结构和 SLA 的综合取舍。要先明确任务是知识问答、代码生成、复杂推理、客服流程、内容生成还是内部助手，再判断对私有知识、实时性、稳定性和安全的要求。

强模型直连的优势和风险

强模型直连通常工程链路短、通用能力强、推理和指令遵循更好，适合复杂、多变、难以穷举的任务。风险是外部依赖、单次成本、延迟波动、数据出域、供应商可用性和可解释性限制。如果场景有严格数据边界，就不能只看效果分数。

本地模型加 RAG 的价值和代价

本地模型 + RAG + Prompt 优化适合私有知识密集、问题域稳定、权限复杂或调用量较大的场景。它的价值是知识可更新、数据可控、引用可追溯，并且可以按业务做提示词和检索策略。但代价是需要维护知识库、索引、embedding、rerank、缓存、模型服务和评测体系。

效果评估要按真实任务比较

两类方案要用同一批真实任务评估，包括答案正确性、事实一致、引用支持、拒答合理、复杂推理成功率、长尾覆盖和人工验收。RAG 方案不能只看召回率，强模型方案也不能只看单轮回答质量，都要看最终任务是否完成。

性能和成本要看整体链路

强模型成本主要来自外部推理和 token；本地方案成本来自 GPU、服务运维、向量库、embedding、rerank 和知识更新。延迟也要拆分为检索、rerank、prompt 构造、排队、推理和网络。只有把峰值并发、P95/P99 和失败降级一起算，成本结论才可靠。

混合路由通常更稳

实际系统可以按数据敏感度、问题类型、置信度、成本预算和延迟 SLA 做路由：高频标准问题走本地 RAG，复杂推理或低置信问题走强模型，敏感问题留在本地或人工处理。关键是有统一评测、审计、兜底和回退，而不是把选择做成一次性拍板。

易错点

直接说强模型一定更好，忽略数据安全、成本和供应商依赖。
直接说本地模型更省钱，忽略 GPU、运维、索引和知识更新成本。
把 RAG 当成万能补丁，忽略复杂推理、证据误用和召回失败。
只比较单轮回答效果，不比较真实任务成功、P95/P99 和故障降级。
没有混合路由和 fallback，导致复杂样本或敏感样本没有合适处理路径。

面试官追问

什么情况下强模型直连更合适？

任务复杂、变化快、需要强推理或泛化能力，数据可以合规外发，且延迟和成本可接受时，强模型直连通常更快落地。

什么情况下本地模型 + RAG 更合适？

私有知识密集、数据敏感、权限复杂、问题域稳定、调用量大或需要可追溯引用时，本地 RAG 更有优势。

为什么 RAG 方案不能只看召回率？

召回到相关文档不代表答案正确。还要看证据是否被正确使用、是否减少幻觉、最终任务是否完成以及延迟成本是否可接受。

混合路由怎么设计？

可以按数据敏感度、任务类型、模型置信度、检索命中质量、成本预算和 SLA 做路由，并保留低置信升级、失败回退和人工兜底。

如何避免本地方案越做越复杂？

先用真实任务集验证本地方案能解决的核心问题，再逐步引入 rerank、缓存、微调和复杂路由。每个组件都要有明确收益指标。