谷歌Gemini文件搜索升级：图片终于能"看懂"了

「以前搜文档，图片是盲区。现在图表、产品图、设计稿都能被模型直接索引和检索。」——这是谷歌开发者文档里的原话，也是这次更新的核心。

谷歌Gemini API的文件搜索工具（File Search Tool）刚刚完成一次关键迭代：通过接入Gemini Embedding 2模型，实现了原生的多模态检索能力。这意味着你上传的PDF、产品照片、流程图，可以和文字文档放在同一个知识库里被统一搜索。

对做产品的朋友来说，这解决了一个真实痛点：企业知识库里有大量"半结构化"信息——财报里的图表、电商后台的商品图、设计团队的Figma导出图——过去要么靠人工打标签，要么干脆搜不到。现在模型自己读图、理解、建立索引。

这篇指南完整拆解从建库到查询的全流程，包括一个可直接试用的AI Studio示例应用。

File Search到底是什么

它是Gemini API内置的RAG（检索增强生成）工具。RAG这个概念被讲烂了，但File Search的差异化在于"全托管"——上传文件后，分块、嵌入、索引、检索全由API自动处理。

查询时，你在prompt里附带一个file_search工具，模型会自动从你的数据里捞相关片段，生成带依据的回答。

和自己搭RAG管道相比，File Search省掉三块硬骨头：

• 不用自己选型向量数据库
• 不用调分块策略和嵌入模型
• 不用维护检索排序逻辑

代价是灵活性。谷歌给你封装好了，但你也改不了内部机制。

多模态能力从哪来

关键变量是embedding_model参数。创建File Search Store时，指定"models/gemini-embedding-2"就能解锁图片索引能力。

这个参数是可选的。如果不填，默认走"gemini-embedding-001"——专为纯文本优化，成本更低，但建库后不能切换模型。

两个模型的定位很清晰：

| 模型 | 适用场景 |
| gemini-embedding-001（默认） | 文本密集型任务，成本优先 |
| gemini-embedding-2 | 图文混合检索 |

选型决策建议前置：一旦Store创建，embedding_model锁死。如果未来可能需要搜图，直接上gemini-embedding-2。

实操：从建库到查询

第一步，确保Python SDK是最新版：

pip install -U google-genai

创建多模态知识库的代码：

from google import genai
from google.genai import types

client = genai.Client()

file_search_store = client.file_search_stores.create(
config={
"display_name": "product-catalog",
"embedding_model": "models/gemini-embedding-2"
}
)
print(f"Created store: {file_search_store.name}")

第二步，上传文件。upload_to_file_search_store方法把上传和索引合成一步，支持PDF和图片格式。注意：音频和视频目前不支持。

上传PDF示例：

operation = client.file_search_stores.upload_to_file_search_store(
file_search_store_name=file_search_store.name,
file="product_catalog.pdf",
config={"display_name": "Product Catalog 2024"}
)

上传后会返回一个operation对象，可以用它轮询索引进度。大文件可能需要几分钟完成嵌入。

查询与引用：答案从哪来

查询阶段的核心是"grounded generation"——模型生成回答时，必须基于检索到的文档片段，而不是瞎编。

File Search的响应包含两类关键信息：

• 文本片段：直接引用原文段落
• 图片引用：返回相关图片的存储路径和页码/位置信息

这意味着你可以做两件事：一是让模型总结财报图表的趋势，二是追问"这张柱状图的数据来源是哪一页"。

引用追溯是RAG系统的信任基础。谷歌的示例应用里，每个回答都附带页码和来源标记，用户可以一键跳转到原始文件。

一个立即可试的Demo

不想写代码？谷歌在AI Studio里搭了一个完整示例：上传你的PDF和图片库，直接对话查询。

这个Demo的设计很产品化——实时检索、带引用、支持图文混合问答。适合用来验证场景可行性，再决定要不要接API。

典型测试路径：上传一份带图表的产品手册，问"Q3销量增长最多的品类是什么"，看模型能否定位到正确的柱状图并解读数据。

边界与限制

目前明确的限制有三条：

• 音频、视频格式不支持
• Store创建后embedding_model不可更改
• 图片索引成本高于纯文本（gemini-embedding-2的定价未在文档中明确，但通常多模态嵌入更贵）

另外，"多模态检索"不等于"多模态理解"。模型能根据图片内容做语义匹配，但复杂图表的精确数值提取仍可能出错。关键数据建议人工复核。

为什么这次更新值得盯

企业知识库的演进有个明显趋势：从"能搜到"转向"能看懂"。纯文本搜索的时代，图片是沉默的数据孤岛。打标签、建目录、人工整理——这些脏活累活占用了大量产品运营资源。

Gemini Embedding 2的升级逻辑很直接：让模型承担理解成本，把人的时间释放出来做更高层的事。

对开发者来说，File Search降低的是RAG系统的维护负担。不用纠结Milvus还是Pinecone，不用调chunk size，不用写重排序逻辑。代价是黑盒化——谷歌不暴露嵌入向量的具体数值，你也无法做自定义的相似度计算。

这是典型的平台化取舍：牺牲极致灵活性，换取快速上线和规模弹性。

落地场景想象

几个马上能想到的产品场景：

• 电商后台：商品图+详情页统一检索，客服机器人能根据产品图回答"这款有几个颜色"
• 设计系统：Figma导出图+组件文档混合搜索，新人问"按钮规范"直接定位到设计稿
• 投研工具：财报PDF里的图表自动索引，问"毛利率变化"时模型能引用正确的折线图

这些场景的共性：图文信息原本割裂，现在被拉平到同一个语义空间检索。

下一步行动

如果你正在评估RAG方案，建议做两件事：

第一，去AI Studio跑一遍官方Demo。用你自己的真实文档测试，重点观察图片检索的准确率和引用完整性。

第二，算一笔成本账。对比自建方案（向量数据库+嵌入服务+运维人力）和File Search的API费用，注意多模态索引的单价差异。

技术选型没有银弹，但多一个经过验证的托管选项，总好过从零造轮子。至少现在，你的产品图和PDF终于可以住在同一个搜索框里了。