[ai/01-3] Fine-tuning vs RAG vs Prompt Engineering：三條路怎麼選？

上一篇搞懂了 Token 跟 Embedding，這篇來聊一個你遲早會面對的問題：怎麼讓 AI 回答得更好？

先講結論

讓 LLM 表現更好有三條路，從便宜到貴排列：

Prompt Engineering — 改你問問題的方式（免費）
RAG — 給 AI 參考資料再回答（中等成本）
Fine-tuning — 用你的資料重新訓練模型（最貴）

90% 的場景，前兩條路就夠了。如果有人一上來就說要 fine-tune，你可以先問：「你試過好好寫 prompt 嗎？」

Prompt Engineering：成本最低的優化

Prompt Engineering 就是「怎麼問問題，AI 才會給你好答案」。聽起來很廢話，但這真的是最被低估的技能。

幾個馬上能用的技巧：

1. 角色設定

差：「幫我 review 這段 code」
好：「你是一位資深的 TypeScript 工程師，專精 React。請 review 以下 code，
     重點看效能和可維護性問題。」

2. 給範例（Few-shot）

「把以下文字翻譯成英文。

範例：
中文：早安
英文：Good morning

請翻譯：
中文：你好」

幾乎所有情況下，給 2-3 個範例都比不給好。這是最簡單也最有效的 prompt 技巧。

3. Chain of Thought（思考鏈）

「請一步一步思考，在給出答案之前先列出你的推理過程。」

就這一句話，就能讓複雜推理的正確率提高一截。~~我也很想一步一步思考就能加薪。~~

4. 限制條件

「只使用 ES2020 語法，不要使用 lodash，回答用 JSON 格式。」

你限制越明確，AI 亂發揮的空間就越小。

RAG：不改模型，給它參考資料

RAG（Retrieval-Augmented Generation）的概念很簡單：

傳統 LLM：
使用者問題 → LLM → 回答（只靠模型自己的「記憶」）

RAG：
使用者問題 → 搜尋知識庫 → 找到相關文件 → 問題+文件一起給 LLM → 回答

就像考試的時候可以帶小抄一樣——LLM 本來只靠自己背的東西回答，現在你讓它看著資料回答。

RAG 的典型流程：

使用者問：「我們公司的退款政策是什麼？」
系統把問題轉成 embedding
在 Vector DB 裡找語意最接近的文件段落
把原始問題 + 找到的文件一起塞進 prompt
LLM 根據文件內容回答

為什麼大多數情況 RAG 比 Fine-tuning 好用？

	RAG	Fine-tuning
成本	低（只要 Vector DB）	高（需要 GPU）
更新知識	即時（改文件就好）	慢（要重新訓練）
能追溯來源	可以（引用原文）	不行（知識融入模型裡）
幻覺控制	較好（有來源可驗證）	一般

我自己在做 ClawdBot 的時候，一開始也想說要不要 fine-tune 一下。後來發現光是好好寫 system prompt + RAG 接上 workspace 的文件，效果就已經很夠了。~~省下來的 GPU 錢可以吃好幾頓。~~

Fine-tuning：最後的手段

Fine-tuning 是在已訓練好的模型上，用你的資料繼續訓練。想像成：模型已經會說話了，你再教它你家的行話。

通用模型（GPT / Claude / LLaMA）
    ↓ 用醫療資料繼續訓練
醫療專用模型

什麼時候才真的需要 Fine-tuning？

你要改變模型的「語氣」或「風格」（例如客服機器人要用你們公司的口吻）
你有一個非常特定的任務，通用模型表現不好
你需要讓小模型在特定任務上表現接近大模型（省 API 錢）

Fine-tuning 的坑：

需要高品質的訓練資料（通常幾千到幾萬筆）
可能「忘記」原本的通用能力（catastrophic forgetting）
模型更新時要重新 fine-tune
成本不低——需要 GPU

好消息是有 LoRA / QLoRA 這種「平價版 fine-tuning」：

Full Fine-tuning: 修改全部 70B 參數 → 需要數百 GB VRAM
LoRA:             只訓練額外 ~1% 參數 → 十幾 GB 就夠
QLoRA:            LoRA + 模型量化      → 幾 GB 就能跑

LoRA 讓個人開發者也能 fine-tune 大模型，這在兩年前是不可能的事。但我的建議還是：先把 prompt engineering 和 RAG 做好，真的不夠再考慮 fine-tune。

決策流程圖

遇到「怎麼讓 AI 表現更好」的問題，按這個順序想：

1. Prompt 寫好了嗎？（有角色設定、有範例、有限制條件）
   → 沒有 → 先把 prompt 寫好
   → 有了，還是不夠好 ↓

2. 是缺乏特定知識嗎？（公司資料、最新資訊）
   → 是 → 用 RAG
   → 不是 ↓

3. 是需要改變模型行為嗎？（語氣、格式、特殊任務）
   → 是 → Fine-tuning（先試 LoRA）
   → 都試了還是不行 → 可能這個任務不適合用 LLM 解決

最後那一行很重要——不是所有問題都該用 AI 解決。有時候一個好的 if-else 比一個不穩定的 LLM 靠譜多了。

好，你現在知道怎麼讓 AI 變聰明了。但 AI 要跑在哪裡？花多少錢？

AI 部署與成本：API 還是自己架？

90% 的 AI 問題都能用好好寫 prompt 解決。剩下的 10%——你確定不是 prompt 沒寫好嗎？

Terry Yao's Blog

分類

目錄