Prompting vs RAG vs Fine-Tuning：如何為 LLM 注入知識？

一個關鍵問題：如何讓 LLM 知道它不知道的事？

當你想讓 LLM 回答關於你公司產品、內部文檔或最新資訊的問題時，你有三個選擇：

1. Prompt Engineering（提示工程）：在 prompt 中直接提供資訊
2. RAG（檢索增強生成）：從知識庫動態檢索相關資訊
3. Fine-tuning（微調）：直接訓練模型學習新知識

但該如何選擇？Gao+ (2023) 的研究提供了一個清晰的框架來理解這三種方法的權衡。

本文將深入解析：

• 三種方法的核心差異
• 外部知識需求 vs 模型調整需求的二維分析
• 從基礎到進階的演進路徑
• 實際場景的選擇指南

📊 理解二維座標系統

兩個關鍵維度

根據 Gao+ (2023) 的研究框架，我們可以用兩個維度來評估不同方法：

維度 1：外部知識需求（Y 軸）

高 (High)
│
│  需要大量、頻繁更新的外部知識
│  例如：最新新聞、公司資料、技術文檔
│
│
低 (Low)
   只需要通用知識或少量特定資訊
   例如：常識問答、基礎對話

維度 2：模型調整需求（X 軸）

低 (Low)                           高 (High)
    不需要改變模型行為              需要深度改變模型
    例如：偶爾查詢                  例如：領域專家、特定風格

三種方法的定位

外部知識需求 (Y)
    ↑
    │
高  │         RAG 區域
    │      (動態檢索)
    │         ▲
    │         │
    │         │
中  │    Prompt Engineering
    │    (提供上下文)
    │         │
    │         │
低  │         │
    │         ▼
    │    Fine-tuning 區域
    │    (內化知識)
    │
    └──────────────────────→
   低        中        高   模型調整需求 (X)

💡 方法 1：Prompt Engineering（提示工程）

核心概念

「在輸入中直接提供需要的資訊或指導」

最簡單的方式：
User: 告訴我關於 Django 的資訊
↓
不夠好，LLM 可能不知道最新資訊

改進方式（Prompt Engineering）：
System: 你是 Python 專家...
Context: Django 是一個高階 Python 網頁框架...
User: 根據上述資訊，Django 適合什麼場景？
↓
更好！提供了必要的上下文

演進路徑

根據圖中的演進，Prompt Engineering 有四個層次：

低複雜度 → 高複雜度

1. Standard Prompt（標準提示）
   └→ 2. Few-shot Prompt（少樣本提示）
       └→ 3. XoT Prompt (e.g., CoT, ToT)
           └→ 4. 整合到 Naive RAG

Level 1: Standard Prompt（標準提示）

最基礎的方式

# 範例：標準提示
prompt = """
請回答以下問題：
Django 是什麼？
"""

response = llm.generate(prompt)

特點：

• ✅ 最簡單
• ❌ 效果有限
• ❌ 無法處理複雜任務

Level 2: Few-shot Prompt（少樣本提示）

提供範例教導 LLM

# 範例：Few-shot 提示
prompt = """
請將問題分類為技術或非技術問題。

範例 1：
問題：Django 如何部署？
分類：技術

範例 2：
問題：你今天過得怎麼樣？
分類：非技術

範例 3：
問題：Python 的 GIL 是什麼？
分類：技術

現在請分類：
問題：React 和 Vue 有什麼區別？
分類：
"""

response = llm.generate(prompt)
# 輸出：技術

特點：

• ✅ 效果明顯提升
• ✅ 不需要訓練
• ⚠️ 受 context window 限制
• ⚠️ 每次都要傳送範例（成本高）

Level 3: XoT Prompt（進階推理提示）

XoT = X-of-Thought（各種思維鏈技術）

包含：

• CoT (Chain-of-Thought)：思維鏈
• ToT (Tree-of-Thought)：思維樹
• GoT (Graph-of-Thought)：思維圖

3.1 CoT（Chain-of-Thought）

# 範例：CoT 提示
prompt = """
問題：一個餐廳有 23 個蘋果。如果他們用了 20 個做派，
又買了 6 個，現在有多少個蘋果？

請一步一步思考：

步驟 1：
步驟 2：
步驟 3：
最終答案：
"""

response = llm.generate(prompt)

