AutoRAG 自動化 RAG:Cloudflare 全託管知識庫 | Cloudflare 完整教學

AutoRAG(現稱 AI Search) 是 Cloudflare 推出的全託管 RAG(檢索增強生成) 服務。上一篇我們親手把整條 RAG pipeline 串了起來,這一篇要做的正好相反:把文件丟進 R2,剩下的解析、分塊、產 embedding、建索引、自動更新、查詢生成,全都交給 Cloudflare 自動完成。你只需要呼叫一個 API。這篇帶你搞懂 AutoRAG 怎麼運作、search 與 aiSearch 怎麼用,以及它和自建 RAG 各自適合什麼場景。

前言

上一篇《RAG 架構實作》,我們親手把一整條 RAG pipeline 從頭串到尾:文件分塊、用 Workers AI 產 embedding、upsert 進 Vectorize、查詢時檢索 topK、組 prompt、餵給 LLM 生成回答。整條龍跑通之後,你應該也感覺到了——這裡面有不少重複的苦工:管理 chunking 策略、維護向量索引、處理文件更新、應付寫入的最終一致性延遲……如果你只是想快速做一個「文件問答」,有沒有更省事的方法?

有。這就是這一篇的主角:Cloudflare AutoRAG(現已更名為 AI Search)。

AutoRAG 是一個完全託管(fully-managed)的 RAG 服務。你可以把它想成:上一篇那條你親手寫的 pipeline,現在整條打包成一個 Cloudflare 幫你顧的黑盒子。你要做的只剩三件事——把文件丟進 R2、建立一個 AutoRAG 實例、然後呼叫查詢 API。中間的解析、分塊(chunking)、產 embedding、建立 Vectorize 索引、偵測更新並重新索引,全部由 Cloudflare 自動處理。

打個比方。自建 RAG 就像自己開一間餐廳:採買、備料、切菜、掌廚、擺盤,每一步都你來,好處是想做什麼菜、火候多大都你說了算。而 AutoRAG 像是訂了一份全託管的餐點外送:你只要把「食材」(文件)放進指定的冰箱(R2),廚房就自動幫你把整套流程做完、把成品(答案)端上桌。你少了很多控制權,但也少了幾乎所有的雜活。

要特別強調一點:AutoRAG 不是要取代自建 RAG,而是另一種取捨。 兩者底層其實用的是同一套東西——Workers AI 產 embedding、Vectorize 存向量。差別只在於「pipeline 由誰維護、能客製到什麼程度」。讀完這篇你要能判斷:什麼情況該用 AutoRAG 省事,什麼情況該回頭自建 RAG 換取控制權。

讀完你會掌握:

• AutoRAG 是什麼、怎麼運作——為什麼「文件丟進 R2 就好」,以及它在背後自動做了哪些原本你要手寫的步驟。
• 實際怎麼用——如何接上 R2 資料源、如何用 env.AI.autorag(name).search() 做語意搜尋、用 aiSearch() 直接拿到 AI 生成的答案。
• AutoRAG vs 自建 RAG 的選型——兩者的取捨、適用場景、常見誤解(以為零調校、更新延遲、成本)與限制。

這一篇也是我們 Vectorize / RAG 系列的收尾。開始吧。

核心概念

理解 AutoRAG 最快的方法,就是拿它跟上一篇你親手做的每一步對照。你會發現,AutoRAG 沒有變魔術——它只是把你原本要寫的那些步驟,自動化了。

一、AutoRAG 全託管流程 vs 自建 RAG 對照

先回想上一篇自建 RAG 的索引階段,你要親手做這些:準備文件 → 分塊 → 產 embedding → 寫入 Vectorize +（D1 存原文）。而 AutoRAG 把這一整段換成:把文件丟進 R2,結束。

下面這張圖把兩邊逐步對照,你就能一眼看出 AutoRAG 幫你「吃掉」了哪些工作:

【自建 RAG(上一篇)— 每一步你都自己寫】

你的程式碼:
  讀文件 → splitText() 分塊 → env.AI.run(embedding)
        → env.VECTORIZE.upsert() → env.DB 存原文
  查詢時: 問題向量化 → VECTORIZE.query() → 過濾 → 撈原文
        → 組 prompt → env.AI.run(LLM) 生成


【AutoRAG(這一篇)— 你只做兩端,中間全託管】

你:  把文件丟進 R2  ──────────────┐
                                    ▼
        ┌──────── Cloudflare 自動處理 ────────┐
        │  解析(轉 Markdown)                  │
        │  自動 chunking                       │
        │  自動產 embedding(Workers AI)       │
        │  自動建立 / 更新 Vectorize 索引       │
        │  偵測 R2 變化 → 自動重新索引          │
        └──────────────────────────────────────┘
                                    ▼
