每張卡片只處理一個術語的核心概念、概念位置、可觀察訊號與判讀方式。卡片之間用相對連結互引，建立可導航的概念網路。

建卡判準

商業術語建卡的判準是該術語是否承擔判斷成本，而不是只看是否常見。讀者如果不知道這個名詞，會誤判某段分析的結論或無法解碼一張財務表，就值得建卡。

適合建卡的術語通常有三個特徵。第一，它包含結構性意涵，超出字面翻譯—例如 lock-in 背後是切換成本與生態系設計，遠不只「鎖定」二字。第二，它會影響讀者對商業策略的判讀—例如 FDE 不只是「派工程師」，而是揭露 SaaS 模式不可行的訊號。第三，它可以被獨立說明成「核心概念、位置、訊號、判讀」的四段結構。

不適合建卡的是過度寬泛的詞（「策略」「成長」「轉型」）或僅在特定文章中成立的臨時詞。這類詞應在分析文章中直接補清楚。

卡片格式

每張卡片用四段結構：

 1---
 2title: 術語中英文名
 3date: YYYY-MM-DD
 4description: 一行說明卡片責任
 5weight: 編號
 6---
 7
 8開頭段：定義核心概念，回答「這個術語是什麼」。首段須包含至少一條鄰卡連結建立網路。
 9
10## 概念位置
11
12說明這個概念在商業推理中的位置，跟其他概念的關係。應包含至少一條鄰卡連結。
13
14## 可觀察訊號與例子
15
16說明什麼時候這個概念變成判讀的重點，舉一到兩個具體情境。
17
18## 判讀方式
19
20說明遇到這個概念時要做什麼判斷，常見陷阱是什麼。

開頭段必須先給定義，不要先丟例子。可觀察訊號段必須是具體情境，不可只給名詞解釋。判讀方式段必須給可操作的判斷指引。

商業模式

公司賣什麼、賣給誰、怎麼收費。這是讀懂任何分析文章的第一層語言。

單位經濟

每個客戶或每筆交易的成本與利潤結構。判讀一家公司是否真的賺錢的核心語言。

進入市場

用什麼通路、銷售模式、組織安排把產品賣出去。

競爭護城河

為什麼客戶留下來、為什麼別人打不進來。決定一家公司能否長期擊敗對手。

市場動態

賽道處在什麼階段、競爭強度、需求類型。判讀一個產業現在能不能進、何時進。

資本估值

公司價值怎麼被定價、被誰定價、何時崩塌。

執行知識

把產品做出來、把客戶服務好的隱性能力。常被低估、卻是 AI 時代差異化的核心。

這個模組先建立共同語言。每張卡片只處理一個概念，並用「概念位置、可觀察訊號、接近真實的例子、設計責任」說明它在本地 LLM 生態中的角色。讀者可以從章節中遇到陌生詞時點進來補完，回到原章節仍能接續閱讀。

卡片分類

模型輸出機制

模型權重與量化

推論加速技巧

推論基礎建設

macOS 與 shell 基礎

讓對 Mac 操作不熟的讀者也能跟上本地 LLM 章節。這組卡片不算 LLM 領域知識、但本地 LLM 章節必然會碰到。

硬體與架構

線性代數基礎

LLM 機率與資訊論

LLM 訓練流程

Reasoning Models

Vision / 多模態

Deployment / 靜態場景

Coding Agent 工程

Production / Observability

Retrieval 進階

Constrained / Structured Output

安全 / 合規

Tokenization

Sampling 策略

推論加速進階

評估指標 / Benchmark

應用層模式

Prompt 技術

設計典範 / 人機協作

模型行為與安全

Production 推論

卡片寫法

每張卡片維持四段：

1. 核心概念：用一句話說明這個術語承擔什麼責任。
2. 概念位置：說明它在本地 LLM 三層架構（介面 / 伺服器 / 模型）的哪一層、跟其他概念的關係。
3. 可觀察訊號與例子：用真實使用情境說明這個概念何時會出現、會以什麼形式被讀者察覺。
4. 設計責任：使用者或工程師遇到這個概念時要做哪些判斷或設定。

卡片之間互相連結，章節文章使用術語時優先連到卡片。卡片是概念索引，章節文章負責情境推導；兩者分工讓讀者可以快速查詢術語，也能完整跟著章節思考。

卡片與章節的關係

模組零的概念文章（本地 vs 雲端、為什麼 LLM 生字慢、三層架構 等）會引用大量卡片術語；模組一的實作文章（Ollama 安裝、模型選型 等）也會用到同一批詞彙。卡片讓兩個模組共用詞彙、避免各自重新定義。

這個模組先建立共同語言。每張卡片只處理一個知識節點，並用「概念位置、可觀察訊號、接近真實網路服務的例子、設計責任」說明它在後端系統中的角色。

術語建卡判準

知識卡片的建卡判準是術語是否承擔理解成本與判斷成本，核心重點在它如何影響服務理解，而非只看它是否已經在多篇文章重複出現。讀者如果缺少某個名詞的服務語意，就會難以理解服務路徑、風險邊界、artifact 欄位或下一步決策，這個名詞就值得建卡。

適合建卡的術語通常有三個特徵：第一，它超過單純字面翻譯，並包含服務責任、操作條件或失敗代價；第二，讀者若缺少它就難以理解服務路徑、風險邊界或下一步決策，例如 validation query、rollback window、fallback read；第三，它可以被獨立說明成「概念位置、可觀察訊號、例子、設計責任」。出現頻率與是否影響實作判斷都可以當補充訊號，但不參與「是否要建卡」的必要判準。

不適合建卡的是過度寬泛、沒有明確服務責任的詞。若名詞只是文章中的普通形容詞、單一欄位值、或只能在該句子內成立，優先在正文補清楚，不硬拆成卡片。

資料與一致性

快取與流量

入口與部署

通訊協定

邊界與治理

訊息與事件

遷移與資料同步

可觀測性與可靠性

效能工程與容量規劃

事故處理與復盤

資安與資料保護

使用方式

知識卡片是章節引用單位。選型文章遇到術語時，應連到對應卡片；服務實體章節需要更深入時，再從卡片延伸到具體工具操作。

卡片先回答概念本質，再放例子與提醒。這個順序讓讀者先知道該概念在系統裡承擔什麼責任，再理解 RabbitMQ、Redis、Kubernetes 或 observability 平台中的具體名稱。

Hyprland（v0.55+ 的配置格式）、Neovim（整個 plugin 和配置生態）、WezTerm（terminal emulator 配置）都用 Lua 作為配置語言。在 dotfile 管理的脈絡裡，Lua 是讀懂和寫好這些工具配置的前提知識。

配置檔用到的核心語法

變數和型別

1local name = "hello"       -- 字串
2local count = 42            -- 數字
3local enabled = true        -- 布林
4local nothing = nil         -- 空值（類似其他語言的 null）

local 宣告區域變數。沒有 local 的變數是全域的，配置檔裡幾乎都該用 local。

Table：唯一的複合資料結構

Lua 只有一種複合型別——table，同時當 array 和 dictionary 用：

 1-- 當 array（index 從 1 開始，不是 0）
 2local fruits = { "apple", "banana", "cherry" }
 3print(fruits[1])  -- "apple"
 4
 5-- 當 dictionary
 6local config = {
 7    gaps_in = 5,
 8    border_size = 2,
 9    layout = "dwindle",
10}
11print(config.gaps_in)  -- 5
12
13-- 巢狀 table（配置檔最常見的形式）
14local decoration = {
15    rounding = 8,
16    blur = {
17        enabled = true,
18        size = 5,
19        passes = 2,
20    },
21}

Hyprland 的 hl.config() 接收的就是一個巢狀 table：

1hl.config({
2    general = {
3        gaps_in = 5,
4        gaps_out = 10,
5    },
6    decoration = {
7        rounding = 8,
8    },
9})

Function

1local function greet(who)
2    return "hello " .. who   -- .. 是字串串接
3end
4
5-- 匿名 function（Neovim 配置常見）
6vim.keymap.set("n", "<leader>f", function()
7    require("telescope.builtin").find_files()
8end)

條件判斷

1if hostname == "work-laptop" then
2    -- 工作機設定
3elseif hostname == "home-desktop" then
4    -- 家裡桌機設定
5else
6    -- 預設
7end

只有 nil 和 false 是 falsy。0 和 "" 是 truthy（跟 Python 不同）。

迴圈

 1-- 數字 for（Hyprland 批次產生 workspace keybind）
 2for i = 1, 9 do
 3    hl.bind("SUPER", tostring(i), "workspace", tostring(i))
 4end
 5
 6-- 遍歷 table
 7local tools = { "zsh", "git", "nvim", "tmux" }
 8for _, tool in ipairs(tools) do
 9    print(tool)
10end

模組化（require）

1-- hyprland.lua 裡載入同目錄的其他 .lua 檔
2require("keybinds")     -- 載入 keybinds.lua
3require("rules")        -- 載入 rules.lua
4require("appearance")   -- 載入 appearance.lua

require() 是 Lua 原生的模組載入，取代了舊 Hyprland .conf 格式的 source = ... 指令。

為什麼配置工具選 Lua

Lua 被嵌入到配置層的原因是一組特定的 trade-off：

• 比 JSON/TOML/YAML 強：有變數、迴圈、條件判斷。配置檔可以用 for 產生重複項目、用 if 處理機器差異，不需要外部 template engine
• 比 Python/JavaScript 輕：300KB 的直譯器可以嵌入 C/C++ 程式，不需要拖一個完整的 runtime
• 沙盒化容易：宿主程式可以控制 Lua 能存取哪些 API，限制配置檔的能力範圍

這也是 Neovim 從 VimScript 遷移到 Lua 的理由——plugin 生態需要一個真正的程式語言（有資料結構、有錯誤處理），但又不能讓配置檔變成一個安全隱患。

其他使用 Lua 的場景

共同模式：一個用 C/C++ 寫的高效能核心，把 Lua 嵌入進去當配置和擴展語言。

跟 Python/JavaScript 的差異速查

寫 Hyprland 或 Neovim 配置用到的 Lua 知識量很小——主要是 table（配置結構）、for loop（批次 keybind）、if-else（機器差異）、require（模組拆分）。不需要學 metatable、coroutine、metatmethod 這些進階功能。

IaC 工具分兩條路線：宣告式 DSL（Terraform / OpenTofu，用 HCL 描述資源）與程式語言（AWS CDK / Pulumi，用 TypeScript / Python / Go 生成資源）。兩者都能達成「用程式碼描述、由工具收斂」的目標，差別在閱讀門檻與抽象能力。

概念位置

IaC 是 infra 系列的根概念，貫穿所有模組。成熟度階梯的第二階（宣告式 IaC）是 IaC 正式生效的起點，第三階（環境分離）和第四階（PR 流程治理）都建立在 IaC 之上。沒有 IaC，後續所有模組的能力都無法落地。

可觀察訊號

需要 IaC 的訊號是規模與協作的函數：環境數量超過一套、多人同時改資源、環境事故頻率上升、外部稽核要求變更紀錄。詳見模組負一：該開始導入 IaC 的訊號。

設計責任

採用 IaC 時要決定的核心問題：

• 工具選型：宣告式 DSL vs 程式語言，取捨在審查透明度 vs 抽象複用能力
• State 的存放：remote backend 的選擇與保護
• Console 唯讀紀律：所有寫入操作回到程式碼，Console 只作觀察
• 納管範圍：哪些資源先進 IaC、哪些暫時留在手動

鄰卡

• State — IaC 工具追蹤現實的記憶機制
• Drift — state 與現實不一致時的狀態
• 環境分離 — 同一份 IaC 描述套用到多環境

概念位置

SaaS 是商業模式的一種分類，相對於買斷型軟體（perpetual license）與託管型服務（managed service）。SaaS 之所以能擴張，是因為傳統 SaaS 的 邊際成本 接近零、客戶 留存 高、可走 PLG 自助上手。

可觀察訊號與例子

判斷一家軟體公司是不是 SaaS，看三個訊號：客戶按時間訂閱付費、產品部署在雲端讓客戶用瀏覽器或 API 連線、新客戶上線的邊際成本接近零。三者全成立就是經典 SaaS。Adobe 從買斷型 Photoshop 改成 Creative Cloud 訂閱，是傳統軟體業者轉 SaaS 的代表案例。

判讀方式

讀到一家公司號稱是 SaaS 但 毛利 只有 40%、需要派業務逐單推銷時，要懷疑它是不是真 SaaS，可能更接近顧問服務或重整合的客製軟體。AI 時代許多新創號稱 SaaS 但因為要燒 GPU 算力，COGS 被推高，毛利反而接近傳統軟體業—這是這波 AI 商業化的結構性議題，直接影響 估值。

概念位置

Adaptive retrieval 位在 RAG 的控制流端。它跟 query rewriting 不同：rewriting 假設要 retrieve，只改查詢形狀；adaptive retrieval 先決定 retrieve 是否必要。

可觀察訊號與例子

「2+2 等於多少」不需要 retrieve；「公司退款政策第 4 條怎麼說」需要 retrieve。若使用者 query 一半是聊天、一半是 factual lookup，adaptive retrieval 可以明顯降低 retrieval cost。

設計責任

判斷器可以是規則、小模型、主模型 self-report 或 confidence signal。風險是模型過度自信而跳過檢索；高風險事實問答應偏向 retrieve 或提供 fallback。

概念位置

它是 multi-agent system 的一種拓樸，也可透過 MCP 暴露成 tool server。它跟 subagent 的差異是：subagent 常是同一 runtime 內的任務分派，agent-as-tool 強調對外介面與重用邊界。

可觀察訊號與例子

主 agent 呼叫 run_security_review()，背後其實是一個安全 reviewer agent 讀檔、查規則、輸出 findings。主 agent 不需要知道內部步驟，只需要 consume 結果。

設計責任

Agent-as-tool 要把輸入、輸出、權限、副作用與 timeout 定清楚。否則呼叫方會把它當 deterministic tool，但內部其實是 fuzzy agent，失敗模式會被隱藏。

概念位置

