D8 评估先行：搭 golden set、算召回与排序指标、用模型当裁判判忠实度

今日目标

能从真实语料出发构造一份 golden set,并说明为什么它必须包含无答案问题和多跳问题
能实现召回率、平均倒数排名与归一化折损累计增益三个指标，并说清各自敏感于什么
能设计一个模型裁判的提示词并用人工抽检验证它靠不靠谱，而不是无条件信任它的分数

第一周你把系统跑起来了，但一直没法回答一个问题：它到底好不好？今天就是来装这把秤的。读完回到页面顶部把三条目标勾掉。

小白版讲解

没有秤就别谈减肥

一个人下决心减肥，第一个月改吃沙拉，第二个月开始跑步，第三个月又戒了夜宵。三个月后他瘦了吗？他自己也说不清——因为家里根本没有秤。他只能凭"裤子好像松了一点"来判断，而这种判断在心情好的日子里格外准确。

第一周结束时，你的检索问答系统就处在这个状态。D4 你换了切法，D5 你调了索引参数，D7 你把两路检索融合到一起，每一步你都觉得"应该更好了"。但如果我现在问你：把向量那一路的权重从 0.6 调到 0.8，会更好还是更差？你只能猜。

秤的价值不在于告诉你现在多少斤，而在于让"这个改动有没有用"变成一个可以回答的问题。所以第二周的第一天不做任何优化——先把秤造出来。从今天起，这门课里"该不该上重排""该切多大""要不要做查询改写"这类问题，唯一合法的答案是：跑一遍评估，看数字。

一把秤要有两样东西：一组固定的被测对象，和一套读数的规则。前者叫标准答案集（golden set），后者就是指标。可惜这两样都不能直接拿来用——现成的公开评测集里全是维基百科问答，跟你的公司知识库没有半点关系；而指标看起来有一堆现成的名字，实际选错了会让你看着数字往上走、用户体验往下掉。

最后说一件最容易被跳过的事：造秤是有成本的。20 道题标好答案文档，我在实验里花了两小时。很多团队跳过它，理由是"先做起来再说"，结果三个月后系统改了二十版，没有一版说得清自己强在哪——那不是省了两小时，是把三个月的工作变成了不可验证的。

golden set 怎么造：从语料反向出题

标准答案集的构造方向，跟大多数人的直觉是反的。直觉是"先想用户会问什么，再去看语料里有没有"，正确做法是反过来：打开语料，从每一篇里读出它能回答什么问题。

理由很简单：前一种做法你会写出一堆自己都不知道答案的问题，标注时无从下手；后一种做法，答案文档在你出题的那一刻就已经确定了。实验里的 20 道题就是这么出来的，每一道的 answerDocIds 都是我出题时正在读的那一篇。

一条题目长这样：

JSONJSON

{
  "id": "q17",
  "question": "把某个工作区的链路追踪采样率临时调到 100%，属于几级变更？按规范最晚要提前几个工作日提单？",
  "answerDocIds": ["doc-022", "doc-021"],
  "type": "multi"
}

type 这个字段决定了这道题怎么算命中，一共三类，缺一类你的秤就是瞎的：

single：单篇文档就能答。答案文档列了多篇时，任意一篇进上下文就算命中。
multi：多跳（multi-hop），必须全部答案文档都进上下文才算命中。凑齐一半等于答不出来，算"命中一半"是给自己发安慰奖。
none：语料里根本没有答案。它不参与召回率，它考的是系统会不会闭嘴。

第三类是最容易被跳过、也最不能跳过的一类。原因是这样的：一个只会硬答的系统，在只有可答问题的评估集上能拿到接近满分——它每次都塞一堆材料给模型，模型每次都编一段话出来，而你的评估集根本没有"应该拒答"这一栏，于是这个致命缺陷在报表上完全不可见。无答案问题是唯一能让"乱编"这个故障显形的东西。

出无答案问题也有讲究：必须留强干扰词。实验里问"网页端支持哪些浏览器？对版本有什么最低要求"，语料里恰好有一句"提交工单时请附上浏览器与版本"；问"私有化部署需要多少 CPU 和内存"，语料里既有"私有化部署"也有"CPU、内存"，只是从来没写过硬件配置。没有干扰词的无答案题太好答了，检索器一条都捞不到，你测出来的是分词器而不是系统。

覆盖度给一个可以直接抄的配比：20 题起步，多跳不少于 3 道、无答案不少于 3 道，其余是单文档题。20 题就够把"完全不能用"和"基本能用"分开；上线系统建议做到 100–200 题，每次线上出问题就把那个问题补进去——评估集是长出来的。

