RAG系统上线前必修课：检索质量与生成效果评估体系
RAG（Retrieval-Augmented Generation，检索增强生成）真正进入企业生产环境后，最容易出现的问题并不是“模型不够聪明”，而是没有一套能够量化系统质量的评测体系。
开发阶段经常出现这样的情况：测试人员输入几个问题，发现答案“看起来不错”，于是认为RAG已经可以上线；但正式接入数万份企业文档后，问题开始集中暴露——有些问题检索不到正确资料，有些问题虽然召回了正确文档，却把关键内容排在很靠后的位置，还有一些问题检索结果完全正确，但模型最终生成的答案仍然出现事实错误、遗漏甚至幻觉。
这说明一个核心事实：
RAG不是单一模型，而是一条由数据、切分、检索、重排、上下文组装和生成共同构成的链路。
因此，RAG系统不能只看最终回答是否“像人话”，而应该把系统拆成多个可观测、可测量的环节，分别回答三个问题：
该找的资料有没有找到？
找到的资料是否真正支持问题？
模型是否基于这些资料生成了正确、完整、可信的答案？
RAGAs等研究工作也明确指出，RAG评估至少涉及检索模块找到相关上下文的能力、模型对上下文的利用能力以及最终生成质量，而不能只评价最终文本。([ACL Anthology][1])
对于企业系统而言，更合理的做法是建立一条完整的评测流水线：
┌──────────────────┐
│ 企业知识库 │
└────────┬─────────┘
│
文档切分/索引
│
▼
用户问题 ────────► Query处理
│
▼
┌────────────────────┐
│ Retriever │
│ BM25 / Vector │
│ Hybrid Search │
└─────────┬──────────┘
│
Top-K
│
▼
┌────────────────────┐
│ Reranker │
└─────────┬──────────┘
│
Top-N
│
▼
┌────────────────────┐
│ Context Assembly │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ LLM │
└─────────┬──────────┘
│
▼
Answer
│
┌─────────────┴─────────────┐
▼ ▼
Retrieval Eval Generation Eval
Recall / MRR Faithfulness
Precision / NDCG Correctness
Hit Rate Relevance
│ │
└─────────────┬─────────────┘
▼
评测报告
│
▼
版本迭代 / 回归测试
一、为什么RAG上线前必须建立评测体系
传统搜索系统通常有明确的相关性判断：输入一个Query，系统返回一组文档，然后通过人工标注或者点击行为判断结果是否相关。
RAG则多了一层复杂性。
假设企业知识库中存在以下三个文档：
Doc A：2026年员工报销制度
Doc B：2025年员工报销制度
Doc C：差旅费用审批流程
用户问：
2026年员工出差住宿费最高可以报销多少？
系统可能发生三种情况。
情况一：正确检索，正确生成
Query
↓
Doc A
↓
LLM
↓
正确答案
这是理想情况。
情况二：检索错误，模型“自己发挥”
Query
↓
Doc B
↓
LLM
↓
引用2025年政策回答
最终答案可能语言非常流畅，但事实已经过期。
情况三：检索正确，生成错误
Query
↓
Doc A
↓
LLM误读/遗漏
↓
错误答案
这类问题尤其容易被传统RAG测试忽略。
因此，单纯统计最终答案正确率无法回答：
到底是Retriever有问题，还是LLM有问题？
企业RAG评测的第一原则，就是把检索评测与生成评测解耦。
二、第一步：建立企业级Golden Dataset
没有评测数据集，就没有真正意义上的RAG评测。
企业应该建立自己的Golden Dataset，也就是一套经过人工确认、能够代表真实业务场景的问题集合。
一个基本的数据结构可以设计成：
{
"id": "qa-000001",
"question": "员工出差住宿费的报销标准是多少？",
"reference_answer": "根据2026年差旅管理办法，员工住宿费按照职级和城市类别执行对应标准。",
"relevant_documents": [
"doc_2026_travel_policy"
],
"relevant_chunks": [
"chunk_01882"
],
"category": "企业制度",
"difficulty": "medium"
}
进一步，可以增加：
{
"question_type": "factoid",
"department": "财务",
"version": "2026",
"expected_entities": [
"住宿费",
"职级",
"城市类别"
],
"must_cite": true
}
这样做的意义在于：后续系统发生变化时，可以对同一批问题重复测试。
1. 数据集不能只包含简单问题
企业真实用户的问题远比Demo复杂。
至少应该覆盖：
类型 | 示例 |
|---|---|
事实查询 | 报销标准是多少？ |
条件查询 | 什么情况下可以申请退款？ |
多跳问题 | A政策和B政策同时满足时如何处理？ |
对比问题 | 新旧制度有哪些变化？ |
时间问题 | 2026年政策与2025年有什么区别？ |
否定问题 | 哪些费用不能报销？ |
模糊问题 | 出差住宿怎么报？ |
长问题 | 某业务发生特定条件时应该执行什么流程？ |
无答案问题 | 公司制度中是否规定了某项不存在的政策？ |
特别要注意无答案问题。
企业RAG不能只测试“有答案的问题”，还必须测试：
知识库没有答案时，模型能不能明确说“不知道”。
否则系统可能在知识库缺少信息时通过模型先验知识强行补答案。
三、检索质量评估：Recall到底意味着什么
检索阶段首先关注的是：
相关内容有没有进入Top-K？
这就是Recall@K。
设某个Query真正相关的文档集合为：
Retriever返回Top-K文档集合：
那么：
例如：
真实相关文档：
A、B、C
Top-5检索结果：
D、A、F、B、G
那么：
Recall@5 = 2 / 3 = 66.7%
因为A、B被召回，而C没有。
1. 为什么RAG尤其关注Recall
传统搜索系统可能更强调Precision。
但对于RAG来说，如果正确资料根本没有进入上下文，后面的LLM基本没有可靠依据。
可以简单理解：
正确答案不在Context
↓
LLM无法可靠回答
所以RAG通常首先应该解决：
Recall不能太低。
例如企业内部知识库的第一阶段评估可以设定：
Recall@5 >= 90%
Recall@10 >= 95%
这不是通用行业标准，而应该根据业务风险、知识库规模和问题类型建立自己的SLO。
四、MRR：不仅要找到，还要排得靠前
Recall只告诉我们：
找到了没有？
但没有告诉我们：
第几个结果才找到？
这就是MRR（Mean Reciprocal Rank）。
对于单个Query：
如果正确答案排名：
第1名 → RR = 1
第2名 → RR = 0.5
第3名 → RR = 0.333
第10名 → RR = 0.1
多个Query取平均：
例如：
Query 1 → Rank 1
Query 2 → Rank 2
Query 3 → Rank 4
那么：
MRR特别适合评价：
FAQ检索
单答案查询
企业制度查询
知识库问答
搜索结果排序
BEIR等信息检索基准也将Recall、Precision、NDCG、MAP、MRR等作为重要检索指标。([GitHub][2])
五、Recall高，为什么RAG仍然可能很差
这是企业RAG最常见的误区之一。
假设：
Recall@10 = 100%
看起来非常好。
但Top-10可能是：
1. 无关文档
2. 无关文档
3. 无关文档
4. 旧政策
5. 旧政策
6. 相关文档
7. 相关文档
8. 无关文档
9. 无关文档
10. 相关文档
虽然相关资料被召回，但上下文充满噪声。
这时候就需要Precision类指标。
六、Precision与Context Precision
传统Precision@K：
例如Top-5中有3个相关文档：
对于RAG，还可以进一步关注Context Precision：
排在前面的上下文是否更加相关？
这比简单统计“相关文档数量”更加重要。
因为：
方案A：
相关
相关
相关
无关
无关
明显优于：
方案B：
无关
无关
相关
相关
相关
虽然两者Precision@5完全一样。
企业RAG因此通常应该同时观察：
Recall@K
Precision@K
MRR
NDCG@K
Context Precision
而不是只看一个指标。
七、NDCG：处理“相关程度不同”的问题
现实知识库中，文档并不是简单的“相关/不相关”。
例如：
文档A：完全回答问题
文档B：部分回答问题
文档C：背景介绍
文档D：完全无关
可以定义：
A = 3
B = 2
C = 1
D = 0
这时候NDCG（Normalized Discounted Cumulative Gain）会更加合适。
DCG的核心思想是：
再通过理想排序进行归一化：
NDCG特别适用于企业知识库中存在大量“部分相关文档”的情况。
例如：
Query：
2026年上海地区员工住宿标准是多少？
结果：
1. 2026差旅住宿标准——上海
2. 2026差旅制度
3. 2025差旅制度
4. 全国差旅制度
5. 财务报销流程
显然第1个结果价值最高。
NDCG能够比简单Recall更加细致地描述这种排序质量。
八、RAG检索评测的正确分层方式
一个成熟系统不应该只测最终Retriever。
应该把检索链路拆开：
Query
│
├── Query Rewrite
│
▼
Retriever
│
├── BM25
├── Vector Search
└── Hybrid Search
│
▼
Top-K
│
▼
Reranker
│
▼
Top-N Context
然后分别评估：
召回阶段：
Recall@K
Precision@K
排序阶段：
MRR
NDCG@K
上下文阶段：
Context Precision
Context Recall
Context Relevance
这样才能定位问题。
例如：
BM25 Recall@20 = 94%
Vector Recall@20 = 87%
Hybrid Recall@20 = 97%
Hybrid MRR@10 = 0.71
Reranker NDCG@5 = 0.89
那么显然：
问题不在基础召回，而可能集中在Reranker或者Context组装阶段。
九、生成效果评估：不能只用BLEU和ROUGE
传统NLP经常使用BLEU、ROUGE等指标。
但RAG问答存在一个特殊问题：
一个问题可能存在多个完全不同但都正确的答案。
例如：
问题：
如何申请VPN？
答案A：
登录IT门户提交VPN申请，经管理员审批后即可使用。
答案B：
员工需要进入IT服务平台创建VPN权限申请，审批通过后系统自动开通。
两句话表达方式不同，但事实完全一致。
因此单纯依赖文本字面重合并不合理。
RAG生成评估应该至少包含四个维度：
生成质量
│
┌───────────┼───────────┐
│ │ │
Correctness Faithfulness Relevance
│ │ │
└───────────┼───────────┘
│
Completeness
十、Faithfulness：答案是不是由Context支持
Faithfulness，也可以理解为事实忠实度/上下文一致性。
核心问题：
模型回答中的事实，能否从检索上下文中得到支持？
例如Context：
公司规定：
普通员工年度培训预算为5000元。
模型回答：
普通员工年度培训预算为10000元。
即使模型语言非常自然，也应该判定：
Faithfulness = 0
一个常见实现方式，是把回答拆成若干原子事实：
Answer：
1. 普通员工有培训预算。
2. 年度预算为10000元。
3. 预算可以用于外部课程。
然后逐条判断Context是否支持。
最终可以近似表示为：
这也是RAGAs评估体系中的核心思想之一。([ACL Anthology][1])
十一、Answer Correctness：正确不等于忠实
Faithfulness与Correctness必须区分。
例如知识库：
2026年公司员工餐补标准：
每人每天30元。
模型回答：
公司员工每天餐补30元。
这是：
Faithful = 1
Correct = 1
但如果知识库本身已经过期：
2026制度实际上规定为40元
而系统检索到了错误的旧文档，那么模型可能：
Faithful = 1
Correct = 0
这揭示了一个重要问题：
模型忠实地回答错误资料，仍然是错误。
所以企业评测不能只有Faithfulness，还必须存在Reference Answer或者人工标注，用于评价事实正确性。
十二、Answer Relevancy：有没有真正回答问题
另一个常见问题是：
模型说了一堆正确的话，但没有回答用户真正的问题。
例如用户问：
VPN申请需要多久？
模型回答：
VPN是一种虚拟专用网络技术，可以帮助员工安全访问企业内部资源。企业VPN通常采用加密通信……
这些内容都可能正确。
但用户真正想知道的是：
需要多久。
因此需要Answer Relevancy。
可以将其理解为：
Question
↓
用户真正意图
↓
Answer
↓
是否覆盖核心意图？
企业可以进一步按照业务场景进行评分：
0：没有回答问题
1：部分相关
2：基本回答
3：完整回答
对于高风险业务，可以要求人工评估，而不是完全依赖LLM-as-a-Judge。
十三、Completeness：企业RAG经常忽略的指标
对于复杂问题，“答案是否完整”非常重要。
例如：
新员工入职需要准备哪些材料？
标准答案可能包含：
身份证
银行卡
学历证明
劳动合同
照片
体检报告
模型只回答：
身份证、银行卡、学历证明。
它不能算完全错误。
但答案是不完整的。
因此可以将：
例如覆盖4项中的6项：
对于企业制度、操作流程、合规知识等场景，这个指标非常重要。
十四、建立统一的RAG评测数据结构
推荐在系统内部统一设计Evaluation Record：
{
"query": "员工出差住宿标准是多少？",
"retrieval": {
"top_k": 10,
"retrieved_ids": [
"doc_01",
"doc_07",
"doc_12"
],
"recall": 1.0,
"mrr": 0.5,
"ndcg": 0.86
},
"generation": {
"answer": "……",
"faithfulness": 0.95,
"correctness": 0.92,
"relevance": 0.98,
"completeness": 0.88
},
"latency": {
"retrieval_ms": 82,
"rerank_ms": 46,
"llm_ms": 1240,
"total_ms": 1398
}
}
最终可以形成统一的评测结果：
RAG Evaluation
│
┌───────────────┼────────────────┐
▼ ▼ ▼
Retrieval Generation System
│ │ │
Recall@K Correctness Latency
MRR Faithfulness Cost
NDCG Relevance Error Rate
Precision Completeness
十五、推荐的企业RAG评测架构
一个可落地的工程架构可以设计成：
┌─────────────────────┐
│ Evaluation Dataset │
│ Golden QA / Cases │
└──────────┬──────────┘
│
▼
┌──────────────────┐
│ Evaluation Runner│
└────────┬─────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Retriever Reranker LLM
│ │ │
▼ ▼ ▼
Retrieval Log Ranking Log Generation Log
│ │ │
└──────────────┼──────────────┘
▼
┌─────────────────┐
│ Metric Engine │
├─────────────────┤
│ Recall │
│ MRR │
│ NDCG │
│ Precision │
│ Faithfulness │
│ Correctness │
│ Relevance │
│ Completeness │
└────────┬────────┘
▼
┌─────────────────┐
│ Evaluation DB │
└────────┬────────┘
▼
┌─────────────────┐
│ Dashboard / CI │
└─────────────────┘
其中最关键的是：
每一次评测都必须保存检索结果和最终答案，而不能只保存最终Score。
否则出现问题时无法回溯。
十六、一个简单的Recall/MRR实现
例如使用Python实现基础检索指标：
def recall_at_k(retrieved, relevant, k):
top_k = retrieved[:k]
if not relevant:
return 0.0
return len(set(top_k) & set(relevant)) / len(set(relevant))
def reciprocal_rank(retrieved, relevant, k):
relevant = set(relevant)
for index, doc_id in enumerate(retrieved[:k], start=1):
if doc_id in relevant:
return 1.0 / index
return 0.0
def mrr(results, k=10):
if not results:
return 0.0
total = 0.0
for retrieved, relevant in results:
total += reciprocal_rank(
retrieved,
relevant,
k
)
return total / len(results)
生产环境中还应该考虑：
重复chunk
文档级/Chunk级相关性
多个正确文档
部分相关文档
无答案Query
因此不要把上述代码直接当成完整的企业评测实现，而应该将其作为Metric Engine的基础组件。
十七、LLM-as-a-Judge应该怎么用
对于Faithfulness、Relevance、Completeness等语义指标，企业通常会使用LLM进行评估。
基本结构：
Question
Context
Answer
│
▼
Evaluator LLM
│
├── Correctness
├── Faithfulness
├── Relevance
└── Completeness
│
▼
JSON Score
Evaluator Prompt必须要求结构化输出，例如：
你是企业RAG质量评估器。
请根据Question、Context和Answer进行评价。
评分：
0 = 完全错误
1 = 部分正确
2 = 基本正确
3 = 完全正确
必须严格依据Context判断Faithfulness。
返回JSON：
{
"faithfulness": 0-3,
"correctness": 0-3,
"relevance": 0-3,
"completeness": 0-3,
"reason": "简要说明"
}
但需要注意：
LLM-as-a-Judge本身也是一个需要被评估的系统。
如果Evaluator对某类答案存在系统性偏差，那么整个评测体系都会受到影响。
因此关键业务指标仍然应该保留人工抽检。
NIST的AI RMF及其生成式AI扩展也强调了AI系统测试、评估、验证与风险管理的重要性。([NIST][3])
十八、人工评测不能被完全替代
企业最合理的方案不是：
全部人工
也不是：
全部LLM
而是：
Evaluation
│
┌────────────┴────────────┐
▼ ▼
自动化评测 人工评测
│ │
Recall / MRR 高风险问题
NDCG 新问题类型
Faithfulness 边界案例
Relevance 争议样本
│ │
└────────────┬────────────┘
▼
最终质量判断
推荐：
80%~95% 自动化
5%~20% 人工抽检
具体比例应该根据业务风险调整。
金融、医疗、法律、企业合规等场景，对人工审核的要求显然高于普通企业知识问答。
十九、评测必须进入CI/CD
真正成熟的RAG系统，不应该上线前评一次就结束。
例如每次修改：
Embedding Model
Chunk Size
Chunk Overlap
Retriever
Reranker
Prompt
LLM
Knowledge Base
都应该自动执行Regression Test。
可以设计成：
Git Commit
│
▼
Build RAG
│
▼
Run Golden Dataset
│
▼
Metric Evaluation
│
▼
Compare Baseline
│
├── Recall下降 > 3% ──► FAIL
├── Faithfulness下降 > 2% ──► FAIL
├── Latency增加 > 20% ──► WARN
└── 全部通过 ──► PASS
例如：
evaluation:
recall_at_10:
threshold: 0.92
direction: maximize
mrr_at_10:
threshold: 0.75
direction: maximize
faithfulness:
threshold: 0.90
direction: maximize
answer_relevance:
threshold: 0.90
direction: maximize
p95_latency_ms:
threshold: 2000
direction: minimize
这比“测试人员觉得效果不错”可靠得多。
二十、不要只看平均值，要看分桶指标
平均分很容易掩盖问题。
例如：
整体Recall@10 = 94%
看起来不错。
但拆开：
产品文档 98%
技术文档 96%
财务制度 95%
法律制度 73%
历史文档 61%
真正的问题已经非常明显。
因此企业应该至少按照：
问题类型
业务部门
知识库
语言
文档类型
难度
时间版本
进行分桶。
例如：
SELECT
question_type,
AVG(recall_at_10),
AVG(mrr),
AVG(faithfulness),
AVG(correctness)
FROM evaluation_results
GROUP BY question_type;
这样可以直接发现：
系统不是“整体不好”，而是“某一类问题不好”。
二十一、建立错误分类体系
指标只能告诉你“哪里下降”，错误分类才能告诉你“为什么下降”。
建议企业建立以下Error Taxonomy：
Retrieval Error
├── Query理解错误
├── Chunk切分错误
├── Embedding语义不匹配
├── BM25关键词缺失
├── Hybrid权重错误
├── Reranker排序错误
├── Top-K过小
└── 数据版本错误
Generation Error
├── Hallucination
├── Context误读
├── 信息遗漏
├── 答非所问
├── 推理错误
├── 时间版本错误
└── 无答案时强行回答
例如：
Recall@10下降
│
▼
检查Retriever
│
├── BM25下降
├── Vector下降
└── Hybrid正常
那么问题可能来自：
Embedding模型
而不是LLM。
这种定位能力，是建立评测体系真正的价值。
二十二、线上数据应该反哺离线评测
Golden Dataset不能永远不变。
生产环境中每天都会出现新的真实问题。
因此可以建立：
Production Query
│
▼
匿名化/脱敏
│
▼
困难样本筛选
│
├── 低置信度
├── 用户重新提问
├── 用户点踩
├── 人工纠正
└── 高风险问题
│
▼
人工标注
│
▼
Golden Dataset
│
▼
Regression Test
这就形成真正的闭环：
线上问题 → 标注 → Golden Dataset → 自动评测 → 模型/检索优化 → 再上线 → 新数据继续进入评测集。
这比一次性建立1000道测试题更加有价值。
二十三、RAG评测最终应该关注“系统级质量”
不要把：
Recall = 95%
直接理解成：
RAG质量 = 95%
这是错误的。
RAG最终效果是多个环节共同决定的：
可以进一步建立企业自己的综合评分：
其中：
R = Recall
M = MRR
F = Faithfulness
C = Correctness
Rel = Relevance
例如：
Recall 25%
MRR 15%
Faithfulness 25%
Correctness 25%
Relevance 10%
但需要强调：
综合分数只适合做总体趋势管理，不应该替代单项指标。
如果Faithfulness低于安全阈值，即使综合得分很高，也不应该上线。
因此实际生产中更推荐：
Hard Gate + Composite Score
即：
必须满足：
Recall >= 90%
Faithfulness >= 90%
Correctness >= 90%
同时：
Composite Score >= 92%
任何Hard Gate不通过，直接阻止发布。
二十四、上线前建议执行的RAG评测清单
一个企业RAG正式上线之前，至少应该完成以下检查。
数据层
□ Golden Dataset建立
□ 每个问题有标准答案
□ 关键问题存在人工标注
□ 有无答案问题
□ 有时间版本问题
□ 有多跳问题
□ 有困难样本
检索层
□ Recall@5
□ Recall@10
□ Precision@K
□ MRR@K
□ NDCG@K
□ Context Precision
□ Context Recall
□ Reranker评估
生成层
□ Answer Correctness
□ Faithfulness
□ Answer Relevance
□ Completeness
□ Hallucination
□ 无答案拒答能力
工程层
□ P50/P95/P99延迟
□ Token消耗
□ 单次请求成本
□ 错误率
□ 超时率
□ 检索日志
□ Prompt版本
□ Model版本
□ Embedding版本
发布层
□ Regression Test
□ Baseline对比
□ 自动化CI
□ 人工抽检
□ 高风险问题专项测试
□ 灰度发布
□ 线上质量监控
二十五、从“能回答”走向“可证明地回答”
RAG真正进入企业生产环境之后，评价标准应该发生变化。
Demo阶段关注：
“它能不能回答？”
生产阶段应该关注：
“它为什么这样回答？”
进一步还要回答：
“它引用的资料是否正确？”
“资料是否完整？”
“模型有没有产生知识库之外的事实？”
“如果换一个Embedding模型，效果有没有下降？”
“如果知识库更新了，旧答案是否仍然存在？”
“昨天的Recall是94%，为什么今天变成89%？”
这就是RAG评测体系存在的意义。
一个成熟的企业RAG系统，本质上应该形成下面这个闭环：
┌───────────────────┐
│ 企业真实问题 │
└─────────┬─────────┘
▼
┌───────────────────┐
│ RAG Pipeline │
└─────────┬─────────┘
▼
┌───────────────────┐
│ Retrieval Metrics │
│ Recall / MRR/NDCG │
└─────────┬─────────┘
▼
┌───────────────────┐
│ Generation Metrics│
│ Correct/Faithful │
└─────────┬─────────┘
▼
┌───────────────────┐
│ Error Analysis │
└─────────┬─────────┘
▼
┌───────────────────┐
│ Golden Dataset │
└─────────┬─────────┘
▼
┌───────────────────┐
│ Regression / CI │
└─────────┬─────────┘
│
└──────► 下一版本RAG
RAGAs的研究已经证明，可以从检索上下文、上下文利用和最终回答多个维度对RAG进行系统化评估，而BEIR等信息检索基准则说明，Recall、MRR、NDCG等指标能够从不同角度描述检索系统性能。([ACL Anthology][1])
但企业真正落地时，不应该照搬某个框架的指标表。评测指标必须围绕业务风险设计。
对于普通企业知识库，可以重点关注：
Recall@K
MRR
Faithfulness
Correctness
Relevance
对于制度、财务、合规等高风险知识库，则应该进一步增加：
版本正确性
引用正确性
拒答准确率
关键事实完整率
人工审核通过率
最终，一个值得上线的RAG系统，不是因为它在几个Demo问题上表现得很好，而是因为它能够用数据证明：
该召回的内容基本都能召回，相关内容能够排在前面，模型能够忠实使用检索结果，最终答案能够正确、完整地解决用户问题，并且当代码、Prompt、Embedding、Reranker或知识库发生变化时，系统能够通过自动化回归测试及时发现质量退化。
这才是企业RAG从“AI Demo”走向“生产系统”的关键一步。
参考资料
Shahul Es, Jithin James, Luis Espinosa-Anke, Steven Schockaert. RAGAs: Automated Evaluation of Retrieval Augmented Generation. EACL 2024. ([ACL Anthology][1])
Nandan Thakur et al. BEIR: A Heterogenous Benchmark for Zero-shot Evaluation of Information Retrieval Models. NeurIPS 2021. ([arXiv][4])
National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). 2024. ([NIST][3])
[1]: https://aclanthology.org/2024.eacl-demo.16/?utm_source=chatgpt.com "RAGAs: Automated Evaluation of Retrieval Augmented Generation - ACL Anthology"
[2]: https://github.com/beir-cellar/beir/wiki/Metrics-available?utm_source=chatgpt.com "Metrics available · beir-cellar/beir Wiki · GitHub"
[3]: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence?utm_source=chatgpt.com "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile | NIST"
[4]: https://arxiv.org/abs/2104.08663?utm_source=chatgpt.com "BEIR: A Heterogenous Benchmark for Zero-shot Evaluation of Information Retrieval Models"