BNF 是 grammar 的一種表示法，特別適合描述 context-free grammar。規則左邊是非終結符，右邊是它可以展開成的符號組合；終結符是實際會出現在字串中的 token，非終結符是中間抽象節點。

1<expr> ::= <term> | <expr> "+" <term>
2<term> ::= <number> | "(" <expr> ")"

這段規則表示 expression 可以是 term，也可以是 expression 加 term；term 可以是 number，也可以是括號包住的 expression。

可觀察訊號與例子

看到 ::=、<name>、多個展開選項，就是 BNF 或 BNF-like grammar。LLM structured output 文章裡提到 BNF，通常是在說「把合法輸出格式寫成形式語法，推論時用它限制生成」。llama.cpp 的 GBNF、部分 grammar engine 與 parser 文件都會使用類似記法。

BNF 的限制是它描述語法，不描述語意。它能表示「括號必須成對」「欄位順序合法」，但不能直接表示「日期必須晚於今天」「使用者必須有權限讀這筆資料」這類外部約束。

設計責任

BNF 適合拿來讀懂 grammar-constrained sampling 的規則形狀。實作時要確認你使用的引擎支援的是標準 BNF、EBNF、GBNF，還是自家 dialect；不同 dialect 的 optional、repeat、token escaping 寫法會不同。下一步路由是 Grammar 與 Lark Grammar。

概念位置

能力光譜是評估與選型用語，用來替代 binary checklist。它把能力拆成範圍、穩定性、成本與失敗模式：模型能做什麼、在多寬的分佈上穩定、錯的時候怎麼錯、需要多少 prompt / validator / retry 才可用。

1宣稱支援 → happy path 可用
2基礎可用 → 常見變體可用
3生產可用 → edge cases、錯誤路徑、壓力情境仍可控

可觀察訊號與例子

Function calling 的能力光譜可以用幾個訊號量化：單工具成功率、多工具選擇成功率、schema 合法率、參數語意正確率、錯誤時是否追問。某模型能輸出合法 JSON，不代表它能選對工具；能選對工具，也不代表它能填對 nested argument。

能力光譜的常見陷阱是把 demo 成功當成生產穩定。Demo 通常測 happy path，生產會遇到拼字錯、缺欄位、權限不足、工具 timeout、prompt injection、schema 演化與多語言輸入；這些才決定能力落在哪個位置。

設計責任

做模型選型或應用設計時，把「有沒有」改成「到什麼程度可用」。判準要包含成功率、覆蓋範圍、錯誤成本、監控訊號與回退路徑。下一步路由是：能力來自訓練資料時讀 Training Example Coverage；能力需要推論階段兜底時讀 Sampling Constraint。

概念位置

Context drift 是 agent loop 的長程失敗模式，跟 goal drift 不同：goal drift 是把子目標當終點，context drift 是上下文重心逐步偏移。

可觀察訊號與例子

任務原本是修 bug，十步後變成重構模組，再十步後變成重寫整個檔案，就是 context drift。常見訊號是 agent 開始引用近期工具輸出當主目標，卻不再回看最初 acceptance criteria。

設計責任

緩解方式是定期重錨原始目標、保留 checklist、設 checkpoint、讓外部 evaluator 比對目前行動與原始任務距離。漂移持續發生時，縮短 loop、改用 single-call pipeline，或提高 human review 頻率。

概念位置

Context packing 位在 top-k retrieval 結果與 LLM prompt 之間。它跟 retrieval source 相鄰，因為來源 metadata 會影響引用；也跟 lost-in-the-middle 相鄰，因為 chunk 順序會影響模型注意力。

可觀察訊號與例子

常見 packing 決策包含 dedup 重複 chunk、把最相關內容放前後、按 document order 保留段落流、摘要或壓縮過長 chunks、在每段前加 source path 與 score。這些決策會改變答案品質、token cost 與可追溯性。

設計責任

設計 context packing 時要回答：哪些 chunk 真的要進 prompt、順序如何安排、是否保留來源、是否需要 summarization / compression。高追溯場景優先保留 source metadata；長 context 場景要避免把重要 chunk 放在中間；latency 敏感場景要限制 top-k 與 compression call。

概念位置

四維對照：

典型 LLM 應用的混合：

1User input
2   ↓ Fuzzy（LLM 理解意圖）
3   ↓ Deterministic（DB / API / policy）
4   ↓ Fuzzy（LLM 寫回應）
5   ↓ Deterministic（發送 / 寫入）

設計責任

讀 LLM 應用設計文章或開始設計 production AI 系統時、這個 framing 決定每個 step 的工具選擇。實作判讀：

1. 哪段該 deterministic / 哪段該 fuzzy：規則可窮舉、失敗代價高、需要解釋、需要 byte-exact 重現的 → deterministic；自由文字輸入、生成有風格的輸出、邊界模糊的 → fuzzy。
2. 典範用錯的反模式：deterministic 需求硬用 fuzzy（用 LLM 算稅金）、fuzzy 需求硬用 deterministic（regex 解析自由文字）、邊界混（prompt 內塞算術 / code 內塞意圖分類）。
3. Fuzzy 邊界的四種 guardrail：schema validation、output validator、action gating、distribution monitoring。混用、不同 risk class 分擔不同層。
4. 跟 HITL 的關係：HITL 是 deterministic guardrail 的一種——把人類判斷當 deterministic check 包 fuzzy LLM 行為。
5. 失敗的歸因分層：壞掉時要問「是 prompt / model / context / tool / 還是 deterministic glue 的 bug」。deterministic 軟體歸因單一、fuzzy 軟體要分這幾層查。

完整典範討論見 0.8 Deterministic vs Fuzzy Engineering。

概念位置

在 LLM 應用裡，DSL 常出現在自然語言與程式執行之間。模型把使用者意圖轉成 DSL，應用再 parse、validate、authorize、execute；這比直接讓模型輸出任意程式碼更容易控管，也比純自然語言更容易自動化。

1使用者：「找出高優先、尚未處理的 billing ticket」
2  ↓
3LLM 輸出 DSL：ticket.where(category="billing", priority="high", status!="done")
4  ↓
5parser / validator / executor

可觀察訊號與例子

看到「特定 query language」「workflow mini-language」「policy expression」「filter expression」「tool command language」就是 DSL 候選。例子包括搜尋篩選語法、監控告警規則、資料轉換 pipeline、客服工單查詢、CI workflow 條件式。

DSL 的風險是語法看起來可控，但語意與權限仍然危險。模型生成的 DSL 要經過 parser 確認語法、validator 確認欄位與型別、authorization 確認可操作範圍、dry run 或 preview 確認副作用；不能因為輸出不是通用程式碼就直接執行。

設計責任

DSL 適合操作集合固定、需要高可控性、且自然語言到執行之間需要審計紀錄的場景。設計時先定義最小語法、失敗路由與不可表示狀態；需要讓 LLM 穩定產生 DSL 時，用 grammar 或 JSON Schema 約束輸出。下一步路由是 Structured Output 與 Sampling Constraint。

概念位置

Zero-shot vs few-shot 對照：

 1Zero-shot：
 2  Classify the tone as positive/negative/neutral.
 3  Review: "Fine, but I expected more."
 4  → 模型自己判斷「中性」邊界
 5
 6Few-shot：
 7  Classify the tone as positive/negative/neutral.
 8  Examples:
 9    "Exceeded my expectations" → positive
10    "OK, but I wish more features" → negative
11    "Service was adequate" → neutral
12  Review: "Fine, but I expected more."
13  → 模型按範例對齊、更傾向 negative

Few-shot 跟 fine-tune 對照：

設計責任

讀 prompt engineering 文章或寫 production prompt 看到「few-shot」「in-context examples」就是這個機制。實作判讀：

1. 適用任務有「我的標準跟模型預設不同」：分類邊界、抽取格式、tone alignment、structured output 形狀。
2. 失效在範例選不好：cherry-picked 不代表 distribution、cover 不到 edge case、範例彼此衝突。
3. 跟 chain-of-thought 可疊（few-shot CoT 是經典組合）、跟 fine-tune 是 endpoint 取捨。
4. 何時轉 fine-tune：範例多到撐爆 context window 又每天都用、才考慮。預設先 few-shot iterate。
5. Retrieval-augmented prompting：把寫死的 few-shot 換成從範例庫即時 retrieve、屬於 RAG 概念延伸。

完整 prompt 技術 landscape 見 4.0 Prompt 技術光譜。

概念位置

跟其他 eval 概念對照：

工作流：

1Day 1：定義 eval set + 初始 prompt + model
2   ↓ 跑 production 一段時間（如 2 週）
3Day 14：把當下 prompt + model freeze 成 baseline-v1
4   ↓
5新版本 prompt / model 都跟 baseline-v1 比
6   ↓ 定期（如每季）refresh
7Day 90：baseline-v2、標明 refresh 時點

設計責任

讀 eval / production AI 文章看到「frozen baseline」「baseline drift」「regression set」就是這個機制。實作判讀：

1. 為什麼必要：每次 A/B 都跟「最新版本」比、長期累積漂移完全不可見、「整體變好了沒」無從回答。Frozen baseline 是漂移的錨點。
2. 何時 freeze：production 跑穩、user 滿意度可接受時 freeze。太早 freeze 鎖到不夠好的版本、太晚 freeze 鎖不到。
3. 何時 refresh：定期（每季 / 每半年）、或當 baseline 明顯 obsolete（如 model 升級、產品大改版）。Refresh 後標明時點、舊版本仍可保留當歷史對照。
4. 跟 frozen baseline 一起的還有：regression set（failed case 永遠進、防 fix 一個壞一個）、production trace 抽樣補進 eval set（讓 eval set 不脫節）。
5. 失敗模式：baseline 跟 production 分佈差太遠（baseline 用 lab case、production 是 wild input）、跑出來分數沒參考價值。緩解：baseline 的 eval set 用 production trace 抽樣建。

完整 eval 系統設計見 4.13 Eval 設計座標系。

概念位置

Goal drift 是 agent loop 的 termination 失敗。它跟 context drift 的差異是：context drift 是上下文逐步偏移，goal drift 是完成條件被錯誤替換。

可觀察訊號與例子

原任務是「實作、測試、commit」，agent 實作完就回答「已完成」，這是 goal drift。另一個訊號是 agent 每步都在完成一個合理子任務，但沒有維護整體 checklist。

設計責任

緩解方式是把完成條件外部化：test pass、檔案存在、PR 開啟、commit hash 產生、人工批准。不要只靠模型自評完成；高風險任務要用 checklist 與 deterministic gate。

概念位置

Grammar 位在格式定義層，常被 constrained decoding 編譯成 token mask。它跟 schema 的差異在表達方式：schema 常描述資料結構與欄位限制，grammar 描述字串如何從符號規則生成；JSON Schema 適合物件欄位，grammar 適合自訂語言、查詢語法、括號結構與特定文字格式。

1grammar 規則 → parser / decoder 編譯
2  ↓
3每個生成位置算出合法 token
4  ↓
5不合法 token 被 mask 掉

可觀察訊號與例子

看到 expr: term ("+" term)*、start: object、<json> ::= ... 這類規則就是 grammar。例子是讓模型只輸出簡化查詢語言：欄位只能是 status / owner，運算子只能是 = / in，字串必須加引號；grammar 可以把非法查詢擋在生成階段。

Grammar 的邊界是語意與外部狀態。它可以限制語法合法，卻不能知道 owner = "alice" 是否真有這個使用者，也不能判斷查詢是否符合權限；這些仍要交給 validator、authorization 與業務規則。

設計責任

需要自訂輸出格式時，先判斷格式是資料結構還是小語言：物件欄位優先用 JSON Schema，小語言或查詢語法才用 grammar。下一步路由是：需要語法表示法讀 BNF 或 Lark Grammar；需要應用層自訂語言讀 DSL。

概念位置

GQA 是 multi-head attention 的推論友善變體。MHA 是每個 query head 都有自己的 K/V；MQA 是所有 query head 共用一組 K/V；GQA 則把 query head 分組，每組共用 K/V。

可觀察訊號與例子

在 model config 裡看到 num_attention_heads: 32、num_key_value_heads: 8，代表 32 個 Q head 共用 8 組 K/V head，group size 是 4。這會讓 KV cache 約縮到 MHA 的四分之一，長 context 與高併發更友善。

設計責任

選模型或估算 serving 成本時，要看 num_key_value_heads，而不是只看總參數。GQA 對本地推論特別重要，因為 context window 與併發數常被 KV cache 卡住。

概念位置

Guardrail 是一組控制層。常見形式包含 structured output、validator、allowlist、rate limit、sandbox、human approval、eval、monitoring 與 rollback。它通常包在模型輸出與下游副作用之間。

可觀察訊號與例子

客服分類可以用 enum schema 限制類別；tool use 可以用 allowlist 限制可呼叫工具；production 操作可以要求 human-in-the-loop approval；外部內容進 context 前可以標記為 untrusted，降低 prompt injection 後果。

設計責任

設計 guardrail 時先判斷失敗代價，再選控制強度。低風險任務用 schema 與 retry 即可；高副作用任務要加 permission boundary、sandbox、審查與 audit log。相關基礎見 Deterministic vs Fuzzy engineering。

概念位置

HITL 三種觸發時機：

跟其他相關概念對照：

設計責任

讀 AI 應用設計或 agent paper 看到「HITL」「human-in-the-loop」「approval flow」「appeal」就是這個機制。實作判讀：

1. 位置由 risk 跟 validator 能力決定：risk 高 + validator 弱、HITL 頻率高；risk 低 + validator 強、HITL 頻率低。
2. 三時機可組合：pre-act 擋高代價、mid-stream 處理 agent 不確定性、post-hoc 收回饋。三者各擋不同 risk class、不互斥。
3. 避免橡皮圖章化的四條件：分級不同 risk 走不同 gate、approval UI 強制 show diff、reject 有明確 fallback、approval 訊號回饋進系統。任一不滿足、HITL 退化成形式。
4. 跟 jagged frontier 的關係：frontier 外的任務該強制 HITL、不交給 user 自由心證。
5. 跟 fuzzy engineering 典範的關係：HITL 是 fuzzy 行為的 deterministic guardrail 一種、不是預設要有、看 risk 跟自動 validator 能力決定。

