Ragas：别再凭感觉测 AI 搜索，用数据集做答案回归

AI 搜索、知识库问答、客服机器人上线前，最容易犯的错误是“我随便问了几个问题，感觉回答还行”。这种 vibe check 对 QA 来说风险很高：同一个问题换个问法可能答偏，召回文档可能不对，回答可能看似流畅但没有依据。

Ragas 解决的不是传统接口测试，而是 AI 应用评估。官方介绍里，Ragas 的目标是把 AI 应用从“凭感觉检查”推进到系统化 evaluation loop；它提供 metrics、datasets、experiments 等能力，用来持续评估 LLM 应用。

适合的 QA 工作类型：AI 搜索测试、RAG 问答回归、知识库更新验收、客服机器人上线前抽检。

AI 直接参与的测试动作：用 LLM-based metrics 评估回答相关性、忠实度、上下文命中情况，并把失败样例沉淀成回归数据。

真实场景：知识库更新后，QA 怎么确认回答没劣化？

假设团队更新了帮助中心文档，RAG 应用的检索逻辑也改了一点。产品只说“应该更准了”，但 QA 要确认：老问题不能答错，新问题要能找到新文档，回答不能编造不存在的规则。

原始做法通常是：

1. 人工准备几个问题。
2. 在页面上手动问。
3. 看回答是否顺眼。
4. 出问题时截图给研发。
5. 下一次文档更新再重新凭记忆问一遍。

这套流程最大的问题是不可复现。问题集、标准答案、引用上下文、评分口径都没有沉淀。

Ragas 的更合理用法是：先建一个小的 golden set，再固定评估指标，每次文档、prompt、召回策略变化后跑同一批问题。

最小验证路径

Ragas 官方文档提供了安装和 quickstart 路径。你可以先不用接线上系统，拿 5-10 条真实问题做一个最小评估集。

安装：

pip install ragas

更快的方式是用 quickstart 创建项目：

uvx ragas quickstart rag_eval
cd rag_eval

最小数据集建议包含四列：

1. question：用户真实问题。
2. expected：QA 或业务确认过的期望回答点。
3. contexts：系统应该召回的文档片段。
4. risk：是否高风险，例如支付、退款、隐私、合规。

第一次不要追求复杂指标。先用官方列出的 RAG 指标思路：context precision、context recall、response relevancy、faithfulness。重点不是分数多漂亮，而是失败样例能不能被复现和解释。

提效点拆解

第一，少凭感觉判断回答好坏。

Ragas 官方 metrics 覆盖 RAG、agent/tool、SQL、自然语言比较等任务。对 RAG QA 来说，最实用的是把“回答是否相关、是否忠实于上下文、上下文是否召回正确”拆开看。

第二，少重复人工问答。

一批高频问题、历史缺陷问题、风险问题可以沉淀成数据集。后续文档更新、prompt 更新、embedding 模型更新，都跑同一批问题。

第三，少遗漏召回问题。

很多回答错误不是生成模型问题，而是检索没有拿到正确文档。把 contexts 放进评估流程后，QA 能区分“召回错了”和“生成编了”。

第四，少写含糊缺陷。

失败报告应包含问题、实际回答、期望要点、召回上下文、评分原因。研发拿到后能判断是知识库、检索、prompt 还是模型的问题。

QA 必须人工校对什么

第一，golden set 的标准答案。

Ragas 可以评分，但不能替你定义业务规则。退款、会员权益、隐私授权这类回答必须由业务和 QA 先确认。

第二，LLM judge 的评分原因。

LLM-based metrics 不是绝对真理。高风险问题要抽样复核评分理由，必要时改 rubric 或加人工审核。

第三，指标阈值。

不要一开始就设一个“低于多少就阻断发布”的硬阈值。先跑几轮，观察历史版本分布，再把关键指标放进门禁。

适合和不适合

适合：AI 搜索、知识库问答、客服机器人、内部助手、文档问答、需要反复回归的 RAG 应用。

不适合：没有明确知识来源的开放闲聊；业务没有标准答案的问题；用户输入高度私密且无法脱敏的场景。

总结

Ragas 对 QA 的价值，是把 AI 问答验收从“随机问几个问题”变成可复跑的数据集、指标和失败分析。

如果你的团队已经有 RAG 应用，但上线前仍然靠人工感觉判断回答质量，先用 5-10 条高风险问题搭一个最小 Ragas 回归集，会比空谈大模型评测平台更实用。

官方资料

• Ragas 官方介绍
• Ragas Metrics
• Evaluate and Improve a RAG App
• Ragas Installation