12.5.3 图片、表格、图表、代码等内容进入 RAG 时，核心难点分别是什么？

先给结论：不同数据形态的难点不是“是否能向量化”，而是“能否保留结构与可解释性”。你需要为每种形态定义自己的检索策略。

图片

难点：视觉语义难以直接用于文本检索，且证据可解释性弱。
策略：

图片检索后必须生成可解释文本（caption/摘要）
对关键区域做局部检索（而非整图）
将图像与上下文文本绑定（标题、说明、位置）

表格

难点：表格语义依赖行列结构，直接分块会丢掉“行列关系”。
策略：

保留行列结构，避免只做文本化
用结构化查询补充（SQL/过滤）
对表格块建立“表名 + 列名 + 关键值”的可检索索引

图表

难点：图表的信息不在文字，而在“趋势与关系”。
策略：

OCR 只做文字补充，不是核心
建立“轴/刻度/趋势”的结构化描述
允许图表转摘要（趋势结论）

代码

难点：代码语义依赖上下文与依赖关系，纯文本检索会碎片化。
策略：

按函数/类/模块分块，而非行级分块
记录依赖关系（调用链、import）
给代码补充“用途摘要”，便于检索匹配

通用原则

复杂形态必须“结构化 + 可解释”
一定要区分“检索证据”和“生成解释”
不同形态的索引与检索器应当独立

自检清单

是否为每种数据形态设计了专属索引策略？
是否保留了结构而不是只做文本化？
证据是否可解释并能支撑答案？

一句话总结

复杂数据形态进入 RAG 的关键，是“保留结构、建立对齐、保证可解释”。不同形态要有不同策略，不能一刀切。