RAGAS是什么与选型
上一篇收束了自建指标的全部四组——意图、检索、性能、行为，覆盖了路由对不对、文档找到没、用户等多久、系统行为合不合理。这四组指标有一个共同特点：全是集合运算或数值运算，跑一遍不到 1 秒，可以挂 CI 每次提交都跑。
但它们也有一个共同的盲区——评不了内容。
假设某条 query 的自建指标全绿：Hit@5 = 1.0，Recall@5 = 1.0，intent_top1 正确，TTFT 也在阈值内。打开实际回答一看：模型在 chunk 信息的基础上多编了一段话。chunk 里只写了保修 1 年，模型回答保修 1 年且 AppleCare+ 可延保至 3 年——后半句是编的。自建指标对这种幻觉完全无感。检索确实命中了正确文档，意图确实分对了，响应确实够快——但答案是错的。
这就是需要 RAGAS 的理由。
自建指标的盲区：评不了内容
1. 三种自建指标看不出的问题
用比特严选的场景举三个例子：
幻觉（编造细节）
用户问“AirPods Pro 2 的保修期是多久”，检索到的 chunk 里只写了“标准保修期 1 年”。模型回答：“AirPods Pro 2 标准保修 1 年。如果购买了 AppleCare+ 服务，可延保至 3 年，并享受意外损坏维修服务。”——后面两句是模型从预训练知识里补的，不在 chunk 里。
自建指标：Hit@5 = 1.0，chunk 命中了。看不出答案里有编造。
跑题（答非所问）
用户问“退货怎么寄回去”，检索到的 chunk 确实是退货退款政策文档。模型回答：“退款通常在 35 个工作日到账，如果使用信用卡支付可能需要 710 天。”——回答了退款时间，但用户问的是退货流程（怎么寄回去、走什么渠道）。
自建指标：Hit@5 = 1.0，文档是对的。intent_top1 也对，确实是售后意图。但答案跑偏了。
遗漏（关键信息缺失）
用户问“哪些情况不能退货”，chunk 里列了三个条件：已拆封的耳机、超过 7 天、无购买凭证。模型只回答了前两个，漏了第三个。
自建指标：Recall@5 = 1.0，所有相关文档都召回了。但答案不完整。
三种情况的共同点：自建指标全绿，答案有问题。需要一个能读懂文本、判断内容质量的工具。
2. 需要一个能读懂文本的评估工具
要检测幻觉、跑题、遗漏，本质上需要做语义级的判断——这段话能不能从上下文推出来？回答切不切题？标准答案里的信息有没有被覆盖？
用正则匹配太脆弱（同义词换个说法就失效），人工逐条审太慢（150 条 × 每次迭代都看一遍不现实）。可行的方案是：用另一个大模型来当裁判，系统化地拆解答案、逐个判断。
这就是 LLM-as-judge 的思路，也是 RAGAS 的核心。
RAGAS：用 LLM 当裁判的评估框架
1. 一句话定义
RAGAS（Retrieval Augmented Generation Assessment）是一个开源的 RAG 评估框架，GitHub 仓库 vibrantlabsai/ragas。它不是简单让 judge 模型给出好、中、差的整体评分，而是把 RAG 的不同环节拆成更细粒度的判断：有的指标会把回答拆成原子级声明（atomic claims）或陈述（statements），逐条判断是否被上下文或标准答案支持；有的指标会反向生成问题，再计算与原问题的语义相似度；有的指标会逐个判断 retrieved contexts 是否和 reference 相关。
比如评忠实度：先把回答拆成几个独立的事实声明，再让 judge 逐一判断每个声明能否从检索到的上下文推导出来。判完之后算比例——10 个 claim 里 8 个有据可查，忠实度 = 0.8。比整体打分更可靠、更可解释、也更容易定位问题出在哪。
2. 为什么不能全跑：成本账
RAGAS 0.4.3 提供了不少可选指标和变体，覆盖 RAG、文本对比、Agent / Tool、SQL、Rubric 等场景。全跑？先算一笔账。
RAGAS 里的 LLM-based 指标通常不是一次模型调用就结束。它可能会做 claim 拆解、逐条判断、反向生成问题、计算 embedding 相似度、逐个 context 判相关性等步骤。不同指标、不同样本长度、不同 strictness、不同 contexts 数量，都会影响调用量和成本。
粗算本项目的开销：
| 维度 | 数值 |
|---|---|
| 选定指标数 | 5 个 |
| 每条样本 × 5 指标的 judge / embedding 步骤 | 约十几次量级 |
| 评估集规模 | 20 条 |
| 单轮评测总步骤 | 约 200+ 次量级 |
压制方差跑 3 轮（--ragas-n 3） | 约 600+ 次量级 |
| 时间 | 十几分钟~半小时，取决于并发、限流和上下文长度 |
| 费用 | 取决于 judge 模型、embedding 模型、输入输出 token 和重试次数 |
5 个指标已经是一个不小的离线评测任务。如果跑 10 个指标，成本和耗时大概率翻倍，评测报告也会变得更难读。更要命的是：指标越多，信号越分散。10 个指标里有 3 个低了，你不知道该先优化哪个——选型的核心不是越多越好，而是每个指标都能指向一个明确的优化动作。
选 5 个的判断标准
三个硬约束：
跑得起——20 条 × 3 轮的成本可控，开发阶段改一版 prompt 能当天看到结果，不需要长时间高费用验证。
看得懂——每个指标的含义一句话能解释清楚。拿给不做评测的同事看报告，不需要翻长篇大论才能理解这个 0.7 大概意味着什么。
能驱动迭代——指标低了能定位到具体的优化方向。忠实度低 → 可能是模型编造或上下文不足；上下文召回低 → 可能是检索策略、chunk 切分或知识库覆盖有问题；答案相关性低 → 回答跑题了，继续查意图、query rewrite 或 prompt 聚焦。每个指标对应一组优先排查方向，而不是笼统地说“需要改进”。
一句话概括选型哲学：不追求全覆盖，追求每个指标都能指向一个明确的优化动作。