rag-auditor

RAG 审计员

系统性评估整个检索生成链路中的 RAG 流程：设计评估查询集，衡量检索指标（Precision@K、Recall@K、MRR），评估生成质量（有依据性、完整性、幻觉率），诊断组件级故障，并提出有针对性的改进建议。

参考文件

文件	内容	何时加载
references/retrieval-metrics.md	Precision@K、Recall@K、MRR、NDCG 的定义和计算方法	始终
references/generation-metrics.md	有依据性、完整性、幻觉检测方法	需要评估生成时
references/failure-taxonomy.md	RAG 故障类别：检索、生成、分块、嵌入	需要诊断故障时
references/diagnostic-queries.md	设计评估查询集、有标准答案的问题、难度级别	设置评估时

前提条件

• 可访问 RAG 流程（或其输出，以便进行事后评估）
• 一组包含已知正确答案的测试查询
• 了解流程组件（嵌入模型、检索器、生成器）

工作流

阶段 1：流程清单

记录 RAG 流程配置：

1. 文档来源 — 索引了哪些文档？格式、数量、大小。
2. 分块 — 策略（固定大小、语义、段落）、分块大小、重叠长度。
3. 嵌入 — 模型名称和版本、维度。
4. 向量存储 — 类型（FAISS、Pinecone、Chroma、pgvector）、索引类型。
5. 检索 — 方法（相似度、混合、重排）、top-K 参数。
6. 生成 — 模型、提示词模板、上下文窗口用量。

阶段 2：设计评估查询

创建一组多样化的测试查询：

查询类型	目的	数量
有标准答案（事实类）	衡量检索 + 生成准确率	10+
多跳查询	需要组合多个分块中的信息	5+
无法回答	答案不在语料库中——应拒答	3+
有歧义	存在多种有效解释	3+
最新/已更新	测试时效性	2+

为每个查询记录预期答案和来源分块。

阶段 3：评估检索

针对每个测试查询，衡量：

1. Precision@K — 检索到的 K 个分块中，有多少个相关？
2. Recall@K — 语料库中所有相关分块里，有多少个被检索到？
3. MRR（平均倒数排名） — 排名最高的相关分块排得有多靠前？
4. 分块相关性 — 为每个检索到的分块评分：相关、部分相关、不相关。

阶段 4：评估生成

针对每个包含检索上下文的测试查询：

1. 有依据性 — 响应中的每项陈述是否都能由检索到的上下文支持？ 评分：0（存在幻觉）到 1（完全有依据）。
2. 完整性 — 响应是否利用了上下文中的所有相关信息？ 评分：0（忽略上下文）到 1（完整）。
3. 幻觉检测 — 找出上下文不支持的具体陈述。
4. 拒答 — 对于无法回答的查询，模型是否正确地回答“我不知道”？

阶段 5：诊断失败

对于每个错误或质量较低的回答，判断其根本原因：

失败类型	诊断	指标
检索失败	未检索到相关分块	Recall@K 较低
排序失败	检索到相关分块，但排名较低	MRR 较低，Recall 较高
分块边界问题	答案被拆分到不同分块的边界	多个分块中出现部分匹配
嵌入不匹配	查询语义与分块嵌入不匹配	相关分块的相似度得分较低
生成失败	上下文正确，但答案错误	检索得分较高，依据充分度较低
幻觉	模型编造上下文中没有的事实	无法追溯到任何分块的说法
过度弃答	上下文充足时，模型仍拒绝回答	存在相关上下文但未作答

阶段 6：提出建议

根据失败分析，建议具体的改进措施：

失败模式	建议
分块边界问题	增加重叠，尝试语义分块
Precision@K 较低	减小 K，增加重排序阶段
Recall@K 较低	增大 K，尝试混合搜索
嵌入不匹配	尝试不同的嵌入模型，增加查询扩展
幻觉	在提示词中加强依据约束，降低温度
过度弃答	放宽提示词中的弃答标准

输出格式

## RAG Audit Report

### Pipeline Configuration
| Component | Value |
|-----------|-------|
| Documents | {N} ({format}) |
| Chunking | {strategy}, {size} tokens, {overlap}% overlap |
| Embedding | {model} ({dimensions}d) |
| Retrieval | {method}, K={N} |
| Generation | {model}, temperature={T} |

### Evaluation Dataset
- **Total queries:** {N}
- **Known-answer:** {N}
- **Multi-hop:** {N}
- **Unanswerable:** {N}

### Retrieval Quality

| Metric | Score | Target | Status |
|--------|-------|--------|--------|
| Precision@{K} | {score} | {target} | {Pass/Fail} |
| Recall@{K} | {score} | {target} | {Pass/Fail} |
| MRR | {score} | {target} | {Pass/Fail} |

### Generation Quality

| Metric | Score | Target | Status |
|--------|-------|--------|--------|
| Groundedness | {score} | {target} | {Pass/Fail} |
| Completeness | {score} | {target} | {Pass/Fail} |
| Hallucination rate | {score} | {target} | {Pass/Fail} |
| Abstention accuracy | {score} | {target} | {Pass/Fail} |

### Failure Analysis

| # | Query | Failure Type | Root Cause | Recommendation |
|---|-------|-------------|------------|----------------|
| 1 | {query} | {type} | {cause} | {fix} |

### Recommendations (Priority Order)
1. **{Recommendation}** — addresses {N} failures, expected impact: {description}
2. **{Recommendation}** — addresses {N} failures, expected impact: {description}

### Sample Failures

#### Query: "{query}"
- **Expected:** {answer}
- **Retrieved chunks:** {chunk summaries with relevance scores}
- **Generated:** {response}
- **Issue:** {diagnosis}

校准规则

1. 隔离组件。 独立评估检索和生成。如果只检查最终输出，优秀的检索器配上糟糕的生成器，看起来就像是检索失败。
2. 先用已知答案。 从正确答案明确无歧义的事实类问题开始。多跳和有歧义的查询更难评估。
3. 量化，不要定性。 “检索效果不好”不是一项发现。“Precision@5 为 0.3（目标：0.8），且 70% 的失败由分块边界拆分导致”才具有可操作性。
4. 深入抽查失败案例。 汇总指标能指出问题在哪里。对单个失败案例进行分析，才能找出问题的原因。

错误处理

问题	解决方案
没有可用的已知答案查询	协助根据文档语料设计这类查询。选取 10 条事实并据此编写问题。
无法访问流水线	根据记录的输入和输出开展工作。可使用查询—上下文—响应三元组进行事后评估。
语料过大，无法审阅	进行基于抽样的评估。选取有代表性的文档，并据此生成查询。
多种失败类型并存	优先解决检索失败。生成质量不可能超过检索质量。

何时不应审计

如果出现以下情况，请提出异议：

• 流水线尚未构建——先设计流水线，再进行审计
• 语料少于 10 份文档——规模太小，无法进行有意义的检索评估
• 用户想比较嵌入模型——这是基准测试任务，而非审计