如何提升RAG系统的准确性：CRAG架构与置信度路由

摘要

传统检索增强生成（RAG）系统的一个主要问题在于其缺乏对检索质量的评估机制，导致即使返回的相关文档不准确，也无法识别。本文介绍一种新的架构——Corrective RAG (CRAG)，通过引入“置信度评估与动态路由”的机制，使得RAG系统能够自我反思和调整策略。在实际应用中，采用CRAG架构可以显著提升系统的召回率和答案忠实度。

引言：传统RAG的局限性

构建一个完整的RAG系统通常需要花费大量时间和精力进行调优。然而，在实际应用场景中，用户提问所返回的相关文档并不总能满足需求。例如，当用户询问“公司的远程办公政策是什么？”时，传统的RAG系统可能返回一系列不相关的或过期的信息，导致生成的答案出现误导和错误。

这种现象的核心原因在于传统RAG系统缺乏对检索结果的质量评估机制，无法判断哪些文档是真正相关的，并且在面对低质量的检索结果时无能为力。因此，如何让RAG系统具备自我校正的能力是一个亟待解决的问题。

传统RAG架构中的问题

缺乏质量评估

传统RAG的工作流程是一条固定的流水线：

用户提问 → 向量数据库检索 → 拼接上下文 → LLM生成答案

在这个过程中，系统不会对检索到的文档进行相关性判断。即使相似度分数很低，也会直接将这些文档传递给语言模型。

缺乏反馈机制

当检索失败（即返回的相关文档质量低或无相关文档）时，系统通常会硬着头皮生成答案，而没有其他补救措施。

没有动态路由策略

所有的用户提问都会遵循同一种处理方式，无论是简单的事实查询还是复杂的推理问题。这种单一路径的方法导致了效率低下和准确性下降的问题。

CRAG架构：引入置信度评估与动态路由

为了解决这些问题，Corrective RAG (CRAG) 架构应运而生。该架构通过在检索和生成之间插入一个“相关性评估”节点来解决传统RAG的局限性。此节点根据文档的相关性进行评分，并据此选择不同的后续处理路径。

CRAG的核心流程

CRAG的工作流程如下图所示：

            ┌─────────────┐
            │   用户提问  │
            └──────┬──────┘
                   ↓
            ┌─────────────┐
            │ 向量检索    │
            └──────┬──────┘
                   ↓
            ┌─────────────┐
            │ 置信度评估   │ ← 核心创新
            └──────┬──────┘
                   ↓
      ┌────────────┼────────────┐
      ↓            ↓            ↓
 置信度≥7      3≤置信度<7    置信度<3
      ↓            ↓            ↓
┌─────────┐  ┌─────────┐  ┌─────────┐
│直接生成  │  │查询重写  │  │Web搜索  │
└─────────┘  └────┬────┘  └────┬────┘
                  ↓            ↓
             ┌─────────┐  ┌─────────┐
             │二次检索  │  │外部知识  │
             └────┬────┘  └────┬────┘
                  ↓            ↓
             ┌─────────────────┐
             │   LLM 生成答案   │
             └─────────────────┘

通过这样的架构设计，CRAG能够根据检索文档的质量动态选择不同的处理路径。例如：

• 置信度高（≥7）：系统直接使用当前的上下文进行生成。
• 中等置信度（3≤置信度<7）：尝试对查询进行重写，或者从外部知识库中搜索相关信息。
• 低置信度（<3）：采用Web搜索或其他形式的补救措施。

CRAG架构的优势

以下是CRAG相对于传统RAG的主要改进：

这些改进使得RAG系统的准确性得以大幅提升。例如，在实际测试数据集中，CRAG架构可以将召回率从0.62提升至接近1，并且答案的忠实度也显著提高。

置信度评估器的设计

评估器的作用

CRAG中的置信度评估器负责对检索到的文档与用户查询的相关性进行评分。该评估器的输出包括一个0-10范围内的分数以及相应的推理理由，以便更好地调试和理解评估结果。

实现细节

为了实现这一功能，可以使用开源的大规模语言模型（如gpt-4o-mini）作为置信度评估器。以下是其实现方式：

from openai import OpenAI
from typing import List, Dict

client = OpenAI()

