📑 本页目录（点开跳转）

08c · 查询侧处理，和 RAG 怎么评估

⏱ 24 分钟 ｜ ⭐ 最容易被跳过，也最致命的一环

🎯 一句话

前两页把检索做对了，但你还缺一样东西：判断「这次改动到底有没有变好」的能力。这一页先讲查询侧还能做什么（HyDE、查询改写），再讲评估 —— ⚠️ 不做评估的 RAG，所有优化都是凭感觉。

🔄 环节四：查询侧处理

技巧	做什么	解决
查询改写	把口语化问题改成检索友好的	「上次说的那个咋样了」→ 无法检索
多查询扩展	一个问题生成 3–5 个变体分别检索	单一表述漏召回
HyDE	先让模型假装回答，用假答案去检索	问题和答案的表述差异大
意图路由	判断该查文档、查数据库、还是直接答	不是所有问题都需要 RAG
多跳检索	检索→发现缺信息→再检索	需要串联多个事实的问题

💡 HyDE 的巧妙之处：问题「怎么申请报销」和文档「报销流程：第一步…」在向量空间里未必近；但模型编的假答案「报销需要先填单据…」和真文档就很近了。

📊 环节五：评估（最容易被跳过，也最致命）

必须分开评估两段，否则你不知道问题出在哪：

操作步骤

检索质量：正确答案在召回结果里吗？
指标：Recall@K、MRR、NDCG ← 推荐算法第 12 章的老朋友
生成质量：
· 忠实度 Faithfulness —— 答案是否只基于检索到的内容（防幻觉）⭐
· 答案相关性 —— 答案是否真的回答了问题
· 上下文相关性 —— 召回的内容是否真的有用

⚠️ 最常见的诊断错误：答案不对就去调提示词。 先查检索——如果正确文档根本没被召回，提示词再怎么调都没用。

📐 RAGAS 的四个指标（把上面三条补齐）

先把常见的四类评估问题分开；具体库的类名、输入和实现会随版本变化：

指标	它问的是什么	分低说明	属于哪一段
`faithfulness` 忠实度	答案里的每一句，都能在召回的上下文里找到依据吗	模型在编	生成
`answer_relevancy` 答案相关性	答案是在回答这个问题吗（不是"对不对"，是"答没答"）	答跑题了 / 车轱辘话	生成
`context_precision` 上下文精确率	召回的那几块里，有用的排在前面吗	重排缺失或没做好，正确文档排太后	检索
`context_recall` 上下文召回率	标准答案需要的信息，都被召回了吗	压根没捞到——切分不当 / 缺 BM25 / 表述差异	检索 ⭐

不要把“四指标”当固定 API。是否需要 reference 取决于所选 metric 的实现：上下文 precision 有有参考与无参考版本；上下文 recall 常需参考事实或相关文档标注。运行前锁定 Ragas 版本，检查类名和 required inputs。见官方 context precision 文档。

计算方式	最少需要明确什么	它不能保证什么
文档 ID 的 Recall@K	每题所有相关文档 ID、实际候选 ID	答案是否正确、引用是否支持结论
有参考的 context precision	问题、候选、参考答案或标注，依 metric 而定	权限、答案完整性
无参考的 context precision/utilization	问题、候选、回答等实际输入要求	参考答案未覆盖的信息是否缺失
Faithfulness	回答主张与送入模型的上下文	上下文本身是否过时、越权或错误

Recall 低先分清资料不存在、解析丢失、切分或检索漏掉；precision 低也可能是无关候选过多，不只是缺重排。小样本先校准评分器，再比较趋势。11c提供不依赖 LLM 裁判的多证据计算与消融。

⚠️ RAGAS 这四个分数多数是靠 LLM 打出来的，所以它自带 LLM-as-a-Judge 的全部毛病：分数随裁判模型版本漂移、成本按 token 计、同一批数据两次跑结果不完全一样。 把它当"趋势指标"用（这次改动比上次高了吗），别当"绝对分数"用——「我们的 faithfulness 是 0.87」这句话离开了裁判模型和版本就没有意义。

🩺 一张诊断表（照着查，5 分钟定位问题）

现象	先查这个	大概率的根因	哪个指标会先亮红灯
答案完全跑偏	召回结果里有正确文档吗？	检索问题：切分不当 / 缺 BM25 / 查询表述差异大	`context_recall`
召回里有正确文档，但答案还是错	它排第几？	重排缺失——正确文档排在第 15 位，被截断了 ⭐	`context_precision`
答案对但编了引用	提示词有没有强制"只用给定内容"	生成侧幻觉，要加约束 + 引用校验	`faithfulness`
答案太笼统	召回的块是不是太大	块里混了多个主题，模型抓不住重点	`answer_relevancy`
专有名词/型号查不到	有没有 BM25	纯向量检索的典型失败 ⭐	`context_recall`
时效性内容答错	索引多久更新一次	索引腐烂——文档更新了但没重建	`context_recall`（症状而已，根因在索引管线）
别人的数据被查出来了	有没有做行级权限过滤	🚨 合规事故（第 14 章）	⚠️ 一个都不会亮

