RAG用LangChain还是LlamaIndex？刚入门有点选择困难

几百个PDF其实不算少，检索质量比框架选择更值得花时间。我两个都用过，LangChain适合快速搭原型但后期改起来确实烦，LlamaIndex的index抽象更贴合RAG场景，维护起来清爽些。不过说实话你这个规模，我更倾向直接LlamaCPP加原生Python，少一层抽象少一个坑，等真复杂了再换也不迟。生产环境的话LangChain版本升级经常breaking change，LlamaIndex早期文档和API变动也挺频繁，都得锁版本小心伺候。

几百个PDF场景不复杂，LlamaIndex够用，LangChain那套抽象后期改起来真挺折腾。

几百个PDF其实原生Python写pipeline完全撑得住，检索加拼prompt那点逻辑真没必要上框架。但要是打算长期迭代查询路由、多路召回这些，LlamaIndex的索引抽象确实比LangChain清爽，改起来不用扒三层。生产上LangChain的坑主要是版本升级API老变，还有callback那套调试起来挺绕；LlamaIndex文档少踩坑得自己啃源码。你们内部手册更新频率高吗？如果增量索引是刚需，这块值得先想清楚再选。

几百个PDF场景不复杂，我会直接上LlamaIndex，省得跟LangChain的抽象层打架。

几百个PDF的场景真心建议先别急着上框架，原生Python跑通baseline再决定。LangChain那套抽象层小项目里确实容易帮倒忙，调个prompt要翻好几层源码。LlamaIndex做索引确实顺手，但生产环境里它的callback和异步支持踩过坑，文档更新频繁时增量索引偶尔会抽风。可以先用LlamaIndex快速验证，真到维护阶段再考虑把核心逻辑抽出来自己管。

几百个PDF真不算多，我个人偏向LlamaIndex，索引抽象比LangChain清爽，改起来不用扒三层。不过上生产的话，LlamaIndex的坑主要在增量更新和版本迭代太快，接口说变就变。LangChain生态确实香，但你这种场景封装反而是负担，调个retriever都得绕半天。其实原生Python加LlamaCPP也不是不行，就是后面想加rerank、多路召回时得自己造轮子，看你能不能接受。