这道题其实问的是,当 [[RAG]] 系统遇到非纯文本的文档时,怎么把表格、图片这些信息有效利用起来。说白了,核心就两个问题:一是怎么把非结构化内容转成机器能理解的形式,二是怎么让文本查询和图片、表格这些不同模态的信息对齐。
我们先从文档解析说起。表格和图片的处理路径不太一样,你得根据场景来选。比如表格,如果结构清晰,直接用 Camelot、Table Transformer 这类工具提取成 Markdown 或 JSON,保留行列关系,这样 LLM 能看懂。但如果是扫描件里的复杂表格,比如带合并单元格、跨页的,直接提取容易出错,我的做法是截图加结构化文本双路存储,检索时根据 query 类型决定用哪一路。图片呢,分两类:一类是纯文本图片,比如截图,用 [[OCR]] 提取文字就行;另一类是图表,比如折线图、柱状图,光 OCR 不行,还得用视觉模型解析出趋势、极值等结构化信息,或者干脆保留视觉特征。
接下来是[[向量化]]。这里有个常见的纠结:是图片和文本各自编码、分开建索引,还是用一个[[多模态]]模型统一编码?我的经验是,没有银弹,得按业务场景来。如果文档里图片主要是配图,跟文字内容强相关,那用 [[CLIP]] 这类联合编码模型,一个向量搞定,检索时 query 直接映射到同一个空间,简单高效。但如果图片是独立的,比如产品目录里的商品图,跟周围文字关系不大,那分开编码更合适,文本用 BERT,图片用视觉 Encoder,检索时做 late fusion,也就是文本检索和图片检索各出一批结果再合并。落地时我通常走混合方案:表格存结构化文本加截图双向量,关键图片存 OCR 文本加视觉向量,让系统按需选择。
再说到生成阶段,LLM 能不能直接吃图片,取决于模型能力。如果用的模型原生支持多模态,比如 Qwen-VL,那直接把图片 base64 传进去就行;如果不支持,就只能把图片转成描述文本,比如用视觉模型生成一段 caption,再跟文本一起喂给 LLM。表格的话,我倾向用 Markdown 格式,因为 LLM 对 Markdown 的理解力比 HTML 好,token 也更省。
实际落地中,挑战不少。解析精度是第一个坑,扫描件表格识别错位、图表 OCR 漏字,都会导致下游检索和生成出错。我的做法是加置信度过滤,低于阈值的走人工标注或回退到纯文本链路。模态对齐是第二个坑,比如一张图配的文字说明是错的,检索时图文语义就对不上。这种问题需要靠多模态预训练或对比学习微调来缓解,但成本高,小团队可以先做规则兜底。成本与延迟也很现实,视觉 Encoder 计算重,图片 token 占上下文长,我的策略是分层检索:先用文本检索粗筛,再对 top-k 结果中的图片做精细处理,避免全量计算。
还有一个容易被忽略的点:评估。多模态 RAG 的答案很难自动评测,比如问“这张图里峰值在哪”,模型答对了但格式不对,算不算对?目前业界也没有统一标准,我会自己构建多模态评测集,用 GPT-4V 做裁判,但成本高,还在探索更轻量的方法。
所以整体上,我更倾向把多模态 RAG 看成一套按需路由的系统,先判断文档类型,纯文本走轻量链路,复杂文档走多模态链路,而不是一个统一的方案。核心是平衡精度、成本和延迟,根据业务容忍度做取舍。