企业官网建设流程全解析

建设营销网站,婚介网站怎么做,嘉兴网站建设技术托管,制作视频软件哪个好Datawhale干货 作者#xff1a;尹大吕#xff0c;all-in-rag项目负责人一、什么是 RAG#xff1f;1. 核心定义从本质上讲#xff0c;RAG#xff08;Retrieval-Augmented Generation#xff09;是一种旨在解决大语言模型#xff08;LLM#xff09;“知其然不知其所以然”…Datawhale干货作者尹大吕all-in-rag项目负责人一、什么是 RAG1. 核心定义从本质上讲RAGRetrieval-Augmented Generation是一种旨在解决大语言模型LLM“知其然不知其所以然”问题的技术范式。它的核心是将模型内部学到的“参数化知识”模型权重中固化的、模糊的“记忆”与来自外部知识库的“非参数化知识”精准、可随时更新的外部数据相结合。其运作逻辑就是在 LLM 生成文本前先通过检索机制从外部知识库中动态获取相关信息并将这些“参考资料”融入生成过程从而提升输出的准确性和时效性。 一句话总结RAG 就是让 LLM 学会了“开卷考试”它既能利用自己学到的知识也能随时查阅外部资料。2. 技术原理那么RAG 系统是如何实现“参数化知识”与“非参数化知识”的结合呢如图 1-1 所示其架构主要通过两个阶段来完成这一过程1检索阶段寻找“非参数化知识”知识向量化嵌入模型Embedding Model充当了“连接器”的角色。它将外部知识库编码为向量索引Index存入向量数据库。语义召回当用户发起查询时检索模块利用同样的嵌入模型将问题向量化并通过相似度搜索Similarity Search从海量数据中精准锁定与问题最相关的文档片段。2生成阶段融合两种知识上下文整合生成模块接收检索阶段送来的相关文档片段以及用户的原始问题。指令引导生成该模块会遵循预设的Prompt指令将上下文与问题有效整合并引导 LLM如 DeepSeek进行可控的、有理有据的文本生成。图 1-1 RAG 双阶段架构示意图3. 技术演进分类RAG 的技术架构经历了从简单到复杂的演进如图 1-2 大致可分为三个阶段。图 1-2 RAG 技术演进分类这三个阶段的具体对比如表 1-1 所示。表 1-1 RAG 技术演进分类对比“离线”指提前完成的数据预处理工作如索引构建“在线”指用户发起请求后的实时处理流程。二、为什么要使用 RAG1. 技术选型RAG vs. 微调在选择具体的技术路径时一个重要的考量是成本与效益的平衡。通常我们应优先选择对模型改动最小、成本最低的方案所以技术选型路径往往遵循的顺序是提示词工程Prompt Engineering - 检索增强生成 - 微调Fine-tuning。我们可以从两个维度来理解这些技术的区别。如图 1-3 所示横轴代表“LLM 优化”即对模型本身进行多大程度的修改。从左到右优化的程度越来越深其中提示工程和 RAG 完全不改变模型权重而微调则直接修改模型参数。纵轴代表“上下文优化”是对输入给模型的信息进行多大程度的增强。从下到上增强的程度越来越高其中提示工程只是优化提问方式而 RAG 则通过引入外部知识库极大地丰富了上下文信息。图 1-3 选型路径图基于此我们的选择路径就清晰了先尝试提示工程通过精心设计提示词来引导模型适用于任务简单、模型已有相关知识的场景。再选择 RAG如果模型缺乏特定或实时知识而无法回答则使用 RAG通过外挂知识库为其提供上下文信息。最后考虑微调当目标是改变模型“如何做”行为/风格/格式而不是“知道什么”知识时微调是最终且最合适的选择。例如让模型学会严格遵循某种独特的输出格式、模仿特定人物的对话风格或者将极其复杂的指令“蒸馏”进模型权重中。RAG 的出现填补了通用模型与专业领域之间的鸿沟它在解决如表 1-2 所示 LLM 局限时尤其有效表 1-2 RAG 对 LLM 局限的解决方案2. 关键优势1准确性与可信度的双重提升RAG 最核心的价值在于突破了模型预训练知识的限制。它不仅能补充专业领域的知识盲区还能通过提供具体的参考材料有效抑制“一本正经胡说八道”的幻觉现象。论文研究还表明RAG 生成的内容在具体性和多样性上也显著优于纯 LLM。更重要的是RAG 具备可溯源性——每一条回答都能找到对应的原始文档出处这种“有据可查”的特性极大提高了内容在法律、医疗等严肃场景下的可信度。2时效性保障在知识更新方面RAG 解决了 LLM 固有的知识时滞问题即模型不知道训练截止日期之后发生的事。RAG 允许知识库独立于模型进行动态更新——新政策或新数据一旦入库立刻就能被检索到。这种能力在论文中被称为“索引热拔插”Index Hot-swapping——就像给机器人换一张存储卡一样瞬间切换其世界知识库而无需重新训练模型实现了知识的实时在线。3显著的综合成本效益从经济角度看RAG 是一种高性价比的方案。首先它避免了高频微调带来的巨额算力成本其次由于有了外部知识的强力辅助我们在处理特定领域问题时往往可以使用参数量更小的基础模型来达到类似的效果从而直接降低了推理成本。这种架构也减少了试图将海量知识强行“塞入”模型权重中所需的计算资源消耗。4灵活的模块化可扩展性RAG 的架构具备极强的包容性支持多源集成无论是 PDF、Word 还是网页数据都能统一构建进知识库中。同时其模块化设计实现了检索与生成的解耦这意味着我们可以独立优化检索组件比如更换更好的 Embedding 模型而不会影响到生成组件的稳定性便于系统的长期迭代。3. 适用场景风险分级表 1-3 展示了 RAG 技术在不同风险等级场景中的适用性。表 1-3 RAG 适用场景风险分级三、如何上手 RAG1. 基础工具链选择构建 RAG 系统通常涉及几个关键环节的选型。在开发模式上我们可以利用LangChain或LlamaIndex等成熟框架快速集成也可以选择不依赖框架的原生开发以获得对系统流程更精细的控制力在 AI 编程辅助下这并非难事。而在记忆载体向量数据库方面既有Milvus、Pinecone等适合大规模数据的方案也有FAISS、Chroma等轻量级或本地化的选择需根据具体业务规模灵活决定。后期为了量化效果还可以引入RAGAS或TruLens等自动化评估工具。2. 四步构建最小可行系统MVP1数据准备与清洗这是系统的地基。我们需要将 PDF、Word 等多源异构数据标准化并采用合理的分块策略如按语义段落切分而非固定字符数避免信息在切割中支离破碎。2索引构建将切分好的文本通过嵌入模型转化为向量并存入数据库。可以在此阶段关联元数据如来源、页码这对后续的精确引用很有帮助。3检索策略优化不要依赖单一的向量搜索。可以采用混合检索向量关键词等方式来提升召回率并引入重排序模型对检索结果进行二次精选确保 LLM 看到的都是精华。4生成与提示工程最后设计一套清晰的Prompt 模板引导 LLM 基于检索到的上下文回答用户问题并明确要求模型“不知道就说不知道”防止幻觉。3. 新手友好方案如果希望快速验证想法而非深耕代码可以尝试FastGPT或Dify这样的可视化知识库平台它们封装了复杂的 RAG 流程仅需上传文档即可使用。对于开发者利用LangChain4j Easy RAG或 GitHub 上的TinyRAG[^6]等开源模板也是高效的起手方式。4. 进阶与挑战当基础的 RAG 系统搭建完成后下一步的进阶之路便聚焦于如何评估、诊断并突破其固有的瓶颈。1评估维度与挑战一套 RAG 系统的好坏并不能仅凭感觉。业界通常会从几个维度进行量化评估首先是检索相关性找到的内容是否包含答案其次是生成质量这又可以细分为语义准确性回答的意思是否正确和词汇匹配度专业术语是否使用得当。这些评估维度也直接对应了 RAG 当前面临的主要挑战。比如检索依赖性问题——如果检索系统召回了错误信息再强的 LLM 也会“一本正经地胡说八道”。此外对于需要跨多个文档进行综合分析的多跳推理问题常见的 RAG 架构也普遍感到吃力。2优化方向与架构演进针对上述挑战社区探索出了多种优化路径。在性能层面可以通过索引分层对高频数据启用缓存和多模态扩展支持图像/表格检索来提升效率和能力边界。而在架构层面简单的线性流程正在被更复杂的设计模式所取代。例如系统可以通过分支模式并行处理多路检索或通过循环模式进行自我修正这些灵活的架构是通往更智能 RAG 的必由之路。四、RAG 已死随着大模型长上下文窗口能力的提升社区中开始出现“RAG 已死”的声音。这一论调主要来自两个方面一是认为长上下文已经能暴力“消化”海量文本不再需要复杂的检索系统二是批评 RAG 这个术语本身就过于宽泛模糊了太多技术细节反而阻碍了理解与优化。这些观点忽略了一个技术概念在演进过程中的普遍规律。正如我们可以轻易地为现代复杂的 RAG 系统起一个更精确、更唬人的名字比如“大模型知识管理专家系统”Large Language Model Knowledge Management Expert SystemLKE。因为它早已超出了最初“检索-增强-生成”的简单范畴。但这种“换名游戏”恰恰说明了“RAG 已死”论的表面化——这无异于在用一个新瓶子去装 RAG 这个不断陈化的老酒。笔者在此并非要创造一个新词不过为什么要起 LKE 这个名字它代表了三个核心要素1. LLarge Language Model强调系统的驱动力是大语言模型。2. KKnowledge Management寓意着系统就像一个知识管理员精准地为我们找到检索所需要的知识辅助我们后续利用大模型进行更高阶应用。3. EExpert说明系统能像专家一样通过路由、分析、融合、修正等一系列步骤最终给出答案生成、解决问题。可以类比Transformer。今天无论是以 GPT 为代表的 Decoder-only 还是以 BERT 为代表的 Encoder-only我们都习惯称之为“基于 Transformer 架构”尽管它们与最初论文中的完整形态差异巨大。但是 Transformer 这个标签抓住了一次技术范式的核心飞跃并成为了一个技术时代的象征。同理RAG 的核心在于“将 LLM 的内在参数化知识与外部非参数化知识相结合”。只要这个思想或需求不变无论我们为其增加多少模块——查询转换、多路召回或者自我修正等等它本质上依然是在这个框架下的演进。所以“RAG 已死”是一个伪命题。相反RAG 作为一个概念活得很好它正在像 Transformer 一样成为一个不断吸收新技术、不断进化的基础架构范式。它的生命力正在于它的“面目全非”和“包罗万象”。而本教程的目标就是绘制出这张描绘 RAG 全貌的清晰地图当我们可以解构它的每一个模块、理解它的每一种可能性时RAG 也好LKE 也罢这些都无关紧要。我们要做的就是通过 RAG 这道经典例题来学习和拓展将 LLM 的内在参数化知识与外部非参数化知识相结合这类题型的解题思路。RAG 技术仍在快速发展中可以持续关注学术和工业界的最新进展本文来自Datawhale all-in-rag项目https://github.com/datawhalechina/all-in-rag参考文献1. Genesis, J. (2025).Retrieval-Augmented Text Generation: Methods, Challenges, and Applications.2. Gao et al. (2023).Retrieval-Augmented Generation for Large Language Models: A Survey.3. Lewis et al. (2020).Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.4. Gao et al. (2024).Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks.5.TinyRAG: https://github.com/KMnO4-zx/TinyRAG一起“点赞”三连↓