本文记录了作者在探索RAG检索增强生成过程中从传统“切chunk embedding检索”到GraphRAG、LightRAG的尝试与不足最终发现问题的根源在于文档结构破坏上下文和关键词污染。作者提出通过LLM将文档整理成层级清晰的Markdown基于标题结构“建树”进行检索的Tree RAG方案效果显著。同时作者还发现了GitHub上的PageIndex项目也在类似方向上探索并进一步介绍了Agentic RAG的趋势和应用前景。引言最近在折腾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大模型成为越来越多程序员转行就业、升职加薪的首选很简单这些岗位缺人且高薪智联招聘的最新数据给出了最直观的印证2025年2月AI领域求职人数同比增幅突破200% 远超其他行业平均水平整个人工智能行业的求职增速达到33.4%位居各行业榜首其中人工智能工程师岗位的求职热度更是飙升69.6%。AI产业的快速扩张也让人才供需矛盾愈发突出。麦肯锡报告明确预测到2030年中国AI专业人才需求将达600万人人才缺口可能高达400万人这一缺口不仅存在于核心技术领域更蔓延至产业应用的各个环节。那0基础普通人如何学习大模型 深耕科技一线十二载亲历技术浪潮变迁。我见证那些率先拥抱AI的同行如何建立起效率与薪资的代际优势。如今我将积累的大模型面试真题、独家资料、技术报告与实战路线系统整理分享于此为你扫清学习困惑共赴AI时代新程。我整理出这套 AI 大模型突围资料包【允许白嫖】✅从入门到精通的全套视频教程✅AI大模型学习路线图0基础到项目实战仅需90天✅大模型书籍与技术文档PDF✅各大厂大模型面试题目详解✅640套AI大模型报告合集✅大模型入门实战训练这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】①从入门到精通的全套视频教程包含提示词工程、RAG、Agent等技术点② AI大模型学习路线图0基础到项目实战仅需90天全过程AI大模型学习路线③学习电子书籍和技术文档市面上的大模型书籍确实太多了这些是我精选出来的④各大厂大模型面试题目详解⑤640套AI大模型报告合集⑥大模型入门实战训练如果说你是以下人群中的其中一类都可以来智泊AI学习人工智能找到高薪工作一次小小的“投资”换来的是终身受益应届毕业生‌无工作经验但想要系统学习AI大模型技术期待通过实战项目掌握核心技术。零基础转型‌非技术背景但关注AI应用场景计划通过低代码工具实现“AI行业”跨界‌。业务赋能 ‌突破瓶颈传统开发者Java/前端等学习Transformer架构与LangChain框架向AI全栈工程师转型‌。获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】