行動端微調 vs RAG：為什麼 RAG 仍然需要伺服器

檢索增強生成（RAG）是「如何為我的 AI 提供領域知識？」這個問題的標準答案。檢索相關文件、注入到提示詞中、讓模型帶著上下文回答。這在具有伺服器基礎設施的網頁應用上運作良好。

在行動端，RAG 有一個結構性問題。檢索步驟需要向量資料庫。那個資料庫要嘛在伺服器上（重新引入伺服器依賴），要嘛在裝置上（消耗大量儲存空間和 RAM）。對行動端來說，兩種選擇都不乾淨。

微調採用不同的方法。不是在推論時查找知識，而是在訓練期間將知識嵌入模型權重中。模型不需要檢索任何東西就知道你的領域知識。

RAG 的工作原理（以及為什麼它需要基礎設施）

標準的 RAG 流程：

1. 索引階段： 將你的文件分塊、生成嵌入向量、儲存到向量資料庫中
2. 查詢階段： 將使用者的問題轉換為嵌入向量、在向量資料庫中搜尋相似的分塊、檢索前 3-5 個結果
3. 生成階段： 將檢索到的分塊與使用者的問題一起注入提示詞中、發送給 LLM

伺服器依賴

第 2 步需要向量相似度搜尋。在伺服器端，這使用 Pinecone、Weaviate 或 pgvector 等資料庫。這些是伺服器端服務。

對於行動端，你有兩個選擇：

伺服器端 RAG： 使用者的問題發送到你的伺服器，伺服器執行檢索並呼叫 LLM API。這是最常見的架構，但意味著每個查詢都需要一次網路往返。你又回到了雲端依賴的所有問題：延遲、離線失敗、隱私問題和持續的基礎設施成本。

裝置端 RAG： 將向量資料庫儲存在手機本地。這消除了伺服器但產生了新的問題：

• 向量資料庫根據你的語料庫大小消耗 100MB-1GB+ 的額外儲存空間
• 查詢的嵌入生成需要運行一個單獨的模型（通常 50-100MB）
• 帶有向量擴展的 SQLite 是最實用的選擇，但能力有限
• 裝置端的總佔用空間（LLM + 嵌入模型 + 向量資料庫）可能超過 3-4GB
• 更新知識庫需要下載新的向量，而不僅僅是替換模型

微調的工作原理

微調在訓練期間教導模型你的領域知識：

1. 資料準備： 將你的領域知識格式化為問答對、對話或指令-回應範例
2. 訓練： 在基礎模型（1-3B 參數）上使用你的資料進行 LoRA 微調
3. 匯出： 轉換為 GGUF、量化、部署到裝置端
4. 推論： 模型從學到的知識中回答。無需檢索步驟。

模型權重檔案是唯一的產出物。沒有向量資料庫、沒有嵌入模型、沒有檢索基礎設施。

比較

何時 RAG 更好

RAG 在特定場景中有真正的優勢：

快速變化的知識庫。 如果你的內容每天都在變化（新聞、庫存、定價），微調無法跟上。RAG 檢索最新的文件。但請考慮：有多少行動 AI 功能真正需要即時的知識更新？

非常大的知識庫。 如果你的領域知識跨越數百萬份文件，微調一個 1-3B 模型無法全部吸收。RAG 檢索相關的子集。但同樣：有多少行動應用程式需要在本地搜尋數百萬份文件？

來源引用。 RAG 可以指向提供其答案依據的特定文件。微調模型無法輕易引用其來源。如果你的功能需要在答案旁邊顯示「這是來源」，RAG 有優勢。

何時微調更好

對於大多數行動 AI 使用場景，微調更勝一籌：

你的知識是穩定的。 產品文件、公司政策、領域術語、行業規則。這些每月或每季更新，而非每天。微調可以乾淨地吸收這些知識。

你的任務是特定的。 分類、摘要、關於有限領域的問答、特定風格的內容生成。這些任務受益於嵌入模型中的深度領域知識，而非文件檢索。

你需要離線支援。 微調模型在離線狀態下工作完全相同。RAG（即使是裝置端的）在離線時更慢且更複雜。

你想要簡潔。 一個檔案（GGUF 模型）對比三個元件（LLM + 嵌入模型 + 向量資料庫）。更少的複雜度意味著更少的故障點。

你關心速度。 微調推論沒有檢索步驟。首個 token 的時間是 50-200ms 對比裝置端 RAG 的 200-500ms。

混合方法

一些行動應用程式受益於混合方法：

• 微調模型 用於領域知識、風格和任務執行
• 本地搜尋（關鍵字或簡單的 SQLite FTS5）用於使用者特定的內容（筆記、訊息、文件）
• 伺服器端 RAG 作為連線時的可選增強，用於超出裝置端模型知識的任務

微調模型處理 90% 的查詢。本地搜尋處理使用者特定的內容。伺服器端 RAG 處理需要更廣泛知識的罕見邊界情況，但僅在有網路連線時可用。

實際範例

場景： 一個行動應用的客戶支援聊天機器人。

RAG 方法： 將你的 500 篇支援文章儲存在向量資料庫中。每次使用者提問時，檢索最相關的 3 篇文章，注入到提示詞中，生成回應。需要伺服器基礎設施或裝置上 500MB+ 的向量。

微調方法： 將你的 500 篇支援文章轉換為 2,000 個問答訓練範例。微調一個 3B 模型。模型學會你的產品、你的術語和你的支援風格。部署 1.7GB 的 GGUF 檔案。無需檢索。

結果： 微調模型從內化的知識中回答。回應延遲：100-200ms。儲存空間：1.7GB（僅模型）。離線：可用。基礎設施成本：部署後每月 $0。

像 Ertas 這樣的平台簡化了微調路徑：上傳你的支援文章或問答對、使用 LoRA 訓練、匯出 GGUF、部署。領域知識在模型中，而非在資料庫中。

決策

如果你的行動應用程式需要具有領域知識的 AI：

1. 知識是否穩定（每月或更少頻率更新）？微調。
2. 應用程式是否需要離線工作？微調。
3. 知識庫是否少於 10,000 份文件？微調。
4. 知識是否每天變化？考慮伺服器端 RAG 搭配微調後備方案。
5. 你是否需要來源引用？考慮針對那些特定功能使用 RAG。

對於大多數行動 AI 使用場景，微調比 RAG 更簡單、更快速、更便宜、也更可靠。