检索侧三个指标，各自对什么故障敏感

检索侧我们只算三个指标。它们不是三种口味，是三层不同的故障。

召回率（recall）问的是"答案有没有进上下文"。 注意口径：这里的"进上下文"不是"排进前 5 名"，而是在 600 token 的上下文预算里被真的装进去了。按固定条数比较是不公平的——大块切法取 5 条能塞两千多 token，小块切法取 5 条只有几百，赢的那一方只是买了更多货。这个口径与 D4 完全一致，两天的数字才能放在一起看。

平均倒数排名（mean reciprocal rank）问的是"第一条相关结果排在第几"。 排第 1 得 1 分，排第 2 得 0.5，排第 10 得 0.1，一条都没有得 0，全部问题上取平均。它对"答案还在、只是被挤到后面"极其敏感——而召回率在预算被挤爆之前完全看不出这件事。

归一化折损累计增益（normalized discounted cumulative gain）问的是"前十名整体质量好不好"。 每一名的收益按名次打折，越靠后折得越狠，再除以理想排序能拿到的分数归一化到 0 到 1。它和倒数排名的区别在于：倒数排名只认第一条，"一条命中加九条垃圾"和"五条全命中"在它眼里一模一样；而这个指标会把前十名里每一条都算进去。重排（rerank）优化的正是它。

三个指标的实现全在实验的 metrics.ts 里，核心就这么长：

metrics.js

// 召回率：single 任意一篇进上下文即命中，multi 必须全部进
export function isHit(t) {
  if (t.type === 'none') return false
  if (t.type === 'multi') return t.answerDocIds.every((id) => t.contextDocIds.includes(id))
  return t.answerDocIds.some((id) => t.contextDocIds.includes(id))
}
 
// 倒数排名：第一条相关结果的名次取倒数。下标从 0 起、名次从 1 起，差一位分数就全偏高
export function reciprocalRank(t) {
  const rank = t.rankedDocIds.findIndex((id) => t.answerDocIds.includes(id))
  return rank === -1 ? 0 : 1 / (rank + 1)
}
 
// 归一化折损累计增益：前 k 名各自按 1 / log2(名次 + 1) 折算，再除以理想排序的分数
export function ndcgAt(t, k = 10) {
  const gains = t.rankedDocIds.slice(0, k).map((id) => (t.answerDocIds.includes(id) ? 1 : 0))
  const dcg = gains.reduce((sum, g, i) => sum + g / Math.log2(i + 2), 0)
  let idcg = 0
  for (let i = 0; i < Math.min(t.relevantChunkCount, k); i += 1) idcg += 1 / Math.log2(i + 2)
  return idcg === 0 ? 0 : dcg / idcg
}

metrics.py

from math import log2
 
 
def is_hit(t: dict) -> bool:
    """召回率：single 任意一篇进上下文即命中，multi 必须全部进"""
    if t["type"] == "none":
        return False
    if t["type"] == "multi":
        return all(doc_id in t["context_doc_ids"] for doc_id in t["answer_doc_ids"])
    return any(doc_id in t["context_doc_ids"] for doc_id in t["answer_doc_ids"])
 
 
def reciprocal_rank(t: dict) -> float:
    """第一条相关结果的名次取倒数。enumerate 从 1 起算，省掉一次差一位的机会"""
    for rank, doc_id in enumerate(t["ranked_doc_ids"], start=1):
        if doc_id in t["answer_doc_ids"]:
            return 1 / rank
    return 0.0
 
 
def ndcg_at(t: dict, k: int = 10) -> float:
    """前 k 名各自按 1 / log2(名次 + 1) 折算，再除以理想排序的分数"""
    gains = [1 if d in t["answer_doc_ids"] else 0 for d in t["ranked_doc_ids"][:k]]
    dcg = sum(g / log2(i + 2) for i, g in enumerate(gains))
    idcg = sum(1 / log2(i + 2) for i in range(min(t["relevant_chunk_count"], k)))
    return dcg / idcg if idcg else 0.0

无答案那一类不进这三个指标，它有自己的一项：拒答率——四道无答案题里，系统有几道真的说了"资料里没有"。实验跑出来的基线是这样的：

TextText

召回率（可答题）  87.5%
召回率（single）  100.0%
召回率（multi）   50.0%
平均倒数排名      1.0000
nDCG@10           0.6711
无答案题拒答率    0.0%

这份数字信息量很大。单文档题全中，多跳题只中一半——那道"主备切换要谁审批、他叫什么名字"，第二篇文档一次都没捞上来。而拒答率是 0%：四道无答案题一道都没闭嘴，全被塞了不相干的材料。只算召回率的话，87.5% 看着还挺不错。

