將 $0 成本的 Agentic RAG 助手升級至 Llama 4 Scout 17B MoE

如果您最近和我的 AI 助手聊過天，您可能會發現它的速度和智商都得到了極大的提升。我已經正式將 Agentic RAG 架構的核心「大腦」從笨重的 Gemma 26B 和 Llama 3 8B 模型升級到了 Cloudflare Workers AI 上全新的 Llama 4 Scout 17B MoE (混合專家) 模型。

這裡為您深度剖析這次架構升級的前因後果以及最終成果。

問題所在：「快」與「聰明」的取捨困境

在上一版的架構中，我陷入了一個令人沮喪的取捨困境：

Gemma 26B & Llama 3 70B：這些稠密（Dense）模型非常聰明。它們能毫不費力地駕馭複雜的多工具 ReAct 迴圈。但它們實在太慢了。在邊緣計算節點上，使用 Gemma 26B 產生一次回覆通常需要 ~16 秒。在即時聊天的用戶介面中，16 秒的首位元組時間（TTFB）對使用者體驗來說是災難性的。
Llama 3 8B：為了解決延遲問題，我嘗試將流量路由到一個更小的 8B 模型。它確實很快（低於2秒的延遲），但它卻遭受著嚴重的幻覺和錯誤的工具呼叫（False Positives）。例如，因為我的名字叫 "Elvis"，如果用戶問一些刁鑽的問題，這個 8B 模型有時候會完全無視它的系統設定指令（System Prompt），開始幻想並自稱是傳奇音樂人「貓王」（Elvis Presley）。

我迫切需要一個既有 8B 的極速，又具備 70B 邏輯推理能力的解決方案。

解決方案：Llama 4 Scout 17B MoE

終於，@cf/meta/llama-4-scout-17b-16e-instruct 橫空出世。

這是 Cloudflare Workers AI 原生支援的 混合專家 (MoE) 架構。與那些在每個 token 產生時都要啟動全部參數的稠密模型不同，MoE 模型會將 token 路由到特定的「專家」子網路。儘管這個模型總共有 17B 個參數（分佈在 16 個專家上），但它每次只需要啟動其中一小部分的參數。

結果是什麼？它擁有一個龐大模型才具備的邏輯推理能力，卻只消耗微型模型的算力和延遲。

架構資料流圖

下面是更新後的 RAG 資料流向：

graph TD
    User([用戶]) --> UI[Next.js 前端]
    UI --> Worker[Cloudflare Worker 後端]
    Worker --> Cache{D1 語意快取}
    Cache -- 命中 (餘弦相似度 >= 0.93) --> Return[即時返回快取答案]
    Cache -- 未命中 --> Agent[ReAct Agent 智能體迴圈]
    
    subgraph Llama 4 Scout 17B MoE
        Agent --> Router[MoE 路由器]
        Router -.-> E1[專家 1: 搜尋]
        Router -.-> E2[專家 2: 程式碼]
        Router -.-> E3[專家 3: 邏輯]
    end
    
    Agent <--> Vectorize[(Cloudflare Vectorize 向量庫)]
    Agent <--> Tools[系統工具: get_site_map 等]
    Agent --> Final[產生最終的 RAG 答案]

成果與驗證

我執行了一個詳盡的自動化測試套件 (vitest-pool-workers) 來對新架構進行基準測試。

100% 測試通過率：完美通過了所有 5 項核心邊界測試。
零幻覺 (Zero Hallucination)：當被明確問及「Android 應用」（我根本沒開發過）或「我是不是歌手」時，模型完美地基於 RAG 上下文進行了後退防守並否認了這些說法，而不是胡編亂造。
低於4秒的延遲：整個 ReAct 迴圈（包括嵌入提示詞、查詢 Vectorize、執行工具並產生最終回覆）現在穩定在 ~3.5 秒 左右。

透過充分利用 Cloudflare 的邊緣推理網路和 MoE 的效率，這個企業級的 Agentic RAG 系統完全保留在免費層內（$0 成本），同時為您提供了零卡頓的高階用戶體驗。