RAG系统用Chunking还是GraphRAG？生产环境下有点纠结

两万份文档上GraphRAG确实有点重了，光实体抽取和社区摘要的维护就够三个人喝一壶的。我之前试过类似规模，最后还是退回chunking加了个bge-reranker，召回稳了不少，跨段落的坑可以用小chunk加大overlap先顶一顶。真要上图谱，建议只对会议纪要这种关系密集的子集做，别全量硬上。你们现在bad case主要集中在哪类问题上？

有没有更详细的教程推荐？

两万份文档这个量级，说实话我觉得不用急着上GraphRAG。你们三个人维护一套图抽取+实体对齐+图存储的pipeline，光是文档更新时的增量构建就够喝一壶了，更别说实体消歧这种脏活。我之前也试过类似路线，生成速度掉一半还算好的，关键是隐式关联没召回多少，反倒引入一堆噪声边，调起来比chunk还痛苦。建议先把chunk策略做细一点，别死磕固定512，技术文档按标题层级切、会议纪要按议题切，再配合small-to-big的父子块召回，跨段落问题会好不少。reranker确实值得加，bge-reranker之类的对召回质量提升挺明显，成本也就多几十毫秒。另外可以试试query改写或者多路召回，把长问题拆成子查询分别检索再合并，比硬上图谱划算。真要做关系，先拿一小部分数据跑个轻量方案验证收益，别一上来就全量建图。

2万份文档三个人维护GraphRAG有点吃力，光实体抽取的pipeline出问题就够你喝一壶的。我建议先别急着换架构，把chunk策略调细一点试试，技术文档按标题层级切、会议纪要按发言段落切，比一刀切512 tokens强不少。跨段落召回不稳的话加个reranker效果挺明显的，成本也低。真要做图谱可以先挑一两个高频查询场景做小范围验证，别一上来全量铺开。