概念位置

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 沒流到要訓的權重。

概念位置

主流 LLM benchmark 一覽：

事實查核註：各 benchmark 的飽和狀態、前沿模型 score 持續變動、上述為 2026/5 主流觀察。引用前以 Papers with Code 或 HuggingFace Open LLM Leaderboard 當前狀態為準。

Benchmark 的常見陷阱

1. 訓練資料污染（Contamination）：benchmark 題目本身在 pretrain corpus 出現過、模型「記得」答案、看似強實際是 memorization
2. 飽和（Saturation）：前沿模型 score 接近上限、無法區分模型品質差距（HumanEval 80%→95% 看似進步、實際 5% 多半是 lucky 而非實質提升）
3. LLM-as-judge bias：用 LLM（如 GPT-4）評其他 LLM、judge 的偏好（如「冗長 = 好」）會 bias 評分
4. Single-task overfitting：模型廠商針對 benchmark 特別 fine-tune、benchmark 高分但通用能力沒提升
5. Prompt sensitivity：同個 benchmark 用不同 prompt format、score 差幾個百分點

設計責任

讀 model card / paper 看到 benchmark 數字、判讀框架：

1. 看 multiple benchmarks、不只一個：如挑 coding 模型、看 HumanEval + MBPP + SWE-bench、不只看 HumanEval
2. 跟自己任務對齊的 benchmark 才重要：你做 RAG 應用、看 retrieval benchmark；你做 chat、看 MT-Bench / Arena
3. 看「相對」、不只看「絕對」：「Model A 在 MMLU 比 Model B 高 2%」可能 noise；「A 比 B 高 10%」更可信
4. In-house benchmark 是最後檢驗：自己的真實工作流案例 > 任何公開 benchmark

概念位置

跟 traditional logging 的對比：

主流 OTel GenAI span 類型：

每個 span 標準屬性：gen_ai.system（vendor）、gen_ai.request.model、gen_ai.usage.input_tokens / output_tokens、gen_ai.request.temperature 等。

設計責任

讀 LLM observability docs / OTel spec 看到「span」「trace」「OTel GenAI semconv」就是這 framing。寫 code 場景的判讀：

1. 何時值得加 tracing：超過個人 demo、有實際使用者 / production 流量、開始遇到「為什麼 agent 跑這條路」debug 問題
2. 不該自己寫 logging：用 OTel GenAI semconv 標準化、未來可換 backend（LangSmith → Phoenix → 自架）
3. Trace 不只 debug、也是 eval 來源：production trace 餵回 LLM-as-judge 做品質評估
4. 跟 4.20 LLM tracing 章節 的關係：本卡是定義、章節是工程實務（attribute 設計、cost monitoring、failure debug 流程）

概念位置

跟其他 eval 路徑的對比：

主要 use case：

1. In-house benchmark：自己工作流的真實案例、自寫 rubric、judge 評
2. Production trace eval：用 LLM tracing 蒐集的 production trace、定期 judge 跑、抓品質回歸
3. A/B test：兩個 prompt / model 變體、judge 做 pairwise 比較
4. Synthetic data quality：用大模型生 fine-tune 資料、judge 過濾低品質

設計責任

讀 eval framework / production AI app 看到「LLM as judge」「pairwise eval」「LLM evaluator」就是這 framing。寫 code 場景的判讀：

1. Judge 模型選擇：強模型當 judge（GPT-5 / Claude 4 / Gemini 旗艦）、reasoning model 更穩；judge 跟被測同家可能有 self-preference bias
2. 三大 bias 緩解：
   • Position bias：A/B pairwise 換位置跑 2 次取一致 vote
   • Verbosity bias：rubric 加「冗長不加分」明確指示、或長度 normalize
   • Self-preference bias：用 3 個不同 judge model 取多數
3. 跟 4.21 LLM-as-judge 章節 的關係：本卡是定義、章節是工程實務（rubric design、bias 緩解、calibration、trace 串接）
4. 不是萬靈丹：高 stake 任務（醫療、法律、安全）仍需 human eval；judge 的天花板 = judge 模型本身的能力

概念位置

Logit 在 LLM 輸出 pipeline 的位置：

1最後一層 Transformer 輸出 hidden state
2   ↓ output projection（linear layer）
3logits（shape: vocab_size、實數、可正可負）
4   ↓ logit warping / masking（可選、用於控制輸出）
5   ↓ /temperature
6   ↓ softmax
7probability distribution
8   ↓ sampling（greedy / top-k / top-p）
9next token

操作 logit 的常見技巧：

設計責任

理解 logit 後可以判讀 sampling 階段的控制粒度：所有「不重訓模型、影響輸出」的技巧（temperature、structured output、constrained generation、logit bias）本質上都是「在 softmax 前後動 logit」、不是動模型權重。這也是為什麼同一個模型用不同 sampling 設定能產生差很多的輸出。

概念位置

LoRA 的數學形式：

1原 layer 輸出：y = W × x       （W 凍住）
2加 LoRA 後：  y = W × x + B × A × x
3                          └──┬──┘
4                       LoRA update（rank r）
5                       A shape: (r, hidden_dim)
6                       B shape: (hidden_dim, r)

關鍵特性：

QLoRA（Dettmers et al., 2023）進一步把原模型量化到 4-bit、LoRA 訓在量化模型上、消費級 GPU 也能 fine-tune 大模型。

設計責任

讀 fine-tuning 教學 / Hugging Face PEFT 看到 LoRA、QLoRA 是現在主流。寫 code 場景的判讀：LoRA 適合「在現有模型上加領域知識 / 風格」（如教模型用特定 codebase 慣例）、不適合「教模型新世界知識」（仍要 pre-training 級資料）；adapter 形式讓「多客戶 / 多風格」場景可以共用 base model、只切換 adapter、節省 GPU 記憶體。

概念位置

LLM 各訓練階段用不同的 loss function：

評估時用的指標（perplexity、accuracy、BLEU 等）跟訓練 loss 是不同概念：loss 是「訓練要 minimize 的東西」、指標是「給人看模型好不好的數字」、兩者不一定一致（loss 降但指標不一定升、反之亦然）。

設計責任

選 loss function 等於選「訓練要把模型推往哪個方向」。Cross-entropy 推「機率分佈接近真實 token」、reward model 推「人類偏好高的回應」、DPO 推「偏好回應 vs 拒絕回應的對比」— 每種 loss 對應的模型行為不同。讀 paper 看到「我們用 X loss」、要回問「這 loss 把模型推往哪個方向」、才能判斷模型訓練出來的特性是否符合預期。

概念位置

Long context 的 effective context 跟 claimed context 落差來自三個現象：

 1Recall accuracy vs 答案位置（典型 10K context）：
 2
 3100% |█                                       █
 4     |██                                     ██
 5 80% |███                                   ███
 6     |███                                   ███
 7 60% |███          ____                     ███
 8     |███      ___/    \___                 ███
 9 40% |███    _/            \_               ███
10     |█████─/                \─────         ███
11     |
12       0      2K     4K     6K     8K    10K
13       開頭                              結尾

成因：

1. Attention weight 分佈不均勻：訓練資料中、句首 / 段首通常含關鍵資訊、模型學會偏重句首；長 context 的中段在訓練資料中相對稀疏、attention 沒學好
2. Positional encoding 設計：RoPE / ALiBi 等對長距離 attention 的衰減模式、中段 token 跟 query 距離通常較大、attention 弱
3. 訓練 context 長度的影響：模型若訓練在 8K context、推論時用 128K（用 RoPE scaling 延伸）、中段表現比訓練範圍內差更多

設計責任

讀 long-context paper / benchmark 看到「lost-in-the-middle」「U-shape recall」就是這現象。寫 code 場景的判讀：

