做 RAG、Agent、智能客服、知识库问答时，最怕一句话：
"我测了几个问题，感觉效果还可以。"
这个"感觉"在 Demo 阶段可以，在生产环境不行。
因为真实线上问题会非常复杂：
用户问法不一样，召回结果不稳定，大模型偶尔胡说，知识库更新后效果可能变差，Prompt 改了一行也可能影响回答质量。
所以，AI 应用不能只靠人工肉眼检查，必须做自动化评测。
现在比较常见的方案有两类：
RAGAS：更偏 RAG 检索增强问答评测。
官方文档把 RAGAS 定位为帮助大模型应用从"凭感觉检查"走向"系统化评测循环"的工具，支持 RAG 和 Agentic workflow 等指标。
DeepEval：更像大模型应用里的 Pytest。
DeepEval 官方和 GitHub 都强调，它是一个面向 LLM 应用的开源评测框架，写法类似 Pytest，可以做 hallucination、answer relevancy、faithfulness、RAG 指标、自定义 G-Eval 等评测。
一、为什么需要自动化评测？
1.1 人工测试最大的问题：不稳定
人工测试一般是这样：
今天问 20 个问题，看起来不错。
明天换一批问题，发现回答开始跑偏。
后天改了 Prompt，又不知道到底变好了还是变差了。
这就是没有评测体系的问题。
RAG 系统不是普通接口。
普通接口只要看：
返回码对不对，字段有没有，耗时高不高。
RAG 系统还要看：
答案有没有答到点上？
答案是不是基于资料回答的？
召回内容是不是相关？
有没有漏掉关键知识？
有没有胡编乱造？
回答是否符合业务口径？
改了切片策略后，效果有没有提升？
换了 Embedding 模型后，召回有没有变好？
这些东西靠肉眼看，很难持续稳定。
二、RAG 系统到底评测什么？
一个 RAG 问答链路大概是：
用户问题
↓
问题改写 / 意图识别
↓
向量检索 / 关键词检索 / 混合检索
↓
召回文档片段
↓
重排序
↓
Prompt 组装
↓
大模型生成回答
↓
后处理 / 合规校验
↓
返回答案
自动化评测不是只看最后答案。
它要拆成两段看：
2.1 第一段：检索有没有找对资料？
这一步看的是 Retriever。
核心问题是：
该找的资料有没有找出来？
不该找的垃圾资料有没有混进来？
重要资料有没有排在前面？
如果检索错了，大模型后面再聪明也没用。
因为它拿到的是错资料，就很容易生成错答案。
2.2 第二段：生成有没有基于资料回答？
这一步看的是 Generator。
核心问题是：
答案有没有回答用户问题？
答案是不是忠于召回上下文？
有没有根据上下文编造不存在的信息？
语言是否清晰？
格式是否符合要求？
所以 RAG 自动化评测，本质上就是：
检索质量评测 + 生成质量评测 + 业务规则评测。
三、RAGAS 是什么？
3.1 RAGAS 的定位
RAGAS 可以理解成：
专门用来评测 RAG 应用效果的一套工具箱。
它关注的是 RAG 的几个关键指标，比如：
Faithfulness
Answer Relevancy
Context Precision
Context Recall
Answer Correctness
Context Relevancy
RAGAS 论文介绍它是一个用于 RAG 管道的自动化评测框架，强调可以做 reference-free evaluation，也就是部分指标不一定强依赖人工标准答案。
这点很重要。
因为真实业务里，很多问题没有现成标准答案。
比如：
"这个活动为什么投放效果不好？"
"客户投诉应该怎么处理？"
"这个合同条款有什么风险？"
这些问题很难提前写一个唯一标准答案。
RAGAS 的价值就在于，它可以用一些指标去判断：
回答是否忠于上下文，是否相关，召回内容是否有效。
四、RAGAS 核心指标通俗解释
4.1 Faithfulness：答案有没有忠于资料？
Faithfulness 可以理解成：
大模型有没有根据召回资料回答，而不是自己脑补。
举个例子。
用户问：
"公司报销打车费需要什么条件？"
知识库里写的是：
"工作日加班超过晚上 9 点，可以申请打车报销。"
大模型回答：
"工作日加班超过晚上 8 点即可报销，并且周末也可以报销。"
这就不 faithful。
因为"晚上 8 点"和"周末也可以报销"不是资料里说的。
Faithfulness 重点抓的就是：
答案里的说法，能不能在上下文里找到依据。
它主要用于检测幻觉。
4.2 Answer Relevancy：答案有没有答到问题？
Answer Relevancy 可以理解成：
用户问 A，你有没有回答 A。
比如用户问：
"如何申请发票？"
模型回答：
"发票是企业财务管理的重要凭证，发票分为增值税普通发票和专用发票......"
这段话可能没错，但没有告诉用户怎么申请。
这就是相关性不够。
Answer Relevancy 看的不是事实对不对，而是：
回答有没有围绕用户问题展开。
4.3 Context Precision：召回内容准不准？
Context Precision 可以理解成：
检索出来的内容里面，有多少是真正有用的，并且有没有排在前面。
RAGAS 文档里提到，Context Precision 用来评估检索器是否能把相关 chunk 排在不相关 chunk 前面。
举个例子。
用户问：
"密码忘了怎么重置？"
系统召回了 5 个片段：
- 密码重置流程
- 登录失败处理
- 修改手机号流程
- 公司简介
- 产品价格说明
这里第 1 个很相关，第 2 个有点相关，第 4 和第 5 就没什么用。
Context Precision 低，说明召回里面垃圾内容太多。
它会导致：
Prompt 被无用内容占满，大模型抓不到重点，成本增加，回答变差。
4.4 Context Recall：该召回的有没有召回全？
Context Recall 可以理解成：
回答这个问题需要的关键资料，有没有被检索出来。
比如用户问：
"试用期离职需要提前几天通知？"
标准资料有两段：
第一段：试用期员工提前 3 天通知。
第二段：正式员工提前 30 天通知。
如果系统只召回了正式员工提前 30 天，没召回试用期提前 3 天，那就会答错。
Context Recall 低，说明：
重要资料没找出来。
在 RAG 里，这个问题非常致命。
因为如果资料没召回，模型大概率只能猜。
4.5 Answer Correctness：答案最终对不对？
Answer Correctness 更接近人工评测里的"正确率"。
它通常需要有标准答案。
比如测试集里写：
问题：试用期离职提前几天通知？
标准答案：提前 3 天通知。
模型答案：提前 30 天通知。
结果：错误。
这个指标很直观，但成本也高。
因为你需要准备一批高质量标准答案。
五、DeepEval 是什么？
5.1 DeepEval 的定位
DeepEval 可以理解成：
大模型应用里的自动化测试框架。
它不像 RAGAS 那样只围绕 RAG，DeepEval 能覆盖更广的 LLM 应用评测场景，比如：
RAG 评测
Agent 评测
聊天机器人评测
幻觉检测
答案相关性
上下文相关性
自定义评测规则
CI/CD 阈值拦截
DeepEval 官方文档介绍了多种指标，例如 Answer Relevancy、Faithfulness、Contextual Relevancy、Contextual Recall、Contextual Precision 等。
它最像工程里的 Pytest：
写测试用例，配置指标，设置阈值，跑评测，出结果。
如果指标低于阈值，就认为这次改动不通过。
六、DeepEval 核心指标通俗解释
6.1 Hallucination：有没有胡说？
Hallucination 就是幻觉检测。
比如上下文里没有说"支持退款"，模型却回答：
"用户可以在 7 天内无理由退款。"
这就是幻觉。
DeepEval 可以通过 hallucination 相关指标判断回答是否脱离上下文。
6.2 Contextual Precision：检索排序好不好？
DeepEval 的 Contextual Precision 关注 RAG 检索结果的排序质量，用来评估 retriever 或 re-ranker 是否把相关内容排在更靠前的位置。
这对生产系统很重要。
因为大模型通常更关注 Prompt 前面的内容。
如果最相关资料排在第 8 条，第 1 到第 7 条都是干扰项，模型就可能答偏。
6.3 Contextual Recall：关键信息有没有找全？
Contextual Recall 判断召回上下文是否包含回答问题所需的信息。
这适合检查：
切片是否太碎？
Embedding 模型是否不适合？
TopK 是否太小？
混合检索是否缺失关键词召回？
知识库是否缺少内容？
6.4 Contextual Relevancy：召回内容和问题是否相关？
这个指标看的是：
召回的资料是不是围绕用户问题。
比如用户问"怎么开发票"，结果召回了一堆"会员等级说明"，那就是 Contextual Relevancy 低。
6.5 G-Eval：自定义业务评测规则
DeepEval 里比较强的是 G-Eval。
它可以让你写自定义评测标准。
官方文档说明，G-Eval 是一种使用 LLM-as-a-judge 的评测方式，可以按照自定义 criteria 来评估输出。
比如业务规则：
回答必须使用中文。
回答不能出现"我不知道以外的编造内容"。
回答必须分步骤说明。
回答必须引用知识库依据。
客服回答不能承诺赔偿金额。
医疗场景不能给诊断结论。
金融场景不能直接给投资建议。
法律场景必须提示用户咨询专业人士。
这些就可以用自定义评测规则做自动化检查。
七、RAGAS 和 DeepEval 怎么选？
7.1 如果主要是 RAG 知识库问答，优先看 RAGAS
RAGAS 更聚焦 RAG。
适合：
企业知识库问答
智能客服
文档问答
合同问答
政策问答
内部制度问答
检索增强生成系统
它的优势是：
指标围绕 RAG 设计，能拆解检索和生成问题。
比如：
Faithfulness 低：模型可能胡说。
Context Precision 低：召回垃圾内容太多。
Context Recall 低：关键资料没召回。
Answer Relevancy 低：回答没答到点上。
这对排查问题非常有帮助。
7.2 如果要做完整工程测试，优先看 DeepEval
DeepEval 更像测试框架。
适合：
LLM 应用单元测试
Prompt 回归测试
Agent 工具调用评测
CI/CD 自动拦截
多轮对话评测
自定义业务规则评测
它的优势是工程化更强。
尤其适合团队里这样使用：
开发改 Prompt
↓
提交代码
↓
CI 自动跑 DeepEval
↓
指标达标才允许合并
↓
指标不达标直接失败
这种方式非常适合生产环境。
7.3 最佳实践：两个都可以用
不是非要二选一。
可以这样搭配：
RAGAS 负责 RAG 核心质量评测。
DeepEval 负责工程测试、阈值拦截、自定义规则、CI 集成。
也就是说：
RAGAS 更像"RAG 体检工具"。
DeepEval 更像"AI 应用自动化测试框架"。
八、自动化评测完整落地流程
8.1 第一步：准备评测数据集
自动化评测的核心不是工具，而是数据集。
评测数据集一般包含：
问题 question
标准答案 ground_truth
召回上下文 contexts
模型回答 answer
业务标签 category
难度等级 difficulty
来源文档 doc_id
期望关键词 expected_keywords
禁止内容 forbidden_words
例如：
{
"question": "试用期离职需要提前几天通知？",
"ground_truth": "试用期员工离职需要提前3天通知。",
"contexts": [
"员工在试用期内解除劳动合同，应提前三日通知公司。"
],
"answer": "试用期离职需要提前3天通知公司。",
"category": "人事制度",
"difficulty": "easy"
}不要一上来追求几千条。
可以先做：
50 条核心问题
100 条高频问题
200 条线上真实问题
500 条覆盖主要业务场景的问题
关键是质量，不是数量。
8.2 第二步：设计问题分类
评测集不能乱堆问题。
要分层。
可以分成：
高频简单问题
多条件组合问题
容易混淆问题
跨文档问题
需要计算的问题
需要总结的问题
需要拒答的问题
知识库无答案的问题
敏感风险问题
长问题
口语化问题
错别字问题
例如：
简单问题：
"怎么修改密码？"
多条件问题：
"我是试用期员工，本月请假 2 天，现在想离职，需要提前多久？"
跨文档问题：
"销售合同审批需要哪些材料，财务付款又需要哪些条件？"
无答案问题：
"老板明天会不会涨工资？"
拒答问题：
"帮我伪造一份病假证明。"
这种分层非常重要。
因为它能让你知道系统到底弱在哪里。
8.3 第三步：跑 RAG 链路，收集中间结果
自动化评测不能只收最终答案。
必须保存中间过程。
一次问答最好记录：
requestId
user_query
rewrite_query
retrieved_chunks
rerank_score
final_context
prompt
model_answer
model_name
temperature
token_usage
latency
trace_id
知识库版本
Prompt 版本
Embedding 模型版本
切片策略版本
为什么要记录这些？
因为评测结果差的时候，你要知道问题出在哪。
是问题改写错了？
是检索没召回？
是重排序排错了？
是 Prompt 太乱？
是模型幻觉？
是知识库本身没有答案？
是新版本 Embedding 效果变差？
没有中间日志，评测只能告诉你"差"。
有中间日志，评测才能告诉你"为什么差"。
8.4 第四步：选择评测指标
一套比较实用的指标组合是：
检索阶段：
Context Precision
Context Recall
Context Relevancy
TopK 命中率
MRR
人工相关性标签
生成阶段：
Faithfulness
Answer Relevancy
Answer Correctness
Hallucination
格式合规
安全合规
业务口径一致性
系统阶段：
平均耗时
P95 耗时
Token 成本
失败率
重试率
超时率
降级率
最终你会得到一张评测报告：
| 指标 | 结果 | 说明 |
|---|---|---|
| Context Recall | 0.82 | 大部分关键资料能召回 |
| Context Precision | 0.61 | 垃圾召回偏多 |
| Faithfulness | 0.90 | 回答基本忠于资料 |
| Answer Relevancy | 0.78 | 部分回答绕远 |
| Hallucination | 0.08 | 幻觉率较低 |
| 平均耗时 | 2.3s | 可以接受 |
| P95 耗时 | 5.8s | 高峰期偏慢 |
九、生产环境怎么用自动化评测？
9.1 场景一：Prompt 改动前后对比
比如你改了 Prompt：
老版本：
"请根据资料回答用户问题。"
新版本：
"请严格根据资料回答，如果资料中没有答案，请回答无法确认。"
然后跑同一批评测集。
对比结果：
Faithfulness 是否提升？
Answer Relevancy 是否下降？
拒答率是否升高？
回答是否变得过于保守？
Token 成本是否增加？
很多时候，Prompt 改完不是单纯变好，而是：
幻觉降低了，但拒答变多了。
回答更安全了，但可用性下降了。
格式更统一了，但内容变啰嗦了。
自动化评测就是帮你量化这些变化。
9.2 场景二：切片策略评测
RAG 里切片非常关键。
比如你有三种方案：
方案 A：每 300 字切一片
方案 B：每 800 字切一片
方案 C：按标题层级切片
怎么判断哪个好？
不能靠感觉。
应该用评测集跑一遍：
Context Recall 哪个高？
Context Precision 哪个高？
Faithfulness 哪个高？
回答耗时哪个低？
Token 成本哪个低？
一般来说：
切片太小，容易丢上下文。
切片太大，容易塞进无关内容。
按标题切片，结构更自然，但实现更复杂。
自动化评测可以帮你找到平衡点。
9.3 场景三：Embedding 模型替换评测
比如你想从旧 Embedding 模型换成新 Embedding 模型。
不要直接上线。
先跑评测：
同一批问题
同一套知识库
同一个 TopK
只替换 Embedding 模型
然后比较：
召回率有没有提升？
相关性有没有提升？
耗时有没有增加？
向量维度有没有变大？
存储成本有没有变化？
如果 Context Recall 提升明显，但 Context Precision 下降，说明新模型召回更广，但噪声也变多。
这时候可以配合 rerank。
9.4 场景四：重排序模型评测
重排序模型的作用是：
先粗召回 30 条，再精选前 5 条给大模型。
评测重点是：
Context Precision
Contextual Precision
TopK 相关性
最终回答质量
整体耗时
如果加了 rerank 后：
Context Precision 提升
Faithfulness 提升
Answer Relevancy 提升
但耗时只增加 200ms
那就值得。
如果只提升一点点，但耗时增加 1 秒，就要谨慎。
9.5 场景五：上线前 CI/CD 自动拦截
生产级做法是：
每次改代码、Prompt、切片策略、检索参数、模型版本，都自动跑评测。
例如设置阈值：
Faithfulness 不能低于 0.85
Answer Relevancy 不能低于 0.80
Context Recall 不能低于 0.75
幻觉率不能高于 0.10
P95 耗时不能超过 6 秒
如果不达标，就不允许上线。
这就是 AI 应用里的质量门禁。
十、RAGAS 落地示例思路
10.1 输入数据格式
RAGAS 常见需要这些字段：
question
answer
contexts
ground_truth
通俗理解：
question：用户问什么
answer：模型答什么
contexts：检索出来的资料
ground_truth：人工标准答案
如果没有 ground_truth，也可以评估部分指标，比如 Faithfulness、Answer Relevancy、Context Precision 等。
10.2 RAGAS 适合回答哪些问题？
比如你做知识库问答，评测后发现：
Faithfulness 高，Answer Relevancy 低。
说明模型基本没胡说，但回答没答到点上。
可能原因：
Prompt 没要求直接回答
问题改写错了
召回内容太长
模型输出太发散
如果：
Context Recall 低，Faithfulness 也低。
说明关键资料没召回，模型开始猜。
应该优化：
切片策略
Embedding 模型
混合检索
TopK
query rewrite
知识库清洗
如果：
Context Precision 低，但 Context Recall 高。
说明资料找到了，但混入了很多垃圾内容。
应该优化：
rerank
过滤规则
metadata 条件
文档分类
召回阈值
这就是 RAGAS 的价值：
它不是只告诉你"好不好"，而是告诉你"哪里不好"。
十一、DeepEval 落地示例思路
11.1 DeepEval 像写测试用例
DeepEval 的工程思路更像：
写一个测试文件
定义输入问题
定义实际输出
定义检索上下文
选择评测指标
设置阈值
运行测试
比如：
from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric
test_case = LLMTestCase(
input="试用期离职需要提前几天通知？",
actual_output="试用期离职需要提前3天通知公司。",
retrieval_context=[
"员工在试用期内解除劳动合同，应提前三日通知公司。"
]
)
answer_relevancy = AnswerRelevancyMetric(threshold=0.8)
faithfulness = FaithfulnessMetric(threshold=0.8)
assert_test(test_case, [answer_relevancy, faithfulness])这类写法非常适合团队工程化。
因为研发同学熟悉测试思维。
你可以把它放进 CI 里，每次改动自动跑。
11.2 DeepEval 适合做业务规则评测
比如智能客服场景：
要求：
不能承诺一定退款。
不能编造政策。
不能输出内部系统字段。
不知道就说无法确认。
回答必须简洁。
回答必须给下一步操作建议。
这些不一定是 RAGAS 标准指标能覆盖的。
这时 DeepEval 的自定义指标就很有用。
十二、自动化评测指标怎么设计才合理？
12.1 不要只看一个总分
很多团队容易犯错：
做一个"综合得分"，然后只看总分。
这很危险。
因为 RAG 系统的问题是分层的。
比如：
总分 85，看起来不错。
但拆开看：
Context Recall 只有 0.55
Faithfulness 有 0.95
Answer Relevancy 有 0.88
这说明模型很听话，但资料经常没找全。
如果不拆指标，你根本不知道问题在哪。
12.2 指标要和业务风险挂钩
不同业务关注点不一样。
普通 FAQ：
重点看 Answer Relevancy、Context Precision。
政策制度问答：
重点看 Faithfulness、Answer Correctness、拒答准确率。
客服售后：
重点看业务口径、安全合规、幻觉率。
金融法律医疗：
重点看拒答、风险提示、合规性、来源依据。
数据分析助手：
重点看工具调用准确率、SQL 正确率、计算结果正确性。
Agent 系统：
重点看任务完成率、工具选择准确率、步骤稳定性、异常恢复能力。
十三、评测集怎么建设？
13.1 从线上日志里抽问题
最真实的问题来自线上。
可以从日志中抽取：
高频问题
低满意度问题
用户追问多的问题
人工客服接管的问题
模型拒答的问题
模型答错的问题
召回为空的问题
耗时特别长的问题
这些问题比自己编的测试题更有价值。
13.2 人工标注标准答案
自动化评测离不开高质量标注。
至少要标：
标准答案
答案依据
相关文档片段
问题分类
是否允许拒答
风险等级
关键词
不允许出现的内容
标注不是越复杂越好。
前期可以轻量做。
比如每条数据只标：
question
ground_truth
relevant_context
category
后面再逐步丰富。
13.3 构造难题集
普通问题测不出系统边界。
一定要有难题集。
比如：
相似政策混淆
多个条件组合
跨文档总结
知识库没有答案
用户故意诱导
错别字
口语化表达
长文本问题
反问句
多轮追问
难题集可以专门用来做版本回归测试。
十四、自动化评测报告应该怎么看？
14.1 看整体分数
先看整体：
平均 Faithfulness
平均 Answer Relevancy
平均 Context Precision
平均 Context Recall
失败率
幻觉率
拒答率
耗时
成本
这能判断系统大盘表现。
14.2 看分类分数
再按分类看：
人事制度类
财务报销类
合同审批类
产品说明类
售后政策类
异常投诉类
可能整体分数不错，但某个分类很差。
例如：
整体 Answer Relevancy 0.84
但财务报销类只有 0.62
这说明财务类知识库可能需要重点优化。
14.3 看 Badcase
指标只是入口，Badcase 才是根因。
每次评测要沉淀：
问题
模型答案
标准答案
召回内容
评测得分
错误原因
修复方案
是否已修复
错误原因可以分类：
知识库缺失
切片错误
召回失败
排序错误
Prompt 问题
模型幻觉
业务规则缺失
问题改写错误
多轮上下文丢失
最后形成 Badcase 闭环。
十五、常见问题和优化方向
15.1 Faithfulness 低怎么办？
说明模型容易脱离资料。
优化方向：
Prompt 加强"只根据资料回答"
没有依据时明确拒答
减少无关上下文
增加引用来源
降低 temperature
增加后处理校验
引入事实一致性检查
15.2 Context Recall 低怎么办？
说明该找的资料没找出来。
优化方向：
优化切片策略
增加 chunk overlap
使用混合检索
增加 query rewrite
提高 TopK
换 Embedding 模型
补充关键词索引
增加 metadata 过滤
清洗知识库标题和层级结构
15.3 Context Precision 低怎么办？
说明召回噪声太多。
优化方向：
增加 rerank
调高相似度阈值
过滤低质量文档
按业务类型分库检索
使用 metadata 限制范围
优化用户意图识别
减少 TopK
文档去重
15.4 Answer Relevancy 低怎么办？
说明回答没答到点上。
优化方向：
Prompt 要求先直接回答
减少背景废话
增加回答模板
强化问题改写
保留用户原问题
多轮对话中补充上下文
限制回答范围
15.5 Answer Correctness 低怎么办？
说明最终答案错。
优化方向：
检查知识库是否过期
检查标准答案是否正确
检查召回上下文是否完整
检查 Prompt 是否误导
检查模型是否幻觉
检查业务规则是否缺失
检查是否需要工具调用
十六、RAGAS 和 DeepEval 的生产级组合方案
16.1 离线评测
每天或每次发布前跑：
固定评测集
线上抽样评测集
Badcase 回归集
难题集
输出：
版本对比报告
指标趋势
失败用例
优化建议
16.2 在线评测
线上不能每条都用大模型评测，成本太高。
可以做抽样：
1% 请求进入评测
低满意度请求进入评测
人工接管请求进入评测
高风险分类请求进入评测
召回为空请求进入评测
用户连续追问请求进入评测
评测结果进入看板。
16.3 发布门禁
上线前设置质量门槛：
核心指标不能下降超过 3%
高风险问题不能出现严重错误
Badcase 回归集必须全部通过
幻觉率不能超过阈值
P95 耗时不能超过阈值
这才是企业级 AI 应用该有的发布方式。
十七、一个完整的自动化评测架构
可以这样设计：
用户问题日志
↓
样本抽取
↓
人工标注 / 自动生成候选标注
↓
评测数据集管理
↓
RAG 链路批量执行
↓
保存检索结果、Prompt、模型回答
↓
RAGAS / DeepEval 自动评分
↓
指标看板
↓
Badcase 分析
↓
优化检索、Prompt、模型、知识库
↓
再次评测
↓
上线发布
这就是一个闭环。
自动化评测不是一次性工作。
它应该像单元测试、接口测试、性能测试一样，成为 AI 应用研发流程的一部分。
十八、总结
自动化评测解决的是一个核心问题：
AI 应用不能靠感觉上线，必须靠数据说话。
RAGAS 更适合评测 RAG 系统，能拆解检索和生成质量。
DeepEval 更适合工程化测试，像 Pytest 一样把大模型应用纳入自动化测试、CI/CD 和质量门禁。
RAG 评测不能只看最终答案。
要同时看：
资料有没有找对
资料有没有找全
答案有没有答到点上
答案有没有忠于资料
有没有幻觉
有没有违反业务规则
耗时和成本是否可接受
真正生产级的做法是：
评测集建设 + 指标体系 + 自动化测试 + Badcase 闭环 + 发布门禁。
一句话总结：
RAGAS 让你知道 RAG 哪里差，DeepEval 让你把 AI 应用像工程项目一样测试起来。