RAG做出来没人用？2026年检索增强系统评测实战教程

为什么你的RAG”看着能跑，用起来不行”

很多团队搭RAG的流程是：文档切块 → 丢进向量库 → 接到大模型 → 上线。结果用户一用就发现：答案引用了不存在的段落、检索不到该找的内容、答非所问。

问题在于：没人测过它到底行不行。RAG是个多环节系统，任何一环出错都会毁掉体验。这篇教你用工程化的方法把它测明白。

先理解RAG的两个独立环节

RAG = 检索(Retrieval) + 生成(Generation)。它们必须分开评。

• 检索环节：该找的文档找到了吗？
• 生成环节：找到的文档被正确使用了吗？

混在一起评，你根本不知道问题出在哪。

环节一：评测检索质量

核心指标：

指标	含义
Recall@k	前k条里是否含正确文档
Precision@k	前k条里有多少是相关的
MRR	正确结果排得靠不靠前
Hit Rate	有多少问题能找到答案

做法：准备50-100个真实问题，人工标注”标准答案在哪段文档”。然后测你的检索能否找到它。

最常见的失败：

• 切块太大 → 噪声多，关键信息被稀释
• 切块太小 → 语义不完整，检索不到
• 只用向量检索 → 专有名词、编号查不准，需混合关键词检索

环节二：评测生成质量

检索对了，生成仍可能错。重点测：

1. 忠实度(Faithfulness) 答案是否只基于检索到的内容？有没有编造？

2. 答案相关性(Answer Relevance) 回答是否切题，有没有答非所问？

3. 幻觉率 统计答案中”检索内容里不存在的事实”占比。

评测方法：

• 人工抽查（小规模，最准）
• 用大模型做”裁判”(LLM-as-judge)，批量打分
• 两者结合：AI 初筛，人工复核关键样本

一套可落地的评测流程

1. 建评测集：80个真实问题 + 标准答案 + 出处
2. 跑检索指标：看Recall/MRR是否达标
3. 跑生成指标：用LLM裁判给忠实度、相关性打分
4. 定位失败：把错例分类（检索错/生成错/切块错）
5. 针对性优化：改切块策略、加混合检索、改prompt
6. 回归测试：改完再跑一遍，防止优化一处、退化别处

常见问题与对策速查

症状	可能原因	对策
检索不到	切块不当/纯向量	混合检索、调切块
答非所问	prompt不清	改指令、加约束
编造内容	模型爱自由发挥	强制引用、要求”无据不答”
答案太笼统	检索粒度粗	更细切块
专有名词查不准	无语义匹配	加关键词/BM25

一条重要原则

“检索不到就老实说不知道”，比”硬编一个答案”有价值得多。 在prompt里明确要求模型：找不到依据时必须回答”文档中未提及”。这一条能大幅降低幻觉的伤害。

核心结论

RAG的质量不是”上线才知道”，而是可以在上线前系统性测出来的。把检索和生成分开评、建立评测集、持续回归测试，你的RAG才能从”能演示”变成”敢交付”。记住：RAG的敌人不是技术不够先进，而是没人认真测过它。 评测越扎实，用户越信任。