很多 RAG 项目演示时很好看，上线后却被用户质疑：“这句话从哪来的？”“为什么没找到明明存在的制度？”“它是不是编了一个答案？”问题不一定出在模型，可能出在文档、切分、召回、重排、提示词或引用展示。RAG 要进入生产，必须有评估和防幻觉机制。
适用人群
适合已经做了知识库问答原型的开发者、企业 IT、客服知识库负责人和合规团队。如果你还没搭 RAG，可以先看基础搭建教程；如果你准备让团队真实使用，评估这一步不能省。
评估目标
RAG 质量可以拆成四个问题：有没有找到正确资料，资料是否排在前面，模型是否基于资料回答，答案是否正确引用。对应指标是召回率、重排质量、忠实度和引用准确率。只看用户觉得“回答不错”是不够的，因为流畅错误最危险。
第一步：建立测试集
测试集要来自真实问题，而不是编辑部自己想象。可以收集客服记录、员工搜索词、历史工单、产品 FAQ。每个问题最好配标准答案、正确来源、可接受变体和拒答条件。
例如问题“异地差旅住宿标准是多少？”标准答案应标注来自哪份制度、哪一条、适用城市等级。如果制度里没有某城市，就应标注“需要人工确认”，而不是让模型猜。
测试集不用一开始很大，50 到 100 个高频问题就能暴露大量问题。上线后每周把失败案例加入测试集，形成回归评估。
第二步：评估召回
先不看模型回答，只看检索结果。对于每个问题，检查前 5 或前 10 个片段里是否包含正确来源。如果没有，问题在文档处理或检索策略；如果有但排得很后，问题在重排；如果正确片段有但模型没用，问题在提示词或生成阶段。
召回评估可以半自动：用标准来源 ID 对比检索结果，也可以人工抽检。企业场景中，召回失败通常来自切分不合理、标题丢失、同义词缺失、权限过滤过严或文档过期。
测试集 JSON 示例
[
{
"question": "异地差旅住宿标准是多少？",
"expectedSourceId": "policy-travel-2026",
"expectedAnswerKeywords": ["城市等级", "住宿标准", "报销上限"],
"shouldRefuse": false
},
{
"question": "下个月住宿标准会不会调整？",
"expectedSourceId": null,
"expectedAnswerKeywords": [],
"shouldRefuse": true
}
]简单评估脚本思路
for (const item of testset) {
const chunks = await retrieve(item.question);
const hit = chunks.some((chunk) => chunk.sourceId === item.expectedSourceId);
console.log({
question: item.question,
retrievalHit: item.shouldRefuse ? "skip" : hit,
topSources: chunks.slice(0, 5).map((c) => c.sourceId),
});
}界面验收图要包含评估表格、失败案例详情、引用高亮对比图。RAG 评估教程如果没有失败案例截图，读者很难学会怎么定位问题。
第三步：检查答案忠实度
忠实度指答案是否只说资料里支持的内容。提示词要明确：资料不足时回答不知道，不能使用常识补全。生成后可以再用一个评估模型检查“答案中的每个关键句是否被引用片段支持”。对于高风险场景，仍建议人工抽检。
常见问题是模型把两个相邻条款拼成新规则，或者把旧版本制度和新版本制度混在一起。解决办法包括版本过滤、来源优先级、日期提示和引用约束。
第四步：设计拒答机制
好的 RAG 系统必须会说“不知道”。拒答不是失败，而是保护用户。可以设置规则：召回分数低于阈值时拒答；引用来源少于 1 个时拒答；问题涉及权限外内容时拒答；问题要求预测、建议或承诺而资料没有支持时拒答。
拒答文案不要冷冰冰。可以回答：“当前知识库没有找到足够依据，建议查看某某文档或联系某某部门。”这样用户知道下一步该做什么。
第五步：用户反馈闭环
每个答案旁边都应有“有帮助 / 不准确 / 来源不对 / 文档过期”等反馈入口。反馈要进入后台，按问题类型分类。很多时候不是模型错，而是知识库缺文档、文档标题不清楚、制度过期没人维护。RAG 系统会反过来暴露组织知识管理的问题。
监控指标
上线后建议持续看六个指标：问题量、命中率、拒答率、用户追问率、负反馈率、人工转接率。问题量说明是否有人用；命中率说明知识库覆盖度；拒答率过低可能代表系统太敢答，过高可能代表召回太差；追问率高说明答案不够清楚；负反馈率高说明可信度不足；人工转接率能帮助判断哪些问题应该补文档或接工具。
还要定期抽样看引用。很多系统上线初期引用准确，迭代几轮后因为切分、重排或提示词变化，引用开始漂移。每周抽检 20 到 50 条高频问答，成本不高，却能提前发现质量下滑。
责任边界
RAG 系统应在界面上说明答案来源和适用范围。内部制度问答可以说“基于当前知识库资料生成”；客服问答可以说“以下为系统根据公开政策整理，复杂情况将转人工”。不要让用户误以为 AI 答案天然等同最终裁决。责任边界说清楚，反而更容易获得信任。
对内部团队，还要明确谁有最终解释权。比如人事制度以 HR 发布文档为准，产品参数以产品手册为准，客服政策以运营公告为准。RAG 可以提高查找效率，但不能替代制度发布流程。这个边界越早写清楚，后面争议越少。
如果答案会被用于对外沟通，建议在后台保留一次完整证据包：用户问题、召回片段、模型回答、引用来源和最终发送版本。出现争议时，团队能回溯当时系统为什么这样答，也能判断问题来自知识库、检索还是人工审核。
常见坑
| 现象 | 应该定位到哪层 | 修法 | |------|----------------|------| | 正确文档没进前 5 | 召回层 | 调整切分、混合检索、同义词扩展 | | 正确文档进了前 5 但答案错 | 生成层 | 提示词要求逐句引用，禁止资料外补充 | | 引用了整份文档但找不到段落 | 引用层 | 引用保存到 chunk ID 和段落位置 | | 模型不该答却答了 | 拒答层 | 低召回分数、无引用、权限外问题必须拒答 | | 线上越用越差 | 运营层 | 每周把负反馈加入测试集，做回归评估 |
失败案例记录模板：
{
"question": "异地差旅住宿标准是多少？",
"expected": "引用 travel-policy-2026 第 4 条",
"actual": "引用了 2024 旧制度",
"failedLayer": "retrieval",
"fix": "归档旧制度，并在检索过滤 updatedAt"
}替代方案
如果场景风险高，例如法律、医疗、金融合规，可以把 RAG 定位为“检索和草稿助手”，最终答案由专家确认。如果问题答案高度结构化，可以直接做规则引擎或数据库查询，不必让模型生成。对于公开文档问答，也可以用搜索增强的 AI 搜索产品先验证需求。
小结
RAG 防幻觉的核心不是一句提示词，而是一整套质量系统：真实测试集、召回评估、忠实度检查、引用约束、拒答机制和用户反馈。只有答案能被来源支撑，企业用户才会放心把知识库交给 AI。