完整 HITL 拓樸設計見 4.5 人機協作拓樸。

概念位置

HyDE 三步：

 1User query
 2   ↓
 3[Step 1] LLM 生成 hypothetical document
 4         (可能 hallucinate、事實正確性不重要)
 5   ↓
 6[Step 2] Embed 假文件
 7   ↓
 8[Step 3] 用假文件 embedding 去 vector DB retrieve 真文件
 9   ↓
10真實 top-k chunks → 主 LLM 回答

為什麼比直接 embed query 好：假文件的 phrasing、長度、結構都更接近真文件的分佈、embedding 距離更可靠。重點是假文件當 embedding 的代理、不是當答案——hallucinate 出錯誤事實 OK、但語意 / 領域要落對。

設計責任

讀 RAG paper 或工具看到「HyDE」「hypothetical document」「query-side augmentation」就是這個機制。實作判讀：

1. 適用 phrasing 落差顯著的場景：問句 vs 陳述、口語 vs 正式、抽象 vs 技術詞彙。HyDE 原論文跨多領域都有提升、不限技術 / 學術。
2. 失效在假文件偏離主題：LLM hallucinate 到別領域、retrieve 拿到完全不相關的東西。緩解：生成多個假文件取平均 embedding、或用 query + 假文件兩個 embedding 合併 retrieve。
3. Cost：每 query 多一個 LLM call（生假文件）、latency 加 500ms-1s，屬於明顯的 retrieval cost。對 latency 敏感場景考慮 query rewriting 等較輕量的替代。
4. 跟 hybrid search 互補：HyDE 解語意 phrasing 落差、hybrid 解語意 / 字面互補、可以同時用。

完整 RAG 檢索增強技術 landscape 見 4.2 RAG 檢索增強。

概念位置

ICL 是推論時行為，不是訓練流程。Few-shot prompting 是 ICL 最常見的操作方式；SFT、LoRA、QLoRA 則是修改權重的訓練或微調方式。

可觀察訊號與例子

給模型三個分類範例後，第四個樣本就按同一標準分類，這是 ICL。把專案命名規則、輸出格式、review rubric 放進 prompt，模型在當次回合遵守，也屬於 ICL。

設計責任

ICL 適合快速迭代與少量範例；當範例多到吃滿 context window、每天重複使用且標準穩定時，再考慮 fine-tune。需要穩定輸出格式時，ICL 應搭配 structured output 或 validator。

概念位置

Instruction-tuned model 是訓練狀態，instruction following 是行為表現。模型可能經過 SFT，仍在細格式、邊界條件或多約束任務上失敗；也可能在簡單指令上表現穩定，但遇到衝突指令或長 prompt 漏掉限制。

可觀察訊號與例子

測試訊號包含：是否輸出指定 JSON、是否只回答要求的欄位、是否避免多餘解釋、是否在資料不足時說不知道、是否遵守「不要呼叫工具」或「只讀不寫」。本地小模型常在簡單問答可用，但在多條格式限制同時存在時掉分。

設計責任

評估 instruction following 時要做 coverage 測試：格式、長度、拒答、資料不足、衝突指令、跨語言指令都要看。失敗時優先用更清楚的 prompt、few-shot、structured output 或 validator 兜底；長期穩定需求才考慮 fine-tune。

概念位置

典型對照（2024-2025 觀察、會隨模型升級漂移）：

各失敗的機制各不相同：算術靠符號操作 + tokenizer 把數字切碎、計數跟 attention 機制不對盤、冷僻格式不在訓練分佈中、URL hallucination 是模型分辨不了「真實 vs 看起來合理」。Reasoning model + tool use 普及後 frontier 會移動、表的價值在 framing「不規則」、不是具體 4 個 case 當定論。

設計責任

讀 AI 應用設計文章看到「jagged frontier」「AI capability boundary」「falling asleep at the wheel」就是這個 framing。設計判讀：

1. 不要用人類直覺難易推測 AI 能力：試跑、看結果、不要預判。
2. 「全自動」是 over-trust 假設：frontier 鋸齒、總有些子任務落 frontier 外、需要人介入或 tool 補。設計時假設「有部分子任務 AI 會失敗」、不是「都會成功」。
3. 失敗在 frontier 外加 prompt iteration 通常無效：那是模型能力邊界問題、不是 prompt 問題。對應 prompt 技術光譜 的 systematic vs random error 診斷。
4. Falling asleep at the wheel：BCG 研究觀察到的人類行為——傾向不分辨任務是否在 frontier 內、對 AI 結果一律低度審查。緩解：對團隊 / user 明確標 frontier、frontier 外任務強制人類審查（HITL）、抽樣審查偵測 frontier 漂移。

完整人機協作 framing 見 4.5 人機協作拓樸。

概念位置

Lark 是 Python 生態的 parsing toolkit，Lark grammar 是它的規則語言。它比傳統 BNF 更接近實作格式，常見元素包含 rule、terminal、literal、repeat、optional、ignore whitespace 與 start rule。

1start: query
2query: FIELD OP VALUE
3FIELD: "status" | "owner"
4OP: "=" | "!="
5VALUE: ESCAPED_STRING
6%import common.ESCAPED_STRING
7%ignore " "

這段規則描述一個很小的查詢語言，只允許固定欄位、固定運算子與 quoted string。

可觀察訊號與例子

看到 start:、大寫 terminal、%import common.*、%ignore，通常就是 Lark grammar 或受它影響的格式。LLM 場景常用它描述 JSON 子集、SQL-like query、指令 DSL、分類輸出或固定格式報告。

Lark grammar 的風險是把 parser 格式誤當跨引擎標準。某些 constrained decoding 工具支援 Lark-like 語法，某些只支援 JSON Schema、regex、GBNF 或自家格式；搬規則前要確認目標 server 能不能解析同一套語法。

設計責任

Lark grammar 適合需要清楚描述自訂格式、且工具鏈支援 Lark dialect 的場景。設計時先把合法範圍縮到應用真的需要的語法，再補 validator 處理外部狀態與權限。下一步路由是 Grammar 與 DSL。

概念位置

Tensor split 位在 inference server / GPU serving 層，跟 NVLink 或 PCIe 是不同責任：互連決定卡間傳輸成本，tensor split 決定權重怎麼分布。

可觀察訊號與例子

在 llama.cpp 看到 --tensor-split 或 -ts，通常是在手動指定多卡分配比例。兩張 VRAM 不同的卡可以用不同比例，避免小卡先 OOM。

設計責任

只有多 GPU 且需要手動控制分配時才需要它。單卡消費級 PC 通常不用；多卡沒有高速互連時，分割模型可能降低速度，需用實際 benchmark 校準。

概念位置

這個決策跨越 three-layer architecture 的所有層：介面可以相同，伺服器與模型位置不同。常見組合是同一個 IDE 介面同時接本地 OpenAI 相容 API 與雲端 API，依任務切換。

可觀察訊號與例子

本地適合私有資料、離線、可控成本、低資料外流風險；雲端適合高難度 reasoning、大型 agent、多模態、需要最新旗艦能力的任務。混合策略常見於 coding：本地做補完、摘要、低風險查詢，雲端處理複雜修復與大型 agent loop。

設計責任

判斷時看五個訊號：資料敏感度、模型能力需求、延遲體感、每月成本、維運能力。當任務失敗代價高且能力要求高，雲端未必可替代人工審查；當資料敏感且任務簡單，本地模型通常更划算。完整框架見 0.6 本地 vs 雲端。

概念位置

它位在模型層與安全治理交界，跟 model card 不同：model card 提供 metadata，supply-chain trust 判斷來源、hash、量化流程、namespace 與散發路徑是否可信。

可觀察訊號與例子

官方 organization、知名量化者、verified registry、可比對 hash、清楚 license 與 model card 都提升信任；個人上傳、來源不明、檔案被替換、缺 metadata 都降低信任。GGUF、Safetensors、Ollama registry、Hugging Face Hub 都在這條鏈上。

設計責任

下載模型前確認來源；下載後記錄 SHA-256、檔案大小與版本；第三方量化要看量化者信譽與社群採用。MCP server 與 plugin 是另一條可執行程式碼供應鏈，要用更高權限標準判讀。

概念位置

跟 multi-call 對照：

三種主流拓樸：

設計責任

讀 agent framework / paper 看到「multi-agent」「orchestrator」「agent-as-tool」就是這層設計。實作判讀：

1. 「先 multi-call、不夠再 multi-agent」：multi-agent 是「特定問題的解法」、不是「更高級的設計」。判讀訊號：role 顯著差異 / 跨產品重用 / 真正平行 / 動態協作 / 團隊熟悉度——四條件全滿足才走 multi-agent。
2. Specialization gain vs orchestration overhead：拆細帶來單一責任、獨立優化、重用、平行；代價是 context 重複傳遞、latency 累積、debug 困難、責任歸屬模糊。
3. 特有失敗模式：循環依賴、責任歸屬模糊、context 重複傳遞、orchestrator 單點瓶頸、agent 互相 hallucinate。每類有對應 guardrail（call stack 監測、trace 全紀錄、shared context、deterministic dispatch rule、schema validation）。
4. 跟 MCP 的關係：MCP 的 tool primitive 視角下、agent-as-tool 可包成 MCP server 暴露、跨組織重用走這條路。

完整 multi-agent 拓樸設計見 4.8 Multi-Agent 拓樸。

概念位置

它是 RAG 與 agent loop 的交界：控制流比 vanilla RAG 複雜，但目標仍是補齊回答所需 context，而不是任意行動。

可觀察訊號與例子

多 hop 問題常需要 multi-step retrieval：先查 A 的屬性，再用該屬性查 B，最後比較。單次 retrieve 可能只抓到其中一邊，導致回答缺關鍵證據。

設計責任

Multi-step retrieval 只有在問題確實需要多 hop、latency budget 允許、且有停止條件時才划算。沒有 stop condition 時容易無限 retrieve；沒有資訊足夠性判斷時容易提高 retrieval cost 卻沒提升。

概念位置

oMLX 位在 three-layer architecture 的伺服器層。它的差異化重點通常是 Apple Silicon 最佳化、長 context prefill 成本、SSD-backed KV cache 或相關 cache 策略；它對上仍可提供 API，對下仍載入模型權重。

可觀察訊號與例子

看到文章把 oMLX 跟 Ollama、LM Studio、llama.cpp server 放在同一組比較時，討論的是 serving 路線。看到它跟 MLX / MTP 並列時，判讀重點是「框架、解碼技巧、伺服器」三者層級不同。

設計責任

評估 oMLX 時，重點是工作流是否真的受長 context 與 TTFT 影響；短 prompt 對話通常未必需要特化 serving。下一步路由是 MLX、KV Cache 與 0.4 MLX / MTP / oMLX。

概念位置

位置資訊通常在 embedding 進入 Transformer block 前或 attention 計算中注入。常見路線包含 sinusoidal positional encoding、learned positional embedding、RoPE 與 ALiBi；現代 decoder-only LLM 多使用 RoPE 或其長 context scaling 變體。

可觀察訊號與例子

讀 model architecture 看到 max_position_embeddings、RoPE base、RoPE scaling、ALiBi、YaRN、NTK-aware scaling，就是位置編碼相關設定。長 context 擴展常卡在位置編碼外推能力，而不是只把 context window 數字調大。

設計責任

評估長 context 模型時，要分清楚「宣稱 context 長度」與「位置編碼在該長度仍可靠」。超過訓練長度太多時，即使能載入，模型對遠距關係也可能退化。完整章節見 Transformer architecture。

概念位置

Query decomposition 位在 RAG 的 query 端，跟 multi-step retrieval 相鄰但不相同。Decomposition 是先拆好 N 個子 query 平行 retrieve；multi-step retrieval 是 retrieve 後讀結果，再決定下一步要查什麼。

可觀察訊號與例子

「比較 A 與 B 在安全性和成本上的差異」可以拆成「A 的安全性」「B 的安全性」「A 的成本」「B 的成本」。每個子 query 都能獨立命中文件，最後再合成比較表。

設計責任

Query decomposition 適合子問題彼此獨立的複合問題。若後一個子 query 需要前一輪結果才能產生，改用 multi-step retrieval；若拆解後子 query 過多，要回到 retrieval cost 與 latency budget 評估。

概念位置

Query expansion 位在 RAG 的 query 端增強層。它會提高 retrieval cost，因為每個變體都要 retrieve；它也常跟 hybrid search 的 RRF 合併思路相鄰，用排名融合降低單一 query 變體失誤。

可觀察訊號與例子

使用者問「python deploy」時，系統可能擴成「Python application deployment」「Docker deploy Python service」「CI/CD for Python backend」。這能增加 coverage，但也可能把不同意圖混在一起。

設計責任

Query expansion 適合短 query、歧義 query、或同一問題有多種常見說法的場景。設計時要限制變體數量，保留 original query，並用 retrieval recall 驗證是否真的提高命中率；變體太發散時應改用澄清問題或 query rewriting。

概念位置

Query rewriting 位在 RAG pipeline 的 query 端，早於 embedding、hybrid search、reranker 與 context packing。它跟 HyDE 不同：rewriting 產生更好的查詢句，HyDE 產生假設文件再拿去 embed。

可觀察訊號與例子

使用者問「API 為什麼很慢」，rewriting 可能改成「API latency bottleneck, tail latency, database query optimization」。這能讓 retrieval 更容易命中正式文件中的用詞，但會增加 retrieval cost。

設計責任

改寫要保留原始意圖，避免把「診斷原因」改成「優化方案」這類偏移。實務上要保存 original query，retrieve 後再用原始 query 檢查結果是否對題。

概念位置

Query-document gap 位在 query 端與 embedding / search 端之間。它跟 hybrid search 的字面 vs 語意互補相關，也跟 query rewriting 與 HyDE 直接相鄰：前者改寫 query，後者生成假設文件來靠近 document 分佈。

可觀察訊號與例子