# LLM 輸出：
# 步驟 1：餐廳原本有 23 個蘋果
# 步驟 2：用了 20 個，剩下 23 - 20 = 3 個
# 步驟 3：又買了 6 個，所以 3 + 6 = 9 個
# 最終答案：9 個蘋果

3.2 ToT（Tree-of-Thought）

# 範例：ToT 提示（探索多個推理路徑）
prompt = """
問題：設計一個高流量網站架構

請探索以下三個方向：
分支 1：單體架構 + 強大伺服器
分支 2：微服務架構 + 負載均衡
分支 3：Serverless 架構

評估每個分支的優缺點，然後選擇最佳方案：
"""

特點：

• ✅ 大幅提升複雜推理能力
• ✅ 適合需要多步驟思考的任務
• ❌ Token 消耗更多
• ❌ 回應時間更長

Level 4: 整合到 Naive RAG

Prompt Engineering 的終點是 RAG 的起點

# Naive RAG = 簡單的檢索 + Prompt
def naive_rag(query):
    # 1. 檢索相關文檔
    docs = retrieve(query)
    
    # 2. 組合成 prompt
    prompt = f"""
根據以下資訊回答問題：

{docs}

問題：{query}

答案：
"""
    
    # 3. 生成答案
    return llm.generate(prompt)

這就是從 Prompt Engineering 到 RAG 的自然過渡！

Prompt Engineering 總結

關鍵洞察：

• 當你需要的「外部知識」越來越多時
• Prompt 會變得越來越長、越來越貴
• 這時候就該轉向 RAG 了！

🔍 方法 2：RAG（檢索增強生成）

核心概念

「需要什麼知識，就動態檢索什麼知識」

Prompt Engineering:
把所有可能需要的資訊都放進 Prompt（固定、昂貴）

RAG:
根據問題動態檢索相關資訊（靈活、高效）

RAG 的演進路徑

根據圖中的層次結構：

低複雜度 → 高複雜度

1. Naive RAG
   └→ 2. Advanced RAG (Index/Pre/Post-retrieval)
       └→ 3. Modular RAG

Level 1: Naive RAG

基礎的「檢索 + 生成」

class NaiveRAG:
    """最簡單的 RAG"""
    
    def answer(self, query):
        # 1. 檢索
        docs = self.retriever.retrieve(query)
        
        # 2. 組合 prompt
        prompt = f"根據：{docs}\n問題：{query}\n答案："
        
        # 3. 生成
        return self.llm.generate(prompt)

特點：

• ✅ 簡單直接
• ✅ 適合基礎場景
• ❌ 檢索品質影響大
• ❌ 無法處理複雜問題

對應到前面的文章系列：

• 這就是《RAG 系統實戰教學》中的基礎實作

Level 2: Advanced RAG

優化檢索、索引和後處理

Advanced RAG 的三個優化方向：

1. Index 優化（索引層）
   - 更好的 Chunking 策略
   - 多種索引結構（向量 + 關鍵字）
   - 層級化索引

2. Pre-retrieval 優化（檢索前）
   - Query Rewriting（查詢改寫）
   - Query Expansion（查詢擴展）
   - HyDE（假設性文檔嵌入）

3. Post-retrieval 優化（檢索後）
   - Reranking（重新排序）
   - Context Compression（壓縮）
   - 相關性過濾

實作範例：

class AdvancedRAG:
    """進階 RAG"""
    
    def answer(self, query):
        # Pre-retrieval: 查詢優化
        optimized_query = self.query_rewriter.rewrite(query)
        expanded_queries = self.query_expander.expand(optimized_query)
        
        # Retrieval: 多路檢索
        all_docs = []
        for q in expanded_queries:
            docs = self.retriever.retrieve(q, k=20)
            all_docs.extend(docs)
        
        # Post-retrieval: Reranking
        ranked_docs = self.reranker.rerank(query, all_docs, top_k=5)
        
        # Post-retrieval: Compression
        compressed_context = self.compressor.compress(ranked_docs)
        
        # Generate
        prompt = f"根據：{compressed_context}\n問題：{query}\n答案："
        return self.llm.generate(prompt)

對應到前面的文章系列：

• 《Advanced RAG 優化技術》
• 《Reranking 深度解析》

Level 3: Modular RAG

有機組合多個模組

Modular RAG 概念：
RAG 不是固定流程，而是可組合的模組系統

可能的模組：
- Query Understanding（理解查詢意圖）
- Multi-source Retrieval（多來源檢索）
- Reasoning（推理）
- Memory（記憶）
- Tool Use（工具使用）
- Self-correction（自我糾錯）

