在上一篇導論中，我們提到因簡單的RAG不足以處理實務問題，且有機敏資料你希望保護，所以需要在地端建立AgenticRAG。那就會有人問: "那為什麼公司不自己Fine-Tuning一顆模型呢? "
所以今天，我們要更深入理解 RAG 與 Fine-Tuning 的比較，並且拆解 RAG 的完整系統架構。

🔍 為什麼是 RAG，而不是 Fine-tuning？

要讓大型語言模型（LLM）理解特定的資料，或是增加pre-train模型並沒有學過的知識，主要可以透過兩種方式來達成，就是Retrieval-Augmented Generation (RAG) 和 Fine-Tuning（微調），兩種方式各有定位，選擇哪種方案通常取決於專案需求、資源限制與應用場景。

🔹 RAG 的特點

定義
RAG 是一種架構，讓 LLM 能夠從 外部知識庫 中檢索資訊，再與使用者的查詢一起餵給LLM模型，進而產生更準確的答案。

優勢

• 即時性：能隨時更新知識庫，無需重新訓練。
• 事實準確性：檢索來源可追溯，降低「幻覺」。
• 資料安全：企業私有資料可控在內部，不需上傳至第三方。
• 可擴展性：方便根據場景替換或增補知識。

適用場景

• 客服聊天機器人（回答最新產品資訊）
• 財務報告生成（整合即時市場數據）
• 法律文件分析（檢索判例、法規）
• 醫療診斷輔助（使用最新研究）
• 個人化推薦、動態FAQ、自動翻譯等

挑戰

• 建立與維護向量資料庫的工程成本高
• Chunking 策略、Embedding 模型選擇、檢索門檻值等參數都需細緻調整

🔹 Fine-Tuning 的特點

定義
使用特定領域資料搭配一個base LLM再次訓練，使其行為更貼合專業需求。

優勢

• 更深的專業理解（醫療、法律、技術寫作等）
• 可調整語氣、風格與格式
• 對邊緣案例的精準適配
• 部分場景下，能以較小模型達到高效能

適用場景

• 醫療診斷助手（專注於醫學術語）
• 情感分析（辨識諷刺或複雜情緒）
• 法律文件解讀（NER、專業術語識別）
• 特定國家用詞用語（例如TaiwanLlama）

挑戰

• 計算資源昂貴
• 資料集需高品質且具備專業標註
• 更新新知識困難，需要重新訓練
• 可能削弱模型的通用能力

綜合建議

先說結論，RAG 通常是首選，因為它提供了快速迭代與較低的維護成本，RAG搞不定你再評估看看要不要用Fine-tuning(或是這案子可能挑戰太高QQ)。

Fine-tuning不是不行，只是有沒有那個必要性。雖然這個策略能針對特定領域優化模型，但它存在幾個關鍵缺點與成本挑戰：

1. 成本高昂

   • 資料需求：需要數十萬甚至數百萬筆標註資料，蒐集與清理的成本極高。
   • 計算資源：中大型模型的 Fine-tuning 通常需要 數十到數百張 GPU（A100 或 H100），連續運行數天到數週。這對大部分企業來說是一個極高的進入門檻。

2. 靈活性不足

   • Fine-tuned 模型一旦完成，若知識更新（例如法規修訂、公司政策變動），就需要重新收集資料再訓練，更新成本高。
   • 相比之下，RAG 只需更新向量資料庫中的文件，就能立即反映最新知識。

3. 維運複雜

   • 需要專門的 MLOps 團隊來管理模型版本、部署、監控與資源調度(不然你訓練要用那麼多GPU)。
   • 對比之下，RAG 架構更接近「Plug-and-Play」，可直接搭配現有大模型 API 或內部 LLM。

📌 額外補充：

現在比較少人在談的pre-train，因為大家都知道成本很高，真正能做的公司企業不多，而且做了不一定會成功。
這邊舉一個有名的例子:
2023年的5月30，知名財經公司Bloomber發佈了他們使用了使用了約 7000 億 tokens 的資料量、500 億參數模型架構，並且在 512 張 A100 GPU 的集群上訓練 53 天，總共約 130 萬 GPU 時間來建立在金融領域的大型專用模型 BloombergGPT，推估金額高達一千萬美元。這些資源投入不只是金錢成本，也包括人力／法務／資料管道維護等隱性成本。
不幸的是，GPT 4 在 3 月 14 日（早了 2 週）推出，而到 10 月時有人開始測試自訂的 BloombergGPT與 GPT 4 來解決金融題目，結果 GPT 4 在大部分的題目都擊敗了 BloombergGPT。

參考資料
RAG vs Fine-Tuning for LLMs: A Comprehensive Guide
17 real world Examples of Using RAG vs. Fine-Tuning
Failed AI Projects: The real ROI isn't on the P&L...

🏗️ RAG 架構分層

基於上面資訊，筆者還是先專注在RAG的應用，這邊就快速來認識一下一個簡單的RAG會有什麼樣的架構吧!

RAG 可以分成 兩個核心模組：

1. 資料處理與知識庫模組

這部分負責「知識的準備」：

• 文件解析（Document Parsing）：PDF、Word、HTML、API 資料流等
• 切分（Chunking）：將長文件切成可檢索的片段
• Embedding 向量化：使用模型（如 OpenAI Ada-002、BGE、MinLLM）將文本轉成向量
• 向量資料庫（Vector Store）：儲存 Embedding，支援相似度檢索（如 Chroma、Qdrant、Pinecone）

簡單說，這一層解決「如何把資料轉成 LLM 能理解並高效檢索的格式」。

2. 使用者查詢與生成模組

這部分負責「回答問題」：

1. 使用者輸入 Query
2. 檢索器（Retriever） 從向量資料庫找相關片段
3. 拼接上下文：將檢索結果與 Query 一起餵入 LLM
4. 生成器（Generator）：LLM 根據查詢 + 上下文產生回覆

以上就是RAG的關鍵組成，大家可以先記住這兩個模組。

小結

今天文章的重點為:

• Fine-Tuning 與 RAG 各有定位，但在企業應用中，RAG 更容易快速上線、維護、並使用較低的成本迭代。
• RAG 架構可以清楚分成兩層：知識層（Data Layer）+ 查詢層（Query Layer）。

下一篇（Day 3），我們會開始討論 文件解析與 Chunking 策略，我們一起實作幾個把文件變成LLM讀的懂的資訊吧!