RAG 实验设计：别让优化变成玄学

用实验矩阵、固定数据集、版本化配置和对比报告管理 RAG 优化，避免凭感觉调 chunk、embedding、rerank 和 prompt。

RAG 优化最常见的坏味道是：改了三个参数，问了五个问题，感觉变好了，然后上线。这个流程无法复现，也无法解释为什么好，更无法知道哪些样本变差。

实验设计的目标是把 RAG 优化从“调参手感”变成“可比较的工程实验”。

核心原则

每次实验只改变少数变量，并留下数据集、配置、指标、失败样本和决策记录。否则你得到的只是一次临时演示，不是可复用经验。

实验对象

RAG 实验可以拆成几个层级。

层级	常见变量	主要指标
数据	解析器、清洗规则、版本过滤	空文本率、重复率、Recall@K。
Chunk	chunk size、overlap、parent-child	Recall@K、Context Precision、Citation Accuracy。
Embedding	模型、维度、归一化	Recall@K、MRR、成本。
Retrieval	BM25、向量、hybrid、RRF	Recall、NDCG、Latency。
Rerank	topN、模型、阈值	Context Precision、P95。
Prompt	引用、拒答、冲突处理	Faithfulness、Refusal Quality。

不要在同一个实验里同时换 embedding、chunk 和 prompt。结果变好时你不知道功劳是谁，变差时也不知道该回滚什么。

最小实验矩阵

每个实验至少记录：

baseline 版本。
candidate 版本。
变更变量。
数据集版本。
指标变化。
新增失败样本。
可接受风险。

数据集分层

实验数据集不能只有高频问题。

样本层	目的
Core	核心业务问题不能退化。
Long-tail	检查冷门术语、低频文档和边界表达。
Conflict	检查新旧版本、冲突证据和过期文档。
Security	检查权限、敏感信息和拒答。
Bad Case	防止历史问题回归。

报告模板

Experiment: rag-hybrid-rrf-k60
Baseline: rag-2026-07-01
Candidate: rag-2026-07-07
Changed: RRF k 20 -> 60

Retrieval:
- Recall@10: 0.82 -> 0.86
- MRR: 0.61 -> 0.64

Answer:
- Faithfulness: 0.91 -> 0.90
- Citation Accuracy: 0.84 -> 0.85

Cost:
- P95: +180ms
- Token: no change

Regressions:
- 2 medium, 0 high, 0 critical

决策规则

实验不是为了证明新方案更好，而是为了支持发布决策。

如果核心样本或权限样本回归，默认不发布。

如果整体指标变好但 bad case 增加，需要人工复核。

如果延迟或成本明显上升，需要解释收益是否值得。

如果只改善少数 demo 问题，不应作为发布理由。

结论

RAG 实验的价值不在指标本身，而在可复现的比较过程。只有当团队能稳定回答“为什么这版更好、哪里变差、如何回滚”，优化才不是玄学。

讨论

继续讨论这篇笔记

有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。