根據任務動態組合這些模組

實作範例：

class ModularRAG:
    """模組化 RAG"""
    
    def __init__(self):
        self.modules = {
            'query_understanding': QueryUnderstandingModule(),
            'retrieval': RetrievalModule(),
            'reasoning': ReasoningModule(),
            'memory': MemoryModule(),
            'generation': GenerationModule(),
            'verification': VerificationModule()
        }
    
    def answer(self, query):
        # 1. 理解查詢
        query_analysis = self.modules['query_understanding'].analyze(query)
        
        # 2. 根據查詢類型選擇策略
        if query_analysis['type'] == 'simple':
            strategy = ['retrieval', 'generation']
        elif query_analysis['type'] == 'complex':
            strategy = ['retrieval', 'reasoning', 'generation', 'verification']
        elif query_analysis['type'] == 'conversational':
            strategy = ['memory', 'retrieval', 'generation']
        
        # 3. 執行策略
        context = {}
        for module_name in strategy:
            module = self.modules[module_name]
            context = module.process(query, context)
        
        return context['answer']

對應到前面的文章系列：

• 《Multi-step RAG 完全指南》
• 《RAG 的三大類型》（Iterative/Recursive/Adaptive）

RAG 總結

關鍵洞察：

• RAG 適合外部知識需求高但模型調整需求低的場景
• 知識可以快速更新（只需更新知識庫）
• 不需要重新訓練模型

🎓 方法 3：Fine-tuning（微調）

核心概念

「直接訓練模型，將知識內化到參數中」

Prompt/RAG:
知識在「外面」，需要時查詢或提供

Fine-tuning:
知識在「裡面」，模型直接「知道」

Fine-tuning 的類型

根據圖中的分類：

Fine-tuning 的三個方向：

1. Retriever Fine-tuning（檢索器微調）
   - 訓練更好的檢索模型
   - 適應特定領域的檢索需求

2. Generator Fine-tuning（生成器微調）
   - 訓練 LLM 本身
   - 改變輸出風格、格式、行為

3. Collaborative Fine-tuning（協同微調）
   - 同時優化檢索器和生成器
   - 端到端訓練

類型 1: Retriever Fine-tuning

訓練更好的檢索模型

# 範例：訓練領域特定的檢索器

from sentence_transformers import SentenceTransformer, InputExample, losses

# 1. 準備訓練資料
train_examples = [
    InputExample(texts=["Django 部署", "如何部署 Django 應用"], label=1.0),
    InputExample(texts=["Django 部署", "Python 安裝教學"], label=0.3),
    InputExample(texts=["React hooks", "useState 使用方法"], label=0.9),
    # ... 更多標註資料
]

# 2. 載入基礎模型
model = SentenceTransformer('sentence-transformers/all-MiniLM-L6-v2')

# 3. 定義訓練目標
train_loss = losses.CosineSimilarityLoss(model)

# 4. 訓練
model.fit(
    train_objectives=[(train_dataloader, train_loss)],
    epochs=3,
    warmup_steps=100
)

# 5. 使用微調後的模型
retriever = CustomRetriever(model)

適用場景：

• ✅ 有標註的查詢-文檔配對資料
• ✅ 通用檢索器效果不佳
• ✅ 特定領域術語多

對應到前面的文章系列：

• 《Reranking 深度解析》中的「用 Reranking 回饋訓練 Retriever」

類型 2: Generator Fine-tuning

微調 LLM 本身

# 範例：微調 LLM 以符合特定風格或格式

from transformers import AutoModelForCausalLM, TrainingArguments, Trainer

# 1. 準備訓練資料（指令-回應對）
train_data = [
    {
        "instruction": "解釋 Django ORM",
        "output": "Django ORM 是一個對象關係映射器..."
    },
    {
        "instruction": "如何優化 Django 查詢",
        "output": "可以使用 select_related() 和 prefetch_related()..."
    },
    # ... 大量資料（通常需要 1000+ 筆）
]

# 2. 載入基礎模型
model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-2-7b-hf")

# 3. 設定訓練參數
training_args = TrainingArguments(
    output_dir="./django-expert-model",
    num_train_epochs=3,
    per_device_train_batch_size=4,
    learning_rate=2e-5,
)

# 4. 訓練
trainer = Trainer(
    model=model,
    args=training_args,
    train_dataset=train_dataset,
)
trainer.train()

