多模态 RAG 卡在哪？
多数人的回答在检索那一侧。embedding 不够好，rerank 不够准，图和文的向量对不齐。
八月底挂出来的一篇预印本给的是另一个答案。
arXiv 2608.25986，cs.AI，v1，八个作者，文件 553 KB。标题长得像三个缩写叠在一起，这些都不重要。重要的是它说的那件事。
现在这套流程，是把图单独拎出来编码，再想办法拼回去
论文先把现状复述了一遍。
近期做多模态 RAG 的人，开始把多模态知识图谱当成 GraphRAG 的知识库，让检索同时吃进图和文。
想法没问题，做法有问题。
现有的方法基本走同一条路：每个模态先各自处理，处理完再融合。图归图，文归文，最后拼到一起。
论文点出这样做的代价。在图像信息抽取那一步，和之后多模态知识融合那一步，文本只被用上一点点。
这就有点怪。图本来就长在文里。你把图抠出来单独编码，语义已经掉了一块。
论文把这个叫语义鸿沟。措辞比较客气。说白了就是图和字对不上。
它给的解法，本质上是替每张图配一段说清楚它是什么的字
框架缩写叫 CEMMKG，全称不用记。
做法是在两个尺度上给每张图补文本上下文。
局部那一层，不只用图像周围的文本，还去找语义上跟它相关的句子，而且做了多粒度设计，能在不同细节层次上抓语义。
全局那一层，给整个段落配一个摘要。
然后拿这套东西去支撑多模态 GraphRAG。论文说在选定的以视觉为中心的数据集上做过实验，CEMMKG 在不同基于 MMKG 的 RAG 方法上都有效，不是只对某一种检索器管用。
跨方法有效这一点我觉得是实的。比单点刷一个数好看。
这几年做 RAG 的功夫，大多花在检索那一侧
换个向量库，换个 rerank 模型，把 chunk size 从 512 调到 1024，再调回来。
这些不是没用。但它们的天花板早就摸到了。
如果你在入库那一步就把材料切得七零八落，检索侧再怎么调，捞回来的也是一块没有上下文的碎片。
一篇论文里的图，从段落里切出来那一刻，它和周围那些字的联系就断了。后面用多大的模型去融合，融合的是两个已经被稀释过的东西。
所以这篇论文真正值得看的点，不在框架名字，在它把功夫挪到了入库这一侧。
多模态数据的预处理，可能比检索算法本身更值得花时间。
这条我讲得比较满。因为它不只是一篇论文的判断。
落到普通人身上，有个能直接抄的动作
你手里那堆笔记、文档、截图，喂给 AI 之前整理过吗。
多数人没有。拖一个文件夹进去就完事。
论文里那个两层结构可以抄。给一份材料配一句话说清它是什么，这是全局。再给里面的关键部分补一两句它周围的上下文，这是局部。
这个动作不花什么钱，也不用懂 RAG。
但它对结果的影响，可能比你换个模型大。
留个白话版
GraphRAG，可以理解为检索时不是在一堆平铺的碎片里找相似度，而是沿着知识图谱的骨架走。
骨架在，模型就知道哪些东西是连着的。
这个概念我之前收过一次。这次是往里面加了图和文。
另外
这篇我只看懂了一半。局部上下文那个多粒度设计，具体分几层、按什么分，我还没吃透。先放在这里，等我搞明白再补一句。
这周就收这一条。其他动静不是没有，是我看不清它们对普通人意味着什么。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。