判断是否需要检索 = 判断“仅靠模型参数内知识，是否足以可靠回答当前问题”

实现方式可以分为4 大类，从易到难：

1. 规则 / 启发式
2. LLM 自评（最常用）
3. 不确定性 / 置信度驱动
4. 端到端学习（Self-RAG 的做法）

一、最简单可落地：规则 / 启发式方法（Baseline）

适合：工程快速上线、原型验证

常见规则

1️⃣ 基于问题类型

如果问题包含： - 最新 / 今年 / 最近 - 数据 / 数值 / 排名 - 法律 / 医疗 / 政策 → 需要检索

2️⃣ 基于实体密度

问题中包含大量专有名词（人名、论文、公司、产品） → 高概率需要检索

3️⃣ 基于问题长度 / 复杂度

问题越长、约束越多 → 越可能需要外部资料

📌 优点：

• 快
• 可控
• 无需额外模型

📌 缺点：

• 不鲁棒
• 覆盖率低
• 无法泛化

二、实践中最常用：让 LLM 自己判断（LLM Router）

这是当前最主流、性价比最高的方法。

核心思想

先不检索，先问模型：你需不需要检索？

方式 1：显式 Yes / No 判断（推荐）

Prompt 示例

你是一个 AI 助手。 请判断回答下列问题是否需要依赖外部文档或实时信息。 如果模型自身知识足够，请回答：NO_RETRIEVAL 如果需要外部信息，请回答：RETRIEVAL 问题： {user_question}

输出示例

RETRIEVAL

或

NO_RETRIEVAL

📌 然后：

• RETRIEVAL→ 走 RAG
• NO_RETRIEVAL→ 直接生成

方式 2：多标签判断（更细）

请选择以下标签（可多选）： [A] 事实性问题 [B] 需要最新信息 [C] 需要专业文档支持 [D] 可基于常识直接回答

📌 若包含 A/B/C → 检索

优点

✔ 实现简单
✔ 准确率高
✔ 可快速调 prompt 微调行为

缺点

✖ 额外一次 LLM 调用
✖ 判断本身可能出错

三、更稳健：基于“不确定性 / 置信度”的方法

这是学术和高端工程常用。

思路 1：先尝试生成 → 再判断可信度

流程：

问题 ↓ LLM 直接回答（不检索） ↓ 评估回答是否“不确定 / 模糊 / 猜测” ↓ 若不可信 → 再检索

如何评估“不确定”？

方法 A：语言特征

如果回答中出现：

• “可能”
• “大概”
• “我不确定”
• “无法确认”

→ 触发检索

方法 B：Self-Evaluation Prompt

请评价你刚才的回答是否完全基于可靠知识， 是否存在猜测或不确定性？ 只回答 YES 或 NO。

思路 2：多次采样一致性（Self-Consistency）

同一问题生成 N 次答案 如果答案差异大 → 不确定 → 检索

📌 成本高，但效果很好

四、最先进：Self-RAG / 端到端学习判断（论文级）

这是你刚才提到的视频里最核心的创新点。

核心思想

把“是否检索”变成模型生成过程的一部分

而不是一个外部 if-else。

Self-RAG 是怎么做的？

1️⃣ 引入特殊 token

例如：

<NEED_RETRIEVAL> <NO_RETRIEVAL> <USEFUL> <NOT_USEFUL>

2️⃣ 模型在生成过程中自己决定

生成过程可能是：

<NEED_RETRIEVAL> → 调用检索 → 阅读文档 → <USEFUL> → 继续生成答案

或者：

<NO_RETRIEVAL> → 直接生成答案

3️⃣ 训练时如何学会判断？

训练数据中包含：

• 问题
• 是否需要外部证据
• 证据是否支持回答

模型被监督学习这些判断。

📌 本质是把“是否检索”当成一个可学习的策略问题。

优点

✔ 判断更细粒度
✔ 和生成强耦合
✔ 减少无效检索

缺点

✖ 训练成本高
✖ 实现复杂
✖ 不适合一般业务直接复现

五、工程推荐方案（实战总结）

🔥 最推荐的 3 层方案

第 1 层：LLM 判断是否需要检索（Router） 第 2 层：检索后评估文档是否有用 第 3 层：生成后自检，不确定则二次检索

架构示意

User Question ↓ Need-Retrieval LLM ↓ Yes ──→ Retriever ──→ Answer No ───────────────→ Answer