1. 把關鍵資訊放開頭或結尾：system prompt 在開頭、最新指示在結尾（剛好是模型 attention 最強的兩處）
2. 長 context 不是「塞越多越好」：超過 effective context（典型 8-16K）後、邊際效用急降
3. RAG 比 long context 仍有價值：把相關片段 retrieve 出來放 prompt 開頭、比把整份文件塞進 100K context 效果更穩定
4. 驗證自己模型的 effective context：用 needle-in-haystack 或自製測試、看模型在 8K / 16K / 32K 表現掉到哪
5. Reasoning model 的 thinking trace 不會遇到這事故嗎？ — 仍會遇到、但 reasoning 過程會主動重新引用前文、部分緩解；不過 thinking trace 本身會擠壓 context budget、可能反而觸發 degradation

概念位置

LLM 中 matmul 出現的關鍵位置：

關鍵尺寸規則：左矩陣 column 數 = 右矩陣 row 數、即 (m × k) @ (k × n) = (m × n)。Dimension mismatch 是訓練 / 推論最常見的 PyTorch 報錯之一。

為什麼 matmul 是 memory bandwidth bound

LLM 推論每生一個 token、要把整份模型權重從記憶體讀到處理器一次（每個權重在當輪 forward pass 的某個 matmul 都用得到）；現代 GPU / Apple Silicon 的算力遠超頻寬、所以「讀權重要多久」變主要瓶頸。這就是為什麼：

• 31B 模型 Q4_K_M 約 18GB、M4 Max 頻寬 546 GB/s、理論上限 ≈ 30 tok/s
• 量化 加速主要是「權重變小、每秒能讀過更多次完整模型」
• Batching / speculative decoding 加速主要是「一次讀權重、攤平到多個 token」

設計責任

讀 paper / model card 看到模型參數量、可以反推總 matmul 工作量；看到 inference benchmark 看到 tok/s、可以用「模型大小 / memory bandwidth」算理論上限對照。寫 code 場景無需直接寫 matmul、但理解這個運算的成本結構、能看懂量化 / batching / speculative decoding 等加速技巧為什麼有效。

概念位置

MoE 在 transformer 架構中的位置：

1transformer block：
2  ├── attention 層（所有 token 共用）
3  ├── layer norm
4  └── FFN 層
5        ├── Dense 架構：所有 token 走同一組 FFN
6        └── MoE 架構：FFN 拆成多個 expert、router 挑選 top-k 個啟用

主流 MoE 模型的設計選擇（依模型而異）：

• expert 數量：通常 8 ~ 256 個
• 每 token 啟用 expert 數：通常 1 ~ 2 個（top-k routing）
• shared expert：部分模型保留少數所有 token 共用的 expert
• total / active parameter 比：常見 5x ~ 10x（如 Qwen3-30B-A3B：30B total / 3B active）

事實查核註：MoE 架構的具體實作（router 演算法、load balancing loss、expert 並行策略等）依模型快速演進、引用前以該模型的技術報告或 paper 為準。

代表性 MoE 模型（依公開資訊）：Mixtral 8x7B、DeepSeek V3、Qwen3-30B-A3B、Llama 4 Scout 等。

設計責任

理解 MoE 後可以解釋三個現象：為什麼 MoE 模型的「30B 總參數」跟「3B active parameter」是兩個獨立指標（前者影響記憶體需求、後者影響速度）、為什麼 MoE 適合 CPU 卸載（不活躍的 expert 可以留在系統 RAM）、為什麼 MoE 在多 GPU 場景的並行策略跟 Dense 模型不同（expert 可以分到不同卡）。

選 MoE 模型 vs Dense 模型、需考慮：MoE 對 RAM 容量要求較高（要放所有 expert 權重）、對 GPU 算力要求較低（每 token 走 active parameter）；Dense 對 VRAM 容量要求較低（可全載中型模型）、對 GPU 算力要求較高。詳見 5.1 MoE 模型與 CPU 卸載策略 跟 5.5 PC 場景的模型選型優先順序。

概念位置

典型的 model card 包含哪些區段（依平台跟模型而異）：

事實查核註：Hugging Face 推動 Model Card 規範跟 Model Card Toolkit、但實際填寫品質依 organization 變化、部分 repo 的 model card 內容很簡略、不能 100% 依賴。引用前以該 repo 當前內容為準。

設計責任

理解 model card 後可以解釋兩個現象：為什麼選模型不能只看名字（同個 base model 的不同 fine-tune 版本能力差很多）、為什麼商用前要看 license（Llama Community License、Apache 2.0、MIT 等差異大）。

實務上選模型時、model card 是第一閱讀對象、其他資訊（社群評測、benchmark leaderboard）作為交叉驗證；引用模型時應該明確記下「base model + fine-tune 變體 + 量化版本」三層。詳見 6.0 模型供應鏈與信任邊界 跟 LLM Deployment 供應鏈完整性。

概念位置

Model tag 是介面層跟推論伺服器之間的識別碼、形式由各個伺服器各自定義。Ollama 用 family:size-variant-quantization 的單行字串、LM Studio 用 Hugging Face 完整檔名、llama.cpp 直接用 .gguf 檔路徑。同一份模型權重在不同伺服器有不同 tag 字串、但指向的底層GGUF權重可以是同一份。

可觀察訊號與例子

Ollama 的 tag 結構：

四個欄位裡、size 直接決定記憶體佔用、variant（instruct / coding / base）決定模型適合的任務型態、quantization 影響品質跟記憶體取捨。Tag 中省略某些欄位時、伺服器用該欄位的預設值（通常是「常用組合」）。

設計責任

選 tag 時要看三件事：先看 size 確認模型塞得進記憶體（對照硬體記憶體預算）、再看 variant 確認用途匹配（寫 code 要選 instruct / coding 變體、避免 base model 的隨機接龍行為）、最後看 quantization 決定品質 / 記憶體甜蜜點。完整可用 tag 在各伺服器的 model registry（Ollama 在 ollama.com/library、LM Studio 在 Discover 分頁）。

概念位置

MoE 卸載屬於「推論時的權重位置管理」、跟 量化 屬於「權重精度壓縮」是兩個獨立維度、可以疊加（如 30B MoE Q4 + 卸載部分層、模型精度跟記憶體位置同時被處理）。它跟 KV cache 量化是 PC 場景常一起使用的兩個工具：卸載騰出 VRAM、KV cache 量化讓騰出的 VRAM 拿去開大 context window。

在 llama.cpp 中、對應的旗標是 --n-cpu-moe <N>、把 N 層的 MoE 專家權重保留在 CPU 記憶體。例如 --n-cpu-moe 30 表示 30 層的專家層留 RAM、其餘走 GPU。

可觀察訊號與例子

以 Qwen3-30B-A3B Q4_K_M（模型體積 10 GB 級、active parameter 約 3B 等級）為例、不同卸載策略下記憶體分布與生字速度的相對方向（具體數值依驅動、CUDA backend、模型版本、PCIe 版本變化、本表用於說明趨勢、不是嚴格 benchmark）：

事實查核註：上表是趨勢示意、不是經本文系統實測的數值。實際數值依顯卡型號、PCIe 版本、CUDA backend、GGUF 量化版本、-ngl 設定、context 長度與 batch size 變化、建議用 llama-bench 或實際工作流校準。

社群常見的觀察是：MoE 卸載對生字速度的衰減幅度、相對於「Dense 模型把同樣比例的層卸載到 CPU」較小、原因是 MoE 每 token 只啟用少數專家、PCIe 上的權重傳輸量也較少；具體幅度依模型架構（active parameter 比例、專家數）變化。

設計責任

理解 MoE 卸載後、可以解釋三個 PC 場景的現象：16GB VRAM 卡能載入 30B 級 MoE 模型（透過部分卸載而非全載 VRAM）、PC 場景 64GB RAM 相對 32GB 在 MoE 卸載空間上明顯更寬裕（可卸載更多層）、Mac 統一記憶體場景較少需要「卸載」這個概念（VRAM 跟 RAM 共用、不需要在兩個區域之間搬資料）。

