用 Go 和 Gemini File Search 做便宜 RAG：不要向量库，两次调用，一个托管存储
来源：dev.to — 2026-09-22
📋 概述
作者想要一个对着「团队书架」回答问题的工具：粘贴设计提案、ADR 或复盘草稿，它回来说清真正被提议的是什么、底下是什么模式、以及书架上哪三处已经有人撞过同一个形状——要带引用、要落地，而不是「LLM 读了你的文档然后有了感想」。常规做法是向量库加嵌入管线、分块与重排，他一样都没用，只用 Go、Gemini 免费额度，检索侧运行成本为零。Gemini 的 File Search 让人建 store、上传文档，由 Google 负责分块、嵌入和索引，然后把 store 作为工具挂到普通的 generateContent 调用上，模型自己在中途检索并返回 groundingMetadata。
🔑 核心要点
- 架构短到尴尬：一个 Go 二进制、SQLite（modernc.org/sqlite，无 cgo）、一个不用 SDK 的 REST 客户端，每个问题两次模型调用，一个托管存储。
- 成本结构是关键：存储免费、查询时嵌入免费，只在建索引时按嵌入价格付一次，检索到的分块按普通上下文 token 计费。
- 免费额度下 store 上限 1 GB，而他整个书架转成 markdown 只有 5.3 MB。
- 文档转换踩过坑：markitdown 把每个单词和邻居粘在一起，pdftotext 修好空格却丢掉全部标题，最后 pymupdf4llm 靠字号判断标题胜出。
- 标题之所以重要，是因为 File Search 按 token 预算和空白分块：从标题开始的分块才有意义，从句子中间开始的分块只是带嵌入的噪音。
💡 金句
把东西落地，带上引用，而不是让 LLM 读了你的文档然后有了点感想。
👍 0
👎 0
← 返回 dev.to 首页