邊緣向量檢索：Vectorize 與邊緣 RAG 知識庫架構

做過一次 RAG 專案的人都知道，真正麻煩的從來不是「呼叫一次向量相似度查詢」，而是切片策略、嵌入更新、索引維護這些持續要做的維運工作。

Cloudflare 在這一塊分成兩層：Vectorize 負責向量資料庫本身，AI Search 則是把整條檢索流程包成託管服務。這篇把兩者的分工，以及 2026 年幾個實際會影響選型的變動講清楚。

邊緣 RAG 的門檻在 2026 年被明顯拉低，但拉低的是「上線速度」，不是「不需要理解架構」。

先分兩層：向量資料庫，跟架在它上面的檢索服務

談邊緣 RAG 之前，先把 Cloudflare 這塊拆成兩層會清楚很多。底層是 Vectorize，一個全球分散式的向量資料庫，專門存放嵌入向量並做相似度查詢。

上層是 AI Search，它的前身是 AutoRAG，定位是全託管的檢索增強生成服務，把切片、嵌入、索引更新、檢索、答案生成整條流程包起來。

換句話說，Vectorize 回答的是「向量怎麼存、怎麼查」，AI Search 回答的是「一套知識庫問答要怎麼從零上線」。兩者不是競爭關係。

Vectorize：容量在 2026 年翻倍，但它終究只是一個資料庫

Vectorize 存的是嵌入向量，可以來自 Workers AI，也可以是 OpenAI 或其他供應商產生的向量，本質上就是把「語意相近」這件事變成可查詢的資料結構。

2026 年 1 月的官方異動公告，把單一索引的容量上限從五百萬向量提高到一千萬，這對正在成長的知識庫是實際的鬆綁，原本要拆成多個索引分攤查詢的做法，現在多了一些空間。

• 它跟 R2、KV、D1 這些 Cloudflare 資料服務是同一個生態系，圖片放 R2、結構化資料放 D1、向量放 Vectorize，可以組成一條不必接外部服務的完整流程。
• 它本身不負責切片與嵌入生成，這兩件事要嘛自己寫，要嘛交給 AI Search 代勞。
• 查詢回傳的是相似度排序結果，要不要再加一層重新排序或過濾邏輯，取決於你自己的應用需求。

如果你的團隊已經有一套成熟的切片與檢索邏輯，只是想找一個低延遲、全球分散的向量儲存層，Vectorize 是可以直接切入的選項，不需要連帶接受 AI Search 的整套自動化。

AI Search：從 AutoRAG 改名之後，多了什麼

AutoRAG 在 2025 年下半年更名為 AI Search，這不是單純換個招牌，2026 年陸續加入的幾個能力，讓它從「自動建索引」進化成「更聰明的檢索」。

• 混合檢索：2026 年 4 月起，向量相似度與關鍵字比對可以在同一次查詢裡一起用，補上純語意檢索容易漏接專有名詞的弱點。
• 相關性加權：可以依時間戳記、優先級這類中繼資料欄位調整排序，官方文件提到每個實例最多支援三個加權欄位。
• 跨實例查詢：一次查詢可以同時打向多個 AI Search 實例，再合併排序結果，適合資料分散在不同知識庫的情境。
• 託管基礎設施：2026 年 6 月遷移到全託管架構後，內建儲存、內建向量索引、內建網頁爬蟲，不必自己另外準備外部依賴。

資料來源的支援也在擴大，除了原本的文件格式，陸續加入圖片、SQL、壓縮日誌檔等類型，網站爬取還多了一種會同時採集 sitemap 與爬取過程中發現連結的模式。

整合的地方也變多了

AI Search 新增了對 OpenAI 相容格式的支援，查詢介面用的是熟悉的 messages 陣列結構，既有的 OpenAI SDK 與工具鏈可以直接沿用，不必為了換一家服務重寫整套呼叫邏輯。

框架整合的部分，官方陸續補上 Cloudflare Agents SDK、Vercel AI SDK 與 LangChain 的支援，代表這套邊緣 RAG 不只是獨立服務，也能嵌進既有的代理式應用開發流程裡。

怎麼選：從一個問題開始

回到最一開始的判斷題：你要的是控制權，還是上線速度？

1. 要上線速度：直接用 AI Search，指向一個 R2 儲存桶或上傳檔案，切片、嵌入、索引更新全部交出去，先把知識庫問答跑起來。
2. 要控制切片與檢索邏輯：自己寫切片與嵌入管線，只把 Vectorize 當作向量儲存與查詢層，換取完全客製化的空間。
3. 資料量會持續成長：留意單一索引的容量上限，2026 年已經翻倍到一千萬向量，但正式評估前還是查一次官方最新數字。
4. 檢索精度要求高：優先評估混合檢索與相關性加權，純向量相似度在專有名詞與型號查詢上通常不夠用。

這塊的功能演進速度很快，建議把「查一次官方最新文件」當成上線前的固定動作，而不是憑一年前的印象做架構決策。