本地模型跑 RAG 质量不稳？试试这套级联验证机制降低 Token 成本
最近我在优化一套企业内部知识库的链路，尝试通过构建一套“级联验证循环”来平衡成本与质量。核心逻辑不再是单一的模型输出，而是在本地模型和旗舰模型之间建立一道“质量防火墙”。
具体的操作链路可以分为三个层级：初筛层、验证层和兜底层。
首先是初筛层，这里部署量化后的本地模型（我目前测试的是 Qwen2-7B-Instruct 的 4-bit 量化版本）。这一层的作用是快速处理检索到的文档片段并尝试生成答案。由于大多数 RAG 场景中的问题其实相对简单，本地模型在 70% 的情况下能够给出及格的回答。
关键点在于接下来的验证层。这一层同样由本地模型执行，但它不再负责生成答案，而是扮演一个“审核员”的角色。我会通过一套极其严苛的 Prompt 强制模型对比原文档与生成的答案。如果答案中包含任何幻觉，或者遗漏了 Context 中的关键事实，验证层必须输出 FAIL，否则输出 PASS。
这里分享一个我实操中比较有效的验证 Prompt 逻辑：
# Validation Prompt
Context: {{retrieved_chunks}}
Generated Answer: {{local_answer}}
Task: Compare the Generated Answer against the Context.
If the answer contains any hallucinations or missing critical facts from the context, return "FAIL".
If it is fully supported and accurate, return "PASS".
Output only one word: PASS or FAIL.只有当验证层明确返回 FAIL 时，系统才会触发兜底层，将该请求向上抛给托管的旗舰模型 API 进行最终生成。这样一来，昂贵的 Token 消耗被限制在了极少数的“疑难杂症”请求中。
但在实际部署过程中，我踩到了一个非常关键的坑：验证层的模型规模决定了这套机制是否有效。
在对 20 多个不同规模的本地模型进行对比测试时我发现，如果验证层使用的模型参数量在 7B 以下，其“自省”能力非常弱，极易出现“盲目自信”的情况——即模型明明生成了错误答案，但在验证环节却给自己打了 PASS。这种情况会导致级联机制直接失效，因为第一层漏检后，请求根本不会到达旗舰模型。
经过多轮测试，我建议验证层至少要使用 14B 或 32B 以上规模的模型（例如 Qwen2-72B 的量化版或 Llama3-70B）。虽然验证层的推理耗时会稍微增加，但它能显著提升拦截准确率，确保只有真正高质量的答案能通过，而真正有问题的请求能被精准地路由到旗舰模型。
总结下来，这套方案将 RAG 的成本结构从“全量付费”变成了“按需付费”。对于追求极致成本控制且对质量有底线要求的项目，这种“本地生成 → 本地验证 → 云端兜底”的级联链路比单纯依赖单一模型要稳健得多。
