WordPress AI 搜索与 Gemini File Search Store：哪些有效，哪些无效
Source: Dev.to
这是一篇提交作品，参加 Built with Google Gemini: Writing Challenge
我用 Google Gemini 构建的项目
默认的 WordPress 搜索会返回与关键字匹配的文章列表。它不理解意图，不能回答问题，在用户期待对话式 AI 和完整句子查询的时代显得过时。
我构建了 Geweb AI Search —— 一个 WordPress 插件，用 Google Gemini 提供的 AI 助手取代传统搜索。
工作原理
与链接列表不同，用户将获得：
- 直接的 AI 生成答案
- 生成该答案所使用的确切页面的来源链接
- 可选的对话历史，用于后续提问
插件拦截标准的 WordPress 搜索表单，并打开一个包含两种模式的模态框：
| 模式 | 描述 |
|---|---|
| 自动完成 | 由 WP_Query 提供支持的即时建议 |
| AI 回答 | 完整的 Gemini 响应并附带来源归属 |
此架构的核心是 Gemini File Search Store。
为什么选择文件搜索存储而不是传统 RAG？
一个典型的基于 LLM 的站点搜索通常需要：
- 将内容转换为向量嵌入
- 将它们存储在向量数据库中（Pinecone、pgvector、Weaviate 等）
- 对每个查询执行相似度搜索
- 检索相关片段
- 将这些片段作为上下文传递给 LLM
这是一套完整的 RAG 堆栈——基础设施繁重且运维复杂。
Gemini 文件搜索存储简化了工作流
- 将 WordPress 帖子转换为 Markdown
- 通过 Gemini API 将文档上传到 Store
- 当查询到来时，指示 Gemini 使用该 Store
索引、检索和答案生成均由 Gemini 在内部处理。
- 无需单独的向量数据库
- 无需嵌入管道
- 无需检索编排层
理想使用场景
- 企业网站
- 文档门户
- 电商目录
- 内容丰富的博客
由于模型严格在上传的内容范围内工作，响应会基于站点数据而非通用模型知识，从而保持答案的可靠性。
演示
- 实时演示： – 立即测试自动完成和 AI 回答。
- WordPress 目录：
- 源代码：
截图
我学到的
Gemini 3 与 2.5 – 有哪些变化以及对集成有什么影响
在集成过程中，我发现 Gemini 2.5 与 Gemini 3 在使用文件搜索 Store 时存在重要的行为差异。
| 观察点 | Gemini 2.5 | Gemini 3 |
|---|---|---|
| 结构化 JSON 响应（非 Store 模式） | 可靠 | 可靠 |
| 结构化 JSON 响应（Store 模式） | 以纯文本返回 | 支持并带有来源归属 |
| 对基于 Store 的搜索 + 结构化输出的整体支持 | 有限 | 改进 |
要点： 如果你的 UI 依赖结构化响应（例如程序化渲染或附加元数据），模型版本就很关键。插件支持两种生成方式，但完整的结构化归属在 Gemini 3 上才能正常工作。上线前务必在预发布环境中测试具体的模型 + Store 组合。
安全的 API‑key 存储
Gemini API 密钥使用 libsodium 加密后存放在 WordPress 数据库中。
实现原则
- 密钥在写入数据库前会被加密。
- 只有具备相应 WordPress 权限的用户才能修改它。
- 解密仅在运行时、发起 API 请求时进行。
- 不依赖外部库。
Store 开启了新用例
在开发此插件的过程中，我意识到文件搜索 Store 不仅仅是搜索功能。它为基于隔离、可信内容的整套 AI 驱动特性提供了可能：
- AI 驱动的网站搜索
- 企业网站的虚拟助理
- 在线商店的产品顾问
- 基于真实文档的 FAQ 机器人
这些都遵循同一原则：将结构化内容上传到 Store，让模型严格在这些边界内工作。这样即可在不构建完整自定义 RAG 堆栈的情况下，获得可预测、内容限定的答案。
Google Gemini 反馈
表现良好的方面
- File Search Store 是最大的收获。
- 无需启动向量数据库、构建嵌入管道、管理相似度搜索或维护检索逻辑。
- 只需上传文档，Gemini 会在内部处理索引和检索。
从开发者的角度来看，这显著降低了基础设施的复杂性并加快了上市时间。
导致摩擦的因素
(内容在原始提交中被截断。)
Source: …
Gemini 文件搜索存储 API（v1beta）的问题
该 API 仍处于 beta 阶段（v1beta），问题也随之而来。
1. 多个基础 URL
文件上传使用：
https://generativelanguage.googleapis.com/upload/v1beta而其他操作使用：
https://generativelanguage.googleapis.com/v1beta在不同的基础 URL 之间对同一逻辑实体进行操作会让人感到困惑。
2. 不同的上传流程返回不同的结构
上传文件有两种方式：
- 先上传文件，再将其附加到 Store
- 直接上传到 Store 中
这两种方式返回的响应格式不同。
- 如果单独上传后再附加，路径以
files/...开头。 - 如果直接上传到 Store，得到的路径是
documents/...。
对于文件搜索 Store 查询，需要使用 documents/... 格式。这一点并不直观，需要通过反复试验才能发现。
3. 负载下的稳定性
在高峰时段，API 有时会出现延迟或间歇性错误。在生产环境中，这需要：
- 合理的错误处理
- 使用指数退避的重试逻辑
我希望看到的
- 统一的基础 URL 用于所有 API 操作
- 一致的响应结构 跨上传流程
- 清晰的文档 包含端到端文件搜索存储示例
- 存储级别的管理操作（例如，一次请求删除包含所有文档的 Store）
- 长期目标： 兼容 S3 的存储接口，以便更容易集成
- 一个稳定的、非 beta 发行版
总体收获
Google Gemini ——尤其是 File Search Store ——显著降低了构建 AI 驱动站点搜索的门槛。对于 WordPress 开发者而言，这使得在不维护完整 RAG 基础设施的情况下实现高级 AI 搜索成为可能。