我开始怀疑RAG了：从GraphRAG到TreeRAG的一次踩坑实录

引言最近在折腾RAG从最传统的“切chunk embedding检索”一路试到GraphRAG、LightRAG最后发现很多问题可能根本不在模型而在“文档结构”本身。尤其在制度、流程、医疗这类强结构化场景里Chunk切分会破坏上下文Graph又容易被高频关键词污染。后来我换了个思路不再重点“建图”而是先让LLM把文档重新整理成层级清晰的Markdown再基于标题结构“建树”做检索。效果居然稳定了很多。更有意思的是后来逛GitHub时发现PageIndex这个30k star的项目也在往类似方向发展只不过它更进一步直接让Agent去探索文档树彻底抛弃了embedding那一套流程。这篇文章主要记录一下我从传统RAG一路踩坑到开始重新思考“Tree RAG / Agentic RAG”的整个过程。一、 传统RAG切块、向量化然后开始“碰运气”最近在做RAG把“切块 -- 向量化 -- 相似度检索”这一套尝试一通后发现召回的chunk大都是与query不相关的。无它唯幻觉尔emm…二、GraphRAG和LightRAG更复杂了但没强多少既然上述传统RAG不好用那就试试比较火的GraphRAG吧。又是一通调研发现微软开源的GraphRAG有个致命缺点慢 贵。接着调研发现了HKU开源的轻量级LightRAG。是的这名字听上去就很“轻量”。于是直接git拉代码一顿操作终于部署到本地RTX 3060设备上了。把代码跑起来进入到LightRAG的web界面上传了好几个本地文件啥格式都有。等待处理等待几分钟后处理好了知识库准备完毕。LightRAG设置了好几种检索模式我测试了推荐的“混合模式”也就是将多种召回方式的结果综合一下作为最终的召回结果。看了它召回的chunk比传统RAG那一套稍微好了一点但因为没有做系统化的评测也只是随机选了几个问题用瞪眼法来评估的所以有很大的主观性。即使是好了一点也只是好了“一点”远远达不到落地可用的水平。三、问题到底出在哪算法还是数据RAG这东西和模型训练的针对性优化方向是相似的数据 算法先来看数据。我的数据啥格式都有我用微软开源的markitdown统一成了markdown格式直接喂给RAG框架。仔细查看转换后的markdown文件发现很多层级标题都是乱的而且还带着各种脚注、页码、页眉等信息。这逆天的数据混乱程度。再来看算法。这里的算法更像是搜索算法本质上就是做基于“相似度计算”的召回后续把与query比较相似的chunk统统取出来丢给llm等llm吐答案给到用户就好了。传统RAG的query就是用户的问题LightRAG的query表面上也是用户的问题但是内部会根据用户问题拆解出来好几个关键词实体节点和关键词值之间的联结实体关系边。在“混合检索”模式下最终用于检索的query实体关系原始query兵分多路做检索还会基于“Graph”结构做多跳查询最后再做合并归纳。算法貌似没啥大问题。再看数据。除了数据混乱外每个chunk都是按照固定长度切分的万一把关键句子给截断了那么整个chunk的embedding向量的语义就变了。此外用户提问的问题肯定先强制肯定都是基于这些数据所包含的内容的在我这个应用场景下专门针对应用场景分析下用户query的某些“语义信息丰富”的关键词其实会频繁的出现在很多chunk中比如“制度”“患者”这种这就导致一部分基于关键词的查询其实是没有意义的。数据不行跳多少次也没用只是瞎猫去碰死耗子罢了。四、找到突破口了从“建图”到“建树”算法差不多就那样了而现在已经发现了数据的缺陷那就从数据入手展开优化吧。基于Graph的RAG本质上是基于文档来构建一张Light RAG是多张图具体做法是把文档丢给llm做实体抽取和关系识别。但是上面说过在我的场景里“语义信息丰富”的关键词会频繁的出现在很多chunk中所以Graph这一套不好用了。不如这样同样是把文档丢给llm但是给llm的提示词是把文档根据全文语义做重新排版生成标题层次清晰标题语义明确的markdown文件。标题通常很短噪声很少语义很集中。这样一来每个标题本身就蕴含了丰富的语义信息这些层级标题天然的形成了“一棵树”三级标题是三级标题对应chunk的父节点三级标题对应chunk的祖先路径节点是一级标题–二级标题–三级标题。同时也不用再手动切分chunk了每个最小层级标题下的内容本身就是一个chunkllm做了详细的层级拆解目前没有遇到超长chunk的情况那就先这样。由于这些树的节点本身蕴含了非常丰富的语义信息因此在做相似度检索时直接把query和这些节点也就是层级标题做相似度计算就好了。然后选择相似度top-k个节点把对应的chunk全取出来去重后直接作为召回的chunk。最后再把传统的RAG作为一路召回分支集成到上述方案中就得到了基于树的双路召回方案两路召回结果去重后丢给llm等待答案输出就好了。五、最终方案从原始文件到Tree RAG知识库先建数据库建库分两步。第一针对多种格式不同来源的文件vibe一个基于web的平台实现从“源文件–原始信息提取–llm层次化整理”的“一键批量执行”。第二把第一步得到的.md文件按照如上所述基于树的方法存入向量数据库。我的向量数据库用的是milvus基于docker部署。入库时记录每个chunk的父节点和完整的祖先路径等多维度信息方便后续检索。建库完成后直接查询就好了。六、后来我发现PageIndex居然也是这么干的逛GitHub发现一个叫做PageIndex的开源项目也采用了基于树的RAG方案不过它这个更彻底直接弃用了embedding相似度计算那一套转而全面拥抱了agent。同样基于llmPageIndex将每个文档抽取成一棵树树的每个节点都配备对该节点的一段文字描述有点像skills文件的description然后让agent带着用户的query去探索这棵树看看哪些节点与query高度相关通过反复的探索让agent综合分析后给出答案。七、最近用Claude Code / Cursor后我开始重新思考RAG确实agentic RAG应该是未来的趋势了。最近在用Claude Code / Cursor时我直接把query丢给agent它自己就从原始文档里面找到答案了而且给出的结果比RAG强多了。这样做的好处显而易见1直接探索原始文档没有任何的信息压缩embedding那一套直接把信息压缩到了一个向量没有任何的文本切分上下文信息被完整保留下来2这种边推理边搜索的agentic方式不再像RAG那样局限在top-k个chunk一旦llm感到困惑会让agent调用工具搜集更多信息缺啥就补啥从而减少幻觉。那既然agent自己这么厉害了PageIndex这类方案的存在又有什么意义呢有当遇到文档巨多的情况时纯agent探索的方式固然可用但是要在海量文档中找答案可不是一个简单的事情agent要执行更多轮的工具调用进行反复的思考和决策这本身是一个非常耗时耗钱(token)的事。在这个时候如果提前能把海量文档的层级抽象成“一棵树”那么agent只需要探索这棵树去找答案就好了既省钱又省时间。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】