你:  env.AI.autorag("name").aiSearch({ query })  →  拿到答案

換句話說,自建 RAG 那條長長的 pipeline,在 AutoRAG 裡被收斂成「R2 進、API 出」兩個端點,中間所有步驟都由 Cloudflare 託管執行。

二、AutoRAG 的運作原理

AutoRAG 的運作可以拆成兩條路徑:索引路徑(由 R2 變化自動觸發) 與 查詢路徑(由你的 API 呼叫觸發)。

索引路徑(自動、非同步):

1. 你把文件(.txt、.md、.pdf、.csv、.html、程式碼、甚至含 OCR 的圖片)上傳到綁定的 R2 bucket。
2. AutoRAG 偵測到 R2 的變化,自動觸發索引任務。
3. Cloudflare 依序完成:解析文件(通常轉為 Markdown)→ 自動 chunking → 用 Workers AI 產 embedding → 寫入它自己管理的 Vectorize 索引。
4. 之後你若在 R2 新增、修改或刪除文件,AutoRAG 會自動偵測並重新索引,讓知識庫保持同步。

這一整條,就是上一篇你要手寫的「索引階段」——現在完全不用你碰。

查詢路徑(由你呼叫):

1. 你呼叫 search() 或 aiSearch(),傳入使用者的問題。
2. AutoRAG 自動把問題向量化、在 Vectorize 裡做語意搜尋、取出最相關的 chunk。
3. 若你用的是 aiSearch(),它還會再進一步把檢索到的內容組成 prompt、餵給 LLM,直接回傳生成好的答案。

三、關鍵術語一次記牢

實作範例

觀念清楚後,我們實際把 AutoRAG 跑起來。這一篇的「實作」跟上一篇有個很大的不同:大部分的建立工作是在 Cloudflare 儀表板上點選完成的,而不是寫程式。 你真正要寫的程式碼,少得驚人。

小提醒:AutoRAG(AI Search)仍在快速演進中,以下的 UI 步驟名稱與 API 方法名稱以當下 Cloudflare 官方文件為準;若名稱有出入,以官方文件為主。核心概念(R2 進、API 出)不變。

1. 準備 R2 資料源

AutoRAG 的知識庫來源是 R2。先建立一個 R2 bucket,把你要索引的文件放進去:

# ① 建立一個 R2 bucket 當作知識庫來源
npx wrangler r2 bucket create my-knowledge-base

# ② 把文件上傳進去(支援 .md / .txt / .pdf / .csv / .html / 程式碼 / 圖片)
npx wrangler r2 object put my-knowledge-base/docs/workers-intro.md --file=./docs/workers-intro.md
npx wrangler r2 object put my-knowledge-base/docs/pages-guide.pdf --file=./docs/pages-guide.pdf

這一步就是你在自建 RAG 裡要親手做的「準備文件來源」。差別是:自建 RAG 你還要自己讀出來分塊,AutoRAG 只要文件「在 R2 裡」就夠了。

2. 在儀表板建立 AutoRAG 實例

接著到 Cloudflare 儀表板建立 AutoRAG(AI Search)實例。這一步取代了上一篇你手寫的「建立 Vectorize 索引 + metadata index + D1 表」那一大串 wrangler 指令:

1. 前往 Cloudflare 儀表板 → AI → AI Search。
2. 點擊 Create,建立一個新實例(取個好記的名字,例如 my-autorag)。
3. 選擇資料來源:選 R2 Bucket,連結上一步建立的 my-knowledge-base。
4. 配置索引設定:embedding 模型、chunking 策略、系統提示(system prompt) 等——這些有預設值,但你可以調整。
5. 建立後,AutoRAG 會開始自動索引 R2 裡的文件。文件量不大時,通常幾分鐘內就完成。

注意這裡有個關鍵認知:建立實例時選的 embedding 模型與 chunking 策略,一旦開始索引就定型了。 這跟上一篇「索引與查詢必須用同一個 embedding 模型」的鐵律是同一回事——只是現在由 AutoRAG 幫你確保兩端一致,你不會不小心用錯模型。

3. Worker binding 設定

AutoRAG 透過 env.AI 存取,不需要單獨的 Vectorize binding(向量索引由 AutoRAG 自己管)。所以 wrangler.jsonc 只要綁 AI 就好,乾淨得出奇:

