引言

最近在折腾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了，每个最小层级标题下的内容本身就是一个chunk（llm做了详细的层级拆解，目前没有遇到超长chunk的情况，那就先这样）。

由于这些树的节点本身蕴含了非常丰富的语义信息，因此，在做相似度检索时，直接把query和这些节点（也就是层级标题）做相似度计算就好了。然后选择相似度top-k个节点，把对应的chunk全取出来，去重后直接作为召回的chunk。

最后，再把传统的RAG作为一路召回分支，集成到上述方案中，就得到了基于树的双路召回方案，两路召回结果去重后，丢给llm等待答案输出就好了。

五、最终方案：从原始文件到Tree RAG知识库

先建数据库，建库分两步。

第一，针对多种格式不同来源的文件，vibe一个基于web的平台，实现从“源文件–>原始信息提取–>llm层次化整理”的“一键批量执行”。

第二，把第一步得到的.md文件按照如上所述基于树的方法存入向量数据库。我的向量数据库用的是milvus，基于docker部署。

入库时，记录每个chunk的父节点和完整的祖先路径等多维度信息，方便后续检索。

建库完成后，直接查询就好了。

六、后来我发现：PageIndex居然也是这么干的

逛GitHub发现，一个叫做PageIndex的开源项目也采用了基于树的RAG方案，不过它这个更彻底，直接弃用了embedding相似度计算那一套，转而全面拥抱了agent。

同样基于llm，PageIndex将每个文档抽取成一棵树，树的每个节点都配备对该节点的一段文字描述（有点像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%免费】