RAG 评估系统：如何用“打分机制”让智能问答越用越聪明？
上一期我们搭建了从禅道SQL到智能问答的RAG系统，但它真的“好用”吗？
这一期，我们聊聊如何通过人工打分 + 指标体系，让系统自我进化，从“能回答”到“答得准”。
一、为什么需要评估系统？
RAG系统上线后，我们面临几个现实问题：
- 检索结果相关性如何？ 有没有把真正相关的用例排到前面？
- 不同模型、参数组合，哪个更好？ 靠直觉还是靠数据？
- 怎么才能持续优化？ 总不能每次靠人工翻看几百条结果吧？
答案就是：建立一套可量化的评估体系，用打分数据驱动模型迭代。
二、整体数据流：从“检索”到“打分”再到“优化”
┌─────────────────────────────────────────────────────────────────┐
│ RAG 评估系统核心流程 │
└─────────────────────────────────────────────────────────────────┘原始数据 数据清洗 向量化存储 检索查询zentao.sql ──▶ zentao_rag ──▶ ChromaDB ──▶ 两阶段检索│▼┌──────────────────┐│ 检索结果(Top5) ││ + 期望用例ID │└────────┬─────────┘│▼┌──────────────────┐反馈到优化方向 ◀── 评估报告 ◀── 人工打分 │ 人工打分界面 ││ │ (1-5分评价) │▼ ▼ ▼┌─────────────┐ ┌─────────────┐ ┌─────────────┐│ 模型/策略 │ │ 指标分析 │ │ 打分数据 ││ 迭代更新 │ │ 问题诊断 │ │ JSON存储 │└─────────────┘ └─────────────┘ └─────────────┘
整个流程可以概括为：检索 → 打分 → 分析 → 改进 → 再检索，形成闭环。
三、详细数据流拆解
3.1 数据预处理阶段
SQL文件 ──▶ 正则提取 ──▶ 字段清洗 ──▶ JSON ──▶ Markdown ──▶ 分块 ──▶ 向量化
(zentao.sql) (HTML转义) (5450条) (5450条) (5450条) (768维向量)│▼ChromaDB持久化存储
这一步为后续检索打好了基础，每个测试用例都是一个独立的语义单元。
3.2 检索阶段（两阶段召回）
用户查询 ──▶ Bi-Encoder ──▶ ChromaDB ──▶ 粗排Top10 ──▶ Cross-Encoder ──▶ 精排Top5(text2vec) 向量检索 (快速召回) (mmmarco) (精准重排)
- Bi-Encoder：速度快，负责从全库中召回候选集。
- Cross-Encoder：精度高，对候选集精排，保证最终输出质量。
3.3 人工打分阶段（核心数据来源）
┌─────────────────────────────────────────────────────────────────┐
│ 人工打分流程示例 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 查询: "如何测试车辆压地感后的云支付功能？" │
│ 期望用例ID: [7] │
│ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ 用例 #1 (ID: 92065) │ │
│ │ 得分: [1] [2] [3] [4] [5] ← 用户根据相关性点击 │ │
│ │ 内容: "天启月卡延期测试..." │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ 用例 #2 (ID: 7) ✅ 与期望匹配 │ │
│ │ 得分: [1] [2] [3] [4] [5] ← 用户点击 5 分 │ │
│ │ 内容: "车辆压地感后云支付功能测试..." │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ ... (其余3个用例) │
│ │
│ 保存打分记录: │
│ { │
│ "query_id": 0, │
│ "ratings": [4, 5, 2, 1, 3], │
│ "timestamp": "2026-03-25T..." │
│ } │
└─────────────────────────────────────────────────────────────────┘
关键点：每个查询都预先标注了“期望相关用例ID”，打分的核心就是看系统能否把期望用例排到前面。
四、打分机制如何指导模型优化
4.1 从分数到改进路径
人工打分结果 ──▶ 分析问题 ──▶ 确定优化方向 ──▶ 实施改进│ │ │▼ ▼ ▼
┌─────────┐ ┌───────────┐ ┌─────────────────┐
│ 原始分数 │ │ 问题诊断 │ │ 改进措施 │
└─────────┘ └───────────┘ └─────────────────┘
一个真实案例：
| 查询 | 期望ID | 检索ID | 打分 | 问题诊断 |
|---|---|---|---|---|
| 跟车行为 | 8626 | 92065,41459,31608,68071,34808 | 1,1,1,1,1 | 期望用例未被召回，检索完全失效 |
诊断：召回能力不足 → 措施：更换更强的 Embedding 模型（如 bge-large-zh），或扩大 Top_K 范围。
4.2 指标体系（量化目标）
有了打分数据，就可以计算标准指标，用数字说话：
| 指标 | 计算方式 | 含义 | 优化目标 |
|---|---|---|---|
| 平均相关性 | 所有打分平均值 | 答案整体质量 | ↑ 越高越好 |
| 精确率@K | 3分以上/总数 | 返回结果中有用比例 | ↑ 越高越好 |
| Recall@K | 命中期望/总期望 | 召回能力 | ↑ 越高越好 |
| MRR | 首个相关排名倒数 | 首位结果质量 | ↑ 越高越好 |
| NDCG | 考虑排名的加权相关 | 整体排序质量 | ↑ 越高越好 |
4.3 实验追踪（让每次优化都有据可查）
# experiment_logger.py 自动记录
{"id": 1,"name": "text2vec-base-v1","config": {"embedding_model": "shibing624/text2vec-base-chinese","reranker_model": "cross-encoder/mmarco-mMiniLMv2","top_k": 5},"metrics": {"recall@5": 0.75,"precision@5": 0.60,"mrr": 0.72,"ndcg@5": 0.68,"avg_relevance": 0.65}
}
通过对比不同实验的指标，可以客观选择最优配置。
五、决策树：如何根据打分结果选择优化方向
人工打分完成│▼
┌──────────────────────────────────────────┐
│ 分析打分结果 │
└──────────────────────────────────────────┘│├─▶ 平均分 < 3.0（普遍偏低）│ ││ ▼│ 问题: 整体语义理解差│ 解决: 更换 Embedding 模型│ - bge-large-zh-v1.5（推荐）│ - m3e-base│ - bce-embedding-base-v1│├─▶ Recall@5 < 0.5（期望用例常未召回）│ ││ ▼│ 问题: 召回能力不足│ 解决: - 增加 Top_K 初筛数量│ - 添加查询扩展（同义词/关键词）│ - 调整分块策略（增大重叠度）│├─▶ MRR 低（相关用例排名靠后）│ ││ ▼│ 问题: 重排序模型不够强│ 解决: - 使用更强的 Cross-Encoder│ - 用领域数据微调 reranker│└─▶ 部分高分、部分低分│▼问题: 领域匹配度不够解决: - 优化 prompt（强调停车场领域）- 增加元数据过滤（如用例类型）- 引入关键词权重
六、迭代优化闭环
┌──────────────┐│ 基准版本 ││ (baseline) │└──────┬───────┘│▼┌──────────────┐│ 人工打分评估 │ ◀──────────────┐└──────┬───────┘ ││ │▼ │┌──────────────┐ ││ 分析问题 │ │└──────┬───────┘ ││ │▼ │┌──────────────┐ ││ 改进策略 │ ││ (换模型/参数)│ │└──────┬───────┘ ││ │▼ │┌──────────────┐ ││ 重新评估 │────────────────┘└──────┬───────┘│▼┌──────────────┐│ 对比报告 │ ──▶ 选出最优模型└──────────────┘
每轮迭代都是一个“假设 → 实验 → 验证”的科学过程，打分数据就是最好的证据。
七、实际改进案例：从“答非所问”到“精准命中”
初始打分结果：
| 查询 | 期望ID | 检索ID | 打分 | 问题 |
|---|---|---|---|---|
| 跟车行为 | 8626 | 92065,41459,31608... | 1,1,1,1,1 | 未召回 |
| 邻道干扰 | 8690 | 8690,8691,8692... | 5,2,1,1,1 | 首位命中，但后续差 |
| 月租车延期 | 41459,46102 | 92065,31608,68071... | 2,1,2,1,1 | 部分召回 |
诊断与改进：
- 召回不足 → 换用
bge-large-zh-v1.5模型 - 排序不准 → 增加查询扩展（如“月租车”补充“包月车”）
- 二次评估 → 重新打分，验证效果
经过 2 轮迭代，Recall@5 从 0.52 提升到 0.81，MRR 从 0.63 提升到 0.79。
八、总结：打分机制的核心价值
- 量化“好与坏”：把主观感受变成可对比的数字。
- 定位问题根源：通过指标（Recall、MRR）区分是召回问题还是排序问题。
- 支撑科学决策：每次改进都有数据验证，避免“拍脑袋”。
- 形成持续闭环：打分 → 分析 → 优化 → 再打分，让系统越用越聪明。
如果你也在做 RAG 应用，不妨从今天开始，为自己的系统加一套“打分机制”。
有数据，才有方向。