1. 从“幻觉”到“落地”为什么你的LLM需要RAG如果你最近在折腾大语言模型不管是ChatGPT、Claude还是本地部署的Llama、Qwen大概率都遇到过同一个让人血压飙升的问题它开始一本正经地胡说八道了。你问它一个非常具体、需要精确事实支撑的问题比如“我们公司去年Q3的销售冠军是谁”或者“帮我查一下用户ID为A12345的最近一次工单处理记录”它可能会给你编造出一个名字、一段从未发生过的对话甚至引用一份根本不存在的文档。这种现象在圈内有个专业的名字叫做“幻觉”。幻觉不是LLM的错至少不全是。它的本质是一个基于概率生成文本的模型它的“知识”来源于训练时“看过”的海量数据。这些数据有截止日期有知识盲区更不可能包含你公司内部的机密文档、最新的行业报告或者你昨晚刚写的会议纪要。当你要求它回答这些它“不知道”的事情时它不会说“我不知道”而是倾向于根据已有的语言模式“创作”一个看起来合理但实际上错误的答案。这就像让一个博览群书但从未出过图书馆的学者去回答图书馆外正在发生的街头新闻他只能根据书里的情节来编造。那么怎么解决这个问题一个最直接的想法是微调。把公司内部的知识库喂给模型让它重新学习。这听起来很美好但实操起来成本极高。你需要准备高质量的标注数据、强大的算力资源、专业的算法工程师并且每更新一次知识就要重新训练或微调一次模型耗时耗力灵活性极差。对于绝大多数业务场景这无异于用高射炮打蚊子。于是检索增强生成应运而生。它不试图改变LLM本身而是为LLM配备一个“外接大脑”或“实时搜索引擎”。其核心思想极其朴素当用户提问时RAG系统会先从你的专属知识库可以是文档、数据库、网页等中快速检索出与问题最相关的几段信息然后把这些检索到的“证据”和用户的问题一起打包成一个更详细的提示词再交给LLM去生成最终答案。简单来说就是“先查资料再写答案”。RAG的魅力在于它完美地结合了传统信息检索的“精准”和LLM的“理解与生成”能力。知识库的更新变得无比简单——你只需要往向量数据库里插入新的文档片段即可无需动模型分毫。LLM的答案也有了可靠的依据大大减少了幻觉。过去一年从LangChain、LlamaIndex这类框架的爆火到Dify、Coze等低代码平台对RAG工作流的深度集成再到“Agentic RAG”、“Graph RAG”等进阶概念的提出都证明了RAG已成为LLM落地应用尤其是企业级知识问答、客服、内容生成等场景的事实标准技术路径。接下来我们就抛开概念深入这套系统的每一个齿轮看看如何从零搭建一个健壮、可用的RAG系统。2. RAG系统的核心架构拆解不止是“向量搜索LLM”很多人初识RAG会把它简单理解为“向量数据库 LLM”。这个理解没错但过于简化就像一个说汽车是“轮子沙发”一样。一个能投入生产环境、应对复杂查询的RAG系统其内部是一个精密的流水线。我们可以将其核心架构分解为四个关键阶段我习惯称之为“切、存、找、答”。2.1 知识切片把“书本”拆成“便签”你的知识源可能是一本几百页的PDF产品手册、一个满是Markdown的技术Wiki或者一堆杂乱的会议记录。第一步就是把这些非结构化的“书本”处理成LLM和检索系统能高效处理的“便签”即文本片段。这个过程叫做文本分割或分块。这里最大的误区是认为“切得越碎越好”。实际上分块策略是RAG效果的第一个决定性因素。分块太小会丢失上下文信息。比如“销售额同比增长了15%”这句话如果不知道是“哪个产品”、“哪个季度”它就是一句废话。分块太大又会引入无关噪声降低检索精度并且可能超出LLM的上下文窗口限制。常见的分块策略与选择逻辑固定大小重叠分块这是最基础、最常用的方法。比如设定每个块500个字符块与块之间重叠50个字符。这能保证信息的连续性适合通用文档。在LangChain中你可以用RecursiveCharacterTextSplitter轻松实现。from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, length_functionlen, separators[\n\n, \n, , ] # 按段落、换行、空格优先分割 ) chunks text_splitter.split_text(your_document_text)为什么选择重叠为了避免一个完整的句子或概念被硬生生从中间切断。重叠部分充当了“缓冲区”确保关键信息能完整地出现在至少一个块中。基于语义的分块更高级的策略。它不仅仅看字符长度而是试图在语义完整的边界处进行分割比如在段落、章节标题、或者句子结束的地方。这需要利用NLP模型进行句子边界检测。LlamaIndex中的SentenceSplitter就属于此类。什么时候用当你处理结构清晰、段落分明的文档如论文、报告时语义分块能更好地保留原文的叙事逻辑。智能分块与分层索引这是应对复杂查询的利器。除了基础分块还可以同时创建不同粒度的索引。例如小颗粒度块如单个句子或小节用于精准匹配事实型问题“某产品的定价是多少”。中颗粒度块如完整段落用于需要一定上下文的理解型问题“解释一下某功能的工作原理”。大颗粒度块如整个章节或文档用于需要全局视野的总结型问题“概括一下这份白皮书的核心观点”。 在查询时系统可以并行搜索不同层次的索引或者先粗筛再精查。这就是“多路召回”思想的体现。实操心得没有放之四海而皆准的分块规则。你必须根据你的数据形态和查询预期进行调优。一个实用的方法是抽取一部分典型问题用不同的分块参数进行检索测试人工评估返回的“块”是否包含了回答问题所需的完整信息。通常技术文档需要较小的块200-400字符而叙述性内容可以稍大400-800字符。重叠比例一般在10%-20%之间。2.2 向量化与存储让计算机“理解”文本含义文本被切分成块后需要转换成计算机能“理解”和“比较”的形式这就是向量化。通过嵌入模型我们将一段文本映射为一个高维空间中的点即向量。语义相近的文本其向量在空间中的距离也更近。嵌入模型的选择是关键通用vs领域专用像OpenAI的text-embedding-ada-002Cohere的嵌入模型或开源的BGE、E5系列都是优秀的通用模型。但如果你的领域非常垂直如生物医学、法律使用在该领域语料上微调过的嵌入模型效果会有显著提升。维度常见的有384维、768维、1024维等。更高的维度通常能承载更多信息但也会增加计算和存储开销。对于大多数应用768维的模型是一个很好的平衡点。存储这些向量的数据库就是向量数据库。市面上选择很多Pinecone、Weaviate、Qdrant、Milvus、Chroma轻量级等。它们都提供了高效的相似性搜索能力。这里有一个至关重要的细节常被忽略元数据存储。除了向量本身一定要把文本块的元数据一并存储。元数据至少包括原始文本内容、来源文档ID、在文档中的位置页码、章节。更完善的还可以包括文档类型、更新时间、作者等。为什么这很重要当检索系统返回一个相关片段时你不仅需要它的内容还需要知道它来自哪里以便进行后续的引用溯源、置信度评估或者在重排序阶段利用元数据进行过滤例如优先考虑更新时间更近的文档。2.3 检索与召回从“大海”里精准“捞针”当用户提问“如何重置产品A的密码”时检索阶段的目标是从向量库中找出与这个问题最相关的几个文本块。基础检索余弦相似度搜索最直接的方式是将用户问题也向量化然后计算它与库中所有向量之间的余弦相似度返回相似度最高的K个块比如top-5。这是RAG的基线方法。但为什么光有向量搜索不够—— 多路召回策略单一向量搜索的局限性在于它完全依赖于嵌入模型对语义的理解。如果用户问题中的关键词和文档中的表述不一致例如用户说“死机”文档里写“系统无响应”或者问题包含多个子意图简单的向量搜索可能会漏掉关键信息。因此工业级RAG系统会引入多路召回。常见的召回路径包括语义召回主路基于向量相似度搜索。关键词召回辅路使用BM25、TF-IDF等传统全文检索算法。它对精确匹配、术语、缩写非常有效是对语义召回的良好补充。元数据过滤召回辅路例如用户可能指定“只要2024年的文档”或者“只看产品A的说明书”。这需要在检索前或检索后利用存储的元数据进行过滤。系统会并行执行这几路召回各自得到一个候选列表最后将结果合并。合并时可能需要去重并按一定的规则如加权分数进行初步排序。2.4 重排序给“候选人”排座次多路召回合并后可能会得到10-20个甚至更多的候选文本块。直接把这些全部扔给LLM是不明智的一来成本高输入越长API调用越贵二来噪声多可能干扰LLM的判断。重排序阶段的任务就是用一个更精细、但通常也更耗资源的模型对这几十个候选块进行重新打分和排序筛选出最相关、最优质的3-5个块作为最终提供给LLM的“证据”。为什么需要专门的重排序模型因为向量搜索和关键词搜索的打分机制相对粗糙。重排序模型如Cohere的rerank模型或开源的bge-reranker是一个经过训练的“裁判”它专门判断“给定一个问题和一段文本这段文本对回答这个问题的相关性有多高”。它能够理解更复杂的逻辑关系比如因果关系、对比关系而不仅仅是表面语义的相似。重排序的典型工作流将用户问题和每一个候选文本块拼接起来输入到重排序模型。模型为每个(问题文本块)对输出一个相关性分数。根据这个分数对所有候选块进行降序排列。选取Top-N个块作为最终上下文。实操建议对于精度要求极高的场景如法律、医疗问答重排序是必不可少的环节。虽然它增加了延迟和成本但能显著提升最终答案的准确率。你可以将其视为在“召回”和“生成”之间加装的一道“质量检测关卡”。3. 提示工程与生成教会LLM“看资料答题”现在我们有了精准检索到的、经过重排序筛选的几段关键上下文。下一步就是如何将这些上下文和用户问题一起“喂”给LLM并引导它生成一个基于上下文的可靠答案。这完全依赖于提示词工程。一个糟糕的提示词即使给了黄金般的上下文LLM也可能视而不见继续胡编乱造。一个优秀的提示词则能严格约束LLM的行为。3.1 构建基础提示词模板你的提示词应该是一个结构清晰的模板。以下是一个经过实战检验的强效模板你是一个专业的问答助手。请严格根据提供的“参考上下文”来回答问题。 如果答案不在上下文中请直接说“根据提供的资料我无法回答这个问题”。不要编造任何信息。 参考上下文{context}用户问题{question} 请基于以上上下文给出准确、简洁的答案。并在答案结尾以“来源[文档名]”的格式注明答案所依据的上下文来源。这个模板的设计逻辑角色设定明确LLM的身份使其行为更专业、更聚焦。核心指令“严格根据...回答问题”和“如果答案不在...请直接说...”这是对抗幻觉最有力的两道指令。必须清晰、强硬。上下文格式化使用反引号或明确标记将上下文包裹起来使其在提示词中视觉上独立帮助LLM区分指令和材料。引用要求要求注明来源。这不仅能增加答案的可信度更重要的是它能“强迫”LLM去关联上下文中的具体信息。如果它无法找到明确的来源就很难编造出一个带引用的答案从而更可能触发“无法回答”的指令。3.2 进阶技巧思维链与少样本示例对于复杂问题可以引入思维链来提升LLM的推理质量。例如在提示词中要求LLM分步思考...前述角色和指令... 请按以下步骤思考 1. 首先从上下文中找出与问题直接相关的所有事实。 2. 然后分析这些事实之间的逻辑关系。 3. 最后综合这些信息组织成连贯的答案。 ...另一种强大的方法是少样本示例。在提示词中提供一两个“问题-上下文-答案”的示例让LLM通过模仿来学习你期望的回答格式和严谨程度。这对于格式化输出如JSON或特定风格的答案尤其有效。3.3 生成后的校验与护栏即使提示词写得再好也不能100%信任LLM的输出。因此在答案返回给用户之前建议增加一个校验层。答案相关性校验判断生成的答案是否真的回答了原始问题。可以用一个简单的分类模型或另一个LLM调用来实现。引用真实性校验检查答案中声称的引用是否真的出现在提供的上下文中。可以做一个字符串匹配或模糊匹配。幻觉检测使用专门的幻觉检测模型或规则扫描答案中是否存在上下文未提及的实体或事实断言。这些校验可以作为安全护栏一旦检测到问题可以触发重试、返回保守答案“我无法确认”或转交人工处理。4. 超越基础应对复杂场景的进阶RAG模式基础的RAG管道解决了“有据可查”的问题但在面对复杂、多跳查询时仍可能力不从心。例如“我们部门去年利润率最高的产品是什么”这个问题可能需要先检索“部门产品列表”再检索“各产品年度财务报告”最后进行对比计算。这就需要更高级的RAG模式。4.1 Agentic RAG让RAG拥有“思考”和“执行”能力Agentic RAG的核心思想是引入智能体的概念。它不再是一次性的“检索-生成”而是一个循环迭代的过程规划智能体解析复杂问题将其拆解成一系列可执行的子问题或步骤。执行针对每个子问题调用相应的工具如RAG检索、计算器、代码解释器、API查询来获取信息。观察收集工具执行的结果。反思与迭代判断当前信息是否足以回答原问题。如果不能则规划下一步行动例如提出一个新的、更具体的问题进行检索直到满足条件或达到最大迭代次数。最终生成综合所有步骤获得的信息生成最终答案。LangGraph或Dify Workflow这类工具正是为了编排这种多步骤、有状态的智能体工作流而生。它们让构建一个能自动完成“检索-分析-决策-再检索”的智能问答系统成为可能。4.2 Graph RAG利用知识图谱捕捉深层关系当你的知识库中实体和关系非常丰富时例如人物、地点、事件、产品之间的复杂关联传统的基于文本块的RAG可能无法有效捕捉这些结构化关系。Graph RAG将知识图谱与RAG结合。其流程通常是从文档中提取实体和关系构建或更新一个知识图谱。当用户提问时首先在知识图谱上进行查询或推理。例如通过图谱可以轻松找到“所有由某位工程师负责的项目”或者“与某个技术栈相关的所有产品”。将图谱查询结果可能是一组实体或关系路径作为“线索”再去向量库中检索与之相关的详细文本描述。将图谱提供的结构化关系和文本提供的详细描述结合起来生成答案。Graph RAG特别适合需要深度关系推理、溯源和探索式问答的场景。4.3 查询转换与扩展让问题变得更“好搜”用户的提问方式往往不是最优的检索查询。查询转换旨在优化用户问题提升检索效果。查询重写将口语化、冗长的问题改写成简洁、关键信息突出的陈述句。例如“我电脑老是卡住不动了咋办” - “系统无响应故障排查”。查询扩展生成原问题的同义词或相关问题用于多路检索。例如针对“LLM训练成本”可以扩展出“大语言模型计算开销”、“Transformer模型训练费用”等。假设性文档嵌入这是一种更“主动”的技术。它先让LLM基于问题“假设”一个可能包含答案的理想文档然后用这个“假设文档”的向量去进行检索。这相当于让LLM先帮我们“想象”一下答案可能长什么样再用这个想象去匹配真实文档。5. RAG系统的评估、监控与持续迭代搭建完RAG系统只是开始如何评估其好坏并让它越用越好才是真正的挑战。5.1 如何评估RAG效果不能只靠人工抽查。需要建立一套量化的评估体系通常包括检索相关度检索到的上下文与问题的相关程度。可以用人工标注0/1分也可以用重排序模型的分数作为代理指标。答案忠实度生成的答案是否严格基于提供的上下文没有增加未提及的信息幻觉。这是评估抗幻觉能力的核心指标。答案相关性生成的答案是否直接回答了问题。答案有用性综合性的主观评分评估答案的整体质量和帮助程度。可以利用像RAGAS、TruLens这样的开源评估框架它们提供了这些指标的自动化计算方法虽然部分仍依赖LLM进行评估有一定成本。5.2 核心监控指标在生产环境中必须监控以下关键指标延迟从用户提问到收到答案的总时间。区分检索延迟和生成延迟。消耗Token使用量、API调用成本。检索质量平均每个问题检索到的文本块数量、向量搜索的相似度分数分布。用户反馈点赞/点踩率、人工审核中发现幻觉的比例。失败率请求超时、模型调用失败的比例。5.3 持续迭代的闭环RAG系统是一个活系统需要持续喂养数据和优化。数据闭环将用户与系统的交互日志问题、检索到的上下文、生成的答案、用户反馈收集起来。特别是那些被用户点“踩”或人工复核发现问题的案例是宝贵的负样本。问题归因分析当答案出错时要定位是哪个环节出了问题。是检索没找到相关资料还是检索到了但排序不对没进入前几名或者是LLM无视了上下文自己编的不同的原因对应不同的优化策略。定向优化如果是检索问题可以调整分块策略、尝试不同的嵌入模型、引入或优化重排序模型、增加召回路径。如果是生成问题可以优化提示词模板、增加少样本示例、尝试不同LLM或调整生成参数如温度。如果是知识缺失那就需要补充和更新知识库文档。建立一个基于监控数据和用户反馈的持续迭代流程是RAG系统保持生命力和准确度的唯一途径。从我自己的多个RAG项目实战来看最大的教训就是RAG没有银弹参数。网上那些“最佳分块大小1024”之类的建议都只是起点。真正有效的系统一定是经过对自身业务数据、用户问题、效果指标的反复测量、分析和调优后打磨出来的。它更像一门工程实验艺术而非简单的配置组装。希望这份完全指南能帮你避开初期那些显而易见的坑更高效地踏上让LLM“言之有据”的实践之路。
1. 从“幻觉”到“落地”为什么你的LLM需要RAG如果你最近在折腾大语言模型不管是ChatGPT、Claude还是本地部署的Llama、Qwen大概率都遇到过同一个让人血压飙升的问题它开始一本正经地胡说八道了。你问它一个非常具体、需要精确事实支撑的问题比如“我们公司去年Q3的销售冠军是谁”或者“帮我查一下用户ID为A12345的最近一次工单处理记录”它可能会给你编造出一个名字、一段从未发生过的对话甚至引用一份根本不存在的文档。这种现象在圈内有个专业的名字叫做“幻觉”。幻觉不是LLM的错至少不全是。它的本质是一个基于概率生成文本的模型它的“知识”来源于训练时“看过”的海量数据。这些数据有截止日期有知识盲区更不可能包含你公司内部的机密文档、最新的行业报告或者你昨晚刚写的会议纪要。当你要求它回答这些它“不知道”的事情时它不会说“我不知道”而是倾向于根据已有的语言模式“创作”一个看起来合理但实际上错误的答案。这就像让一个博览群书但从未出过图书馆的学者去回答图书馆外正在发生的街头新闻他只能根据书里的情节来编造。那么怎么解决这个问题一个最直接的想法是微调。把公司内部的知识库喂给模型让它重新学习。这听起来很美好但实操起来成本极高。你需要准备高质量的标注数据、强大的算力资源、专业的算法工程师并且每更新一次知识就要重新训练或微调一次模型耗时耗力灵活性极差。对于绝大多数业务场景这无异于用高射炮打蚊子。于是检索增强生成应运而生。它不试图改变LLM本身而是为LLM配备一个“外接大脑”或“实时搜索引擎”。其核心思想极其朴素当用户提问时RAG系统会先从你的专属知识库可以是文档、数据库、网页等中快速检索出与问题最相关的几段信息然后把这些检索到的“证据”和用户的问题一起打包成一个更详细的提示词再交给LLM去生成最终答案。简单来说就是“先查资料再写答案”。RAG的魅力在于它完美地结合了传统信息检索的“精准”和LLM的“理解与生成”能力。知识库的更新变得无比简单——你只需要往向量数据库里插入新的文档片段即可无需动模型分毫。LLM的答案也有了可靠的依据大大减少了幻觉。过去一年从LangChain、LlamaIndex这类框架的爆火到Dify、Coze等低代码平台对RAG工作流的深度集成再到“Agentic RAG”、“Graph RAG”等进阶概念的提出都证明了RAG已成为LLM落地应用尤其是企业级知识问答、客服、内容生成等场景的事实标准技术路径。接下来我们就抛开概念深入这套系统的每一个齿轮看看如何从零搭建一个健壮、可用的RAG系统。2. RAG系统的核心架构拆解不止是“向量搜索LLM”很多人初识RAG会把它简单理解为“向量数据库 LLM”。这个理解没错但过于简化就像一个说汽车是“轮子沙发”一样。一个能投入生产环境、应对复杂查询的RAG系统其内部是一个精密的流水线。我们可以将其核心架构分解为四个关键阶段我习惯称之为“切、存、找、答”。2.1 知识切片把“书本”拆成“便签”你的知识源可能是一本几百页的PDF产品手册、一个满是Markdown的技术Wiki或者一堆杂乱的会议记录。第一步就是把这些非结构化的“书本”处理成LLM和检索系统能高效处理的“便签”即文本片段。这个过程叫做文本分割或分块。这里最大的误区是认为“切得越碎越好”。实际上分块策略是RAG效果的第一个决定性因素。分块太小会丢失上下文信息。比如“销售额同比增长了15%”这句话如果不知道是“哪个产品”、“哪个季度”它就是一句废话。分块太大又会引入无关噪声降低检索精度并且可能超出LLM的上下文窗口限制。常见的分块策略与选择逻辑固定大小重叠分块这是最基础、最常用的方法。比如设定每个块500个字符块与块之间重叠50个字符。这能保证信息的连续性适合通用文档。在LangChain中你可以用RecursiveCharacterTextSplitter轻松实现。from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, length_functionlen, separators[\n\n, \n, , ] # 按段落、换行、空格优先分割 ) chunks text_splitter.split_text(your_document_text)为什么选择重叠为了避免一个完整的句子或概念被硬生生从中间切断。重叠部分充当了“缓冲区”确保关键信息能完整地出现在至少一个块中。基于语义的分块更高级的策略。它不仅仅看字符长度而是试图在语义完整的边界处进行分割比如在段落、章节标题、或者句子结束的地方。这需要利用NLP模型进行句子边界检测。LlamaIndex中的SentenceSplitter就属于此类。什么时候用当你处理结构清晰、段落分明的文档如论文、报告时语义分块能更好地保留原文的叙事逻辑。智能分块与分层索引这是应对复杂查询的利器。除了基础分块还可以同时创建不同粒度的索引。例如小颗粒度块如单个句子或小节用于精准匹配事实型问题“某产品的定价是多少”。中颗粒度块如完整段落用于需要一定上下文的理解型问题“解释一下某功能的工作原理”。大颗粒度块如整个章节或文档用于需要全局视野的总结型问题“概括一下这份白皮书的核心观点”。 在查询时系统可以并行搜索不同层次的索引或者先粗筛再精查。这就是“多路召回”思想的体现。实操心得没有放之四海而皆准的分块规则。你必须根据你的数据形态和查询预期进行调优。一个实用的方法是抽取一部分典型问题用不同的分块参数进行检索测试人工评估返回的“块”是否包含了回答问题所需的完整信息。通常技术文档需要较小的块200-400字符而叙述性内容可以稍大400-800字符。重叠比例一般在10%-20%之间。2.2 向量化与存储让计算机“理解”文本含义文本被切分成块后需要转换成计算机能“理解”和“比较”的形式这就是向量化。通过嵌入模型我们将一段文本映射为一个高维空间中的点即向量。语义相近的文本其向量在空间中的距离也更近。嵌入模型的选择是关键通用vs领域专用像OpenAI的text-embedding-ada-002Cohere的嵌入模型或开源的BGE、E5系列都是优秀的通用模型。但如果你的领域非常垂直如生物医学、法律使用在该领域语料上微调过的嵌入模型效果会有显著提升。维度常见的有384维、768维、1024维等。更高的维度通常能承载更多信息但也会增加计算和存储开销。对于大多数应用768维的模型是一个很好的平衡点。存储这些向量的数据库就是向量数据库。市面上选择很多Pinecone、Weaviate、Qdrant、Milvus、Chroma轻量级等。它们都提供了高效的相似性搜索能力。这里有一个至关重要的细节常被忽略元数据存储。除了向量本身一定要把文本块的元数据一并存储。元数据至少包括原始文本内容、来源文档ID、在文档中的位置页码、章节。更完善的还可以包括文档类型、更新时间、作者等。为什么这很重要当检索系统返回一个相关片段时你不仅需要它的内容还需要知道它来自哪里以便进行后续的引用溯源、置信度评估或者在重排序阶段利用元数据进行过滤例如优先考虑更新时间更近的文档。2.3 检索与召回从“大海”里精准“捞针”当用户提问“如何重置产品A的密码”时检索阶段的目标是从向量库中找出与这个问题最相关的几个文本块。基础检索余弦相似度搜索最直接的方式是将用户问题也向量化然后计算它与库中所有向量之间的余弦相似度返回相似度最高的K个块比如top-5。这是RAG的基线方法。但为什么光有向量搜索不够—— 多路召回策略单一向量搜索的局限性在于它完全依赖于嵌入模型对语义的理解。如果用户问题中的关键词和文档中的表述不一致例如用户说“死机”文档里写“系统无响应”或者问题包含多个子意图简单的向量搜索可能会漏掉关键信息。因此工业级RAG系统会引入多路召回。常见的召回路径包括语义召回主路基于向量相似度搜索。关键词召回辅路使用BM25、TF-IDF等传统全文检索算法。它对精确匹配、术语、缩写非常有效是对语义召回的良好补充。元数据过滤召回辅路例如用户可能指定“只要2024年的文档”或者“只看产品A的说明书”。这需要在检索前或检索后利用存储的元数据进行过滤。系统会并行执行这几路召回各自得到一个候选列表最后将结果合并。合并时可能需要去重并按一定的规则如加权分数进行初步排序。2.4 重排序给“候选人”排座次多路召回合并后可能会得到10-20个甚至更多的候选文本块。直接把这些全部扔给LLM是不明智的一来成本高输入越长API调用越贵二来噪声多可能干扰LLM的判断。重排序阶段的任务就是用一个更精细、但通常也更耗资源的模型对这几十个候选块进行重新打分和排序筛选出最相关、最优质的3-5个块作为最终提供给LLM的“证据”。为什么需要专门的重排序模型因为向量搜索和关键词搜索的打分机制相对粗糙。重排序模型如Cohere的rerank模型或开源的bge-reranker是一个经过训练的“裁判”它专门判断“给定一个问题和一段文本这段文本对回答这个问题的相关性有多高”。它能够理解更复杂的逻辑关系比如因果关系、对比关系而不仅仅是表面语义的相似。重排序的典型工作流将用户问题和每一个候选文本块拼接起来输入到重排序模型。模型为每个(问题文本块)对输出一个相关性分数。根据这个分数对所有候选块进行降序排列。选取Top-N个块作为最终上下文。实操建议对于精度要求极高的场景如法律、医疗问答重排序是必不可少的环节。虽然它增加了延迟和成本但能显著提升最终答案的准确率。你可以将其视为在“召回”和“生成”之间加装的一道“质量检测关卡”。3. 提示工程与生成教会LLM“看资料答题”现在我们有了精准检索到的、经过重排序筛选的几段关键上下文。下一步就是如何将这些上下文和用户问题一起“喂”给LLM并引导它生成一个基于上下文的可靠答案。这完全依赖于提示词工程。一个糟糕的提示词即使给了黄金般的上下文LLM也可能视而不见继续胡编乱造。一个优秀的提示词则能严格约束LLM的行为。3.1 构建基础提示词模板你的提示词应该是一个结构清晰的模板。以下是一个经过实战检验的强效模板你是一个专业的问答助手。请严格根据提供的“参考上下文”来回答问题。 如果答案不在上下文中请直接说“根据提供的资料我无法回答这个问题”。不要编造任何信息。 参考上下文{context}用户问题{question} 请基于以上上下文给出准确、简洁的答案。并在答案结尾以“来源[文档名]”的格式注明答案所依据的上下文来源。这个模板的设计逻辑角色设定明确LLM的身份使其行为更专业、更聚焦。核心指令“严格根据...回答问题”和“如果答案不在...请直接说...”这是对抗幻觉最有力的两道指令。必须清晰、强硬。上下文格式化使用反引号或明确标记将上下文包裹起来使其在提示词中视觉上独立帮助LLM区分指令和材料。引用要求要求注明来源。这不仅能增加答案的可信度更重要的是它能“强迫”LLM去关联上下文中的具体信息。如果它无法找到明确的来源就很难编造出一个带引用的答案从而更可能触发“无法回答”的指令。3.2 进阶技巧思维链与少样本示例对于复杂问题可以引入思维链来提升LLM的推理质量。例如在提示词中要求LLM分步思考...前述角色和指令... 请按以下步骤思考 1. 首先从上下文中找出与问题直接相关的所有事实。 2. 然后分析这些事实之间的逻辑关系。 3. 最后综合这些信息组织成连贯的答案。 ...另一种强大的方法是少样本示例。在提示词中提供一两个“问题-上下文-答案”的示例让LLM通过模仿来学习你期望的回答格式和严谨程度。这对于格式化输出如JSON或特定风格的答案尤其有效。3.3 生成后的校验与护栏即使提示词写得再好也不能100%信任LLM的输出。因此在答案返回给用户之前建议增加一个校验层。答案相关性校验判断生成的答案是否真的回答了原始问题。可以用一个简单的分类模型或另一个LLM调用来实现。引用真实性校验检查答案中声称的引用是否真的出现在提供的上下文中。可以做一个字符串匹配或模糊匹配。幻觉检测使用专门的幻觉检测模型或规则扫描答案中是否存在上下文未提及的实体或事实断言。这些校验可以作为安全护栏一旦检测到问题可以触发重试、返回保守答案“我无法确认”或转交人工处理。4. 超越基础应对复杂场景的进阶RAG模式基础的RAG管道解决了“有据可查”的问题但在面对复杂、多跳查询时仍可能力不从心。例如“我们部门去年利润率最高的产品是什么”这个问题可能需要先检索“部门产品列表”再检索“各产品年度财务报告”最后进行对比计算。这就需要更高级的RAG模式。4.1 Agentic RAG让RAG拥有“思考”和“执行”能力Agentic RAG的核心思想是引入智能体的概念。它不再是一次性的“检索-生成”而是一个循环迭代的过程规划智能体解析复杂问题将其拆解成一系列可执行的子问题或步骤。执行针对每个子问题调用相应的工具如RAG检索、计算器、代码解释器、API查询来获取信息。观察收集工具执行的结果。反思与迭代判断当前信息是否足以回答原问题。如果不能则规划下一步行动例如提出一个新的、更具体的问题进行检索直到满足条件或达到最大迭代次数。最终生成综合所有步骤获得的信息生成最终答案。LangGraph或Dify Workflow这类工具正是为了编排这种多步骤、有状态的智能体工作流而生。它们让构建一个能自动完成“检索-分析-决策-再检索”的智能问答系统成为可能。4.2 Graph RAG利用知识图谱捕捉深层关系当你的知识库中实体和关系非常丰富时例如人物、地点、事件、产品之间的复杂关联传统的基于文本块的RAG可能无法有效捕捉这些结构化关系。Graph RAG将知识图谱与RAG结合。其流程通常是从文档中提取实体和关系构建或更新一个知识图谱。当用户提问时首先在知识图谱上进行查询或推理。例如通过图谱可以轻松找到“所有由某位工程师负责的项目”或者“与某个技术栈相关的所有产品”。将图谱查询结果可能是一组实体或关系路径作为“线索”再去向量库中检索与之相关的详细文本描述。将图谱提供的结构化关系和文本提供的详细描述结合起来生成答案。Graph RAG特别适合需要深度关系推理、溯源和探索式问答的场景。4.3 查询转换与扩展让问题变得更“好搜”用户的提问方式往往不是最优的检索查询。查询转换旨在优化用户问题提升检索效果。查询重写将口语化、冗长的问题改写成简洁、关键信息突出的陈述句。例如“我电脑老是卡住不动了咋办” - “系统无响应故障排查”。查询扩展生成原问题的同义词或相关问题用于多路检索。例如针对“LLM训练成本”可以扩展出“大语言模型计算开销”、“Transformer模型训练费用”等。假设性文档嵌入这是一种更“主动”的技术。它先让LLM基于问题“假设”一个可能包含答案的理想文档然后用这个“假设文档”的向量去进行检索。这相当于让LLM先帮我们“想象”一下答案可能长什么样再用这个想象去匹配真实文档。5. RAG系统的评估、监控与持续迭代搭建完RAG系统只是开始如何评估其好坏并让它越用越好才是真正的挑战。5.1 如何评估RAG效果不能只靠人工抽查。需要建立一套量化的评估体系通常包括检索相关度检索到的上下文与问题的相关程度。可以用人工标注0/1分也可以用重排序模型的分数作为代理指标。答案忠实度生成的答案是否严格基于提供的上下文没有增加未提及的信息幻觉。这是评估抗幻觉能力的核心指标。答案相关性生成的答案是否直接回答了问题。答案有用性综合性的主观评分评估答案的整体质量和帮助程度。可以利用像RAGAS、TruLens这样的开源评估框架它们提供了这些指标的自动化计算方法虽然部分仍依赖LLM进行评估有一定成本。5.2 核心监控指标在生产环境中必须监控以下关键指标延迟从用户提问到收到答案的总时间。区分检索延迟和生成延迟。消耗Token使用量、API调用成本。检索质量平均每个问题检索到的文本块数量、向量搜索的相似度分数分布。用户反馈点赞/点踩率、人工审核中发现幻觉的比例。失败率请求超时、模型调用失败的比例。5.3 持续迭代的闭环RAG系统是一个活系统需要持续喂养数据和优化。数据闭环将用户与系统的交互日志问题、检索到的上下文、生成的答案、用户反馈收集起来。特别是那些被用户点“踩”或人工复核发现问题的案例是宝贵的负样本。问题归因分析当答案出错时要定位是哪个环节出了问题。是检索没找到相关资料还是检索到了但排序不对没进入前几名或者是LLM无视了上下文自己编的不同的原因对应不同的优化策略。定向优化如果是检索问题可以调整分块策略、尝试不同的嵌入模型、引入或优化重排序模型、增加召回路径。如果是生成问题可以优化提示词模板、增加少样本示例、尝试不同LLM或调整生成参数如温度。如果是知识缺失那就需要补充和更新知识库文档。建立一个基于监控数据和用户反馈的持续迭代流程是RAG系统保持生命力和准确度的唯一途径。从我自己的多个RAG项目实战来看最大的教训就是RAG没有银弹参数。网上那些“最佳分块大小1024”之类的建议都只是起点。真正有效的系统一定是经过对自身业务数据、用户问题、效果指标的反复测量、分析和调优后打磨出来的。它更像一门工程实验艺术而非简单的配置组装。希望这份完全指南能帮你避开初期那些显而易见的坑更高效地踏上让LLM“言之有据”的实践之路。
