课程主线#

一句话心智模型#

RAG 回答失败，不等于模型一定不好；先分别看有没有拿到该拿的资料，以及答案有没有使用那条资料。

1
question
2
  -> retrieved titles        # 检索层
3
  -> answer text             # 生成层
4
  -> two independent checks  # 评估层

看当前项目怎样接入#

现有 RAG 搜索结果有 title，聊天结果最终是文本。把它们适配成第 37 章的函数输入：

1
result = evaluate_case(
2
    case,
3
    retrieved_document_titles=[item.title for item in search_results],
4
    answer_text=answer_text,
5
)

这段代码不负责搜索也不负责生成；它只比较：

• expected_document 是否在检索到的标题中。
• expected_fact 是否在最终文本中。

真实代码锚点#

app/evals/contracts.py 的 evaluate_case() 返回三个字段：

1
EvaluationResult(
2
    retrieval_passed=True,
3
    answer_passed=True,
4
    tool_usage_passed=True,
5
)

第 38 章只看前两个。tool_usage_passed 留给下一章 Agent。

最小验收#

1
poetry run pytest tests/test_evaluation_contracts.py

然后把测试中的固定 retrieved_document_titles 和 answer_text 替换成你从真实 RAG 调用收集到的结果。第一次不用自动跑全库：只挑 3 条你最在乎的问题，例如退款规则、权限规则和一个“知识库没有依据”的问题。

Ragas 在什么位置#

Ragas 官方文档 的主流程也是：准备 dataset -> 调用 RAG -> 评价 response -> 保存结果。它近期的 v0.4 把旧的 evaluate() 方式迁移到 experiment 工作流；不要从旧博客复制过时 API。迁移说明

本项目当前没有安装 ragas。等手写评估集已经稳定、且你确实需要 Faithfulness / Context Recall 这类软指标时，再执行：

1
poetry add --group dev ragas

三遍练习#

1. [追踪] 解释 expected_document 为什么验证检索层，expected_fact 为什么验证答案层。
2. [改] 故意把检索标题从 退款规则 改成 账户帮助，判断哪项失败。
3. [独立做] 写 3 条 RAG case：一条应命中、一条应拒答、一条用于检查相似文档是否被错误挤掉。

常见坑#

• 只测最终答案，导致不知道是检索还是生成坏了。
• 只追求平均分，掩盖一个高价值 case 的严重失败。
• 调参后不重跑同一批 case，无法证明改动是否真的改善。
• 把 Ragas 分数当作绝对真相；它也是指标和评估模型共同产生的信号。

课后压缩#

1
检索是否命中？
2
回答是否包含关键事实？
3
两项分开，才能定位问题。

下一章复用同一 case 结构，但把“是否调用了必要工具”加进检查。