使用者問「API 為什麼很慢」，文件寫的是「tail latency、database query plan、connection pool saturation」。兩者意思相關，但 phrasing、抽象層級與術語不同，embedding 可能命中弱，BM25 可能完全漏掉。

設計責任

處理 query-document gap 時先判斷落差類型：同義詞、口語 vs 正式、問句 vs 陳述、跨語言、domain jargon 或識別碼。輕量修法是 query rewriting；形態落差明顯時可用 HyDE；精確 keyword 與語意都重要時用 hybrid search；仍然 top-k 不準時再加 reranker。

概念位置

Reflection 三步：

1[Generate]    模型生成 v1
2   ↓
3[Critique]    模型（或 critic LLM）對 v1 給回饋
4   ↓
5[Refine]      模型按回饋生成 v2
6   ↓
7(可選 loop)

跟其他模式對照：

設計責任

讀 prompt engineering / agent paper 看到「reflection」「self-critique」「self-refine」「critic」就是這個機制。實作判讀：

1. 適用模型有能力辨識「自己寫的不夠好」、critique 跟 generator 不會共用同樣 blind spot。
2. 失敗在 systematic error：critique 跟 generator 是同個模型、訓練分佈中的盲點不會因為「再想一次」消失。判讀訊號：critique 每次給很像的建議、或修完還是同一類錯——換 critic 用不同 base model、或加外部驗證（test、lint、schema）取代 LLM critique。
3. 失敗在低能力模型：critic 能力不足、產不出有用建議、徒增 cost / latency。
4. 失敗在無限循環：沒有客觀停止訊號、reflection 一直跑、cost 爆掉。緩解：step cap + 外部 metric（test pass、schema valid）。
5. 失敗在過度修正：每次 reflection 都改一點、累積結果變糟（過度 fitting critic 意見）。緩解：保留 baseline、reflection 結果要跟 baseline 比、不一定採用。

Agent loop 是 reflection 的延伸特例、進階失敗模式見 4.4 Agent 架構。完整 workflow pattern 比較見 4.7 Workflow patterns。

概念位置

Residual connection 是局部結構：把 layer input 加回 output。Residual stream 是整體視角：token representation 在每層 attention、FFN、normalization 作用後沿著主通道前進。

可觀察訊號與例子

讀 Transformer 架構或 mechanistic interpretability 文章看到「write to residual stream」「read from residual stream」「logit lens」時，討論的是各層如何在同一條 hidden state 通道上累積特徵。

設計責任

一般使用者不用調 residual stream，但理解它能幫助區分 layer、block、hidden state 與 residual connection。進一步閱讀可回到 Transformer 與 Residual Connection。

概念位置

Retrieval cost 橫跨 query 端、retrieval 端、context 組裝端與控制流端。它跟 TTFT 有關，但不只是一個延遲數字：query rewriting 多一次 LLM call，query expansion 多次 retrieve，reranker 多一段 cross-encoder 計算，retrieved chunks 進 prompt 會增加 token cost。

可觀察訊號與例子

常見訊號是「accuracy 有提升，但 p95 latency 變差」「每個 query 都 retrieve，聊天問題也燒 embedding / vector DB」「multi-step retrieval 連跑三輪，答案只比 single-step 好一點」。這時問題在於收益是否大於成本，而非技術能不能做。

設計責任

判斷 retrieval cost 要把 accuracy、latency、token budget、服務費用與維運複雜度一起看。低風險聊天可用 adaptive retrieval 降低不必要檢索；高價值問答可接受 reranker 或 multi-step retrieval 的額外成本；即時補完則通常偏向 single-step、cache 或較小 top-k。

概念位置

Retrieval recall 位在 retrieval component eval 層。它跟 reranker 相鄰，因為 reranker 常用來提升 top-k 的排序品質；也跟 query-document gap 相鄰，因為 gap 太大會讓 expected doc 不進 top-k。

可觀察訊號與例子

一組 eval query 事先標出 expected chunk。若 expected chunk 出現在 top-5，記為 hit@5；一百題中 82 題命中，hit_rate@5 是 82%。若 retrieval recall 高但答案錯，問題多半在 generation 或 context packing；若 retrieval recall 低，先修 chunking、embedding、hybrid search 或 query 端增強。

設計責任

設計 retrieval recall eval 時要保存 query、expected source、top-k 結果、score 與失敗分類。不要只看 end-to-end answer correctness；否則 retrieval miss 會被 LLM hallucination、judge 偏差或 prompt 問題掩蓋。

概念位置

Retrieval source 位在 ingestion、index 與 runtime retrieval 的交界。它跟 chunking 不同：chunking 決定來源如何切片，retrieval source 決定來源本身是否可信、是否新鮮、是否有權限被查、是否能被引用。

可觀察訊號與例子

看到「從 codebase retrieve」「從歷史客服案例庫取相似案例」「從 vector DB 查 policy」「把 filesystem search 結果塞進 prompt」就是 retrieval source 問題。不同 source 的責任不同：官方 policy 文件可引用，使用者上傳文件要標記租戶與權限，網頁內容要防 prompt injection，過期 index 要能重建。

設計責任

設計 retrieval source 時要同時回答四件事：資料來源是否可信、資料是否新鮮、查詢者是否有權限、LLM 回答是否能追溯。高風險來源要保留 source metadata、ingestion timestamp、tenant boundary 與引用標籤；否則 retrieval 命中正確內容，也可能把不該看的資料送進 prompt。

概念位置

Sampling 約束屬於推論階段，不修改模型權重，也不等於模型真的理解規則。常見控制手段有 temperature、top-p / top-k、logit bias、grammar mask、JSON mode 與 constrained decoding；其中 grammar mask 是 structured output 最關鍵的一類。

1prompt → model forward pass → logits
2  ↓
3sampling constraint：調整候選 token / logit / 機率
4  ↓
5sample next token → append → 下一輪

可觀察訊號與例子

看到「低 temperature 讓答案更穩」「top-p 過濾長尾 token」「logit bias 禁止某個 token」「grammar mask 只允許合法 JSON token」就是 sampling 約束。例子是 enum 分類：如果合法答案只有 billing、technical、other，推論伺服器可以在輸出欄位值的位置只允許這幾組 token 的路徑。

Sampling 約束的風險是把模型逼到錯誤但合法的輸出。當 grammar 太窄、enum 缺少 unknown、schema 沒有容納例外狀態時，模型可能輸出看似可解析但語意不可信的值；這時要加 fallback、confidence 或人工覆核路由。

設計責任

Sampling 約束適合處理格式合法性與候選空間控制，不適合單獨承擔事實正確性。設計時先問三件事：合法 token 集合能否完整表示業務狀態、約束失敗時要 retry 還是回退、下游 validator 如何分辨「格式合法但語意可疑」。下一步路由是 Structured Output 與 Top-K / Top-P / Min-P Sampling。

概念位置

Structured output 位在推論與應用交界，常見實作包含 JSON mode、JSON Schema、grammar 約束、constrained decoding 與 logit mask。它跟 function calling 的差異在責任層：function calling 是模型訓練出的工具呼叫能力，structured output 是推論時讓輸出形狀穩定的約束。

1模型能力：知道是否該呼叫工具、該填什麼參數
2推論約束：輸出必須符合 JSON / schema / grammar
3應用消費：parser 解析、validator 檢查、dispatcher 執行

可觀察訊號與例子

看到「固定輸出 JSON」「把結果分類成 enum」「回傳符合 schema 的物件」「讓 parser 不再處理自由文字」就是 structured output 場景。例子是客服工單分類：模型輸出 {"category":"billing","priority":"high"}，後端可以直接依欄位路由，而不是從一段自然語言裡抽關鍵字。

Structured output 的成功訊號是合法率、schema 對位率與下游解析失敗率。JSON 合法率只代表文字可被 parser 讀，schema 對位率才代表欄位、型別、enum、required 都符合應用契約；兩者分開看，才能分辨是語法錯、schema 錯，還是模型語意判斷錯。

設計責任

Structured output 適合「下游要自動執行」的輸出：tool 參數、分類、抽取、workflow 狀態、查詢條件。它的邊界是語意品質：grammar 可以保證格式合法，但不能保證模型填的值正確。下一步路由是：需要理解 token mask 機制讀 Constrained Decoding；需要判斷它跟工具呼叫的分工讀 Function Calling；需要完整應用層組合讀 4.6 應用層協議。

概念位置

三層責任分工如下：

1介面層：CLI / IDE plugin / Web UI，負責接收任務與顯示結果
2伺服器層：inference server，負責載入模型、提供 API、跑推論
3模型層：權重檔與 tokenizer，負責提供可被執行的神經網路參數

它跟 OpenAI 相容 API 的關係是：API 是介面層跟伺服器層之間的標準接縫；跟 inference server 的關係是：伺服器層是三層中的中介。

可觀察訊號與例子

看到 Continue.dev、Open WebUI、aider，通常是在介面層；看到 Ollama、LM Studio server、llama.cpp server、vLLM，通常是在伺服器層；看到 GGUF、Safetensors、MLX 權重，通常是在模型層。LM Studio 這類 all-in-one 工具會跨層，但仍可拆成 UI 與 server 兩種責任。

設計責任

排錯或換工具時，先問「問題出在哪一層」。連不上 localhost 是伺服器或網路問題；回答品質差多半是模型或 prompt 問題；IDE 操作不順是介面層問題。完整推導見 0.2 三層架構。

概念位置

它是 tool use 與 agent loop 交界的失敗模式。模型可能選對工具、也成功呼叫工具，但在 observe 階段錯讀結果。

可觀察訊號與例子

git push 失敗，agent 卻開始寫 PR description；查詢回空集合，agent 卻假設資料存在；測試命令非零退出，agent 只讀到最後幾行 log 就當成功。這些都是工具結果誤判。

設計責任

工具回傳要結構化表示 status、exit code、error type、stdout/stderr 與可重試性。Agent loop 要在 error signal 出現時強制 re-read 或 retry，必要時呼叫狀態確認工具，而不是依賴模型記憶。

概念位置

它建立在 tool use、MCP 與 sandbox 之上。核心不是模型是否「想」執行，而是執行該 tool 的 process 是否有權限、是否有 allowlist、是否需要 approval。

可觀察訊號與例子

Read-only file search 可以自動；修改檔案要 checkpoint；刪除資料、push、部署、發送外部訊息通常要 step-by-step approval。第三方 MCP server 如果能讀整個 home directory，風險高於只讀 workspace 的 server。

設計責任

先把工具分成 read、local write、external side effect、irreversible operation，再配置 sandbox、allowlist、confirmation、audit log 與 rollback。高風險工具的預設應是人類批准，而不是 prompt 裡要求模型小心。

概念位置

Coverage 是訓練資料分佈的問題，常在 SFT、偏好資料、tool-use data、domain fine-tune 裡出現。它跟 prompt 範例不同：few-shot 範例只存在於當次 context，training examples 會透過訓練更新模型權重，影響模型「自然」傾向怎麼回答。

1訓練資料有覆蓋 → 模型自然輸出穩定
2訓練資料缺口大 → 靠 prompt / structured output / validator 兜底

可觀察訊號與例子

Function calling 的 coverage 可從四個面向判讀：該呼叫時是否呼叫、工具選擇是否正確、參數型別是否正確、巢狀 schema 與多工具情境是否穩定。小模型常在單一工具 + 平坦 schema 表現可用，但一進到多工具、optional field、nested object、跨語言 query 就明顯掉分，這通常是 coverage 不足而不是單純 parser 問題。

Coverage 的陷阱是只看 happy path。訓練範例如果只有成功呼叫工具，模型會傾向每次都呼叫；如果缺少「資訊不足時先追問」「使用者要求超出權限時拒絕」「工具錯誤時重試或回退」這類範例，部署後會在安全與可靠性邊界失敗。

設計責任

評估模型能力時，把支援功能改問成覆蓋範圍：支援哪些 tool schema 複雜度、哪些語言、哪些錯誤路徑、哪些反例。下一步路由是用 eval set 補齊代表性情境；如果 coverage 無法補在模型訓練層，就用 structured output、validator、retry 與 fallback 降低失敗成本。

概念位置

Unigram 是 subword tokenizer 家族的一員，常由 SentencePiece 支援。它跟 BPE 的差異在訓練與切分策略：BPE 是貪婪合併，unigram 是機率選擇與剪枝候選。

可觀察訊號與例子

讀 tokenizer 文件看到「unigram language model」「subword regularization」「SentencePiece unigram」就是這個概念。它可在訓練時對同一句話採不同合理切分，增加 tokenizer 層的資料多樣性。

設計責任

一般應用不會手動選 unigram tokenizer，但理解它能幫助比較模型的多語言支援與 token 效率。判讀時搭配 Vocabulary Size 與 Token。

概念位置

Word2Vec 屬於 LLM 前一代的 static embedding 方法，常見訓練方式是 skip-gram 與 CBOW。它跟現代 embedding model 的差異是：Word2Vec 對同一個詞給固定向量，現代 Transformer 會依上下文產生 contextual representation。

可觀察訊號與例子

經典例子是 king - man + woman ≈ queen 這類向量類比。它展示 embedding space 可以承載語意方向，但也暴露靜態詞向量對多義詞與上下文的限制。

設計責任

讀 embedding 章節看到 Word2Vec 時，把它當成「embedding 概念的歷史基線」。實務 RAG 選型通常看現代 embedding model 與 MTEB，不是直接使用 Word2Vec。

概念位置

WordPiece 屬於 subword tokenizer 家族，BERT 系列是代表。BPE 偏向合併高頻相鄰片段；WordPiece 偏向選擇能最大化語言模型 likelihood 的片段；SentencePiece 則是 tokenizer framework，可支援 BPE 或 unigram。

可觀察訊號與例子

看到 ##ing、##ed 這類 continuation marker，通常是 WordPiece 風格 vocabulary。它讓模型能處理未見過的詞，因為陌生詞仍可拆成已知 subword。

設計責任

比較 tokenizer 時，WordPiece 主要作為 BERT/encoder 系統的背景知識。寫 LLM 推論與本地 serving 時更常遇到 BPE、SentencePiece、vocab size 與 special tokens。

概念位置

