最近幫幾個團隊看生成式 AI 的 PoC，我發現大家卡關的點很少是「模型選哪個」，更多是「知識要放哪裡、怎麼維護、出了事誰負責」。

RAG 跟微調常被拿來當二選一，但在企業情境裡，它更像兩種不同的治理策略：一種把知識寫進模型，另一種把知識留在外部系統，讓模型按需取用。

微調：把知識變成模型的習慣

微調的好處很直觀：

• 風格、語氣、專業術語能更貼近領域
• 對固定且穩定的任務，輸出一致性更好

但它也把維運成本拉高：公司規章、產品資訊、流程版本一變，模型裡那段「習慣」不會自動更新。你最後會面對一個很現實的問題：更新週期要多短、成本要多高、誰有權限決定要不要重訓。

RAG：把知識留在外面，讓模型當讀者

RAG 的價值在於把「知識更新」從模型本體移出去：

• 文件改了，更新資料庫或索引就能生效
• 回答可以附來源段落，更容易做稽核與追溯
• 更符合企業對合規與風險控管的直覺

不過 RAG 也不只是「搜尋貼上」。真正影響品質的，往往是那些工程上看似瑣碎的細節。

RAG 的輸出品質，常死在三個細節

1) Chunking：你怎麼切，模型就怎麼理解

切片太碎，模型讀到的是片段化的話；切片太長，雜訊太多，注意力被稀釋。多數團隊第一次做 RAG 會用字數硬切，結果明明資料都在，回答卻像在拼湊。

實務上更可靠的做法是用結構切：標題、段落、條列、主題轉換點，讓每個 chunk 都能自成一個語義單元。

2) Embedding：你其實是在做「相似度檢索」

向量化把文字丟進一個高維空間，檢索是在算距離。這也是為什麼 RAG 常會出現兩種狀況：

• 問得很精準，卻撈到語義接近但不相干的段落
• 關鍵詞不同，卻意外找到真正相關的資料

這不是模型「看不懂」，而是檢索階段的召回與排序策略在影響你餵給模型的上下文。

3) 取回的文字如何塞進 prompt

很多人以為找到段落就結束了，實際上「塞進去的順序、格式、標註方式」會直接影響模型能不能引用得乾淨。

• 你要讓模型知道哪些是引用資料、哪些是使用者問題
• 你要限制模型只能依據引用資料回答，還是允許補充常識
• 你要不要要求模型在回答時標註來源

這些決策比想像中更像產品設計，而不是純工程。

真正的分水嶺：有沒有回饋迴圈

更進階的 RAG 會加上「自我檢查」與「重查」：模型先判斷取回的段落是否足夠，如果不夠就回頭調整查詢再撈一次；回答輸出前，再做一次對照，避免講出與來源相衝突的內容。

做到這裡，RAG 才會從一個檢索管線，變成可控的知識工作流程。

我自己的結論：選型只是開始，維運才是成本主體

如果你的知識更新頻繁、需要可追溯、又有合規壓力，RAG 通常比較符合企業的節奏。

如果你的任務高度固定、你更在意輸出風格與一致性，微調的投資才可能划算。

更重要的是，不要把它當成一次性的模型專案。這是一套會長期在組織裡運作的知識系統：你要設計更新、設計稽核、設計失敗時的責任邊界。

原文連結：Threads 貼文

RAG #FineTuning #生成式AI #AI工程 #LLM #知識管理