Google新推出的RAG工具：File Search Tool

File Search Tool 本质上就是 Google 给 Gemini 做好的“一体化托管 RAG 管线”。

一、它到底是什么？放在 Gemini 里的“托管 RAG 引擎”

1. File Search 是 Gemini API 里的一个 Tool，用来做 Retrieval Augmented Generation（RAG）。你把自己的文档丢给它，它负责导入、切块、向量化、索引和检索，然后在 generateContent 时自动把检索到的内容塞进上下文里。Google AI for Developers+1
2. 相比传统 RAG 要自己选向量库、调 chunking、管 embedding 和索引，File Search 是“全托管”：
   • 文件存储、分块策略、embedding 生成、向量检索、上下文注入全都由 Google 负责。blog.google+1
   • 调用方式仍然是普通的 generateContent，只是在 tools 里加上 file_search 配置即可。Google AI for Developers
3. 它用的是最新的 Gemini Embedding 模型（例如 gemini-embedding-001），通过语义向量检索来理解你的 Query，而不是简单关键词匹配。blog.google+1

简单一句话：这是给 Gemini 做的“官方知识库 + 检索后自动引用”的服务。

二、核心概念：File Search Store / Document / Chunk

1. File Search Store（文件搜索库）
   • 你可以把它理解为一个托管的向量数据库实例。
   • 名字形如 fileSearchStores/my-file-search-store-123。Google AI for Developers+1
   • 每个 Store 里可以有很多 Document（文档），文档再被拆成若干 Chunk（块），这些 Chunk 才是真正被向量化和索引的单位。Google AI for Developers+1