設定 PC 推論伺服器時、卸載層數通常跟 KV cache 量化、context 長度、併發數一起調：先估算想開的 context 長度、扣掉 KV cache 體積算出 VRAM 餘量、再選卸載層數讓模型剛好放得進。詳見 5.0 VRAM + RAM 分層預算。

概念位置

MTEB 的 8 大任務類別：

對寫 code / RAG 場景最相關：Retrieval、Reranking 兩類（粗體）。其他類別反映通用能力、但不直接影響 RAG 應用品質。

主流 embedding model 在 MTEB Retrieval 的代表性能（2026/5 估計、會持續變動）：

事實查核註：MTEB 數字依模型版本、評估配置變動、上述為 2026/5 大致排名、引用前以 MTEB Leaderboard 當前狀態為準。

設計責任

讀 embedding model 比較看到「MTEB score」就是這 benchmark。寫 code / RAG 場景的判讀：

1. 看 Retrieval 子分數、不是 overall：MTEB overall 含 8 類、跟 RAG 場景關係最大的是 Retrieval 子分；通用 retrieval 分數高、reranking 分數高、就值得試
2. 跟自己 domain 對齊：MTEB 多為通用語料、自己 domain（如 code、medical、legal）可能跟 MTEB 落差大；in-domain benchmark 比 MTEB 更重要
3. 大小 / 速度 / 品質 trade-off：bge-large（335M）vs nomic-embed（137M）、後者跑得快、適合本地 RAG；前者品質略高、適合雲端或 latency 不敏感場景
4. MTEB 高分不代表「適合你」：高分模型可能是 instruction-tuned embedding（query 需要加特定前綴）、用法跟簡單模型不同、要看 model card

概念位置

MHA 的計算結構：

1輸入 hidden state（dim = 4096）
2   ↓ 投影成 Q/K/V、每個切成 h 個 head（如 h=32、每個 head 128 維）
3Head 1：Q_1、K_1、V_1 → attention_1（128 維）
4Head 2：Q_2、K_2、V_2 → attention_2
5...
6Head h：Q_h、K_h、V_h → attention_h
7   ↓ concat 所有 head 輸出（h × 128 = 4096）
8   ↓ output projection（4096 → 4096）
9最終輸出

多頭變體：MHA → GQA → MLA 是 KV cache 體積壓縮的演化方向。

設計責任

讀 model card 看到 num_attention_heads: 32、num_key_value_heads: 8 等就是 MHA / GQA 設定（Q=32、K/V=8 表示 GQA、g=4）。寫 code 場景的意涵：GQA / MLA 的 KV cache 體積小、長 context / 高併發場景更友善、是現代 LLM 大量採用的設計。

概念位置

三種 fusion 方式的對比：

1. Early Fusion（最主流）

1image → vision encoder → image tokens ─┐
2                                       ├→ concat 成單一 sequence → 同 LLM Transformer 處理
3text → tokenizer → text tokens ────────┘

• 特性：image token 跟 text token 在同一個 token sequence、共用 LLM 的 attention / FFN
• 代表：LLaVA、Qwen2-VL、Llama 3.2 Vision、Pixtral、GPT-4V 多數變體
• 優點：實作簡單、可重用 LLM 的 weight、訓練資料效率高
• 缺點：image token 佔 context、長對話 / 多圖時 context budget 吃緊

2. Cross-Attention（Flamingo-style）

1image → vision encoder → image features ─┐
2                                          │ Cross-attention 層
3text → tokenizer → tokens → LLM Transformer ──┤  插在每幾層 Transformer 之間
4                                          │ Image features 不進 LLM 主流
5output ←─────────────────────────────────┘

• 特性：image features 不變成 LLM 的 token、透過額外的 cross-attention 層注入
• 代表：Flamingo（DeepMind）、Idefics（Hugging Face）、部分 video LLM
• 優點：text token sequence 不會被 image 撐大、長文字 + 多圖比較友善
• 缺點：架構複雜、訓練難、推論伺服器支援度差

3. Native Multimodal（unified token space）

1image → patchify → discrete image tokens（如 VQ-VAE 編碼）
2text → tokenizer → text tokens
3
4兩者共用 vocab、同一個 Transformer 從頭訓
5（沒有「分開的 vision encoder」、modality 在 vocab level 統一）

• 特性：架構上「圖跟文字是同一種東西」、共用 vocab
• 代表：Chameleon（Meta 研究）、未來 trend
• 優點：理論最 clean、跨模態 generation 自然（生圖 + 生文都同個模型）
• 缺點：訓練極貴、目前研究階段為主、實用 VLM 仍以 early fusion 為主流

主流選擇對比

設計責任

讀 VLM paper / blog 看到「early fusion」「LLaVA-style」「Flamingo-style」「cross-attention adapter」就是這分類。寫 code 場景的判讀：

1. 本地跑 VLM 多半是 early fusion：選 Qwen2.5-VL / Llama 3.2 Vision / Gemma 3 Vision 都是這條路線、推論伺服器（llama.cpp、Ollama、LM Studio）都支援
2. Cross-attention 模型本地跑可能撞牆：推論伺服器對 Idefics 等 cross-attention 模型支援度差、不一定能跑 GGUF
3. 理解 fusion 影響 token 估算：early fusion 下「image token = 真的進 context」、cross-attention 下不算進 context window 主流
4. 未來 trend 是 unified：但現在做 production / 本地工作流不必等、用 early fusion 主流模型即可

概念位置

NIH 測試的典型流程：

 11. 準備 haystack：一份長文（如 Paul Graham essays、技術文件）
 22. 在指定位置（如 50% 處）插入 needle：
 3   「The best thing to do in San Francisco is eat a sandwich at Dolores Park.」
 43. Prompt 模型：「What is the best thing to do in San Francisco?」
 54. 看模型能否抓出 needle 內容
 6
 7Variables：
 8- Context 總長度（1K、4K、16K、64K、128K、1M）
 9- Needle 插入位置（0%、10%、25%、50%、75%、90%、100%）
10
11每個 (length, position) 組合測 N 次、得到 accuracy heatmap

跟 lost-in-the-middle 的對比：

 1典型 NIH heatmap（GPT-4 128K 之類）：
 2
 3100% |████ ████████████████████████████ ████
 4 80% |████ ████████████████████████████ ████
 5 60% |
 6 40% |
 7 20% |
 8   0 +----+----+----+----+----+----+----+
 9     0%   25%   50%   75%   100%（needle 位置）
10     ↑                                  ↑
11     開頭強                             結尾強
12
13NIH heatmap 通常全綠（強模型）、但實用任務（reasoning over long context）就會出現中段塌陷

設計責任

讀 long context 模型 release notes 看到「needle in a haystack: 100%」「pass NIH up to 128K」等聲稱、要區分：

1. NIH 100% 不代表「能用 128K context」：NIH 只測單一事實 retrieve、實際 reasoning over long context 仍可能崩
2. 真實任務 benchmark：LongBench、RULER 等是更貼近實用的 long context evaluation、會暴露 lost-in-the-middle 等問題
3. 本地跑 long context 模型：先用 NIH 驗證 baseline、再用 RULER / 自己工作流 case 測 effective context
4. 判讀「我的模型實際能用幾 K」：NIH pass 的長度是上限、實用 effective context 通常是 NIH pass 長度的 1/2 到 1/4

概念位置

NVLink 在多卡推論場景的角色：

1. tensor parallel：把一個 transformer 層的 weight 切到多張卡、每 token 計算時需要卡間同步、卡間頻寬影響直接。
2. pipeline parallel：把不同層分到不同卡、卡間需要傳 activation、頻寬要求中等。
3. 資料分發：把不同 request 分到不同卡（data parallel）、卡間流量低、PCIe 也夠。

頻寬對照（廠商標稱、依世代變化）：

NVLink 比 PCIe 高一個量級、是資料中心多卡推論的關鍵；消費級 RTX 場景多卡通常只能走 PCIe、縮放效益相對受限。