生成侧两个指标：有没有编，有没有答

检索找对了，模型还可能把话说歪。生成侧看两个指标，必须成对看。

忠实度（faithfulness）：回答里的每一句陈述，材料里有没有支撑。它抓的是编造。算法是把回答拆成一句一条，逐条判定，最后取"有支撑的条数除以总条数"。

答案相关性（answer relevancy）：回答有没有答到问题上。它抓的是"说了一堆但没回答"。

为什么必须成对：一句"资料中没有找到能支撑回答的内容"忠实度满分——它一个字都没编——但相关性为零。只看忠实度，你的系统学会一直拒答就能刷满分。反过来只看相关性，一段编得头头是道、完全切题的假话也能拿高分。这两个指标是互相看着对方的。

实验的基线里有一组特别值得看的数字：忠实度 1.0000，答案相关性 0.3931。忠实度满分是因为离线模式下的"回答"是把命中块里的句子摘出来拼的，逐字来自材料，当然不会编；但相关性只有 0.39，说明摘出来的多半不是问题要的那句。忠实度高不等于回答对，这是这一节最值得记住的一句话。

逐句判定长这样：

faithfulness.js

export function faithfulness(answer, contextText) {
  const unsupported = []
  let decidable = 0
  for (const claim of claimsOf(answer)) {
    const ratio = overlapRatio(claim, contextText)
    if (ratio === null) continue // 判不了的不进分母，见下面的坑
    decidable += 1
    if (ratio < MIN_OVERLAP) unsupported.push(claim)
  }
  return { score: decidable === 0 ? 0 : 1 - unsupported.length / decidable, unsupported }
}

faithfulness.py

def faithfulness(answer: str, context_text: str) -> tuple[float, list[str]]:
    unsupported: list[str] = []
    decidable = 0
    for claim in claims_of(answer):
        ratio = overlap_ratio(claim, context_text)
        if ratio is None:  # 判不了的不进分母，见下面的坑
            continue
        decidable += 1
        if ratio < MIN_OVERLAP:
            unsupported.append(claim)
    score = 0.0 if decidable == 0 else 1 - len(unsupported) / decidable
    return score, unsupported

模型当裁判的坑

忠实度这类判断，最终得靠一个模型来做——把材料、问题、回答一起发过去，让它打分。这就是模型裁判（LLM-as-judge）。它便宜、快、能规模化，也有三个必须知道的系统性偏差。

位置偏好。 让裁判在两个回答之间二选一时，它更倾向选排在前面那个。缓解办法是不做两两比较，改成逐条独立打分；非要做比较，就把两个回答的顺序交换再跑一遍，两次结论不一致的直接判平局。

偏爱长答案。 同样的信息量，写得长的更容易拿高分。缓解办法就是上一节那个逐句判定：忠实度是"有支撑的条数除以总条数"，写得越长分母越大，多写的每一句都得自己挣支撑，长度红利自动消失。

自己评自己。 用同一个模型既生成又评判，它对自己的输出会更宽容。缓解办法是换一家或换一档：生成用 claude-sonnet-5，评判就换另一个供应商的模型；预算紧张时用 claude-haiku-4-5-20251001 当裁判也可以，但换完必须重新做一次人工抽检。

除了这三条，提示词本身还有两个要求：给死评分锚点（1.0 是什么、0.6 是什么、0.3 是什么，不给锚点它每天给的分都不一样），以及强制结构化输出，并要求把没支撑的句子原样列出来。第二条是为人工抽检准备的——只给你一个 0.83，你无从复核；把争议句子列出来，你三十秒就能判断裁判对不对。

而校准的唯一办法是人工抽检算一致率：

跑一次评估，打开报告，分层抽 10 条——各类型都要有，命中的和没命中的都要有，裁判给高分和给低分的都要有。
每条只回答一个问题：这段回答里有没有材料里没写的东西。只判忠实度，不判好不好。
把判断写进 human-labels.json，跟裁判的结论比对，算出一致率。
低于 0.8 就别再拿这个裁判的分数拦合并，先去改提示词，改完重抽一次。

把评估接进流程

评估脚本写完只是第一步，它必须变成一条命令、一个文件、一道闸门，否则三周之后没人会再跑它。

一条命令：pnpm start 跑完全套，输出 reports/latest.json 与一份人能读的 Markdown。一个文件：把认可的那一版存成 eval/baseline-report.json，它就是往后所有对比的锚点。一道闸门：

gate.js