Speculative decoding 一個 step 的流程：

11. Drafter 一次生 K 個候選 token（如 K=5）
22. Target model 對「prefix + 這 K 個 token」並行驗證
33. 從前往後：
4   - drafter token i 跟 target 第 i 個位置 sampling 一致 → 接受
5   - 第一個不一致 → 接受到此為止、用 target 的 token 取代第一個不一致
64. 若全 K 個都接受、target 再 sample 一個 bonus token

Acceptance rate 影響：

影響 acceptance rate 的因素

1. Drafter / target 同 family：同訓練分佈、acceptance rate 高（如 Gemma 4 31B + Gemma 4 E4B）
2. 任務難度：簡單任務（boilerplate、常見 pattern）drafter 容易猜對；困難任務（reasoning、罕見領域）acceptance rate 降
3. Sampling temperature：高 temperature 兩邊 sample 分佈都拉平、隨機性增加、acceptance rate 降；T=0（greedy）acceptance rate 最高
4. K 設太大：drafter 越往後預測、累積誤差越大、後半段 token acceptance rate 急降；K 通常設 3-5 為甜蜜點

設計責任

讀 speculative decoding 設定 / model card 看到「draft acceptance」「acceptance length」就是這指標。寫 code 場景的判讀：

1. 挑 drafter 看 family + 大小：drafter 跟 target 同 family（如 Gemma 4 31B + Gemma 4 E4B、Qwen3-30B + Qwen3-1.5B）是 acceptance rate 最高的組合
2. llama-bench 量實際加速比理論 K 倍重要：理論加速 = K × acceptance rate、實測才知道 drafter 在自己工作流的真實表現
3. 太低的 acceptance rate 是訊號：< 0.3 通常表示 drafter / target 不匹配、值得換 drafter；< 0.5 表示甜蜜點以下、可調 K 或 sampling 設定
4. MTP（Multi-Token Prediction）：把 drafter 改成 target 內建多預測 head、acceptance rate 通常更高（因為 head 跟 target 完全同分佈）

概念位置

LLM 中 activation function 主要出現在 FFN 內、夾在兩個矩陣乘法之間：

1FFN: input → W_up (linear) → activation → W_down (linear) → output
2                              ↑
3                       這裡是 activation function

主流 LLM 用的 activation function 演化：

SwiGLU / GeGLU 是「gated」變體、用兩條線性投影相乘、表達能力比單一 activation 強、是現代 LLM 主流。

設計責任

讀 paper / model card 看到 SwiGLU、ReLU、GELU 等詞、知道它們是 FFN 內部的選擇、影響模型表達能力跟訓練穩定性、不影響「模型怎麼用 / 怎麼 inference」這類使用者面議題。寫 code 場景的判讀：模型用什麼 activation 由模型作者決定、使用者通常不用調；但若要 fine-tune 或自己訓模型、activation 選擇是設計決策之一。

概念位置

模型命名中的 active parameter 線索：

模型在不同維度的影響：

事實查核註：active parameter 跟模型能力的關係是社群常見回報、不是嚴格定理；具體模型在 coding / reasoning / 對話等任務的表現依訓練資料、RLHF、prompt 風格變化、需以 SWE-bench 等公開 benchmark 跟自己工作流校準。

設計責任

理解 active parameter 後可以解釋兩個現象：為什麼 30B MoE 跟 30B Dense 在同硬體下生字速度差很多（前者每 token 只走 3B active）、為什麼 MoE 模型能力對應的「等價 Dense 大小」不是簡單線性（社群常見回報接近總參數的 60% ~ 80% 等價 Dense 能力、但 case-by-case）。

選 MoE 模型時、active parameter 是速度判讀軸、總參數是記憶體判讀軸、能力判讀靠自己工作流的 benchmark；不要直接拿「30B」跟 Dense 30B 作能力對等。

概念位置

Adam 更新規則（簡化）：

1m_t = β₁ × m_{t-1} + (1 - β₁) × g_t      ← gradient 的 EMA（一階矩、方向）
2v_t = β₂ × v_{t-1} + (1 - β₂) × g_t²     ← gradient² 的 EMA（二階矩、變動率）
3W -= lr × m_t / (sqrt(v_t) + ε)
4            └──────┬──────┘
5        每個參數獨立縮放
6        經常變動的方向減小步長、穩定方向加大

跟其他 optimizer 對比：

關鍵：AdamW 對 weight decay 跟 lr 解耦、修正了 Adam 在「lr × weight_decay」交互上的 bug、是 GPT、Llama、Gemma 等系列訓練的標配。

設計責任

讀 LLM training paper / config 看到 optimizer: AdamW、betas: [0.9, 0.95]、weight_decay: 0.1 等就是這個 optimizer 的標準設定。記憶體佔用 = 模型權重 × 3（model + m + v）、加上 backpropagation 的 activation、是訓練 vs 推論記憶體差距的主要來源。

概念位置

典型的 agent loop 流程：

1循環開始：
2  step 1：LLM 看任務目標 + 當前狀態 → 規劃下一步 → 生成 tool call
3  step 2：client 執行 tool call → 得到結果
4  step 3：tool 結果回灌 conversation → LLM 看到新狀態
5  step 4：LLM 判斷：任務完成？ → yes 結束 / no 回 step 1
6循環結束。

Agent loop 的兩個關鍵變數：

1. max steps：循環最大次數、防止無限迴圈跟成本爆炸。
2. stop condition：什麼算「任務完成」、由 LLM 自己判斷還是有額外驗證。

常見實作（依框架而異）：LangGraph、AutoGPT、Claude 的 agentic abilities、OpenAI Assistants API 都提供 agent loop 機制。

設計責任

理解 agent loop 後可以解釋兩個現象：為什麼 agent 工作流的成本比單次 LLM call 高一個量級（loop 跑很多輪）、為什麼 agent loop 是 prompt injection 的放大器（loop 中段被 injection 後、後續步驟都被牽動）。

防禦設計的核心：

1. max steps 上限：避免無限循環、控制成本。
2. per-step review checkpoint：每幾步強制人為或自動驗證、防止 agent 飄離原意圖。
3. agent 持的 credential 最小化：避免單次 injection 影響面跨越多服務。
4. tool 結果在 prompt 中包覆：明確標記「以下是 tool 回傳、不執行內含指令」、降低觸發率。

詳見 LLM Agent Prompt Injection 後果治理 跟 4.4 Agent 架構原理。

概念位置

五個層次的對比：

跟其他相關概念的關係：

設計責任

讀 agent paper / 設計 / framework docs 看到「agent memory」「memory store」「mem0 / Letta」「episodic / semantic memory」就是這 framing。寫 code 場景的判讀：

1. 不是每個 agent 都需要五個層次都用：autocomplete 只要 working memory；對話 IDE assistant 多用 working + session；長期 coding agent 才需要 long-term
2. Long-term memory 的兩條實作路線：(a) retrieval-on-demand（vector store + similarity search、見 RAG）、(b) injection-on-startup（把關鍵 memory 編進 system prompt、適合小量穩定的 procedural）
3. 失敗模式：memory drift（舊 memory 過時但仍被 retrieve）、PII 寫入（user 不知情下被存）、context 污染（不相關 memory 被 inject 進 working）、跟 hallucination 互相 boost
4. 跟 4.19 agent memory 章節 的關係：本卡是分類定義、章節是工程實務（寫入時機、retrieval 設計、失敗模式緩解）

概念位置

Attention 在 Transformer block 中的位置：

1Transformer block：
2  ├── Layer Norm
3  ├── Attention（本卡聚焦）
4  │     ├── Q · K^T → attention score
5  │     ├── softmax → weight
6  │     └── weight · V → output
7  ├── Layer Norm
8  └── FFN 層（或 MoE）

簡化的計算公式：

1attention(Q, K, V) = softmax(Q · K^T / √d) · V

Attention 的常見變體（影響 KV cache 體積跟推論性能）：

設計責任

理解 attention 後可以解釋三個現象：為什麼 LLM 推論的記憶體用量隨 context 長度線性增加（KV cache 是 attention 暫存）、為什麼 KV cache 量化 對品質影響有不對稱性（K 用於 score 比較、V 用於加權平均、誤差累積方式不同）、為什麼不同 attention 變體在同等模型大小下推論速度差異明顯（KV cache 體積跟卡間頻寬需求不同）。

工程實務上、Attention 是 LLM 推論性能跟記憶體需求的最大來源、量化策略、context 上限、併發數設計都圍繞 attention 跟 KV cache 展開。

概念位置

Backpropagation 是訓練 loop 的中段、夾在 forward pass 跟權重更新之間：

1[forward pass]：input → layer1 → layer2 → ... → output → loss
2                                                          ↓
3[backpropagation]：把 loss 對最後一層權重的偏微分算出來
4                  ←─ chain rule ─ 再往前傳播一層、算前一層的 gradient
5                  ←─ chain rule ─ ...一路傳回輸入層
6                                                          ↓
7[optimizer step]：每個權重 w 用對應的 gradient 更新

關鍵特性：

1. 計算成本 ≈ forward pass 的 2~3 倍：每個 layer 都要存 forward 階段的中間值（activation）、反向時拿來算 gradient。所以訓練比推論貴一個量級。
2. 記憶體佔用 = forward 階段 activation 的累計：這是訓練比推論吃 VRAM 的主因、不是「權重變大」、是「activation 要存著」。
3. 數值穩定性敏感：long chain 的 chain rule 容易導致 gradient 爆炸或消失、見 gradient 卡。

設計責任

推論階段完全不用 backpropagation。理解這點能解釋幾個現象：為什麼同樣模型訓練要 8 卡 H100 一週、推論單卡就跑得動（差幾十倍的計算與記憶體需求）；為什麼 LoRA / QLoRA 等 parameter-efficient fine-tuning 能大幅降低訓練成本（凍住大部分權重、只對少數 LoRA 矩陣做 backpropagation）；為什麼 inference framework（llama.cpp、vLLM）跟 training framework（PyTorch、JAX）的設計重點完全不同。

概念位置

Batching 介於 inference engine 內部、跟 KV cache 一起決定一個 GPU / Apple Silicon 能服務多少並發 user。但 batching 不是 free——靜態 batching 要等湊滿才跑、延遲首字延遲；連續 batching 平衡 throughput + latency 但實作複雜。Single-user 場景常無 batching（local Mac 跑 Ollama 即此情境）、production multi-tenant 必有 batching。

可觀察訊號與例子

實務觀察：production LLM 服務 throughput 在 batch size 4-32 之間有明顯提升、超過 GPU memory 上限後反而下降（KV cache 跟 model weight 競爭記憶體）。

設計責任

選 batching 策略看兩維度：

1. 應用 latency tolerance：
   • 互動式 UI（chatbot、IDE 補完）→ continuous batching、低 latency 優先
   • 批次處理（夜間 summarization）→ static batching、throughput 優先
2. 硬體 KV cache 上限：
   • GPU memory - model weights = batchable 容量
   • 預估 max batch size = available_memory / per_user_kv_cache

Embedding 服務通常 batch 16-128 都 OK（embedding 是純 forward pass、無 KV cache 累積）；chat / generation 服務 batch size 受 KV cache 嚴格限制。

詳細跟 production 部署 capacity planning 的對接見 4.9 Production 資源評估；跟 autoregressive 推論的單 token 瓶頸對應的優化討論見 3.2 attention 機制。

概念位置

Beam search 跟其他 decoding 策略的對比：

Beam search 的算法直覺：

1beam_width = 3
2Step 1：從機率分佈挑前 3 個 token、得到 3 條 partial sequence
3Step 2：每條 partial 各自展開所有可能下個 token、組合機率排序、保留前 3
4Step 3：重複 Step 2、直到所有 beam 都遇到 EOS 或達到 max_length
5Final：選總 log-probability 最高的 beam 當輸出

Beam search 在 LLM chat / coding 場景的副作用：

1. 輸出偏 boilerplate：K 個 beam 容易收斂到同樣的高頻開頭（「Sure!」「That’s a great question」）、各 beam 平均化掉原本該有的多樣性。
2. 缺乏隨機性：給同 prompt 永遠生同輸出、缺乏寫作 / 創意任務需要的變化。
3. 計算貴：K 倍記憶體 + K 倍 forward pass。

設計責任

讀 inference framework 看到 num_beams: 1 預設值就是用 greedy/sampling、num_beams: 5 才會開 beam search。寫 code 場景的判讀：日常用 top-p sampling 為主、需要確定性測試用 greedy、需要「在多個候選中挑最好的」用 best-of-N（每個獨立 sample、再選 reward 最高）而非 beam search。Beam search 在現代 LLM chat 場景已經少用、但在 translation / structured output 等「有正確答案」場景仍見。

概念位置

三層典型 bind address 的暴露範圍：

關鍵差異：

1. 127.0.0.1 只接 loopback、無論其他網路介面狀態都不接外部請求。
2. 0.0.0.0 在所有介面上監聽、若機器有 public IP 或在公開 Wi-Fi、就會被網路上其他人連到。
3. 具體 LAN IP 是中間地帶、限定來源到該介面的網段。

檢查當前 bind 狀態的指令：

1# macOS / Linux
2lsof -i -P -n | grep LISTEN | grep <port>
3
4# Linux
5ss -lntp | grep <port>
6
7# 或
8netstat -an | grep LISTEN | grep <port>

看到 127.0.0.1:<port> 是 loopback、*:<port> 或 0.0.0.0:<port> 是所有介面。

設計責任

理解 bind address 後可以解釋兩個現象：為什麼預設安全的伺服器都 bind 到 127.0.0.1（避免不小心暴露）、為什麼 Docker -p 8080:8080 預設 bind 到 0.0.0.0（容器化的便利性、但對個人 dev 是潛在暴露點）。

設計本地推論伺服器時、預設 loopback、想分享 LAN 時 bind 到具體 LAN IP（不要直接 0.0.0.0）、要對外時加 reverse proxy + auth + TLS。詳見 6.1 推論伺服器的綁定與暴露範圍 跟 7.3 入口治理與伺服器防護。

概念位置

BPE 訓練 tokenizer 的流程（簡化）：