事實查核註：NVLink 各世代的頻寬數字依 NVIDIA 官方規格、不同 GPU 跟世代有差異；NVLink 在哪些消費級 / 工作站 / 資料中心 GPU 可用、依時段跟廠商策略變化、引用前以 NVIDIA 官方產品頁 跟對應 GPU 的 datasheet 為準。

設計責任

理解 NVLink 後可以解釋兩個現象：為什麼資料中心多卡 LLM 推論能線性 scale（NVLink 頻寬足以做 tensor parallel）、為什麼消費級雙卡 RTX 推論縮放比通常低於線性（沒 NVLink、走 PCIe x4 / x8、卡間頻寬限制）。

選消費級 GPU 跑本地 LLM 時、NVLink 不是常見選項；多卡升級的判讀應該基於「能否容忍縮放比低於線性」、而不是預期 NVLink 等級的卡間頻寬。詳見 5.6 GPU 廠商差異。

概念位置

2025 版的 10 項（簡述）：

跟模組六的 mapping

設計責任

讀企業 LLM 安全 / 合規文件 / vendor security audit 看到「OWASP LLM Top 10」就是這 framing。寫 code 場景的判讀：

1. 跟企業溝通必備：安全 team / vendor audit 都用 OWASP 編號、能 map 自己應用到 LLM01-LLM10 就能 align 對話
2. 不是 production 才需要看：個人 dev 也適用大部分（LLM01 prompt injection、LLM03 supply chain、LLM06 excessive agency 對個人都直接相關）
3. 跟 6.6 OWASP 對照章節 的關係：本卡是定義 + mapping、章節是詳細 mapping + 個人 dev 場景的對應 control

概念位置

PCIe 在本地 LLM 推論的兩個階段角色不同：

1. 模型載入階段：模型權重從 SSD → 系統 RAM → 走 PCIe → VRAM。PCIe 是常見瓶頸、影響「啟動時間」、不影響推論。
2. 推論階段：
   • 全載 VRAM 場景：權重已在 VRAM、推論時 PCIe 流量很少。
   • MoE 卸載場景：每 token 從系統 RAM 拉專家權重經 PCIe、PCIe 頻寬成為次要瓶頸。

PCIe 版本跟頻寬（廠商標稱、單向）：

實際傳輸吞吐受驅動、檔案系統、量化格式影響、通常低於規格上限。

事實查核註：PCIe 各版本的標稱頻寬數字以 PCI-SIG 官方規格為主、實際可達吞吐依硬體配置變化、引用前以對應版本的官方規格文件為準。

消費級主機板的 PCIe lane 分配常見「一條 x16 + 一條 x4」、加第二張 GPU 時、第二張的有效頻寬可能只有 x4、影響多卡縮放效益。詳見 5.3 llama.cpp 在 PC 上 的多卡 tensor split 段落。

設計責任

理解 PCIe 後可以解釋三個現象：為什麼模型載入要等幾秒到十幾秒（PCIe 是橋）、為什麼單卡 + MoE 卸載通常不卡 PCIe（每 token 拉的權重量小於 PCIe 頻寬）、為什麼雙卡縮放比沒有直接翻倍（PCIe lane 跟主機板配置）。

選 PC 配置時、PCIe 版本影響模型載入體感、但對單人推論的生字速度通常影響小。多卡升級前要看主機板的 PCIe lane 分配。

概念位置

Perplexity 跟 cross-entropy 的關係：

換算範例（base e）：

Perplexity 主要用於：

• 預訓練評估：在 held-out 語料上算 perplexity、衡量基礎建模能力。
• 量化品質衡量：fp16 vs Q4 vs Q3 模型的 perplexity 差異、看量化造成多少品質損失。
• 領域 benchmark：在特定領域語料（code、math、医學文獻）上算 perplexity、評估模型對該領域的熟悉度。

設計責任

Perplexity 是 base model 評估標準、但對 instruction-tuned / chat 模型用處有限（chat 模型輸出風格已偏離 raw text、perplexity 不一定降）。對寫 code 場景的判讀：看到 paper 報 perplexity 是評估 pretrain 品質的訊號、實際聊天 / coding 能力要看 SWE-bench、MMLU、HumanEval 等任務式 benchmark。

概念位置

完整的 server 入口由兩個欄位定義：

Port 是 16 bit 數字（0 ~ 65535）、其中 0 ~ 1023 是 well-known port（HTTP 80、HTTPS 443 等、需 root 權限才能 bind）、1024 ~ 65535 是 user port、本地 LLM 工具都用這個區間（Ollama 11434、LM Studio 1234、llama.cpp 8080）。同一個 port 在同一個 listen address 上同時只能被一個 process 持有、要兩個 Ollama 並存就要其中一個換 port。

三個常見 listen address 的語意：

可觀察訊號與例子

驗證 server 真的在聽預期地址：

1# macOS 下查誰佔了 11434
2lsof -i :11434
3# COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
4# ollama  1234 mac  6u IPv4 0xabcd      0t0 TCP localhost:11434 (LISTEN)

TCP localhost:11434 (LISTEN) 表示這個 process 只接 localhost 進來的封包。改 listen address 把 Ollama 暴露到 LAN：

1OLLAMA_HOST=0.0.0.0:11434 ollama serve
2# lsof 之後會看到 TCP *:11434 (LISTEN)、星號表示所有介面

curl 用不同 host 名稱呼叫同一個 server：

1curl http://localhost:11434/api/version    # 走 loopback、最快
2curl http://127.0.0.1:11434/api/version    # 跟上面等價
3curl http://<本機 LAN IP>:11434/api/version # 若 listen 在 0.0.0.0、會通；只 listen localhost 會 connection refused

「為什麼桌機跑 Ollama、筆電連不到」的最常見原因就是 Ollama 沒改 listen address、預設只接受 loopback。

設計責任

選 listen address 是信任邊界決定：

• 127.0.0.1（預設）：機器本身就是信任邊界、外部進不來、最安全
• 0.0.0.0 在家用 / 信任 LAN：把 server 暴露給同網路裝置、便於多裝置共用、風險可接受
• 0.0.0.0 在公共 Wi-Fi / 對 internet：等於對所有路過裝置開放、Ollama 沒有內建 auth、需要 SSH tunnel 或 reverse proxy + auth 才安全

Port 衝突的處理順序：用 lsof 確認佔用方身分 → 若是舊版自己 kill、若是別的服務改自己的 port → 同步更新 IDE plugin 的 apiBase。完整資料流判讀見 0.7 隱私資料流。

概念位置

Pre-training 在 LLM 訓練 pipeline 的位置：

1[網路文字 / 書籍 / code / 論文]（trillion token 級）
2   ↓ Pre-training（next-token prediction、cross-entropy loss）
3[Base model]：會接龍但不會對話
4   ↓ SFT（指令-回答對資料）
5[Instruction-tuned model]：會跟指令走
6   ↓ RLHF / DPO（人類偏好資料）
7[Aligned model]：對話風格 / 安全性對齊

Pre-training 的特性：

設計責任

理解 pre-training 後可以判讀幾件事：模型的「世界知識」絕大部分在 pre-training 時就決定了、SFT / RLHF 只是「教模型怎麼用這些知識回答」、不會大幅增加新知識；模型 cutoff date 就是 pre-training 資料的截止；想做新領域知識引入、RAG 比繼續 fine-tune 划算（pre-training 太貴、且 fine-tune 容易讓既有能力退化）。

概念位置

Prefix Cache 在推論流程中的角色：

1傳統推論：
2  Request A：system prompt + user A → 完整 prefill → 生成
3  Request B：system prompt + user B → 完整 prefill → 生成
4                                       ↑ 重複算 system prompt
5
6開啟 Prefix Cache：
7  Request A：system prompt + user A → prefill 整段、cache 共用 prefix
8  Request B：system prompt + user B → 重用 cache 的 system prefix + 只 prefill user B → 生成
9                                       ↑ 省下 system prompt 的 prefill 算力

效益對應的場景：

主流推論引擎的支援度（依版本變化）：vLLM、SGLang、llama.cpp 等都有 prefix cache 機制、命名各異。