# 5. 使用微調後的模型
fine_tuned_model = AutoModelForCausalLM.from_pretrained("./django-expert-model")

適用場景：

• ✅ 需要特定輸出格式
• ✅ 需要特定說話風格
• ✅ 需要學習特定推理模式
• ✅ 有大量高品質訓練資料

類型 3: Collaborative Fine-tuning

端到端訓練整個 RAG 系統

# 概念：同時訓練檢索器和生成器

class CollaborativeRAGTrainer:
    """協同訓練 RAG 系統"""
    
    def __init__(self, retriever, generator):
        self.retriever = retriever
        self.generator = generator
    
    def train(self, training_data):
        """
        端到端訓練
        
        訓練資料格式：
        {
            'query': '問題',
            'documents': ['文檔1', '文檔2', ...],
            'answer': '正確答案'
        }
        """
        for batch in training_data:
            # 1. 檢索
            retrieved_docs = self.retriever.retrieve(batch['query'])
            
            # 2. 生成
            generated_answer = self.generator.generate(
                batch['query'], 
                retrieved_docs
            )
            
            # 3. 計算 loss
            # - 檢索 loss：檢索到的文檔是否相關
            retrieval_loss = compute_retrieval_loss(
                retrieved_docs, 
                batch['documents']
            )
            
            # - 生成 loss：生成的答案是否正確
            generation_loss = compute_generation_loss(
                generated_answer, 
                batch['answer']
            )
            
            # - 總 loss
            total_loss = retrieval_loss + generation_loss
            
            # 4. 反向傳播（同時更新檢索器和生成器）
            total_loss.backward()
            optimizer.step()

優勢：

• ✅ 檢索器和生成器互相配合
• ✅ 端到端優化

挑戰：

• ❌ 訓練複雜度極高
• ❌ 需要大量計算資源
• ❌ 需要精心設計的訓練策略

Fine-tuning 總結

關鍵洞察：

• Fine-tuning 適合模型調整需求高的場景
• 知識被「內化」到模型參數中
• 更新知識需要重新訓練（不靈活）

🎯 三種方法的對比總結

核心差異表

圖中的「All of the above」區域

圖中右上角有個橘色區域標註「All of the above」，這表示：

最強大的系統：組合使用所有方法！

生產級 AI 系統的最佳實踐：

1. Fine-tune Generator（微調生成器）
   └→ 符合公司說話風格、輸出格式

2. Fine-tune Retriever（微調檢索器）
   └→ 適應領域術語、提升檢索準確率

3. 使用 Advanced/Modular RAG
   └→ 動態檢索最新資訊

4. 搭配 Prompt Engineering
   └→ 引導模型按特定方式思考

結果 = 最佳效果！

🎨 視覺化對比

從 Prompting 到 RAG 的過渡

場景：回答關於公司產品的問題

═══════════════════════════════════════════

階段 1：Standard Prompt
問題：我們的產品有什麼功能？
LLM：我不知道你們的產品...❌

═══════════════════════════════════════════

階段 2：Few-shot Prompt
系統：以下是一些範例...
產品 A 功能：X, Y, Z
產品 B 功能：P, Q, R

問題：我們的產品有什麼功能？
LLM：根據範例，你們的產品可能有...⚠️
（只是猜測）

═══════════════════════════════════════════

階段 3：Naive RAG
問題：我們的產品有什麼功能？
系統：[檢索產品文檔] → [找到：功能列表]
LLM：根據文檔，你們的產品有以下功能...✅

═══════════════════════════════════════════

階段 4：Advanced RAG
問題：我們的產品有什麼功能？
系統：[優化查詢] → [多路檢索] → [Rerank]
      → [壓縮] → [提供精確上下文]
LLM：[完整且準確的回答]✅✅

═══════════════════════════════════════════

階段 5：Modular RAG + Fine-tuned
問題：我們的產品有什麼功能？
系統：[理解意圖] → [檢索] → [推理] → [驗證]
LLM（微調過）：[符合公司風格的專業回答]✅✅✅

成本 vs 效果的權衡

效果
 ↑
 │                                    ● Fine-tuning
 │                                  ／   (Collaborative)
高│                              ／
 │                          ／
 │                      ● Modular RAG
 │                    ／
 │                ／
中│            ● Advanced RAG
 │          ／
 │      ／
 │  ● Naive RAG
 │／● Few-shot Prompt