// 盯住五项，各守一层：召回率守"找得到"，倒数排名与 nDCG 守"排得好"，
// 忠实度守"不乱说"，拒答率守"没有答案时闭嘴"。少一项就有一类退步能溜过去
export function gate(current, baseline, tolerance = 0.01) {
  const regressions = METRICS.map(({ name, pick }) => ({
    name,
    delta: Number((pick(current) - pick(baseline)).toFixed(4)),
  })).filter((r) => r.delta < -tolerance)
  return { passed: regressions.length === 0, regressions }
}

gate.py

def gate(current: dict, baseline: dict, tolerance: float = 0.01) -> tuple[bool, list[dict]]:
    """盯住五项，各守一层：找得到、排得好、不乱说、没有答案时闭嘴"""
    regressions = [
        {"name": name, "delta": round(current[key] - baseline[key], 4)}
        for name, key in METRICS
        if current[key] - baseline[key] < -tolerance
    ]
    return not regressions, regressions

在持续集成里跑它，退步就让流水线失败：

BashBash

MOCK=1 GATE=1 pnpm start   # 有指标退步就以非 0 退出码结束

容差别设大。同一份数据、同一份配置本该逐位相同，留 0.01 只是为了给换 embedding 后端留点余量；设成 0.05，一次真实的退步就能大摇大摆走过去。

最后说成本。20 题跑一轮模型裁判只要几分钱，随便跑；扩到 200 题、每天十次，账单就该有人管了。常见做法是分两档：每次提交只跑检索侧指标（纯本地计算，几秒钟、零成本），模型裁判留给合并前和每晚各一次。评估本身也要报三笔账：指标、延迟、钱。

源码导读

动手实验

🧪 D8 实验：一套可复跑的评估脚本与第一周系统的基线报告

代码位置：labs/rag-14days/day-08-eval-harness

验收标准：

MOCK=1 pnpm start 跑完，最后一段「七、验收」七项全部 ✅
报告里 single 与 multi 两档召回率不同，说明多跳用的是「全部命中」口径
归一化折损累计增益的值与召回率不相等，逐题表里能看出哪几题排序差
裁判探针里「与材料无关的编造」那条被抓出来，忠实度低于 0.7
把召回率人为调低 15 个点，回归闸门会拦住

starter/ 里挖了 5 个练习点，分别是三个检索指标、忠实度的逐句判定、以及回归闸门。原样跑有 5 项验收是 ❌，每做完一个就有一项变 ✅——这是今天的进度条。语料和 20 题标准答案集都已经准备好了，eval/golden-set.json 的前 10 题与 D4 逐字相同，一个字都不要改，改了两天的数字就不能比了。

打开 eval/golden-set.json 通读 20 道题，对着 corpus/ 抽查三道，确认答案文档确实答得上；再确认四道无答案题在语料里是真的没有答案。
在 src/metrics.ts 里实现三个检索指标，跑一次，看召回率从 0.0% 变成有意义的数字，并注意 single 与 multi 两档的差距。
在 src/judge.ts 里补上忠实度的逐句判定，跑一次，看第四段的裁判探针从 ❌ 变 ✅。
照 README 的做法分层抽 10 条改写 eval/human-labels.json，重跑，看第五段的一致率和分歧列表。
在 src/report.ts 里接上回归闸门，跑一次确认「闸门拦住了」，再用 MOCK=1 GATE=1 pnpm start 体会退步时的非 0 退出码。

面试题

今天 4 道题在下方题库区，侧重评估集构造、检索指标的选择、模型裁判的可靠性与偏差。展开后先看"分析过程"再看要点——照着推导练，比背要点管用。标注"国内高频 / 海外高频"方便按目标市场取舍。

检查清单与明日预告

能从真实语料出发构造一份 golden set,并说明为什么它必须包含无答案问题和多跳问题
能实现召回率、平均倒数排名与归一化折损累计增益三个指标，并说清各自敏感于什么
能设计一个模型裁判的提示词并用人工抽检验证它靠不靠谱，而不是无条件信任它的分数
能说清召回率、倒数排名、归一化折损累计增益三者分别在什么故障下先掉下来
能解释为什么忠实度和答案相关性必须成对看，只看一个会被怎么骗
实验的 5 条验收标准全部通过，手里有一份第一周系统的基线报告
4 道面试题不看要点也能答出至少 3 道

明天（D9）做第二周的第一项优化：混合检索与重排——两路召回用倒数排名融合合起来，再拿一个交叉编码器把前几十条重排一遍。先建评估再优化的理由是：混合检索的收益完全取决于语料和问题分布，有的场景涨十几个点，有的一个点都不涨甚至倒退。没有今天这份基线，你明天只能说"感觉好了一点"。

评估先行：搭 golden set、算召回与排序指标、用模型当裁判判忠实度