1. 从“一本正经地胡说八道”到“先查资料再发言”RAG的诞生逻辑如果你用过ChatGPT、文心一言这类大语言模型大概率遇到过一种让人哭笑不得又有点后怕的情况你问它一个非常具体、甚至有点冷门的问题它不仅能立刻给你一个答案而且这个答案看起来逻辑清晰、用词专业充满了自信。但只要你稍微懂点行或者去查证一下就会发现它说的内容里关键事实、数据、甚至人名都是它自己“编”出来的。这种现象在AI圈里有个专门的名字叫“幻觉”或“胡编乱造”。这背后的原因并不复杂。LLM的本质是一个基于海量文本训练出来的概率模型它的核心能力是“根据上文预测下一个最可能的词是什么”。它就像一个博览群书、记忆力超群但缺乏“事实核查”本能的天才学生。当你问它“2023年诺贝尔物理学奖得主是谁”时它可能会从训练数据中“回忆”起相关的片段并给出正确答案。但当你问它“我们公司内部项目‘天枢’系统的核心架构图是什么样的”这种它从未“见过”的信息时它并不会说“我不知道”而是会基于它对“系统架构图”这个概念的普遍理解结合它学到的技术术语生成一个看起来合理但实际上完全错误的描述。因为它被训练的目标是“生成流畅、合理的文本”而不是“只输出有确凿证据支持的事实”。“幻觉”问题在要求事实准确性的场景下是致命的比如智能客服回答产品参数、法律助手引用法条、医疗助手提供诊断建议或者企业内部知识库问答。我们不能接受一个AI助手用自信的口吻告诉我们错误的信息。那么如何让这个“天才学生”学会在回答前先“翻书查资料”呢这就是检索增强生成技术要解决的核心问题。RAG不是一个单一的算法而是一套工程框架和思想。它的核心理念非常直观在LLM生成最终答案之前先从一个外部的、可信的知识库中检索出与问题最相关的文档片段然后将这些片段作为“参考资料”和原始问题一起交给LLM指令它“基于以下资料回答问题”。这样一来LLM的“知识来源”就从其固有的、可能过时或不完整的参数化记忆变成了实时、可控、高质量的外部知识源。它的角色从一个“全知全能的讲述者”转变为一个“拥有最新参考资料的分析师”从而极大地约束了其胡编乱造的倾向提升了回答的事实准确性。2. RAG系统核心架构拆解从问题到可信答案的流水线一个完整的、可用于生产环境的RAG系统远不止是“向量搜索LLM”这么简单。它是一个精心设计的流水线每个环节都关乎最终答案的可靠性与可用性。我们可以将其拆解为几个核心阶段。2.1 知识库的构建与预处理给资料库“贴标签”这是所有RAG系统的地基也是最容易被低估但至关重要的环节。你的知识库质量直接决定了系统能力的上限。这个过程主要包括两个步骤知识切片和向量化。知识切片的目标是将原始的文档如PDF、Word、网页、数据库记录切割成适合检索的“片段”。这里最大的误区是认为“切得越细越好”。实际上切片需要平衡“检索精度”和“信息完整性”。检索精度如果片段过长比如一整章里面包含的信息太杂即使被检索出来LLM也可能无法从中精准定位答案或者被无关信息干扰。信息完整性如果片段过短比如一两句话可能无法提供足够的上下文来理解一个概念或回答一个需要多句话推理的问题。常见的切片策略包括固定长度重叠切片这是最基础的方法。设定一个固定的字符数如500字和重叠长度如50字。优点是简单但可能在不该断开的地方如表格中间、句子中间切断语义。基于语义的切片利用自然语言处理技术在段落、标题等自然边界进行切割。这能更好地保持语义完整性但对文档结构要求较高。递归切片先按大标题切分再对每个部分进行更细粒度的切片。这种方法层次清晰适合结构规整的文档。实操心得在实际项目中我通常采用“递归语义”的混合策略。例如对于技术文档先按一级、二级标题切分然后在每个小节内确保每个切片是一个完整的段落或一组逻辑紧密的句子。同时为每个切片添加元数据至关重要比如来源文件、章节标题、页码、时间戳等。这些元数据在后续的检索结果呈现和LLM生成引用时非常有用。向量化是将文本切片转化为计算机可以理解和比较的数学形式——即向量一组数字。这个过程由一个嵌入模型来完成。嵌入模型会将语义相近的文本映射到向量空间中相近的位置。例如“狗”和“犬”的向量距离会很近而“狗”和“电脑”的向量距离则较远。选择嵌入模型时需要考虑语言是否有针对中文优化的模型如BGE、M3E系列领域通用模型如OpenAI的text-embedding-ada-002还是专业领域模型如针对生物医学的模型维度向量的长度通常维度越高表征能力越强但存储和计算成本也越高。上下文长度模型单次能处理的最大文本长度。生成向量后它们会被存入一个专门的数据库——向量数据库中如Pinecone、Weaviate、Qdrant、Milvus或Chroma。这些数据库的核心能力是进行近似最近邻搜索即快速找到与问题向量最相似的若干个知识片段向量。2.2 检索与召回在资料库中“大海捞针”当用户提出一个问题时系统首先将这个问题用同样的嵌入模型转化为向量然后在向量数据库中进行搜索找出最相似的N个知识片段。这个过程称为“召回”。但单一的向量搜索也称为“稠密检索”可能存在局限性词汇不匹配用户问“如何重启服务”知识库中用的是“服务重启步骤”。虽然语义高度相关但字面重叠少单纯基于关键词的搜索可能失效而向量检索可以解决。语义漂移用户问“苹果公司的市值”向量检索可能召回关于“苹果这种水果的营养价值”的片段因为“苹果”这个词的向量表征在通用语料中可能更靠近水果。精确术语检索对于产品型号、代码错误号、法律条款编号等需要精确匹配的查询向量检索可能不如传统的关键词检索如BM25算法可靠。因此工业级的RAG系统通常会采用“混合检索”策略稀疏检索使用如BM25等算法进行关键词匹配保证精确术语的召回。稠密检索使用向量搜索进行语义匹配保证语义相似内容的召回。融合将两种检索方式的结果合并并去重。简单的融合可以是取并集更复杂的则会对结果进行加权打分。2.3 重排序给召回结果“排座次”通过混合检索我们可能得到了20个甚至更多的相关片段。但并非所有片段都对回答问题有同等价值。有些可能只是略微相关有些可能包含重复信息有些可能虽然相关但来自权威性较低的来源。重排序阶段的任务就是对这个初步的召回列表进行精细化排序筛选出最相关、最权威、最精炼的Top-K个片段作为最终送给LLM的“参考资料”。重排序器本身通常是一个小型但高效的神经网络如Cross-Encoder它会对“查询-文档”对进行更精细化的相关性打分这个打分比单纯的向量余弦相似度或BM25分数更准确。踩坑实录在早期的一个项目中我们忽略了重排序直接将向量搜索的前5个结果扔给LLM。结果发现当用户问题比较模糊时LLM经常被一个相关度排第三但内容冗长、包含无关细节的片段带偏生成跑题的答案。引入重排序模型后我们强制让最相关、最简洁的片段排在前面答案的准确性和聚焦度立刻得到了显著提升。重排序模型虽然增加了少量计算开销但对于提升答案质量是性价比极高的投入。2.4 生成与引用让LLM“有据可依”这是流水线的最后一环也是直接面向用户的环节。我们将用户原始问题Query和经过检索、重排序后得到的最相关的几个知识片段Context按照一定的提示模板组合起来形成最终的提示词发送给LLM。一个精心设计的提示模板至关重要。一个糟糕的模板可能让LLM忽略你提供的资料继续“自由发挥”。一个基础的模板可能是这样的请严格根据以下提供的资料来回答问题。如果资料中没有足够的信息来回答问题请直接说“根据现有资料无法回答该问题”。 资料 {context_1} {context_2} ... {context_k} 问题{query} 基于以上资料请回答更高级的模板会加入角色设定、输出格式要求如“用列表形式回答”、“引用资料中的原话”以及防止幻觉的强力约束。引用是生产级RAG的必备功能。LLM在生成答案时应该能够明确指出答案的哪一部分来源于哪个知识片段通过元数据如文件名、页码。这不仅是可解释性的要求也能让用户快速追溯到原始资料进行核实极大增强信任感。3. 超越基础RAG应对复杂场景的进阶架构基础的RAG流程在处理简单事实性问答时表现良好但当面对复杂、多跳推理或需要综合多个文档信息的问题时就显得力不从心。为此业界发展出了多种进阶的RAG架构。3.1 智能体化RAG让检索过程“学会思考”传统的RAG是“一次性检索一次性生成”。而Agentic RAG引入了智能体的概念让系统能够根据LLM的“思考”来决定是否需要检索、检索什么、以及如何迭代。其工作流程更像一个研究员规划LLM先分析用户问题将其拆解成几个子问题或确定需要检索的关键信息点。执行根据规划系统执行一次或多次检索可能是并行检索多个子问题。反思LLM评估检索到的资料是否足够回答用户问题。如果不够则调整检索策略如改写查询词、扩大检索范围并再次检索。生成在认为资料充足后综合所有检索结果生成最终答案。例如用户问“我们公司去年在华东区和华南区的销售额对比如何”。Agentic RAG可能会先规划需要检索“去年华东区销售额报告”和“去年华南区销售额报告”。执行检索后如果只找到分季度的报告它可能会反思并规划新的子动作“计算华东区各季度销售额之和”、“计算华南区各季度销售额之和”然后再进行生成。这个过程使得RAG系统能够处理更复杂的查询。3.2 图增强RAG利用知识间的“关系网”很多知识并非孤立的文档片段而是相互关联的实体网络。例如人物、地点、事件、概念之间的关系。Graph RAG在传统向量知识库的基础上额外构建了一个知识图谱。当用户查询“爱因斯坦在伯尔尼专利局工作时提出了什么理论”时系统依然会进行向量检索召回关于“爱因斯坦”、“伯尔尼专利局”、“相对论”的文档片段。同时系统会从知识图谱中查询“爱因斯坦”这个实体找到其“工作地点”关系指向“伯尔尼专利局”其“提出”关系指向“狭义相对论”和“广义相对论”。将图谱查询到的结构化关系信息与向量检索到的非结构化文本片段一起作为上下文送给LLM。图谱提供的精确关系路径能极大地帮助LLM进行准确、连贯的多跳推理避免在纯文本中模糊匹配导致的错误。3.3 递归与迭代式RAG层层递进的“追问”对于一些答案隐含在深层上下文中的问题可以采用递归检索。例如用户问“文档中提到的XXX项目的最终验收标准是什么”。第一轮检索可能只召回提到了“XXX项目”的概述性段落。这个段落里可能说“验收标准详见附录A”。系统可以自动以“附录A 验收标准”为新的查询发起第二轮检索从而定位到最精确的信息。另一种思路是查询改写/扩展。用户的原始查询可能不够优化。系统可以先用LLM对查询进行改写或扩展生成多个同义或相关的查询词然后并行检索最后合并结果。例如将“怎么重启电脑”扩展为“如何重启计算机”、“系统重启步骤”、“电脑重新启动方法”。4. RAG项目实战从零搭建一个简易知识库问答系统理论说了这么多我们动手搭建一个最核心的RAG流程。这里我们使用LangChain一个流行的LLM应用框架和Chroma一个轻量级向量数据库来演示。4.1 环境准备与依赖安装首先确保你的Python环境建议3.8以上然后安装核心库。pip install langchain langchain-community langchain-chroma pip install sentence-transformers # 用于本地嵌入模型 pip install pypdf # 用于读取PDF文档 # 如果你使用OpenAI的LLM和嵌入还需要 # pip install openai4.2 文档加载与文本切片我们假设有一个名为company_handbook.pdf的公司手册PDF文件。from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加载文档 loader PyPDFLoader(./company_handbook.pdf) documents loader.load() # 2. 文本切片 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个切片大约500字符 chunk_overlap50, # 切片间重叠50字符保持上下文连贯 length_functionlen, separators[\n\n, \n, 。, , , , , , ] # 中文优先分隔符 ) chunks text_splitter.split_documents(documents) print(f原始文档被切分为 {len(chunks)} 个片段。)4.3 向量化与存储我们使用一个开源的、针对中文优化的嵌入模型BAAI/bge-small-zh-v1.5并将向量存储到本地的Chroma数据库中。from langchain_chroma import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings # 1. 初始化嵌入模型 embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-small-zh-v1.5, model_kwargs{device: cpu}, # 使用GPU可改为 cuda encode_kwargs{normalize_embeddings: True} # 归一化提升检索效果 ) # 2. 创建向量数据库并存储 # persist_directory 指定向量数据库持久化到本地目录 vectorstore Chroma.from_documents( documentschunks, embeddingembedding_model, persist_directory./chroma_db_company_handbook ) vectorstore.persist() # 持久化保存 print(知识库向量化并存储完成。)4.4 构建检索链与问答现在我们创建一个检索器并将其与LLM这里以OpenAI GPT为例也可替换为其他本地模型组合成一条问答链。from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI import os # 设置你的OpenAI API Key (请替换为你的真实Key或使用其他LLM) os.environ[OPENAI_API_KEY] your-api-key-here # 1. 从已保存的数据库加载向量库 vectorstore Chroma( persist_directory./chroma_db_company_handbook, embedding_functionembedding_model ) # 2. 将向量库转换为检索器可以设置返回的片段数量 retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 返回最相关的4个片段 # 3. 初始化LLM llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # temperature0 使输出更确定 # 4. 创建检索增强生成链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 将所有检索到的上下文“塞”进提示词 retrieverretriever, return_source_documentsTrue, # 返回源文档用于引用 chain_type_kwargs{ prompt: PROMPT # 这里可以传入一个自定义的提示模板下文会定义 } ) # 5. 进行问答 query 我们公司的年假制度是怎样的 result qa_chain.invoke({query: query}) print(问题, query) print(答案, result[result]) print(\n--- 引用来源 ---) for i, doc in enumerate(result[source_documents]): print(f[{i1}] 片段内容前200字: {doc.page_content[:200]}...) print(f 来源: {doc.metadata.get(source, N/A)}, 页码: {doc.metadata.get(page, N/A)}\n)4.5 设计一个有效的提示模板上面代码中的PROMPT是一个关键变量。一个好的提示模板能显著提升效果。我们可以这样定义from langchain.prompts import PromptTemplate template 你是一个专业的公司知识库助手。请严格根据以下提供的上下文信息来回答问题。如果上下文中的信息不足以回答问题请直接说“根据提供的资料我无法回答这个问题”。不要编造任何信息。 上下文信息 {context} 问题{question} 请基于上下文信息给出准确、简洁的回答。如果适用请在回答中指明信息来源于上下文的哪一部分。 回答 PROMPT PromptTemplate( input_variables[context, question], templatetemplate, )将这个PROMPT变量赋值给上面RetrievalQA中的chain_type_kwargs即可。5. RAG系统评测与常见“坑点”规避搭建出RAG系统只是第一步如何评估其好坏并在实际运营中持续优化才是更大的挑战。5.1 如何评测一个RAG系统不能只靠“感觉”需要建立量化指标。评测通常分为“检索”和“生成”两个阶段。检索阶段评测命中率对于一组有标准答案的问题系统检索到的Top-K个片段中至少包含正确答案片段的比例。这衡量了检索的召回能力。平均排序倒数正确答案片段在检索结果列表中的平均排名的倒数。排名越靠前得分越高。这衡量了检索的精度。生成阶段评测事实一致性生成的答案与检索到的上下文事实是否一致。这是对抗“幻觉”的核心指标。可以通过让另一个LLM作为裁判来判断或使用专门的评估模型。答案相关性生成的答案是否直接回答了用户的问题是否跑题。引用准确性答案中声称的引用是否真实存在于提供的上下文中且支持所述观点。端到端评测 直接使用人工评估设计一批测试问题由真人从“准确性”、“完整性”、“流畅性”、“有用性”等多个维度打分。这是最可靠但成本最高的方法。5.2 实战中高频“坑点”与解决方案检索不到正确答案可能原因切片不合理过大或过碎、嵌入模型不匹配如用英文模型处理中文、查询词与文档表述差异大。解决方案优化切片策略尝试语义切片更换或微调嵌入模型实施查询改写/扩展利用LLM将用户问题改写成更接近文档风格的查询。检索到正确答案但LLM不用可能原因提示词指令不够强检索到的无关噪声信息太多干扰了LLMLLM的“温度”参数过高导致创造性过强。解决方案强化提示词使用“必须基于”、“禁止编造”等强约束性词语引入重排序确保最相关的片段排在前面减少temperature参数值如设为0尝试在提示词中让LLM先“找出相关句子”再“综合回答”。回答正确但未引用或错误引用可能原因基础RAG链如stuff方式将所有上下文拼接LLM难以区分具体来源。解决方案使用更高级的链类型如map_reduce或refine它们能更好地处理多文档引用。或者在生成后增加一个“引用追溯”步骤让另一个LLM根据答案和上下文反推引用来源。处理长文档或复杂问题时效果差可能原因一次性输入LLM的上下文长度有限上下文窗口限制导致信息丢失。解决方案采用递归检索或Agentic RAG将复杂问题分解对于长文档在切片时保留层次结构信息元数据检索时可以考虑先检索高层级概述再定位细节。知识库更新滞后问题公司制度更新了但RAG系统还在用旧资料回答。解决方案建立知识库的增量更新机制。当源文档更新时能自动或手动触发对受影响部分的重新切片、向量化并更新向量数据库中的对应记录这是一个需要精心设计的工程问题。RAG技术正在快速发展从基础的检索生成演进到智能体化、图增强、多模态等复杂形态。它的核心价值在于以一种相对低成本、高可控的方式将LLM的通用语言能力与特定领域的精准知识结合起来打造出真正可靠、实用的AI应用。理解其核心架构亲手搭建一个流程再深入思考其局限性与优化方向是掌握这项技术的最佳路径。 RAG技术解析：从向量检索到智能问答，构建可信AI知识库
1. 从“一本正经地胡说八道”到“先查资料再发言”RAG的诞生逻辑如果你用过ChatGPT、文心一言这类大语言模型大概率遇到过一种让人哭笑不得又有点后怕的情况你问它一个非常具体、甚至有点冷门的问题它不仅能立刻给你一个答案而且这个答案看起来逻辑清晰、用词专业充满了自信。但只要你稍微懂点行或者去查证一下就会发现它说的内容里关键事实、数据、甚至人名都是它自己“编”出来的。这种现象在AI圈里有个专门的名字叫“幻觉”或“胡编乱造”。这背后的原因并不复杂。LLM的本质是一个基于海量文本训练出来的概率模型它的核心能力是“根据上文预测下一个最可能的词是什么”。它就像一个博览群书、记忆力超群但缺乏“事实核查”本能的天才学生。当你问它“2023年诺贝尔物理学奖得主是谁”时它可能会从训练数据中“回忆”起相关的片段并给出正确答案。但当你问它“我们公司内部项目‘天枢’系统的核心架构图是什么样的”这种它从未“见过”的信息时它并不会说“我不知道”而是会基于它对“系统架构图”这个概念的普遍理解结合它学到的技术术语生成一个看起来合理但实际上完全错误的描述。因为它被训练的目标是“生成流畅、合理的文本”而不是“只输出有确凿证据支持的事实”。“幻觉”问题在要求事实准确性的场景下是致命的比如智能客服回答产品参数、法律助手引用法条、医疗助手提供诊断建议或者企业内部知识库问答。我们不能接受一个AI助手用自信的口吻告诉我们错误的信息。那么如何让这个“天才学生”学会在回答前先“翻书查资料”呢这就是检索增强生成技术要解决的核心问题。RAG不是一个单一的算法而是一套工程框架和思想。它的核心理念非常直观在LLM生成最终答案之前先从一个外部的、可信的知识库中检索出与问题最相关的文档片段然后将这些片段作为“参考资料”和原始问题一起交给LLM指令它“基于以下资料回答问题”。这样一来LLM的“知识来源”就从其固有的、可能过时或不完整的参数化记忆变成了实时、可控、高质量的外部知识源。它的角色从一个“全知全能的讲述者”转变为一个“拥有最新参考资料的分析师”从而极大地约束了其胡编乱造的倾向提升了回答的事实准确性。2. RAG系统核心架构拆解从问题到可信答案的流水线一个完整的、可用于生产环境的RAG系统远不止是“向量搜索LLM”这么简单。它是一个精心设计的流水线每个环节都关乎最终答案的可靠性与可用性。我们可以将其拆解为几个核心阶段。2.1 知识库的构建与预处理给资料库“贴标签”这是所有RAG系统的地基也是最容易被低估但至关重要的环节。你的知识库质量直接决定了系统能力的上限。这个过程主要包括两个步骤知识切片和向量化。知识切片的目标是将原始的文档如PDF、Word、网页、数据库记录切割成适合检索的“片段”。这里最大的误区是认为“切得越细越好”。实际上切片需要平衡“检索精度”和“信息完整性”。检索精度如果片段过长比如一整章里面包含的信息太杂即使被检索出来LLM也可能无法从中精准定位答案或者被无关信息干扰。信息完整性如果片段过短比如一两句话可能无法提供足够的上下文来理解一个概念或回答一个需要多句话推理的问题。常见的切片策略包括固定长度重叠切片这是最基础的方法。设定一个固定的字符数如500字和重叠长度如50字。优点是简单但可能在不该断开的地方如表格中间、句子中间切断语义。基于语义的切片利用自然语言处理技术在段落、标题等自然边界进行切割。这能更好地保持语义完整性但对文档结构要求较高。递归切片先按大标题切分再对每个部分进行更细粒度的切片。这种方法层次清晰适合结构规整的文档。实操心得在实际项目中我通常采用“递归语义”的混合策略。例如对于技术文档先按一级、二级标题切分然后在每个小节内确保每个切片是一个完整的段落或一组逻辑紧密的句子。同时为每个切片添加元数据至关重要比如来源文件、章节标题、页码、时间戳等。这些元数据在后续的检索结果呈现和LLM生成引用时非常有用。向量化是将文本切片转化为计算机可以理解和比较的数学形式——即向量一组数字。这个过程由一个嵌入模型来完成。嵌入模型会将语义相近的文本映射到向量空间中相近的位置。例如“狗”和“犬”的向量距离会很近而“狗”和“电脑”的向量距离则较远。选择嵌入模型时需要考虑语言是否有针对中文优化的模型如BGE、M3E系列领域通用模型如OpenAI的text-embedding-ada-002还是专业领域模型如针对生物医学的模型维度向量的长度通常维度越高表征能力越强但存储和计算成本也越高。上下文长度模型单次能处理的最大文本长度。生成向量后它们会被存入一个专门的数据库——向量数据库中如Pinecone、Weaviate、Qdrant、Milvus或Chroma。这些数据库的核心能力是进行近似最近邻搜索即快速找到与问题向量最相似的若干个知识片段向量。2.2 检索与召回在资料库中“大海捞针”当用户提出一个问题时系统首先将这个问题用同样的嵌入模型转化为向量然后在向量数据库中进行搜索找出最相似的N个知识片段。这个过程称为“召回”。但单一的向量搜索也称为“稠密检索”可能存在局限性词汇不匹配用户问“如何重启服务”知识库中用的是“服务重启步骤”。虽然语义高度相关但字面重叠少单纯基于关键词的搜索可能失效而向量检索可以解决。语义漂移用户问“苹果公司的市值”向量检索可能召回关于“苹果这种水果的营养价值”的片段因为“苹果”这个词的向量表征在通用语料中可能更靠近水果。精确术语检索对于产品型号、代码错误号、法律条款编号等需要精确匹配的查询向量检索可能不如传统的关键词检索如BM25算法可靠。因此工业级的RAG系统通常会采用“混合检索”策略稀疏检索使用如BM25等算法进行关键词匹配保证精确术语的召回。稠密检索使用向量搜索进行语义匹配保证语义相似内容的召回。融合将两种检索方式的结果合并并去重。简单的融合可以是取并集更复杂的则会对结果进行加权打分。2.3 重排序给召回结果“排座次”通过混合检索我们可能得到了20个甚至更多的相关片段。但并非所有片段都对回答问题有同等价值。有些可能只是略微相关有些可能包含重复信息有些可能虽然相关但来自权威性较低的来源。重排序阶段的任务就是对这个初步的召回列表进行精细化排序筛选出最相关、最权威、最精炼的Top-K个片段作为最终送给LLM的“参考资料”。重排序器本身通常是一个小型但高效的神经网络如Cross-Encoder它会对“查询-文档”对进行更精细化的相关性打分这个打分比单纯的向量余弦相似度或BM25分数更准确。踩坑实录在早期的一个项目中我们忽略了重排序直接将向量搜索的前5个结果扔给LLM。结果发现当用户问题比较模糊时LLM经常被一个相关度排第三但内容冗长、包含无关细节的片段带偏生成跑题的答案。引入重排序模型后我们强制让最相关、最简洁的片段排在前面答案的准确性和聚焦度立刻得到了显著提升。重排序模型虽然增加了少量计算开销但对于提升答案质量是性价比极高的投入。2.4 生成与引用让LLM“有据可依”这是流水线的最后一环也是直接面向用户的环节。我们将用户原始问题Query和经过检索、重排序后得到的最相关的几个知识片段Context按照一定的提示模板组合起来形成最终的提示词发送给LLM。一个精心设计的提示模板至关重要。一个糟糕的模板可能让LLM忽略你提供的资料继续“自由发挥”。一个基础的模板可能是这样的请严格根据以下提供的资料来回答问题。如果资料中没有足够的信息来回答问题请直接说“根据现有资料无法回答该问题”。 资料 {context_1} {context_2} ... {context_k} 问题{query} 基于以上资料请回答更高级的模板会加入角色设定、输出格式要求如“用列表形式回答”、“引用资料中的原话”以及防止幻觉的强力约束。引用是生产级RAG的必备功能。LLM在生成答案时应该能够明确指出答案的哪一部分来源于哪个知识片段通过元数据如文件名、页码。这不仅是可解释性的要求也能让用户快速追溯到原始资料进行核实极大增强信任感。3. 超越基础RAG应对复杂场景的进阶架构基础的RAG流程在处理简单事实性问答时表现良好但当面对复杂、多跳推理或需要综合多个文档信息的问题时就显得力不从心。为此业界发展出了多种进阶的RAG架构。3.1 智能体化RAG让检索过程“学会思考”传统的RAG是“一次性检索一次性生成”。而Agentic RAG引入了智能体的概念让系统能够根据LLM的“思考”来决定是否需要检索、检索什么、以及如何迭代。其工作流程更像一个研究员规划LLM先分析用户问题将其拆解成几个子问题或确定需要检索的关键信息点。执行根据规划系统执行一次或多次检索可能是并行检索多个子问题。反思LLM评估检索到的资料是否足够回答用户问题。如果不够则调整检索策略如改写查询词、扩大检索范围并再次检索。生成在认为资料充足后综合所有检索结果生成最终答案。例如用户问“我们公司去年在华东区和华南区的销售额对比如何”。Agentic RAG可能会先规划需要检索“去年华东区销售额报告”和“去年华南区销售额报告”。执行检索后如果只找到分季度的报告它可能会反思并规划新的子动作“计算华东区各季度销售额之和”、“计算华南区各季度销售额之和”然后再进行生成。这个过程使得RAG系统能够处理更复杂的查询。3.2 图增强RAG利用知识间的“关系网”很多知识并非孤立的文档片段而是相互关联的实体网络。例如人物、地点、事件、概念之间的关系。Graph RAG在传统向量知识库的基础上额外构建了一个知识图谱。当用户查询“爱因斯坦在伯尔尼专利局工作时提出了什么理论”时系统依然会进行向量检索召回关于“爱因斯坦”、“伯尔尼专利局”、“相对论”的文档片段。同时系统会从知识图谱中查询“爱因斯坦”这个实体找到其“工作地点”关系指向“伯尔尼专利局”其“提出”关系指向“狭义相对论”和“广义相对论”。将图谱查询到的结构化关系信息与向量检索到的非结构化文本片段一起作为上下文送给LLM。图谱提供的精确关系路径能极大地帮助LLM进行准确、连贯的多跳推理避免在纯文本中模糊匹配导致的错误。3.3 递归与迭代式RAG层层递进的“追问”对于一些答案隐含在深层上下文中的问题可以采用递归检索。例如用户问“文档中提到的XXX项目的最终验收标准是什么”。第一轮检索可能只召回提到了“XXX项目”的概述性段落。这个段落里可能说“验收标准详见附录A”。系统可以自动以“附录A 验收标准”为新的查询发起第二轮检索从而定位到最精确的信息。另一种思路是查询改写/扩展。用户的原始查询可能不够优化。系统可以先用LLM对查询进行改写或扩展生成多个同义或相关的查询词然后并行检索最后合并结果。例如将“怎么重启电脑”扩展为“如何重启计算机”、“系统重启步骤”、“电脑重新启动方法”。4. RAG项目实战从零搭建一个简易知识库问答系统理论说了这么多我们动手搭建一个最核心的RAG流程。这里我们使用LangChain一个流行的LLM应用框架和Chroma一个轻量级向量数据库来演示。4.1 环境准备与依赖安装首先确保你的Python环境建议3.8以上然后安装核心库。pip install langchain langchain-community langchain-chroma pip install sentence-transformers # 用于本地嵌入模型 pip install pypdf # 用于读取PDF文档 # 如果你使用OpenAI的LLM和嵌入还需要 # pip install openai4.2 文档加载与文本切片我们假设有一个名为company_handbook.pdf的公司手册PDF文件。from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加载文档 loader PyPDFLoader(./company_handbook.pdf) documents loader.load() # 2. 文本切片 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个切片大约500字符 chunk_overlap50, # 切片间重叠50字符保持上下文连贯 length_functionlen, separators[\n\n, \n, 。, , , , , , ] # 中文优先分隔符 ) chunks text_splitter.split_documents(documents) print(f原始文档被切分为 {len(chunks)} 个片段。)4.3 向量化与存储我们使用一个开源的、针对中文优化的嵌入模型BAAI/bge-small-zh-v1.5并将向量存储到本地的Chroma数据库中。from langchain_chroma import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings # 1. 初始化嵌入模型 embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-small-zh-v1.5, model_kwargs{device: cpu}, # 使用GPU可改为 cuda encode_kwargs{normalize_embeddings: True} # 归一化提升检索效果 ) # 2. 创建向量数据库并存储 # persist_directory 指定向量数据库持久化到本地目录 vectorstore Chroma.from_documents( documentschunks, embeddingembedding_model, persist_directory./chroma_db_company_handbook ) vectorstore.persist() # 持久化保存 print(知识库向量化并存储完成。)4.4 构建检索链与问答现在我们创建一个检索器并将其与LLM这里以OpenAI GPT为例也可替换为其他本地模型组合成一条问答链。from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI import os # 设置你的OpenAI API Key (请替换为你的真实Key或使用其他LLM) os.environ[OPENAI_API_KEY] your-api-key-here # 1. 从已保存的数据库加载向量库 vectorstore Chroma( persist_directory./chroma_db_company_handbook, embedding_functionembedding_model ) # 2. 将向量库转换为检索器可以设置返回的片段数量 retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 返回最相关的4个片段 # 3. 初始化LLM llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # temperature0 使输出更确定 # 4. 创建检索增强生成链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 将所有检索到的上下文“塞”进提示词 retrieverretriever, return_source_documentsTrue, # 返回源文档用于引用 chain_type_kwargs{ prompt: PROMPT # 这里可以传入一个自定义的提示模板下文会定义 } ) # 5. 进行问答 query 我们公司的年假制度是怎样的 result qa_chain.invoke({query: query}) print(问题, query) print(答案, result[result]) print(\n--- 引用来源 ---) for i, doc in enumerate(result[source_documents]): print(f[{i1}] 片段内容前200字: {doc.page_content[:200]}...) print(f 来源: {doc.metadata.get(source, N/A)}, 页码: {doc.metadata.get(page, N/A)}\n)4.5 设计一个有效的提示模板上面代码中的PROMPT是一个关键变量。一个好的提示模板能显著提升效果。我们可以这样定义from langchain.prompts import PromptTemplate template 你是一个专业的公司知识库助手。请严格根据以下提供的上下文信息来回答问题。如果上下文中的信息不足以回答问题请直接说“根据提供的资料我无法回答这个问题”。不要编造任何信息。 上下文信息 {context} 问题{question} 请基于上下文信息给出准确、简洁的回答。如果适用请在回答中指明信息来源于上下文的哪一部分。 回答 PROMPT PromptTemplate( input_variables[context, question], templatetemplate, )将这个PROMPT变量赋值给上面RetrievalQA中的chain_type_kwargs即可。5. RAG系统评测与常见“坑点”规避搭建出RAG系统只是第一步如何评估其好坏并在实际运营中持续优化才是更大的挑战。5.1 如何评测一个RAG系统不能只靠“感觉”需要建立量化指标。评测通常分为“检索”和“生成”两个阶段。检索阶段评测命中率对于一组有标准答案的问题系统检索到的Top-K个片段中至少包含正确答案片段的比例。这衡量了检索的召回能力。平均排序倒数正确答案片段在检索结果列表中的平均排名的倒数。排名越靠前得分越高。这衡量了检索的精度。生成阶段评测事实一致性生成的答案与检索到的上下文事实是否一致。这是对抗“幻觉”的核心指标。可以通过让另一个LLM作为裁判来判断或使用专门的评估模型。答案相关性生成的答案是否直接回答了用户的问题是否跑题。引用准确性答案中声称的引用是否真实存在于提供的上下文中且支持所述观点。端到端评测 直接使用人工评估设计一批测试问题由真人从“准确性”、“完整性”、“流畅性”、“有用性”等多个维度打分。这是最可靠但成本最高的方法。5.2 实战中高频“坑点”与解决方案检索不到正确答案可能原因切片不合理过大或过碎、嵌入模型不匹配如用英文模型处理中文、查询词与文档表述差异大。解决方案优化切片策略尝试语义切片更换或微调嵌入模型实施查询改写/扩展利用LLM将用户问题改写成更接近文档风格的查询。检索到正确答案但LLM不用可能原因提示词指令不够强检索到的无关噪声信息太多干扰了LLMLLM的“温度”参数过高导致创造性过强。解决方案强化提示词使用“必须基于”、“禁止编造”等强约束性词语引入重排序确保最相关的片段排在前面减少temperature参数值如设为0尝试在提示词中让LLM先“找出相关句子”再“综合回答”。回答正确但未引用或错误引用可能原因基础RAG链如stuff方式将所有上下文拼接LLM难以区分具体来源。解决方案使用更高级的链类型如map_reduce或refine它们能更好地处理多文档引用。或者在生成后增加一个“引用追溯”步骤让另一个LLM根据答案和上下文反推引用来源。处理长文档或复杂问题时效果差可能原因一次性输入LLM的上下文长度有限上下文窗口限制导致信息丢失。解决方案采用递归检索或Agentic RAG将复杂问题分解对于长文档在切片时保留层次结构信息元数据检索时可以考虑先检索高层级概述再定位细节。知识库更新滞后问题公司制度更新了但RAG系统还在用旧资料回答。解决方案建立知识库的增量更新机制。当源文档更新时能自动或手动触发对受影响部分的重新切片、向量化并更新向量数据库中的对应记录这是一个需要精心设计的工程问题。RAG技术正在快速发展从基础的检索生成演进到智能体化、图增强、多模态等复杂形态。它的核心价值在于以一种相对低成本、高可控的方式将LLM的通用语言能力与特定领域的精准知识结合起来打造出真正可靠、实用的AI应用。理解其核心架构亲手搭建一个流程再深入思考其局限性与优化方向是掌握这项技术的最佳路径。