12.人工智能实战：RAG 检索命中了但回答仍然错误？上下文压缩、引用约束与反幻觉 Prompt 的工程实践

人工智能实战RAG 检索命中了但回答仍然错误上下文压缩、引用约束与反幻觉 Prompt 的工程实践一、问题场景资料明明找到了模型还是胡说上一篇我们解决了 RAG 系统里最常见的问题召回不准通过结构化切分 混合检索 rerank 重排 TopK 控制检索效果明显提升。但很快又遇到第二个问题资料已经召回正确模型回答仍然不稳定。典型表现1. 引用了正确资料但回答多加了不存在的内容 2. 多个资料放在一起后模型混合了不同规则 3. 明明资料里没有答案模型仍然强行回答 4. 模型回答看起来很自信但依据不明确 5. 长上下文下模型忽略了真正关键的一句话这类问题比“召回失败”更隐蔽。因为你看检索结果资料是对的但最终回答还是错的很多人会继续换模型或者把 Prompt 写得更长。但实际工程经验是RAG 的生成阶段不是简单把资料塞给模型而是要做上下文治理。这篇文章重点解决检索命中后如何让模型严格基于资料回答减少幻觉和错引。二、真实问题复现准备几条容易冲突的制度文档docs[{id:policy_001,title:差旅报销制度,content:一线城市住宿费每天不超过500元二线城市住宿费每天不超过350元。},{id:policy_002,title:销售部门特殊报销制度,content:销售部门因客户拜访产生的住宿费一线城市每天不超过650元。},{id:policy_003,title:实习生报销制度,content:实习生差旅住宿费每天不超过200元需提前审批。}]用户问销售同事去一线城市出差住宿费最多报销多少如果上下文拼接不清楚模型可能回答一线城市住宿费每天不超过500元。但正确答案应该是销售部门客户拜访场景下一线城市住宿费每天不超过650元。这说明资料都在但模型没有正确识别适用条件。三、原因分析RAG 生成阶段的三个核心问题1. 上下文太长关键证据被稀释很多系统为了保险会塞很多文档TopK 10 每段 1000 字 总上下文接近 10000 字模型看似信息更多实际问题更大1. 噪声增加 2. 适用条件混乱 3. 关键句被淹没 4. token 成本上升2. 资料之间存在冲突或适用条件不同企业文档里经常存在通用规则 部门特殊规则 地区特殊规则 新旧版本规则 例外条款如果 Prompt 没有要求模型判断适用条件就容易答错。3. 没有强制引用依据如果不要求模型引用资料编号它会自由生成。这在 RAG 里非常危险。因为你无法判断回答来自资料还是模型自己编的。四、解决方案设计生成阶段要做四件事1. 上下文压缩只保留和问题直接相关的句子 2. 资料结构化保留来源、标题、适用条件 3. 强引用约束回答必须引用资料编号 4. 无答案兜底资料不足时必须回答无法确定目标不是让模型回答得更长而是回答更可控、更可追溯。五、上下文压缩不要把整段都塞进去假设重排后拿到这些资料retrieved_docs[{id:policy_001,title:差旅报销制度,content:适用于全体员工。一线城市住宿费每天不超过500元二线城市住宿费每天不超过350元。},{id:policy_002,title:销售部门特殊报销制度,content:适用于销售部门客户拜访场景。销售部门因客户拜访产生的住宿费一线城市每天不超过650元。},{id:policy_003,title:实习生报销制度,content:适用于实习生。实习生差旅住宿费每天不超过200元需提前审批。}]可以先做一个简单的句子级压缩defsplit_sentences(text:str):separators[。,,\n]sentences[text]forsepinseparators:new_sentences[]forsinsentences:new_sentences.extend(s.split(sep))sentencesnew_sentencesreturn[s.strip()forsinsentencesifs.strip()]根据关键词筛选相关句defcompress_context(query:str,docs:list[dict]):keywords[wforwinqueryifw.strip()]compressed[]fordocindocs:sentencessplit_sentences(doc[content])selected[]forsentenceinsentences:ifany(kinsentenceforkin[销售,一线城市,住宿费,报销]):selected.append(sentence)ifselected:compressed.append({id:doc[id],title:doc[title],content:。.join(selected)})returncompressed这个版本比较简单生产环境可以用1. 小模型摘要 2. 句向量相似度筛选 3. LLM extract 4. 规则 rerank但核心原则不变生成阶段不要塞无关信息。六、构造带引用的上下文defbuild_cited_context(docs:list[dict]):blocks[]fordocindocs:blockf [资料ID:{doc[id]}] 标题:{doc[title]}内容:{doc[content]}blocks.append(block.strip())return\n\n.join(blocks)生成的上下文类似[资料ID: policy_001] 标题: 差旅报销制度 内容: 适用于全体员工。一线城市住宿费每天不超过500元 [资料ID: policy_002] 标题: 销售部门特殊报销制度 内容: 适用于销售部门客户拜访场景。销售部门因客户拜访产生的住宿费一线城市每天不超过650元这样模型更容易区分通用规则 vs 特殊规则七、设计反幻觉 Prompt重点不是写得华丽而是约束清楚。defbuild_anti_hallucination_prompt(query:str,context:str):returnf 你是企业知识库问答助手。 请严格根据【资料】回答问题不要使用资料之外的常识或猜测。 【回答规则】 1. 如果资料中存在直接答案请给出明确答案。 2. 如果资料存在多个规则请优先使用与用户问题条件最匹配的规则。 3. 如果资料中没有答案请回答“根据现有资料无法确定”。 4. 回答中必须标注引用的资料ID。 5. 不允许编造资料ID不允许引用不存在的内容。 【资料】{context}【用户问题】{query}【输出格式】 直接答案 依据 注意事项 这个 Prompt 解决三个问题1. 限定信息来源 2. 要求判断适用条件 3. 强制输出依据八、增加答案校验器生成完答案后不要直接返回。可以做一个简单校验defvalidate_answer(answer:str,allowed_doc_ids:list[str]):has_referenceany(doc_idinanswerfordoc_idinallowed_doc_ids)ifnothas_reference:returnFalse,answer has no valid referenceforbidden_words[我认为,可能,一般来说,通常情况下]ifany(wordinanswerforwordinforbidden_words):returnFalse,answer may contain unsupported speculationreturnTrue,ok调用allowed_ids[doc[id]fordocincompressed_docs]valid,reasonvalidate_answer(answer,allowed_ids)ifnotvalid:answer根据现有资料无法确定。这个校验器很简单但工程上很有用。尤其是面向制度、合同、财务、法务类知识库时宁可回答不知道也不要胡说。九、完整流程代码defrag_generate(query:str,retrieved_docs:list[dict]):compressed_docscompress_context(query,retrieved_docs)ifnotcompressed_docs:return{answer:根据现有资料无法确定。,references:[]}contextbuild_cited_context(compressed_docs)promptbuild_anti_hallucination_prompt(query,context)# 这里替换成真实 LLM 调用answercall_llm(prompt)allowed_ids[doc[id]fordocincompressed_docs]valid,reasonvalidate_answer(answer,allowed_ids)ifnotvalid:return{answer:根据现有资料无法确定。,references:allowed_ids,validation:reason}return{answer:answer,references:allowed_ids,validation:ok}十、模拟 LLM 调用为了本地可运行可以先用 mockdefcall_llm(prompt:str):return 直接答案 销售同事因客户拜访去一线城市出差住宿费最多报销650元/天。 依据 该规则来自资料ID: policy_002其中说明销售部门因客户拜访产生的住宿费一线城市每天不超过650元。 注意事项 如果不是销售部门客户拜访场景则可能适用普通差旅报销制度。 测试query销售同事去一线城市出差住宿费最多报销多少resultrag_generate(query,retrieved_docs)print(result[answer])print(result[references])十一、验证结果优化前问题销售同事去一线城市出差住宿费最多报销多少 回答一线城市住宿费每天不超过500元。 问题忽略了销售部门特殊规则。优化后回答销售部门客户拜访场景下一线城市住宿费最多650元/天。 引用policy_002。核心变化不是模型变强了而是上下文更干净约束更明确答案可追溯。十二、踩坑记录坑 1上下文越多越好这是 RAG 里非常常见的误区。上下文越多模型越容易混淆。正确做法是召回多一点生成少一点。也就是召回 TopK 可以较大 最终放进 Prompt 的内容必须精简。坑 2没有区分通用规则和特殊规则企业知识库里经常存在例外条款。如果不让模型判断适用条件它很容易选通用规则。Prompt 中必须明确优先使用与用户问题条件最匹配的规则。坑 3不要求引用资料 ID不要求引用就没法追责。用户问依据是什么系统必须能回答来自哪份资料哪个片段。坑 4让模型自由发挥RAG 的目标不是发挥创造力而是基于资料回答。所以制度问答、合同问答、内部文档问答应降低自由度temperature 0 或 0.1坑 5没有答案也强行回答RAG 系统最重要的能力之一是知道自己不知道。Prompt 必须允许模型回答根据现有资料无法确定。十三、适合收藏的生成阶段 Checklist上下文 [ ] 是否压缩无关内容 [ ] 是否保留资料来源 [ ] 是否保留标题 [ ] 是否保留适用条件 [ ] 是否限制最大上下文长度 Prompt [ ] 是否要求严格根据资料回答 [ ] 是否允许回答无法确定 [ ] 是否要求引用资料ID [ ] 是否要求判断适用条件 [ ] 是否禁止编造 校验 [ ] 是否检查引用ID [ ] 是否检查答案是否包含猜测词 [ ] 是否对无引用答案降级 [ ] 是否记录最终上下文十四、经验总结RAG 的生成阶段核心不是让模型“更会说”而是让模型更守规矩。很多答错问题并不是因为模型能力差而是因为1. 上下文太乱 2. 资料冲突没有处理 3. Prompt 没有约束 4. 回答没有校验一句话总结RAG 生成质量 干净上下文 明确约束 可追溯引用 后置校验。十五、后续优化建议可以继续做1. 句子级 rerank 2. LLM-based context compression 3. 引用片段高亮 4. 答案一致性校验 5. 多轮追问时重写 query 6. 对高风险问题强制返回引用 7. 对制度类问题使用低 temperature 8. 对无答案问题建立拒答策略最后一句经验RAG 系统最怕的不是回答少而是没有依据地回答多。