低│● Standard Prompt
 └──────────────────────────────→
   低              中              高
                成本

🤔 如何選擇？決策樹

決策流程

開始
 │
 ▼
Q1: 需要經常更新的外部知識嗎？
 │
 ├─YES→ 排除 Fine-tuning（知識更新不靈活）
 │      │
 │      ▼
 │      Q2: 知識量有多大？
 │      │
 │      ├─少（< 10 篇文章）→ Few-shot Prompt ✓
 │      │
 │      └─多（> 100 篇文章）→ RAG ✓
 │                            │
 │                            ▼
 │                            Q3: 複雜度如何？
 │                            │
 │                            ├─簡單 → Naive RAG
 │                            ├─中等 → Advanced RAG
 │                            └─複雜 → Modular RAG
 │
 └─NO→ Q4: 需要改變模型行為嗎？
       │
       ├─YES→ Fine-tuning ✓
       │      │
       │      ▼
       │      Q5: 有足夠的訓練資料嗎？
       │      │
       │      ├─YES（>1000）→ 開始 Fine-tuning
       │      └─NO → 先用 Prompt/RAG 收集資料
       │
       └─NO→ Prompt Engineering ✓

📝 實際場景指南

場景 1：公司內部知識庫問答

需求：
- 員工問問題（如：「假期政策是什麼？」）
- 知識來源：公司文檔、政策手冊
- 知識經常更新

分析：
✅ 外部知識需求：高（大量文檔）
❌ 模型調整需求：低（標準問答即可）

推薦方案：RAG
- Naive RAG：快速原型
- Advanced RAG：提升準確率
- 不建議 Fine-tuning：文檔更新頻繁

場景 2：客服機器人

需求：
- 24/7 回答客戶問題
- 需要特定說話風格（禮貌、專業）
- 需要查詢產品資訊、訂單狀態

分析：
✅ 外部知識需求：中（產品目錄、訂單）
✅ 模型調整需求：高（特定風格、格式）

推薦方案：Fine-tuning + RAG
- Fine-tune Generator：學習說話風格
- 用 RAG：動態查詢產品、訂單資訊

場景 3：程式碼助手

需求：
- 根據最新的框架文檔回答問題
- 生成符合專案風格的程式碼
- 解釋複雜的程式碼邏輯

分析：
✅ 外部知識需求：高（最新文檔、專案程式碼）
✅ 模型調整需求：高（程式碼風格、命名規範）

推薦方案：全套組合
- Fine-tune Generator：學習專案程式碼風格
- Fine-tune Retriever：理解技術術語
- Modular RAG：處理複雜查詢
- Prompt Engineering：引導特定推理

場景 4：教育輔導

需求：
- 回答學生問題
- 展示解題步驟
- 根據教科書內容

分析：
✅ 外部知識需求：中（教科書內容）
⚠️ 模型調整需求：中（解題風格）

推薦方案：RAG + CoT Prompting
- RAG：檢索教科書相關章節
- CoT：引導逐步解題
- 可選 Fine-tuning：如果需要特定教學風格

場景 5：簡單閒聊機器人

需求：
- 日常對話
- 不需要特定知識

分析：
❌ 外部知識需求：低
❌ 模型調整需求：低

推薦方案：Standard Prompt
- 直接使用基礎 LLM
- 加上系統提示設定個性
- 最經濟的方案

💰 成本對比

開發成本

運行成本（每 1000 次查詢）

Standard Prompt:
- Token 消耗：少
- 成本：$1-2

Few-shot Prompt:
- Token 消耗：多（範例）
- 成本：$5-10

Naive RAG:
- 檢索成本：$0.5
- LLM 成本：$3
- 總成本：$3.5

Advanced RAG:
- 檢索成本：$1（多次）
- Reranking：$0.5
- LLM 成本：$4
- 總成本：$5.5

Fine-tuned Model:
- 自架主機：$2（攤提）
- 或 API：$2-3
- 總成本：$2-3（長期最省！）

🎯 最佳實踐

階段式演進策略

不要一開始就選最複雜的方案！

第 1 階段（第 1 週）：驗證可行性
├─ 使用：Few-shot Prompt
├─ 目標：快速原型，驗證想法
└─ 投入：1 人 × 3 天

第 2 階段（第 2-4 週）：基礎功能
├─ 使用：Naive RAG
├─ 目標：達到基本可用
└─ 投入：2 人 × 2 週

