5. LLM & Agent – 原理解析
大語言模型（LLM）其實就是 超大型「下一個字預測器」。
你給它一段文字，它根據訓練過的統計規律，一個 token 一個 token 接下去生成，直到覺得該結束。
它「不是」什麼
| 常見誤解 | 實際 |
|---|---|
| 有真實世界知識庫可查 | 參數裡「壓縮」了訓練資料的模式，不是資料庫 |
| 會「思考」再回答 | 沒有獨立推理引擎；是條件式文字生成 |
| 永遠說實話 | 目標是產出流暢合理的續寫，不是保證正確 |
| 記得你上週說的話 | 除非你把歷史塞進上下文視窗 |
Token 與上下文視窗（Context Window）
原理
- Token：模型讀寫的最小單位（可能是字、字片段或英文子詞）
- 中文「你好」可能 2～4 個 token；英文 “hello” 常 1 個
- 上下文視窗：一次能「看見」的 token 上限（如 8K、32K、128K）
flowchart LR SYS["System Prompt"] --> CTX["上下文視窗<br>有限長度"] HIST["對話歷史"] --> CTX RAG["RAG 檢索段落"] --> CTX USER["使用者問題"] --> CTX CTX --> OUT["模型續寫輸出"]
模型越大、context 越大，本機 RAM/VRAM 需求越高
Transformer 直覺
Attention（注意力）
Transformer 問的是：當前要預測下一個 token 時，應該「多看」輸入裡的哪些位置？
- 「它」可能指向前文的「蘋果」或「公司」
- Attention 讓模型建立長距離依賴，比舊 RNN 更能處理長文
為什麼模型有「參數量」？
| 規模 | 約略意義 | 本機可行性 |
|---|---|---|
| 7B | 70 億參數，教學與 Tool 常用 | 16GB RAM 可跑（量化後） |
| 13B～70B | 更強推理與知識 | 需較大 VRAM 或雲端 |
| MoE（混合專家） | 總參數大，每次只啟用部分 | Ollama 部分模型支援 |
參數 = 模型在訓練中學到的權重；不是「記住的 Wikipedia 條目數」。
模型怎麼來的？
預訓練（Pre-training）
- 餵海量文字（網頁、書、程式碼…）
- 任務：下一個 token 預測
- 產出「基礎模型」，會續寫但未必聽話、未必安全
微調（Fine-tuning）
- 用較高品質、任務導向資料繼續訓練
- 例：指令遵循、程式碼、繁體中文加強
qwen2.5:7b-instruct的 instruct 即經過指令微調
對齊（Alignment）
- RLHF / DPO 等：讓輸出更符合人類偏好（有禮貌、少毒性、較安全）
- 解釋了為什麼商業模型常「拒絕」某些請求
flowchart LR A["預訓練<br>會寫"] --> B["微調<br>會聽指令"] B --> C["對齊<br>更像助理"] C --> D["你用的 chat 模型"]
推理參數 — 控制「隨機性」
生成時不是完全確定性；常見旋鈕：
| 參數 | 低值效果 | 高值效果 | 建議場景 |
|---|---|---|---|
| temperature | 保守、重複性高 | 創意、發散 | Tool 選擇用 0.1～0.3；寫作用 0.7～0.9 |
| top_p | 只在高機率 token 中選 | 詞彙更豐富 | 與 temperature 二擇一調即可 |
| max_tokens | 輸出短 | 輸出長 | 控制成本與截斷 |
| stop sequences | — | 遇到特定字停止 | 結構化輸出 |
模型每一步對詞彙表有機率分布；temperature 把分布「壓扁或拉尖」，再抽樣下一 token。
自訂模型設
Temperature: 0.3，就是降低胡亂發揮，讓「Next.js 助教」風格穩定。
幻覺（Hallucination）與 RAG
幻覺是模型產出流暢但錯誤的內容：假論文、假股價、假 API。它優化的是「像真的」，不是「查證過」。
RAG（Retrieval-Augmented Generation） = 生成前先檢索你的文件，把相關段落塞進 prompt。
sequenceDiagram participant U as 使用者 participant W as Open WebUI participant V as 向量庫 participant L as LLM U->>W: 問題 W->>V: 向量相似度搜尋 V-->>W: Top-K 段落 W->>L: Prompt = 系統提示 + 段落 + 問題 L-->>W: 依據段落的回答 W-->>U: 顯示（可附引用）
RAG 三步
- 切片 + Embedding：文件 → 向量
- 檢索：問題向量找最近鄰
- 增強生成：LLM 只負責「讀給它的材料」做摘要回答
限制
- 文件爛 → 答案爛（Garbage in, garbage out）
- 檢索錯段落 → 答非所問
不能取代 Tool：即時股價、寫檔仍要 API / Python
從 LLM 到 Agent — Tool Calling
純 LLM vs Agent
| 純 LLM | Agent（+ Tools） | |
|---|---|---|
| 能力 | 只產生文字 | 可觸發外部動作 |
| 例子 | 解釋什麼是 PE 比 | 真的去查 2330.TW 股價 |
| 風險 | 幻覺數字 | Tool 執行錯誤需處理 |
Function Calling 原理
- 每個 Tool 有 名稱、參數 schema、說明
- 模型輸出結構化 JSON：
{"name": "get_stock_price", "arguments": {"ticker": "2330.TW"}} - 執行環境（Open WebUI / LangChain）跑函式，結果字串塞回上下文
- 模型再組織成自然語言
Agent 運作迴圈（ReAct 模式）
flowchart TD
Q["使用者問題"] --> T["Thought 思考"]
T --> A["Action 選擇工具"]
A --> O["Observation 觀察結果"]
O --> D{"任務完成？"}
D -->|否| T
D -->|是| R["回覆使用者"]
Agent 不是「問一句答一句」，而是：
- 思考下一步要做什麼
- 行動呼叫工具（寫檔、讀檔、呼叫 Notion API）
- 觀察工具回傳結果
- 重複直到任務完成
本地 vs 雲端
| 方案 | 優點 | 缺點 |
|---|---|---|
| 本地（本講義） | 隱私、免 API 費、可客製 | 需自行管理模型與硬體 |
| 雲端 API | 能力強、免裝模型 | 按量計費、資料上傳 |
Ollama 與本機推理 — LLM 原理的落地
本機跑的是同一套數學
Ollama 不是「簡化版 ChatGPT」，而是把同款 Transformer 權重載入記憶體，在你的 CPU/GPU 上做自迴歸生成。
| 概念 | 雲端 API | Ollama 本機 |
|---|---|---|
| 模型 | 廠商伺服器上的權重 | ~/.ollama/models 裡的檔案 |
| 推理 | 他們的 GPU | 你的 RAM/VRAM |
| 隱私 | 請求上傳 | 預設不出機房 |
| 成本 | 按 token 付費 | 硬體與電費 |
量化（Quantization）直覺
- FP16 權重大 → 慢、吃記憶體
- Q4_K_M 等量化 → 權重壓縮，略損精度，大幅降 RAM
- 這就是為什麼 7B 能在筆電跑起來
Open WebUI 在架構中的位置
Open WebUI 不訓練模型；它負責：對話管理、RAG、Tool 編排、把請求轉給 Ollama API。
flowchart TB U["使用者"] --> OW["Open WebUI<br>編排層"] OW -->|HTTP API| OL["Ollama<br>推理引擎"] OL --> M["權重檔<br>qwen2.5:7b"] OW --> RAG["向量庫 RAG"] OW --> TOOL["Python Tools"]
延伸閱讀