Gemini 检索通道怎么选

Gemini 的检索有三条通道：公开实时信息走 google_search，指定网页走 url_context，私有文档走 file_search；File Search 不能与其他工具在同一请求组合。（核验 2026-11-05，F98）

一、Gemini 检索通道怎么选：问题不是哪个更强，而是数据在谁手上

「接个搜索让它能查资料」——这句话听起来是一个动作，实际是三个不同的决定。Gemini 给了三条检索通道，长得像、用法像，解决的问题完全不同：

• google_search：模型自己去公开网络上搜，查询词由它生成。
• url_context：你给具体网址，它去把那几页读下来。
• file_search：你把文档传上去建一个库，它在库里做语义检索。

选错的代价不是「效果差一点」，而是白花钱还拿不到答案：拿 google_search 去查一份内部合同，永远搜不到；拿 file_search 去查今天的汇率，库里根本没有这份数据。

更关键的一条硬约束：File Search 不能与 Grounding with Google Search、URL Context 等工具在同一请求里组合（F98）。这意味着「既搜公开网络、又查私有库」不是加一个工具的事，而是两次调用、两套结果、你自己合并。通道选择因此是一个互斥决策，不是加法。

二、Gemini 检索通道选择：最小可运行示例

把需求拆成四个特征，选择就变成一个可复算的函数。

## EXPECT: 今天的汇率 → google_search | 这份合同的条款 → file_search | 这个页面的价格 → url_context | 把这段话改短一点 → 不用检索，直接回答 | File Search 不能与其他工具组合
NEEDS = [
    {"name": "今天的汇率", "public": True, "fresh": True, "has_url": False, "owned_doc": False},
    {"name": "这份合同的条款", "public": False, "fresh": False, "has_url": False, "owned_doc": True},
    {"name": "这个页面的价格", "public": True, "fresh": False, "has_url": True, "owned_doc": False},
    {"name": "把这段话改短一点", "public": False, "fresh": False, "has_url": False, "owned_doc": False},
]

def pick(need):
    if need["owned_doc"]:
        return "file_search"
    if need["has_url"]:
        return "url_context"
    if need["public"] and need["fresh"]:
        return "google_search"
    return "不用检索，直接回答"

picked = [(n["name"], pick(n)) for n in NEEDS]
assert picked[0][1] == "google_search"
assert picked[1][1] == "file_search"
assert picked[2][1] == "url_context"
assert picked[3][1] == "不用检索，直接回答"
print(" | ".join(f"{name} → {tool}" for name, tool in picked) +
      " | File Search 不能与其他工具组合")

四个特征的顺序就是判断优先级：文档归你所有（owned_doc）优先，因为这是唯一需要你先建库的通道；其次你手上有具体网址；再次才轮到「公开且需要最新」。顺序反了会怎样？一条「我内网 wiki 上的这篇文档」的需求，如果先判 public，会被错误地送进 google_search，然后拿到一堆看起来相关但完全不对的内容。

第四条需求落进了「不用检索」这个分支，值得单独看一眼：它不是「查不到」，而是「本来就不需要查」。这类请求如果被强行挂上检索工具，模型可能会为了用上工具而编一个搜索词，拿回一堆无关材料再硬答——比不加检索更糟。什么时候该让模型凭已有知识回答，是一条产品判断，不是技术判断。

三、解释与边界：三条通道各自的前提

google_search 的前提是「公开且可检索」。 它会先分析问题，判断要不要搜，然后自动生成一条或多条查询（F89 的计费口径就是按这些查询算的）。所以它适合「今天的汇率」「某公司最新公告」这类问题，不适合「我们内部系统的接口文档」。

url_context 的前提是「你已经有确切地址」。 它的检索是两步：先查平台内部索引缓存，没命中再实时抓取（F91）。响应里除了正文，还有 url_context_result 记录每次抓取的状态与最终 URL（F92），排查「为什么这页没读到」时先看它。硬限制也很直接：单请求最多 20 个 URL、单页 34MB、必须公网可访问——localhost、私有网络、隧道服务都不支持（F93）。

file_search 的前提是「你愿意先建库」。 它是 embedding 语义检索，不是关键词匹配；建库三步：建 store、上传并导入（切片、向量化、建索引）、查询时指向该 store（F97）。生命周期上有个容易忽略的点：embedding 没有 TTL，会一直留着；但导入时生成的原始 File 对象在 48 小时后删除（F96）。所以别再指望回头去下载当初那个文件，要留档得自己留。

边界。 本节只做「选哪条」。搜到什么之后怎么把引用显示出来，见 7.2；搜索按次计费怎么算账，见 7.3；私有库的权限与隔离，见 7.4。本节也不评价三家搜索引擎的质量差异——那属于评测，不属于接入。

四、预期输出与异常分支

真跑输出：

今天的汇率 → google_search | 这份合同的条款 → file_search | 这个页面的价格 → url_context | 把这段话改短一点 → 不用检索，直接回答 | File Search 不能与其他工具组合

六类分支。答不准但通道选对了：先看是索引旧了还是查询词偏了，别急着换通道。把内网文档丢给 google_search：搜出来的东西看着相关、实则无关，这是最容易被误判成「模型不行」的一类。url_context 抓不到：先看 url_context_result 的状态，付费墙、YouTube、Workspace 文件、音视频本身就不在支持范围（F94）。URL 是 localhost 或内网地址：直接被拒，隧道服务也不行（F93）。想同时查公开网络和私有库：File Search 不支持组合（F98），只能分两次调用，再自己合并结果。文件上传后过两天想重新下载：原始 File 已删（F96），要在导入时就留好源文件。

五、判据卡：答不准时先查通道还是先调提示词

六、来源与核验

• https://aistudio.google.com/docs/google-search.md（核验 2026-11-05，F89、F90）
• https://aistudio.google.com/docs/url-context.md（核验 2026-11-05，F91、F92、F93、F94）
• https://aistudio.google.com/docs/file-search.md（核验 2026-11-05，F96、F97、F98）

三条通道的能力与限制属于「API 结构／区域与能力」档事实，复核周期三个月，见 1.3。若官方放开 File Search 的工具组合限制，本节「互斥」这个结论要重写，不能只改一句。

七、动手试

1. 在 NEEDS 里加一条 {"name": "我们产品的报价单", "public": False, "fresh": False, "has_url": True, "owned_doc": False}，重跑。预期走 url_context；验收标准是你能说清「为什么它不该走 file_search」——提示：文档不在你手上，只是有一个地址。
2. 把 pick 里 owned_doc 与 has_url 的判断顺序对调，重跑。预期「这个页面的价格」仍走 url_context、「这份合同的条款」变成 url_context；验收标准是说明这个错误会造成什么线上后果。
3. 打开你项目里接检索的那段代码，看它用的是哪条通道。验收标准：写一行「数据来源 + 通道」；如果来源是私有文档而通道是搜索，这就是要改的第一处。