导图社区 可能替代RAG的技术
传统 RAG 遇挑战,三大替代技术谁主沉浮?本思维导图先剖析传统 RAG 固定流水线的本质缺陷,传统 RAG 依靠查询向量化、向量检索、拼接检索文本再送入大模型生成答案,整套流程固化,存在检索成本偏高、文本总结能力有限等短板,面对复杂企业知识库场景时容易出现信息遗漏、检索不准等问题。再深度解读超长上下文、Agentic Retrieval、LLM Wiki 三大技术及其适用边界。超长上下文技术依托大模型不断扩容的记忆容量,直接将完整文档作为输入,省去向量检索环节,适合小规模知识库,但存在 token 成本上涨、长文本中间信息遗忘等局限。Agentic Retrieval 智能体检索将检索升级为推理任务,构建思考、行动、观察的循环,依靠工具链自主规划、分步完成复杂查询,适配企业多步骤复杂检索需求。LLM Wiki 知识导航系统具备页面级语义存储、实体关系构建能力,支持知识动态更新,适合长期沉淀专业知识。最后给出技术选型指南,明确三大新技术并非全面取代 RAG,各自拥有适用场景与局限性,RAG 仍是企业级应用基石,企业可结合知识库规模、查询复杂度、成本预算灵活搭配方案。无论研究大模型应用的算法工程师、学习检索增强技术的研发人员,还是需要选型知识库方案的产品从业者,都可以借助这套分析框架理清 RAG 替代方案的技术逻辑。
提示: 本内容由社区用户上传并分享。平台不对内容的真实性、合法性、知识产权归属及是否侵害第三方权利进行事前审核或保证。本内容可能包含受版权保护的图片、字体或其他第三方素材,使用前请自行确认授权范围。
传统 RAG 遇挑战,三大替代技术谁主沉浮?本思维导图先剖析传统 RAG 固定流水线的本质缺陷,传统 RAG 依靠查询向量化、向量检索、拼接检索文本再送入大模型生成答案,整套流程固化,存在检索成本偏高、文本总结能力有限等短板,面对复杂企业知识库场景时容易出现信息遗漏、检索不准等问题。再深度解读超长上下文、Agentic Retrieval、LLM Wiki 三大技术及其适用边界。超长上下文技术依托大模型不断扩容的记忆容量,直接将完整文档作为输入,省去向量检索环节,适合小规模知识库,但存在 token 成本上涨、长文本中间信息遗忘等局限。Agentic Retrieval 智能体检索将检索升级为推理任务,构建思考、行动、观察的循环,依靠工具链自主规划、分步完成复杂查询,适配企业多步骤复杂检索需求。LLM Wiki 知识导航系统具备页面级语义存储、实体关系构建能力,支持知识动态更新,适合长期沉淀专业知识。最后给出技术选型指南,明确三大新技术并非全面取代 RAG,各自拥有适用场景与局限性,RAG 仍是企业级应用基石,企业可结合知识库规模、查询复杂度、成本预算灵活搭配方案。无论研究大模型应用的算法工程师、学习检索增强技术的研发人员,还是需要选型知识库方案的产品从业者,都可以借助这套分析框架理清 RAG 替代方案的技术逻辑。
如何提高 RAG 召回效率和精准度?本篇思维导图从知识库处理,到查询优化,到混合检索,再到精排召回,每一步都可以在不增加 LLM 负担的前提下提高召回质量。在知识库处理阶段,可通过知识库问题生成与检索向量化、对话知识沉淀、知识库质量校验、版本管理与性能对比,提前清洗、优化知识库内容,减少脏数据对检索的干扰,夯实底层数据基础。查询优化环节,采用多 Query 策略,借助大模型对原始查询进行改写、扩展,丰富检索维度,挖掘用户真实意图。检索层面使用混合检索策略,融合 BM25 关键词检索与向量检索,兼顾语义匹配与关键词命中,弥补单一检索方式的缺陷。检索完成后接入重排模型,对初步召回的候选文档做二次打分筛选,过滤无关片段,进一步提升结果精准度。导图还拓展了 GraphRAG 与 Agentic RAG 进阶方案,GraphRAG 依托知识图谱挖掘文本实体关联,适合复杂全局推理;Agentic RAG 将检索交给智能体,自主完成多轮检索规划。整套优化链路将工作量前置在检索环节,不额外增加大模型输入 token,减轻 LLM 处理压力。
多模态 RAG 是推动 AI 从单纯内容生成走向 Agent 智能体的关键路径,本次思维导图分享完整拆解迪士尼 RAG 助手的全链路构建流程。项目以搭建多模态 RAG 系统为核心,可处理文本、图片、视频等多种格式数据,解决非结构化数据处理、跨模态知识召回难题。流程分为三大核心阶段:首先是数据解析与向量化,对 Word、PDF 等文档解析,依托多模态 Embedding 模型,将文本、图像、视频转化为统一维度向量;其次构建统一 FAISS 向量索引,把不同模态向量存入同一向量空间,实现跨模态检索;同时搭配多种文档切片策略,切片作为检索质量基石,可按需选择方案优化召回效果。在查询推理环节,系统加入意图检测、相似度阈值过滤、智能 Query 处理,筛选有效检索素材,再交由大模型整合信息输出答案,实现 “以文搜图”“以图搜文”,让 AI 具备自主检索、筛选信息的能力,不再局限于简单生成文本。能力进一步延伸到 AI 辅助办公,可用于汇报材料制作,利用 AI 生成配图、借助 LLM 重塑工作流,高效产出图文素材。整套体系让 AI 拥有自主理解任务、检索外部资料、规划执行任务的能力,完成从被动生成到主动执行的转变。无论大模型开发学习者、AI 技术从业者,还是希望用 AI 优化汇报工作的职场人员,都可以参考这套落地方案。
社区模板帮助中心,点此进入>>
传统 RAG 遇挑战,三大替代技术谁主沉浮?本思维导图先剖析传统 RAG 固定流水线的本质缺陷,传统 RAG 依靠查询向量化、向量检索、拼接检索文本再送入大模型生成答案,整套流程固化,存在检索成本偏高、文本总结能力有限等短板,面对复杂企业知识库场景时容易出现信息遗漏、检索不准等问题。再深度解读超长上下文、Agentic Retrieval、LLM Wiki 三大技术及其适用边界。超长上下文技术依托大模型不断扩容的记忆容量,直接将完整文档作为输入,省去向量检索环节,适合小规模知识库,但存在 token 成本上涨、长文本中间信息遗忘等局限。Agentic Retrieval 智能体检索将检索升级为推理任务,构建思考、行动、观察的循环,依靠工具链自主规划、分步完成复杂查询,适配企业多步骤复杂检索需求。LLM Wiki 知识导航系统具备页面级语义存储、实体关系构建能力,支持知识动态更新,适合长期沉淀专业知识。最后给出技术选型指南,明确三大新技术并非全面取代 RAG,各自拥有适用场景与局限性,RAG 仍是企业级应用基石,企业可结合知识库规模、查询复杂度、成本预算灵活搭配方案。无论研究大模型应用的算法工程师、学习检索增强技术的研发人员,还是需要选型知识库方案的产品从业者,都可以借助这套分析框架理清 RAG 替代方案的技术逻辑。
如何提高 RAG 召回效率和精准度?本篇思维导图从知识库处理,到查询优化,到混合检索,再到精排召回,每一步都可以在不增加 LLM 负担的前提下提高召回质量。在知识库处理阶段,可通过知识库问题生成与检索向量化、对话知识沉淀、知识库质量校验、版本管理与性能对比,提前清洗、优化知识库内容,减少脏数据对检索的干扰,夯实底层数据基础。查询优化环节,采用多 Query 策略,借助大模型对原始查询进行改写、扩展,丰富检索维度,挖掘用户真实意图。检索层面使用混合检索策略,融合 BM25 关键词检索与向量检索,兼顾语义匹配与关键词命中,弥补单一检索方式的缺陷。检索完成后接入重排模型,对初步召回的候选文档做二次打分筛选,过滤无关片段,进一步提升结果精准度。导图还拓展了 GraphRAG 与 Agentic RAG 进阶方案,GraphRAG 依托知识图谱挖掘文本实体关联,适合复杂全局推理;Agentic RAG 将检索交给智能体,自主完成多轮检索规划。整套优化链路将工作量前置在检索环节,不额外增加大模型输入 token,减轻 LLM 处理压力。
多模态 RAG 是推动 AI 从单纯内容生成走向 Agent 智能体的关键路径,本次思维导图分享完整拆解迪士尼 RAG 助手的全链路构建流程。项目以搭建多模态 RAG 系统为核心,可处理文本、图片、视频等多种格式数据,解决非结构化数据处理、跨模态知识召回难题。流程分为三大核心阶段:首先是数据解析与向量化,对 Word、PDF 等文档解析,依托多模态 Embedding 模型,将文本、图像、视频转化为统一维度向量;其次构建统一 FAISS 向量索引,把不同模态向量存入同一向量空间,实现跨模态检索;同时搭配多种文档切片策略,切片作为检索质量基石,可按需选择方案优化召回效果。在查询推理环节,系统加入意图检测、相似度阈值过滤、智能 Query 处理,筛选有效检索素材,再交由大模型整合信息输出答案,实现 “以文搜图”“以图搜文”,让 AI 具备自主检索、筛选信息的能力,不再局限于简单生成文本。能力进一步延伸到 AI 辅助办公,可用于汇报材料制作,利用 AI 生成配图、借助 LLM 重塑工作流,高效产出图文素材。整套体系让 AI 拥有自主理解任务、检索外部资料、规划执行任务的能力,完成从被动生成到主动执行的转变。无论大模型开发学习者、AI 技术从业者,还是希望用 AI 优化汇报工作的职场人员,都可以参考这套落地方案。
可能替代RAG的技术
一、传统RAG的本质
固定流水线
Query提问 → Embedding向量化 → Search向量检索 → Top-k截取 → 生成答案
关键缺陷
检索逻辑在运行前就已固化(策略、召回数量等参数写死),强大的LLM在其中仅充当"文本总结者",完全被动读取结果,不参与任何检索决策。
二、三大"替代"技术深度剖析
1. 超长上下文(Long Context)
核心逻辑
利用大模型不断扩展的"记忆容量",将完整文档库直接作为上下文输入,绕开检索与拼接步骤。
核心洞察
宣传的上下文窗口多为理论最大值,受注意力衰减影响,实际有效利用率仅约25%。
主流模型预训练窗口对比
适合替代的场景
小型知识库(几十至几百万Token)
单文档强相关(合同、财报)
高精度理解(表格、代码逻辑)
无法替代的局限:
海量知识库塞不进窗口
Token成本指数上升
注意力衰减导致的"中间遗忘"效应
可以用一句话先记住:注意力机制就是让模型在处理一段话时,不是平均地看每个词,而是自动判断哪些词更重要,并重点“关注”它们。 通俗理解:它像“智能划重点” 比如这句话: “小明买了苹果,他把它吃了。” 人类读到“它”时,会自然回头找:这个“它”指的是“小明”还是“苹果”?你会很快发现,“它”和“苹果”关系更强,所以重点看“苹果”。 注意力机制就是让模型也做类似的事: 对每个词,都去句子里其他词那里“扫一遍”,算出谁跟它关系最紧,然后给重要的词更高权重,给不重要的词更低权重。 核心机制:Query、Key、Value 注意力机制最关键的三个概念是 Q、K、V: Query “我想找什么信息?” “它”想找前面指代的是谁 Key “我能提供什么信息?” “苹果”的标签是“食物、被买、被吃” Value “我实际包含的内容是什么?” “苹果”的完整语义信息 计算过程可以分成四步: 生成 Q、K、V 每个词通过线性变换得到自己的 Query、Key、Value 向量。 算相似度 用当前词的 Q 去和句子里所有词的 K 做点积,看看谁跟它更匹配。 Softmax 归一化 把相似度变成一组权重,比如 0.7、0.2、0.1,加起来等于 1。 加权求和 用这些权重去组合所有词的 V,得到当前词新的表示。这样,“它”就不再只是“它”本身,而是融合了“苹果”的信息。 公式是:  其中除以 是为了防止向量维度太高时,点积数值过大,导致 Softmax 梯度不稳定。 为什么需要多头注意力? 单头注意力相当于只从一个角度理解句子。 多头注意力就是把 Q、K、V 拆成多组,并行计算,再拼起来。 比如同一句话: 一个头可能关注语法结构:主语、谓语、宾语; 一个头关注语义关系:苹果、吃、食物; 一个头关注指代关系:它 → 苹果。 这样模型能从多个视角理解文本,表达能力更强。 自注意力和交叉注意力的区别 自注意力:同一句话内部,词与词互相看。比如“它”去找“苹果”。 交叉注意力:两个序列之间互相看。比如翻译时,解码器生成“苹果”时,会重点看编码器里的“apple”。 因果注意力:生成文本时只能看前面的词,不能“偷看”后面的词,保证生成是自回归的。 它解决了什么问题? 在注意力机制之前,RNN 这类模型是逐字处理句子的,句子太长时容易“记不住前面”。注意力机制让模型可以直接看到整个序列,并行计算,也能更好地捕捉长距离依赖。 可以把它理解成: RNN 像逐字朗读,Transformer 像一眼扫完整句,然后自动给关键信息打高亮。 但要注意:注意力机制本身并不负责检索,它更擅长在已经拿到的上下文里做加权理解。检索部分通常还是靠向量检索、BM25、混合召回这些机制完成。 “注意力衰减”这个词在 LLM 里有两层意思: 狭义上,指位置编码或注意力机制里人为加入的“距离越远、权重越低”的衰减偏置; 广义上,也常被用来描述长上下文里模型注意力资源被稀释,导致中间信息越来越难被利用的现象,也就是常说的 上下文衰减 / Context Rot / Lost in the Middle。 1. 狭义:位置编码里的“衰减” Transformer 的自注意力本身只看内容相似度,不天然知道“谁离谁远”。所以需要用位置编码把位置信息塞进去。 常见做法有两种: ALiBi 在 attention score 上加线性偏置,距离越远惩罚越大 让模型天然更关注近处 token,提升长度外推能力 RoPE 通过旋转 q、k,让点积里自然带上相对位置差 不直接“衰减”,但距离变化会影响相似度 ALiBi 比较接近“衰减”的直觉:两个 token 距离越远,attention logit 上就被减去越多,从而降低它们之间的注意力权重。 RoPE 则是把位置信息编码成旋转角度,点积时自动体现相对距离,不一定单调衰减,但会让远距离 token 的匹配关系发生变化。 2. 广义:长上下文里的注意力稀释 这是工程里更常遇到的情况。LLM 生成每个 token 时,都会对上下文里所有 token 计算注意力权重;这些权重经过 softmax 后会归一化,总和是 1。 所以,当上下文从 500 token 变成 50,000 token 时,即使某个关键信息仍然很重要,它分到的注意力权重也可能被大量无关 token 稀释。 典型表现是 Lost in the Middle: 信息在开头,模型更容易看到; 信息在结尾,模型也更容易看到; 信息埋在中间,尤其上下文很长时,召回率会明显下降。 这不完全等同于“中间位置一定权重更低”,而是长上下文里注意力分配变得不稳定:噪声增多、冲突信息增多、位置偏置增强,都会让模型更难抓住关键内容。 3. 对你做 RAG 的影响 你在做测试规程这类长文档 RAG 时,注意力衰减主要会带来三类问题: 关键条款被淹没 比如把 10 个 chunk 一起塞进 prompt,真正的那一段如果在中间,可能被忽略。 冲突信息更难分辨 不同版本标准、不同章节的参数混在一起时,模型可能不再稳定引用正确段落。 Top-K 越大不一定越好 盲目把检索结果全部塞进上下文,反而可能降低准确率。 4. 工程上怎么缓解 先检索,再压缩:不要把所有召回 chunk 原样塞进 prompt,用 Reranker 或规则过滤掉低相关、重复、冲突片段。 控制上下文长度:只保留真正支撑答案的证据,而不是堆满窗口。 把关键信息放在更可靠的位置:问题、约束、最重要证据尽量靠近开头或结尾。 chunk 级去重与版本校验:结合前面说的哈希值,避免同一内容多个版本同时进入上下文。 评测不同位置策略:不要机械认为“证据必须放开头”,不同模型、不同任务表现可能不同,最好用你的国标问答集实测。
2. Agentic Retrieval(智能体检索)
本质转变:Retrieval becomes Reasoning(检索即推理)。LLM从被动工具变为主导者,自主决策:
搜什么:模糊问题 → 精准搜索指令
何时搜:判断背景知识是否充足
下一步搜什么:根据信息缺口动态规划
停止/迭代:评估证据充分性与矛盾
核心架构
从"Retrieve Once"(一次性检索)进化为"Reason-Retrieve Loop"(推理-检索循环)。
经典实现
ReAct Pattern —— Thought(思考)→ Action(行动)→ Observation(观察)闭环,直到获得足够信息。
企业案例(退款率升高排查)
Agent自主串联日志分析 → 发现支付宝接口异常 → 再排查版本更新 → 锁定根因。
五层架构:
工具层(Tool)
规划器(Planner)
记忆层(Memory)
推理循环(Reasoning Loop)
执行运行时(Execution Runtime)
适用场景
复杂故障根因分析、跨系统咨询、客服疑难处理("查多步·跨系统·找根因")。
3. LLM Wiki(知识导航系统)
核心思想
保留知识的原始结构,而非切碎成碎片,为LLM构建可阅读、可导航的完整知识空间。
本质是知识定义的范式跃迁——从"被动存储"到"持续演化的动态系统"。
五大核心能力:
页面化:以页面为单位保留语义完整(区别于无边界Chunk)
双向链接:借鉴维基百科,构建实体关联网络,支持多跳推理
多跳推理就是:一个问题不能靠一条检索或一步推理直接回答,必须沿着多个中间信息点一步步推导,才能得到最终答案。 “跳”可以理解为一次信息跳转或一次推理步骤。比如: 张三所在公司的去年营收是多少? 单靠“张三”这个信息,没法直接回答。系统需要先跳到“张三所在公司”,再跳到“这家公司去年营收”,至少两跳才能答出来。 为什么普通 RAG 容易答不好 普通 RAG 通常是:问题 → 一次检索 → 拼上下文 → 生成答案。 但多跳问题往往需要跨多个片段、多个实体、多个关系才能连接起来。 比如国标电池测试场景里,如果问: GB/T 24554-2022 里提到的额定功率测试方法,对耐久性测试有什么影响? 这个问题就不是简单查一个条款能解决的。可能需要: 找到“额定功率测试方法”相关条款; 找到“耐久性测试”相关条款; 再判断两者之间是否存在引用关系、条件依赖或参数约束。 这就是典型的多跳。 常见的多跳推理形式 实体接力 张三的公司 → 公司营收 答案不在同一段落 条件链 A 触发 B,B 影响 C 需要保持因果链不断裂 跨文档整合 标准条款 + 测试报告 + 产品手册 需要跨来源对齐 约束推理 满足条件 X 且满足条件 Y 不能只命中其中一个 常见做法有几类: 迭代检索 先检索一次,拿到中间信息;再根据中间结果生成新查询,继续检索。 问题分解 把复杂问题拆成多个子问题,分别检索后再合并。 知识图谱增强 把文档里的实体和关系抽出来建成图,然后沿着图做多跳扩展。 重排与证据聚合 多跳召回后,用重排器筛选真正支撑答案的片段,避免把噪声堆进上下文。 需要注意的风险 多跳推理越深,越容易出错。中间任何一跳检索失败、实体识别错误、关系判断偏差,都可能导致最终答案跑偏。 所以工程上通常会加几道保险: 限制跳数,避免无限循环; 对中间结果做校验; 保留证据来源,便于追溯; 资料不足时允许模型拒答,而不是硬编。 一句话概括:单跳是“直接查到答案”,多跳是“先找到中间线索,再顺着线索继续推理”。 在你做国标 RAG 时,凡是涉及“条款之间引用关系”“测试条件影响”“参数依赖链”的问题,基本都属于多跳推理范畴。
层级目录:让LLM先定位大类再聚焦细节
实体关系:抽取结构化实体与关系,构建知识图谱(Neo4j)
自动摘要+自动索引:多级摘要、混合搜索(BM25+Vector+Graph)
三层架构(Karpathy提出):
Raw Layer(原始数据湖)
Wiki Layer(编译输出层)
Schema Layer(控制协议)
核心转变
从"查询时理解"转向"摄入时编译"(Ingest-time Intelligence)
知识更新机制:
外部事件驱动(数据变更、Schema迭代)
内部逻辑驱动(连锁反应、自动同步)
从"Append-only新增"升级为"Recompilation重构"
现实挑战
构建成本高
知识更新难(级联失效)
不适合超实时数据
三、总结与展望:技术选型指南
三大技术均未真正"取代"RAG,而是各有适用边界
面对海量知识,RAG仍是企业级应用的基石
超长上下文适合小型单文档场景
Agentic Retrieval适合复杂推理任务
LLM Wiki适合需要长期沉淀与强关联的企业知识资产