在边缘构建 RAG：Cloudflare Workers、Vectorize 与 FAISS — 实际可行的方案

Source: Dev.to

介绍

我使用 Cloudflare Workers、它们的新 Vectorize 服务以及 FAISS 构建了一个 检索增强生成（RAG）系统。以下是我的收获：

• 边缘计算很酷，但它并非万能钥匙。
• 这套技术栈可行，但你会遇到传统方法所规避的摩擦点。

这不是教程——而是一次对真实权衡的事后分析。

第1节：看起来很理想的架构

为什么我选择了这套技术栈

• Cloudflare Workers – 承诺无冷启动的无服务器推理。
• Vectorize – 边缘托管的向量存储。
• FAISS – 超快速的本地相似度搜索。

理论上：零延迟、零运维开销、成本高效。但实际操作中，情况更为复杂。

设置步骤

1. 将嵌入存储在 Vectorize（Cloudflare 基于 Postgres 的托管向量数据库）中。
2. 部署一个 Worker，对文档进行分块，并使用本地大语言模型生成嵌入。
3. 在开发期间，将 FAISS 用作仅本地推理的后备方案。

# Install dependencies
npm install @cloudflare/workers-types wrangler faiss-node
pip install faiss-cpu langchain sentence-transformers

# Configure wrangler.toml
[env.production]
vars = { VECTORIZE_INDEX = "rag-index-prod" }

该架构看起来很稳固，但实际执行中暴露出三个难题。

第2节：Cloudflare Workers + Vectorize 实际失效的地方

问题 1 – Worker 执行超时 vs. 嵌入生成

Cloudflare Workers 在生产环境中有 30 秒 CPU 超时。为超过约 2 000 token 的文档生成嵌入往往会持续超出此限制¹。

解决方案： 将繁重的工作转移到后台任务或 Durable Objects，这就违背了 “无服务器简易性” 的宣传。

# This works locally. This fails at the edge.
def embed_document(text: str):
    model = SentenceTransformer('all-MiniLM-L6-v2')
    embeddings = model.encode(text, show_progress_bar=True)  # 5‑15 s per doc
    return embeddings

问题 2 – Vectorize API 延迟并非宣传的那样

Vectorize 查询即使是最简单的相似度搜索，也会出现 200‑400 ms 的响应时间。营销宣传说 “边缘速度”，但实际上仍然要经历一次数据库往返。一个本地的 FAISS 索引完成同样查询只需 ≈ 1 秒，这已经可以接受。

Cloudflare Workers + Vectorize 失效的场景：

• 需要子 200 ms 检索、重新排序或大量推理的 RAG 流程。
• 抽象层泄漏——你仍然需要管理 Durable Objects、KV 备份以及外部服务。

本地 RAG 的优势在于：

边缘计算真正有意义的场景： 轻量级推理（分类、路由），而非 RAG。

经验教训： 不要仅因为 Cloudflare Workers 很流行就使用它们。只有在你的问题符合它们的约束时才使用它们。RAG 并不符合。将其部署在本地或传统的带 GPU 的服务器上，你会更快交付并节省成本。

来源

5

Footnotes

1. Cloudflare Workers 在生产环境中强制执行 30 秒的 CPU 执行时间限制。 ↩