文件里表格一多，传统文本RAG就频频翻车？这个问题其实并不新鲜。最近团队同时在推进两件事：一边帮客户落地已有的文本知识库产品并提供咨询，另一边在研发一款多模态RAG产品。客户反馈最集中的痛点，就是准确率不够——不是某一次不够，而是很多场景下都差那么一口气。
问题的根源，在于数据源的复杂性。文档里一旦混入图片、表格、页眉页脚、边框这些元素，输出的准确性就会直线下降。哪怕用了RAGFlow的DeepDOC加上第三方视觉模型，也时不时会出幺蛾子。举个例子，下面这份PDF是一份项目开发排期表：
问一句“排期工作量共有多少天？”，市面上主流文本知识库产品大多给不出靠谱答案，回答五花八门。本质原因其实不难理解：RAG从文档解析开始，到内容切分、向量化、检索召回，任何一个环节都可能丢了关键信息。
多模态业界方向
准确率是RAG系统的命门。我们翻了不少国内外论文和博文，挑几个含金量高的观点跟大家聊聊。
先分享一篇来自《The Rise and Evolution of RAG in 2024: A Year in Review | RAGFlow》的内容，非常有启发：
回到RAG本身，如果我们能够根据用户查询，在大量PDF中精准找到包含答案的图像和文本，再用VLM生成最终答案——这才是多模态RAG的核心价值。它远远超越了简单的图像搜索。
实现这个目标，一条路是用模型把多模态文档转成文本，再走索引检索；另一条路则更直接——借助VLM生成向量，跳过复杂的OCR过程。2024年夏天问世的ColPali就是后一条路的先驱。ColPali把一张图像看成1024个图像块，每个块生成嵌入向量，这样一来整张图就变成一个实实在在的张量。
多模态模型
从上图已经能看出多模态的优势：它真正理解了文档图片的语义，而不是只做一层OCR提取文字。
再说一篇微信公众号文章《多模态RAG文档检索竞赛前三获奖方案解读：MMDocIR/KR任务》。这篇文章详细分析了多模态RAG的评测比赛以及前三名方案。我们重点拆解其中一个方案：
Task1_MMDocIR任务的方案是：基于图像和VLM文本，使用ColQwen模型生成每一页的图像和文本嵌入向量，然后融合这些向量。根据文本查询找到查询嵌入向量，通过延迟交互机制计算页面嵌入与查询嵌入的相似度，最终检索出相似度最高的前5页。
Task2_M2KR任务：根据查询文件名从维基百科抓取图像（或使用传统OpenCV从截图提取），用基于Transformer的视觉模型（ColQwen2）生成密集嵌入向量，用FAISS（IndexFlatL2）对段落图像建索引；每个查询检索出最相关的top-k图像。
关键思路在于：ColQwen模型同时处理图像和文本的嵌入向量并进行融合，检索时计算查询向量与嵌入向量的相似度。这就实现了真正意义上的图文融合——在业务场景中，既能输入输出图片和文本，又能理解图片内容。
多模态 RAG 实测效果
顺着论文思路，我们做了Demo验证。简单说一句话：回复的准确性令人震惊。
案例一（PDF表格）：就是开头那张“曝光排期”的PDF文档。效果图如下，完美回复。对照测试就不再去RAGFlow了，有兴趣的可以自己试试。
案例二（PDF图片）：输入一份文档，要求总结出目录。
源文档：
实测效果：又是完美还原。
案例三（PDF文本）：输入一份读书笔记文本。
实测效果：纯文本自然也不在话下。
结论
多模态RAG的核心优势在于对图片和文字的理解。基于ColPali的方案省去了OCR环节，检索速度反而非常快。劣势在于向量化过程对计算资源要求很高——实测至少需要4090以上GPU显卡，才能在5秒内解析约5M的文档。另外，视觉大模型对硬件配置和Token的消耗也远超普通文本LLM。不过，在本地私有化部署的场景下，这些都不是大问题——相比于问答质量的跃升，算力成本其实没那么敏感。
KnowFlow将持续在多模态RAG方向上打磨产品，为企业知识管理与应用提供切实的赋能，让知识真正流动起来。