给 RAG 检索调参前，我会先建一组可回归问题集

最近在给一个知识库问答工具调检索质量时，我又遇到一个熟悉的问题：开发环境里问三四个问题都能答上来，换到真实用户问题后，答案开始忽高忽低。看日志会发现，问题有时出在切片，有时出在 topK，有时出在 rerank，有时只是 prompt 把证据解释过头了。如果每次都靠人工临时提问，调参很快会变成凭感觉试错。

原创示意图：从问题集、期望证据、检索器、评测指标到回归报告的 RAG 质量评测流水线。来源：Codex image generation

问题背景

LangSmith 的评测文档把 offline evaluation 放在开发阶段，用 curated dataset 比较版本、做 benchmark 和捕捉回归。这个说法很贴近我的场景。RAG 的每次改动都可能影响检索顺序和答案表达，只有把问题、期望证据和评测方式固定下来，才知道这次优化有没有伤到旧能力。

LlamaIndex 的评测文档也把生成质量和检索质量拆开看：Response Evaluation 关注答案是否匹配上下文、问题和参考答案，Retrieval Evaluation 关注取回来源是否与问题相关。这个拆分提醒我，RAG 质量排查要先定位是哪一层在变差。

关键难点

第一个难点是问题样本太随机。产品、客服和研发各自记得几条典型问题，但没有统一字段，后面换索引策略时很难复跑。第二个难点是证据没有身份。只写一段参考答案，无法判断检索器有没有拿到正确 chunk，也无法区分答对是靠证据命中还是模型猜中了。

第三个难点是指标容易被压成一个总分。Ragas 的指标列表里有 Context Precision、Context Recall、Faithfulness、Response Relevancy 等 RAG 指标，其中 Context Precision 专门评估检索器能否把相关 chunk 排到更靠前的位置。TruLens 的 RAG Triad 也把评测拆成 context relevance、groundedness 和 answer relevance。对工程排查来说，这些信号分开看比一个平均分更有价值。

解决思路

我后来先建了一张很小的 golden set 表，字段包括 question、intent、must_chunk_ids、nice_to_have_chunk_ids、answer_points、forbidden_claims、difficulty 和 tags。must_chunk_ids 来自当前已入库文档的稳定 ID，格式里带文档版本、标题 slug、段落序号和 hash 摘要。这样一来，检索评测可以先看命中，再看排序，最后再看回答。

每次调参都保存一份实验快照：语料版本、切片大小、overlap、embedding 模型、topK、过滤条件、reranker、prompt hash 和生成模型。评测脚本只接收快照 ID，不直接读当前配置。这样昨天的实验结果不会被今天的配置覆盖，回归报告也能解释差异来自哪一层。

关键步骤

第一步是从真实问题里挑样本。我会先选覆盖面够宽的问题，包含术语精确问法、模糊问法、跨文档问法、权限边界问题和容易幻觉的问题。每条问题都人工标出必须命中的 chunk，并写出答案要点和禁止扩展的说法。

第二步是把检索评测放在生成之前。先运行 retriever，只记录取回的 chunk ID、rank、score 和过滤条件。这里可以计算 hit rate、MRR、Context Precision 或基于 ID 的 precision。只有检索通过基本阈值后，才进入答案生成和 groundedness 检查。

第三步是输出对比报告。报告里不只写分数，还要列出退步样本、丢失的 must chunk、新增的噪声 chunk、答案缺失点和不该出现的声明。对于小型团队，我更愿意让报告先保持朴素，Markdown 表格加 JSON 明细就够用，后面再接 LangSmith、Ragas 或 TruLens 这类工具。