大模型应用正在从“纯文本问答”进入“多模态知识库”时代。企业内部的合同扫描件、产品设计稿、数据报表截图——这些非结构化图片长期游离于检索系统之外，核心问题在于传统的 RAG 流程只有一条“文本通道”。图像里的表格结构、图表趋势、手写批注被硬生生拍平成了文字，信息损失无法避免。

Gemini 3.5 的“原生多模态”特性改变了这一局面。它不再需要外部 OCR 插件，而是能直接“看懂”图片中的布局、空间关系与图文关联，为构建真正的图文混合检索系统提供了关键的技术基础。

在动手搭建系统之前，通常需要先在 KULAAI（dl.877ai.cn） 等聚合平台上对 Gemini 3.5、GPT-5 和 Claude 4.8 进行横向对比，通过跑批实测摸清它们在图文联合推理和跨模态对齐方面的真实差异。这一步是为后续的索引策略和检索逻辑设计提供数据锚点。

一、传统方案的瓶颈：分轨存储导致语义割裂

在传统的企业级文档处理架构中，文本和图像是被粗暴地“分轨存储”的。这种架构最致命的缺陷在于，它将天然一体的文档拆得七零八落：不仅丢失了表格结构、图表趋势等关键信息，还切断了图片与图片、文字与图片之间原有的上下文关联。即便采用 OCR 和多模态提取等事后补救手段，也只能还原出碎片化的数据，很难融合成完整的语义理解。

二、核心构建步骤：让图文混合检索跑起来

1. 建立“文本-图像”关联索引

首先要将文档拆分为可独立检索的“语义单元”。关键技巧是提前定义好语义锚点，让模型直接输出 JSON 格式的元数据，记录下文字区块的位置以及与它相关联的图片锚点 ID。在处理图像块时，必须充分利用 Gemini 3.5 的原生视觉理解能力，直接提取图像内容并生成富含空间关系和深层语义的摘要，这一步直接决定了后续跨模态检索的天花板。

2. 设计跨模态检索管线

检索不再是传统的“文本搜文本”。在索引层面，文本块和图像块的 Embedding 需要统一存入一个向量空间中。交叉检索逻辑被设置为：用户的自然语言查询，将同时在这个共享的语义空间中去匹配最相关的文本摘要以及图像描述。为了打破碎片化，还可以引入后期融合排序策略，对召回的相邻图文进行关联性重新排序，实现“图文共同召回、联合排序”。

3. 处理长上下文与复杂排版

Gemini 3.5 百万 Token 的上下文窗口，可以一次性装下整份复杂的 PDF 文档，或者一次处理几十张图片。这样可以完全跳过切片预处理环节，避免了“只见树木不见森林”的问题。在模型内部进行无损失的跨模态推理，然后再输出可用于检索的结构化摘要，极大地提升了信息的完整性。

三、优化技巧与避坑指南

虽然 Gemini 3.5 效果强大，但在生产环境中还需注意性能优化。多模态 Embedding 推理消耗较大，尽量复用 Gemini 3.5 在一次推理中同步生成的摘要作为稀疏检索标签，实现密集向量加稀疏关键词的混合检索方案。针对高频访问的文档或图表模板，建立语义缓存避免重复调用 API，降低 Token 开销。

同时，定期检查文档索引中的“孤儿锚点”以及图像摘要的分块更新策略，确保每一次源文档更新都能准确同步到向量数据库中，维护系统数据的时效性与一致性。

四、总结：迈向原生多模态知识库

传统 RAG 架构中“文本-图像”分轨存储的天然鸿沟，正在被 Gemini 3.5 等原生多模态模型的技术突破所抹平。通过深度利用模型对原始文档的无损理解能力，开发者得以跳出传统 OCR 的局限，构建起真正意义上 “图文并茂、语义互通” 的混合检索系统。作为多模态 RAG 的第一步，这套图文混合检索的实现不仅解决了存量多模态资产的实时检索难题，更为后续复杂的 Agent 自动推理和跨文档分析奠定了坚实的基础。