RAG 评估：离线评估、线上反馈与版本回归

构建 RAG 系统很容易，但评估它是否有效却很难。我们不能仅凭“感觉”说这个回答好不好，需要量化的指标。

1. 评估的核心维度

RAGAS 等工具提供了 RAG 评估指标与实现参考，但评估设计不应绑定单一框架。无论使用 Python 工具、Go 服务还是内部平台，都应先拆开检索与生成，明确每个指标需要什么标注和适用边界。LLM-as-a-Judge 可以辅助规模化评审，但不能自动成为唯一真值。

核心指标分为两类：

1.1 生成质量 (Generation Quality)

信实度 (Faithfulness): 答案是否完全基于检索到的上下文？（检查幻觉）
答案相关性 (Answer Relevance): 答案是否直接回答了用户的问题？

1.2 检索质量 (Retrieval Quality)

上下文精确度 (Context Precision): 检索到的文档中，有用信息的占比是多少？（噪音多少）
上下文召回率 (Context Recall): 检索到的文档是否覆盖了回答问题所需的所有信息？

2. Golang 实现 LLM-as-a-Judge

不使用专用框架时，也可以通过模型 API 实现 Judge。生产评估还需要固定 Judge 模型与 Prompt 版本、校验结构化输出、处理失败，并用人工样本检查 Judge 与业务标准是否一致。

示例：评估“信实度” (Faithfulness)

逻辑：

让 LLM 从生成的“答案”中提取所有的“陈述 (Statements)”。
让 LLM 逐一判断每个“陈述”是否能从“上下文”中推导出来。
分数 = 支持的陈述数量 / 总陈述数量。

Golang 代码实现：

package main

import (
	"context"
	"fmt"
	"strings"

	"github.com/tmc/langchaingo/llms"
	"github.com/tmc/langchaingo/llms/openai"
)

const faithfulnessPrompt = `
你是一个公正的法官。请根据【上下文】判断【答案】中的每一句话是否都有事实依据。
如果一句话能从上下文中推导出来，输出 1；否则输出 0。
最后返回 JSON 格式：{"score": 0.x, "reason": "..."}

【上下文】：
{{.Context}}

【答案】：
{{.Answer}}
`

func EvaluateFaithfulness(ctx context.Context, llm llms.Model, contextStr, answerStr string) {
	// 简单演示：直接构造 Prompt 发送给 LLM
	// 实际工程中需使用 Template 替换变量
	prompt := strings.ReplaceAll(faithfulnessPrompt, "{{.Context}}", contextStr)
	prompt = strings.ReplaceAll(prompt, "{{.Answer}}", answerStr)

	resp, err := llm.Call(ctx, prompt)
	if err != nil {
		fmt.Println("Evaluation failed:", err)
		return
	}

	fmt.Println("=== 评估结果 ===")
	fmt.Println(resp)
}

func main() {
	llm, _ := openai.New()

	context := "Golang 是 Google 开发的。它发布于 2009 年。"
	answer := "Golang 是 Google 在 2009 年发布的，它是世界上最好的语言。" // 后半句是幻觉

	EvaluateFaithfulness(context.Background(), llm, context, answer)
}

3. 构建评估数据集 (Golden Dataset)

要进行评估，你需要一个“测试集”。通常包含：

Question: 问题
Ground Truth: 标准答案（人工撰写）

如何辅助生成测试集？ 可以让 LLM 从文档中生成候选 (Question, Answer) 对，但生成结果必须经过人工审核，并保留证据定位。纯合成问题容易偏向表面事实，也可能复制模型偏好，不能替代真实用户问题、边界案例和历史故障。

const qgPrompt = `
请根据以下文档片段，生成 3 个由浅入深的问题，并给出对应的标准答案。
格式：
Q1: ...
A1: ...
`
// 调用 LLM 生成 QA 对，存入 JSON 文件作为测试集

4. 持续评估 (CI/CD)

在企业级项目中，评估不应该是一次性的。

Regression Test: 每次修改 Prompt 或检索策略后，跑一遍测试集。
Online Monitoring: 随机抽取线上用户的问答，后台异步进行打分。

线上抽样必须遵守隐私、权限和数据保留要求。Judge 分数适合用作趋势信号，不能在未经校准时直接当作业务正确率。

5. 离线评估：先固定样本和版本

一个可回归的数据项不应只有问题与标准答案。建议至少包含：

json

{
  "case_id": "permission-policy-001",
  "question": "谁可以审批生产权限？",
  "expected_evidence": [
    {"document_id": "policy-7", "version": "v3", "locator": "审批流程/生产权限"}
  ],
  "reference_answer": "由业务定义并经审核的参考答案",
  "access_context": {"tenant": "example", "roles": ["employee"]},
  "tags": ["事实查询", "权限"],
  "review_status": "approved"
}

