本地RAG框架横评：LangChain vs LlamaIndex

8s 条评论

1. 

   午后续命水 成长9,188 2026年7月9日 13:00

   LlamaIndex 索引那步确实快，但 v0.2.0 配合 Cohere Embeddings 做混合检索时，mrr 分数高 15% 也是实打实的。LangChain 赢在 rerank 阶段接 BGE 方便，端到端效果还得看这一步。

2. 

   一句封神 绽放16.2k 2026年7月8日 22:08

   emmm 其实还有个关键点是 rerank 模型的选择，langchain 接 bge-reranker 比较方便，llama_index 得自己写 pipeline。单纯比检索器意义不大，端到端的效果还得看重排序后的 mrr@10。

3. 

   P值小于0.05 成长11.4k 2026年7月8日 14:40

   P@10 才是硬指标，别只看召回。LangChain 重排序后准确率稳在 85%，LlamaIndex 容易误报。图表我放上面了。

4. 

   需求又改了 成长11.7k 2026年7月8日 13:57

   LlamaIndex 配 ChromaDB 确实省事，LangChain 调参门槛太高，客户哪有空跟你磨？这玩意交付才是王道，别整那些虚的。

5. 

   Debug到秃头 绽放12.1k 2026年7月7日 15:25

   @周报难产中 刚用 v0.1.23 复现了一下，LlamaIndex 的 SimpleDirectoryReader 对 PDF 切块确实稳，但 LangChain 在自定义 Document Transformers 上更灵活。我这边用 v0.2.0 试了 Cohere Embeddings，混合检索的 mrr 分数比单用向量高 15% 左右，调参门槛高但上限也高。

6. 

   路过点个赞 绽放13.2k 2026年7月8日 12:48

   引用 Debug到秃头

   @周报难产中 刚用 v0.1.23 复现了一下，LlamaIndex 的 SimpleDirectoryReader 对 PDF 切块确实稳，但 LangChain 在自定义 Document Transformers 上更灵活。我这边用 v0.2.0 试了 Cohere Embeddings，混合检索的 mrr 分数…

   跑 v0.1.23 时记得加 metadata_filtering，不然 LlamaIndex 在十万级文档检索上延迟能飙到 2s 以上，这点 LangChain 封装得更顺手。

7. 

   五百一天Ken 成长11.9k 2026年7月7日 12:32

   这俩在私有库场景确实是宿敌。LlamaIndex 做数据索引确实快，但 LangChain 的组件编排能力没得黑，尤其是你要接外部 API 的时候。上次给客户搭方案，用 LangChain 搞了个混合检索，虽然调参调得我头秃，但交付质量确实稳，这钱花得值。

8. 

   路过点个赞 绽放13.2k 2026年7月7日 08:58

   @周报难产中 我也测过，LlamaIndex 确实对向量数据库适配更丝滑。不过 LangChain 的 Agent 模式在需要动态调用工具的场景下，比它强不少。看你是重检索还是重推理了。