1Step 0：vocab = 所有單一字元（256 個 byte / Unicode 字符）
2
3迭代：
4  Step 1：掃描 corpus、統計所有相鄰 token 對的出現頻率
5  Step 2：找出現最多的字元對（如 "l" + "o" 一起出現 1M 次）
6  Step 3：把它當新 token 加進 vocab、把 corpus 裡所有這個對換成新 token
7  Step 4：回到 Step 1、直到 vocab 達到目標大小（如 50K、128K、256K）

實際 token 化的結果：

BPE 的變體：

1. Byte-level BPE：把每個 byte 當基底（256 個）、所以任何 Unicode / 二進制都能 tokenize、不會有 unknown token。GPT-2 開始的標準。
2. SentencePiece BPE：跟 SentencePiece 框架結合、處理多語言更靈活。

設計責任

讀 model card 看到 tokenizer: BPE 就是這個演算法。BPE 對英文友好（高頻單詞整個一 token）、中文 / 日韓較不友好（單字符常被當獨立 token）；這就是為什麼同一段中文翻譯成英文後、英文 token 數常常更少、雲端 LLM 用中文 API 比英文貴。但越新的模型（Gemma 4、Qwen3 等）vocab 越大（256K+）、對中文友善度提升中。

概念位置

Catastrophic forgetting 在 LLM fine-tuning 的典型表現：

 1Before fine-tune（base instruct model）：
 2  HumanEval: 75
 3  MMLU: 70
 4  自己 domain 任務 hit rate: 40%
 5
 6After fine-tune（在自己 domain 資料上跑 SFT、3 epochs）：
 7  HumanEval: 55  ← 下降 20 點
 8  MMLU: 50       ← 下降 20 點
 9  自己 domain 任務 hit rate: 70%  ← 提升 30 點
10
11→ 自己 domain 強了、但通用能力崩了

成因：

1. Gradient 在新資料上對 base 權重做大更新：原本 base 的權重對通用任務有用、被覆蓋掉
2. 資料分佈差距大：自己 domain 跟 pretrain corpus 分佈差距大、學新的 = 忘舊的
3. 訓練 epoch 太多：模型 over-fit 到新資料、舊能力衰退更嚴重
4. Learning rate 太高：每步更新幅度大、舊權重變化快

緩解策略

主流 fine-tuning 配置（避免 catastrophic forgetting）：

1方法：QLoRA fine-tune
2參數：
3  - rank: 16-64（看資料量）
4  - alpha: 32（typical）
5  - lr: 1e-4 ~ 5e-4（LoRA 適合較大 lr）
6  - epochs: 1-3（不過度訓）
7  - 資料：80% in-domain + 20% 通用 instruction data（保留通用能力）

設計責任

讀 fine-tune paper / 報告看到「forgetting」「retention」「regression」就是這現象。寫 code 場景的判讀：

1. Fine-tune 前先建 baseline benchmark：把 base model 在通用 benchmark + 自己 domain 都跑一遍、fine-tune 後對比看 regression
2. 用 LoRA / QLoRA 是 default：除非有特殊理由要 full fine-tune、不然優先 LoRA
3. 不要把通用 chat 能力 fine-tune 掉：如果 fine-tune 後模型不會聊天、只會答自己 domain 問題、就是 forgetting 過頭
4. Iterative fine-tune 風險疊加：在 fine-tuned 模型上再 fine-tune（如 SFT → DPO）、forgetting 風險加倍、要小心評估
5. Reasoning 能力特別容易 forget：reasoning 是後期訓練的、fine-tune 一輪 SFT 容易破壞、reasoning model 不建議再 fine-tune

概念位置

Causal mask 在 attention 計算中的位置：

 1score = Q @ K^T / sqrt(d)     ← shape (seq_len, seq_len)、每對 token 一個分數
 2score = score + causal_mask   ← 加上 mask
 3attention = softmax(score) @ V
 4
 5causal_mask 長這樣（lower triangular、上三角全是 -∞）：
 6        K_0    K_1    K_2    K_3
 7Q_0   [  0    -∞     -∞     -∞ ]   ← token 0 只能看自己
 8Q_1   [  0     0     -∞     -∞ ]   ← token 1 能看 0~1
 9Q_2   [  0     0      0     -∞ ]
10Q_3   [  0     0      0      0 ]

關鍵特性：

1. 訓練時並行有效：所有 token 同時跑 forward pass、causal mask 確保每個 token 只看到該看的範圍。沒 mask 就會「偷看未來」、訓出 cheating 模型。
2. 推論時自動成立：自回歸生成本來就是一個一個生、後面不存在、mask 是隱式的。
3. 跟 KV cache 結合：推論時 cache 只存「過去」的 K/V、causal mask 自然滿足。

跟其他 attention 變體的關係：

設計責任

讀 paper / model card 看到「causal」「decoder-only」「auto-regressive」這幾組詞、就是這個機制。實務上、寫 code 場景的所有主流 LLM 都用 causal mask、所以這個概念是隱式 default、不會主動暴露給使用者；但理解它能解釋為什麼 LLM 是「接龍」、為什麼 bidirectional context 在 LLM 裡不存在（要 bidirectional 要用 encoder 架構）。

概念位置

CoT 的兩種觸發方式：

1直接回答：
2  Q: 23 × 47 = ?
3  A: 1081
4
5Chain-of-Thought：
6  Q: 23 × 47 = ?
7  A: 先算 20 × 47 = 940、再算 3 × 47 = 141、加起來 940 + 141 = 1081。
8     答案：1081

CoT 在 LLM 演化中的兩個階段：

第三階段的特性：模型自己決定「該想多久」（test-time compute 動態擴展）、推理 trace 可達數千 token、最終答案才是少數 token。

設計責任

讀 prompt engineering / paper 看到「CoT」「step by step」「reasoning trace」「thinking」等就是這個機制。寫 code 場景的判讀：

1. 複雜推理任務開 CoT 通常有幫助（math、debug、algorithm design）— 即使是 instruct model 也能透過 prompting 觸發
2. 簡單任務 CoT 浪費 token（autocomplete、單行查詢、純查表）
3. Reasoning model 的 CoT 是內建行為、不需要用 prompt 觸發、但 reasoning trace 會消耗大量 token（推論時間、context、API 成本都翻倍）
4. 本地跑 reasoning model：DeepSeek-R1 distill 系列、Qwen-QwQ 等可本地跑、但需要較大 context window 容納 reasoning trace

概念位置

Chunking 介於 corpus 跟 embedding model 之間、決定 embedding 的單位。同一份 corpus 不同 chunking 策略產出不同 index、retrieval 行為完全不同。Chunk 邊界也決定 retrieval 命中後給 LLM 的 context 邊界——chunk 邊界穿過語意單位、會把連貫資訊切散。

可觀察訊號與例子

切法策略：

• 固定 token 數：簡單但易切過句子 / 段落中間。
• 段落感知：用空白行切、保留段落完整。
• 語意 chunking：用 LLM / embedding 找語意邊界。
• 結構化文件：按 heading / section 切（markdown、code）。

跨 chunk 重複（overlap）：相鄰 chunk 留 10-20% 重疊、避免邊界訊號丟失。

設計責任

Chunking 之前要回答四個問題：

1. 任務類型：問答 / 摘要 / 探索性搜尋？決定 chunk 大小 baseline。
2. 文件結構：純文字 / markdown / code？決定切割 strategy。
3. 語言混合：中文跟英文 token 比例不同、char-based heuristic 可能不準。
4. Embedding model 能力：太短 / 太長 chunk 都會降低 embedding 品質。

寫 code 場景的實作範例見 RAG demo hands-on 的 slice_markdown function、設計取捨展開見 4.1 RAG 原理 的「Chunking 的本質取捨」段。

概念位置

跟其他 LLM deployment 形態的對比：

主流 client-side runtime（2026/5）：

設計責任

讀靜態網站 / 前端 RAG / 離線 LLM 教學看到「WebGPU LLM」「browser-side embedding」「offline LLM」就是這 paradigm。寫 code 場景的判讀：

1. 首訪載入慢：browser 第一次要下載模型權重（embedding 模型 ~50MB、LLM 1-5GB）、首訪體驗差；後續訪問 cache 起來、變快
2. WebGPU 支援度：2026/5 仍非所有 browser / 裝置都穩定支援、Safari iOS 較弱；fallback 到 WASM 但速度降一個量級
3. 模型完整性沒簽章：使用者下載到的模型權重沒類似 GGUF model card 的官方驗證、要靠 CDN + HTTPS 信任、不像本地 Ollama 有 hash 比對
4. 適合「embedding + 小 LLM」、不適合「30B reasoning」：browser 記憶體跟 WebGPU 算力都遠不如本地 Ollama、選 < 4B 模型較實際
5. 跟資安的關係：client-side 不需要 server API key、隱私強；但模型分發鏈（CDN → browser）成為新的供應鏈面、見 4.16 靜態 RAG deployment 的資安段

概念位置

CLIP 的訓練架構（簡化）：

 14 億組 (image, caption) 從網路爬：
 2  (photo of cat, "a fluffy orange cat sitting")
 3  (screenshot of code, "Python error: NameError x undefined")
 4  ...
 5
 6訓練：
 7  image → Image encoder（ViT-L/14）→ image_embedding
 8  caption → Text encoder（Transformer）→ text_embedding
 9
10  正向對（matching image-caption）：embedding 應該相似
11  負向對（同 batch 內其他不匹配）：embedding 應該遠
12
13  [Contrastive learning](/llm/knowledge-cards/contrastive-learning/) loss

訓完後得到：

1. 共享 embedding 空間：圖跟文字 embedding 都在 768/1024 維空間、相似度比較有意義
2. Zero-shot classification 能力：給一張圖、給 100 個文字標籤、看哪個 embedding 最接近 → 不用 fine-tune 就能分類
3. Image search / 多模態 retrieval：text 跟 image 互查、是 multimodal RAG 基底

對 VLM 的影響：

1CLIP 訓出來後：
2  image encoder 已經學會「把圖片變成有意義的 embedding」
3
4VLM 訓練時：
5  - 直接拿 CLIP 的 image encoder 當 vision encoder（凍住或一起 fine-tune）
6  - 接上 LLM、用 image-text 任務資料訓 alignment
7  - 不用從頭訓 vision encoder、省下大量 compute

跟 SigLIP 的關係：SigLIP（Zhai et al., 2023）是 Google 提出的 CLIP 變體、用 sigmoid loss 取代原本 InfoNCE、訓練更穩、品質略佳；Gemma 3 / Idefics 等用 SigLIP 而非原 CLIP。

設計責任

讀 VLM paper / model card 看到「CLIP backbone」「SigLIP encoder」「OpenCLIP weights」就是這 family。寫 code 場景的判讀：

1. CLIP 本身不是 VLM：CLIP 只有 image-text 相似度、不能生文字回答；VLM 是「CLIP 的 image encoder + LLM + alignment training」
2. 不同 CLIP 變體影響 VLM 能力：CLIP ViT-L/14 是經典、SigLIP / DFN（Apple）等變體在某些任務更強
3. Multimodal RAG 直接用 CLIP：純 image-text retrieval（如「找跟這張圖相似的 doc」）不需要完整 VLM、CLIP-like 模型就夠
4. CLIP 用於 zero-shot 分類仍實用：給定固定的 class label set（如「截圖 / 設計稿 / 程式碼 / 文件」）、CLIP 能直接 zero-shot 分類、不需要訓 specific classifier

概念位置

跟既有 sampling 概念的層次：

1模型 forward pass → logits（每個 vocab token 一個分數）
2   ↓ apply temperature
3   ↓ apply grammar mask（constrained decoding）  ← 本卡聚焦
4       - 算出當下位置的合法 token 集合
5       - 不合法 token 的 logit 設 -∞
6   ↓ softmax → 機率分佈
7   ↓ sampling（greedy / top-p / top-k）
8   ↓ next token

主要 grammar 類型：

主流實作對比：

設計責任

讀 sampling / structured output / function calling 進階文件看到「constrained decoding」「grammar mask」「JSON schema enforcement」就是這 framing。寫 code 場景的判讀：

1. 何時值得用：需要 100% 合法 JSON / 特定格式、function calling spec 嚴格、structured output 不可有解析錯誤
2. 不該用的情況：自由 / 創意輸出（會限制模型表達）、grammar 太嚴讓模型「該說的話說不出來」（如 enum 不含「unknown」、模型強制選錯）
3. 跟 function calling 的關係：function calling 是「模型訓練 + structured output」、constrained decoding 是 sampling 層的工程實作、可獨立組合
4. 加速 vs 拖慢：常見誤解是 grammar 拖慢 — 實測 XGrammar 等 pre-compiled 實作反而加速生成（跳過 boilerplate token 直接生關鍵 token、節省 forward pass）
5. 跟 3.10 constrained decoding 章節 的關係：本卡是定義、章節是內部機制（token mask 計算、CFG 編譯、性能取捨）

概念位置

典型 coding agent 的 context 構成（以 200K 模型為例）：

 1[1. System prompt + tool schema]：     固定 ~10K-30K
 2   - agent 角色、輸出規則、tool 列表 + spec、subagent 路由
 3   - 經常用 prompt cache 加速、見 [prompt cache 卡]
 4
 5[2. 工作歷史 / conversation history]：  動態 0-60K
 6   - 過去回合的 user query + assistant answer + tool calls
 7   - 越長越貴、harness 要決定何時 summarize / trim
 8
 9[3. 當前任務 file context]：           動態 0-100K
10   - 開啟的檔案、grep 結果、@-mention 帶入的內容
11
12[4. Reasoning trace（若 reasoning model）]：  動態 1K-10K / step
13   - <think>...</think> 段、每次推論都會佔 context
14
15[5. Tool result]：                    動態 0-50K
16   - file read 結果、bash output、test result
17
18[6. Margin / safety buffer]：         保留 20-30K
19   - 防止 generation 階段碰到 context limit

主流 coding agent 的 25% 規則（context engineering 慣例）：

設計責任

讀 coding agent 設計 / harness paper 看到「context budget」「context engineering」「token budgeting」就是這 framing。寫 code 場景的判讀：

