## 1. 為什麼需要 RAG？
Large Language Model（LLM）本身具有強大的 language understanding 與 generation 能力，但它有幾個天然限制：
1. **Knowledge cutoff**
* LLM 的知識來自 training data，無法知道最新資訊。
* 例如：公司最新產品規格、內部文件、最新政策。
2. **No private knowledge**
* LLM 不知道企業內部資料。
* 例如：HR 規章、產品文件、客戶資料。
3. **Hallucination**
* 當 LLM 缺乏資訊時，可能產生看似合理但錯誤的答案。
一個直覺的想法是：
> 如果我們可以在問問題時，把相關資訊提供給 LLM，是否可以讓它回答得更準確？
這就是 RAG 的核心概念。
---
# 2. RAG 的核心概念
RAG 全名是：
> **Retrieval-Augmented Generation**
拆開來看：
* **Retrieval**
* 從外部 knowledge source 找出與問題相關的資訊。
* **Augmented**
* 將找到的資訊加入 LLM 的 context。
* **Generation**
* LLM 根據補充後的 context 產生答案。
簡單來說：
> RAG = Retrieval system + LLM
LLM 不再只依靠自己的 training knowledge，而是在回答前先查詢外部資料。
---
# 3. 沒有 RAG 的 LLM
傳統 LLM workflow：
```
User Question
|
v
LLM
|
v
Answer
```
例如：
User:
> 公司今年的 AI strategy 是什麼？
LLM 只能根據 training data 猜測。
問題：
* 它不知道你的公司資料。
* 它可能 hallucinate。
* 它無法回答 private information。
---
# 4. RAG Architecture
加入 RAG 後：
```
Knowledge Base
|
|
Retrieval System
|
User Question -------->|
|
v
Relevant Context
|
|
v
LLM
|
v
Answer
```
流程：
1. User 提出問題。
2. Retrieval system 搜尋 knowledge base。
3. 找出與問題相關的 documents。
4. 將 documents 放入 prompt。
5. LLM 根據 context 生成答案。
---
# 5. Knowledge Base 是什麼？
Knowledge Base 可以是任何外部資料來源：
例如：
* Company documents
* Product manuals
* Technical papers
* Customer database
* Internal wiki
* Code repository
例如一家航空公司：
Knowledge Base：
```
Flights database
Ticket pricing
Destination information
Hotel recommendation
Travel policy
```
User:
> 東京機票多少錢？
RAG workflow：
1. Retrieval 找出 Tokyo flight information。
2. 加入 prompt：
```
User question:
東京機票多少錢？
Relevant information:
Flight:
Taipei -> Tokyo
Price:
NT$8500
Departure:
08:30
```
3. LLM：
> 根據資料，目前台北到東京航班價格約 NT$8500。
---
# 6. Retrieval 如何找到相關資料？
早期 RAG 可以使用 keyword search：
例如：
User:
> London flight price
System:
```
Search keyword:
London
```
找到：
```
London flight document
```
再放入 prompt。
但現代 RAG 通常使用：
## Vector Search
核心概念：
將文件轉換成 embedding vector：
```
Document
|
v
Embedding Model
|
v
Vector
```
例如：
```
"Apple releases new iPhone"
|
v
[0.23, 0.91, -0.14 ...]
```
User query 也轉換成 vector：
```
"What is Apple's latest phone?"
|
v
[0.21, 0.88, -0.10 ...]
```
透過 similarity search 找最接近的資料。
常見技術：
* Cosine similarity
* Approximate nearest neighbor search
常見 Vector Database：
* FAISS
* Milvus
* Pinecone
* Chroma
---
# 7. Modern RAG Pipeline
實際 RAG system 通常包含：
## Step 1: Document Ingestion
將文件匯入：
```
PDF
Word
HTML
Database
Code
```
↓
## Step 2: Chunking
文件切成小段：
```
Large Document
|
v
Chunk 1
Chunk 2
Chunk 3
```
原因：
* LLM context window 有限制。
* 小 chunk 比較容易找到 relevant information。
↓
## Step 3: Embedding
每個 chunk 轉換成 vector：
```
Chunk
|
Embedding Model
|
Vector
```
↓
## Step 4: Indexing
存入 vector database：
```
Vector Database
Vector
Metadata
Original Text
```
↓
## Step 5: Retrieval
User query：
```
Question
|
Embedding
|
Similarity Search
|
Top-K documents
```
↓
## Step 6: Generation
組合 prompt：
```
System Prompt
Relevant Context:
(document chunks)
User Question:
(question)
Answer:
```
送給 LLM。
---
# 8. RAG 與 Fine-tuning 的差異
很多人會混淆：
> 要讓 LLM 知道企業資料，應該 Fine-tune 還是 RAG？
兩者目的不同。
| | RAG | Fine-tuning |
| ------- | ---------- | ------------- |
| 目的 | 提供新知識 | 改變模型行為 |
| 資料更新 | 容易更新 | 需要重新 training |
| 成本 | 低 | 高 |
| 適合 | 企業文件、最新資訊 | 專業能力、格式控制 |
| Example | 公司 Wiki QA | 醫療診斷模型 |
例如：
公司產品規格每天更新：
→ 使用 RAG
希望模型永遠用固定格式寫 code：
→ Fine-tuning
---
# 9. RAG 的真正價值
RAG 的重要性不只是「讓 LLM 查資料」。
它改變了 LLM 的角色：
從：
> A model that knows everything
變成：
> A reasoning engine connected to external knowledge
LLM 負責：
* Understanding question
* Reasoning
* Generating answer
Knowledge Base 負責：
* Providing accurate facts
* Maintaining latest information
因此：
> RAG 將 LLM 從一個封閉的 language model，轉變成可以連接企業資料與真實世界資訊的 AI system。
---
# 10. 小結
RAG 的核心思想非常簡單：
> **不要重新訓練 LLM，而是在 inference time 將相關資訊提供給 LLM。**
完整流程：
```
User Query
|
v
Retrieve relevant information
|
v
Augment prompt
|
v
LLM Generate Answer
```
RAG 已成為目前企業導入 Generative AI 最重要的架構之一，因為它提供了一條低成本、高彈性的方法，讓 LLM 能夠安全地使用企業自己的 knowledge。
參考資料:
Master AI Agents in 30 days: build 8 real-world projects with OpenAI Agents SDK, CrewAI, LangGraph, AutoGen and MCP., Ed Donner