第 3 階段（第 2-3 月）：優化提升
├─ 使用：Advanced RAG
├─ 目標：提升準確率到生產級
└─ 投入：2-3 人 × 1 月

第 4 階段（第 4-6 月）：深度定製（可選）
├─ 使用：Fine-tuning + Modular RAG
├─ 目標：最佳效果、最低成本
└─ 投入：3-5 人 × 2-3 月

組合使用的模式

模式 1：RAG 為主 + Prompt 輔助

def hybrid_qa(query):
    # 判斷是否需要檢索
    if need_external_knowledge(query):
        # 使用 RAG
        docs = retrieve(query)
        prompt = f"""
你是專業助手。請根據以下資訊回答。

資訊：{docs}

問題：{query}

要求：
1. 只根據提供的資訊回答
2. 如果資訊不足，明確說明
3. 使用專業但友善的語氣

答案：
"""
    else:
        # 使用 Prompt Engineering
        prompt = f"""
你是友善的助手。

問題：{query}

答案：
"""
    
    return llm.generate(prompt)

模式 2：Fine-tuned 模型 + RAG

class ProductionQA:
    def __init__(self):
        # 使用微調過的模型（風格、格式）
        self.llm = load_finetuned_model("company-style-llm")
        # 使用 RAG 獲取知識
        self.rag = AdvancedRAG()
    
    def answer(self, query):
        # RAG 檢索知識
        context = self.rag.retrieve(query)
        
        # 微調的 LLM 生成（風格正確）
        answer = self.llm.generate(query, context)
        
        return answer

🏁 總結

核心要點

1. 理解二維座標系統

        外部知識需求
              ↑
              │
          RAG │
              │
   Prompting  │     Fine-tuning
              │
              └───────────→
                模型調整需求

2. 沒有最好的方法，只有最適合的

• Prompting：快速、靈活、低成本
• RAG：適合外部知識需求高的場景
• Fine-tuning：適合需要深度定製的場景

3. 演進路徑

Prompt → RAG → Fine-tuning + RAG
（簡單） （中等） （複雜但最強）

4. 實際生產系統往往組合使用

Fine-tuned LLM（風格、格式）
    +
Advanced RAG（動態知識）
    +
Prompt Engineering（引導推理）
    =
最佳效果

選擇檢查清單

選擇 Prompt Engineering 如果：

• ☑️ 知識量很少（<10 頁）
• ☑️ 不需要頻繁更新
• ☑️ 追求快速上線
• ☑️ 預算有限

選擇 RAG 如果：

• ☑️ 知識量大（>100 文檔）
• ☑️ 知識經常更新
• ☑️ 不需要改變模型行為
• ☑️ 追求準確性

選擇 Fine-tuning 如果：

• ☑️ 需要特定風格或格式
• ☑️ 有大量標註資料（>1000）
• ☑️ 有足夠的計算資源
• ☑️ 追求長期最佳效果

選擇組合方案如果：

• ☑️ 是生產環境
• ☑️ 追求最佳平衡
• ☑️ 資源充足

最後的建議

1. 從簡單開始

   • 不要一開始就做 Fine-tuning
   • 先用 Prompt/RAG 驗證可行性

2. 收集資料

   • 記錄使用者查詢
   • 記錄效果好壞
   • 為未來的 Fine-tuning 準備

3. 持續優化

   • Prompt → RAG → Advanced RAG → Fine-tuning
   • 每個階段都有明確的 ROI

4. 關注成本

   • 計算 Token 消耗
   • 評估訓練成本
   • 選擇性價比最高的方案

記住：最好的 AI 系統不是技術最複雜的，而是最適合業務需求的！

🔗 延伸閱讀

• 📄 Retrieval-Augmented Generation for Large Language Models: A Survey - Gao+ 2023（本文理論基礎）
• 💻 Fine-tuning vs RAG: When to Use Each
• 📚 Prompt Engineering Guide
• 🎓 Parameter-Efficient Fine-Tuning (PEFT)
• 📊 Cost Analysis: Prompting vs RAG vs Fine-tuning

🔗 相關文章系列

• 《RAG 系統實戰教學》- 如何建立基礎 RAG
• 《Advanced RAG 優化技術》- Pre/Post-retrieval 優化
• 《Reranking 深度解析》- 提升檢索準確率
• 《Multi-step RAG 完全指南》- 處理複雜問題
• 《RAG 的三大類型》- Iterative/Recursive/Adaptive