最近关于结合知识图谱的呼声不绝于耳，以微软代表的GraphRaG落地极其难，为啥没人用，做了一堆社区，摘要社区啥的，为了解决摘要，以及实体扩招问题，但成本太高，收效很小，所以大家也就丢弃了，换来的是纯关键词构图，就结束了。- 至于KAG，也是把KG那套也搬进来了，明曰，做逻辑推理，但这又是长尾现象【私域另说】，所以也扔一边了。
- 再说到这个pikeRAG，工作想的很全面，挺面面俱到了，但是环节太多，定的太细，还分等级。虽然表现出来在一些测试榜单上要比之前的vanilla rag以及Graphrag要好，但要注意，所用的评测数据集，其实和大家真实落地的问题gap很大，所以，也是纯学术意义。落地也是不敢用的。
- 这些GraphRAG框架的意义，其实目的是贡献思路，而非贡献落地方案，其实是两码事，大家要清楚这一点哦。
那么如何正确看待RAG，RAG应该要越做越简单，而不是越来越臃肿，越复杂。大道至简，二八定律。到终极方案，也是大家所期望的，就是超级无敌长文本llm，丢进去问就完了。只是目前做不到，长路漫漫。我的策略是preprocess+llm+postprocess，中间别做，因为会被卷死，下游只做配套组件，因为llm会变，做到适配拆拔。preprocess，要重点做，做给llm助力的东西，这些东西做了之后，输入给llm，llm效果会更好的东西。这样一来能保证，llm会越来越强【必然趋势】，效果也会越来越好，是正收益。postprocess，也可以叫application，前两个干了，他也就会好，但它的风险点在于，有依赖性，比较被动，会很疲惫。要么做应用，比如最近得deepseek+，赚快钱。传统公司，要么做数据处理，比如合合信息，比如庖丁这些。大家也可以看到这个分化，头部大厂跟llm top公司做llm。所以，优先级是preprocess>postprocess>llm。往往，做preprocess感觉还更有出路一些，因为这是硬通货。依据是，一个是大厂兴趣不大，因为太细分，劳动密集型，不划算，有自有业务。一个现在小公司也没业务，踏踏实实给大厂抱腿做组件，也是出路。一个是做postprocess，小公司不容易切进去，尤其是C端，B端和GJ端还好些，但回款能力这些，也需要扛的住。 |