2. Document（文档）
   • 对应你上传的一份源文件（PDF、DOCX、TXT、JSON、代码文件等）。blog.google+1
   • API 里以 fileSearchStores/*/documents/* 形式存在，可以单独删除、更新。Google AI for Developers
3. Chunk（块）
   • 文件导入时会自动被分块，并为每个块生成 embedding；你也可以通过 chunking_config 调整每块最大 token 数和重叠 token 数。Google AI for Developers+1
   • 分块策略会直接影响召回质量、上下文拼接效果和延迟。

三、基本工作流：从导入文件到问答

File Search 的典型流程可以分为 5 步（Python / JS / REST 都类似）：Google AI for Developers+1

1. 创建 File Search Store
   • 通过客户端：
     • Python: client.file_search_stores.create(config={'display_name':'my_rag_store'})
     • JS: ai.fileSearchStores.create({ config: { displayName: 'my_rag_store' } })
2. 上传并索引文件
   • 直接上传到 Store：upload_to_file_search_store（或 REST 的 uploadToFileSearchStore 端点）。Google AI for Developers+1
   • 或者：先用 Files API 上传成临时 File，再用 importFile 导入 Store。Google AI for Developers
   • 这个过程是长任务（Long-running Operation），需要轮询 operations.get 直到 operation.done == true。Google AI for Developers+1
3. 自动 chunking + embedding + 索引
   • 导入完成时，系统已经自动：
     • 拆成多个 Chunk
     • 使用 Gemini Embedding 模型生成向量
     • 存进托管的 File Search Store 索引里Google AI for Developers+1
   • 如需自定义分块，可提供： "chunking_config": { "white_space_config": { "max_tokens_per_chunk": 200, "max_overlap_tokens": 20 } }

4. 在 generateContent 中启用 File Search 工具
   • 典型调用结构是：
     • 指定 model: "gemini-2.5-flash" 或 gemini-2.5-pro
     • tools 中传入 file_search，并写上 file_search_store_names: [store.name]Google AI for Developers+1
   • 模型在生成前会：
     • 将用户 Query 转成向量
     • 在 Store 里做语义检索
     • 把最相关的几段文本作为上下文拼进 Prompt，再回答
5. 带引用的回答（Citations）
   • 输出中会自动带“引用来源”，指明答案用到了哪个文档、哪一段内容，方便你追溯和验证。blog.google+1

四、价格与资源限制：只为“初次索引”付费

1. 计费模型
   • 存储 + 查询时生成 embedding：免费。
   • 只有“初次索引”（即第一次为文档生成 embedding）需要按 token 计费，目前官方示例价是：
     • 大约 $0.15 / 100 万 tokens，按使用的 embedding 模型单价结算（文中以 gemini-embedding-001 为例）。blog.google+1
2. 容量和限制（来自公开教程总结）Analytics Vidhya
   • 单文件最大约 100 MB
   • 每个项目最多 10 个 File Search Stores
   • 存储配额大致为：
     • 免费层：总共 1 GB
     • 付费 Tier1/2/3：分别约 10 GB / 100 GB / 1 TB
3. 模型支持
   • File Search 目前支持在 gemini-2.5-pro 与 gemini-2.5-flash 上使用，都支持 grounding、元数据过滤和引用。Analytics Vidhya

五、支持的文件类型与语义检索能力

1. 文件类型
   • 官方明确支持的包括：PDF、DOCX、TXT、JSON，以及多种常见编程语言源代码（例如 .py、.js 等）。blog.google+1
   • 对于构建“知识库型 RAG”，可以直接把技术文档、规范、代码仓的关键文件丢进去。
2. 检索方式：语义向量搜索
   • File Search 用的是语义检索：它根据 Query 的“含义”而不是关键字做匹配。
   • 这意味着：
     • 即使用户提问的措辞与文档中不同，也能匹配到相关内容。Google AI for Developers+1
     • 对长文档、多文件库特别友好，不需要你自己写复杂的过滤逻辑。

六、与自己搭 RAG Pipeline 相比，有哪些差异？

1. 你不再需要：
   • 自己部署 / 管理向量数据库（如 PGVector、Qdrant、Pinecone 等）。
   • 自己调用 embedding 接口并存储向量。
   • 自己设计/调参 chunking 逻辑、控制 overlap、手动写检索 + rerank pipeline。Philschmid+1
2. 你将得到：
   • 完全托管的 Store（有免费额度和简单的分级容量）。Analytics Vidhya+1
   • 内置 citations：让你在前端直接展示“这段话来自哪份 PDF 第几块”。blog.google+1
   • 和 Gemini 模型紧耦合的 DX：所有操作都在同一个 SDK / API 中完成，减少 glue code。Google AI for Developers+1
3. 但也意味着：
   • 索引在 Google 基础设施中，你不能像操作自建向量库那样任意做自定义算子、直接跑 ANN Benchmark 等。
   • 嵌入模型由官方指定，灵活度不如“任意 embedding + 任意模型”的组合方案。
   • 与其它云 / 本地系统的深度一体化，需要考虑通过应用层做桥接，而不是直接共享同一个向量库。

七、典型应用场景（官方示例 + 你可以怎么用）

官方 Blog 里提到了几个早期接入的案例：blog.google+1

1. 智能客服 / Support Bot
   • 把 FAQ、手册、工单知识库全部导入 File Search；
   • 用 Gemini 2.5 Flash 做多轮对话，利用 citations 告诉用户答案出处；
   • 适合 SaaS 产品、Dev Docs、自助服务终端（你之前做电梯知识库 / 支持系统也可以直接套）。
2. 内部知识助手
   • 导入公司内部规范、流程、会议纪要、技术文档；
   • 让员工问“这条流程有没有例外情况”，“某个型号的设备安装步骤”；
   • File Search 会自动在所有库里并行检索，延迟控制在 ~秒级。blog.google+1
3. 内容发现与创意平台
   • 比如 Blog、游戏内容、故事模版等，开发者 Beam 用它来对海量模版做并行检索，每天跑上千次查询，把结果控制在 2 秒内返回。blog.google

八、和 Google 其它“Grounding 方式”的关系

1. File Search vs 自己的 Search API Grounding
   • 在 Vertex AI 文档中，Google 还支持“用你自己的搜索 API 来做 Grounding”，也就是模型会调用你提供的 HTTP 搜索接口作为工具。Google Cloud Documentation
   • 那种方式适合你已经有现成的搜索服务（如内部 ElasticSearch、定制知识图谱 API）。
   • File Search 则是“没有现成搜索服务时的托管方案”：你只要有文件，就能立刻搭一个语义检索 + RAG 系统。blog.google+1
2. File Search vs 传统“长上下文 + 直接塞全文”
   • 长上下文会很快吃满 token，还容易被“无关信息”污染。
   • File Search 是在模型上下文之外做索引 + 精选召回，只把相关段落塞进 prompt，更节省 token，也更可控。Analytics Vidhya+1

九、使用时可以重点关注的几个“工程细节”

1. Chunking 策略
   • 长技术文档（比如标准、论文）建议适当提高 max_tokens_per_chunk，但保持适度 overlap；
   • 过小的 chunk 容易丢掉上下文；过大的 chunk 会拖慢检索并导致“召回一大块无关内容”。Google AI for Developers+1
2. 文档组织与 Store 规划
   • 可以按业务域、产品线或保密等级划分 File Search Store；
   • 对于非常大的知识库，可用“顶层 Store + Tag / 元数据过滤”方式来做逻辑拆分。
3. 安全与合规
   • 需要考虑：哪些文档允许上传到公有云；
   • 不同项目 / 租户最好使用不同的 File Search Store 和 API key，以免数据混用。
4. 成本控制
   • 初次索引是按 token 计费的：可以先试小样本（核心标准章节、典型案例）验证效果，再批量导入整库。