基础RAG能解决80%的问题但剩下20%的难题需要更进阶的技术。一、基础RAG碰到了什么天花板基础RAG的套路很简单文档切块 → Embedding → 向量检索 → 拼接Prompt → 大模型生成答案。简单场景够用但往深了用三个问题绕不开。孤立片段处理不了关联。文档切成Chunk后每块独立检索也只能捞出孤立内容。碰上《论文A》和《论文B》观点有什么异同这类问题基础RAG就抓瞎了。缺乏深层语义理解。它只会找相关段落多跳推理、跨文档对比这些复杂动作做不了。搞不定领域特有的关系。法律、医疗、金融里实体之间的关系高度领域化纯文本检索摸不到这层。这几个问题把RAG逼出了几条进化路线。二、GraphRAG用知识图谱把关系显式建出来2.1 为什么孤立片段是致命的一个典型失败场景法律AI里用户问这份合同里的保密条款和《数据安全法》哪些规定相关基础RAG会分别检索保密条款和数据安全法的文档拼接在一起扔给大模型。但大模型根本不知道这两者之间有什么具体关系很可能找错关联或遗漏关键条文。文档之间的关系是隐式的基础RAG没有建模手段。2.2 GraphRAG的核心做法把文档之间的关联关系显式构建出来作为检索的一部分。实体抽取用LLM或NER模型从文档中提取实体——人物、组织、概念、法规条款。关系抽取用LLM分析实体之间的关系例如数据安全法规范个人信息“合同包含保密条款”。知识图谱 图检索用户提问时不仅检索相关Chunk还检索相关的实体和关系路径。比如问哪些法规和合同保密条款相关系统找到保密条款实体 → 沿关系路径找到相关实体“个人信息”→ 找到规范这些实体的法规“数据安全法”→ 返回关联路径和对应文档。2.3 什么场景值得用GraphRAG的优势在关联推理场景非常明显。效果数据问题类型基础RAGGraphRAG提升“A和B是什么关系”33%71%38%“涉及X的所有法规有哪些”28%75%47%“找出A→B→C的关联路径”15%68%53%简单事实问答82%85%3%问题越依赖关联关系GraphRAG优势越大。简单问答两者差别不大。适合的场景关联密切的领域法律、医学、金融、多跳推理问题、需要比较类回答。不建议的场景简单FAQ、单一文档问答、不依赖关联的检索场景。务实的起步方式先用基础RAG跑 → 找出高频的关联推理问题 → 优先为这些问题构建图谱用小图谱大检索的混合架构。全量图谱成本很高不要一开始就铺。三、HyDE让大模型猜答案再检索3.1 思路HyDEHypothetical Document Embedding的做法很巧妙先让大模型生成一个假答案再拿这个假答案去找相关文档。传统检索Query → 向量检索 → 返回文档 HyDE检索Query → 大模型生成假答案 → 向量检索 → 返回文档用户的问题往往很短语义信息不足直接检索容易召回不准。HyDE先生成一段完整的假答案——包含了完整语义的描述拿去检索反而更容易命中真正相关的文档。3.2 适用和局限适合用户问题表述模糊、问法和文档表述差异大多语言场景、同义词多、需要召回语义相近但字面不同的文档。局限多一次大模型调用增加延迟和成本大模型猜错时检索会跑偏。建议HyDE作为混合检索的一路和正常检索一起用用RRF融合两路结果。这样HyDE出问题也不影响整体。四、Self-RAG让大模型自己决定要不要检索4.1 核心问题基础RAG有一个隐藏浪费不是所有问题都需要检索。有些问题大模型自己就能答好但基础RAG一律走检索既浪费资源又可能引入干扰。Self-RAG解决的是这个问题让大模型自己判断是否需要检索以及检索结果有没有用。4.2 机制Self-RAG引入了特殊的Reflection Token大模型在回答过程中输出•Retrieve我需要检索•Relevant这条检索结果和问题相关•Supported检索结果能支持我的回答•Utility这个回答对我有帮助最终回答可以附带这些Token的判断结果可追溯、可解释。4.3 效果和适用场景• 减少不必要的检索降低延迟和成本• 只有真正相关的检索结果才会被使用回答质量更高• 每个回答可追溯是否检索了、“检索是否有效”适合大规模知识库检索成本高、对回答质量要求高的场景。局限需要微调模型来识别Reflection Token标准API无法直接实现。五、Code-RAG代码场景的专门设计5.1 代码检索的特殊挑战技术文档RAG里代码检索有几个不一样的问题•上下文依赖一个函数名单独出现没有意义需要完整的函数定义•版本和语法差异Python 2和Python 3语法不同混淆了会出问题•层级结构代码不是平铺文本有函数、类、模块的层级•语义和字面不匹配用户问如何并发处理代码里可能写的是threading实现5.2 关键设计Chunk策略按函数/类/文件边界切分不要简单按行数切。整个函数作为最小单位包含定义、注释、调用关系。破坏函数完整性的切分方式要避免。Embedding模型通用Embedding对代码效果差需要专门的代码模型。常用方案CodeBERT微软出品、GraphCodeBERT加入AST结构信息、Cohere/codeCohere多语言代码Embedding、国产的若问代码Embedding有中文优化。检索多路并进代码语义检索Embedding 关键词检索文档注释、变量名 文档检索README、API文档 示例检索具体用法、完整可运行代码。5.3 建议代码和文档分开处理用不同的Chunk策略和Embedding模型。每个代码Chunk要包含完整的函数定义和必要的调用关系检索结果最好能提供完整可运行的代码片段。六、行业黑话文档怎么搞RAG6.1 问题在哪企业内部文档常有大量行业黑话和内部术语——外部人完全陌生但内部人习以为常。• 外部Embedding模型不懂Q1行动、三个一工程是什么意思• 同一个词内部和外部的理解完全不同• 理解这些术语需要背景知识不是简单翻译能解决的6.2 三种解法解法一术语词典 Query扩展最小成本立即见效维护一个术语词典术语 → 解释/同义词检索前用词典扩展Query用户QueryQ1行动是什么 展开为Q1行动 OR 第一季度重点行动方案同时在文档里标记术语检索时也做展开两端对齐。解法二领域自适应Embedding用领域数据微调Embedding模型让它学会内部术语。用对比学习Contrastive Learning微调后在内部Query上测试召回效果。适合内部术语量大、高频使用、效果收益明显的核心场景。成本高不建议一开始就做。解法三知识图谱 术语映射用知识图谱建立术语之间的关联关系三个一工程节点连接集团年度重点项目、涉及部门、相关政策、历史沿革。检索时自动带上关联上下文。这个方案和GraphRAG结合最好适合复杂查询场景。建议的建设顺序先建术语词典 → 再考虑知识图谱 → 最后考虑微调Embedding。术语词典要持续维护知识图谱需要领域专家参与定义关系。七、多模态RAG不止文本7.1 需求现代文档不只是纯文本还有图片、表格、图表、流程图甚至视频和音频。• 技术文档里一张架构图胜过千字• 财务报告里表格包含核心数据• 培训视频里有大量讲解和演示基础RAG只能处理文本这些多模态内容全部浪费了。7.2 各个模态的处理方式图片用CLIP、BLIP等多模态模型将图片转成向量同时提取图片描述文本存两份索引。检索时图片向量检索和图片描述文本检索两路并进。表格用专门的表格解析模型如TaBERT提取内容转成结构化文本“表格行1列A是X列B是Y”或者把表格关键数据单独建索引。图表和流程图用OCR图像描述模型提取内容复杂图表可以让LLM做描述总结同时保存原图检索到描述后呈现原图。视频/音频用Whisper做语音转文字提取关键帧做图片索引检索时文字匹配、视频/音频呈现。7.3 分阶段做多模态RAG成本和复杂度都较高建议分阶段八、写在最后RAG还在快速演进几个值得持续关注的方向Agent RAGRAG不只是检索→生成而是让Agent主动决定何时检索、检索什么、如何使用检索结果。RAG从一个被动工具变成主动推理组件这是质变。长上下文RAG上下文窗口越来越大100K tokensRAG的形态会随之变化——不再需要激进的压缩和筛选可以直接给大模型喂更多上下文Chunk策略也会跟着调整。实时学习RAG知识库不再是静态的而是可以实时更新、增量学习和大模型同步演进。多模态原生RAG从一开始就把文本、图像、音频、视频作为原生输入不是分别处理再融合——这是架构层面的变化。基础RAG是起点不是终点。选择哪个进阶方向取决于你的场景瓶颈在哪里。文章首发于 「小小寰宇」