1. 面试场景还原与问题本质拆解“RAG系统的LLM幻觉怎么治” 这个问题在滴滴Agent岗的二面中被抛出来本身就很有意思。它不是一个简单的“什么是RAG”或者“RAG怎么用”的入门问题而是一个直击RAG系统生产落地核心痛点的“诊断与治疗”问题。面试官想看到的绝不仅仅是你对几个技术名词的背诵而是你能否像一个系统架构师或资深算法工程师一样从根源上理解问题并构建一套层次化的防御体系。我们先来还原一下这个问题的背景。当我们在谈论一个服务于滴滴内部或面向用户的Agent比如智能客服、行程规划助手、内部知识问答机器人时RAG检索增强生成几乎是当前构建可靠、事实性强的对话系统的首选架构。它的理想很美好用户提问系统从海量、准确的知识库如司机规范、城市交规、最新促销政策文档中检索出最相关的片段然后交给大语言模型LLM让它基于这些“证据”来生成回答。这样既能利用LLM强大的语言理解和生成能力又能用“检索”这根缰绳拴住它防止它信口开河即产生“幻觉”。但现实很骨感。即便给了“证据”LLM依然可能产生幻觉。比如你问“滴滴专车在北京首都机场T3航站楼的指定上车点在哪里” RAG系统从最新的《北京机场接送指南》PDF里检索出了正确段落“T3航站楼到达层8号门对面。” 但LLM在生成答案时可能会画蛇添足地加上一句“请注意该上车点仅在早6点至晚10点开放。” 而原文根本没有提到时间限制。这句多出来的、看似合理但毫无依据的话就是典型的“幻觉”。在出行这种对信息准确性要求极高的场景下这种幻觉是致命的可能导致乘客白等、司机被投诉。所以面试官问“怎么治”其实是在考察你以下几个维度的能力深度诊断能力你是否能超越“LLM不靠谱”这种笼统的抱怨精准定位幻觉产生的具体环节和根源系统化思维你是否能构建一个从前到后、层层设防的治理框架而不是依赖某个“银弹”工程权衡意识每一种“疗法”都可能带来成本计算、延迟、复杂度的增加你是否能根据业务场景如滴滴的实时客服 vs. 内部知识沉淀做出合理的权衡前沿技术嗅觉你是否了解行业内最新的研究和实践来应对这一问题接下来我们就沿着“两类根源 - 四道防线”的脉络深入拆解这个问题的“治疗方案”。2. 追根溯源RAG系统中幻觉的两大“病根”治理幻觉首先要像老中医一样“辨证”找到病根。在RAG的流水线中幻觉主要滋生在两个环节我把它们称为“检索侧失察”和“生成侧任性”。2.1 病根一检索侧失察——给了错误的“证据”这是幻觉的“上游污染源”。如果检索系统递给LLM的文档片段本身就是不相关、不准确或信息不足的那么LLM基于此生成错误答案的概率就会极大增加。具体又分为几种情况检索无关内容这是最常见的问题。用户的查询和检索到的文档在语义上匹配度低。例如用户问“如何报销高速公路费”系统却检索出了一段关于“市内停车费规则”的文档。LLM可能会强行捏造一个基于停车费规则的“报销流程”造成完全错误的指引。检索到过期或错误内容知识库更新不及时。比如某城市的机场接送政策已变更但知识库中还是旧文档。LLM基于旧信息生成答案自然就是“幻觉”。检索粒度不当检索出的片段要么太短缺乏上下文导致信息模糊要么太长夹杂了大量无关噪声让LLM抓不住重点。例如检索出一整页的法律条文但关键条款淹没在冗长文本中LLM可能总结错误。多文档检索冲突当从多个来源检索信息时不同文档之间可能存在矛盾。例如一份文档说A业务需要审核3天另一份说需要5天。LLM如果没有明确的“裁决”机制可能会生成一个折中的、错误的“4天”或者随机选择一个。核心原因在于传统的向量检索如基于Embedding的相似度搜索本质上是“语义相似度”匹配它无法保证“事实一致性”。它可能把“苹果公司”和“吃苹果”的文档混在一起因为它们的Embedding在某种角度上相似。此外单纯的词频统计如BM25也无法理解语义的细微差别。2.2 病根二生成侧任性——无视或曲解“证据”即使检索系统提供了完美、相关、准确的证据LLM本身也可能“不听话”这是幻觉的“内生性病灶”。忽略检索内容IgnoringLLM完全或部分忽略了提供的检索上下文而是依赖于其内部参数化知识可能已过时或不准确来生成答案。这在模型参数知识很强而检索内容较弱时尤其明显。过度概括或捏造Over-generalizing/FabricatingLLM基于检索到的正确信息进行了超出范围的推断或添加了不存在的细节。就像开头的机场例子LLM根据“上车点”这个事实自行脑补了“开放时间”。理解偏差MisinterpretationLLM错误理解了检索片段中的复杂逻辑、否定关系或限定条件。例如文档说“除特殊情况外不允许……”LLM可能生成为“完全不允许……”。忠实度与流畅度的权衡LLM的训练目标之一是生成流畅、连贯的文本。有时为了语句的通顺和“看起来合理”它可能会牺牲对检索内容的严格忠实进行小幅度的改写或补充而这些补充恰恰引入了错误。核心原因在于LLM本质上是一个概率生成模型它的目标是生成“看起来最可能”的下一个词序列而不是“最忠实于证据”的序列。它的“知识”来源于训练数据而训练数据本身可能存在偏见、错误或时效性问题。当指令遵循Instruction Following和上下文利用In-Context Learning的能力不足时幻觉就产生了。理解了这两类根源我们的“治疗”方案就有了明确的靶点既要优化检索系统确保送上前线的“弹药”是精准的也要约束LLM的生成行为让它成为一个严谨的“证据使用者”。3. 第一道防线检索优化——确保“证据”的精准投送这是治理幻觉最前端、也最有效的防线。目标是从源头减少垃圾信息的输入。3.1 精细化文档处理与索引策略在文档进入向量数据库之前预处理的质量直接决定了检索的上限。分块Chunking策略的艺术抛弃简单的按固定字数或段落分割。对于结构化文档如API文档、QA列表按章节或问题分割对于非结构化长文本采用基于语义的递归分割确保每个块有完整的主题。例如使用LangChain的RecursiveCharacterTextSplitter时仔细调整chunk_size和chunk_overlap并利用分隔符优先级如\n\n\n,。,来保持句子和语义的完整性。元数据增强为每个文本块附加丰富的元数据如来源文档标题、章节、更新时间、作者、置信度标签等。在检索时这些元数据可以作为强大的过滤条件。例如在滴滴的场景中可以为每个政策条款块附加城市、生效日期、业务线快车/专车/代驾等元数据。当用户提问时可以先通过元数据过滤器缩小范围再进行语义搜索准确性大幅提升。混合检索Hybrid Search这是目前业界的标配实践。结合稠密向量检索Dense Vector Retrieval 捕捉语义相似和稀疏向量检索Sparse Retrieval 如BM25 捕捉关键词匹配。向量检索能找到“意思相近”的文档BM25能精准找到“包含关键词”的文档。两者结果通过加权如RRF融合能有效应对术语准确但表述不同或表述相似但主题无关的情况。Elasticsearch或Pinecone等现代检索系统都支持开箱即用的混合检索。3.2 查询理解与重写用户的原始查询往往是模糊、简短或不规范的。直接用于检索效果很差。查询扩展Query Expansion使用一个轻量级LLM如GPT-3.5-Turbo或传统的同义词库对原始查询进行扩展。例如用户问“车费不对怎么办”系统可以自动扩展为“车费异常、费用计算错误、多扣费、申诉流程”。这能增加检索到相关文档的概率。多轮查询重写Query Rewriting在多轮对话中用户的当前问题可能省略了上文语境。例如用户先问“我去浦东机场”接着问“预约要提前多久”。第二个问题“预约”的指代是模糊的。此时可以用LLM将当前查询与对话历史结合重写为一个独立的、信息完整的查询如“预约滴滴专车从市区前往上海浦东国际机场需要提前多久预约”。这样检索的目标性会强得多。意图分类与路由在检索之前先对用户查询进行意图分类例如政策咨询、操作指引、故障报修、费用查询。不同意图可以路由到不同的知识库子集或采用不同的检索策略。例如政策咨询类查询对准确性要求极高可以调高稀疏检索的权重并启用严格的元数据过滤。3.3 检索后重排序Re-ranking初步检索可能返回10-20个相关文档块但它们的相关性排序未必最优。一个专门的重排序模型可以充当“质检员”对初筛结果进行更精细的排序。为什么需要重排序向量检索模型如text-embedding-ada-002通常是通用型的并非为你的特定领域数据微调。重排序模型如BGE-Reranker、Cohere Rerank是“句子对”分类模型专门判断“查询”和“文档”的相关性精度远高于向量相似度计算。实操要点重排序模型计算量较大通常只对Top K如K20的初检结果进行重排然后取Top N如N3送给LLM。这相当于用较小的计算成本换取了最终上下文质量的显著提升。在LangChain中可以方便地集成CohereRerank或FlashRank等组件。个人经验在资源允许的情况下重排序是性价比极高的优化手段。我们曾在一个客服项目中引入重排序后LLM答案的幻觉率通过人工评估直接下降了约15%。它的作用在于把那些“看起来相关但其实不沾边”的文档压到后面确保LLM看到的都是“精华”。4. 第二道防线提示工程——给LLM戴上“紧箍咒”当精准的“证据”准备好后如何有效地“喂”给LLM并命令它严格使用是提示工程要解决的核心问题。这是成本最低、见效最快的防线。4.1 结构化上下文与明确指令最基础的RAG提示模板是“基于以下上下文回答问题{context}。问题{question}”。这远远不够。强约束性指令在提示词中必须使用强硬、清晰的指令。请你严格扮演一个事实核查员的角色仅根据提供的参考上下文来回答问题。 上下文 {context} 问题 {question} 你的回答必须遵守以下规则 1. 答案必须完全来源于上述上下文不能引入上下文以外的任何知识。 2. 如果上下文中的信息不足以回答问题请明确说“根据提供的信息无法回答此问题”。 3. 不要对上下文信息进行任何推断、扩展或总结出上下文未明确提及的结论。 4. 引用上下文时可以注明出处例如根据第X段...。这种指令大幅降低了LLM“自由发挥”的倾向。上下文结构化不要简单地把检索到的文本块拼接起来。为每个块添加清晰的编号和来源标识。[文档片段 1 来源《滴滴平台规则》第3.2章 更新时间2024-01-15] {chunk_text_1} [文档片段 2 来源内部客服手册_V2.1 更新时间2023-11-30] {chunk_text_2} ...这不仅能帮助LLM更好地理解和引用也为后续的可解释性提供了基础。4.2 少样本示例Few-Shot与思维链Chain-of-Thought对于复杂任务光有指令还不够需要给LLM做“示范”。少样本示例在提示词中提供1-3个高质量的“问题-上下文-答案”示例。示例中要特意展示如何处理“信息不足”的情况。例如示例1 上下文[文档A] 乘客取消订单无责时限为3分钟。 问题司机接单后乘客多久内取消不用付钱 答案根据上下文乘客在司机接单后3分钟内取消订单无需承担责任。 示例2 上下文[文档B] 北京天气晴。 问题上海明天会下雨吗 答案提供的上下文只涉及北京天气没有上海天气信息因此无法回答上海明天是否会下雨。LLM会模仿示例中的严谨风格。思维链CoT引导对于需要多步推理的问题在提示中要求LLM先分解步骤。例如“请先列出回答问题所需的关键信息点然后逐一检查上下文中是否包含这些信息点最后给出结论。” 这迫使LLM更仔细地审视上下文而不是直接跳转到答案生成。4.3 元提示Meta-Prompting与角色设定这是一种更高级的技巧通过让LLM进行“自我对话”或扮演特定角色来提升忠实度。“验证者”角色设计一个两阶段提示。第一阶段让LLM作为“生成者”基于上下文生成一个初步答案。第二阶段将初步答案和原始上下文一起交给同一个LLM但切换为“验证者”角色提示词为“请严格核对以下答案是否完全基于提供的上下文。答案{draft_answer}。上下文{context}。请指出答案中任何没有上下文支持、或与上下文矛盾的部分。” 最后根据验证结果修正答案。虽然这增加了调用次数但对关键任务非常有效。系统角色设定在OpenAI API等接口中充分利用system消息来固化角色。system消息中的指令对模型行为的影响比user消息更持久和深刻。例如system: “你是一个高度严谨、安全的滴滴出行政策助手。你的所有回答都必须以滴滴官方知识库为准绝对不允许猜测或编造信息。如果知识库没有明确信息你必须告知用户无法确认。” user: “{context} \n\n 问题{question}”踩坑心得提示工程不是一劳永逸的需要针对不同的任务类型信息提取、总结、推理设计不同的提示模板。我们建立了一个“提示词库”并通过A/B测试来评估不同提示词在“答案忠实度”指标上的表现。同时要警惕“提示词注入”攻击即用户输入中可能包含试图覆盖你系统指令的内容需要在拼接提示词时做好清洗和隔离。5. 第三道防线生成过程约束——在输出前安装“过滤器”前两道防线主要是在“输入”和“指令”层面工作。这一道防线则直接介入LLM的生成过程从技术手段上限制其“胡说”的能力。5.1 受控生成与约束解码这是相对前沿但非常有效的技术方向旨在从生成算法的层面施加约束。关键词/短语约束确保生成的答案中必须或禁止包含某些关键词。例如在回答关于“报销政策”时可以约束答案中必须出现“发票”、“审批流程”、“7个工作日内”等关键术语。这可以通过在解码时修改词汇表的概率分布来实现如使用Guidance、Outlines或Transformers库的LogitsProcessor。如果模型试图生成偏离这些核心术语的句子其概率会被抑制。格式与语法约束强制要求答案以特定格式如JSON、列表、特定开头句生成。结构化输出本身就更易于后续的自动校验。例如要求答案格式为{answer: “...”, “confidence”: high/medium/low, “source_fragments”: [1,2]}。这不仅能减少自由文本的随意性也为后续的验证环节提供了便利。基于上下文的词汇约束一个更智能的方法是在生成每个词时动态地允许的词汇集限制在从检索上下文中提取出的实体、术语和它们的同义词范围内。这需要更复杂的集成但能极大提高生成内容与上下文的相关性。5.2 后处理校验与一致性验证在LLM生成答案后但返回给用户前增加一个自动化的“质检”步骤。答案与上下文的忠实度评分使用一个专门的、轻量级的文本蕴含Textual Entailment或问答QA模型来评估生成的答案是否被给定的上下文所支持。例如将“上下文”作为前提将“生成的答案”作为假设用模型判断是“蕴含”支持、“矛盾”还是“中性”。如果评分低于阈值则触发重生成或返回“信息不足”的提示。自我一致性检查Self-Consistency让同一个LLM或另一个校验模型基于相同的上下文从不同角度生成答案或进行验证。例如问题分解验证将复杂问题分解成子问题分别验证答案的每个部分是否有上下文支持。反向提问根据生成的答案反过来构造一个问题然后看从上下文中是否能检索到支持这个新问题的证据。多路径采样与投票用相同的提示和上下文让LLM在较低温度temperature下生成多个答案然后检查这些答案在关键事实点上是否一致。如果不一致则说明生成过程不稳定可能包含幻觉。事实溯源与引用强制要求LLM在生成答案时必须为陈述的每个关键事实标注出处对应到上下文片段的编号。这不仅能提高可信度也使得自动或人工校验变得非常方便。你可以检查这些引用是否真实存在且支持其陈述。技术选型思考后处理校验会增加系统延迟和复杂度。在实际工程中我们需要权衡。对于实时性要求高的客服场景可能只对高风险问题如涉及费用、安全、政策启用完整的后处理流水线。对于内部知识库问答则可以全面启用。我们团队曾尝试将DeBERTa模型微调成一个“忠实度分类器”专门用于判断生成答案与上下文的支持关系效果不错但需要标注数据。6. 第四道防线系统迭代与评估——建立长效“免疫系统”治理幻觉不是一次性的战斗而是一个持续的过程。需要建立一套监控、评估和迭代的机制让系统在运行中不断自我完善。6.1 构建多维度的评估体系不能只靠人工抽查必须建立自动化的评估指标。忠实度Faithfulness这是对抗幻觉的核心指标。衡量答案是否严格源自提供的上下文。可以通过基于规则的字符串匹配、NLI模型自动评分或人工评估来实现。答案相关性Answer Relevance评估生成的答案是否直接回答了用户的问题避免答非所问。上下文相关性Context Relevance评估检索到的上下文是否与问题真正相关。这是上游检索质量的指标。事实准确性Factual Accuracy在有标准答案的情况下直接对比生成答案与标准答案的一致性。这需要构建高质量的测试集。综合评分像RAGAS、TruLens这样的框架提供了成套的自动化评估指标。可以定期如每周在预留的测试集上运行评估跟踪各项指标的变化。6.2 构建“幻觉”负反馈闭环将生产环境中发现的问题快速反馈到系统改进中。日志与归因分析详细记录每一次问答的“问题-检索上下文-生成答案-用户反馈”。当用户给出负面反馈如点“踩”、人工客服介入时能快速定位是哪个环节出了问题。是检索错了还是LLM胡编了错误案例库建立一个持续增长的“幻觉案例库”。每个案例包含问题、错误答案、正确上下文/答案以及根因分析检索失败、指令遵循失败等。这个案例库有三个核心用途提示词优化针对特定类型的幻觉设计更具针对性的提示词。检索优化分析检索失败的案例调整分块策略、Embedding模型或重排序权重。评估基准作为内部回归测试集确保系统优化不会引入新的退化。主动学习与数据增强利用这些错误案例可以主动地补充知识库对于知识盲区或者创建新的训练数据来微调重排序模型、校验模型甚至是在特定领域微调LLM本身使其更“听话”。6.3 面向领域的系统优化在滴滴这样的具体业务场景下可以做一些更深度的定制。领域自适应Embedding使用滴滴内部的工单、客服对话、政策文档等数据对开源的Embedding模型如BGE、text-embedding-ada-002进行领域自适应微调。让模型更理解“行程取消”、“费用异议”、“安全投诉”等业务术语的语义大幅提升检索相关性。构建业务规则引擎对于一些高度结构化、确定性极强的知识如“XX城市服务开通列表”、“最低消费金额”完全可以绕过RAG和LLM直接由规则引擎匹配和返回。将RAGLLM用于处理需要理解和推理的复杂、非结构化问题。这种“规则AI”的混合系统在保证核心事实绝对准确的同时又能处理灵活的自然语言查询。人机协同与渐进式披露对于置信度不高的答案系统可以不直接给出肯定答复而是采用更保守的策略如“关于您提到的‘跨城费是否包含高速费’我找到一条相关规定引用片段但其中没有明确说明。您是否需要我为您转接人工客服进一步确认” 这既提供了价值又避免了传播不确定信息。治理RAG中的LLM幻觉没有单一的“银弹”。它要求我们从一个系统工程师的视角出发在数据准备、检索、提示、生成、校验的每一个环节都设立关卡层层过滤。从确保高质量的知识供给检索优化到给模型明确的作战指令提示工程再到对输出进行技术审查生成约束最后建立持续改进的机制系统迭代这四道防线共同构成一个动态的、鲁棒的防御体系。在实际面试中如果能沿着这个脉络结合滴滴具体的业务场景如处理司乘纠纷、解读地方交规来举例说明每一道防线的具体实施方法和权衡考量并展现出你对成本、延迟、效果三者关系的深刻理解那么你给出的就不仅仅是一个“答案”而是一份令人信服的“解决方案蓝图”。这正是在高级别技术面试中脱颖而出的关键。
