【第 4 篇：RAG 知识库问答——检索只是第一步】-平芜编程栈

第 4 篇：RAG 知识库问答——检索只是第一步

系列记录：《从零搭建企业级 LLM 应用》，这是第 4 篇
上一篇：Dify——低代码开发平台，快速搭建一个智能体
下一篇：记忆系统——长短期记忆与混合记忆

知识库调通了，但答不对

第 3 篇里我把 Dify 知识库接好了，搜文档这个动作已经能跑通。接下来就是 RAG 最核心的部分——拿到检索结果，让 LLM 生成回答。

一开始的想法很简单：用户提问 → Dify 检索文档 → 把检索结果拼到 prompt 里 → 让 LLM 回答。大概就是：

用户："公司的年假政策是什么？" → Dify 检索：返回文档片段 → 拼 prompt："根据以下资料回答：{文档内容} 问题：年假政策？" → LLM 生成答案

跑了几轮就发现不对劲了。有几个问题反复出现：

检索结果质量差，LLM 基于不相关内容硬编了一个答案
同一个问题换种问法，检索结果完全不一样
LLM 偶尔编造文档里根本没有的数据

第一步：查询改写——不同问法，搜出来的应该一样 ——《扩写问题》

同一个意图，用户可能有三种表达：

"年假怎么休？" "我想请年假，HR 流程是什么？" "关于带薪年假的规定"

直接用原话去搜，语义匹配效果参差不齐。尤其短的问法，向量包含的信息很少。

所以我加了查询改写这一环：在送入检索之前，先让 LLM 把用户的口语化问题转换成更适合语义搜索的表达，同时输出关键词和子问题：

输入："年假怎么休？" 输出：{ "rewritten_query": "企业员工带薪年假的申请流程和使用规定", "keywords": ["年假", "带薪休假", "申请流程"], "sub_questions": ["年假天数如何计算", "年假申请流程是什么"] }

两个保护措施：

短问题跳过改写。10 字以内的问题改写后容易偏离原意，直接搜原文更靠谱。
改写失败回退。改写后的 query 搜不到结果时，自动用原始问题再搜一次。有时候 LLM 改写的措辞跟文档原文差距太大，反而匹配不上。

第二步：答案验证——给回答装一个"质检员" ——《自检回答》

检索质量提升后，还是会碰到 LLM 基于不够相关的文档片段硬编答案的情况。

我的解法：在生成答案之后，再加一步验证。用另一个 LLM 调用判断答案是否靠谱：

GOOD：有明确的文档依据，内容具体 → 通过
HALLUCINATION：出现了文档没提到的内容，或编造了数据 → 需要重来
NO_CONTEXT：文档里确实没有相关信息，答案已说明 → 直接告知用户
INSUFFICIENT：文档与问题关联度不够 → 换表达重试

验证 prompt 的设计原则：

不要太严格。只要文档与问题有相关性就判 GOOD，不因"不够全面"打回——那是生成质量的问题，不是幻觉。
异常默认通过。验证 LLM 调用失败（网络超时等），不阻断正常流程。
HALLUCINATION 和 INSUFFICIENT 处理不同。幻觉需要换表达重搜，上下文不足则尝试更宽泛检索。

第三步：重试循环——一次不行换种方式再试 ——《自检未通过时，重试：换种表达问题的方式重新检索回答》

验证不通过时，给一次重试机会。策略是换一种表达方式重新检索。

重试上限设为 1 次，原因：

幻觉重试有意义：第一次是看到了似是而非的内容然后编造答案，换表达可能命中更精准的文档。
不相关重试意义不大：第一次检索结果就跟问题无关，换表达大概率还是不行。重试后仍不行就返回部分答案加"可能不够完整"的提示，不无限循环。
之前踩过坑：Data Agent 开发时没限制重试次数，Agent 反复执行耗时暴涨。同一类问题不能犯两次。

第四步：规则引擎兜底

答案生成和验证之后，最后过一道规则引擎——防止"技术错误信息暴露"，比如答案里不小心包含了 API 异常信息、代码报错。检测到就用兜底回复替换。

这个检查与业务逻辑解耦，规则写在 YAML 配置文件里，不改代码就能调整。

整条链路的全貌

用户提问 │ ├─ 查询改写（长问题结构化，短问题跳过） │ ├─ 首次检索（用改写 query 搜 Dify） │ └─ 无结果 → 回退检索（用原始 query） │ ├─ LLM 生成答案（基于检索上下文） │ ├─ 答案验证 │ ├─ GOOD → 继续 │ ├─ HALLUCINATION / INSUFFICIENT → 换表达重搜（最多 1 次） │ └─ NO_CONTEXT → 直接返回 │ └─ 规则引擎后校验 → 返回最终答案