1. 超出 budget 的訊號：模型開始忽略 system prompt、回答跟前文重複、tool call 重複過去步驟、reasoning trace 截斷
2. 節省 budget 的策略：用 prompt cache 把 system + tool schema 攤平、grep 取代全檔讀、tool result 限長度（如 head -100）、定期 summarize history
3. 跟 lost-in-the-middle 的關係：context 用越多、中段內容 recall 越差、所以「能用 20K 解就別用 100K」、不是「能塞 200K 就塞滿」
4. 不同 task 不同 budget：autocomplete 任務 budget 小（系統 prompt + 最近 50 行 code 就夠）；refactor 任務 budget 大（多檔案）；agent loop 任務 budget 動態（每步可能 grow）

概念位置

Contrastive learning 的核心訓練形態：

 1正向對（positive pair）：
 2  (query, relevant_doc) — 應該在 embedding 空間靠近
 3  例：("Python how to read file", "Python file reading tutorial...")
 4
 5負向對（negative pair）：
 6  (query, irrelevant_doc) — 應該在 embedding 空間遠離
 7  例：("Python how to read file", "CSS flexbox guide...")
 8
 9Loss（簡化的 InfoNCE loss）：
10  pull positive pair 靠近
11  push negative pair 遠離（多個 negative samples 對比）

主流形式：

關鍵特性：

1. 資料量需求大：contrastive learning 需要億級的正向對才能訓出好 embedding；資料來源是 query-doc click log、StackExchange QA pair、CC-paraphrase 等
2. Hard negative mining 是品質關鍵：隨機選 negative 容易（從 batch 取就行）、找「看似相關但實際無關」的 hard negative 更挑戰、是 embedding quality 提升的關鍵
3. 不能直接拿 pretrained LLM 用：LLM 的 hidden state 不是「為 retrieval 優化」的、要再 fine-tune 一輪 contrastive learning 才能當 embedding model

設計責任

讀 embedding model paper / 訓練 code 看到「InfoNCE」「triplet」「hard negatives」「mining strategy」就是這 paradigm。寫 code 場景的判讀：

1. 挑 embedding model 看訓練資料 domain：通用 retrieval（如 bge-large、nomic-embed）vs code-specific（如 jina-embeddings-v2-code、CodeT5+）、訓練資料分佈影響大
2. 不能拿任意 LLM 抽 hidden state 當 embedding：如「Llama 的 last hidden state 當 embedding」這類做法在 retrieval 上通常顯著輸給專門 contrastive-trained embedding model
3. Fine-tune embedding model 通常用 LoRA + contrastive loss：在自己 domain 資料上 fine-tune、提升 in-domain retrieval；標準 pipeline 是 sentence-transformers + LoRA

概念位置

Cross-entropy 在 next-token prediction 訓練裡的具體計算：

1模型預測：p = softmax(logits)  ← shape: (vocab_size,)
2真實答案：y = one-hot(true_token)  ← shape: (vocab_size,)、只有真實 token 那位是 1
3
4cross-entropy = -sum(y_i × log(p_i))
5              = -log(p_true_token)  ← 因為 y 是 one-hot、只剩這項

所以實作上 cross-entropy 就退化成「真實 token 預測機率的負對數」、機率越接近 1、loss 越接近 0；機率越接近 0、loss 越接近 ∞。

跟相關概念的關係：

設計責任

讀 LLM 訓練 / paper 時看到「training loss」幾乎都是 cross-entropy。實務判讀：cross-entropy 直接代表「模型對真實 token 的預測機率有多差」、loss = 2 大致對應「真實 token 被預測機率 ≈ 0.135」（exp(-2)）。模型在 pretrain 階段 cross-entropy 從約 11（純隨機）降到約 2-3（成熟模型）、SFT 階段再略降。

概念位置

Dot product 在 LLM 中的核心應用：

幾何直覺：

1兩個向量方向接近時：dot product 大（正值大）
2兩個向量垂直時：    dot product = 0
3兩個向量方向相反時：dot product 大負值
4
5a · b = |a| × |b| × cos(θ)
6                          ↑
7                  θ 是兩向量夾角

LLM 推論性能上、dot product 是「matrix multiplication 的基本單元」、整個 forward pass 可以看成大量 dot product 的批次運算；這是為什麼 GPU / Apple Silicon Neural Engine 都針對 dot product 做硬體優化。

設計責任

讀 attention / RAG 相關內容看到「inner product」「dot product」「QK^T」就是這個運算。寫 code 場景的判讀：用 vector database 時、選 distance metric 看：cosine 適合未 normalized 的 embedding、dot product 適合 L2-normalized 的 embedding（兩者結果同、後者較快）；attention 的 KV cache 量化（K=Q8 / V=Q4）對品質的不對稱影響、根本原因是 K 用於 dot product（誤差累積快）、V 用於加權平均（誤差被平均化）。

概念位置

DPO vs RLHF 的對比：

DPO 的 loss 形式（簡化）：

1loss = -log σ( β · (log π(y_w|x)/π_ref(y_w|x) - log π(y_l|x)/π_ref(y_l|x)) )
2                └─ 偏好 response 在 policy 跟 ref 的 ratio ─┘
3                                                            └─ 拒絕 response 的同樣 ratio ─┘

直覺：讓 policy 對偏好 response 的機率增加（相對 ref）、對拒絕 response 的機率降低（相對 ref）。

設計責任

讀開源 LLM 的 paper / model card 看到「DPO-tuned」「preference fine-tuning」就是這個流程。實務上 DPO 訓練成本只是 RLHF 的一小部分、許多 fine-tune 平台（如 Hugging Face TRL）內建支援。後續還有 IPO、KTO、ORPO 等變體、都是「直接用偏好 fine-tune、不訓 reward」這條路線的進一步演化。

概念位置

Embedding layer 在 forward pass 的位置：

1input："Hello world"
2   ↓ tokenizer
3token IDs: [9906, 1917]            ← 整數序列
4   ↓ embedding layer（vocab × hidden 查表）
5embeddings: [[0.1, -0.3, ...], [0.5, 0.2, ...]]   ← 向量序列、(seq_len, hidden_dim)
6   ↓ Transformer block × N
7   ↓ output projection
8logits

跟 embedding model 的差別：

兩者「都產出向量」、但層級跟用途完全不同：embedding layer 是 LLM 內部結構（per-token、給模型 forward pass 用）、embedding model 是外部工具（per-text、給檢索系統用）。

Embedding layer 的大小：

• Gemma 4 31B：vocab=256K、hidden=5120、embedding matrix ≈ 256K × 5120 = 1.3B 參數
• Llama 3 8B：vocab=128K、hidden=4096、embedding matrix ≈ 0.5B 參數

通常跟 output projection（hidden → vocab）相同大小、有些模型 tied（共用權重）、有些 untied。

設計責任

讀模型架構圖看到「token embedding」「embed_tokens」就是這一層。實務意涵：模型大小有非小比例來自 embedding（vocab 越大、embedding 越大）；換 tokenizer 等於整個 embedding 重訓、是 fine-tune 時通常不動的部分。

概念位置

Entropy 跟 LLM 相關概念的關係：

1Entropy(P) = -sum P log P                  ← 一個分佈自身的不確定性
2Cross-entropy(P, Q) = -sum P log Q         ← 用分佈 Q 編碼 P 的成本
3KL(P ‖ Q) = Cross-entropy(P, Q) - Entropy(P) ← 兩個分佈的差距

Entropy 在 LLM 中的具體意義：

範例：vocab = 128K、uniform 分佈的 entropy = log(128K) ≈ 11.76（接近 12）；成熟模型在文本上的平均 entropy 約 2-3。

設計責任

Entropy 本身在 LLM 訓練 / 推論很少直接出現、但理解它能解釋一些現象：perplexity = exp(cross-entropy) 是模型平均不確定性的指數形式；temperature 控制 sampling entropy（高 T → 高 entropy → 多樣輸出）；某些評估方法（如 entropy-based uncertainty estimation）會看模型輸出分佈的 entropy 來判讀「模型有多確定」。

概念位置

標準 FFN 的計算：

1input（hidden_dim）
2  ↓ W_up（linear、hidden_dim → intermediate_dim、通常放大 4x）
3intermediate vector
4  ↓ activation function（ReLU / GELU / SwiGLU）
5  ↓ W_down（linear、intermediate_dim → hidden_dim）
6output（hidden_dim）

Intermediate dim 通常是 hidden dim 的 4 倍（例如 hidden=4096、intermediate=16384）、所以 FFN 的參數量是 hidden × intermediate × 2 ≈ 8 × hidden²、遠大於 attention 的 4 × hidden²（Q/K/V/O 四個 hidden × hidden 矩陣）。

FFN 變體：

設計責任

理解 FFN 是參數大頭、能解釋幾件事：MoE 為什麼是「把 FFN 換成多個專家、只啟用部分」（因為 FFN 是最值得稀疏化的部分）、MoE CPU offload 為什麼是「把 expert FFN 卸到 RAM」（FFN 大、卸下來省 VRAM）、為什麼模型大小用「參數量」算（FFN 主導）。LoRA fine-tuning 時、通常選擇對 attention 的 Q/V 投影做 LoRA、不對 FFN 動、因為 FFN 太大、LoRA 收益相對小。

概念位置

Flash Attention 在推論架構中的角色：

1推論時的 attention 計算：
2  ├── 原始實作：Q · K^T 整個算完、寫進 memory、再讀出來做 softmax、再算 · V
3  │     └── 多次 memory 讀寫、長 context 下 IO 成為瓶頸
4  └── Flash Attention：用 tiling 把計算切塊、中間結果留在 SRAM / register
5        └── 減少 memory 讀寫、長 context 加速明顯

跟 attention 變體的關係：

• Flash Attention 是實作層的優化、跟 MHA / GQA / MLA 等架構層變體是兩個獨立維度。
• 不同變體都能搭配 Flash Attention 的實作技巧。

在 llama.cpp 中的旗標：

1llama-server -fa  # 啟用 flash attention
2# 或
3llama-server --flash-attn

事實查核註：Flash Attention 的版本演進快（Flash Attention 1 / 2 / 3）、不同推論引擎的支援度依版本變化。具體限制（如「V cache Q4 量化要 -fa 才能啟用」）依 llama.cpp 版本變動、引用前以 llama-server --help 跟 release notes 為準。

設計責任

理解 Flash Attention 後可以解釋兩個現象：為什麼啟用 -fa 後長 context 推論速度提升明顯（IO bound 變 compute bound）、為什麼部分 KV cache 量化組合（如 V=Q4_0）在 llama.cpp 上需要 flash attention 才能跑（實作層面的耦合）。

工程實務上、啟用 flash attention 通常沒副作用（數學上等價、品質不變）、是 PC 場景長 context 推論的預設啟用旗標。詳見 5.2 KV cache 量化策略 的 flash attention 段落。

概念位置

主流浮點格式的位元分配：

關鍵 trade-off：

1. FP16 精度好、範圍窄：尾數多、表達小範圍內細節準；但指數少、容易 overflow（gradient 爆炸時）/ underflow（gradient 接近 0 時）。
2. BF16 範圍跟 fp32 一樣大、精度差：指數位跟 fp32 同（8 位）、訓練時的 dynamic range 跟 fp32 接近、不會 overflow；但尾數少、精度差。實測對訓練影響小、所以是現代 LLM 訓練主流。
3. FP8 是新興格式：H100 / B200 等新 GPU 原生支援、訓練 / 推論都能加速、但精度損失需要 careful loss scaling。

LLM 工作流的精度選擇：

設計責任

讀 paper / config 看到 mixed_precision: bf16、torch_dtype: bfloat16 就是 BF16 訓練。寫 code 場景的判讀：本機跑 GGUF Q4_K_M 模型、內部運算的 activation 仍是 fp16 / bf16、只有權重儲存是 4-bit；KV cache 預設也是 fp16、量化 KV cache 是進階優化（K=Q8 / V=Q4）。

概念位置

LLM 一次 forward pass 的大略流程：

 1input token IDs
 2  ↓ embedding layer：整數 → 向量
 3sequence of vectors
 4  ↓ Transformer block 1（attention + FFN）
 5  ↓ Transformer block 2
 6  ↓ ...
 7  ↓ Transformer block N
 8final hidden state
 9  ↓ output projection（hidden → vocab）
10logits（每個 vocab token 一個分數）
11  ↓ softmax（推論時）
12probability distribution → 挑下一個 token

跟相關概念的對比：

設計責任

理解 forward pass 後可以判讀 LLM 的記憶體與速度：每次 forward pass 都要把整份模型權重從記憶體讀到處理器一次、所以 memory bandwidth 是推論瓶頸；KV cache 的存在是為了避免每次 forward pass 重算前面 token 的 K/V；MTP / speculative decoding 都是「一次 forward pass 攤平多個 token 成本」的優化路徑。

概念位置

各家 GPU 對應的常見 backend（2026 年 5 月狀態、依社群實踐變化）：

選 backend 的判讀依硬體跟平台：NVIDIA GPU 用 CUDA、AMD on Linux 優先 ROCm、AMD on Windows 多用 Vulkan、Intel ARC 用 Vulkan 或 SYCL、Apple Silicon 用 Metal。

事實查核註：上表的「llama.cpp 生態成熟度」是社群常見回報、不是經本卡系統實測的 benchmark；各 backend 的支援度跟 throughput 依推論軟體版本快速演進、引用前以對應 backend 的官方文件跟 llama.cpp release notes 為準。

設計責任

理解 GPU compute backend 後可以解釋三個現象：為什麼下載 llama.cpp release 要選 CUDA / ROCm / Vulkan 版本（每個 build 對應一種 backend）、為什麼同樣硬體 throughput 差很多（backend 不對或 fallback 到 CPU）、為什麼非 NVIDIA GPU 跑 LLM 經驗較少（CUDA 生態太成熟、其他 backend 仍在演進）。

選 PC GPU 跑本地 LLM 時、backend 成熟度是「工具鏈支援度」軸、跟硬體規格軸獨立、選卡時兩軸都要考慮。詳見 5.6 GPU 廠商差異。