事實查核註：prefix cache 的命名、設定方式、tenant 隔離預設行為依推論引擎跟版本差異大、引用前以對應引擎的官方文件為準（如 vLLM Automatic Prefix Caching、SGLang RadixAttention 等）。

設計責任

理解 prefix cache 後可以解釋兩個現象：為什麼 production LLM 服務的 latency 在啟用 prefix cache 後大幅下降（system prompt 不再每次重算）、為什麼 prefix cache 在多租戶場景是隱私風險（A 租戶的 prefix 可能被 B 看到、見 llm-multi-tenant-isolation）。

production 設計時、prefix cache 應該按 tenant 分桶、同 tenant 內可共用、跨 tenant 必須隔離。隔離邊界對齊 tenant-boundary 卡片的設計。

概念位置

跟既有 cache 概念的層次：

Prompt cache 的「保留範圍」跟「定價」是商業 LLM 的 product feature：

事實查核註：定價跟 TTL 隨時間更新、引用前以對應 vendor 當前文件為準。

設計責任

讀 LLM API docs / coding agent 設計 / cost optimization blog 看到「prompt cache」「context caching」「cache_control」就是這機制。寫 code 場景的判讀：

1. 誰最值得開：coding agent（system prompt + tool schema 經常 > 10K token、每 turn 重用）、long-context RAG（檢索 chunks 重用）、long conversation（history 累積）
2. 設計原則：把不變的內容（system prompt、tool schema、固定文件）放 prefix；變動的（user query、最新 file content）放後面
3. 常見 anti-pattern：在 prefix 插入 timestamp / user-id / request-id → 每次 prefix 不同 → cache 從不命中、付 1.25× write cost 沒得回本
4. 5 分鐘 TTL 的意涵：query 之間間隔 > 5 分鐘、cache 已 expire、要 1h ext TTL 才能撐長對話
5. 跟 context budget 的關係：cache 攤平 scaffold 部分的 cost、所以可以放寬「scaffold ≤ 25%」的成本顧慮、focus 在「不超 context limit」即可

概念位置

Prompt injection 的兩種主要形態：

Indirect injection 的常見入口：

1. 檔案內容：codebase 中的 README、依賴的 package README、PDF / Word 文件
2. Web 內容：tool 抓的網頁、社群留言、PR 描述
3. tool 回傳結果：DB 查詢結果、API response、其他 service 回傳
4. 使用者貼上內容：從外部複製貼上、帶進惡意 prompt
5. agent 自我循環中累積：sub-agent 回傳、長 agent loop 中前段 injection 影響後段

事實查核註：prompt injection 的攻擊形態跟研究進展快速演進、本卡描述參考 OWASP LLM Top 10 LLM01 跟 Greshake et al. 的「Indirect Prompt Injection」論文、引用前以對應的最新版本為準。

實際造成影響的不是 injection 本身、是 LLM 輸出後的下游動作：

1injection → LLM 輸出 → 下游動作（這裡才是真正攻擊面）
2                       ├── 使用者照建議貼到 shell 跑
3                       ├── tool use 自動執行
4                       ├── 寫進 commit / 文件
5                       └── 觸發下一個 agent

設計責任

理解 prompt injection 後可以解釋兩個現象：為什麼「擋住 injection」對 production LLM application 是不切實際的目標（外部內容會持續引入）、為什麼防禦重點應該放在「下游動作的可逆性 + review checkpoint」（injection 不可完全擋住、但後果可以收斂）。

防禦設計的層次：

1. 降低觸發率：明確標記 untrusted 內容、強化模型對齊（vendor 端責任）。
2. 限制能力上限：tool use 白名單、副作用可逆性、agent loop 步數限制。
3. 後果可控：人為 review checkpoint、自動偵測異常（見 LLM Service 偵測訊號覆蓋）。

詳見 6.3 IDE 場景的 prompt injection 跟 LLM Agent Prompt Injection 後果治理。

概念位置

QLoRA vs full fine-tuning vs LoRA 的記憶體需求對比（70B 模型）：

QLoRA 的核心創新（簡化）：

1. 4-bit NormalFloat（NF4）量化：base model 用 4-bit 表示、精度損失低於原 INT4
2. Double quantization：量化常數本身也量化、再省一點記憶體
3. Paged optimizer：optimizer state 跑 CPU offload、避免訓練 spike OOM
4. LoRA on 4-bit base：LoRA 訓的 A、B 矩陣仍是 BF16、只有 base 是 4-bit、推論時 dequantize → 加 LoRA → forward

設計責任

讀 fine-tuning 教學 / Hugging Face PEFT 文件看到「QLoRA」「bnb-4bit」就是這方法。寫 code 場景的判讀：

1. 想 fine-tune 大模型在消費級硬體：QLoRA 是 default 選擇（不用 QLoRA、就只能訓 < 7B）
2. 記憶體預算估算：QLoRA 訓 N B 模型約需 0.6 × N GB VRAM（30B → ~18GB、70B → ~42GB）
3. 品質 vs full fine-tune 差距：QLoRA 後合併權重的模型、實測跟 full fine-tune 接近（差距 < 2-3%）、對多數場景可接受
4. 跟 LoRA 卡片區分：純 LoRA 是「base 不量化、訓 LoRA」、QLoRA 是「base 量化 4-bit、訓 LoRA」；QLoRA 是 LoRA 的延伸、不是替代
5. 推論時的選擇：QLoRA fine-tuned 模型可以「base 仍 4-bit + 載入 LoRA adapter」推論、記憶體用量低；也可以 merge 後用 GGUF Q4_K_M、跟 base 原相同

概念位置

Reasoning model 跟一般 instruction-tuned model 的差異：

主流 reasoning model 比較（2026/5）：

設計責任

讀 model card / paper 看到「reasoning」「thinking」「test-time compute」「R1-style」就是這個 family。寫 code 場景的判讀：

1. 本地用 distill 版本是合理起點：DeepSeek-R1-Distill-Qwen-32B、QwQ-32B 等是「正常 32B 模型 + reasoning 後訓練」的產物、跑得起來
2. 適合的任務：debug 複雜 bug、算 algorithm complexity、設計 multi-step refactor、解 leetcode hard
3. 不適合的任務：autocomplete（reasoning trace 拉長 TTFT、體感變慢）、簡單 docstring 補完、純文字翻譯
4. 混用策略：日常用 instruction-tuned model（如 Gemma 4 31B、Qwen3-Coder）+ 複雜任務切到本地 reasoning model（如 QwQ-32B）+ 真正困難任務切雲端 o1 / R1 full
5. 記憶體預算：reasoning model 本身大小跟對應 instruct model 相當、但要預留更大 KV cache 給長 reasoning trace（context 通常開 32K+）

概念位置

Refusal 行為的典型形態：

Refusal rate 作為偵測訊號的兩個方向：

1. 率突然下降：可能是對齊被繞過、prompt injection 攻擊在進行、或新版本模型對齊變弱。
2. 率突然上升：可能是訓練資料或對齊政策變嚴、影響使用者體驗、或 vendor 端政策調整。

實作上、偵測 refusal 通常用簡單 pattern matching（看是否含 “I can’t” / “I’m not able” / “Sorry” 等）或更精確的 classifier；具體實作依 偵測平台 設計。

事實查核註：refusal rate 的標準化測量方式、跟「對齊強度」的對應關係仍在研究演進、不同 vendor 跟 model 的 baseline 差異大、引用前以對應模型的 model card 跟最新研究為準。

設計責任

理解 refusal rate 後可以解釋兩個現象：為什麼 production LLM 服務監控 refusal rate（變化是異常訊號）、為什麼開源模型的 refusal rate 通常低於商業旗艦（前者 safety RLHF 投入較少）。

production 設計時、refusal rate 是 content 層偵測訊號之一、需配合 tool call 序列、token usage、prompt pattern 等其他訊號才能形成完整偵測覆蓋。詳見 LLM Service 偵測訊號覆蓋。

