RAG 为什么会答得像对，却没有依据

RAG 最容易制造一种错觉：回答读起来很自然，里面还有专业名词，于是大家默认它是对的。

实际上，“答得像对”只说明模型很擅长组织语言，不说明它真的找到了依据。可靠性要拆开看：资料是否存在、检索是否命中、引用是否对应、模型是否越过了证据边界。把这些混成一个“最终答案”，出了问题就只会得到一句模糊的结论：模型不准。

先分清四种失败

同样是一句错误回答，根因可能完全不同：

所以我不会用“用户觉得回答好不好”作为唯一指标。它可以作为体验反馈，却不能替代检索和引用的验证。

回答前，先看证据够不够

SmartKB 的 Advanced RAG 会先做查询改写、混合召回、元数据过滤和重排，再判断检索置信度。候选片段为空，或者置信度低于阈值时，它不会继续让模型生成一段看似完整的文本，而是直接返回可解释的拒答。

当前知识库中的证据不足，无法可靠回答该问题。
请补充相关文档或换一个更具体的问题。

这不是体验降级，而是产品能力边界的一部分。对于企业知识库，“不知道”比无依据地给出一个答案更有价值。

拒答结果也应该包含系统已经知道的事实：改写后的查询、召回数量、置信度、拒答原因和可展示的相关来源。这样用户能调整问题，开发者也能定位应该补资料还是改检索。

引用必须是独立数据，不是回答末尾的装饰

如果引用只作为一段 Markdown 拼在回答最后，前端难以展示，后端无法校验，评测也没法统计。更稳妥的形式是把引用当作业务字段：

{
  "answer": "售后时限超过后不能申请退款。",
  "references": [
    {
      "documentId": "refund-policy-v3",
      "chunkId": "chunk-17",
      "title": "退款与售后规则",
      "score": 0.91
    }
  ],
  "confidence": 0.82,
  "refused": false
}

回答文本给用户读，references 给用户核对，也给系统做约束。一个实际的检查是：答案中的关键结论，是否至少能回指到一个本轮真实返回的 chunkId。不能回指，就不应该被当作已证实的结论。

prompt 的作用是限制生成，不是弥补坏检索

在有引用的问答里，我会把生成规则写得非常直接：

只根据下面的文档片段回答。
不要用片段之外的通用知识补充。
文档没有提到时，明确说明没有找到相关信息。

这条规则解决的是生成层越界，它不能让错误的召回变正确。即使 prompt 写得再严，给模型的片段本身不相关，最终也只能得到一段谨慎但无用的回答。

因此验证顺序应该反过来：先单独评估检索和引用，再看最终答案。SmartKB 的评测入口就可以只执行改写、召回、过滤和重排，不调用 ChatModel。这样召回质量的波动不会被模型文案掩盖。

要留下什么 trace

一次回答出现争议时，最怕当时的证据已经丢了。SmartKB 的检索 trace 会关联助手消息，并记录查询、候选片段、检索模式和耗时。它让“这条回答为什么这样答”不再只能靠日志猜测。

我会至少保留：

assistant_message_id
original_query / rewritten_query
metadata_filter
candidate chunk ids and scores
selected references
retrieval mode and latency
confidence / refusal reason

这里要注意权限和数据最小化。trace 不等于无条件保存全文；候选片段、用户问题和过滤条件都可能含敏感信息，需要遵循租户隔离、脱敏和保留期规则。

一个更靠谱的验收方式

给 RAG 加一个新模型或重排器时，我不会只问“答案更自然了吗”。我会拿固定问题集做四个检查：

1. 正确资料是否在候选集合中。
2. 正确片段是否进入最终引用。
3. 无资料的问题是否稳定拒答。
4. 最终答案是否没有超出引用片段。

前两项是检索问题，后两项才涉及生成和产品表达。它们分开以后，调优才有方向：资料缺失就补资料，召回不足就调检索，引用不稳就校验映射，模型越界才收紧 prompt 或输出合同。

RAG 的价值不在于它能写出多像人的答案，而在于它能把答案和依据一起交付。用户能点开来源，系统能拒绝证据不足，开发者能复现一次检索过程，这才是知识库问答可以进入业务的前提。

Brief

A fluent RAG answer is not proof that retrieval found the right evidence.

Citations, confidence thresholds and explicit refusal make an answer inspectable instead of merely plausible.