<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>TRL on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/trl/</link><description>Recent content in TRL on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Sun, 16 Aug 2026 09:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/trl/feed.xml" rel="self" type="application/rss+xml"/><item><title>Hugging Face 實戰（三）：微調實戰 — Datasets、Trainer 與 LoRA/QLoRA</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/hugging-face-part3-fine-tuning-zh/</link><pubDate>Sat, 15 Aug 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/hugging-face-part3-fine-tuning-zh/</guid><description>大多數人在 prompt 調不好的時候，第一個念頭是「那我來微調吧」。 正確答案是：八成的情況下你需要的是更好的 prompt 或 RAG，微調解決的是另一類問題。 大多數人以為微調的難點在 GPU。 正確答案是：難點在資料。1,000 筆乾淨資料勝過 10 萬筆雜訊，而後者還會讓模型變笨。
前兩篇我們學會了用現成模型並把它服務化。這一篇處理「現成模型不夠好」的情況——但在寫任何訓練程式碼之前，先確認你真的需要微調。
一、決策：你真的需要微調嗎 1.1 四階梯決策樹 問題：模型輸出不符合需求 │ ▼ ┌─────────────────────────────────────────────────┐ │ 階梯 1：Prompt Engineering │ │ 成本：幾小時 改善幅度：0–40 個百分點 │ │ 先試：明確指令、輸出格式範例、思考步驟拆解 │ └──────────────┬──────────────────────────────────┘ │ 還不夠？ ▼ ┌─────────────────────────────────────────────────┐ │ 階梯 2：Few-shot（在 prompt 裡放 3–10 個範例） │ │ 成本：一天 改善幅度：5–25 個百分點 │ │ 代價：每次請求多 500–2000 input token │ └──────────────┬──────────────────────────────────┘ │ 缺的是「知識」而非「行為」？ ▼ ┌─────────────────────────────────────────────────┐ │ 階梯 3：RAG（檢索增強） │ │ 成本：1–2 週 解決：事實正確性、知識時效 │ │ 注意：RAG 解決不了「格式」與「語氣」問題 │ └──────────────┬──────────────────────────────────┘ │ 缺的是「行為模式」？ ▼ ┌─────────────────────────────────────────────────┐ │ 階梯 4：微調 │ │ 成本：2–6 週 解決：格式穩定性、領域語氣、 │ │ 延遲/成本（小模型取代大模型）│ └─────────────────────────────────────────────────┘ 1.</description></item><item><title>Hugging Face 實戰（四）：後訓練 — 從 SFT 到 DPO、ORPO 與 GRPO</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/hugging-face-part4-post-training-zh/</link><pubDate>Sun, 16 Aug 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/hugging-face-part4-post-training-zh/</guid><description>大多數人以為 post-training 就是「再做一次微調」。 正確答案是：SFT 教模型「怎麼做」，post-training 教它「哪一種做法比較好」——這是兩種完全不同的訊號。 大多數人一聽到 RLHF 就想到 PPO 與四個模型同時塞進 GPU。 正確答案是：2026 年的實務首選是 DPO 或 ORPO，複雜度只有 PPO 的三分之一，效果卻相當。
上一篇我們用 SFT 讓模型學會了任務格式。但 SFT 有一個結構性限制：它只能學「正例」。當兩個回答都符合格式、只是其中一個明顯更好時，SFT 無法表達這個偏好。這就是 post-training 要解決的問題。
一、Post-training 是什麼 1.1 訓練生命週期的三個階段 ┌─────────────────────────────────────────────────────────────────────┐ │ 階段 1：Pre-training（預訓練） │ │ 資料：10T+ tokens 的網路文本 │ │ 目標：預測下一個 token │ │ 成本：$1M – $100M+ │ │ 產物：Base Model（會續寫，但不會「回答」） │ └───────────────────────────┬─────────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 階段 2：SFT（監督微調） ← 上一篇 │ │ 資料：1K – 1M 筆「指令 → 理想回覆」 │ │ 目標：模仿參考答案（cross-entropy） │ │ 成本：$10 – $10K │ │ 產物：Instruct Model（會回答，但品質參差） │ └───────────────────────────┬─────────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 階段 3：Preference Optimization（偏好優化） ← 本篇 │ │ 資料：1K – 100K 組「同一問題的好答案 vs 壞答案」 │ │ 目標：提高好答案的相對機率、壓低壞答案 │ │ 成本：$20 – $50K │ │ 產物：Aligned Model（懂得什麼叫「更好」） │ └─────────────────────────────────────────────────────────────────────┘ 1.</description></item></channel></rss>