概念位置

Bi-encoder vs cross-encoder 的差別：

1Bi-encoder（embedding model、retrieval 第一階段）：
2  query → embedding A
3  document → embedding B（pre-compute、存 vector DB）
4  score = cosine(A, B)
5  → 快、可 pre-compute、適合海量 retrieval
6
7Cross-encoder（reranker、retrieval 第二階段）：
8  (query, document) 一起進模型 → 直接輸出 relevance score
9  → 慢（每對都要 forward pass）、不可 pre-compute、適合 top-K rerank

主流 reranker：

設計責任

讀 RAG / production retrieval docs 看到「reranker」「cross-encoder」「rerank stage」就是這 framing。寫 code 場景的判讀：

1. 何時值得加 reranker：retrieval 結果有「相關但不精確」問題、top-K hit rate 高但 top-5 hit rate 低、有 latency / cost budget
2. 何時不需要：小語料（< 1000 docs、retrieval 已準）、明確 keyword 任務（BM25 已準）、latency 敏感（< 100ms TTFT）
3. Pipeline 設計：bi-encoder retrieve top-50 → reranker rerank → 給 LLM top-5；50/5 是常見起點、看實測調
4. 跟 hybrid search 結合：BM25 + embedding hybrid retrieve top-50 → reranker rerank → LLM、是 production RAG 標配
5. 跟 4.1 RAG 章節 的關係：本卡是定義、章節是 retrieval pipeline 設計（含 reranker / hybrid 段）

概念位置

Residual connection 在 Transformer block 中出現兩次：

 1Transformer block：
 2  x
 3  ├──────────────┐  ← skip connection（保留原始 x）
 4  ↓              │
 5  LayerNorm      │
 6  ↓              │
 7  Self-Attention │
 8  ↓              │
 9  +←─────────────┘  ← residual add：attention output + x
10  │
11  ├──────────────┐  ← skip connection（保留 attention 後的值）
12  ↓              │
13  LayerNorm      │
14  ↓              │
15  FFN            │
16  ↓              │
17  +←─────────────┘  ← residual add：FFN output + previous
18  ↓
19  進入下一個 block

關鍵性質：

1. Gradient 可以走捷徑：Backpropagation 時、gradient 能透過 skip connection 直接傳回淺層、避免 chain rule 累積衰減。
2. Layer 學「殘差」而不是「完整轉換」：每層學「該怎麼微調輸入」、不用學「從零生成輸出」、優化更容易。
3. 跟 LayerNorm 配對：兩者一起是深層 Transformer 訓得起來的基礎。

設計責任

理解 residual connection 後可以判讀 Transformer 能堆幾十層的根本原因（不是因為 attention、是因為 residual + LayerNorm 讓深層仍可訓練）；也能看懂 ResNet、ViT 等其他用 residual 架構的設計。LLM 推論時 residual 不算 bottleneck、但在訓練 / fine-tune 時、residual 是 gradient flow 健康度的關鍵。

概念位置

RLHF 在訓練流程的位置與步驟：

 1[SFT 後的模型]
 2   ↓
 3Step 1：收集人類偏好
 4  對同個 prompt 讓模型生 A、B 兩個 response、人類標「我較喜歡 A」
 5   ↓
 6Step 2：訓 reward model
 7  輸入 (prompt, response)、輸出一個分數
 8  目標：人類偏好的 response 分數高
 9   ↓
10Step 3：用 PPO 等 RL 演算法 fine-tune LLM
11  讓模型輸出讓 reward model 給高分的 response
12  加 [KL constraint](/llm/knowledge-cards/kl-divergence/)：不能偏離 SFT model 太遠
13   ↓
14[Aligned model]：回答更貼近人類偏好

關鍵特性與挑戰：

1. 三個模型同時運作：policy（LLM）、reward model、reference model（SFT 後 frozen 那份）、訓練時記憶體吃緊。
2. Reward hacking：模型可能找到 reward model 的弱點、生成「reward 高但實質爛」的輸出（如冗長 boilerplate）。
3. 訓練不穩：PPO 對 hyperparameter 敏感、需要小心調 β（KL 約束強度）、learning rate 等。

設計責任

RLHF 是 ChatGPT / Claude / Gemini 等商業 LLM 對話品質的核心。讀 model card 看到「RLHF-tuned」「helpfulness fine-tuning」就是這個階段。DPO 是 2023 年後出現的簡化替代方案、跳過 reward model、直接用偏好資料 fine-tune、訓練流程簡單很多、是現代許多開源模型的主流選擇。

概念位置

位置編碼的演化路線：

RoPE 的核心數學（簡化）：

1傳統：token at position m 的 Q 是 Q_m = x_m @ W_Q
2RoPE：Q_m = R(m) × (x_m @ W_Q)  ← R(m) 是依位置 m 決定的旋轉矩陣
3
4attention score = Q_m @ K_n^T
5               = R(m) × q × (R(n) × k)^T
6               = q × R(m - n) × k^T  ← 只依賴相對位置 (m-n)！

關鍵性質：RoPE 算出的 attention score 只依賴相對位置、所以推廣到比訓練長度更長的 context 時有自然的數學基礎、配合 RoPE scaling（YaRN、NTK-aware、Position Interpolation）就能把 8K 訓練的模型擴展到 128K / 1M context。

設計責任

讀 model card 看到 rope_theta: 10000、rope_scaling: {type: yarn, factor: 8} 等就是 RoPE 配置。寫 code 場景的意涵：long context 模型（如 Llama 3 128K）的推廣能力主要靠 RoPE + scaling、不是直接訓練 128K 全長；但聲稱 context 跟「實用 context」仍有差距、長 context 上模型表現會逐步衰減。

概念位置

常見的 sandbox 技術光譜（依隔離強度跟工程成本）：

Sandbox 在 LLM 場景的常見配置：

1. 個人 dev：用獨立 OS user 跑 MCP server、限制檔案存取到 workspace；或用 Docker。
2. production agent：每個 user / session 一個 ephemeral container、跑完就 destroy。
3. code execution tool：把 LLM 生成的 code 丟進 sandbox 跑（如 OpenAI Code Interpreter、Anthropic Claude Code Tool）。

設計責任

理解 sandbox 後可以解釋兩個現象：為什麼跑第三方 MCP server 前 sandbox 是基本配置（MCP 是可執行程式碼、權限上限是「跑該 server 的 user 的權限」）、為什麼 production 場景的 code execution tool 必定在 ephemeral sandbox 內跑（避免長期 state 跟跨 user 殘留）。

設計 LLM application 時、sandbox 跟 tool use 的白名單是兩個獨立的防護層、建議都做：白名單擋已知範圍、sandbox 擋未預期的副作用。詳見 6.2 tool use 與 MCP server 的權限模型。

概念位置

兩層的職責劃分：

 1Scaffold（建構時、static）：
 2  ├── System prompt 模板（角色、約束、輸出格式）
 3  ├── Tool schema 註冊（read_file / write_file / run_bash 等的 spec）
 4  ├── Subagent 拓樸（main agent + 子 agent 的調用關係）
 5  ├── Skill / playbook 註冊
 6  └── 安全 policy（什麼可寫、什麼要 confirm）
 7
 8   ↓ 編譯 / 載入
 9
10Harness（runtime、dynamic）：
11  ├── Tool dispatch（接 LLM tool call、執行、回 result）
12  ├── Context budget 管理（剪裁歷史、塞新內容、不超 25% 規則）
13  ├── Safety / 中斷（confirm UI、permission boundary、可逆性檢查）
14  ├── Error recovery（tool failed → retry / fallback / escalate）
15  └── Telemetry（trace / metrics / cost）

跟既有概念的關係：

設計責任

讀 coding agent paper / blog 看到「scaffold」「harness」「context engineering」就是這 framing。寫 code 場景的判讀：

