考察点
这道题出自阿里巴巴 Agent 开发岗校招一面，第二问「只返回文字，图片信息不会丢失吗」是明显的引导式追问——面试官其实已经把坑指给你了，就等你承认「纯文本化确实会丢信息」，然后讲你怎么补。考察的是对多模态文档理解的完整链路：解析、索引、检索、呈现四段都要答到。
参考答案
先承认问题：图片不能简单地一丢了之
企业文档里图片承载的信息分两类：装饰性图片（logo、分隔图、纯美化配图）丢了无所谓；信息性图片（架构图、流程图、数据图表、界面截图、表格照片）往往是文档里最密集的信息载体——一份产品白皮书的关键对比数据可能全在一张图里。所以处理的第一步是区分这两类，而不是统一处理。
处理路线：三条路按图分类走
路线一：OCR + 文本抽取。适用于以文字为主的图片（截图、扫描件、表格照片）。用 OCR（PaddleOCR 这类）抽出文字，作为图片的文本表示进入索引。成本低，但对架构图、流程图基本无效——OCR 能抽出框里的字，抽不出框之间的连线关系。
路线二：VLM 生成语义描述。用多模态模型（Qwen-VL、GPT-4o 这类）给图片生成一段自然语言描述：「这是一个三层架构图，接入层通过网关连接服务层，服务层包含订单、库存两个微服务，数据层为 MySQL 主从集群」。描述文本进向量索引，参与语义检索。这是目前性价比最高的方案，能覆盖大部分架构图、图表。对于图表类图片，还可以让 VLM 顺手把数据还原成 markdown 表格，比描述更利于精确问答。
路线三：图片直接向量化。用多模态 embedding 模型（CLIP 系的图文双塔，或更新的统一向量模型）把图片本身编码成向量，用户 query 可以直接和图片做跨模态检索。优点是不过度依赖描述的质量，「描述没提到但图里有」的信息也能被召回；缺点是向量库要维护两种模态，工程复杂度高一档。
实践中我倾向组合：信息性图片走「VLM 描述 + 图片原图向量」双路索引，OCR 作为文字密集图片的补充；装饰性图片用规则过滤（尺寸太小、出现频率高的页面装饰元素直接跳过）。
关键设计：chunk 和图片的关联索引
不管走哪条路线，有一个设计不能省——图片必须和它的上下文绑定。图片在文档里不是孤立存在的，它的图注（caption）、所在小节标题、前后段落都是理解它的必要信息。我的做法是：
- 图片作为独立的 chunk 入库，metadata 里带上：所属文档、章节路径、图注、前后相邻文本 chunk 的 ID。
- 图片的文本表示（OCR 结果 / VLM 描述）和上下文拼在一起做 embedding，而不是只向量化描述本身。「图 3」这种描述离开上下文毫无意义。
- 反向索引：文本 chunk 的 metadata 里也记录其中引用了哪些图片，检索到文本时能带出关联图片。
回答第二问：怎么做到不丢信息
只返回文字一定会丢信息，补救分两层：
检索层不丢：图片参与了向量检索，用户问「系统架构分几层」时，架构图能因为描述文本被召回，它的信息进入了模型的上下文——这是信息不丢的第一道保障。
呈现层还原：模型生成答案时引用的是图片描述，但给用户的最终呈现要回填原图。答案里引用到某张图时，前端在对应位置直接渲染原图链接（chunk metadata 里存了图片 URL），用户既能读到文字结论，也能看原图核实。这比纯文字答案的体验和可信度都好得多。更进一步，如果生成模型本身是多模态的，检索召回图片后可以把原图直接喂给模型读，让它看着图回答，绕开「描述失真」的问题——这是成本最高但质量最好的方案，适合对准确率要求高的场景。
评测怎么跟上
多模态 RAG 的评测要在评测集里专门构造「答案只存在于图片中」的样本，单独统计这类问题的召回率和答案正确率——总量指标会掩盖图片链路的问题，因为文本占大头，图片问题全错总量指标也只掉几个点。
可能的追问
- VLM 生成的描述质量怎么保证？ 答：给 VLM 的 prompt 里带上文档上下文（章节标题、图注），描述准确率明显好于裸图直描；抽样人工评测描述忠实度，差的图类型针对性调 prompt。
- 表格怎么处理？ 答：文档解析阶段尽量还原文本表格为 markdown / HTML 进索引；图片形式的表格走 VLM 还原成结构化表格，保留行列关系——直接当普通文本切 chunk 会把表结构切碎。
- 跨模态检索用什么模型？ 答：早期用 CLIP 类双塔，现在更多是支持多模态输入的统一 embedding 模型；选型时在自建评测集上对比「图相关 query」的召回率再定，不盲信榜单。