LLM Agent 中 RAG 与模型智能的平衡：幻觉检测与校准方案

这里涉及到的三个任务都是通过大模型指令来进行的，三个任务分别是：模型 B 基于 A 的 claim 进行提问，模型 B 判断是否继续提问，模型 B 基于 A 的所有回答判断 claim 是否正确。

相比上面 SELF-CHECK 随机解码生成多个答案的方案，从多角度进行提问，个人感觉更有针对性，但两种方法都会有遗漏和误伤。推理成本上 SELF-CHECK 更低，LM vs LM 更高。

自我拒绝（Self-Rejection）

除了通过不一致性判断模型出现幻觉，另一种更干脆直接的方案，是让模型在碰到自己不确定的问题时，直接选择拒绝回答，和 RLHF 中的事实性原则是一个思路。但我对这类方案最大的疑惑是拒识能力的泛化性。究竟模型是学到了对于自身 parametric knowledge 置信度较低、混淆度较高的问题进行拒绝回答，还是模型背下来了对某些知识和上文语义空间进行拒绝回答。

所以这里我们绕过这个问题，聊一种中间策略。R-Tuning 提出指令微调可能放大了模型的回答幻觉。因为指令微调的数据集中所有问题都有答案，微调任务就是负责教会模型各种任务范式，以及在不同的任务中如何召回预训练中学习的知识并回答问题。但我们忽略了 SFT 中很多任务涉及到的知识在模型预训练中可能是没接触过的，但我们依旧选择让模型去进行回答。这种预训练和指令微调间的不一致性，可能会进一步放大模型幻觉。

R-Tuning 给出的解决方案是在构建指令微调数据集时，加入模型是否对该答案表示肯定的描述，这样允许模型拒绝自己不确定的问题。分成 2 个步骤：

1. 找到模型不确定的问题，论文尝试了两种方案：
   • R-Tuning：模型回答和标注答案不一致，适用于有标准答案的 QA 问题。
   • R-Tuning-U：模型回答自我矛盾，这里论文计算模型回答包含的所有答案的熵值。
2. 构建允许模型拒绝的指令数据集，论文也尝试了以下两种 prompt 指令模板：
   • R-Tuning：'Q:{Question},A:{Answer}.{Prompt}.'，其中 prompt 是 Are you sure you accurately answered the question based on your internal knowledge。对于上面模型确定的问题加上 I am sure，不确定的问题加上 I am not sure。
   • R-Tuning-R：对于确定给的问题使用"Q:{Question},A:{Answer}"，对于不确定的问题用 I am not sure 的各种相似表达来直接替换 Answer。

然后使用以上加入模型不确定性表达的数据集进行指令微调即可。在我们的使用场景中 R-Tuning-R 这种直接拒绝的方案更加合适，毕竟我倾向于指令微调的核心并不是知识注入，而是任务对齐，所以模型只要学习到对于自己不确定的问题选择拒绝回答即可。在论文验证的 MMLU 等数据集上这种拒绝微调方案有一定的领域外的泛化效果，不过这些数据集和我们的使用场景相差很大，具体效果要等测试后才知道了。

后置处理：Calibration

除了前置判断，Calibration 方案侧重于让模型先生成，再使用召回内容对模型回答进行修正校准和事实性检查。这通常涉及以下步骤：

1. 生成草稿：模型基于内部知识首先生成一个初步回答。
2. 证据检索：根据生成的关键实体或论点，检索相关文档片段。
3. 一致性校验：将检索到的内容与生成内容进行比对，标记冲突点。
4. 重写与引用：模型根据校验结果重写回答，并强制要求引用来源。

这种方法的优势在于保留了模型的创造性，同时利用外部知识纠正事实错误。实现时可以使用 Chain-of-Thought 引导模型先列出观点，再逐一验证。

混合策略与最佳实践

在实际工程中，单一方案往往难以兼顾效率与准确性。建议采用混合策略：

• 高置信度场景：如常识性问题、通用逻辑推理，直接调用模型，减少延迟和 Token 消耗。
• 中置信度场景：先生成回答，并行检索关键信息，通过轻量级校验器判断是否需要修正。
• 低置信度场景：如专业医疗、法律、实时新闻，直接触发 RAG 流程，强制模型基于检索内容回答。

此外，还可以引入人类反馈机制（RLHF），在系统上线初期收集用户纠错数据，持续优化 Detection 和 Calibration 模块的阈值。

代码示例：基础幻觉检测逻辑

以下是一个简化的 Python 伪代码示例，展示如何使用多轮采样检测一致性：

import random
from typing import List, Dict

def generate_response(model, prompt, n_samples=5):
    responses = []
    for _ in range(n_samples):
        # 设置较高的温度以增加多样性
        response = model.generate(prompt, temperature=0.7)
        responses.append(response)
    return responses

def check_consistency(responses: List[str]) -> bool:
    """
    简单的一致性检查：比较不同回答的核心语义
    实际应用中应结合 NLI 模型或 Embedding 相似度
    """
    if len(responses) < 2:
        return True
    
    # 这里仅做演示，实际需调用 NLI 模型或 Embedding 计算
    # 例如：计算所有回答两两之间的余弦相似度
    avg_similarity = calculate_avg_similarity(responses)
    
    # 设定阈值，低于阈值则判定为幻觉风险高
    return avg_similarity > 0.8

def detect_hallucination(model, query: str) -> Dict:
    responses = generate_response(model, query)
    is_consistent = check_consistency(responses)
    
    if is_consistent:
        return {"status": "safe", "answer": responses[0]}
    else:
        return {"status": "hallucination_risk", "answers": responses}

结论

RAG 技术的核心挑战在于如何在引入外部知识的同时，不牺牲大模型本身的参数化智能。单纯的检索增强容易导致模型退化为提取器，而纯生成模式又面临幻觉风险。

通过前置的 Detection（自我矛盾、自我拒绝）和后置的 Calibration（证据校验、重写），我们可以构建一个更加鲁棒的 Agent 系统。未来的方向在于更细粒度的置信度估计，以及端到端的联合优化，使得模型能够自适应地决定何时信任内部知识，何时调用外部工具。开发者应根据具体业务场景，灵活组合上述方案，在成本、延迟和准确性之间找到最佳平衡点。