如何规避 RAG 系统中大模型的幻觉事情是这样的。有个团队做了一个内部客服机器人接了公司的制度库、产品手册和历史工单。第一轮用户问★报销打车费需要什么材料机器人答得挺准能说出发票、行程单、审批单还能引用制度编号。第二轮用户又问★那如果是晚上十点之后呢机器人也能回答说需要补充加班证明。第三轮用户继续问★那这个是不是主管批一下就行这时候系统开始一本正经地胡说了。它说「主管审批即可无需额外材料」还顺手编了一个制度条款。看起来很像真的语气也很稳甚至还给了一个不存在的“第 4.2.1 条”。这就很要命了。因为用户不是在闲聊他可能真的会照着做。等到财务驳回锅不会甩给向量数据库也不会甩给 prompt用户只会觉得这个 AI 不靠谱。更尴尬的是团队一开始还很困惑。明明接了知识库。明明检索结果也有。明明模型能力也不差。那为什么 RAG 系统还是会幻觉不是模型突然变坏了是系统没有管住它RAG 幻觉最常见的根因不是大模型完全不知道答案。而是系统给了它一堆不干净、不完整、没优先级的信息然后又要求它必须回答得像专家。模型很擅长补全。这既是能力也是风险。当检索结果缺失、上下文冲突、引用不清、问题指代模糊时模型不会天然停下来问一句「我不知道」。它更可能根据已有碎片补出一个听起来合理的答案。所以规避 RAG 幻觉不是只在 prompt 里加一句★不要胡说。这句话有用但很有限。真正要做的是让系统在每一层都减少“模型自由发挥”的空间。第一层用户的问题本身可能就不完整RAG 系统最容易被低估的一层是 Query。单轮问答里用户的问题通常比较完整★公司差旅报销标准是什么但多轮对话里用户经常这么问★那这个呢 刚才那个场景呢 如果换成上海呢 主管批一下行不行人看得懂因为人记得前文。检索系统不一定看得懂。很多系统的代码是这么写的def chat(question, history): docs vector_db.search(question, top_k5) prompt build_prompt(history, docs, question) return llm.generate(prompt)听起来没问题对吧历史进了 prompt文档也检索了。但问题在这里docs vector_db.search(question, top_k5)检索只看了当前这一句。用户问「这个是不是主管批一下就行」向量库根本不知道「这个」指的是“晚上十点之后的打车报销”。于是它可能搜到一堆包含“主管审批”的制度文档却没搜到“夜间打车”“加班证明”“差旅报销”这些关键约束。后面模型拿到的证据已经偏了。它再强也是在错误材料上写答案。这类问题的解法不是把 history 全塞给模型而是做 Query Rewrite。把用户当前问题改写成一个独立、可检索的问题def rewrite_query(question, history_summary): prompt f 你是检索查询改写器。 基于对话摘要和用户当前问题生成一个完整、明确、适合检索知识库的问题。 对话摘要 {history_summary} 用户当前问题 {question} 要求 - 保留用户真实意图 - 补全指代对象 - 不要引入摘要中没有的信息 - 只输出改写后的查询 return llm.generate(prompt)改写后的查询应该类似★晚上十点之后因加班产生的打车费报销是否只需要主管审批还是还需要加班证明和其他材料这时候再去检索命中率会高很多。但 Query Rewrite 也不是银弹。它可能改错用户意图。所以工程上要加两个约束风险处理方式改写过度保留原始 query 和改写 query一起参与检索指代不清让模型返回need_clarificationtrue不要强行改写引入新事实prompt 明确禁止补充历史里没有的信息多轮漂移用结构化摘要而不是无限 append history核心判断很简单检索前的问题越含糊回答后的幻觉越像真的。第二层向量相似不等于答案相关很多 RAG 系统上线初期最爱盯一个指标★向量相似度。相似度高就以为文档靠谱。但线上系统最怕的就是这个。因为向量相似度解决的是“语义上像不像”不是“能不能回答这个问题”。比如用户问★晚上十点之后打车报销是不是主管批一下就行向量检索可能返回这些文档文档为什么被召回实际问题主管审批流程说明有“主管”“审批”没有夜间打车规则差旅报销总则有“报销”条款太泛加班管理制度有“晚上十点”不一定提打车夜间交通补贴规则最相关可能排在后面如果系统直接把 top 5 塞进 prompt模型会在这些材料里自己拼答案。这就是幻觉的温床。更稳的做法是 Hybrid Search Rerank。先用关键词和向量一起召回再用重排模型判断“这份文档是否能回答当前问题”。一个简化流程大概是这样用户问题 - Query Rewrite - Vector Search 召回语义相关文档 - Keyword Search 召回关键词命中文档 - Merge 去重 - Rerank 判断答案相关性 - 只保留高相关证据进入 prompt代码可以写得很直白def retrieve(query): vector_docs vector_db.search(query, top_k20) keyword_docs keyword_search.search(query, top_k20) candidates deduplicate(vector_docs keyword_docs) ranked reranker.rank( queryquery, documentscandidates, top_k6 ) return [doc for doc in ranked if doc.score 0.72]这里有两个关键点。一个是召回要宽一点。不要指望第一次检索就精准命中全部答案。另一个是进入 prompt 要窄一点。不要把低相关文档也塞进去指望模型自己分辨。坦率地讲很多 RAG 幻觉不是因为文档太少而是因为文档太杂。模型看到 6 段互相打架的材料又被要求“给出明确答案”它就会开始编一个看似统一的结论。第三层Prompt 里必须标清证据边界很多系统的 prompt 看起来像这样请根据以下参考资料回答用户问题。 参考资料 {context} 用户问题 {question}这太粗了。模型不知道哪段资料更新哪段资料过期哪段来自正式制度哪段来自历史工单哪段只是用户聊天记录。对人来说来源不同可信度完全不同。对模型来说如果你不标它就可能混着用。更可靠的 prompt 应该把证据边界写清楚你是企业知识库问答助手。 回答规则 1. 只能依据【正式制度】和【产品文档】回答。 2. 【历史工单】只能作为理解问题的辅助不能作为制度依据。 3. 如果资料不足以回答必须说“当前资料不足无法确认”。 4. 每个关键结论后必须引用资料编号。 5. 不允许编造制度编号、条款号、流程名称。 参考资料 [doc_idHR-2025-018] [type正式制度] [updated_at2025-03-12] [trusthigh] 内容晚上十点后因加班产生的打车费需提供加班审批记录、发票和行程单。 [doc_idTICKET-8831] [type历史工单] [updated_at2024-11-02] [trustlow] 内容有员工反馈主管口头同意后仍被财务驳回。 用户问题 晚上十点之后打车报销是不是主管批一下就行这样做不是为了让 prompt 更长。而是为了让模型知道哪些能当证据。哪些只能当背景。哪些信息优先级更高。如果没有这个边界模型很可能把历史工单里的“主管口头同意”当成正式规则。这就是很多企业 RAG 最危险的地方模型不是凭空胡说它是在错误地平权所有上下文。所以我自己更建议RAG prompt 里至少给每段材料加 4 个元信息元信息作用source资料来源制度、手册、工单、网页、用户上传updated_at判断时效性trust_level判断可信度doc_id方便引用和追责当答案不能被高可信资料支撑时系统必须允许拒答。拒答不是体验差。在企业场景里乱答才是体验差。第四层不要让模型替你做事实校验很多团队会把所有压力都压给生成模型★你要准确。 你要基于知识库。 你不要幻觉。 你要引用来源。这当然要写。但不能只写。因为生成模型的主要任务是“生成答案”不是“审计答案”。更稳的架构应该在生成后加一层校验。比如让系统检查三个问题答案里的关键结论是否都能在资料中找到依据引用的doc_id是否真实存在答案有没有出现资料中没有的条款、数字、时间、流程名可以做一个轻量级 verifierdef verify_answer(answer, evidence_docs): prompt f 你是答案校验器。 请检查回答是否完全被证据支持。 证据 {format_docs(evidence_docs)} 回答 {answer} 输出 JSON {{ supported: true/false, unsupported_claims: [], fake_citations: [], should_refuse: true/false }} return llm.generate_json(prompt)如果校验失败就不要直接把原答案吐给用户。可以降级成当前知识库资料不足以确认“只需要主管审批”。 已检索到的正式制度只说明晚上十点后因加班产生的打车费需要提供加班审批记录、发票和行程单。这一步会增加延迟和成本。但在制度、医疗、金融、法务、运维这些场景里很值。因为这些场景里幻觉不是“答错一道题”。它可能会变成错误操作、错误承诺、错误决策。第五层没有评估幻觉只能靠感觉排查RAG 系统最怕一种状态线上有人反馈不准团队就开始调 prompt。调完之后感觉好像好了一点。过几天又有人反馈不准再继续调。这不是工程优化。这是玄学调参。要规避幻觉必须能量化看到它在哪一层发生。至少要记录这些指标指标看什么问题retrieval_hit_rate正确文档有没有被召回rerank_top1_accuracy最相关文档有没有排到前面citation_coverage答案关键结论有没有引用unsupported_claim_rate有多少结论没有证据支持refusal_rate不确定时是否敢拒答multi_turn_decay第几轮开始质量下降尤其是多轮 RAG一定要看质量衰减曲线。比如你可能会看到这样的日志session_id9821 turn1 hit_rate1.00 citation_coverage0.92 unsupported_claim0 session_id9821 turn2 hit_rate0.83 citation_coverage0.86 unsupported_claim0 session_id9821 turn3 hit_rate0.41 citation_coverage0.38 unsupported_claim3 session_id9821 turn4 hit_rate0.35 citation_coverage0.22 unsupported_claim5这时候问题就很清楚了。不是模型从第三轮开始突然不会说话。是第三轮开始检索命中率掉了引用覆盖率掉了无证据结论上来了。排查方向就不该是“换个更大的模型试试”。而是回到 Query Rewrite、Memory 压缩、Rerank 和 Prompt 证据边界。工程上怎么落地如果要把 RAG 幻觉压下去我会按一条链路改。不要一上来就迷信大模型参数。先把系统管住。一套相对稳的链路是用户输入 - 意图识别 / 是否需要检索 - Query Rewrite / 指代消解 - Hybrid Search - Rerank - 证据过滤 - 带元信息的 Prompt - 生成答案 - Grounding Verify - 引用检查 / 拒答降级 - 日志与评估每一层解决一个具体问题层解决什么Query Rewrite用户问题不完整、指代不清Hybrid Search单纯向量召回漏掉关键词约束Rerank相似文档不等于答案文档Metadata Prompt来源、时间、可信度混乱Verify生成内容没有证据支撑Eval不知道幻觉在哪一层出现这里面有几个边界要提前讲清楚。Query Rewrite 会改错意图所以要保留原问题。Rerank 会增加延迟所以可以只对高风险问题启用。Verifier 会增加成本所以可以按场景分级比如制度、权限、金额类问题强制校验。长上下文不能替代信息治理。你把 100 页资料塞进去不等于模型就会更可靠。很多时候只是让模型在更大的噪声里更自信地犯错。面试怎么答如果面试官问★如何规避 RAG 系统中大模型的幻觉不要只答“优化 prompt、增加知识库、降低 temperature”。这个回答太浅。可以这么说我会把 RAG 幻觉拆成四类问题看。第一类是检索前的问题。用户的问题可能有省略和指代所以要做 Query Rewrite把当前问题改写成独立可检索的问题同时保留原始 query避免改写过度。第二类是检索中的问题。向量相似度不代表答案相关所以会用 Hybrid Search 扩大召回再用 Rerank 过滤真正能回答问题的文档。第三类是生成时的问题。Prompt 里要给证据加来源、时间、可信度和 doc_id要求模型只能基于高可信资料回答关键结论必须引用来源资料不足时允许拒答。第四类是生成后的问题。不能只相信模型自己说“我是基于资料回答的”还要做 grounding verify检查答案里的关键结论是否被证据支持引用是否真实。如果继续追问怎么评估我会补一句线上要看检索命中率、引用覆盖率、无证据结论率、拒答率和多轮质量衰减。否则 RAG 准不准只能靠感觉最后会变成反复调 prompt。这个回答的重点不是术语多。而是你能说清楚幻觉不是一个点的问题是检索、排序、上下文、生成、校验、评估整条链路的问题。回到开头那个客服机器人用户问★那这个是不是主管批一下就行系统如果没有做指代消解就不知道“这个”是什么。如果检索只看向量相似度就可能拿到一堆“主管审批”的泛文档。如果 prompt 不标来源就可能把历史工单当正式制度。如果生成后不校验就会把编出来的条款号直接发给用户。所以 RAG 系统里的幻觉很多时候不是模型不知道。而是系统没有告诉它什么能说。什么不能说。什么必须有证据才能说。真正可靠的 RAG不是让模型看起来更聪明。是让模型在证据不足的时候敢停下来。往期内容别再只堆 GPU 了RAG 扛不住高并发是因为你没懂这三件事90%的人只用了Superpowers 10%的能力实战案例带你走通全流程AI写代码比你强这篇建议收藏90%的AI开发都在用PythonJava还有戏吗AI编码效率百倍提升程序员的核心竞争力究竟在哪
如何规避 RAG 系统中大模型的幻觉
如何规避 RAG 系统中大模型的幻觉事情是这样的。有个团队做了一个内部客服机器人接了公司的制度库、产品手册和历史工单。第一轮用户问★报销打车费需要什么材料机器人答得挺准能说出发票、行程单、审批单还能引用制度编号。第二轮用户又问★那如果是晚上十点之后呢机器人也能回答说需要补充加班证明。第三轮用户继续问★那这个是不是主管批一下就行这时候系统开始一本正经地胡说了。它说「主管审批即可无需额外材料」还顺手编了一个制度条款。看起来很像真的语气也很稳甚至还给了一个不存在的“第 4.2.1 条”。这就很要命了。因为用户不是在闲聊他可能真的会照着做。等到财务驳回锅不会甩给向量数据库也不会甩给 prompt用户只会觉得这个 AI 不靠谱。更尴尬的是团队一开始还很困惑。明明接了知识库。明明检索结果也有。明明模型能力也不差。那为什么 RAG 系统还是会幻觉不是模型突然变坏了是系统没有管住它RAG 幻觉最常见的根因不是大模型完全不知道答案。而是系统给了它一堆不干净、不完整、没优先级的信息然后又要求它必须回答得像专家。模型很擅长补全。这既是能力也是风险。当检索结果缺失、上下文冲突、引用不清、问题指代模糊时模型不会天然停下来问一句「我不知道」。它更可能根据已有碎片补出一个听起来合理的答案。所以规避 RAG 幻觉不是只在 prompt 里加一句★不要胡说。这句话有用但很有限。真正要做的是让系统在每一层都减少“模型自由发挥”的空间。第一层用户的问题本身可能就不完整RAG 系统最容易被低估的一层是 Query。单轮问答里用户的问题通常比较完整★公司差旅报销标准是什么但多轮对话里用户经常这么问★那这个呢 刚才那个场景呢 如果换成上海呢 主管批一下行不行人看得懂因为人记得前文。检索系统不一定看得懂。很多系统的代码是这么写的def chat(question, history): docs vector_db.search(question, top_k5) prompt build_prompt(history, docs, question) return llm.generate(prompt)听起来没问题对吧历史进了 prompt文档也检索了。但问题在这里docs vector_db.search(question, top_k5)检索只看了当前这一句。用户问「这个是不是主管批一下就行」向量库根本不知道「这个」指的是“晚上十点之后的打车报销”。于是它可能搜到一堆包含“主管审批”的制度文档却没搜到“夜间打车”“加班证明”“差旅报销”这些关键约束。后面模型拿到的证据已经偏了。它再强也是在错误材料上写答案。这类问题的解法不是把 history 全塞给模型而是做 Query Rewrite。把用户当前问题改写成一个独立、可检索的问题def rewrite_query(question, history_summary): prompt f 你是检索查询改写器。 基于对话摘要和用户当前问题生成一个完整、明确、适合检索知识库的问题。 对话摘要 {history_summary} 用户当前问题 {question} 要求 - 保留用户真实意图 - 补全指代对象 - 不要引入摘要中没有的信息 - 只输出改写后的查询 return llm.generate(prompt)改写后的查询应该类似★晚上十点之后因加班产生的打车费报销是否只需要主管审批还是还需要加班证明和其他材料这时候再去检索命中率会高很多。但 Query Rewrite 也不是银弹。它可能改错用户意图。所以工程上要加两个约束风险处理方式改写过度保留原始 query 和改写 query一起参与检索指代不清让模型返回need_clarificationtrue不要强行改写引入新事实prompt 明确禁止补充历史里没有的信息多轮漂移用结构化摘要而不是无限 append history核心判断很简单检索前的问题越含糊回答后的幻觉越像真的。第二层向量相似不等于答案相关很多 RAG 系统上线初期最爱盯一个指标★向量相似度。相似度高就以为文档靠谱。但线上系统最怕的就是这个。因为向量相似度解决的是“语义上像不像”不是“能不能回答这个问题”。比如用户问★晚上十点之后打车报销是不是主管批一下就行向量检索可能返回这些文档文档为什么被召回实际问题主管审批流程说明有“主管”“审批”没有夜间打车规则差旅报销总则有“报销”条款太泛加班管理制度有“晚上十点”不一定提打车夜间交通补贴规则最相关可能排在后面如果系统直接把 top 5 塞进 prompt模型会在这些材料里自己拼答案。这就是幻觉的温床。更稳的做法是 Hybrid Search Rerank。先用关键词和向量一起召回再用重排模型判断“这份文档是否能回答当前问题”。一个简化流程大概是这样用户问题 - Query Rewrite - Vector Search 召回语义相关文档 - Keyword Search 召回关键词命中文档 - Merge 去重 - Rerank 判断答案相关性 - 只保留高相关证据进入 prompt代码可以写得很直白def retrieve(query): vector_docs vector_db.search(query, top_k20) keyword_docs keyword_search.search(query, top_k20) candidates deduplicate(vector_docs keyword_docs) ranked reranker.rank( queryquery, documentscandidates, top_k6 ) return [doc for doc in ranked if doc.score 0.72]这里有两个关键点。一个是召回要宽一点。不要指望第一次检索就精准命中全部答案。另一个是进入 prompt 要窄一点。不要把低相关文档也塞进去指望模型自己分辨。坦率地讲很多 RAG 幻觉不是因为文档太少而是因为文档太杂。模型看到 6 段互相打架的材料又被要求“给出明确答案”它就会开始编一个看似统一的结论。第三层Prompt 里必须标清证据边界很多系统的 prompt 看起来像这样请根据以下参考资料回答用户问题。 参考资料 {context} 用户问题 {question}这太粗了。模型不知道哪段资料更新哪段资料过期哪段来自正式制度哪段来自历史工单哪段只是用户聊天记录。对人来说来源不同可信度完全不同。对模型来说如果你不标它就可能混着用。更可靠的 prompt 应该把证据边界写清楚你是企业知识库问答助手。 回答规则 1. 只能依据【正式制度】和【产品文档】回答。 2. 【历史工单】只能作为理解问题的辅助不能作为制度依据。 3. 如果资料不足以回答必须说“当前资料不足无法确认”。 4. 每个关键结论后必须引用资料编号。 5. 不允许编造制度编号、条款号、流程名称。 参考资料 [doc_idHR-2025-018] [type正式制度] [updated_at2025-03-12] [trusthigh] 内容晚上十点后因加班产生的打车费需提供加班审批记录、发票和行程单。 [doc_idTICKET-8831] [type历史工单] [updated_at2024-11-02] [trustlow] 内容有员工反馈主管口头同意后仍被财务驳回。 用户问题 晚上十点之后打车报销是不是主管批一下就行这样做不是为了让 prompt 更长。而是为了让模型知道哪些能当证据。哪些只能当背景。哪些信息优先级更高。如果没有这个边界模型很可能把历史工单里的“主管口头同意”当成正式规则。这就是很多企业 RAG 最危险的地方模型不是凭空胡说它是在错误地平权所有上下文。所以我自己更建议RAG prompt 里至少给每段材料加 4 个元信息元信息作用source资料来源制度、手册、工单、网页、用户上传updated_at判断时效性trust_level判断可信度doc_id方便引用和追责当答案不能被高可信资料支撑时系统必须允许拒答。拒答不是体验差。在企业场景里乱答才是体验差。第四层不要让模型替你做事实校验很多团队会把所有压力都压给生成模型★你要准确。 你要基于知识库。 你不要幻觉。 你要引用来源。这当然要写。但不能只写。因为生成模型的主要任务是“生成答案”不是“审计答案”。更稳的架构应该在生成后加一层校验。比如让系统检查三个问题答案里的关键结论是否都能在资料中找到依据引用的doc_id是否真实存在答案有没有出现资料中没有的条款、数字、时间、流程名可以做一个轻量级 verifierdef verify_answer(answer, evidence_docs): prompt f 你是答案校验器。 请检查回答是否完全被证据支持。 证据 {format_docs(evidence_docs)} 回答 {answer} 输出 JSON {{ supported: true/false, unsupported_claims: [], fake_citations: [], should_refuse: true/false }} return llm.generate_json(prompt)如果校验失败就不要直接把原答案吐给用户。可以降级成当前知识库资料不足以确认“只需要主管审批”。 已检索到的正式制度只说明晚上十点后因加班产生的打车费需要提供加班审批记录、发票和行程单。这一步会增加延迟和成本。但在制度、医疗、金融、法务、运维这些场景里很值。因为这些场景里幻觉不是“答错一道题”。它可能会变成错误操作、错误承诺、错误决策。第五层没有评估幻觉只能靠感觉排查RAG 系统最怕一种状态线上有人反馈不准团队就开始调 prompt。调完之后感觉好像好了一点。过几天又有人反馈不准再继续调。这不是工程优化。这是玄学调参。要规避幻觉必须能量化看到它在哪一层发生。至少要记录这些指标指标看什么问题retrieval_hit_rate正确文档有没有被召回rerank_top1_accuracy最相关文档有没有排到前面citation_coverage答案关键结论有没有引用unsupported_claim_rate有多少结论没有证据支持refusal_rate不确定时是否敢拒答multi_turn_decay第几轮开始质量下降尤其是多轮 RAG一定要看质量衰减曲线。比如你可能会看到这样的日志session_id9821 turn1 hit_rate1.00 citation_coverage0.92 unsupported_claim0 session_id9821 turn2 hit_rate0.83 citation_coverage0.86 unsupported_claim0 session_id9821 turn3 hit_rate0.41 citation_coverage0.38 unsupported_claim3 session_id9821 turn4 hit_rate0.35 citation_coverage0.22 unsupported_claim5这时候问题就很清楚了。不是模型从第三轮开始突然不会说话。是第三轮开始检索命中率掉了引用覆盖率掉了无证据结论上来了。排查方向就不该是“换个更大的模型试试”。而是回到 Query Rewrite、Memory 压缩、Rerank 和 Prompt 证据边界。工程上怎么落地如果要把 RAG 幻觉压下去我会按一条链路改。不要一上来就迷信大模型参数。先把系统管住。一套相对稳的链路是用户输入 - 意图识别 / 是否需要检索 - Query Rewrite / 指代消解 - Hybrid Search - Rerank - 证据过滤 - 带元信息的 Prompt - 生成答案 - Grounding Verify - 引用检查 / 拒答降级 - 日志与评估每一层解决一个具体问题层解决什么Query Rewrite用户问题不完整、指代不清Hybrid Search单纯向量召回漏掉关键词约束Rerank相似文档不等于答案文档Metadata Prompt来源、时间、可信度混乱Verify生成内容没有证据支撑Eval不知道幻觉在哪一层出现这里面有几个边界要提前讲清楚。Query Rewrite 会改错意图所以要保留原问题。Rerank 会增加延迟所以可以只对高风险问题启用。Verifier 会增加成本所以可以按场景分级比如制度、权限、金额类问题强制校验。长上下文不能替代信息治理。你把 100 页资料塞进去不等于模型就会更可靠。很多时候只是让模型在更大的噪声里更自信地犯错。面试怎么答如果面试官问★如何规避 RAG 系统中大模型的幻觉不要只答“优化 prompt、增加知识库、降低 temperature”。这个回答太浅。可以这么说我会把 RAG 幻觉拆成四类问题看。第一类是检索前的问题。用户的问题可能有省略和指代所以要做 Query Rewrite把当前问题改写成独立可检索的问题同时保留原始 query避免改写过度。第二类是检索中的问题。向量相似度不代表答案相关所以会用 Hybrid Search 扩大召回再用 Rerank 过滤真正能回答问题的文档。第三类是生成时的问题。Prompt 里要给证据加来源、时间、可信度和 doc_id要求模型只能基于高可信资料回答关键结论必须引用来源资料不足时允许拒答。第四类是生成后的问题。不能只相信模型自己说“我是基于资料回答的”还要做 grounding verify检查答案里的关键结论是否被证据支持引用是否真实。如果继续追问怎么评估我会补一句线上要看检索命中率、引用覆盖率、无证据结论率、拒答率和多轮质量衰减。否则 RAG 准不准只能靠感觉最后会变成反复调 prompt。这个回答的重点不是术语多。而是你能说清楚幻觉不是一个点的问题是检索、排序、上下文、生成、校验、评估整条链路的问题。回到开头那个客服机器人用户问★那这个是不是主管批一下就行系统如果没有做指代消解就不知道“这个”是什么。如果检索只看向量相似度就可能拿到一堆“主管审批”的泛文档。如果 prompt 不标来源就可能把历史工单当正式制度。如果生成后不校验就会把编出来的条款号直接发给用户。所以 RAG 系统里的幻觉很多时候不是模型不知道。而是系统没有告诉它什么能说。什么不能说。什么必须有证据才能说。真正可靠的 RAG不是让模型看起来更聪明。是让模型在证据不足的时候敢停下来。往期内容别再只堆 GPU 了RAG 扛不住高并发是因为你没懂这三件事90%的人只用了Superpowers 10%的能力实战案例带你走通全流程AI写代码比你强这篇建议收藏90%的AI开发都在用PythonJava还有戏吗AI编码效率百倍提升程序员的核心竞争力究竟在哪
