RAG被判死刑：Google用一行API架空工程师！

Google宣判RAG死刑！那条曾让无数工程师自豪的技术链，如今只剩下一行API调用。Gemini的File Search，把检索、分块、索引、引用，全都封进了模型内部。开发者不再需要理解流程，只需要上传文件。当智能被自动化吞并，工程师第一次发现，自己也成了被自动化的一部分。

在过去几年里，RAG是工程师的底气。

他们手动切块、生成向量、建立索引，再把检索到的内容精准拼进prompt。

那是一整套细腻又繁琐的工程活，只有真正懂这些流程的人，才敢说自己「会用大模型」。

而现在，这份骄傲被一行API抹平了。

Gemini的File Search上线后，上传一个PDF或JSON，模型就能自动完成分块、检索、引用，甚至附上来源。

File Search 抽象化了整个检索流程。

这句话像一把锋利的刀，切掉了人和系统之间最后一点链接。

AI不再需要工程师去教它查资料，而工程师，也开始被自己的发明优化掉。

从流程到函数：Google一刀切掉RAG工程链

Gemini的File Search发布后，RAG从工程系统变成了API内置能力。

上传文件，模型自动完成分块、embedding（向量化）、索引、检索与引用，全部在同一接口内完成，无需自建向量库或维护检索逻辑。

多格式支持也被一次性打通：PDF、DOCX、TXT、JSON，以及常见代码文件可直接解析和嵌入，快速搭建统一知识库。

这让开发者能快速构建完整的知识库，而不必再为文件类型或结构做额外适配。

在更新说明中，它被定义为：

一个完全托管的RAG系统，已直接嵌入Gemini API，检索流程被彻底抽象化。

开发者不再需要设计chunk策略或索引结构，系统会在后台自动完成所有环节。

Gemini File Search工作流程：上传文件→自动生成embedding→调用Gemini检索并生成答案→输出含引用结果

定价被改成了「轻入口」：查询时的存储与embedding生成免费；只在首次索引按$0.15/百万tokens计费，这让部署与扩容的边际成本趋近于零。

这意味着搭建知识检索的成本几乎降为零，RAG的技术门槛也随之被平台吸收。

File Search的逻辑：RAG嵌进API

File Search的核心不在能不能搜，而在隐藏整条检索链。

在过去，想让模型基于外部资料回答问题，必须自己搭一套RAG流程：

先把文件切成小块，再用embedding模型把每块转成向量，存入向量数据库；当用户提问时，再检索最相关的片段，把结果塞进prompt里生成回答。

Ask the Manual演示应用程序由Gemini API中的全新文件搜索工具提供支持

整个过程需要维护数据库、管理索引、调参、拼接prompt，每一步都依赖工程师。

而现在，这一切被放进了Gemini API的底层。

上传文件，系统自动完成分块、embedding与索引；提问时，调用同一个generateContent接口即可，Gemini会在内部完成语义检索与上下文注入，并在回答中自动生成引用。

甚至使用的是专门的gemini-embedding-001模型，确保检索与生成的语义空间完全一致

上传一份关于现代i10的文档并询问「什么是现代i10？」。Gemini会检索相关段落，撰写有理有据的答案，并显示支持该答案的来源。

更重要的是，File Search改写了开发逻辑。

开发者不再需要额外部署数据库，也不需要维护检索管线；整个过程只在一次调用中完成。

这意味着，RAG从一个独立系统变成了一个参数。

过去要几百行代码才能跑通的流程，现在是一行配置。官方示例调用如下：

response = client.models.generate_content(

model='gemini-2.5-flash',

contents='What does the research say about ...',

config=types.GenerateContentConfig(

tools=[types.Tool(

file_search=types.FileSearch(

file_search_store_names=[store.name]

)

)]

)

)

当所有检索、存储、注入、引用都自动完成，工程师再也不用理解系统怎么找到答案。

File Search让RAG从一套需要掌握的知识，变成一项被调用的功能。

那一刻，技术不再是一种能力，而成了一种选项。

被抢走工作的工程师

File Search的上线，不只是一次工具升级，而是一场角色迁移。

它让系统具备了自我构建的能力——能够自动切块、索引、检索、引用。

过去，理解这些逻辑是工程师的价值所在；现在，这种理解被彻底隐藏。

在早期接入里，Beam（Phaser Studio）的变化最直观：

他们把File Search接进内容生产线，用来检索模板、组件与设计文档；每天上千次查询跨越六个语料库，两秒内合并结果。

CTO ichard Davey的说法是：

过去几天的工作，现在几分钟就能出结果。

这当然是生产力的进步，但也意味着——工程师失去了对系统的解释权。

当检索策略、引用逻辑、甚至数据结构都由平台控制，工程不再是搭建系统，而是调用系统。

从外部看，这只是少写几百行代码；但从内部看，这是知识密度被平台吸收的瞬间。

当复杂被隐藏，人也随之变得可替换。

权力的迁移：从工程师到平台

File Search的出现，真正重塑的不是开发体验，而是权力结构——它让理解系统的人从工程师变成了平台。

在传统的RAG流程中，工程师拥有对系统的掌控权。

他们能决定怎样分块、怎样索引、怎样检索，也能解释模型为什么会给出某个答案。

这份掌控感来自于可见性——他们看得见每一步的逻辑。

File Search把可见的工程步骤收进了不可见的API。

检索策略、索引结构、引用规则被托管在云端，开发者只看得到答案，看不到过程

这意味着知识注入的权力正在集中：模型基于哪些段落回答、忽略了哪些证据、如何权衡检索结果，均由平台决定。

工程师不再「构建系统」，而是「调用系统」。

这并非孤例。OpenAI的Custom GPTs、Anthropic的Console、以及Gemini的File Search，都在把复杂度下沉到平台底层，让开发更容易，也更受控。

每一次抽象化，都是一次权力集中。

File Search的诞生，让AI开发进入了零配置时代：

人不再需要理解模型，只需调用模型；平台不再提供能力，而是直接提供结果。

这场变化没有任何戏剧性的冲突，却彻底改变了技术的边界。

当系统自己搭建系统，个人的理解被替代为对平台的信任。

File Search并没有「杀死」RAG，它只是把RAG变成了系统的血液。

复杂被隐藏，权力被集中；工程师要做的，是在更高一层的封装里，找到新的入口。

参考资料：

https://blog.google/technology/developers/file-search-gemini-api/

https://x.com/frxiaobei/status/1990091775382602021?s=20

https://medium.com/%40abdulkadir9929/gemini-apis-new-file-search-tool-built-in-rag-for-everyone-e990c054dcff

文章来自于“新智元”，作者 “倾倾”。