想象一家米其林餐厅:采购员负责从食材仓库里挑选新鲜食材,主厨负责把食材做成菜端上桌。如果只考核采购员“食材新不新鲜”,或者只考核主厨“刀工精不精”,你能保证客人满意吗?显然不能——客人吃的是最终上桌的那道菜,采购与烹饪是环环相扣的一条链。RAG(检索增强生成)系统就像这家餐厅:检索器是采购员,从知识库中找资料;生成器是主厨,把资料组织成答案。RAGAS 框架就是那位“品鉴师”——它不只看中间环节,而是对“从用户提问到最终答案”的整条链路打分,这就是端到端评测。RAGAS 提出了忠实性、答案相关性、上下文相关性等指标,还教你如何构建评测集、定位质量瓶颈、设计优化迭代。这篇文章,我们跟着品鉴师把 RAG 系统的每一个环节都品一遍。
学会 RAG 端到端评测,你就掌握了评估 AI 系统“真正好不好用”的能力,这是 AI 工程师上线、迭代、交付 RAG 应用的必备手艺。
可视化演示
展示RAG查询到答案的全链路评估、忠实度/相关性/精度指标组合,以及端到端质量瓶颈的定位与优化。
本节配有交互动效(进入视口后自动加载,约 3KB)。
RAG端到端评测链路 查询→检索→生成→答案 query→answer 将检索与生成作为整体评估全链路质量。
端到端评测理念
米其林餐厅要评星级,品鉴师绝不会只去后厨检查食材新不新鲜,也不会只看主厨的刀工表演。他会坐在餐桌前,点一道菜,从头吃到尾,然后为“菜端上桌那一刻的完整体验”打分。为什么不分开打分?因为采购和烹饪是接力赛——采购再好,烹饪毁了也是白搭;烹饪再好,采购漏了关键食材,菜照样难吃。只有把整条链放在一起看,才知道客人到底吃得好不好。
RAG 系统正是这样的接力赛。用户输入一个查询 $q$,检索器先从知识库里捞出一批相关上下文 $C$,生成器再基于 $q$ 和 $C$ 写出最终答案 $A$。如果只单独评测检索器“召回的片段准不准”,或只单独评测生成器“单写一句通不通顺”,都无法回答老板最关心的问题:用户问完问题,得到的答案到底能不能用?端到端评测(End-to-End Evaluation)把“检索 + 生成”作为一个整体,在真实问答链路上用统一标准打分。
从数学上看,最终答案的分布是所有可能上下文的加权求和:检索决定“选到哪些上下文”的概率,生成决定“在这些上下文下产出答案”的概率。任何一环掉链子,最终答案都会变差,而且两个环节的失误还可能互相掩盖。RAGAS(Retrieval Augmented Generation Assessment)框架就是围绕这条链路设计的一套端到端评测方法。
回到餐厅——品鉴师不关心采购员和主厨谁更辛苦,只关心最后上桌的那道菜。RAGAS 就是这样一位品鉴师:它接过“用户提问”这张订单,一路看到“答案上桌”,对整条服务链给出综合评价。理解了这种“整体论”,我们才能继续学习它具体怎么打分。
- 符号定义$A$ 表示最终答案,$q$ 表示用户查询,$C$ 是检索器选中的上下文片段,$\mathcal{C}$ 是知识库中所有可能被选中的上下文集合。
- 检索环节 $P(C \mid q)$给定查询 $q$,检索器选到上下文 $C$ 的概率,对应“采购员能否按订单挑对食材”。
- 生成环节 $P(A \mid q, C)$在已知查询与上下文的条件下,生成器写出答案 $A$ 的概率,对应“主厨拿到食材后能否做好菜”。
- 求和 $\sum_{C \in \mathcal{C}}$对所有可能的上下文情况加权求和,把检索与生成两段拼成一条完整链路。
RAGAS核心指标
品鉴师拿到一道菜,会从几个维度分别打分:味道是不是忠于食材本身的鲜美(不能靠添加剂硬撑)、这道菜是不是客人点的那道、摆盘里有没有端上来凑数的菜叶。三个维度加在一起,才是一个完整的用餐评价。
RAGAS 框架提供了三大核心指标,恰好对应品鉴师的三个动作:[RAGAS 官方仓库](0) 中把端到端质量拆成了“答案层”与“上下文层”。先看答案层的忠实性(Faithfulness):把生成答案拆成若干条“论断”(claim),统计其中能被检索上下文支持的论断比例,防止大模型“幻觉”。
再看答案相关性(Answer Relevance)——它回答“这道菜是不是客人点的那道”。RAGAS 让生成模型把答案“倒着翻译”成若干问题,再计算这些生成问题与原问题的余弦相似度(把文本映射成向量后求夹角的余弦,值越接近 1 说明方向越一致):
最后是上下文相关性(Context Relevance)——对应“摆盘里有没有凑数的菜叶”。把检索回的上下文切成句子,统计对回答问题有用的句子占比:
此外,RAGAS 也常用语义相似度(套用上面同一个余弦公式)比较“生成答案”与“参考答案”的接近程度,作为答案正确性的组成部分。品鉴师的三问,本质上是在防“添加剂”、防“点错菜”、防“凑数菜叶”——三个维度都过关,这道菜才配得上高分。
- 切分上下文把检索回的上下文切成句子,总数为 $|\mathcal{T}|$。
- 筛出有用句判断哪些句子与回答问题相关,得到相关句集合 $\mathcal{R}_s$。
- 计算比例相关句占比越高,说明检索结果越聚焦、杂质越少。
评测数据构建
品鉴师要给出公正评价,光吃一道菜不够。他会连着几天,点不同菜系、不同生熟、不同冷热的菜,才敢写评价。评测 RAG 系统也一样,关键在“评测集”——它决定了分数有没有代表性。
RAGAS 的一大特点是“合成测试集”:不依赖大量人工标注,而是让大模型从文档里自动生成问答对。流程是:把知识库文档切块 → 让大模型基于块内容生成问题 → 再基于同一块内容生成标准答案 → 得到“(问题,标准答案,上下文)”三元组构成测试集。生成时还会故意构造多跳、对比、条件约束等难题,逼出系统短板。对应到餐厅:品鉴师不但点招牌菜,还会专门点菜单上没有的、需要厨师临场发挥的菜。
光有数量不够,还要控制场景分布。真实用户的问题服从某个分布,比如 60% 是事实型查询、20% 是推理型查询、20% 是“找不到答案”型查询。构造评测集时应按业务实际流量加权采样:
领域样本组织上,客服、医疗、金融等不同业务线要分开建集,避免跨领域污染;基准标注构建上,对关键样本要引入人工校验,确保金标准答案可靠。品鉴师不会凭一晚上的兴致写评价,他的菜单覆盖了酸甜苦辣各种可能——评测集就是 RAG 系统的“菜单”,场景分布决定了一次评测是“偏科”还是“全面”。
- 场景频次统计从线上日志统计每类场景的出现频次 $f_j$。
- 归一化权重用该频次除以所有场景频次之和,得到采样概率。
- 加权采样构建测试集按该概率从各场景候选问题中抽出 $N$ 条,形成评测集。
指标组合策略
品鉴师打分不止看“总评”。他会说:这道菜味道 9 分、摆盘 6 分、上菜速度 4 分。如果你只告诉他综合 7 分,他就不知道应该改后厨流程还是改摆盘。RAG 评测也一样,RAGAS 给出的是多维指标,最后要用一个“组合策略”把维度拼成一个可决策的数字。
常见做法是加权求和:给不同指标赋权重,权重来自业务目标。比如客服场景更看重忠实性(不能给用户错误承诺),知识问答更看重答案相关性(必须答到点子上):
组合策略还包括阈值设定与结果解读:给每个指标设红黄绿灯,例如忠实性低于 0.7 亮红灯,必须修复才能上线;解读时不要只看平均分,要看分数分布和各场景得分表——平均分可能掩盖“部分场景极差”的问题。品鉴师的白板上不仅有总分,还有每一道工序的细分。组合策略就是帮我们把“多个维度的观察”压缩成“一个能拍板的分数”,同时又不丢掉细节。
- 指标得分向量把每个样本的各项 RAGAS 指标汇总,得到得分集合 $\{s_1, \dots, s_m\}$。
- 权重归一化约束权重和为 1,保证综合分不因维度数量而失衡。
- 加权求和逐项相乘后累加,得到端到端综合得分。
瓶颈定位方法
菜不好吃,品鉴师不会笼统地说“这顿饭不行”。他会追问:是采购没买到对的东西,还是主厨做坏了?RAG 系统端到端分数低时,同样不能停在“优化”两个字上,而要定位瓶颈:到底是检索问题还是生成问题?
最经典的定位方法叫“黄金上下文替换”(oracle context)。保持生成器不变,把检索器召回的结果替换成人工标注的黄金上下文,重新用生成器跑一遍并打分。如果分数大幅上升,说明瓶颈在检索;如果分数几乎不变,说明生成环节拖了后腿。反过来,固定检索结果、换一个更强的生成器测试,如果分数提升明显,则生成是瓶颈。写成公式:
另一个思路是“失败样本研判”:把低分样本收集起来,按场景聚类(比如“长尾专有名词”“数值比较”“多文档归纳”),逐类观察是检索召回不足、上下文含噪,还是答案生成跑偏。聚类之后,优化动作就从“猜”变成“对症下药”。品鉴师很聪明地做了一次对照实验——他请主厨用同一批食材做菜,只是悄悄换成最好的食材试试。哪一道工序的替换能救回品质,哪一道就是短板。黄金上下文替换,就是端到端评测里的“对照实验”。
- 两遍评测同一批测试问题,分别用检索上下文和黄金上下文跑出两份得分。
- 逐样本差分对每个样本求黄金上下文得分与检索上下文得分的差。
- 整体平均对所有样本的差分取平均,量化检索环节的瓶颈贡献。
优化实践方案
找到瓶颈之后,餐厅就该动刀子了。如果品鉴师发现问题出在采购,那就要优化检索侧;如果问题出在烹饪,就要优化生成侧。RAG 的优化也分两侧,配合持续回归形成一个闭环。
检索侧优化:改进文本切块策略(按语义段落切块,而不是按固定长度硬切)、换更好的嵌入模型、做“混合检索”(BM25 关键词检索 + 向量语义检索结合,一个管精确匹配、一个管语义召回)、加 reranker 重排序(对初筛结果精排)。衡量检索质量时常用召回率:
生成侧优化:改进提示词(要求模型严格引用上下文、避免编造)、加入少样本示例、统一输出格式;若仍不稳定,再考虑换更大参数模型或做指令微调。提示词工程是成本最低的手段——在系统提示里写明“只能基于给定上下文回答,找不到就说不知道”,往往能显著提升忠实性。同时要建立“评测 → 定位 → 优化 → 回归”的迭代流程:跑一遍端到端评测,定位瓶颈,优化,再用同一套测试集回归,观察综合分与各维度是否回退。评测集要保持不动,否则优化前后没有可比性。品鉴师的评价不是终点而是起点:他每次吃完都给后厨开一张整改单,下一次再点同样的菜验收效果。优化实践的本质,就是把评测改造成一条可持续的改进流水线。
- 集合定义$R_k$ 是检索返回的前 $k$ 个片段,$G$ 是黄金片段集合。
- 交集计数统计命中的黄金片段个数。
- 召回率计算命中数除以黄金总数,衡量检索侧够不够“全”。
局限与演进
品鉴师再专业,也代替不了每一位客人的口味:有人嫌咸,有人嫌淡。自动评测指标同样有天花板——它打的分数不一定等于用户满意度。
局限之一是指标相关性偏差:自动指标(如余弦相似度、论断支持率)与人类主观判断只有一定相关性,可能出现“高分但用户不买账”。业界做法是定期做“人机相关性校验”,计算自动分数与人工评分的 Spearman 秩相关系数(一种衡量两组排序一致性的统计量):
局限之二是参考答案依赖:很多指标要拿生成答案和标准答案对比,如果参考答案本身质量不高,评测就失真。局限之三是长文本与多跳问题难以拆分论断,风格、安全、礼貌等主观维度也很难用规则覆盖。面向未来模型能力演进,评测系统要“可扩展”:RAGAS 支持自定义 LLM 评测指标(用一段提示词定义新评分规则),方便团队按业务加指标;同时建立持续回归流水线,模型升级、知识库更新、提示词改动都自动触发评测。品鉴师明白,菜单会随季节变化,客人口味也在变。一套好的评测体系,既要像品鉴师一样专业、稳定、可追溯,也要像餐厅一样懂得更新菜单——指标与评测集本身,就是需要持续评测的“系统”。
- 排序配对把每个样本分别按自动分数和人工分数排名,$d_i$ 是样本 $i$ 在两种排名中的位次差。
- 平方累加把位次差平方后求和,放大排序不一致的样本。
- 归一化系数除以 $n(n^2-1)$ 并取补,得到范围在 $[-1, 1]$ 的相关系数。
AI 应用场景
智能客服上线前验收
阶段:评测与验收
解决的问题:电商客服 RAG 系统上线前,运营最关心“用户问了能不能得到可用答案”。只看检索精确率,发现不了大模型乱承诺、答非所问等幻觉问题;等上线再被用户投诉,成本太高。
具体案例:一家电商平台用 RAGAS 对 2000 条真实咨询做端到端评测,发现“退换货政策”场景忠实性只有 0.61。再用黄金上下文替换定位,确认是切块把完整条款切碎了,检索不到关键句子。改为按条款语义切块并加混合检索后,忠实性升至 0.88,上线后人工转接率下降 22%。
企业知识助手持续回归
阶段:持续集成与回归
解决的问题:知识库每月更新、提示词经常改版,如何防止“看似更新实则退化”?人工抽测覆盖不全,需要自动化回归。
具体案例:一家法律科技公司维护了覆盖 500 条场景的评测集,每次 RAG 改动自动跑 RAGAS 流水线。有一次增删文档后,上下文相关性跌了 0.15,流水线立刻报警,团队及时回滚,避免了一次大规模内容事故。
金融合规场景的幻觉把关
阶段:安全合规评测
解决的问题:理财产品问答必须“有据可依”,模型“脑补收益承诺”是重大合规风险。忠实性把答案切分成论断、逐条回溯到产品文档,能自动标记无据论断。
具体案例:某基金公司把忠实性低于 0.8 的回答自动拦截进人工复核队列,并附上支持缺失的论断原文,合规团队可以直接定位风险话术,处置效率提升数倍。
Python 演示
# 简化版 RAGAS 端到端评测# 用迷你语料库模拟知识库, 用关键词重叠模拟检索与生成 import re class MiniRagas: def __init__(self, corpus, retriever_topk=2): self.corpus = corpus # 知识库: 段落列表 self.topk = retriever_topk self.stopwords = set(["the", "a", "an", "is", "are", "of", "in", "on", "to", "and", "with", "for"]) def tokenize(self, text): words = re.findall(r"[a-z0-9]+", text.lower()) return [w for w in words if w not in self.stopwords] def retrieve(self, question): q_tokens = set(self.tokenize(question)) scored = [] for i, doc in enumerate(self.corpus): overlap = len(q_tokens & set(self.tokenize(doc))) scored.append((overlap, i, doc)) scored.sort(key=lambda x: x[0], reverse=True) return [item[1] for item in scored[:self.topk]] def generate(self, question, contexts): for doc in contexts: first = re.split(r"[.!]", doc)[0] if len(self.tokenize(first)) > 3: return first + "." return "I cannot find enough evidence in the pantry." def split_claims(self, answer): return [c.strip() for c in re.split(r"[.!]", answer) if len(self.tokenize(c.strip())) > 0] def faithfulness(self, answer, contexts): claims = self.split_claims(answer) if not claims: return 0.0 context_text = " ".join(contexts).lower() supported = 0 for claim in claims: key_tokens = [w for w in self.tokenize(claim) if len(w) > 3] if not key_tokens: continue hit = sum(1 for w in key_tokens if w in context_text) if hit / len(key_tokens) >= 0.5: supported += 1 return supported / len(claims) def answer_relevance(self, question, answer): q_tokens = set(self.tokenize(question)) a_tokens = set(self.tokenize(answer)) if not q_tokens or not a_tokens: return 0.0 return len(q_tokens & a_tokens) / len(q_tokens | a_tokens) def context_relevance(self, context, question): sentences = [s for s in re.split(r"[.!]", context) if len(self.tokenize(s)) > 0] if not sentences: return 0.0 q_tokens = set(self.tokenize(question)) useful = sum(1 for s in sentences if q_tokens & set(self.tokenize(s))) return useful / len(sentences) def evaluate(self, test_set): metric_map = {"faithfulness": [], "answer_relevance": [], "context_relevance": []} report = [] for item in test_set: question = item["question"] gold = item["gold_context"] retrieved = self.retrieve(question) retrieved_docs = [self.corpus[i] for i in retrieved] answer = self.generate(question, retrieved_docs) metric_map["faithfulness"].append( self.faithfulness(answer, retrieved_docs)) metric_map["answer_relevance"].append( self.answer_relevance(question, answer)) metric_map["context_relevance"].append( self.context_relevance(retrieved_docs[0], question)) oracle_faith = self.faithfulness(answer, [gold]) delta = oracle_faith - metric_map["faithfulness"][-1] report.append({ "question": question, "faithfulness": metric_map["faithfulness"][-1], "answer_relevance": metric_map["answer_relevance"][-1], "context_relevance": metric_map["context_relevance"][-1], "oracle_delta": round(delta, 3), }) summary = {key: sum(vals) / len(vals) for key, vals in metric_map.items()} summary["e2e_score"] = round( 0.4 * summary["faithfulness"] + 0.3 * summary["answer_relevance"] + 0.3 * summary["context_relevance"], 3) return summary, report def build_corpus(): return [ "The restaurant pantry stores fresh ingredients, including vegetables," " cheese, and smoked fish, organized by daily menu needs.", "The head chef starts cooking only after the purchaser returns with" " selected ingredients, following the recipe strictly.", "A Michelin taster scores the final dish on the table, not the" " half-finished ingredients in the kitchen.", "The retrieval module is like a purchaser who picks relevant food from" " the warehouse for the current order.", "Faithfulness means every claim on the plate must come from the" " purchased ingredients, without added fabrication.", "Answer relevance checks whether the cooked dish actually matches what" " the customer ordered.", "Context relevance measures whether the purchased ingredients are truly" " useful for the final dish.", "End-to-end evaluation treats purchasing and cooking as one complete" " service chain from order to table.", ] def main(): corpus = build_corpus() evaluator = MiniRagas(corpus, retriever_topk=2) test_set = [ {"question": "who scores the final dish in a michelin restaurant?", "gold_context": corpus[2]}, {"question": "what does faithfulness require for each claim?", "gold_context": corpus[4]}, {"question": "how does the head chef start cooking?", "gold_context": corpus[1]}, ] summary, report = evaluator.evaluate(test_set) for row in report: print(row) print("summary:", summary) avg_delta = sum(r["oracle_delta"] for r in report) / len(report) if avg_delta > 0.15: print("bottleneck: retrieval is the main bottleneck") else: print("bottleneck: generation side should be checked next") if __name__ == "__main__": main()
scored.sort(key=lambda x: x[0], reverse=True)按关键词重叠度对知识库段落排序,取前 topk 段,模拟检索器的打分与排序。answer = self.generate(question, retrieved_docs)把检索结果传给生成器,模拟 RAG 全链路产出答案。hit = sum(1 for w in key_tokens if w in context_text)判断论断中的关键词是否被上下文“兜住”,是忠实性计算的核心。return len(q_tokens & a_tokens) / len(q_tokens | a_tokens)用杰卡德相似度近似答案相关性(正式 RAGAS 用向量余弦相似度)。useful = sum(1 for s in sentences if q_tokens & set(self.tokenize(s)))统计上下文里和问题相关的句子占比,即上下文相关性。oracle_faith = self.faithfulness(answer, [gold])用黄金上下文替换检索结果再算忠实性,为瓶颈定位做准备。delta = oracle_faith - metric_map["faithfulness"][-1]差值大说明检索漏掉了关键证据,检索是瓶颈。summary["e2e_score"] = round(按 0.4/0.3/0.3 的权重组合出端到端综合分,正好对应正文的指标组合策略。if avg_delta > 0.15:阈值判断,输出瓶颈归因结论,模拟线上评测的决策动作。
常见误区
误区“我们的 Recall@k 都 0.9 了,RAG 系统肯定没问题,不用做端到端评测。” 初学者常用组件指标替代整体判断。
正解检索准只是“采购对了食材”,不等于“菜好吃”。生成环节可能误解上下文、答非所问,检索指标根本发现不了。端到端评测把检索与生成串起来,才能看到用户真正拿到的答案质量。
为何常见:组件指标容易获得且数字漂亮,加上检索和生成常由不同团队负责,大家习惯分开考核,忽略了链路耦合。
误区“端到端综合分 0.85,系统可以放心上线了。”
正解平均分会掩盖严重缺陷——可能忠实性只有 0.5(大量幻觉),只是被其他维度拉高了。正确做法是同时看单指标分布、分场景得分和红黄绿灯阈值,先补最差短板再决定是否上线。
为何常见:综合分便于汇报,但人的直觉倾向用一个数字下结论,忽略了分布信息。
误区“我拿 20 条问答跑一遍 RAGAS 就评估完了。”
正解样本太少、场景单一,分数会剧烈波动,无法反映真实业务。评测集需要覆盖事实型、推理型、对比型等场景,并按线上流量分布加权,还要有人工校验的金标准上下文。
为何常见:构造评测集要花人力,很多团队图省事,用少量历史对话或公开数据集糊弄,忽视了代表性。
误区“RAGAS 分数 0.9,用户肯定满意,不用做人工评价了。”
正解自动指标与人类偏好只有一定相关性,风格、安全、实用性等主观维度很难覆盖;参考答案质量差还会让分数失真。需要定期做自动分与人工分的相关性校验(如 Spearman 系数),并按业务自定义指标。
为何常见:自动评估省时省力,大家期望它完全替代人工;但指标本质是代理变量,永远需要校准。
面试题
Q1. 关于 RAG 端到端评测与组件评测的区别,下列说法正确的是?
- A.组件评测比端到端评测更全面
- B.端到端评测只测生成模型
- C.端到端评测不需要任何测试样本
- D.端到端评测覆盖检索生成全链路← 正确答案
答案:D。端到端评测把检索与生成串成一条链,在“用户提问 → 最终答案”的整体上打分,对应菜上桌后的完整体验;组件评测只是单独看食材或刀工,无法代表整体。
Q2. RAGAS 的忠实性(faithfulness)衡量的是什么?
- A.答案论断能否被检索上下文支持← 正确答案
- B.上下文是否包含全部知识库文档
- C.答案是否完全复述了用户问题
- D.生成模型回答用户问题的速度
答案:A。忠实性把答案拆成论断,统计能被上下文支持的比例,防的是“乱加添加剂”的幻觉。选 B 是把上下文相关性记混了,C、D 与忠实性无关。
Q3. RAGAS 的答案相关性(answer relevance)主要通过什么方式度量?
- A.计算检索上下文的相关句子占比
- B.统计生成答案的具体长度
- C.比较问题与答案的关键词数
- D.反向生成问题再算余弦相似度← 正确答案
答案:D。RAGAS 让模型把答案倒着翻译成若干问题,再与原问题做向量余弦相似度,回答“是不是客人点的那道菜”。A 是上下文相关性,B、C 是朴素近似。
Q4. 构造 RAG 端到端评测数据集时,更合理的做法是?
- A.使用未经清洗的用户历史问题
- B.直接复用公开通用评测数据集
- C.覆盖多种场景并按业务流量加权← 正确答案
- D.只用少量真实样本完成回归
答案:C。评测集相当于品鉴师的“菜单”,要覆盖事实型、推理型等场景,并按线上流量分布加权,才有代表性。A、D 缺乏代表性,B 的场景与业务不一致。
Q5. 端到端分数偏低时,定位瓶颈的首选方法是?
- A.替换黄金上下文对比端到端分数← 正确答案
- B.增加测试集样本总量即可定位
- C.直接更换参数量更大的模型
- D.删除出现低分指标以避免暴露
答案:A。黄金上下文替换是“对照实验”:替换后分数大涨说明检索是瓶颈,几乎不变则生成是瓶颈。B、C 是随机尝试,D 是自欺欺人。
Q6. 保持生成器不变,把检索结果换成黄金上下文后忠实性大幅提升,说明?
- A.知识库内容太多导致检索缓慢
- B.生成模型是当前的主要瓶颈所在
- C.检索召回质量是当前的主要瓶颈← 正确答案
- D.评测指标失效需要重新做设计
答案:C。换更好的“食材”后“菜”明显变好,说明问题出在采购环节。若换成黄金上下文分数几乎不变,才说明生成环节拖后腿。B 与题意相反。
Q7. 关于 RAGAS 自动评测指标的局限性,正确的是?
- A.指标依赖参考答案且难以覆盖主观维度← 正确答案
- B.长文本与多跳问题的评测没有挑战性
- C.自动评测指标与人类偏好完全一致
- D.指标对所有业务场景都无需重新校准
答案:A。自动指标是“代理变量”,参考答案质量差会失真,风格、安全等主观维度难覆盖,需要定期做人机相关性校验。B、C、D 都高估了指标的能力。
Q8. 下列哪些是 RAGAS 端到端评测的核心指标?
- A.机器CPU平均使用率指标
- B.忠实性指标← 正确答案
- C.答案相关性指标← 正确答案
- D.上下文相关性指标← 正确答案
答案:BCD。三大核心指标对应品鉴师的三问:防添加剂(忠实性)、点对菜(答案相关性)、去凑数菜叶(上下文相关性)。CPU 使用率是系统性能指标,不属于质量评测。
Q9. 构建 RAG 评测数据集时需要考虑哪些方面?
- A.覆盖事实推理对比多类场景← 正确答案
- B.测试集越大越好且不需多样性
- C.按业务实际流量分布加权← 正确答案
- D.人工标注金标准上下文← 正确答案
答案:ACD。场景覆盖、流量加权、黄金标注是评测集三大要素。B 是常见误区——光靠数量堆不出代表性,样本分布比总量更重要。
Q10. 面向未来模型能力演进,评测系统应如何设计?
- A.固定一组指标永不调整
- B.建立持续回归评测流水线← 正确答案
- C.支持自定义指标扩展评测← 正确答案
- D.解耦参考答案的过度依赖← 正确答案
答案:BCD。RAGAS 支持用提示词自定义指标,配合持续回归流水线,才能适应模型升级与知识库更新;同时要降低对参考答案的依赖。A 是僵化设计,会让评测很快失效。