- Gemini API File Search 内置全托管 RAG,无需配置向量数据库
- gemini-embedding-2 支持文本 + 图像(PNG/JPEG)原生统一嵌入,无需 OCR
- 自定义元数据过滤 + 精确页码回链 + 图像media_id可下载
- 存储与查询嵌入免费,仅收首次索引费 + 标准模型 token 费
- 竞品对比:OpenAI RAG 缺精确引用,Anthropic 不支持多模态嵌入
为什么要用 Gemini API 文件搜索做 RAG
检索增强生成(RAG)是目前让大模型接入私有数据的标准方案。但自建 RAG 管线的维护成本不低——需要向量数据库、嵌入流水线、分块策略、索引更新机制。Gemini API 的文件搜索工具把这些全包了:上传文件后,API 自动完成分块、嵌入、索引和检索,开发者只需要在 generate_content 调用时传递一个 file_search 工具。
2026 年 5 月的更新让 File Search 的能力从纯文本扩展到多模态:图表、产品照片、示意图等图像可以与文本文档在同一存储库中索引和搜索,无需 OCR 先转文本。配合 grounding metadata 中的 page_number 回链和 media_id 图像下载,它正在成为搭建企业级 RAG 应用最具性价比的选择之一。 Gemini API 文件搜索核心能力详解
全托管 RAG 管线
File Search 的设计哲学是「零运维」。对比自建 RAG 的典型流程:
| | |
|---|
| | 自动分块,可选 chunking_config 调整 |
| | 内置 gemini-embedding-001 / gemini-embedding-2 |
| 配置 Pinecone / Weaviate / Milvus 等 | |
| | 通过 upload_to_file_search_store 或 import_file 自动完成 |
| | 通过 file_search tool 自动注入上下文 |
| | 内置 page_number + media_id + download_media |
定价优势:存储和查询时嵌入免费,仅首次索引嵌入收费。这意味着对于频率读多写少的场景(绝大多数 RAG 应用),长期运行成本显著低于自建管道。
Gemini Embedding 2:首个原生多模态嵌入模型Gemini Embedding 2:首个原生多模态嵌入模型
gemini-embedding-2 是 Google 首个原生多模态嵌入模型,核心能力是将文本和图像统一映射到同一向量空间。创建 FileSearchStore 时指定 embedding_model: "models/gemini-embedding-2" 即可启用。
图像嵌入规则:
与纯文本模型对比:
精确引用系统:页码 + 图像下载
File Search 的 grounding metadata 提供两个关键字段:
page_number:对 PDF 等多页文档,直接返回源信息所在页码。通过 response.grounding_metadata.grounding_chunks[i].retrieved_context.page_number 获取。
media_id:当模型引用的是图像块时,返回该图像的唯一 ID,通过 download_media(media_id) 直接下载被引用的图片。
这意味着你可以构建一个用户体验上让用户直接看到模型引用的原始图片和原文段落的 RAG 应用,而不只是文本描述。
自定义元数据过滤
当 FileSearchStore 积累大量文档后,全库搜索的精确度会下降。custom_metadata + metadata_filter 解决这一场景:上传时附加键值对,查询时用 metadata_filter 做条件筛选。
与结构化输出协作
Gemini 3 系列模型支持 File Search + 结构化输出(JSON Schema)并行使用。这意味着 RAG 应用可以返回符合预定义 Schema 的结构化数据,适合构建产品目录检索、表单填充等场景。
实战:20 行代码跑通多模态 RAG
以下是一个端到端的完整示例,涵盖创建存储、上传文档和图像、查询、解析引用四个步骤。使用前确保安装最新 SDK:
步骤 1:创建多模态文件搜索存储
步骤 2:上传文档和图像
步骤 3:查询 + 解析引用
步骤 4:带元数据过滤的查询
管理操作参考
Gemini File Search vs OpenAI RAG vs Anthropic 知识库
| | | |
|---|
| gemini-embedding-2 原生支持文本+图像 | | |
| | | |
| media_id + download_media API | | |
| | | |
| | | |
| | | |
| | | |
| Gemini 3 系列支持 JSON Schema | | |
| | | |
核心差异总结:
- 选择 Gemini File Search:如果你的应用需要跨模态检索(图文混合)、精确溯源(页码+图像下载),或对成本敏感(存储与查询嵌入免费)
- 选择 OpenAI 检索工具:如果你已深度使用 OpenAI 生态(Assistants API),且不需要图像级引用
- 选择 Anthropic 知识库:如果你需要更强的安全护栏和可控性,且检索对象全部为纯文本
File Search 适合和不适合的场景
适合的场景
视觉商品搜索:产品目录含图片和规格说明,通过自然语言或视觉描述搜索。如「找到一双红色、带白色条纹的跑步鞋」。
研究与技术文档:从论文和报告中检索特定的图表、架构图或数据可视化内容。PDF 中的图表可以直接被模型理解并引用。
保险与理赔处理:结构化表单 + 损坏照片的统一评估。理赔员可上传表格和现场照片,用自然语言查问案例。
设计系统与组件库:按视觉外观而非仅命名约定搜索 UI 组件。例如「找一张动态、渐变背景的卡片组件」。
房地产与房源列表:基于平面图、室内照片和风格偏好匹配房源。
不适合的场景
音频/视频检索:当前不支持音频和视频格式。如果你需要对客服录音或视频片段做语义搜索,需等待后续更新。
高频写入的实时索引:File Search 的索引不是实时的——上传后需要轮询 operation.done 确认完成。对实时索引要求高的场景(如工单系统秒级更新)更适合自建向量库。
超大规模文档库:单个 FileSearchStore 的容量限制目前以百万级文档为目标(具体阈值未公开),如果你的语料库在千万级以上,建议先咨询 Google 的文档或联系销售了解上限。
常见问题 FAQ
File Search 的嵌入模型可以切换吗?
不可以。创建 FileSearchStore 时指定的 embedding_model 后续不可更改。如果需要切换模型,必须创建新存储并重新索引所有文档。
上传的文件会被永久保存吗?
通过 upload_to_file_search_store 上传的文件,原始文件在 48 小时后自动删除。但嵌入数据会在 FileSearchStore 中永久保留,直到你手动删除。
可以用免费 API 密钥使用 File Search 吗?
可以。File Search 对所有 API 密钥层级可用,但免费层的速率限制和模型访问范围有所不同。建议从 Gemini 3 Flash Preview 开始测试。
支持哪些文件格式?
文本文件(TXT、PDF、Markdown)和图像文件(PNG、JPEG)。不支持音频和视频。图像分辨率上限 4K×4K,每请求最多 6 张图片。
性能怎么样?响应速度如何?
File Search 的检索延迟取决于文档库大小和 query 复杂度,通常在 500ms–3s 之间(不含模型生成时间)。Google 未公开 FileSearchStore 的最大容量限制,建议百万级以下文档直接使用,千万级以上联系销售。