1. 看新 coding agent 時、分兩層拆解：scaffold（system prompt、tool list、subagent 結構）是「設計做了什麼」、harness（context 怎麼裁、tool 怎麼 dispatch、安全怎麼擋）是「runtime 怎麼跑」
2. 修改 / 客製 agent 時、看你動的是哪層：改 system prompt = 動 scaffold；改 tool 執行邏輯 = 動 harness
3. 跟 4.17 coding-agent harness 的關係：本卡是定義、4.12 是 coding 場景的工程實務（context budget、scaffold 模式、harness pattern）

概念位置

Self-attention 的計算步驟：

 1輸入 sequence: x_1, x_2, ..., x_n（每個是向量）
 2
 3對每個 token i：
 4  Q_i = x_i × W_Q   ← Query：「我要找什麼樣的資訊」
 5  K_i = x_i × W_K   ← Key：「我提供什麼樣的資訊」
 6  V_i = x_i × W_V   ← Value：「我的實際內容」
 7
 8attention(Q_i, K, V) = softmax(Q_i · K^T / √d) · V
 9                       └─ Q 跟所有 K 算分數、決定權重 ─┘
10                                                       └─ 加權平均所有 V ─┘

關鍵特性：

1. Q / K / V 來源相同：跟 cross-attention 區分；都從同一個輸入 sequence 投影。
2. 每個 token 都跟所有 token 算一次：複雜度 O(n²)、是 long context 痛點根源。
3. Causal mask 在 self-attention 內生效：LLM 的 decoder-only self-attention 加 causal mask、token i 只能看 1~i、不能看 i+1 以後（不能偷看未來）。

設計責任

理解 self-attention 後可以判讀幾件 LLM 設計事：KV cache 為什麼有效（自回歸生成時、過去 token 的 K/V 不變、存下來下次直接用）；MHA / GQA / MLA 等變體在動什麼（共享 / 壓縮 K/V 投影、不動 Q）；為什麼長 context 推論慢（self-attention 的 O(n²) 計算）。

概念位置

SentencePiece 跟其他 tokenization 路線的對比：

關鍵特性：

1. ▁ 表示空白：SentencePiece 把空白編碼成 ▁（Unicode U+2581）、所以「Hello world」會被 tokenize 成 ["Hello", "▁world"]、保留空白資訊在 token 內。
2. 不依賴語言預處理：傳統 NLP 要先做 lowercasing、word segmentation；SentencePiece 直接從 raw bytes 開始學、跨語言通用。
3. 原生 multilingual：訓練 corpus 包含多語言時、tokenizer 自動學會跨語言的子詞單元、不需要為每種語言設定不同 tokenizer。

設計責任

讀 model card / repo 看到 tokenizer.model 檔案（不是 tokenizer.json 或 vocab.txt）就是 SentencePiece 用的 protobuf 格式。寫 code 場景的意涵：SentencePiece tokenizer 在中文 / 多語言任務上比 WordPiece 友好；換 tokenizer 等於整個 embedding layer 失效、所以 fine-tune 時不會動 tokenizer。

概念位置

SFT 在訓練 pipeline 的位置與資料形態：

1資料格式（典型）：
2  {"instruction": "寫一個 Python fibonacci",
3   "response":    "def fib(n): ..."}
4
5訓練：
6  把 instruction + response 連起來、跑跟 pre-training 一樣的 next-token prediction
7  但 loss 只算 response token 上的 cross-entropy（instruction 部分不算）

SFT 後同一個模型行為大改：

關鍵特性：

1. 資料量遠小於 pre-training：幾萬到幾百萬筆指令-回答對、相對 pre-training 的兆級 token 是小數字。
2. 訓練成本相對低：通常幾百到幾千 GPU-hour、可在單機完成。
3. 容易過擬合 / 災難遺忘：SFT 資料太少 / 太特化時、模型可能丟掉 pre-training 學到的能力、見 LoRA 的設計動機。

設計責任

讀 model card 看到「instruct」「chat」「-it」「sft」等 suffix、就是經過 SFT 的版本。寫 code 場景用的模型幾乎都是 SFT 後的（base model 對話能力差、實用度低）。Coding-tuned 模型（如 Qwen3-Coder）是 SFT 階段大量加入 code 對話資料的特化版本、跟通用 instruct 模型在 code 任務上有可觀差距。

概念位置

SGD 的更新公式：

1W_new = W_old - learning_rate × gradient_of_loss_on_minibatch

跟其他 optimizer 的對比：

LLM 訓練幾乎都用 Adam / AdamW、不是純 SGD。但 SGD 仍出現在：

1. 小模型 / 簡單任務：fine-tune 小 vision 模型、SGD + momentum 仍是合理選擇。
2. 理論分析 / 教學：SGD 是最簡單的 optimizer、用來解釋 gradient descent 概念。
3. 某些 fine-tuning 場景：LoRA 或 SFT 偶爾用 SGD（避免 Adam 改變 base model 太多）。

設計責任

讀 paper / training script 看到 optimizer 選擇、SGD 是基線、其他 optimizer 通常是「對 SGD 的改進」。寫 code 場景的判讀：訓練自己的小模型可以從 SGD + momentum 開始；fine-tune 大 LLM 沒理由不用 AdamW。

概念位置

Shell（zsh / bash）執行一個程式時、預設讓程式佔住 terminal、stdin / stdout / stderr 直接連到使用者眼前的視窗、稱為前景 process。指令尾巴加 & 改成背景 process、shell 立刻拿回 prompt 控制權、程式繼續跑但不佔住 terminal。背景 process 仍綁在當前 shell session、關掉 terminal 視窗時通常會被 SIGHUP 終止；要完全脫離 shell 生命週期、得改用 launchd service 或 nohup / disown 等機制。

可觀察訊號與例子

shell 控制 process 的關鍵操作：

排錯常用的兩個工具（兩者跟 shell job 不直接相關、是 macOS 系統工具）：

對 macOS 新手最常遇到的兩個事故：一個是「前景跑 server 後不知道怎麼脫身」、解法是 Ctrl+Z 暫停 + bg 改背景、或下次改用 & 啟動；另一個是「pkill 沒指定夠精確的 pattern、誤殺其他 process」、解法是先用 ps aux 加 grep 確認 PID 再 kill。

設計責任

選前景 vs 背景的判讀：debug 場景前景跑、能直接看到 log；日常使用改 launchd service 跑、跟 shell session 完全脫鉤。& 適合「terminal 開著就讓它跑、關掉也沒關係」的臨時場景、不適合需要長期穩定的服務。排錯時養成「先 lsof 找誰佔資源、再 ps 確認身分、最後才 kill」的順序、避免誤殺。

概念位置

LLM 中 softmax 出現的兩個位置：

1位置 1：Attention 內部
2  Q · K^T → 一堆 score
3  softmax(scores) → attention weight（總和 1）
4  weight · V → output
5
6位置 2：每次 token 生成的最後一步
7  最後一層 hidden → logit（每個 vocab token 一個實數分數）
8  softmax(logits / temperature) → 機率分佈
9  從這個分佈 sample 出下一個 token

兩個位置的關鍵差異：

Temperature 在 sampling 端跟 softmax 結合：softmax(logits / T)、T 越小分佈越尖（接近 greedy）、T 越大分佈越平（接近隨機）。

設計責任

理解 softmax 後可以判讀幾件事：temperature 為什麼影響輸出多樣性（改的是 softmax 前的縮放）、為什麼 logit bias / logit warping 等技巧能控制輸出（直接動 softmax 的輸入）、為什麼 structured output 的 grammar-constrained sampling 是「把不合法 token 的機率歸零」（在 softmax 後或前做 masking）。

概念位置

LLM 中 special tokens 的常見類型：

關鍵特性：

1. 訓練時用特殊 token ID 標記：模型透過大量範例學會「看到 <\|user\|> 後面是使用者輸入、看到 <\|assistant\|> 後面要生成回答」。
2. Chat template 把這些組合起來：把使用者輸入 + 系統 prompt + 對話歷史依特定格式插入這些 token、組成模型訓練時看過的格式。
3. <eos> 的 sampling 行為：模型輸出 <eos> 後、推論伺服器停止生成、所以「為什麼回答突然停了」很多時候就是模型決定發 EOS。