概念位置

Gradient 連接「loss」跟「該怎麼更新權重」兩件事、是 backpropagation 算出來的東西、也是 SGD / Adam 等 optimizer 消費的輸入：

1[forward pass] → 算出 loss
2                    ↓
3[backpropagation] → 算出 gradient（每個權重一個值）
4                    ↓
5[optimizer] → 用 gradient 更新權重：w_new = w_old - lr × gradient

Gradient 在 LLM 訓練中的兩個常見問題：

設計責任

推論階段（拿訓練好的模型生 token）不需要算 gradient、只有 forward pass；gradient 只在訓練 / fine-tuning 階段出現。所以本地跑 LLM 寫 code 的場景不會碰到 gradient、但讀懂訓練流程、理解「為什麼 SFT / RLHF 需要 GPU、推論不一定要」這類判讀就要先理解 gradient 的角色。

概念位置

兩種失敗模式的訊號跟處理：

數學直覺（簡化）：

1深 N 層的 chain rule：
2∂loss/∂W_input = ∂loss/∂out × ∂out/∂h_N × ∂h_N/∂h_{N-1} × ... × ∂h_1/∂W_input
3                                └──────────── N 個 factor 連乘 ──────────────┘
4
5若每個 factor ≈ 0.5、N=100：累乘 ≈ 0.5^100 ≈ 0       → vanishing
6若每個 factor ≈ 1.5、N=100：累乘 ≈ 1.5^100 ≈ 4e17    → explosion

Residual connection 讓 gradient 有「捷徑」可走、不全靠 chain rule 一層層乘、是深層 Transformer 訓得起來的核心結構之一。

設計責任

讀訓練 log 看到 loss: nan、grad_norm: inf 就是 explosion；看到 loss 平穩、幾個 epoch 都不降就是可能的 vanishing。寫 code 場景幾乎不會碰到（推論不算 gradient）、但自己 fine-tune 時要會判讀。LLM 用的 SwiGLU / GELU 都是 saturation 較不嚴重的 activation、加上 residual + pre-norm、現代 Transformer 訓 100+ 層相對穩定。

概念位置

Hallucination 的常見形態：

降低 / 偵測 hallucination 的常見手段（依場景變化）：

1. RAG：把真實內容檢索後注入 prompt、模型基於真實內容生成。
2. temperature 降低：採樣較保守、減少創造性但也減少幻覺。
3. citation 要求：prompt 要求列出引用、後續可驗證。
4. 下游驗證：對輸出做事實檢查（如 code 跑 compiler、引用查實際資料庫）。
5. 明確的「不知道就說不知道」instruction：降低過度自信、但不能消除。

事實查核註：Hallucination 的研究跟降低技術仍在快速演進、不同模型、不同任務類型的 hallucination rate 變化大、引用前以最新研究跟具體 model card 為準。Stanford TruthfulQA 等 benchmark 是常見參考。

設計責任

理解 hallucination 後可以解釋兩個現象：為什麼 LLM 給的「具體事實」（人名 / 數字 / 引用）特別要驗證（生成機制本身就會虛構）、為什麼 LLM 寫的 code 看似合理但 import 不存在的 package（hallucinate 出 library API）。

production 場景下、hallucination 影響合規（生成包含真人 PII 的虛構內容仍是 PII 處理）、UX（使用者照抄誤導內容）、安全（生成假 URL 引發釣魚）；應對策略不是「擋住 hallucination」、是「降低觸發率 + 下游驗證 + 適當的 disclaimer」。詳見 LLM Log 與 PII 治理。

概念位置

Homebrew 在 macOS 跟使用者要安裝的工具之間、扮演「公開 registry + 本地套件管理」的角色。它維護一份名為「formula」的 Ruby 腳本清單、每個 formula 描述某個工具怎麼下載、編譯、安裝。執行 brew install ollama 時、Homebrew 找到 ollama formula、下載對應 bottle（預編譯二進位）、放到 /opt/homebrew/（Apple Silicon）或 /usr/local/（Intel Mac）、再把可執行檔 symlink 到 /opt/homebrew/bin/。新機從零的完整安裝順序（含第一次裝 Homebrew、PATH 設定與晶片前綴差異）見 macOS 新機基礎建設。

brew services 是 Homebrew 附帶的服務管理子命令、把指令封裝成 macOS 原生的 launchd service、處理「開機自動啟動 / 停止 / 重啟」需求。

可觀察訊號與例子

日常會碰到的 brew 指令：

Apple Silicon Mac 上的關鍵路徑是 /opt/homebrew/、子資料夾各有角色：bin/（可執行檔）、var/log/（服務 log）、Cellar/（套件實際內容）、opt/（版本無關的 symlink）。看到「/opt/homebrew/var/log/ollama.log」時、就是 brew 管理的 Ollama 服務 log 位置。

設計責任

用 brew 安裝 vs 用官方 .dmg / .pkg 的取捨：CLI 工具（ollama、llama.cpp、git 等）走 brew、好處是統一升級路徑；GUI 應用（LM Studio、Docker Desktop 等）多半改下載官方安裝包、因為 brew cask 不一定即時跟上版本。第一次裝 Homebrew 自己用官方 install script（在 brew.sh）、之後其他工具都從 brew 走。

概念位置

兩條 retrieval 路線的盲點：

主流合併方法：

Reciprocal Rank Fusion（RRF）

最常用、簡單：

 1對每個 doc：
 2  score = sum_over_retrievers(1 / (k + rank_i))
 3
 4k 是常數（典型 60）、rank 是該 retriever 給 doc 的排名
 5
 6example：
 7  doc X 在 BM25 排名 3、在 embedding 排名 1
 8  RRF score = 1/(60+3) + 1/(60+1) = 0.0159 + 0.0164 = 0.0323
 9
10按 RRF score 排序、取 top-K

優點：不需要 normalize 不同 retriever 的分數、簡單可靠 缺點：不能 fine-tune 兩條路線的權重

Weighted score fusion

對每條路線的 score 加權平均：

1score = α × BM25_score_normalized + (1-α) × embedding_score_normalized

優點：可以調 α 偏 BM25 或 embedding 缺點：要 normalize 兩個 score scale、調 α 是 hyper-parameter

設計責任

讀 RAG production / retrieval framework 看到「hybrid search」「BM25 + dense」「RRF」就是這 framing。寫 code 場景的判讀：

1. 何時值得加 hybrid：embedding-only retrieval 漏精確 keyword / 識別碼、BM25-only 漏語意相似、混合補完
2. 何時不需要：純語意任務（embedding 已準）、純 keyword 任務（BM25 已準）、極小語料
3. 跟 reranker 的組合：hybrid retrieve top-50（BM25 top-25 + embedding top-25、RRF 合併）→ reranker rerank → LLM top-5
4. 主流實作：Elasticsearch / OpenSearch 內建、Weaviate / Qdrant / Pinecone 都支援、Postgres 用 pg_search + pgvector
5. 跟 4.1 RAG 章節 的關係：本卡是定義、章節是 retrieval pipeline 設計含 hybrid 段

概念位置

從圖到 image token 的轉換：

1Input image: 1024×1024 RGB
2   ↓ Patchify（切 14×14 patch、得 ~5000 個 patch）
3   ↓ Vision encoder（ViT 處理每個 patch、產 768/1024 維向量）
4   ↓ Optional: 2D position embedding
5   ↓ Optional: pooling / merging（減少 token 數）
6Image tokens: ~500-2500 個（依模型設計）
7   ↓ Projection（vision_dim → LLM hidden_dim、配合 LLM 內部維度）
8   ↓ 跟 text token 串成單一 sequence
9   ↓ Transformer 跟一般 token 一樣處理

主流 VLM 的單張圖 token 用量（粗略、依模型 / 解析度而變）：

事實查核註：上述 token 數量級依模型版本、推論配置（如「low / high detail」模式）變化、引用前以對應 model card 跟 API 文件為準。

設計責任

讀 VLM API / 推論 log 看到「image tokens used: 1247」「visual tokens: 580」就是這指標。寫 code 場景的判讀：

1. 多張截圖 = context 吃緊：一張 1500 token、丟 10 張就 15K、加上 prompt 跟回答、long context 模型才能 handle
2. 同張圖、解析度模式影響成本：許多 API 提供 low / auto / high detail 模式、low detail 約 1/10 token；OCR 需要高解析、不細節辨識可選 low
3. 本地 VLM 推論 prefill 慢：image token 多、prefill 階段（TTFT）對應變長、第一個字出來要等較久
4. API 計費通常 image token 跟 text token 同價：算成本看實際用了多少 image token、不要假設「一張圖 = 一個 token」
5. Image token 是消耗品、不是參數：跟模型內部權重不同、純粹是「這次 forward pass 的 input」

概念位置

KL divergence 在 LLM 中的兩個主要角色：

1. 跟 cross-entropy 的關係：

   1cross-entropy(P, Q) = entropy(P) + KL(P ‖ Q)

   訓練時 P（真實分佈）固定、entropy(P) 是常數、所以「minimize cross-entropy」等於「minimize KL」。

2. RLHF / DPO 的「KL 約束」：

   alignment 階段不能只 maximize reward、否則模型會「為了 reward 把語言能力毀掉」。所以加 KL 約束：

   1objective = E[reward] - β × KL(π_new ‖ π_ref)
   2                         └─ 不讓新模型偏離 ref（通常是 SFT 後的 base）太遠 ─┘

   β 控制「reward 追求」vs「不偏離原始模型」的平衡。

跟相關概念的對比：

設計責任

讀 alignment paper 看到 β、KL penalty、KL coefficient 等詞、知道這些是控制「模型在追 reward 時偏離 base 多遠的容忍度」。β 太小、模型容易 reward hacking（找 reward 高但實質爛的輸出）；β 太大、模型動不了、reward 升不上去。DPO 把 KL 約束內嵌進 loss、不像 RLHF 需要顯式 KL term、是 DPO 比 RLHF 簡單的原因之一。

概念位置

launchd service 用一份 plist（property list、XML 格式設定檔）描述「要跑哪個程式、何時啟動、出問題時要不要重啟、log 寫到哪裡」。plist 放在三個位置之一、決定服務的觸發範圍：

Homebrew 的 brew services 子命令是 launchd 的 wrapper、產生 plist 並放進 ~/Library/LaunchAgents/、避免使用者直接手寫 XML。Apple Silicon Mac 上產生的檔名形式是 homebrew.mxcl.<service>.plist。

可觀察訊號與例子

執行 brew services start ollama 後可以驗證實際發生的事：

1# 看 plist 內容
2cat ~/Library/LaunchAgents/homebrew.mxcl.ollama.plist
3
4# 用 launchctl 看服務狀態
5launchctl list | grep ollama
6
7# 看服務 log（Apple Silicon）
8tail -f /opt/homebrew/var/log/ollama.log

plist 內常見的鍵：ProgramArguments（要跑哪個指令）、RunAtLoad（開機就啟動）、KeepAlive（crash 後自動拉回）、StandardOutPath / StandardErrorPath（log 路徑）。出問題時先看 log 路徑指向的檔案、能直接看到 service 的 stdout / stderr。

服務管理常用指令：

1brew services list             # 列出所有由 brew 管理的服務
2brew services start ollama     # 啟動 + 註冊自動啟動
3brew services stop ollama      # 停掉服務、保留 plist
4brew services restart ollama   # 升級套件後重啟

直接用系統的 launchctl 也行、但語意較底層、實務上有 brew 包裝就用 brew。

設計責任

選擇「launchd service」vs「前景手動跑 ollama serve」的判讀：日常用機建議用 launchd service、好處是重開機自動拉起、出問題的 log 有固定位置可看；只在偶爾用本地 LLM 的場景、保持手動跑反而省記憶體（沒在用就停掉）。升級套件後記得 brew services restart、否則跑的還是舊版二進位。

概念位置

LayerNorm 在 Transformer block 內的位置（現代主流是 pre-norm）：

1Transformer block（pre-norm 配置）：
2  x
3  ↓ LayerNorm
4  ↓ Self-Attention
5  ↓ + 跟 x 做 residual connection
6  ↓ LayerNorm
7  ↓ FFN
8  ↓ + 跟前一步輸出做 residual connection

主流變體比較：

RMSNorm 比 LayerNorm 簡單、實測訓練穩定性接近、推論更快（少算 mean 跟加 β）、所以現代 LLM 多用 RMSNorm。讀 paper 看到「RMSNorm」就是 LayerNorm 的這個簡化變體。

Pre-norm vs post-norm：

• Pre-norm（LayerNorm 在 attention / FFN 之前）：深度模型訓練較穩、現代主流。
• Post-norm（LayerNorm 在 residual add 之後）：原始 Transformer paper 的設計、深層訓練不穩定。

設計責任

理解 LayerNorm 後可以判讀「深層 LLM 為什麼訓得起來」的部分答案：residual connection + LayerNorm 是讓梯度能穩定流過幾十層 Transformer 的兩根支柱。讀 model card 看到「RMSNorm」「pre-norm」等詞、知道對應的設計選擇跟訓練穩定性意涵。

概念位置

LLM 訓練 learning rate 的常見模式：

Learning rate schedule（lr 隨訓練步數調整）的主流模式：

1. Warmup：訓練最初幾百 ~ 幾千 step、lr 從 0 線性升到目標值。避免初期 gradient 大、模型瞬間 diverge。
2. Cosine decay：warmup 後、lr 用 cosine 函數從目標值降到接近 0。訓練後期細調。
3. WSD（Warmup-Stable-Decay）：近期變體、中間維持高 lr 更久。

設計責任

讀 training config 看到 learning_rate、lr_scheduler_type: cosine、warmup_steps: 1000 等就是這組設定。Fine-tune 時 lr 設太大、模型會「忘記」pre-training 學到的能力（catastrophic forgetting）；太小則訓不進新資料、loss 不降。實務除錯：fine-tune 時 loss 第一個 epoch 就 NaN、十之八九是 lr 太大；loss 完全不降、十之八九是 lr 太小或 gradient 沒流到要訓的權重。