ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

RAG的原理框架与拆解

RAG的原理框架与拆解 RAG检索增强生成是目前解决大模型“知识盲区”和“幻觉”问题的核心架构。它的思想很直接在让大模型回答问题时先从一个外部知识库里找出最相关的信息连同问题一起喂给模型让模型“开卷考试”而不是凭记忆瞎编。下面我们把RAG从原理到架构完整拆解一遍。RAG的核心原理为什么要“检索”大语言模型LLM虽然强大但有几个天生的短板知识是过时的模型训练时用的数据有截止日期它不知道之后发生的事情。没有“企业知识”它不知道你的内部文档、产品目录、客户信息等私有数据。会“幻觉”遇到不知道的问题它会一本正经地胡说八道。RAG就是用来解决这三个问题的。 它不是去重新训练模型而是在推理时动态地从你的知识库中检索信息作为上下文提供给模型。这样一来模型就能基于你提供的事实信息来生成回答既保证了答案的时效性和准确性又能通过引用来源来验证。RAG vs 微调微调是把知识“记住”适合让模型学会某种风格或固化知识RAG是“查阅”适合知识频繁更新、需要引用来源的场景。RAG标准架构拆解两阶段一个标准的RAG系统可以拆解为两个核心阶段数据索引阶段准备知识库 和 推理查询阶段回答问题。阶段一数据索引建库阶段这个阶段的目的是把原始文档处理成一个“可检索的知识库”。数据提取与清洗从PDF、Word、数据库等各类数据源提取文本内容进行格式标准化、去噪等预处理。分块把长文档切分成语义完整的小块chunks。这是关键步骤块太大可能引入噪声块太小可能丢失上下文。实践中常用滑动窗口或Small2Big策略检索小句子返回大段落来平衡。向量化用嵌入模型将每个文本块转换成一个高维向量即“嵌入”这个向量代表了文本的语义。存储将生成的向量和原始文本块存入向量数据库如Milvus、pgvector并建立索引以支持高效检索。阶段二推理查询问答阶段这个阶段是实时的处理用户的问题并生成回答。问题向量化接收用户问题后使用同一个嵌入模型将问题也转换成向量。这里必须和建库时用的模型一致否则语义空间不同检索结果会完全失效。检索在向量数据库中用相似度算法如余弦相似度找出与问题向量最相似的前k个文本块。增强将检索到的文本块作为“参考资料”连同用户问题和预设的指令组合成一个完整的提示词。例如“基于以下参考资料回答问题… \n\n 问题…”。生成将增强后的提示词发给大语言模型LLM模型根据提供的资料生成最终答案并可附带引用来源。生产级进阶架构超越“朴素RAG”上面是最简单的“朴素RAG”生产环境通常需要引入更多优化策略。混合检索与重排序o 挑战纯向量检索擅长语义匹配但可能漏掉精确的专有名词如产品型号“ABC-123”。o 方案采用混合检索同时运行向量检索查语义和关键词检索BM25查精确匹配然后通过RRF倒数排名融合 算法综合排序。最后再用一个重排序Rerank模型对结果进行精排进一步提高相关性。元数据过滤与层级索引o 为每个文本块打上元数据标签如来源、日期、作者检索时可以先按元数据筛选如“只看2025年后的文档”缩小范围。o 也可以构建层级索引先通过摘要索引快速定位到相关文档组再到组内进行细粒度检索。搜索优化与查询改写o 在检索前先让模型对用户问题进行一次“改写”或“扩展”比如“帮我查一下退换货政策”可以拆解为“退货流程”和“换货条件”两个查询提高召回率。代理式RAGo 标准RAG流程是固定的。对于复杂的多步推理任务可以让AI代理自主决定是否需要检索、检索哪个知识库、检索几次甚至将检索作为其可调用的“工具”之一实现更灵活的工作流。总结把RAG的架构拆解到这一步最底层的逻辑其实就清晰了它本质上是一个“搜索 阅读”的流水线。• 检索阶段核心职责是召回关键在于“找得准”。• 生成阶段核心职责是回答关键在于“读得懂”。这两点对于你之前关注的C系统编程领域来说正是发挥性能优势的地方——无论是高效实现向量索引、构建高并发检索服务还是优化底层内存管理都是RAG系统在工业级落地时绕不开的硬骨头。
返回列表