🚨 盯住最后一行：RAGAS 四个指标一个都发现不了权限越权。 被越权召回的文档"内容相关、答案忠实、引用属实"——四项全绿，评估体系完全无感。 合规只能靠专门的权限测试用例（拿 A 用户的身份去问只有 B 能看的问题，断言召回为空），指标救不了你。 ⭐ 这条推广出去是一条通用教训：你的指标体系只会告诉你它被设计来测的东西。

🔑 最有价值的一个习惯： 每次 RAG 回答错了，都把"召回的原始块"打印出来看一眼。 记录中间结果后，才能判断错误来自检索、上下文组装还是生成；这里不假设固定比例。

🔨 一个最小可用的评估脚本

# 单相关文档的入门特例：不代替多证据 Recall 或上线验收。
def eval_retrieval(qa_pairs, retrieve, k=10):
    if not qa_pairs:
        raise ValueError("评测集不能为空")
    hits, ranks = 0, []
    for q, gold_id in qa_pairs:
        ids = [d.id for d in retrieve(q, k=k)]
        if gold_id in ids:
            hits += 1
            ranks.append(1 / (ids.index(gold_id) + 1))   # MRR
        else:
            ranks.append(0)
    print(f"Hit@{k} = {hits/len(qa_pairs):.1%}   MRR = {sum(ranks)/len(ranks):.3f}")

💡 有了这 10 行，你的每一次改动才有了意义—— 否则"我觉得加了重排好像好一点"永远只是感觉。 🔗 这条纪律来自《机器学习基础》第 5 章和 Kaggle 教程。

🔗 想再深一层，去哪一套

去哪	为什么
数据这一关 13 · 评测集也是数据	⭐ RAGAS 之外那一半：评测集该抽多大、怎么抽、会不会被污染。尺子本身也会坏
数据这一关 13 · 评测集也是数据	⭐ LLM 评委必须先和人工对齐 —— 那一章有「评分器也要校准」整整一节。⚠️ 不校准的话，你比的是「模型有多像那个裁判」而不是「答得对不对」
智能体工程教程 14 · 评测 Evals	三类评分器、评产出并检查执行约束、LLM 评委上线前必须先和人工对齐
AI全栈 08 · 认证会话与多租户	⚠️ 「权限越权四个指标一个都不亮」那一条的正题：多租户隔离出错时没有任何东西会告诉你

✅ 检查点

RAG 答案不对，第一步该查什么？最有价值的排查习惯是什么？
「召回里有正确文档但答案还是错」——该查什么？
HyDE 的原理是什么？
RAGAS 的四个指标分别问什么？context_precision 低和 context_recall 低，处方有什么不同？
为什么说 RAGAS 分数只能当“趋势指标”？
诊断表里哪一类问题是四个指标一个都不会亮的？该怎么查？

👀 答案

先查检索——正确文档有没有被召回。最有价值的习惯：每次答错都把召回的原始块打印出来看一眼，不预设生成错误的固定比例。
查候选是否真正进入模型上下文，再核对裁剪、顺序、版本、单位与答案断言；不能先断定缺重排。
先让模型假装回答生成一个“假答案”，用假答案去检索。因为假答案和真文档的表述风格更接近，比原始问题更容易匹配上。
faithfulness 答案有没有依据（模型在编）、answer_relevancy 答没答这个问题、context_precision 有用的排没排在前面、context_recall 需要的信息捞没捞到。Recall 低先查入库、过滤与召回；precision 低检查噪声、排序与上下文拼装。 重排是候选已有正确证据时的对照选项，不是固定处方。
因为这四个分数多数是 LLM 打出来的，自带 LLM-as-a-Judge 的毛病：随裁判模型版本漂移、按 token 计费、同一批数据两次跑结果不完全一样。所以「我们的 faithfulness 是 0.87」离开裁判模型和版本就没有意义，只能比“这次改动比上次高了吗”。
权限越权（别人的数据被查出来）。被越权召回的文档内容相关、答案忠实、引用属实，四项全绿。只能靠专门的权限测试用例——拿 A 用户的身份去问只有 B 能看的问题，断言召回为空。通用教训：指标体系只会告诉你它被设计来测的东西。

🛑 可以停在这里

到这里你有了一个能被度量的 RAG：改动之后能说清是好了还是坏了。这只是起点；还需权限、拒答、故障恢复和运行环境验收。

⚠️ 什么时候看下一页：评估分数卡住了，而且你确认瓶颈不在切分、不在重排、不在查询改写 —— 那才轮到进阶方案。

⚡ 走神救援

先记住这几件事

回答错误时先查看召回的原始片段，再判断问题出在检索、排序还是生成。
召回率与精确率低对应不同修法，不要只看一个总分。
自动裁判需要校准；权限隔离必须有专门的越权测试。

下一节 👉 08d-RAG进阶方向.md

打卡记录保存在你的浏览器里，首页能看到总进度