RAG详解：让大模型看见你的私有知识

本文已收录至GitHub推荐阅读 Java随想录文章目录为什么需要 RAG知识的局限性幻觉问题数据安全RAG 的破局思路RAG 的技术架构数据准备阶段构建知识的向量化索引应用阶段高级 RAG 技术搜索索引的演进混合搜索内容增强HyDE假设性答案增强检索查询转换重排与过滤RAG 融合技术流程优势注意事项评估体系评估框架与工具发展趋势结语在把大语言模型用到实际业务时开发者很快会遇到一个问题通用模型很难满足特定场景的需求。主要卡在三个地方知识过时模型的训练数据有截止日期问它最近发生的事基本白问。幻觉严重模型经常一本正经地胡说八道在需要准确性的场景这是致命的。数据安全企业不可能把内部文档上传给第三方但不上传模型又不会。基于这个问题RAG检索增强生成出现了。它的思路很简单不把数据交给模型而是让模型看到它需要的部分。用户提问时系统从私有知识库中检索相关片段把这些片段和问题一起发给大模型。模型结合真实信息来回答而不是靠记忆里不知道哪来的东西生成。为什么需要 RAG知识的局限性大语言模型的知识完全来自训练数据。GPT-4、文心一言、通义千问这些主流模型训练数据主要来自网络公开数据。这带来两个问题时效性模型的知识被定格在训练截止时间点。GPT-4 的知识库可能停在 2023 年 12 月之后的新事件、新政策、新技术它无法直接给出准确答案。私有领域缺失企业的产品规格文档、内部流程规范、医疗机构的诊断指南、法律机构的判例汇编——这些数据从没出现在公开网络上通用大模型对此一无所知。不借助外部手段模型在这些领域的回答质量会大打折扣。幻觉问题大语言模型在生成文本时实际上是在计算下一个 token 出现的概率分布。这种机制导致模型在面对不确定性问题时经常编造看似合理实则错误的答案——学名叫幻觉Hallucination。更麻烦的是模型不具备某一方面知识时它不会选择不知道而是倾向于根据训练数据中学习到的语言模式自信满满地瞎编。在需要高度准确性的生产环境中这绝对不可接受。数据安全对企业来说数据安全是生死攸关的议题。没人愿意承担核心商业机密泄露的风险因此几乎没有企业愿意将私有数据上传到第三方平台进行模型训练或推理。这意味着完全依赖通用大模型自身能力的应用方案不得不在数据安全和应用效果之间做取舍。传统方案要么保数据安全牺牲模型能力要么提升模型能力却承担数据泄露风险。RAG 的破局思路RAG 提供了第三条路不把数据交给模型而是让模型看到它需要的那部分数据。用户提问时系统从私有知识库中检索相关片段把这些片段作为上下文提供给大模型。大模型在回答时既能参考检索到的真实信息又能结合自身的语言理解能力生成流畅的回答。数据始终留在本地模型获得了感知私有知识的能力。RAG 的技术架构RAG 的完整工作流程分为两个阶段数据准备阶段离线索引和应用阶段在线推理。数据准备阶段构建知识的向量化索引数据准备是离线过程目标是将私有数据转化为可高效检索的向量形式。流程包含四个环节数据提取。从多种格式的原始文件中提取纯文本内容包括 PDF、Word、HTML、数据库记录等。技术挑战在于处理各种格式解析、特殊字符清理、无用内容过滤。常用 LangChain 的 DocumentLoaders 来统一处理不同来源的数据。文本分割Chunking。直接影响检索质量。需要综合考虑两个因素一是 embedding 模型对 token 长度的限制二是语义完整性对检索效果的影响。固定长度分割实现简单但容易切断语义边界导致检索时丢失关键上下文。语义分割通过识别句子边界或段落结构来进行切分能更好地保留语义完整性但实现复杂度更高。业界常用策略是设置合适的 chunk size如 512 tokens和 overlap如 50-100 tokens在保证语义完整性的同时避免边界效应。向量化Embedding。将文本转化为高维向量让语义相似的文本在向量空间中具有相近的位置关系。常见的 embedding 模型模型名称特点适用场景OpenAI text-embedding-3API 调用稳定可靠通用场景BGE (BAAI)开源、支持中英文自部署场景M3E (MokaAI)开源、多语言支持中文场景ERNIE-Embedding百度自研、中文优化国产化需求数据入库。将向量及其关联的原始文本、元数据写入向量数据库。主流选择包括 FAISS、Chroma、Milvus、Weaviate 和 Qdrant 等。这些数据库采用近似最近邻ANN算法能够在海量向量中快速找到与查询向量最相似的结果。应用阶段用户提出问题时RAG 系统进入在线推理阶段包含四个关键步骤查询向量化。使用与索引阶段相同的 embedding 模型将用户的自然语言问题转化为语义向量。这个向量的质量直接决定后续检索的准确性。信息检索Retrieval。通过计算查询向量与所有存储向量的相似度如余弦相似度、欧氏距离找出 top-k 个最相关的文档片段。现代向量数据库通常采用 HNSWHierarchical Navigable Small World等算法在保证检索精度的同时实现毫秒级响应。上下文构建。将检索到的相关片段与原始问题组装成完整的提示模板。一个典型的 RAG 提示模板【任务描述】 假如你是一个专业的客服机器人请参考【背景知识】中的内容准确回答用户的问题。 【背景知识】 {检索到的相关文档片段} 【用户问题】 {用户原始问题} 【回答要求】 - 仅根据【背景知识】中的内容回答 - 如果【背景知识】中没有相关信息请明确告知 - 回答要简洁、准确、有条理答案生成Generation。大语言模型接收包含问题和上下文的提示后结合检索到的真实信息生成最终答案。由于有明确的参考资料作为约束模型产生幻觉的概率大大降低。高级 RAG 技术基础 RAG 流程能工作但在实际应用中往往面临检索质量不足、生成效果不稳定等问题。业界发展出一系列高级 RAG 技术来优化系统性能。搜索索引的演进平面索引Flat Index直接计算查询向量与所有存储向量的相似度。实现简单但数据规模达到数万条时线性扫描的计算开销变得不可接受。向量索引采用近似最近邻算法来解决效率问题。FAISS 库提供了多种索引类型IVFInverted File Index通过聚类将向量分组检索时只搜索最相关的聚类中心显著减少计算量。HNSWHierarchical Navigable Small World构建多层图结构实现对数级别的检索复杂度。PQProduct Quantization对高维向量进行压缩大幅降低内存占用。分层索引应对大型知识库。系统维护两个层级的索引一个由文档摘要组成用于快速过滤另一个由文档块组成用于精确检索。这种设计在保证检索召回率的同时大幅提升检索效率。混合搜索单纯的向量检索在处理精确术语匹配时往往表现不佳。比如用户搜索如何重置密码向量检索可能无法准确识别重置和修改之间的细微差别。混合搜索结合传统关键词检索如 BM25、TF-IDF和现代语义向量检索。两种检索结果通过Reciprocal Rank FusionRRF算法进行融合对不同检索方法的结果按排名赋分综合排名最高的文档被选中。关键词检索确保精确匹配的召回语义检索捕捉同义词和语义关联。两者互补能够应对更广泛的查询类型。内容增强语句窗口检索器Sentence Window Retriever采用小块索引、大窗口上下文的策略。文档中的每个句子单独嵌入向量索引以保证检索精度但检索后扩展上下文窗口额外获取前后各 k 个句子提供更完整的语义信息给大模型。自动合并检索器Parent Document Retriever采用层级分割策略文档被递归分割为较小的子块每个子块与较大的父块存在引用关系。检索时获取相关子块当多个相关子块指向同一父块时自动升级为使用父块作为上下文。这种设计让系统同时获得精确检索和宏观语义。HyDE假设性答案增强检索HyDEHypothetical Document Embeddings是一种逆向思维的方法不直接用问题检索而是先用大模型根据问题生成一个假设性的答案然后用这个假设答案去检索相关文档。前提假设是假设答案与真实文档在语义空间中可能更接近因为两者都是回答性的文本。HyDE 在处理抽象概念或模糊查询时表现尤为出色。查询转换用户的原始问题往往不够检索友好。查询转换系列技术利用大模型的推理能力来优化查询查询分解Query Decomposition将复杂问题拆分为多个简单子问题。例如LangChain 和 LlamaIndex 哪个更适合做 RAG 开发这个问题难以直接检索但可以拆分为LangChain 做 RAG 开发的优缺点和LlamaIndex 做 RAG 开发的优缺点两个子问题分别检索后再综合回答。Step-back Prompting生成更通用的查询来获取高层次上下文与原始查询的检索结果一起输入模型实现由面到点的推理。查询重写Query Rewriting使用大模型改写问题表达尝试用不同的表述方式检索提高召回率。重排与过滤检索返回的 top-k 结果可能存在质量问题相关性参差不齐、信息冗余、噪声干扰。重排Reranking技术应运而生。交叉编码器重排将查询和每个候选文档一起输入专门的交叉编码模型输出精细化的相关性评分。这种方法比向量相似度计算更准确但计算开销更大通常用于对初始检索结果的二次筛选。基于元数据的过滤利用文档的元数据时间、来源、类别等进行条件筛选快速排除不相关的结果。RAG 融合RAG 融合RAG Fusion通过 LLM 生成多个变体查询来增强检索效果。单一查询可能无法覆盖用户问题的所有方面通过让 LLM 生成多个不同角度的查询可以从知识库中召回更丰富、更多样化的相关信息。技术流程多查询生成使用 LLM 根据用户原始问题生成 n 个相关查询。并行向量搜索用所有生成的查询分别进行向量检索。结果融合排序应用 RRF 算法对所有检索结果进行综合排名。上下文注入将融合后的相关文档注入提示模板。答案生成LLM 基于融合后的上下文生成最终答案。优势多样性增强不同查询从不同角度切入问题最终结果涵盖更广泛的视角减少单一视角带来的偏差。鲁棒性提升某个查询因表述偏差导致检索不佳时其他查询可以弥补缺陷提升整体系统的稳定性。语义纠偏LLM 生成的查询往往是对原始问题的语义扩展能够捕捉隐含的语义关联。注意事项延迟增加额外的 LLM 调用会引入额外延迟在延迟敏感的场景中需要权衡。专业术语处理如果知识库包含大量内部术语或行话LLM 可能因不了解这些术语而产生无关查询此时需要针对性优化提示词。成本考量额外的 LLM 调用意味着额外的 token 消耗需要评估 ROI。评估体系RAG 系统的质量评估是工程实践中的重要环节。业界通常采用RAG 三元组评估框架检索内容相关性Context Relevance评估检索到的文档与用户问题的相关程度。高相关性意味着检索阶段工作良好能够召回真正有用的信息。常用指标包括召回率Recall和精确率Precision。答案基于性Answer Groundedness衡量 LLM 的回答是否基于检索到的上下文而非依赖自身知识或产生幻觉。这一指标直接反映 RAG 机制的有效性。答案相关性Answer Relevance评估生成的回答是否有效解决了用户的问题。高相关性意味着即使检索和基于性都良好最终答案也能真正满足用户需求。评估框架与工具RAGAs是当前流行的 RAG 评估框架提供标准化的评估流程和指标计算方法。LangSmith是 LangChain 官方提供的评估平台支持自定义评估器、运行时监控和调试追踪。Truelens由 LlamaIndex 团队推出专注于 RAG 系统的可观测性和评估。发展趋势RAG 技术正在快速演进几个方向值得关注端到端优化。传统 RAG 将检索和生成视为独立环节但最新研究开始探索联合优化的可能性。Meta AI 提出的RA-DIT技术同时微调 LLM 和 Retriever让两个组件在学习过程中相互适应在知识密集型任务上取得了显著提升。多模态 RAG。随着多模态大模型的发展RAG 的边界正在从纯文本扩展到图像、视频、音频等多种模态。未来的 RAG 系统需要能够处理跨模态的知识检索和生成。主动学习与持续优化。结合用户反馈和评估结果构建自适应优化机制让 RAG 系统能够从实际使用中持续学习和改进。轻量化与边缘部署。随着模型压缩技术的发展更小、更快的 LLM 将成为 RAG 系统的新选择。Mistral Mixtral、Microsoft Phi-2 等小参数模型的崛起为 RAG 在边缘设备上的部署开辟了新的可能性。结语RAG 技术通过将检索能力与大语言模型的生成能力相结合为 LLM 的实际应用提供了一条切实可行的路。它解决了知识时效性、私有数据访问和幻觉抑制等核心问题。当然RAG 不是万能药。检索质量、响应延迟、系统复杂度等挑战依然存在。开发者需要根据具体场景权衡利弊选择合适的技术组合。至于未来会怎样让时间来检验。