为什么需要RAG?
⼤型语⾔模型(LLM)虽然在⾃然语⾔处理任务上取得了突破性进展,但其固有的局限性在特定应⽤场景下变得尤为突出。RAG的出现正是为了弥补这些不⾜。
对⽐传统LLM的不⾜:
-
幻觉问题(Hallucination):LLM在生成内容时,有时会”自信地”编造事实或提供不准确的信息,这种现象被称为”幻觉”。例如,当被问及一个其训练数据中不存在或模糊的知识点时,LLM可能不会承认”不知道”,而是生成一个看似合理的虚假答案。RAG通过引入外部知识源,要求LLM的回答必须基于检索到的具体上下文,从而显著约束其自由发挥的空间,大幅减少幻觉的产生。
-
知识更新滞后(Knowledge Cutoff): LLM的知识储备来源于其训练数据集,,一旦训练完成,其知识就被”冻结”在那个时间点。对于日新月异的信息和动态变化的知识,LLM无法自动获取和更新。RAG通过连接外部动态知识库(如实时更新的数据库、新闻源、企业内部文档系统),使得LLM能够接触并利用最新的信息进行回答,克服了知识陈旧的问题。
-
领域知识缺乏 (Lack of Domain-Specific Knowledge): 通用LLM虽然知识面广,但在特定专业领域(如医疗、法律、金融、特定行业技术) 的知识深度和精度往往不足。针对每个细分领域都去训练或微调一个专有LLM成本高昂且不灵活。RAG允许将特定领域的专业知识库作为外部”插件”接入,使通用LLM也能在专业问答中表现出色。这对于构建企业内部知识库问答系统尤为重要。
-
缺乏可解释性和可追溯性 (Lack of Interpretability and Traceability):传统LLM的答案生成过程往往像一个”黑箱”,用户难以理解答案是如何得出的,也无法追溯其信息来源。 RAG生成的答案因为明确依赖于检索到的上下文,所以可以展示这些上下文来源(如具体文档的段落),这极大地增强了答案的可信度、可解释性和可追溯性,方便用户验证和信任。
RAG的优势:
-
提升答案准确性和事实性:通过基于检索到的相关、准确的上下文信息生成答案,减少了LLM凭空捏造成分的可能性。
-
引入最新知识:可以轻松接入并利用实时更新的外部数据源,确保生成内容的时效性。
-
增强可解释性与可追溯性:能够清晰展示答案所依据的来源文档或数据片段,便于用户核实。
-
降低微调成本与复杂度:相对于为每个特定任务或知识领域都进行大规模LLM微调, RAG提供了一种更为经济、灵活的知识注入方式。更新知识库远比重新训练模型要简单快捷。
-
个性化与定制化能力:可以方便地针对不同的用户群体、业务场景或特定查询,动态接入和切换不同的知识库,实现高度定制化的问答服务。
RAG通过将大语言模型与外部知识源相结合,有效提升了其在检索精确信息、获取最新数据或提供可验证回答方面的性能。
RAG核心组件
一个典型的RAG系统主要由三大核心组件构成:检索器(Retriever) 、生成器(Generator)和知识库(Knowledge Base) 。这些组件协同工作,实现了从用户查询到生成高质量答案的完整流程。
上图展示了RAG系统的三大核心组件:知识库负责存储信息,检索器根据用户查询从中提取相关上下文,生成器(LLM)则基于这些上下文和原始查询生成回答。数据流清晰地体现了各组件间的协作关系。
检索器(Retriever)
作用:检索器的核心任务是根据用户的输入查询,从大规模的知识库中快速、准确地召回与查询意图最为相关的文档片段(即上下文)。检索器的性能直接决定了后续生成器能够获取到的信息质量,是RAG系统效果的关键瓶颈之一。
关键技术/流程:
-
数据预处理(Indexing Pipeline/Offline Process): 这是在RAG系统提供服务之前,对知识库进行的预先处理和索引构建工作。
-
文档加载(Document Loading):从各种异构数据源 (如PDF文件、TXT文档、HTML网页、数据库记录、Notion页面等)加载原始文档内容。
-
文本分割(Text Splitting/Chunking) :由于LLM通常有上下文长度限制,且为了更精确地定位信息,长文档需要被切分成较小的、但仍保持一定语义完整性的文本块(chunks)。常用的策略包括固定大小切分、递归字符切分、语义切分等。
-
向量嵌入(Embedding):使用预训练的文本嵌入模型(如Sentence-BERT系列, BAAI的BGE模型, OpenAI的text-embedding-ada-002等)将每一个文本块转换成一个高维的数值向量(Embedding Vector) 。这个向量能够捕捉文本块的语义信息,语义相似的文本块在向量空间中的距离也更近。
-
-
索引存储(Vector Store/Indexing) :将文本块的向量表示及其原始内容(有时还包括元数据,如来源、标题等)存储在专门优化的向量数据库中。常见的向量数据库包括FAISS(本地库),Milvus(开源系统), Pinecone (云服务), ChromaDB(本地/轻量级),Qdrant等。这些数据库能够构建高效的索引结构(如IVF-PQ, HNSW) , 以支持大规模向量的快速近似最近邻(ANN)搜索。
-
查询时检索(Runtime Retrieval/Online Process) :当用户发起查询时执行。
-
查询向量化:将用户的自然语言查询也通过与文档块相同的文本嵌入模型转换为查询向量。
-
相似度搜索:在向量数据库中,计算查询向量与索引中所有(或部分)文档块向量之间的相似度(常用的是余弦相似度或点积)。然后,找出与查询向量最相似(即距离最近) 的Top-K个文本块作为候选上下文。
-
生成器(Generator)
作用:生成器,通常是一个强大的大型语言模型(LLM),负责接收用户的原始查询以及由检索器召回的相关上下文信息。它的任务是综合理解这些输入,并基于它们生成一个连贯、准确、满足用户意图的最终答案。
关键技术/模型:
-
7大型语言模型(LLM) :如OpenAI的GPT系列(GPT-3.5, GPT-4), Google的Gemini系列, Meta的LLaMA系列, Anthropic的Claude系列, 以及国内的通义千问(Qwen), ChatGLM, Baichuan等。这些模型具备强大的自然语言理解、推理和生成能力。
-
提示工程(Prompt Engineering) :如何将用户查询和检索到的上下文有效地组织成一个清晰、明确的提示(Prompt) 并输入给LLM至关重要。一个精心设计的Prompt能够更好地引导LLM利用提供的上下文,遵循特定指令(如”仅根据上下文回答”、“如果信息不足请说明”),从而生成高质量的答案。
知识库(Knowledge Base)
作用:知识库是RAG系统外部知识的源泉,它包含了系统在回答问题时需要参考的所有特定领域信息、企业私有数据、实时更新的内容等。知识库的质量、覆盖范围和更新频率直接影响RAG系统的表现上限。
构建方式:
-
知识库的构建是一个持续的过程,可能涉及从多种数据源收集信息,例如:
-
公司内部文档:产品手册、技术文档、FAQ、政策文件、历史邮件等。
-
公开网站内容:行业报告、新闻文章、博客、论坛讨论等。
-
数据库记录:结构化或半结构化的业务数据。
-
API数据源:外部服务提供的实时信息。
-
-
收集到的数据通常需要进行清洗(去除噪声、格式化)、转换(统一格式),有时还需要进行结构化处理(如提取实体关系构建知识图谱,虽然基础RAG主要处理非结构化文本)。
-
最终,这些处理后的内容会经过上述的文本分割和向量化过程,被加载到向量数据库中,形成可供检索器使用的索引。
这三大组件的紧密协作构成了RAG系统的核心运作机制,使得LLM能够”站在巨人的肩膀上”,利用外部知识提升其回答的质量和可靠性(知乎:RAG向量化产品核心组件详解)。
RAG系统典型架构
RAG系统的架构设计旨在高效地整合检索与生成两大过程,为用户提供精准且基于知识的回答。其工作流程通常可以划分为离线的”索引构建”阶段和在线的”查询处理”阶段。
上图区分了RAG系统的两个主要阶段:离线阶段负责将知识源处理并构建成可检索的向量索引;在线阶段则在⽤⼾发起查询时,执⾏检索、上下⽂构建和答案⽣成的过程。这种分离使得知识库可以独⽴更新,⽽查询过程保持⾼效。
架构步骤详解军((在线查询流程):
-
用户查询输入(User Query):一切始于用户提出的自然语言问题。例如:“RAG系统如何解决LLM的幻觉问题?”
-
查询增强/转换(Query Augmentation/Transformation) (可选但常用):原始用户查询可能存在歧义、信息不全或表达方式不利于检索。此步骤通过各种技术优化查询,以提升后续检索的准确性和召回率。常见方法包括:
-
查询改写(Query Rewriting):利用LLM自身能力,将模糊或口语化的查询改写得更清晰、更结构化。例如,将”那东西咋用?“改写为”请说明[具体产品名称]的使用方法。”
-
查询扩展(Query Expansion):为查询增加同义词、近义词、相关概念或上位/下位词,以扩大检索的覆盖面。
-
子查询生成(Sub-query Generation):对于复杂问题, 可以将其分解为多个更简单的子问题,分别对每个子问题进行检索,然后综合子问题的答案。
-
假设性文档嵌入(Hypothetical Document Embeddings,HyDE):一种创新的方法,首先让LLM针对原始查询”幻想”出一个可能包含答案的理想文档片段,然后使用这个假设性文档的嵌入向量去知识库中检索真实的相似文档。在某些场景下,这种方法比直接用查询向量检索效果更好。
-
-
文档检索(Document Retrieval):经过(可能) 增强或转换后的用户查询被向量化。检索器使用此查询向量,在预先构建好的向量数据库中执行相似度搜索(通常是Top-K搜索),召回K个与查询语义最相关的文档块(chunks)。这些文档块构成了初步的上下文信息。
-
上下文重排(Context Re-ranking) (可选但推荐):初步检索到的Top-K文档块虽然在向量空间中与查询接近,但这种相似度并不总能完美对应真实的相关性排序。重排阶段旨在使用更精细(通常计算成本也更高)的模型来对这K个文档块进行二次排序。例如,可以使用Cross-Encoder模型,它会同时接收查询和每个候选文档块作为输入,并输出一个更精确的相关性得分。通过重排,可以将真正最关键的上下文信息置于更靠前的位置,或剔除部分相关性不高的结果,从而提升最终喂给LLM的上下文质量。
-
上下文构建与Prompt注入(Context Construction & Prompt Injection) :将检索到(并可能经过重排)的文档块内容与原始用户查询(或改写后的查询)整合。这一步的核心是按照预先精心设计的Prompt模板,将这些信息结构化地组织起来,形成最终输入给大型语言模型(LLM)的完整提示。Prompt通常会包含明确的指令, 如要求LLM基于提供的上下文作答、如何处理信息不足的情况等。
-
答案生成 (Answer Generation):LLM接收这个包含丰富上下文和用户问题的Prompt。凭借其强大的语言理解和生成能力,LLM消化上下文信息,理解用户意图,并生成一个自然、连贯且基于所提供事实的答案。这个答案随后返回给用户。
这个典型的架构流程清晰地展示了RAG系统如何通过”检索”来”增强”LLM的”生成”能力,使其在处理知识密集型任务时表现得更加出色和可靠。
公众号:硬核隔壁老王 可获取相关大模型资源