// wrangler.jsonc
{
  "name": "autorag-worker",
  "main": "src/index.ts",
  "compatibility_date": "2025-01-01",
  "ai": { "binding": "AI" }
}

對比上一篇要綁 ai + vectorize + d1_databases 三個 binding,這裡只剩一個 ai——因為 Vectorize 與文件儲存都被 AutoRAG 收進去託管了。

4. 用 aiSearch() 直接拿到 AI 生成的答案

這是 AutoRAG 最省事的用法:一個呼叫,從「問題」到「生成好的答案」一步到位。它把上一篇你手寫的「向量化 → 檢索 → 過濾 → 撈原文 → 組 prompt → LLM 生成」六步,全部濃縮成一行:

// src/index.ts
export interface Env {
  AI: Ai;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const question =
      new URL(request.url).searchParams.get("q") ?? "Workers 的冷啟動時間是多少?";

    // aiSearch:檢索 + 生成一步到位,直接回傳答案
    const result = await env.AI.autorag("my-autorag").aiSearch({
      query: question,
      model: "@cf/meta/llama-3.3-70b-instruct", // 用來生成答案的 LLM
      ranking_options: {
        score_threshold: 0.3, // 相似度門檻,過濾掉不夠相關的檢索結果
      },
      stream: false,
    });

    // result 大致長這樣(欄位以官方文件為準):
    // {
    //   response: "根據文件,Workers 的冷啟動時間通常在 0-5ms 以內...",
    //   data: [ { filename: "workers-intro.md", content: "...", score: 0.87 } ]
    // }
    return Response.json(result);
  },
};

只要短短幾行,你就有了一個根據自己 R2 知識庫、有依據的問答端點。回想上一篇 rag.ts 那長長的 ragQuery() 函數——現在被 aiSearch() 一行取代了。

5. 用 search() 只做語意搜尋(不生成)

有時候你不需要 LLM 幫你寫一句話的答案,只想拿到「最相關的幾個文件片段」,自己決定後續怎麼用(例如做搜尋結果列表、或把片段接進你自己的更大流程)。這時用 search(),它只做語意搜尋、不做生成,對應上一篇的 VECTORIZE.query():

// 只檢索、不生成 —— 拿回最相關的原始片段
const results = await env.AI.autorag("my-autorag").search({
  query: "Workers 冷啟動",
  ranking_options: {
    score_threshold: 0.5, // 只做搜尋時門檻可設高一點,結果更精準
  },
});

// results 大致長這樣(欄位以官方文件為準):
// {
//   data: [
//     { filename: "workers-intro.md", content: "...", score: 0.89 },
//     { filename: "performance.md",   content: "...", score: 0.81 }
//   ]
// }

search() 與 aiSearch() 怎麼選? 一句話:要「答案」用 aiSearch()(會多花一次 LLM 生成),只要「相關片段」用 search()(較快、較省)。 若你打算把檢索結果接進自己的 prompt 或 agent 流程,通常用 search() 拿片段就好,生成那步自己來,控制權更大。

6. 串流(streaming)生成長答案

跟上一篇一樣,若答案較長、想邊生成邊顯示給使用者,aiSearch() 也支援 streaming:

const stream = await env.AI.autorag("my-autorag").aiSearch({
  query: "如何設定 Cloudflare Pages?",
  model: "@cf/meta/llama-3.3-70b-instruct",
  stream: true, // 開啟串流
});

return new Response(stream as ReadableStream, {
  headers: {
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
  },
});

部署後,GET /?q=你的問題 就能拿到一個由 AutoRAG 全託管、根據你 R2 知識庫回答的問答服務。你沒寫任何 chunking、沒管任何索引、沒組任何 prompt——這就是「全託管」的威力。

常見錯誤與最佳實踐

AutoRAG 最大的坑,幾乎都源自同一個誤會:把「全託管」當成「完全不用大腦」。 它幫你自動化了「執行」,但沒幫你自動化「判斷」。以下是最高頻的幾個。

坑一:以為 AutoRAG 完全「零調校」,選錯設定還怪它笨。

AutoRAG 自動化的是 pipeline 的執行,不是決策。建立實例時,你仍然要選 embedding 模型、chunking 策略、系統提示與相似度門檻——這些選錯一樣會讓檢索品質崩壞。例如系統提示沒約束「只根據文件回答」,LLM 照樣會幻覺;score_threshold 設太低,一堆不相關的片段被塞進生成,答案就開始跑偏。正確做法:把 AutoRAG 當成「幫你跑腿的助理」而非「全自動大腦」,該調的門檻、該寫的系統提示,一個都不能省。

