LlamaIndex 框架指南
LlamaIndex 最适合那种“问题不在模型，而在数据怎么进、怎么切、怎么查”的项目。你如果已经意识到 RAG 的难点不是聊天框，而是检索链路，那这类框架就会开始有价值。
很多团队一开始只看到“能接很多数据源”，真正用起来以后才发现，它更重要的价值其实是让检索流程变得比较可控。
如果把 LLM 比作“很会说话但记性一般的同事”，LlamaIndex 更像“负责档案、检索和调度的资料管理员”。它不替你定义业务目标，但能决定回答时到底把哪些材料递到模型面前。
#它最适合什么情况
- 数据源很多，而且大多是非结构化文档
- 你已经不满足于“向量检索 + 直接生成”的最小 RAG
- 你需要可控一点的检索流程，比如 metadata 过滤、重排、路由、多索引
如果你现在只是做一份小文档 demo，其实先用最简单的检索链路就够了，不一定非要一上来把 LlamaIndex 的高级组件全搬出来。框架越全，越要克制。
#为什么有人会从 LangChain 转到 LlamaIndex
不是因为它“全面替代 LangChain”，而是因为它在数据索引、检索和 RAG 这条线上更聚焦。很多项目做到后面会发现：
- 链路能跑，不等于检索质量够用
- 工具很多，不等于排错容易
- Agent 很热闹，不等于来源足够可靠
这时候，LlamaIndex 这类更偏检索的框架会更顺手。
说白了，如果你已经从“怎么接大模型”走到“怎么把资料找准”，那它就会比通用编排框架更对味。
#学习顺序
我还是建议按这个顺序来。很多人一开始最想看“高级检索”，但真正决定你后面稳不稳的，通常是索引和节点怎么建。
#一个更像真实项目的落地路线
- 先做单数据源、单索引、单问答链路
- 再补 metadata 和来源可追踪
- 然后引入多数据源和检索优化
- 最后才评估重排、路由和复杂查询拆分
顺序别反。先把基础召回做稳，比一开始上太多高阶组件更重要。
#项目里最常见的两个误区
#误区一：检索效果差，就马上换模型
很多时候不是模型差，而是文档切块、metadata 和 query rewrite 根本没设计好。
#误区二：看见高级组件就全接
Router、Sub-Question、Rerank 这些都很有用，但它们不是“默认越多越好”。组件一多，链路更难观测，排错成本也会上去。
#一句更实用的判断
如果你的问题是“怎么让私有数据更稳定地被查到、被引用、被回答”，LlamaIndex 值得看。
如果你的问题只是“怎么先做个能问答的 demo”，那先别急着上完整框架也没问题。
