← 返回概念解读

Concept Fable精修版

文件搜索

File Search · Managed retrieval tool

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

文书终于不用把整柜合同背进大堂

云桥邮馆常替客户回答合同问题。早年合同少,文书把几份文件摆在桌上,边读边回信,勉强够用。

后来客户上传了几百份手册、报价单和协议。文书若把整柜资料都带进大堂,桌子放不下;若只凭记忆回答,又常漏掉细则。

馆长先让客户把重点页标出来。客户并不知道问题会落在哪一页,标得太少漏证据,标得太多又回到纸山。

他又让文书每次全文搜索关键词。遇到同义词、表格说明和跨页上下文,关键词常找不到真正相关的段落。

新档案师把文件先整理入库,切成可检索片段,建立索引。客户提问时,系统先取回相关内容,再交给文书组织回答。

文书的任务从背文件变成引用证据。他必须说明答案来自哪些片段,哪些文件没有覆盖,哪些问题需要继续查。

档案师还设置更新流程。新文件上传后要重新索引,旧文件失效要下架,不同客户的文件不能串到一起。

几周后,邮馆回答文件问题的速度快了很多。文书不用装作记住所有材料,也不再把无关文件塞满上下文。馆长明白,文件搜索的价值不是让那套机器神奇读完整柜文件,而是把相关证据在正确时刻送到那套机器面前。后来,又来了一件更棘手的活。表面看只是旧问题放大,实际把藏在流程里的缝隙都逼了出来:谁先接手、谁能改动、出了错怎样回到上一步,过去靠熟人默契混过去的地方,现在都必须说清楚。主事人没有再催大家更用心,而是把现场重新走了一遍。他让人记录每次交接、每次失败和每次补救,哪些地方只是慢,哪些地方会误伤结果,哪些地方一旦错了就很难追回。新规矩推开后,最初几天并不顺手。有人嫌多了一道检查,有人觉得旧经验被冒犯。可当下一次异常出现时,大家第一次能沿着痕迹找到问题发生的位置,而不是围着结果互相猜。

揭示

这个故事讲的是:文件搜索

File Search 是托管检索能力:将上传文件建立索引,在模型生成回答时检索相关内容。它通常承担 RAG 中的文件摄取、切分、索引和召回环节,适用于合同、手册、知识库等场景,但仍需要处理权限隔离、文件更新、引用质量和答案评测。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 整柜合同:大量企业文件和知识资料
  • 桌子放不下:context window 限制
  • 全文关键词搜索:简单 lexical search 的局限
  • 整理入库并切片:document ingestion、chunking、indexing
  • 取回相关内容:retrieval / File Search
  • 引用证据:grounded answer 与 citations
  • 文件不能串到一起:tenant isolation 与 permissions
  • 最后洞察:File Search 把文件资料转成可检索证据,而不是把全部文件硬塞给模型

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

RAGvector storeretrievalAssistants APIResponses APIdocuments