评估时锁定文档快照、解析与切片版本、Embedding、索引、检索参数、Prompt、生成模型和 Judge 版本。否则分数变化无法归因。

层级	可观察信号	适用说明
检索	证据是否出现在候选、证据排名、无关候选比例	需要问题到证据的标注
上下文	条件是否完整、重复和截断情况	适合诊断切片与组装
生成	事实是否有证据支持、答案是否完整且相关	结合规则、人工和 Judge
引用	引用是否存在、可打开、与陈述一致	不能只检查引用格式
安全/权限	未授权内容是否被召回或泄露	必须包含负向和跨租户样例
系统	延迟、错误、Token 与外部调用	与质量一起判断取舍

不同业务对错误的代价不同，因此本文不提供统一通过分数。团队应先测当前基线，再由产品、业务、安全和工程负责人共同定义候选版本的阻断条件。

6. 线上反馈：观察真实失败分布

线上信号可以补足离线集覆盖不足，但不能把点击或点赞直接等同于答案正确：

收集“无答案”、引用点击、复制、追问、人工改写、负反馈和客服升级等行为信号。
记录当次回答的请求 ID、检索与模型版本、授权范围和引用 ID，避免只留下无法复现的答案文本。
对高风险或负反馈样本进行权限内的人工复核，确认是数据、检索、生成、引用还是产品交互问题。
去标识化并审核后，才把代表性失败加入回归集；不要让未经审查的线上输入直接改变 Golden Dataset。
按查询类型、租户、语言和版本分组观察，避免总平均值掩盖局部退化。

7. 版本回归与发布决策

每次改动切片、Embedding、检索、重排、Prompt、模型或权限规则时，比较候选版本与当前基线：

在同一数据快照和评估集上运行两个版本。
同时查看总体结果、关键切片和逐案例差异。
对改善与退化样本做盲审或业务复核，避免只追一个聚合分数。
记录质量、延迟、成本和安全取舍，以及最终批准人。
灰度后继续观察线上信号；触发停止条件时回退完整配置组合。

新增样本可以进入后续回归，但比较历史趋势时要区分“模型变了”和“评估集变了”。

8. 面试中如何证明效果

面试表达不要只说“准确率提升了”或“用了 RAGAS”。更可信的结构是：

业务问题与失败代价：用户问什么，错误答案会造成什么影响。
基线：改动前使用什么数据快照、检索策略和评估集。
个人动作：你负责了切片、混合检索、权限过滤、引用还是评估链路中的哪部分。
评估设计：样本如何来源、谁审核、如何区分召回和生成、如何覆盖权限负例。
结果证据：展示经复核的前后对比、失败案例、延迟和成本取舍；只有在真实测量并能解释口径时才给出数字。
上线闭环：如何通过灰度、反馈、告警和回滚控制风险。

例如可以表达为：“我把历史工单和业务专家审核的问题整理为版本化评估集，先定位证据未进入候选的样本，再调整切片与混合检索；候选版本通过逐案例复核后灰度上线，并把引用错误和负反馈回流为回归样本。”数字应替换为项目中可出示口径与记录的真实结果，不能为了简历效果估算。

总结

如果要把评估接入 Agent 与 RAG 的组合系统，可参考 Agent + RAG 组合专题。

不要盲目上线 RAG。
检索、上下文、生成、引用、权限和系统表现要分层评估。
LLM-as-a-Judge 是可用工具之一，需要人工校准、版本锁定和失败处理。
离线评估决定是否值得灰度，线上反馈揭示真实分布，回归测试防止修复旧问题时引入新问题。

回到 RAG 专题查看完整路径；检索失败先读 RAG 检索排查，准备发布时使用 RAG 生产化检查清单。项目落地与证据链示例见企业级 RAG 知识库，求职方向回到程序员转 AI 主路线。

RAG 评估：离线评估、线上反馈与版本回归 ​

1. 评估的核心维度 ​

1.1 生成质量 (Generation Quality) ​

1.2 检索质量 (Retrieval Quality) ​

2. Golang 实现 LLM-as-a-Judge ​

示例：评估“信实度” (Faithfulness) ​

3. 构建评估数据集 (Golden Dataset) ​

4. 持续评估 (CI/CD) ​

5. 离线评估：先固定样本和版本 ​

6. 线上反馈：观察真实失败分布 ​

7. 版本回归与发布决策 ​

8. 面试中如何证明效果 ​

总结 ​

别只收藏 AI 文章，今天就做出第一个能上线的项目