RAG 的最后一块拼图，Google 补上了。
Google 宣布 Gemini API 的 File Search 功能正式支持多模态——意味着你可以直接把图片、带图的 PDF、扫描件扔进检索流程，Gemini 不仅能搜文字，还能理解图像内容。
这个更新到底意味着什么
先说背景。File Search 是 Google 去年为 Gemini API 推出的一项功能：你上传一批文档，Google 帮你建索引，然后在对话时自动检索相关内容。本质上是一个 managed RAG 服务。
但之前的版本只能处理纯文本。如果你有一堆产品手册、发票截图、带图表的报告——这些带图像内容的文件，File Search 基本瞎了。
现在不一样了。多模态 File Search 可以直接理解：
- 图片中的文字和视觉信息
- PDF 中的图表、截图
- 扫描件（OCR + 视觉理解结合）
对开发者来说省了什么事
在这之前，如果你想在 RAG 里处理图片，基本要自己搭一套 pipeline：OCR 提取文字 + 视觉模型理解图像 + 把结果合并进向量库。每一步都要选工具、调参数、处理边缘情况。
现在 Google 把这一坨东西打包成了一个 API 调用。
不是说这个方案一定比自建的好，但对"想快速跑通 demo"或者"团队没有专门做多模态基础设施的人"来说，这是一个显著的门槛降低。
竞争格局
OpenAI 的 GPT-4o 早就支持多模态输入，但在 managed RAG 服务层面，各家进度不太一样：
- Google 这次把多模态和 File Search 整合到了一起
- OpenAI 的 Assistants API 也有类似的文件处理能力
- Anthropic 的 Claude 多模态能力很强，但没有原生的 managed RAG 服务
Google 的优势在于它的文档处理能力——Google Docs、Drive 的生态积累不是短期能复制的。如果 File Search 能和 Drive 深度整合，那对于已经有大量文件存在 Google 生态里的企业来说，迁移成本几乎为零。
实际限制
公告里没有提到几个关键信息：
- 价格口径——多模态搜索会不会比纯文本搜索贵很多？
- 延迟——图像理解比纯文本匹配慢得多，实时场景能不能扛住？
- 支持的文件格式列表——除了 PDF 和图片，PPT、Excel 呢？
这些细节会在后续文档里补充。如果你打算在产品里用，建议先跑一轮 POC 再决定。
多模态 RAG 这个赛道，2026 年才刚刚开始卷。
主要来源：Google Developers Blog, "Gemini API File Search is now multimodal"