Agentic RAG · 模型选型与小模型特性
面试亮点专题 · 从 v9 实验现象出发，建立 Agentic RAG 的模型选型判断框架
一、Meta-Cognition 是什么，Self-RAG 为什么需要它
Self-RAG 的核心设计：LLM 自主判断是否需要检索。
这要求模型同时完成三件事：
1. 判断知识边界
"这个问题在我的参数里有没有可靠答案？"
2. 理解工具语义
"search_rag 是用来做什么的，什么时候应该调用它？"
3. 遵从系统指令优先级
"即使我认为自己知道答案，系统要求先检索，我也要先检索"
这三件事合起来就是 meta-cognition（元认知）：对自身知识状态的认知和管理能力。
二、模型规模 vs Self-RAG 可靠性
| 规模 | 表现 | 备注 |
|---|---|---|
| 7B（Qwen2.5-7B） | 不稳定，经常跳过工具调用 | v9 实验的直接观察 |
| 14B | 基本可用，偶有跳过 | 边界区域，不建议生产 |
| 32B+ | 稳定 | 本地部署 Self-RAG 推荐下限 |
| 70B+（Llama 3.3-70B） | 可靠 | |
| GPT-4o / Claude 3.5+ | 非常可靠 | API 模型额外受 RLHF 优化工具调用 |
v9 的实验现象（Qwen2.5-7B）：
问题：RAG 的分块推荐用多大？（应检索）
实际：0 次工具调用，直接用参数记忆回答，数字还是错的（256-1024 token）
问题：评估 RAG 需要关注哪些指标？（应检索）
实际：0 次工具调用，从通用知识直接回答
Multi-hop 复合问题：
实际：只检索 1 次就停止，没有分解子问题继续检索
根本原因：7B 模型对”我知道这个”的判断阈值太低，遇到训练数据覆盖的话题就短路。
三、小模型的其他已知特性
1. 指令跟随降级
症状：System Prompt 越复杂，遵从率越低
- 多条规则并存时，选择性忽略部分规则
- 格式要求（JSON/XML）容易错位或截断
- "禁止做X"的负向指令比"必须做Y"更难遵从
v9 的 system prompt 有 4-5 条规则，7B 倾向于只执行前 2 条
2. 上下文窗口利用率低（“头尾记忆”效应）
大模型（70B+）能有效利用 32K context 中段的信息
小模型（7B）实际是"头尾记忆"：
✓ 开头的 system prompt
✓ 最近几轮对话
✗ 中间的长检索结果（容易被忽略）
对 RAG 的影响：召回 5 个 chunk，7B 可能只真正"读"了前 2 个
3. 推理链断裂（Multi-hop 失效）
Multi-hop 需要：步骤1 结论 → 作为步骤2 输入 → 步骤3 ...
7B 的问题：
- 步骤1 能完成
- 步骤2 容易"忘记"步骤1 的结论，重新推理
- 3 步以上基本失控
v9 multi-hop 只做了 1 次检索就停止，正是这个现象
4. 工具调用参数幻觉
大模型：正确推断参数类型和边界
search_rag(query="RAG 分块推荐大小", top_k=3) ✓
小模型：容易出现参数幻觉
search_rag(query="...", top_k="three") ✗ 类型错误
search_rag(query="...", filter={"tag": "rag"}) ✗ 多出不存在的参数
5. 自我修正能力弱
大模型：检索结果与问题不匹配时，会重新检索或换关键词
小模型：直接用不匹配的结果强行生成答案
→ 语义正确但事实错误的回答
四、架构 vs 模型能力要求对照
| 架构 | 7B 可用？ | 原因 |
|---|---|---|
| 标准 RAG（v1-v2） | ✅ | 只需生成，不需要判断 |
| 混合检索+Reranking（v5-v6） | ✅ | 检索逻辑在代码层，不依赖模型决策 |
| Query 变换（v7） | ⚠️ 部分可用 | 生成变体 Query 尚可，但质量有限 |
| RAGAS 评估（v8） | ⚠️ 指标不准 | LLM-as-judge 需要较强推理能力 |
| Self-RAG（v9） | ❌ 不稳定 | 需要 meta-cognition |
| Multi-hop（v9） | ❌ 基本失效 | 需要多步推理链 |
| Semantic Cache（v10） | ✅ | 缓存逻辑在代码层 |
核心结论：
- RAG 的检索侧优化（v3.5~v7）= 逻辑在代码层 → 小模型可用
- RAG 的决策侧架构（v9 Agentic）= 逻辑在模型层 → 需要大模型
五、修复非预期行为的三个层次
层次 1 — 改模型（最有效，最直接）
换用 Qwen2.5-32B+ 或 GPT-4o
大模型工具调用遵从度远高于 7B
层次 2 — 强化 System Prompt
当前（conditional）：
"如果需要了解特定信息，请使用 search_rag 工具"
改为（mandatory）：
"你必须先调用 search_rag 工具检索，
即使你认为自己知道答案，也要先检索验证。
禁止直接从参数记忆回答。"
层次 3 — 架构约束（强制检索，绕过模型决策）
取消模型的"是否检索"决策权，改为每次先检索再生成
代价：退化为传统 RAG，失去 Agentic 特性
适用：延迟敏感 / 模型能力不足的场景
六、面试表达
“v9 我用 Qwen2.5-7B 跑 Self-RAG，发现一个典型问题：模型对于它’自认为知道’的问题会跳过工具调用，直接用参数记忆回答。比如’RAG 分块推荐多大’这个问题，7B 认为自己知道，给出了 256-1024 token 这个数字——但这是错的，我们知识库里的正确答案是 200-500 字符。
这暴露了 Self-RAG 对模型的核心要求是 meta-cognition：模型不只要会调工具，还要知道自己什么时候不可信。7B 的元认知能力不足——阈值太低，遇到熟悉话题就短路。
经验规律是：本地部署 Self-RAG 需要 32B+ 才稳定；GPT-4o 这类 API 模型受 RLHF 专门优化了工具调用遵从度，效果更好。
更根本的结论是：RAG 里检索侧的优化（分块、混合检索、Reranking）是代码层的逻辑，用 7B 完全没问题；但 Agentic RAG 的决策逻辑在模型层，模型能力不足会让整个架构失效。这是选型时一个容易踩的坑。“
七、关联知识点
- v9 实验结果 →
09_result.md - v9 代码实现 →
09_v9_agentic_rag.py - 传统 RAG vs Agentic RAG 的适用场景 → v9 STEP 5 输出