答案不在知识库内，改改 RAG 提示词这样就够了吗？

今天抛出一个问题如果你的 RAG 系统检索到了垃圾文档它会不会编一个听起来像模像样的答案提示词中写了“不知道就别答”能管住吗介绍下 CRAG 这种方案。传统 RAG 有一个沉默的故障模式先说个案例。某企业把内部 HR 制度文档灌进向量库员工问年假折现怎么算。检索器找到了最相似的几段偏偏是考勤制度里关于年度考核的段落。模型拿到这堆不相关的文字既没报错也没犹豫直接编了一套折现公式出来。这就是传统 RAG 一个比较大的问题检索器拿到什么模型就吃什么。好比厨师不管食材新不新鲜照样做菜端上桌。整条链路是这样的用户查询 → Embedding → 向量检索 Top-K → 检索文档 → LLM 生成 → 回答中间没有任何质量关卡。检索结果好回答好检索结果烂回答更烂。但看起来一样自信。这篇文章要解决的问题只有一个怎么让 RAG 管道在检索结果不靠谱的时候自己知道不靠谱并且有能力纠正在 Prompt 里写一句「不知道就别答」不就行了很多人第一反应是我在系统提示词里加一句如果检索到的内容无法回答问题请直接回复不知道不就解决了这招在 demo 阶段确实管用但进了生产环境三个硬伤会慢慢露出来。硬伤一LLM 很难分清沾边但没用和完全不相关。用户问年假折现怎么算检索器返回了年度考核评分标准两段文字都有年、评这类词语义也相似向量空间里距离不远。LLM 拿到这段文字Prompt 里虽然写了不能回答就说不知道但模型的训练目标是尽量给出有帮助的回答。这两股力量在打架几百亿参数的统计惯性 vs 你写的一句指令大多数时候可能是惯性赢。模型会从那段考核文档里抽取似是而非的信息拼出一个看起来合理的答案。不是模型不听话是它被训练成了一个讨好型助手天然倾向于回答而不是拒绝。硬伤二没有中间地带。Prompt 兜底只有两个出口能答就答不能答就拒绝。但现实中最常见的情况是检索结果里有 30% 的有用信息混着 70% 的噪声。这时候直接拒绝太浪费有用的部分确实能帮上忙直接用又会被噪声污染。CRAG 的 AMBIGUOUS 路径专门处理这个灰色地带保留有用的部分同时去外部补充缺失的部分两个来源合并后精炼。一句 Prompt 做不到这种精细分流。硬伤三失败了你不知道。假设模型今天没听 Prompt 的指令用垃圾文档编了个答案你怎么发现没有任何信号告诉你这次回答是基于高质量文档还是噪声文档。用户看到的是一个自信的回答监控面板上一切正常直到有人投诉才知道出了问题。CRAG 的评估器每次输出置信度分数和判定路径这些信号可以记录、监控、告警。“今天 40% 的查询走了 INCORRECT 路径”这句话本身就是一个运营信号告诉你知识库有缺口。Prompt 方案完全没有这层可观测性。所以结论是**Prompt 兜底是最后一道防线CRAG 是在防线之前就把问题解决了。**两者不矛盾最佳实践是 CRAG 管道跑完最终生成阶段的 Prompt 里依然保留不确定就说不知道的兜底。纵深防御不是二选一。针对这类问题目前市场上有三个主流方案CRAG、Self-RAG、Adaptive RAG。CRAG检索之后加一道「质检关」CRAGCorrective Retrieval Augmented Generation是 2024 年初 Shi-Qi Yan 等人提出的框架思路其实挺直白的就是在检索器和 LLM 之间插一个检索评估器先判断拿到的文档能不能用再决定怎么处理。评估器对每份检索文档打分得到一个置信度分数然后走三条路路径一CORRECT置信度 ≥ 0.7检索结果靠谱直接用但也不是原封不动丢给 LLM还会做一步知识精炼。知识精炼就是把文档拆成句子级别的碎片逐句判断跟问题有没有关系再把有用的句子拼回去。这步相当于把文档里的噪声洗掉。路径二INCORRECT置信度 0.3检索结果完全不搭边果断扔掉。先用 LLM 把用户的口语化问题改写成搜索引擎友好的查询然后去 Web 搜索拿到外部结果后走同样的精炼流程。路径三AMBIGUOUS0.3 ~ 0.7最微妙也最常见的情况检索结果有点相关但不够充分。这时候两条路都走保留内部检索文档的精华同时触发 Web 搜索把两个来源的结果合并后统一精炼。这三条路的设计抓住了一个实际痛点大部分企业知识库的检索结果恰好落在半对不对的模糊地带。纯二分类相关/不相关处理不了这种情况三路径才是务实的选择。LangGraph 实现核心逻辑用 LangGraph 搭 CRAG核心代码结构大概长这样from langgraph.graph import StateGraph, ENDfrom typing import TypedDict, Listclass GraphState(TypedDict): question: str documents: List[str] web_query: str web_docs: List[str] refined_context: str generation: str verdict: str # CORRECT / INCORRECT / AMBIGUOUSworkflow StateGraph(GraphState)# 定义节点workflow.add_node(retrieve, retrieve_documents)workflow.add_node(evaluate, evaluate_retrieval) # 检索评估器workflow.add_node(refine, refine_knowledge) # 知识精炼workflow.add_node(rewrite_query, rewrite_for_search) # 查询改写workflow.add_node(web_search, web_search_fallback) # Web 搜索回退workflow.add_node(generate, generate_answer)# 路由逻辑workflow.add_edge(retrieve, evaluate)workflow.add_conditional_edges( evaluate, route_by_verdict, { correct: refine, # 直接精炼 incorrect: rewrite_query, # 改写 → Web 搜索 ambiguous: web_search, # 双源融合 })workflow.add_edge(rewrite_query, web_search)workflow.add_edge(web_search, refine)workflow.add_edge(refine, generate)workflow.add_edge(generate, END)评估器的 Prompt 也不复杂核心就是让 LLM 当裁判EVALUATOR_PROMPT 你是一个检索文档质量评估器。给定用户问题和一份检索文档判断这份文档是否包含回答该问题所需的信息。用户问题{question}检索文档{document}请输出 JSON{{score: yes 或 no, reasoning: 一句话理由}}对 Top-K 的每份文档都跑一次评估统计yes的比例作为置信度。全部 yes → CORRECT全部 no → INCORRECT其余 → AMBIGUOUS。生产环境的几个坑延迟问题。每份文档一次 LLM 调用Top-4 就是 4 次评估 若干次精炼调用建议评估器用 GPT-4o-mini 或同级别的快模型把强模型留给最终生成。阈值调优。 0.7 和 0.3 是论文默认值实际要根据业务场景调。法律、医疗这种高风险领域CORRECT 的门槛拉到 0.8 甚至 0.9宁愿多查一次 Web也别让模型用半吊子文档编答案。Web 搜索也要精炼。联网搜索的内容其实有大量的噪声比如导航文字、广告、无关段落必须走同样的 Decompose → Filter → Recompose 流程。最大重试次数。加一个计数器循环最多 3 次不然某些边缘查询会陷入改写 → 搜索 → 评估失败 → 再改写的死循环。Self-RAG让模型自己决定什么时候检索Self-RAG 走了另一条路。它不是在管道里加外部评估器而是微调模型本身让模型在生成过程中插入特殊的反思 TokenReflection Tokens自己判断要不要检索、检索到的东西有没有用、生成的内容有没有幻觉。几个关键的反思 TokenToken含义触发条件[Retrieve]是否需要检索模型判断当前生成需要外部知识[IsREL]检索文档是否相关拿到文档后评估[IsSUP]生成内容是否有文档支撑幻觉检测[IsUSE]最终回答是否有用答案质量自评这套机制的好处是模型不会对每个问题都去检索。问11等于几模型直接回答不浪费检索资源。问公司差旅报销上限是多少模型先输出[Retrieve]触发检索再评估文档相关性。但代价也明显你得微调一个专门的模型。原始论文用的是 Llama 2 7B在一个包含反思 Token 标注的数据集上训练。这意味着你不能直接用 GPT-4 或 Claude它们不认识这些特殊 Token。对于大多数团队来说微调的成本和维护负担太重了。除非你在做医疗诊断或法律文书这类对幻觉零容忍的场景否则 CRAG 的投入产出比更高。Adaptive RAG在检索之前就做路由Adaptive RAG 的思路更上游一步还没开始检索就先判断这个查询需要什么级别的处理。它用一个查询分类器可以是轻量 LLM 或训练的分类模型把查询分成几档简单查询模型参数化知识就能回答 → 直接生成跳过检索中等查询需要标准 RAG → 单步检索 生成复杂查询需要多跳推理 → 迭代检索 推理链实现起来最简单加一个路由节点就行。但它解决的问题跟 CRAG 不同CRAG 管的是检索到垃圾怎么办Adaptive RAG 管的是该不该检索、检索几次。两者其实可以组合使用先用 Adaptive RAG 做前置路由需要检索的查询再进 CRAG 管道做质量把关。三种范式怎么选90% 的团队选 CRAG 就够了。不需要微调模型LangGraph 几十行代码搭完效果立竿见影。检索评估器用便宜的小模型跑成本可控。Self-RAG 留给极端场景。如果你的业务是医疗报告生成或法律合规审查对幻觉的容忍度接近零值得花时间微调一个带反思能力的模型。Adaptive RAG 适合做前置路由。特别是当你的系统同时处理简单闲聊和复杂知识问答时先过一遍分类器能省下大量不必要的检索成本。 最佳实践是 Adaptive RAG CRAG 组合前者决定要不要检索、检索几轮后者保证每轮检索的质量。落地时的几条实操建议1. 评估器的 Prompt 要针对你的领域定制。通用的这篇文档是否相关不够精确。如果你做的是技术文档 QAPrompt 里要明确判断文档是否包含回答技术问题所需的具体参数、步骤或配置信息。2. 置信度阈值不要写死。接入一个配置中心支持按知识库、按查询类型动态调整。新上线的知识库文档质量参差不齐阈值拉高一些成熟的、经过人工审核的库可以适当放低。3. 精炼环节可以用 Embedding 相似度做预过滤。在 LLM 逐句打分之前先用 Embedding 算一下每句话跟查询的余弦相似度低于 0.3 的直接过滤掉。这能减少 60% 的 LLM 调用。4. 记录评估器的判断分布。上线后持续监控三个路径的流量比例。如果 INCORRECT 的比例长期高于 40%说明你的知识库覆盖有明显缺口该补文档了。如果 AMBIGUOUS 占比过高可能是分块策略有问题——块太大导致相关内容被噪声稀释。5. Web 搜索不是万能的回退。对于私有知识库的问题内部制度、客户数据Web 上搜不到答案。这类场景的 INCORRECT 路径应该返回抱歉我没有找到相关信息而不是去 Web 上硬搜一个不相关的结果。最后传统 RAG 的问题不是检索不出东西而是检索出了垃圾还不自知。CRAG 的核心价值就是让管道有了自我判断的能力该用就用不该用就认错找别的路。如果你的 RAG 系统在生产环境里跑着而且你还没有加检索评估这一层可以考虑用用。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】