def evaluate_relevance(query: str, documents: List[str]) -> Dict:
    """
    评估检索文档与查询的相关性

    Args:
        query (str): 用户查询
        documents (List[str]): 检索到的文档列表

    Returns:
        dict: {
            "confidence": float,  # 置信度分数（0-10）
            "reasoning": str      # 推理理由
        }
    """

    # 构建评估prompt
    docs_text = "\n\n".join([f"文档 {i+1}:\n{doc}" for i, doc in enumerate(documents)])

    prompt = f"""
你是一个文档相关性评估专家。请评估以下检索文档与用户查询的相关性。

用户查询：{query}

检索到的文档：
{docs_text}

请按以下格式输出:
1. 置信度分数（0-10）:
   - 0-3: 文档完全不相关或严重偏离主题
   - 4-6: 文档有一定的关联性，但不是非常精确
   - 7-10: 文档高度相关，能够很好地回答用户的问题
2. 推理理由：
"""

    # 发送请求到评估器
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        prompt=prompt,
        max_tokens=150,
        temperature=0.3
    )

    result = response.choices[0].message.content.split('\n\n')
    confidence_score = float(result[0].split(': ')[1])
    reasoning = '\n'.join([line for line in result if '推理理由' in line])

    return {"confidence": confidence_score, "reasoning": reasoning}

通过以上设计，CRAG架构不仅提升了RAG系统的准确性和效率，同时也为未来的改进提供了新的可能。

阈值选择的消融实验

在CRAG架构中，合理设定置信度阈值至关重要。根据论文建议，推荐使用的阈值是 (3, 7)，但这个数值并不适用于所有场景。因此，在50个测试问题上进行了不同阈值组合的效果评估：

为什么选择 (3, 7) 这一最优组合呢？我们可以从以下几个角度分析：

• 高置信度区间过窄的问题：以(5, 8)为例，由于高置信度区间的范围较窄（即只有分数为8、9和10的情况），导致大量中等质量的文档被降级处理成查询重写。比如对于“公司地址是什么？”这类问题，虽然检索到了相关文档但其置信度仅为7.5，按照此阈值组合则无法直接生成答案，增加了额外的工作量。

• 低置信度阈值过高的影响：采用(4, 7)的设定会使得一些“勉强能用”的文档被排除在直接使用之外。例如，“怎么申请在家办公？”的问题，检索到的《考勤管理办法》虽然相关性较低（分数为3.5），但仍然具有一定的参考价值。

• 最优方案的优势：(3, 7)这一阈值组合能很好地平衡各方面需求：

  • 简单问题（如事实查询）大多数情况下都能获得高置信度评分，直接生成答案即可。
  • 对于复杂或模糊的问题，则会触发查询重写机制，提高找到正确信息的概率。
  • 只有在确实无法从知识库中获取有用信息时才会选择回退到Web搜索。

三条路由详解

CRAG架构通过不同的置信度阈值来决定具体的操作方式：

路由1：置信度≥7 → 直接生成

当检索结果高度相关且文档质量较高时，可以直接使用这些文档作为答案。例如，“公司的年假政策是什么？”这样的问题可以迅速找到《员工手册-休假制度》并给出9.2的高分评估后直接回答。

路由2：3≤置信度 <7 → 查询重写

在检索结果中等质量但不能完全满足需求的情况下，可以通过重新构造查询语句提高文档的相关性。比如，“怎么请假？”初检未能找到明确匹配项（如《休假管理制度》），可将其改写为“请假流程”，再进行一次搜索。

路由3：置信度<3 → Web搜索

当知识库中没有适用的信息时，需要借助外部资源来补充答案来源。例如，“2026年的劳动法对加班有何规定？”因为新法规尚未录入系统，所以只能通过网络获取最新的法律文件并据此作答。

实践中的踩坑与优化

在实际应用过程中遇到的一些问题及其解决方案：

• 评估器延迟过高：使用性能较差的gpt模型会导致响应时间过长。为了解决这个问题，选择了更轻量级且速度更快的小型版本gpt-mini作为替代品，在保证效果的同时显著缩短了处理时间。

• 查询重写陷入死循环：为了避免反复修改查询语句而无法找到相关文档的情况发生，设置了两次尝试后的上限以防止无限循环的发生，并直接转向Web搜索获取信息。

• Web搜索结果格式不统一：为了确保所有来源的数据都能被正确解析和使用，在获取到的HTML片段基础上构建了一致性的文档结构模型，从而实现了内部和外部数据的一体化处理流程。

• 置信度分数不稳定：通过在Prompt中加入具体示例指导评估器如何更准确地判断相关性水平，并且利用温度参数减少随机因素对评分的影响，以实现更加稳定可靠的评估结果输出。