基于文本的传统 RAG 缺陷我们团队近期主要在做两件事： 已有的文本知识库产品进行客户交付以及提供一些咨询服务 正在研发一款多模态 RAG 产品
在基于文本的知识库实际企业落地过程中，客户反馈最大的问题还是准确率不足。出现准确略不足的最主要原因还是数据源的复杂性，文档中存在图片、表格、页眉页脚、边框等都会影响到输出的准确性。即使在 RAGFlow 的 DeepDOC 和三方视觉模型加持下仍然时有问题出现。 举个简单的例子，以下是一份 PDF 文档，内容为一个项目的开发排期表： 用基于文本的知识库去提问「排期工作量共有多少天？」，市面上常见的一些文本知识库产品大多难以准确回复，回答的结果千奇百怪。本质的原因在于 RAG 从文档解析、内容切分、向量化、检索召回任意过程都可能存在信息丢失。 多模态业界方向准确率是 RAG 系统极为重要的一个指标，我们查阅国内外相关的一些论文和博文，挑出一些价值较高的观点分享给大家。 首先分享下来自 The Rise and Evolution of RAG in 2024 A Year in Review | RAGFlow，含金量很高，节选内容如下： 回到 RAG 本身，如果我们能够使用 RAG 根据用户查询在大量 PDF 中查找包含答案的图像和文本，那么我们就可以使用 VLM 生成最终答案。这就是多模态 RAG 的意义所在；它超越了对日常物品进行简单的图像搜索。 为了实现这一点，如前所述，一种方法是使用模型将多模态文档转换为文本，然后再进行索引以供检索。另一种方法利用 VLM 的进步，直接生成向量，绕过复杂的 OCR 过程。一个先驱示例是 ColPali ，它于 2024 年夏天问世。ColPali 将图像视为 1024 个图像块，并为每个图像块生成嵌入，从而有效地将单个图像表示为一个张量。
多模态模型 从上述图中已经可以看出来多模态的优势，能够很深入的理解文档图片的语义，而不仅仅是通过 OCR 提取文档的内容。
再看下来自微信公众号文章：多模态RAG文档检索竞赛前三获奖方案解读：MMDocIR/KR任务。 该文章内容说明了多模态RAG检索的评测比赛以及对应的前三名获奖方案。我们就其中一个方案，详细说明下。 Task1_MMDocIR任务，使用的方案为：
基于图像和VLM文本，使用基于ColQwen的模型生成每一页的图像和文本嵌入向量，并将这些嵌入向量进行融合。根据文本查询（即问题）找到查询嵌入向量。利用延迟交互机制，计算页面嵌入向量与查询嵌入向量之间的相似度分数。最终检索出相似度最高的前5页。 对于Task2_M2KR任务，根据查询文件名从维基百科文章中抓取图像（或者你可以选择使用传统的OpenCV技术从维基百科截图中提取图像：查看extract_images.py），使用基于Transformer的视觉模型（ColQwen2）生成密集嵌入向量，使用 FAISS（IndexFlatL2）对段落图像进行索引；每个查询检索出最相关的top-k图像。
通过 ColQwen 模型对图像和文本嵌入向量并融合，检索时计算查询向量和嵌入向量的相似度。这样实现了真正意义上的文本和图像融合，在业务场景上的好处是，可以输入和输出图片和文本，同时还能够理解图片。 多模态 RAG 实测效果基于上述论文中的思路，我们已经实现了 Demo 并验证其效果。简单来说：回复的准确性令人震惊！ 案例一（PDF 表格）：文中开始部分「曝光排期」PDF 文档 效果图如下，完美回复，这里我就不再到 RAGFlow 进行对比了，有兴趣同学去对比下。 案例二（PDF 图片）：输入一份文档，总结出目录 源文档： 实测效果，又是完美还原
案例三（PDF 文本）：输入一份读书笔记文本 实测效果：文本也不在话下 结论多模态 RAG 核心优势在于对图片以及文字的理解，基于 ColPali 的方案由于省去了 OCR 过程，检索速度反而非常快。劣势在于向量化过程高度依赖计算，实测至少 4090 以上 GPU 显卡可以正常在 5s 内解析 5M 左右文档。另外视觉大模型对于硬件配置要求以及 token 的消耗也远远比普通的文本 LLM 大得多。但这些问题对于本地私有化部署问题不大，相比于问答质量的提升，这些问题反而不是那么重要。 KnowFlow 将会持续在多模态 RAG 方向打造出卓越的产品，为企业知识管理和应用赋能，让知识真正的流动起来。 | 