設計責任

讀 tokenizer config（tokenizer_config.json）看到 bos_token、eos_token、chat_template 等就是這組設定。寫 code 場景的判讀：用 Continue.dev / Ollama 時、伺服器會自動套用模型的 chat template、把使用者輸入轉成正確的 special tokens 格式；自己寫 inference code 時、要呼叫 tokenizer.apply_chat_template() 避免格式錯亂導致模型輸出爛。

概念位置

Single agent vs subagent 架構的對比：

 1Single agent（無 subagent）：
 2  Main agent context：
 3    [system prompt + tool schema + 跨所有 specialty 的 history + 所有 file content]
 4    ↓ 容易爆 context、specialty 互相干擾
 5
 6Subagent 架構：
 7  Main agent context（路由 + 高階決策）：
 8    [main system prompt + handoff tool spec + 高階任務歷史]
 9       ↓ 路由到 subagent
10
11  Subagent A context（如「跑測試」專家）：
12    [test-runner system prompt + 測試 tool + 測試相關 file]
13
14  Subagent B context（如「寫 docs」專家）：
15    [docs system prompt + 寫 docs tool + 相關 docs 檔案]

主要好處：

1. Context budget 隔離：每個 subagent 只看自己 specialty 相關 context、不被別的 specialty 污染
2. System prompt 專門化：寫 docs 的 system prompt 跟跑測試的 system prompt 不同、各自最佳化
3. Specialty 路由：main agent 只決定「這個任務該交給哪個 subagent」、不直接做 specialty 工作

主要挑戰：

1. Handoff 設計：main agent 要怎麼選 subagent、怎麼傳 context、怎麼接 result
2. 跨 subagent 共享狀態：codebase 知識、history、要避免重複 work
3. 失敗模式：subagent 之間互相 deadlock、main agent 失去 high-level view、subagent 邊界劃錯

設計責任

讀 multi-agent / subagent paper / coding agent docs 看到「subagent」「handoff」「Task tool」「specialist agent」就是這 framing。寫 code 場景的判讀：

1. 何時用 subagent：單一 agent context 不夠用、specialty 邊界清楚（如 search / coding / testing / documentation）、main agent 的 system prompt 已太長
2. 何時不用：任務簡單、specialty 邊界模糊（強行拆會增加 handoff overhead）、本地小模型（handoff 機制對小模型不穩）
3. 跟 agent loop 的關係：每個 subagent 內部仍是 agent loop（perceive / reason / act / observe / terminate）、只是 loop 範圍縮窄
4. 跟 scaffold vs harness 的關係：subagent 註冊在 scaffold（建構時）、handoff 在 harness（runtime）執行

概念位置

LLM API call 的訊息結構：

1messages = [
2  {role: "system", content: "你是專業 code reviewer..."},  ← system prompt
3  {role: "user",   content: "請 review 這段 code: ..."},
4  {role: "assistant", content: "..."},  ← 模型回答
5  {role: "user",   content: "..."},     ← 後續對話
6  ...
7]

System prompt 在 application 設計中的角色：

事實查核註：不同 LLM vendor 對 system prompt 的處理機制不同（如部分模型把 system 跟 user 視為相同優先級、部分模型有特殊訓練讓 system 較高優先）、具體行為以該模型的官方文件為準。

設計責任

理解 system prompt 後可以解釋兩個現象：為什麼同一個模型在不同 LLM 應用中的「個性」差很多（system prompt 不同）、為什麼 prompt injection 的主要目標是繞過 system prompt 的約束（攻擊者想讓模型不照原本指令走）。

實務上、設計 LLM application 時、system prompt 是行為約束的第一層、但不是唯一防線（容易被 injection 繞過）；critical 行為應該在 application 層（如 tool call 的權限白名單、輸出驗證）加第二層防護。詳見 6.3 IDE 場景的 prompt injection。

概念位置

LLM 中常見的 tensor 維度：

關鍵運算：

1. Reshape：改 shape 但不變資料總量、如 (batch, seq, hidden) → (batch * seq, hidden)。
2. Transpose / permute：交換維度順序、attention 計算前後常用。
3. Broadcasting：不同 shape 的 tensor 自動擴展配對、如 (seq, hidden) + (hidden,)。
4. Indexing / slicing：抽出子 tensor、如 tensor[:, -1, :] 取最後一個 token 的 hidden。

設計責任

讀 PyTorch / MLX 推論 / 訓練 code 看到 torch.Tensor、mx.array、tf.Tensor 等就是這個型別、所有 LLM 運算都建在它上面。寫 code 場景的判讀：報錯訊息看到 shape mismatch / size of dimension X 通常是 tensor 維度配錯；KV cache 內部存的就是 4D tensor (num_layers, 2, batch, num_kv_heads, seq, head_dim) 之類的結構、量化 KV cache 就是改這個 tensor 的 dtype。

概念位置

LLM 算力分配的兩條軸：

 1Training compute（訓練算力）：
 2  pre-training 大量 GPU-hour → 模型參數
 3  一次性投入、後續推論不變
 4  → GPT-3 → 4 的主要 paradigm
 5
 6Test-time compute（推論算力）：
 7  每次推論時、視任務難度動態增加算力
 8  難題想 30 秒（生 5000 token reasoning trace）
 9  簡單問題 1 秒結束（直接答）
10  → o1 / R1 / Claude thinking 的新 paradigm

Test-time compute 的常見實作形式：

DeepSeek-R1 paper 顯示「reasoning trace 長度跟 benchmark 表現正相關、可透過 RL 拉長」— 把 test-time compute 變成可訓練、可 scale 的維度。

設計責任

讀 paper / benchmark 看到「pass@1 vs pass@10」「budget tokens」「thinking time」等就跟 test-time compute 相關。寫 code 場景的判讀：

1. Reasoning model 算成本翻倍：同一個 prompt、reasoning model 生 5000 token thinking + 500 token answer、傳統 model 直接生 500 token answer、推論成本差 ~10 倍
2. 本地跑 reasoning model 的痛點：需要長 context window 容納 thinking trace、生成時間長
3. 適用任務挑選：複雜 reasoning（math、debug、long horizon planning）值得花 test-time compute；簡單任務（autocomplete、查詢）不值得
4. 混用策略：日常用 instruct model、困難任務切到 reasoning model、是個人 dev 常見模式

概念位置

Tool use 的典型流程：

11. 開發者定義 tools（每個 tool 含 name、description、parameters schema）
22. LLM 收到 user message 跟 tools 清單
33. LLM 決定要呼叫哪個 tool、生成結構化 tool call（JSON）
44. LLM client（不是模型本身）執行 tool call、得到結果
55. tool 結果回灌進 conversation、模型基於結果繼續生成或再呼叫

關鍵特性：

1. 模型本身不執行 tool：模型只生成 tool call JSON、實際執行由 client 或 MCP server 完成。
2. 權限由 OS / user / sandbox 決定：模型再「同意」執行 rm -rf /、實際能不能跑取決於跑 tool 的 process 權限。
3. 副作用範圍跟 tool 設計強相關：tool 寫得越通用（如 run_shell）、攻擊面越大；tool 寫得越窄（如 read_workspace_file）、攻擊面越小。

Tool use 跟 function calling、MCP 的關係：

設計責任

理解 tool use 後可以解釋三個現象：為什麼 LLM 「能跑 shell」其實是 client 跑、不是模型跑（職責切分）、為什麼 tool spec 設計直接影響攻擊面（spec 越鬆、injection 後果越大）、為什麼 agent loop 比單次 tool call 危險（多步 tool use 中 injection 累積）。

設計 tool 跟 MCP server 時、權限白名單 + 副作用可逆性 + confirm 機制是基本配置；production 場景見 LLM Agent Prompt Injection 後果治理 跟 6.2 tool use 與 MCP server 的權限模型。