坑二:以為文件更新後「立刻」就能查到最新內容。

AutoRAG 確實會偵測 R2 變化並自動重新索引,但這是非同步、有延遲的過程。你上傳或修改一份文件後,索引任務要跑完(視文件量從數十秒到數分鐘不等)才會反映到查詢結果。這跟上一篇 Vectorize「寫入後 5~10 秒才可見」的最終一致性是同一種脾氣,只是延遲更長(因為多了解析與分塊)。正確做法:別假設「上傳即可查」。 若你的應用需要即時性,在 UI 上明確告知「索引中,稍候可查」,別讓使用者以為系統壞了。實際延遲以官方文件為準。

坑三:被「beta 免費」誤導,忽略底層成本。

AutoRAG(AI Search)在開放測試期間服務層免費,但它底層用到的 Workers AI、Vectorize、R2 是照正常費率計費的。你每次 aiSearch 都會消耗 embedding 推論 + LLM 生成的用量,索引文件也消耗 embedding 用量。正確做法:上線前務必估算底層用量成本,尤其是 aiSearch() 的 LLM 生成——若你的場景其實只需要片段,改用 search() 能省下每次生成的開銷。確切計費以 Cloudflare 官方定價頁為準。

坑四:什麼場景都硬套 AutoRAG,該自建時不自建。

AutoRAG 省事,但它是有邊界的:chunking 策略是它給的選項(不能任意自訂切法)、embedding 模型是固定選單(不能混用 OpenAI 等外部模型)、複雜的多維度 metadata / namespace 過濾也不如自建靈活。正確做法——用下面這張表對號入座:

選型口訣:想快、文件在 R2、不需奇特客製 → AutoRAG;要控制、要客製 chunking / 外部 embedding / 複雜過濾 → 自建 RAG。 兩者底層都是 Workers AI + Vectorize,不衝突;先用 AutoRAG 驗證需求、之後有客製需求再轉自建,是很常見的路徑。

最佳實踐小結: 把 AutoRAG 當「自動化執行」而非「免調校」,該調的門檻與系統提示不能省;接受索引與更新的非同步延遲,別假設上傳即查;分清 search()(要片段、較省)與 aiSearch()(要答案、多花一次生成);記得「beta 免費」只是服務層,底層 Workers AI / Vectorize / R2 照計費,上線前估好成本;客製需求超出 AutoRAG 邊界時,果斷回頭自建。

小結

上一篇《RAG 架構實作》,我們親手把 RAG 的整條 pipeline 從分塊、產 embedding、寫入 Vectorize,到檢索、組 prompt、LLM 生成,一步步串了起來,體會了「完全控制」的力量,也體會了「完全維護」的辛苦。這一篇《AutoRAG 自動化 RAG》,我們走向另一端——讓 Cloudflare 把這整條 pipeline 全託管:

• AutoRAG 是什麼——現稱 AI Search 的全託管 RAG 服務,把自建 RAG 那條長 pipeline 收斂成「R2 進、API 出」;文件丟進 R2,解析、分塊、產 embedding、建索引、自動更新全由 Cloudflare 處理。
• 怎麼用——透過 env.AI 存取(不需 Vectorize binding);aiSearch() 一行從問題直接拿生成好的答案,search() 只做語意搜尋回傳相關片段;兩者都支援 score_threshold 過濾與 streaming。
• 關鍵選型與坑——「全託管」不等於「零調校」(門檻、系統提示仍要你決定);更新是非同步有延遲的;「beta 免費」只是服務層,底層照計費;客製需求超出邊界時,回頭自建 RAG。

到這裡,我們的 Vectorize / RAG 系列就完整收尾了:從《Vectorize 向量資料庫入門》認識向量搜尋、《RAG 架構實作》親手打造知識庫問答,到這一篇用 AutoRAG 享受全託管的省事——你已經掌握了在 Cloudflare 上做語意搜尋與 AI 問答的完整光譜,從「全手動、全控制」到「全託管、零維護」都能自如選型。

想深入 AutoRAG 的完整設定與 API 細節,可以參考 Cloudflare AI Search(AutoRAG)官方文件(方法名稱與參數以官方文件為準)。

聊完了「知識」怎麼餵給 AI,接下來我們要進入更進階的主題:如何讓 AI 不只是回答,而是能自主行動、記住狀態、跨步驟執行任務。下一篇《Agents SDK 入門》,我們就來認識 Cloudflare 的 AI Agent 框架,看看如何在 Workers 上打造真正「會做事」的 AI 代理人。我們下一篇見。