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

卡片分類

模型輸出機制

模型權重與量化

推論加速技巧

推論基礎建設

macOS 與 shell 基礎

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

硬體與架構

線性代數基礎

LLM 機率與資訊論

LLM 訓練流程

Reasoning Models

Vision / 多模態

Deployment / 靜態場景

Coding Agent 工程

Production / Observability

Retrieval 進階

Constrained / Structured Output

安全 / 合規

Tokenization

Sampling 策略

推論加速進階

評估指標 / Benchmark

應用層模式

Prompt 技術

設計典範 / 人機協作

模型行為與安全

Production 推論

卡片寫法

每張卡片維持四段：

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

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

卡片與章節的關係

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

概念位置

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，失敗模式會被隱藏。

來源：Stanford CS230 Deep Learning、講題 “Beyond LLM: Enhancing Large Language Model Applications”。

整理原則：保留講者英文原文以避免翻譯失真、移除口語贅詞、用文章結構重新組織。標題與導讀用 zh-Hant。

講座定位

We started with neurons, then layers, then deep networks, then how to structure projects in C3. This lecture goes one level beyond: what would it look like if you were building agentic AI systems at work, in a startup, in a company?

The goal is not to build an end-to-end product in the next hour, but to give you the breadth of techniques that AI engineers have figured out — and are still exploring — so that after class you have the baggage to dive deeper and learn faster.

Agenda:

1. Challenges and opportunities for augmenting LLMs
2. Prompt engineering
3. Fine-tuning (and why to mostly avoid it)
4. Retrieval-Augmented Generation (RAG)
5. Agentic AI workflows
6. Case study with evals
7. Multi-agent workflows
8. What’s next in AI

1. Why augment LLMs?

Limitations that show up when you use a vanilla pre-trained model:

• Lacks domain knowledge — e.g. a student project building an autonomous farming device with a camera that classifies sick crops. That data set isn’t out there; a pre-trained vision model lacks that knowledge.
• Real-world distribution shift — the model was trained on high-quality data, but data in the wild is much messier.
• Lacks current information — retraining from scratch every few months is impractical. Example: during Trump’s first presidency he tweeted “Covfefe.” The word didn’t exist; Twitter’s LLMs couldn’t recognize it, recommender systems went wild. New trends and slang (rizz, mid, etc.) appear constantly and you can’t keep retraining.
• Trained for breadth, not depth — fine on a wide range of tasks, but may not be precise enough for narrow, well-defined enterprise applications with high precision / low latency requirements.
• Carries unnecessary weight — a massive model where you only use 2% of capability is slow and expensive. Pruning, quantization, and modification are options.

LLMs are hard to control

In 2016 Microsoft launched a Twitter bot that learned from users and quickly became a racist jerk. They removed it 16 hours after launch. Even better-funded teams struggle: there’s an ongoing debate (Elon Musk vs Sam Altman) on whose LLM is the “propaganda machine.” If you hang out on X you’ll see screenshots of LLMs saying controversial things. Even the best-funded labs don’t do a great job of controlling their LLMs.

LLMs may underperform on your task

• Specific knowledge gaps (e.g. medical diagnosis)
• Missing sources — research, education, legal all require sourcing
• Inconsistencies in style / format (e.g. legal contracts where every word counts)
• Task-specific understanding — example: a biotech company categorizing reviews as positive / neutral / negative. What counts as “negative” in that industry may differ from a generic LLM’s notion. You need to align the LLM to your task.

Limited context handling

A lot of enterprise applications need large context. Example: an LLM running on top of your entire drive that can answer “what was our Q4 sales performance?” in one shot. In practice the context window is limited (best models today max out around hundreds of thousands of tokens; 200K ≈ two books). For video or large data, you have to chunk and embed.

The attention mechanism doesn’t attend well over very large contexts. The needle-in-a-haystack benchmark tests this: insert a single sentence (“Arun and Max are having coffee at Blue Bottle”) in the middle of a very long text like the Bible, then ask “what were Arun and Max having?” It’s complex not because the question is hard but because the model must find a fact within a huge corpus.

The RAG debate

In theory, with infinite compute, RAG is useless — you could just read a massive corpus immediately and answer. But even then, latency matters; imagine the LLM reading your entire drive on every question. RAG also has other advantages: accuracy, sourcing.

Analogy to search: when you search, you still find sources. There’s detailed traversal that ranks and finds specific links. Without that, you’d be reading the entire web every query — not reasonable. So RAG-like approaches likely stay relevant.

2. Two dimensions of optimization

Two axes when improving LLM-based products:

1. Foundation model axis — move from GPT-3.5 Turbo → GPT-4 → GPT-4o → GPT-5. Each step (in theory) improves base performance.
2. Engineering axis — keep the same base model, but engineer how you leverage it: better prompts, RAG, agentic workflow, multi-agent system.

This lecture is about the vertical axis: which LLM are you using, and how do you maximize its performance?

3. Prompt engineering

The BCG / HBS / UPenn / Wharton study

Three groups of BCG consultants:

1. No AI access
2. GPT-4 access
3. GPT-4 + training on how to prompt

Two interesting findings:

The jagged frontier: some tasks fall within the frontier where AI clearly helps; others fall outside, where AI actually makes performance worse. Many tasks fell within, many fell outside. Researchers also observed “falling asleep at the wheel” — relying on AI for a task beyond the frontier, and not reviewing outputs carefully.

Centaurs vs cyborgs: two working modes.

• Centaurs divide and delegate — give a big task to the AI, let it work, come back later. (Half human / half horse: clear delegation.)
• Cyborgs fully blend with AI — fast back-and-forth, augmented. Students often work like cyborgs; in the enterprise, when you automate a workflow, you’re thinking like a centaur.

The trained group did best. Prompt engineering is a skill everyone should have — not a job title to build a career on, but a powerful skill in your career.

Basic prompt design principles

A weak prompt:

Summarize this document. {document}

The model has no context on length, audience, focus. Better:

Summarize this 10-page scientific paper on renewable energy in five bullet points, focusing on key findings and implications for policymakers.

Common techniques to make it even better:

• Give an example of a great summary
• Role prompting: “Act as a renewable energy expert giving a conference at Davos”
• Praise: “You are the best in the world at this”
• Reflection / self-critique: ask the model to critique its own output and revise
• Chain of thought: break the task into explicit steps, “think step by step, do not skip any step.” Step 1 identify the three most important findings; Step 2 explain impact; Step 3 write the five-bullet summary.

Andrew Ng recommends looking at other people’s prompts. Repos like “awesome prompt template” on GitHub have many examples engineers have built. Many start with “Act as a Linux terminal”, “Act as an English translator”, “Act as a position interviewer”, etc.

Prompt templates

The advantage of a template is you can put it in your code and scale across many user requests. Example from Workera: the HR system has “Jane is a Product Manager Level 3, US, preferred language English.” That metadata gets inserted into a prompt template that personalizes for Jane. Same template, different metadata for Joe (preferred language Spanish).

Foundation models likely use system prompts you don’t see — e.g. ChatGPT may inject “Act like a helpful assistant” plus user memories from a database before your prompt. That doesn’t stop you from adding your own template on top.

Zero-shot vs few-shot prompting

Zero-shot:

Classify the tone as positive, negative, or neutral. “The product is fine, but I was expecting more.”

Different humans would label this differently — partially positive, partially negative. Alignment to your task can come from few-shot:

Here are examples of tone classifications: “These exceeded my expectations completely.” → positive “It’s OK, but I wish it had more features.” → negative “The service was adequate. Neither good nor bad.” → neutral Now classify: “The product is fine, but I was expecting more.”

The model now likely says negative, aligned to the second example.

Sophisticated AI startups keep their few-shot examples up to date — whenever a user says something interesting, a human labels it and it gets appended to the relevant prompt. Like building a dataset, but inserted directly in the prompt. Faster to iterate because you don’t touch model weights.

Q: How long can the prompt be before the model loses itself?

There is research, but it dates fast. Practical example from Workera: a voice conversation eval breaks down after ~8 turns. Mitigation: chapter the conversation, summarize the first part, start over from a new prompt with the summary inserted.

Chaining complex prompts

The most popular technique. Not chain of thought.

Single prompt for a customer review response:

Read this review and write a professional response that acknowledges concerns, explains the issue, offers a resolution. {review}

You get one output. Hard to debug — everything is mixed together.

Chained version, three prompts:

1. Extract the key issues from this review.
2. Using these issues, draft an outline.
3. Using the outline, write the full response.

Advantages:

• Each prompt can be tested and optimized independently
• You can identify which step is weakest (outline good but email rude? then prompt 3 is the bottleneck)
• Easier to debug than one mega-prompt

Tradeoff: latency. Chains add latency, so for certain applications you don’t want long chains.

Testing prompts

Start with manual error analysis — a baseline prompt, a refined prompt, a chained workflow; humans rate outputs. Manual is slow but builds intuition.

To scale, use platforms (e.g. Promptfoo) that let you:

• Run the same prompt across multiple LLMs side by side in a table
• Define LLM judges

Flavors of LLM judges:

• Pairwise comparison: “Which summary is better?”
• Single-answer grading: “Grade this summary 1–5”
• Reference-guided pairwise or rubric-based: e.g. “A 5 is a summary below 100 chars, with three distinct key points, starting with an overview sentence; a 0 fails to summarize.”

You can stack techniques: few-shot the rubric with examples of 5/5, 4/5, 3/5, etc.

4. Fine-tuning (and why I steer away)

Reasons to avoid fine-tuning:

• Requires substantial labeled data
• May overfit to specific data, losing general-purpose utility
• Time- and cost-intensive — by the time you’re done, the next base model is out and beating your fine-tuned version

The advantage of prompt engineering is you can drop in the next best pre-trained model directly. Fine-tuning doesn’t work like that.

When fine-tuning still makes sense:

• Task requires repeated high-precision outputs (legal, scientific)
• The general-purpose LLM struggles with domain-specific language

The Slack fine-tuning cautionary tale

Ross Lazerowitz (Sep 2023) fine-tuned a model on his company’s Slack messages, hoping it would “speak like us.” Then he asked:

Write a 500-word blog post on prompt engineering.

The model: “I shall work on that in the morning.”

He pushes back: “It’s morning now.”

Model: “I’m writing right now.”

“It’s 6:30 AM here. Write it now.”

“OK, I shall write it now. I actually don’t know what you would like me to say about prompt engineering. I can only describe the process…”

It learned how people talk on Slack — not how they write blog posts. Fine-tuning went wrong because the training distribution wasn’t the task distribution.

5. Retrieval-Augmented Generation (RAG)

Why standalone LLMs fall short

• Small / hard-to-attend-to context windows
• Knowledge gaps and training cutoff dates
• Hallucinations — costly in medical, education
• Lack of sources — research, education, legal love sources. Vanilla LLMs hallucinate fake research papers.

How a vanilla RAG works

Question-answering in the medical field: “What are the side effects of drug X?”

1. Knowledge base of documents
2. Embed documents into lower-dimensional vectors (trade-off: too small → lose info; too big → latency)
3. Store embeddings in a vector database with efficient retrieval and a distance metric
4. Embed the user query with the same algorithm
5. Retrieve the most relevant documents by distance
6. Pull those documents, paste into a prompt template like:

Answer the user query based on the list of documents. If the answer is not in the documents, say “I don’t know.” Cite exact page, chapter, and line.

You can extend the template to require links to the specific page.

Improving RAGs

Q: Do document embeddings retain location info within large documents?

Vanilla RAGs may not. Example: the giant white paper inside a medication box would not be served well by a vanilla RAG.

Two popular improvements:

Chunking — store both the full document embedding and chapter-level embeddings; retrieve both, sourcing becomes more precise.

HyDE (Hypothetical Document Embeddings) — the user query usually doesn’t look like the documents. Example: “What are the side effects of drug X?” vs a multi-page document. To bridge the gap:

1. Take the user query
2. Use a prompt to generate a fake hallucinated document answering it (“write a 5-page report answering this query”)
3. Embed that fake document
4. Compare its embedding to the vector DB

The fake document is closer in structure to real documents, so retrieval is more accurate.

This is just two of many RAG variants — research from 2020–2025 has many branches. (See the linked survey paper in the slides.)

6. Agentic AI workflows

Andrew Ng coined “agentic AI workflows” because everyone uses “agent” to mean very different things — sometimes a single prompt, sometimes a complex multi-agent system. Calling everything an “agent” doesn’t do it justice. Better term: agentic workflow — a multi-step process to complete a task, built from prompts, tools, additional resources, and API calls. This also avoids confusion with the RL definition of “agent” (interacts with environment, state transitions, reward, observation).

One-shot vs agentic example

User on a chatbot: “What is your refund policy?”

• One-shot + RAG: “Refunds are available within 30 days of purchase.” [link to policy]
• Agentic:
  1. Agent retrieves refund policy via RAG
  2. Agent asks user for order number
  3. Agent queries an API to check order details
  4. Agent confirms: “Your order qualifies. The amount will be processed in 3–5 business days.”

Much more thoughtful than the vanilla one.

Specialized agents in the wild

In SF you’ll see billboards: AI software engineer, AI skill mentor, AI SDR, AI lawyer, AI specialized cloud engineer. It would be a stretch to say everything works, but work is being done. (Personal opinion: putting a human face behind these is gimmicky and more scary than engaging. In a few years, very few products will use a human face — it’s a marketing tactic.)

Paradigm shift: traditional software vs agentic AI software

Fuzzy engineering is truly hard. If you let users ask anything, the chance of breakage and attack is high. Companies have been bitten because a user did something authorized that broke the database.

Example from Workera:

• Deterministic item types: multiple choice, multi-select, drag-and-drop, ordering, matching — one correct answer.
• Fuzzy item types: voice questions, voice + coding role-plays — the scoring algorithm can make mistakes, and mistakes are costly.

Mitigation: a human in the loop — e.g. the appeal feature at the end of an assessment that lets users challenge the agent, bringing a human in to fix and align it.

Advice for building a company: get as much done deterministically as possible. Then for the fuzzy parts (back-and-forth interaction), design guardrails up front.

Enterprise workflows: the McKinsey credit memo example

A financial institution takes 1–4 weeks to produce a credit risk memo:

1. Relationship manager gathers data from 15+ sources
2. RM and credit analyst collaboratively analyze
3. Credit analyst spends 20+ hours writing the memo
4. RM and analyst loop on feedback

With Gen AI agents (McKinsey study), time drops 20–60%:

1. RM works with Gen AI agent, provides materials
2. Agent decomposes into tasks for specialist sub-agents
3. Agents gather data, draft memo
4. RM and analyst review and give feedback

The hardest part is changing people. In theory, this is great. In practice — 100,000-employee enterprises will take 10–20 years to rewire job descriptions, business workflows, incentives, and training to make this real at scale.

Core components of an agent

Take a travel booking agent:

• Prompts — the prompts we’ve learned to optimize
• Context management / memory:
  • Core / working memory: fast access. Things needed every interaction (e.g. user’s name).
  • Archival / long-term memory: slower. Things used occasionally (e.g. birthday).
  • Why split: imagine ChatGPT had to re-read all memories on every call. If memory lookup takes 3 seconds, every interaction takes 3 seconds. Working memory must be highly optimized.
• Tools: flight search API, hotel API, car rental API, weather API, payment processing API. You typically pass API documentation to the LLM — they’re good at reading JSON specs and learning the GET request format.
• Resources (Anthropic’s term): data sitting somewhere (e.g. your CRM) that you let the agent read. Provide a lookup tool and access to the resource.

Degrees of autonomy

From least to most autonomous:

• Least: hard-code the steps. “First identify intent, then look up history, then call the flight API, …”
• Semi: hard-code the tools only. “You’re a travel agent, help the user book travel. Here are your tools.”
• Most: agent decides both steps and tools. Give it a code editor; it can ping any web API, perform calculations, generate code to display data.

APIs vs MCP (Model Context Protocol)

With APIs, you teach the LLM to ping a specific API: give it documentation, define how to call it, what it returns. You do this one-off per API. Doesn’t scale well.

With MCP (Anthropic-coined), there’s a system in the middle. Agents communicate with an MCP server:

“What do you need to give me flight info?” “I need origin, destination, and what you’re looking for.” “Here are my requirements.” “You forgot to tell me your budget.”

It’s agent-to-agent communication. Companies publish their MCPs; your agent figures out how to get the data it needs.

Q: Isn’t MCP just a shifted maintenance burden — APIs change, MCPs change?

Yes. But at least the agent can go back and forth and discover requirements. Ideally a startup has documentation, an LLM workflow reads docs and updates code accordingly.

Q: Are there security concerns with MCP?

Likely, depending on the data exposed. Most MCPs have authentication, like APIs. The exact security surface depends on the implementation.

Q: Is MCP about efficiency or accessing more data?

Efficiency. You still control what data is exposed. Compared to one-off API integration, MCP lets a coding agent communicate efficiently with many MCP servers and find what it needs.

Step-by-step workflow example: travel agent

1. User: “Plan a trip to Paris Dec 15–20 with flights, hotels near the Eiffel Tower, and an itinerary.”
2. Agent plans steps: find flights, search hotels, generate recommendations, validate preferences/budget, book.
3. Execute: use tools, combine results.
4. Proactive interaction: propose to user, validate, iterate.
5. Update memory: “User only likes direct flights.” “User is fine with 3-star hotels.”

7. Case study: building a customer support agent + evals

PM asks you to build a customer support agent. Example: “I need to change my shipping address for order X — I moved.”

Where to start

• Research existing models / benchmarks for customer support
• Decompose the task: what would a human support agent do?
• Guess what’s fuzzy vs deterministic in advance

Recommended start: sit with a customer support agent for a day or two. Watch their workflow. Ask where they struggle and how much time each step takes. That gives you the task decomposition.

Decomposed task

A human support agent typically:

1. Extracts key info
2. Looks up the customer record in the database
3. Checks policy (allowed to update address?)
4. Drafts a response email
5. Sends the email

Designing the agentic workflow

For each step, pick the right primitive:

• Step 1 extract info: vanilla LLM call — extract intent, order number, new address
• Step 2 lookup + update: tool — connect to database (custom tool or MCP)
• Step 3 check policy: RAG or rule lookup
• Step 4 draft email: LLM call, with the confirmation pasted in
• Step 5 send email: tool — post to email API

Evals: how do you know it works?

Assume you have LLM traces (a must in any AI startup — if a startup doesn’t have traces, debugging is brutal). Several dimensions for evaluation:

End-to-end vs component-based:

• End-to-end: user satisfaction rating at the end. If user rates 1, follow up: “What was the issue?” → “Prices were too high” → fix the relevant tool/prompt.
• Component-based: error-analyze each tool / prompt independently. “The tool keeps forgetting to update the email field.” “The email-send call uses wrong format.”

Objective vs subjective:

• Objective: “LLM extracted the wrong order ID.” You can write Python to check alignment between user input and DB lookup. Catch automatically.
• Subjective: “Should we recommend a direct flight or cheaper indirect?” Captured via:
  • Curated eval dataset — write 10 prompts where users say “I prefer direct flights, I care about time.” Define what a good output looks like.
  • LLM judges grading on a rubric.

Quantitative vs qualitative:

• Quantitative: % successful address updates; latency per component (e.g. send-email takes 5s — too long).
• Qualitative: error analysis on hallucinations, tone mismatch, user confusion. Typically white-glove.

Example of subjective tone eval: error-analyze 20 user interactions, notice the LLM seems rude / overly short. Then build LLM judges with a politeness rubric. Then swap the underlying LLM (GPT-4 → Grok → Llama), run side by side, see which is most polite on average. Or fix the LLM and tweak the prompt (“Act like a travel agent” → “Act like a helpful travel agent”) to measure the word’s influence.

8. Multi-agent workflows

Why multi-agent when a single workflow already has multiple steps?

• Parallelism — independent things can run in parallel
• Reuse — a design agent built once can serve marketing, product, etc. Many stakeholders benefit from one optimized agent.

Smart home example

Brainstormed by the class:

• Biometric / location agent: tracks where you are and how you’re moving
• Climate agent: monitors and adjusts room temperature
• Energy efficiency agent: tracks usage, gives feedback, may control utilities
• Security agent: identifies who’s entering, applies role-based permissions (parent vs kid)
• Weather / external API agent: integrates outdoor conditions to control temperature, blinds, etc.
• Fridge / grocery agent: knows what’s inside via camera, knows preferences, has e-commerce API access for restocking
• Notification / alerts agent: system updates, energy savings
• Orchestrator agent: the user-facing entry point that delegates to specialists

Interaction patterns

• Flat / all-to-all: every agent can talk to every agent
• Hierarchical: orchestrator routes to specialists

Smart home likely wants hierarchical for UX — users want one interface, not one app per agent. Some flat links may still help (climate + energy efficiency probably need to talk directly).

When you allow agents to speak to each other, it’s basically an MCP-style protocol: treat the other agent like a tool. “Here’s how you interact, here’s what it tells you, here’s what it needs from you.”

Advantages

• Easier to debug specialized agents than a monolithic system
• Parallelization, time savings

9. What’s next in AI

Are we plateauing? (Ilya Sutskever’s question)

The community feeling around the latest GPT release was that the performance jump wasn’t what people expected — though the unified hood (no model selector) made consumer UX better.

LLM scaling laws say more compute + energy → better performance, but that eventually plateaus. What takes us to the next step is probably architecture search. The human brain operates very differently — much more efficient, much faster, with far less data. Big labs are hiring thousands of engineers precisely to hunt the next architectural breakthrough. Whoever discovered Transformers had tremendous impact on AI’s direction; the next analogous discovery could unlock a 10x reduction in compute and energy needs. (Foundation series analogy: individuals can disproportionately shape the future via their decisions.)

Multi-modality

LLMs started as text-only, added images. Models good at images are also better at text — being good at cat images makes you better at text about cats. Add audio and video, and the whole system improves. Pinnacle: robotics, where all modalities converge — the robot is better at avoiding a cat because it knows what a cat looks like, sounds like, smells like.

Methods working in harmony

Humans probably use a mix of methods:

• Meta-learning — survival instinct encoded in DNA (the baby’s “pre-training”)
• Supervised — parents pointing and saying “good / bad”
• Reinforcement — falling and getting hurt
• Unsupervised — observing others

Future AI systems likely combine the methods you saw in CS230, optimizing for speed, latency, cost, and energy.

Human-centric vs non-human-centric research

The human body is limiting. Pure brain-modeled research may miss compute/energy optimizations. Still, the brain has lots to teach — e.g. one research direction asks: does the brain do backpropagation? Probably not — likely only forward propagation. Worth reading if you’re curious about AI’s direction.

Velocity

Things move so fast that we deliberately teach breadth, not depth — because today’s specific RAG technique #17 will be irrelevant in two years. Get the breadth, develop the ability to sprint into depth when needed. The half-life of skills is low.

後話

這篇是 Stanford CS230 公開課的整理、保留英文原文以避免翻譯失真。要看本 blog 對應的中文原理化內容、可以接：

• 模組四：LLM 應用層原理 — RAG / tool use / agent / workflow patterns 的跨工具不變原理
• 4.1 RAG 原理
• 4.4 Agent 架構原理
• 4.14 Benchmarking 與評估方法論
• 4.21 LLM-as-Judge 評估方法

概念位置

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。

用作走查的任務：PM 交派「做一個 customer support agent、能處理用戶查詢、必要時自動完成操作（如改地址）。」本案例聚焦「改地址」這個高頻 query type 走完整流程。

本案例的設計反射

整個流程分七階段：

1. 觀察人類工作流：訪談、決定 task decomposition
2. 典範定位：哪段該 deterministic、哪段該 fuzzy
3. 工作流設計：每個 step 選對應的 LLM / tool / RAG / HITL 形態
4. 協議跟自主度決定：是 single agent / multi-call / multi-agent
5. Trace instrumentation：哪些資訊要記
6. Eval 設計：先選座標、再選工具
7. Iteration loop：error analysis → 修哪一層 → 看 metric 收斂

初次設計 LLM 應用時最常省略階段 1、2、5、6、直接跳到階段 3 開始寫 prompt——這條路會走進「prompt 改了 20 版、無法判讀有沒有變好」的迭代無收斂。本案例強調的是設計反射動作的順序、不是寫 prompt 技巧。

階段 1：觀察人類工作流

PM 給的任務描述是「處理用戶查詢」、但「查詢」涵蓋的範圍可能很大。第一個反射動作是坐在客服旁邊觀察兩天、不是打開 IDE。

實際做的事：

• 統計收到的 query 類型分佈（退款 / 改地址 / 查詢訂單狀態 / 抱怨 / 開放問題各佔多少）。
• 看每類 query 的 human resolution 流程（哪幾步、要查哪些系統、要遵守哪些 policy）。
• 看哪幾類 query 是 high volume + low complexity（最值得自動化）、哪幾類是 low volume + high complexity（自動化 ROI 差）。
• 記下 human 在哪些 step 卡住、哪些 step 反覆需要查同樣資料。

訪談結束、你得到一張 task decomposition map。本案例假設聚焦在「用戶請求改地址」這個高頻 query type：

1User: 「我搬家了、訂單編號 #12345、新地址是 ___」
2   ↓
31. 解析意圖 + 抽取訊息（訂單編號、新地址）
42. 查訂單狀態（已出貨？未出貨？已送達？）
53. 查 policy（這個訂單狀態 + user tier 能不能改地址？）
64. 若可：執行改地址（呼叫物流 / 庫存 API）
75. 若不可：解釋為什麼、給替代方案
86. 草擬回覆 email、發出

引用原理：這個 decomposition 本身對應 0.8 fuzzy engineering（deterministic-vs-fuzzy 卡）的「先分解任務、再判讀每段該 deterministic 還是 fuzzy」。

階段 2：典範定位

對每個 step 做典範定位（deterministic / fuzzy）：

判讀的重點是邊界各歸各位：規則跟政策走 code、人話跟意圖解析走 LLM。

• Policy check 寫成 code（如「user tier + 訂單狀態 → 能否改地址」是 deterministic 規則）。對應反例：把規則塞進 prompt 讓 LLM 判斷、會偶爾跳過規則或誤判 tier。
• 「能不能做」這類 yes/no 走規則。對應反例：用 LLM 算判斷、debug 困難且非確定性。
• 「Helpful 的回覆」走 LLM 寫。對應反例：在 code 內 hard-code 模板、變成僵化的客服機器人腔。

最容易混的邊界在 step 6：「草擬 email」是 fuzzy（要寫人話、tailor to 情境）、「發送 email」是 deterministic（呼叫 API、處理錯誤碼）。把這兩件事拆開、草擬可以 retry / 改 prompt 不影響發送邏輯、發送有結構化 error 不被 LLM hallucinate 蓋過。Step 4「執行改地址」也類似：tool call 本身 deterministic、但是否該 call 的判讀回到 step 3 的 policy check。

引用原理：0.8 fuzzy engineering 的「哪段該 deterministic / 哪段該 fuzzy」決策框架、特別是反模式「邊界用錯」段。

階段 3：工作流設計

對每個 step 選對應的工具：

兩個容易選錯的 step 展開：

Step 1 為何要 structured output、不是純 prompt 解析：抽取結果要餵 step 2-4 的 deterministic tool、order_id 抽錯就整個流程斷。純 prompt 描述「請輸出 JSON」是弱保證、structured output / constrained decoding 是強保證（見 3.10 constrained decoding 內部）。Trade-off：強格式可能犧牲表達彈性、但這個 step 不需要彈性、要的是可靠。

Step 5 為何配 RAG 而非純 few-shot：客服 case 涵蓋多種情境（訂單已出貨 / 已送達 / VIP / 一般 user / 不同國家 policy）、固定 few-shot 範例 cover 不全。RAG 從歷史 case 庫即時 retrieve 最相似的解釋範例、屬於 4.0 prompt 技術光譜 context 軸的 retrieval-augmented prompting。

引用原理：

• Step 1 的 structured output → 4.6 應用層協議
• Step 2-4 的 tool 設計 → 4.3 tool use
• Step 4 的 pre-act HITL → 4.5 人機協作拓樸 pre-act 段。對比講座 Workera appeal 是 post-hoc、本案例選 pre-act 是因為改地址不可逆 + 物流影響大、必須在執行前審
• Step 5 的 RAG → 4.1 RAG 原理 + 4.0 prompt 技術光譜 context 軸

階段 4：協議跟自主度決定

這個工作流的控制流是線性的（1→2→3→4→5→6）、有條件分支（step 3 結果決定走 4 還是 5）、但每步順序固定。判讀：

該用什麼結構：

• 不適用 Multi-agent：步驟順序固定、角色差異不大、orchestration overhead 純增。
• 不適用 Single agent loop（model 自決下一步）：本案例假設 single-turn / 短多 turn、步驟順序明確、不需要 agent 自決。若 user 互動多輪 + turn 數不固定（如 user 中途補資訊、改主意、追問）、可考慮 agent loop。
• 採用 Multi-call pipeline + router：寫成 deterministic pipeline、step 3 後有 router 分流。

引用原理：

• 4.8 multi-agent 拓樸 的「先 multi-call、不夠再 multi-agent」反射
• 4.7 workflow patterns 的 pipeline + router 模式
• 4.4 agent 架構 的「先 single-call、不夠再 agent」反射

自主度：

• Step 1（parse）、5（解釋）、6（草擬 email）：full auto。
• Step 2、3（查訂單、查 policy）：full auto（read-only）。
• Step 4（執行改地址）：pre-act HITL（高風險 + 不可逆）、有 diff show、user 可以 reject。
• Step 6（發 email）：可選 pre-act HITL（看公司風格、保守版要審 email、激進版自動發）。

階段 5：Trace Instrumentation

工作流上線前、先設計要記哪些資訊。Eval 跟 debug 都靠 trace、沒 trace 後面什麼都做不了。

每個 step 要記：

整段 trace 要綁同一個 conversation_id、可以後面 join 起來看完整流程。

引用原理：4.20 LLM tracing。

階段 6：Eval 設計

先選座標、再選工具。對本案例的每個 eval 需求、用 4.13 三軸座標 定位。下面列的 threshold 數字（95%、80%、≥4 等）是 illustrative、實際數字隨產品 baseline、user 容忍度、業務代價而定、不是通用標準。

Eval 1：Step 1 抽取準不準

• 三軸：Objective（有 ground truth）+ Component（測單 step）+ Quantitative（accuracy）。
• 工具：寫 100 個有標註的 query、跑 step 1、看 extraction accuracy（order_id 對 + new_address 對的比例）。
• Threshold：< 95% 不上線。

Eval 2：Step 2-4 tool call 行為正確

• 三軸：Objective + Component + Quantitative。
• 工具：mock API、給 step 2-4 各 50 個 case、看 tool call 參數對不對、返回值處理對不對。
• Threshold：100%（這是 deterministic 行為、不該有錯）。

Eval 3：Step 5 解釋品質

• 三軸：Subjective（沒有單一正解）+ Component + Quantitative。
• 工具：LLM-as-judge with rubric（clarity / helpfulness / tone）、scale 1-5、aggregate average。
• Threshold：average ≥ 4、no 1-2 比例 < 5%。

Eval 4：Step 6 email 品質

• 三軸：Subjective + Component + Quantitative + 加 Qualitative human review。
• 工具：LLM judge 給分 + 每週抽 20 封 human review、看是否有 hallucinate 承諾、是否符合公司 tone。
• Threshold：judge 平均 ≥ 4、human review 沒有 critical issue。

Eval 5：E2E success rate

• 三軸：Objective + End-to-end + Quantitative。
• 工具：跑 200 個 representative case、看「完整完成 + user 沒申訴」的比例。
• Threshold：≥ 85% baseline、降到 < 80% alert。

Eval 6：User 滿意度

• 三軸：Subjective + End-to-end + Quantitative。
• 工具：每次互動結束顯示 thumbs up/down + optional 留言、追蹤 weekly。
• Threshold：thumbs up rate > 80%、appeal rate < 5%。

Eval 7：Failure mode pattern（持續做）

• 三軸：Objective / Subjective + End-to-end + Qualitative。
• 工具：每週讀 50 個 sampled traces + 100% 讀 failure / appeal traces、找 emerging pattern。
• 產出：bug ticket、prompt 修改 hypothesis、policy 補強 hypothesis。

引用原理：

• 三軸座標 → 4.13 eval design framework
• LLM judge rubric → 4.21 LLM-as-Judge
• Trace 接 eval → 4.20 LLM tracing

階段 7：Iteration Loop

上線後、不是「等出問題」、是持續 iteration。典型 iteration cycle：

 1Production trace + eval result
 2   ↓
 3[Error analysis：找 emerging pattern]
 4   ↓
 5   Hypothesis：哪一層有問題？
 6   ├── Prompt 層 → 改 prompt → A/B test → 看 eval 收斂
 7   ├── Tool 層   → 改 tool / schema → 跑 component eval → 收斂
 8   ├── RAG 層    → 改 chunking / query rewriting → 跑 [retrieval recall](/llm/knowledge-cards/retrieval-recall/) → 收斂
 9   ├── Policy 層 → 改 deterministic rule → 跑 step 3 component eval → 收斂
10   └── Model 層  → 換 model → 跑全 eval set → 收斂
11   ↓
12[改動進 production]
13   ↓
14[Frozen baseline 留著、新版本跟它比、漂移看得見]

判讀「該改哪一層」的反射：

引用原理：

• Prompt 跟 model 層的失敗診斷 → 4.0 prompt 技術光譜 systematic vs random error
• 整體 fuzzy / deterministic 邊界判讀 → 0.8

五個容易遺漏的設計反射

實務上常常省略這五個反射動作、走進無收斂迭代：

反射一：先觀察、再開 IDE

階段 1 的價值是把 task decomposition 跟真實人類工作流對齊。沒這層對齊、寫出來的 prompt 跟 tool 拆法跟 reality 偏離、三天後重做。階段 1 的兩天比階段 3 的兩週值得。對應反例：「我先寫個 prompt 試試」、跳過觀察直接寫 code。

反射二：Policy 寫成 code、LLM 只解析意圖

判斷類規則（user tier、訂單狀態、可否操作）走 deterministic code、LLM 只負責「user 想做什麼」這層意圖抽取。這條邊界讓 debug 容易、規則更新不用 prompt iteration。對應反例：「LLM、請判斷這個訂單能不能改地址、規則如下：…」——把判斷塞進 prompt、debug 困難、規則漂移無從追蹤。對應 0.8 的「邊界用錯」反模式。

反射三：Trace 是 day-1 設計

從第一天就把 input / output / latency / token / step name / decision branch / error 進 trace、綁同一個 conversation_id。Eval 跟 debug 都靠 trace、沒 trace 後面什麼都做不了。對應反例：「先讓系統跑起來、之後再加 trace」——出 bug 時 debug 從零開始、production trace 不可回溯。

反射四：Deterministic 行為用 deterministic check

有 ground truth 的行為（抽取對不對、API 參數對不對、JSON schema 合不合）用 Python 函數驗證、判斷成本低、精度高。LLM judge 留給沒 ground truth 的 subjective 行為。對應反例：用 LLM judge 測「step 1 抽取對不對」——cost 翻倍、精度反而不如 deterministic check。對應 4.13 軸誤選一。

反射五：保留 frozen baseline

Frozen baseline 是把某個特定 prompt + 特定 model 跑 production 一段時間後 freeze 起來、每次新版本都跟它比、漂移看得見。對應反例：每次只跟「上一版」比、半年後累積漂移完全不可見、「整體變好了沒」無從回答。

跟其他章節的對應總表

本案例每階段引用的原理章節彙整：

下一步

返回：模組四首頁、或回到 hands-on 索引。

概念位置

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。

讀完本章後、你可以對自己這台 PC 直接回答：能跑哪些模型、要不要做 MoE 卸載、KV cache 該量化到哪一級、context 能開多大、系統 RAM 容量該不該升級。

本章目標

讀完本章後、你應該能：

1. 看 PC 規格（VRAM + RAM）立刻知道能跑哪一級的模型、需不需要卸載。
2. 理解為什麼 16GB VRAM + 64GB RAM 跑 30B MoE 比跑 14B Dense 全載 VRAM 划算。
3. 判讀 KV cache 量化跟 context 長度的權衡。
4. 判斷自己這台 PC 適不適合跑本地 LLM、瓶頸在 VRAM 還是 RAM。

PC 記憶體預算的基本算式

PC 跑本地 LLM 的預算拆成兩塊、各有自己的容量上限：

1VRAM = 顯卡記憶體（GDDR6/7）= 高頻寬區
2  └── 通常需放：當前活躍模型層 + KV cache + 推論中間結果
3
4系統 RAM = 主機板上的 DDR4/5 = 高容量區
5  └── 可以放：MoE 不活躍專家層（透過 --n-cpu-moe）、暫存權重、context cache
6  └── 通常需保留：作業系統 + 應用程式 + GPU driver pinned memory
7
8PCIe = 兩塊預算之間的橋
9  └── 5.0 x16 廠商標稱單向約 64 GB/s、模型載入時較常成為瓶頸、推論時通常較少

兩塊預算各自的估算原則（具體數值依硬體世代、廠商規格與驅動版本而變化、本章引用的數字以廠商規格表為主、實際吞吐受系統配置影響）：

1. VRAM 容量：決定能放多少模型層。Dense 模型若要生字快、所有層都該在 VRAM；MoE 模型可以只放「共用層 + 部分專家」、其餘走 RAM。
2. VRAM 頻寬：影響生字速度上限。常見消費級 NVIDIA 卡的廠商標稱頻寬（向廠商規格表查驗）大致落在數百 GB/s 到約 1 TB/s 級的區間（如 RTX 5060 Ti 16GB 標稱約 448 GB/s、RTX 5070 Ti 約 896 GB/s）；生字 t/s 約等於「VRAM 頻寬 ÷ 模型每 token 讀取的 bytes」、但實際吞吐還受 CUDA backend、量化方式與 batch size 影響。
3. 系統 RAM 容量：影響 MoE 卸載與多模型併存的彈性。對 16GB VRAM 卡而言、64GB DDR5 通常足以支撐重度 MoE 卸載、128GB 對多模型併存或長 context cache 更從容、32GB 則會限縮可卸載的層數。
4. 系統 RAM 頻寬：影響卸載到 CPU 的層走多快。DDR5 6000 雙通道的標稱頻寬約 96 GB/s（依主機板、CMK 模組與時序變動）、相對 VRAM 慢約一個量級、所以卸載層數要跟可接受的生字速度損失一起調。
5. PCIe 頻寬：模型載入時通常是瓶頸、單人推論時較少成為主要瓶頸（除非每 token 都需要把大量卸載權重拉回 VRAM）。

PC 配置與可運作模型對照

下表整理 2026 年 5 月常見消費級 NVIDIA GPU 加上不同 RAM 容量、可運作模型的數量級對照。體感標籤是社群常見回報的相對描述、實際因 llama.cpp / Ollama 版本、CUDA backend、模型量化版本、--n-cpu-moe 設定與工作流類型而變動、需自行實測校準。

讀這張表要注意四件事：

1. 「全載 VRAM」跟「卸載」是兩種選型。全載生字較快但模型較小、卸載生字較慢但能跑較大模型；MoE 結構讓兩者的速度差距小於 Dense 模型。
2. 量化等級可以調整。16GB VRAM 跑 30B MoE Q4 比跑 30B MoE Q5 留下更多 VRAM 餘量、給 KV cache 跟併發數使用。
3. RAM 容量影響選型。32GB RAM 配 16GB VRAM 時、可卸載層數有限、能跑的最大 MoE 規模受限；64GB RAM 配 16GB VRAM 通常足以支撐 30B 級 MoE 的重度卸載。
4. 多卡升級建議在單卡跑穩後評估。雙 GPU 在 llama.cpp 上要設定 tensor split、實際速度提升依模型與配置變化；消費級主機板的 PCIe lane 分配（常見一條 x16 + 一條 x4）也會影響多卡效益。建議先把單卡跑熟、再依瓶頸決定是否多卡。

為什麼 16GB VRAM + 64GB RAM 常被列為寫 code 場景的合理起點

這個配置（RTX 5060 Ti 16GB / RTX 5070 Ti 16GB + 64GB DDR5）在 2026 年 5 月的 PC 本地 LLM 社群裡、常被作為「寫 code 用途」的價格效能比合理起點。對應的判讀軸有四條：

1. 30B 級 MoE 模型在多數寫 code 任務已能勝任。Qwen3-30B-A3B 等 MoE 模型在公開 coding benchmark 上的回報（如 Qwen 官方技術報告、社群 SWE-bench 跑分）顯示表現接近大型 Dense 模型；具體分數依任務類型、prompt 設計與評測版本變動、需參考各模型官方文件或 SWE-bench 卡片。模型總參數與 active parameter 是兩個獨立軸、影響記憶體需求跟生字速度上限。
2. MoE 卸載讓 16GB VRAM 能載入 30B 級模型。把約 30 層 MoE 專家權重留在 RAM、其餘放 VRAM、Qwen3-30B-A3B Q4 量化下整套模型總記憶體約落在 18 ~ 22GB 區間、其中常見約 12 ~ 14GB 在 VRAM（實際依模型結構與 --n-cpu-moe 設定變化）。
3. KV cache 量化能在剩餘 VRAM 開大 context。模型權重放好後、剩餘 VRAM 配上 K=Q8 / V=Q4 的 KV cache 量化、社群常見回報能開到 128K ~ 256K 級 context（依模型 attention 配置變化）、寫 code 場景的長 prompt 較少需要截斷。
4. 零件可分次採購、後續可升級。相對 Apple Silicon 整機綁定配置、PC 零件（GPU、RAM、CPU、儲存）可分次採購與升級；具體零件價格依在地市場、世代與促銷波動、本文不引用具體幣值。

下表是社群討論中常被提及的兩張同代 16GB 卡的相對對照、用意是「同樣 16GB VRAM 但頻寬不同對 throughput 的影響」、不是嚴格 benchmark：

兩張卡的差異主要在 VRAM 頻寬（廠商標稱接近 2 倍）、不在 VRAM 容量。對「同樣的模型能否載入」沒影響、對「生字多快」影響較大。實際 throughput 因驅動版本、模型量化方式、--n-cpu-moe 設定與 prompt 長度而變動、需自行用 llama-bench 或實際工作流校準。

事實查核註：表中 prefill / 生成的具體數字是社群討論中常見回報的相對數量級、不是經本文系統實測的 benchmark。VRAM 頻寬以 NVIDIA 廠商規格表為主、實作上會被 GDDR 模組廠商、PCIe 版本、CUDA backend 版本影響。引用前請以最新官方規格表跟 llama.cpp 官方 benchmark 為準。

社群常見回報的三個觀察點（同樣需以自身配置實測校準）：

1. --n-cpu-moe 數值往上加（如從 20 加到 30）、單張卡的 VRAM 佔用降低、可開的 context 上限拉大、但生成速度也會下降；具體下降幅度依模型 active parameter 比例變化。
2. KV cache 量化（K=Q8 / V=Q4）相對 fp16 KV cache 體積大幅壓縮、能換取更大 context 上限；寫 code 場景的補完品質影響社群多數回報為小幅或不明顯、但會視 prompt 長度與任務類型而異。
3. 系統 RAM 從 32GB 升到 64GB 後、可卸載的 MoE 層數上限明顯提高、能跑的最大模型規模也跟著拉開；具體層數依模型結構而定。

對應的 PC 配置面向（2026 年 5 月、不引用具體幣值）：

• 價格優先：RTX 5060 Ti 16GB + 64GB DDR5 + 中階 CPU（如 AMD 9900X / Intel 14700K）+ 1TB NVMe。
• 生字速度優先：RTX 5070 Ti 16GB + 64GB DDR5 + 中階 CPU。VRAM 容量跟 5060 Ti 相同、頻寬規格接近兩倍。
• 跑得了 70B 級：RTX 4090 24GB / RTX 5090 32GB + 64GB ~ 128GB DDR5。

若你正準備組新機主要為了跑本地 LLM 寫 code、16GB VRAM + 64GB RAM 是社群常見的合理起點；具體選哪張卡、視預算上限與對生字速度的要求而定。

MoE 卸載 vs 全載 Dense 的選型差異

PC 場景有 Mac 沒有的選型變數：同樣 16GB VRAM、要跑「全載 14B Dense」還是「卸載 30B MoE」？

兩條路線的差異：

判讀原則：寫 code 場景下、模型能力對任務成敗的影響通常比生字速度更顯著；30B 模型能完成的跨檔案任務、生字較慢仍可能勝過 14B 較快但解不出來的情況。若工作流以高頻短補完為主、對生字即時體感要求高、14B Dense 全載仍是合理選擇。實際取捨建議用一週實測校準。

KV cache 量化與 context 的權衡

VRAM 預算扣掉模型權重後、剩下的空間主要給 KV cache。KV cache 跟 context 長度大致成正比、長 context 場景的 VRAM 限制跟 Mac 統一記憶體場景類似、但 PC 多了「量化 KV cache」這個工程選項。

下表為 KV cache 體積的數量級估算（依模型 attention head 數、hidden size、量化策略變化、實際值需用工具測量、本表用於說明量化前後的比例變化）：

KV cache 量化在寫 code 場景的體感判讀有三條社群常見回報的原則（具體影響因模型、量化版本與工作流而變、需自行實測校準）：

1. K（key）對量化容忍度通常較高：key 用來計算 attention score、本質是相對量級的比較。社群多數回報指出 K=Q8 相對 fp16 在補完品質上差異不明顯、可作為較安全的起手量化等級。
2. V（value）對量化敏感度集中在長 context 末尾：value 是被加權平均的內容、量化誤差會累積進輸出。短 prompt（< 32K）下 V=Q4 跟 fp16 的差異多為小幅；長 prompt（128K+）的對話末尾、社群回報偶爾觀察到「對前文細節記憶較模糊」的情形、但對跨檔案 code 補完任務影響社群多數回報為小。
3. 品質影響在 coding 跟自由創作場景不同：寫 code 的輸出空間受語法 / 型別 / 編譯限制、KV cache 量化的小幅誤差較容易被約束過濾；自由創作（小說、詩、長對話）對 V 量化較敏感、社群回報品質差異較明顯。

實務上、K=Q8 / V=Q4 是 PC 場景開大 context 的常見組合；若觀察到長 prompt 末尾的回答品質下降、可考慮把 V 升回 Q8 或 fp16（代價是 VRAM 佔用上升、context 上限會縮短）。

具體調參邏輯詳見 5.2 KV cache 量化策略。

系統 RAM 容量在 PC 場景的角色

Mac 統一記憶體只有一個容量數字、PC 多了「VRAM」跟「系統 RAM」兩個獨立數字。PC 場景的預算分配若全部投入 VRAM、可能忽略系統 RAM 對 MoE 卸載策略的支撐角色。

系統 RAM 在本地 LLM 場景的主要用途（具體佔用量依工作流變化）：

1. 作業系統 + 開發工具：Windows / Linux + VS Code + 瀏覽器、常見佔用約 8 ~ 16GB。
2. GPU driver pinned memory：NVIDIA driver 為了 PCIe DMA 會固定一塊系統 RAM、依驅動版本與配置常見約 1 ~ 2GB。
3. MoE 卸載的專家權重：跑 30B MoE 卸載多數專家層、所需 RAM 落在 10 GB 級以上；跑 70B MoE 重度卸載通常需要數十 GB 級。具體數字依模型結構與 --n-cpu-moe 設定變化。
4. 多模型併存：同時跑 coding model + embedding model + 翻譯模型、每個各佔數 GB 級。
5. page cache / 系統暫存：Linux 會把剩餘 RAM 用於 page cache、模型 reload 時可加速。

對 16GB VRAM 配置而言、64GB RAM 通常足以支撐重度 MoE 卸載、是社群常見的起點容量。32GB RAM 配 16GB VRAM 在重度 MoE 卸載場景容易吃緊、可卸載層數會受限；視工作流類型、32GB 也可能足夠跑全載 Dense 模型。

PCIe 頻寬的角色

PCIe 在「載入模型」階段較常成為瓶頸、單人推論時通常不是、但 MoE 卸載會讓 PCIe 在推論時也參與資料流：

1. 模型載入時：PCIe 5.0 x16 廠商標稱單向約 64 GB/s（PCIe 4.0 x16 約一半）、實際走完磁碟 → RAM → VRAM 整條路徑的吞吐通常較規格低、模型載入時間視 NVMe 讀取速度、檔案系統與量化格式變動。常見差異在啟動秒數、推論階段一般感受不到。
2. MoE 卸載推論時：每 token 啟用的專家層權重需透過 PCIe 從 RAM 拉到 VRAM。以 Qwen3-30B-A3B 為例、每 token 啟用約 3B active parameter；若部分專家層在 RAM、每 token 需透過 PCIe 拉部分權重。單人推論場景下、相對 PCIe 5.0 x16 的可用頻寬佔比通常較小、社群多數回報不是主要瓶頸；併發數高或卸載比例極大時會逐漸顯現。
3. 多卡推論：多卡 tensor parallel 會密集走 PCIe / NVLink。消費級 GPU 普遍不支援 NVLink、訊息走 PCIe；多卡的吞吐縮放比社群回報相對單卡 + MoE 卸載的線性度差、需依工作流評估。

實務上、單卡 + MoE 卸載場景下 PCIe 較少成為主要瓶頸；多卡或極端卸載比例下、PCIe lane 分配（如主機板的 x16 + x4 配置）會明顯影響可達吞吐。

給讀者的決策表

看完上面的對照後、可以照下表做決策：

釐清需求類型：個人使用 vs 服務多人

初次接觸本地 LLM 時、常見的疑問是「是不是要 H100 / H200 等資料中心級配置才能跑」。實際上資料中心級配置的設計目標是大規模並發推論服務（同時對許多 client 出 token）、跟單人寫 code 的需求側重不同。釐清需求類型後、硬體選擇會清楚很多。

三條判讀軸：

1. 能載入的模型大小主要受 VRAM 容量影響、跟 GPU 算力等級沒有單一對應關係。16GB VRAM 配 MoE 卸載可載入 30B 級 MoE 模型；資料中心級 GPU 容量更大、能載入更大的 Dense 模型、但對個人寫 code 場景的能力提升不一定線性。
2. 生字速度上限主要由 VRAM 頻寬影響。消費級高階卡（如 RTX 5070 Ti、4090、5090）的頻寬已足以支撐單人寫 code 場景的補完即時體感、實際差異依模型量化、context 長度與 backend 變化。
3. 大量並發推論才需要資料中心級配置。單人開 VS Code 跟 LLM 對話、通常不會用到資料中心的並發優勢。

對應的決策路徑：先確認需求是「個人寫 code」還是「服務多人」、再選 16GB VRAM + 64GB RAM 級的起點配置、實測一週觀察模型能力是否符合任務需求、再依痛點選擇升級方向（VRAM 容量、頻寬、或多卡）。

升級到能跑 70B 級之前、建議先確認痛點是「模型能力不夠」還是「生字速度不夠」。本地 30B MoE 在多數寫 code 任務上已能勝任、社群多數使用者回報不是每個工作流都需要 70B 級模型；具體判斷需用自己的任務實測。

下一章

下一章：5.1 MoE 模型與 CPU 卸載策略、深入 --n-cpu-moe 的判讀。

讀完本章後、你應該能對自己用的模型回答：來源是不是作者本人 / 官方鏡像、檔案完整性怎麼驗、量化版本是不是社群常用的、第三方再上傳的版本該不該用。

本章目標

1. 認識本地 LLM 模型供應鏈的角色：原始作者 → 官方 release → 第三方量化 → registry 散發。
2. 知道個人 dev 場景的信任邊界跟驗證手段。
3. 區分「官方版本」、「社群熱門量化」、「個人上傳」三種來源的信任等級。
4. 用 GGUF 檔案完整性檢查（hash、檔案大小、metadata）建立基本驗證流程。
5. 認識 Ollama / Hugging Face / LM Studio model browser 的供應鏈差異。

本地 LLM 模型供應鏈的角色鏈

1原始作者（如 Meta、Google、Qwen 團隊）
2  ↓ 發布原始權重（safetensors / pt、通常 fp16 或 bf16）
3官方 Hugging Face organization
4  ↓ 第三方量化者（如 bartowski、TheBloke、unsloth）
5量化版本 GGUF（Q4_K_M、Q5_K_M 等）
6  ↓ Ollama 收進 registry 或社群上傳
7Ollama registry / LM Studio 內建瀏覽器
8  ↓ 使用者拉下來
9本機 GGUF 檔案

每一層都是潛在的信任邊界：

1. 原始作者：信任假設是「作者發布的權重就是訓練出來的權重、沒被植入後門」。個人 dev 場景下、選主流作者（Meta、Google、Qwen、Mistral 等）的官方發布通常是合理起點。
2. 量化者：把官方 fp16 權重壓成 Q4 / Q5 等 GGUF 格式的人。社群常見熱門量化者（如 bartowski、unsloth）有公開的量化腳本與長期信譽、但仍是個人或小團隊、不是企業簽章。
3. registry 散發：Ollama registry、HF Hub、LM Studio 內建瀏覽器是分發層。可能被搶 namespace、可能有人偽造「官方」名義上傳。
4. 本機儲存：下載完的 GGUF 檔案在硬碟、後續執行時權重本身就是程式邏輯的一部分（透過 inference 影響輸出）。

事實查核註：上面的角色鏈是 2026 年 5 月的常見運作模式。具體量化者、registry 政策、模型分發流程依平台變化、建議引用前以 Hugging Face、Ollama、LM Studio 各自的安全公告與 community guidelines 為準。

三種來源的信任等級

個人 dev 場景下、常見的模型來源可以分成三個信任等級：

「中等」跟「較高」的差別主要在「企業簽章」這個維度——Hugging Face verified organization 對應「該組織確實是 Meta / Google / Qwen 等主體」、但不對「該組織內部 release process 是否安全」做擔保。即使是官方發布、仍是「人類團隊發布的權重」、不是密碼學意義的零信任。

GGUF 檔案完整性的基本檢查

下載完 GGUF 檔案後、可以做幾個輕量檢查確認檔案完整性：

 1# 1. 比對檔案 SHA-256（HF / Ollama 通常會列出官方 hash）
 2shasum -a 256 ~/.ollama/models/blobs/sha256-xxx
 3# 或
 4sha256sum Qwen3-30B-A3B-Q4_K_M.gguf
 5
 6# 2. 看檔案大小是否跟 model card 標示一致
 7ls -la Qwen3-30B-A3B-Q4_K_M.gguf
 8
 9# 3. 用 llama.cpp 的工具看 GGUF metadata
10./gguf-dump.py Qwen3-30B-A3B-Q4_K_M.gguf | head -50
11# 確認 architecture、context_length、量化等級跟預期一致

這些檢查能擋住：

1. 下載中斷導致檔案不完整：hash 不對、跑不起來、不是安全議題但會誤導判讀。
2. CDN / 鏡像中間人替換：理論可能、實務上 Hugging Face 跟 Ollama 走 HTTPS、TLS 完整性是基礎防護；hash 比對是額外確認。
3. 誤拉到不同量化版本：例如想拉 Q4_K_M 結果拉到 Q4_0、檔案大小跟 metadata 會反映出來。

擋不住：

1. 量化者本身在量化過程做了手腳：hash 對得上、但權重已經被改過。這需要回到原始作者的權重重新量化、屬於進階驗證、個人 dev 場景通常不做。
2. 作者本身在發布的權重裡植入後門：個人 dev 場景的 threat model 假設主流作者不會做這件事；若不信任、不應該用該模型。

事實查核註：GGUF 檔案的完整性檢查工具跟流程依 llama.cpp 版本變化、gguf-dump.py 等腳本路徑可能改名或棄用、以實際 llama.cpp release 跟 GGUF 規格 為準。

Ollama / Hugging Face / LM Studio 的供應鏈差異

三個 registry 在實際拉模型的操作面（namespace、download 指令、本機儲存路徑）見對應安裝章節：1.0 Ollama、1.1 LM Studio、PC 場景的 LM Studio 見 5.4。本節聚焦三者在供應鏈管理上的相對位置：

實務上、社群常見的選擇路徑：

• 想拉 official 模型：優先 Hugging Face official organization、或 Ollama library/ namespace
• 想拉熱門量化：bartowski / unsloth 等知名量化者的 HF repo、Ollama 通常也會把熱門模型收進 official library
• 看到個人 repo 上傳的「特別優化版」：除非有明確來源說明、否則保守看待

量化版本污染的可能性

量化版本污染的具體威脅形態：

1. 量化腳本被改過：量化者公開的腳本跟實際跑的腳本不一致、產出的權重跟「按公開腳本量化」會不同。
2. 量化過程引入後門：在量化的同時微調權重、在特定 prompt 下觸發特定行為。技術上可行、實務上社群罕見公開案例、但無法事前完全排除。
3. 量化版本被替換上傳：先上傳乾淨版本累積下載量、再替換成有問題的版本。HF / Ollama 都有 file history、但個人 dev 通常不會檢查。

個人 dev 場景的合理應對：

1. 優先用知名量化者的版本：bartowski / unsloth 等有長期紀錄的量化者、相對個人首次上傳信任度較高。
2. 下載後立刻記錄 hash：作為日後比對基準；若日後同一 model name 但 hash 變了、值得查 history。
3. 大型 codebase 任務前先用簡單 prompt 試模型：例如「fn main() { println!("hi"); }」這類；確認模型行為基本合理、再用於真實任務。

第三方 plugin / MCP server 的供應鏈

模型本身的供應鏈之外、Continue.dev / MCP server / Ollama plugin 等也構成供應鏈、且風險形態不同：

1. MCP server 多為可執行程式碼：安裝 MCP server 等於在本機跑第三方程式碼、權限影響大於 GGUF 檔案（GGUF 只在 inference 時影響輸出、MCP server 可以直接讀寫檔案、呼叫 shell）。
2. Continue.dev 擴充套件：VS Code marketplace 有基本審查、但 community-published 擴充套件的供應鏈仍是個人視角。Continue.dev 安裝與 multi-provider 配置見 1.3。
3. Ollama Modelfile 中的指令：Modelfile 內可以指定 template、system prompt 等、若使用社群分享的 Modelfile、要看完內容再用。

MCP server 的權限模型詳見 6.2 tool use 與 MCP server 的權限模型。

事實查核註：MCP（Model Context Protocol）的安全模型仍在演進、各 MCP server 實作的權限粒度、認證機制依版本變化、建議引用前以 MCP 官方文件 跟具體 MCP server 的 README 為準。

給讀者的判讀流程

實際下載 / 切換模型時的判讀流程：

1. 確認來源 organization / namespace：是 official、知名量化者、還是個人上傳。
2. 比對檔案完整性：對主流量化等級、HF / Ollama 通常提供 hash；下載完做一次 hash 比對。
3. 記錄 hash 到本機 inventory：建一份 ~/models/inventory.md、記錄每個 GGUF 的來源 URL、下載日期、SHA-256。
4. 試模型基本行為：用簡單 prompt 確認模型行為合理。
5. 若是新 MCP server：分開判讀供應鏈（看 6.2）、不要把 GGUF 跟 MCP 的信任邊界混在一起。

下一章

下一章：6.1 推論伺服器的綁定與暴露範圍、處理伺服器跑起來後的第一個對外接觸面。

概念位置

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 治理。

驗證日期：2026-05-12 ComfyUI：main branch、shallow clone 示範模型：Stable Diffusion XL base 1.0（6.5 GB、stabilityai/stable-diffusion-xl-base-1.0） Python：3.14（venv 隔離、不污染系統）

前置設定

ComfyUI 在 Apple Silicon 跑 Diffusion 用 MPS（Metal Performance Shaders）backend、不需要 NVIDIA CUDA。但跑 SDXL 至少要 12 GB 統一記憶體留給 model + activation、16 GB Mac 跟其他 app 一起會吃緊。

Clone ComfyUI

放在 ~/Projects/ 下、跟其他 dev project 同層：

1cd ~/Projects
2git clone --depth 1 https://github.com/comfyanonymous/ComfyUI.git
3cd ComfyUI

--depth 1 只拉最新 commit、不拉全部歷史、省幾百 MB。要追歷史 / submit PR 才需要 full clone。

ComfyUI 目錄結構（核心部分）：

 1ComfyUI/
 2├── main.py              # 啟動 entry point
 3├── server.py            # HTTP server
 4├── nodes.py             # 內建節點實作
 5├── custom_nodes/        # 第三方 / 客製節點放這
 6├── models/
 7│   ├── checkpoints/     # SD / SDXL 主 model 檔放這
 8│   ├── loras/           # LoRA 微調權重
 9│   ├── vae/             # VAE 模型
10│   ├── controlnet/      # ControlNet 模型
11│   └── ...
12├── output/              # 生成的圖
13├── input/               # 拖進 ComfyUI 的圖片
14└── requirements.txt

建 venv + 裝 dependencies

ComfyUI requirements 含 PyTorch、numpy、PIL、safetensors、einops 等、套件多、版本敏感。用 venv 隔離：

1cd ~/Projects/ComfyUI
2python3 -m venv venv
3source venv/bin/activate
4python --version  # 確認在 venv 內
5pip install --upgrade pip

裝 dependencies：

1pip install -r requirements.txt

實測時間：10-15 分鐘（torch + 各種 dep）、首次跑會編譯部分 C extension。完成後預期看到：

1Successfully installed Mako-... MarkupSafe-... Pillow-... PyOpenGL-... ...
2  torch-... torchvision-... torchaudio-... ...
3  safetensors-... transformers-... ...

驗證 PyTorch + MPS：

1python -c "import torch; print('torch:', torch.__version__, 'mps:', torch.backends.mps.is_available())"
2# torch: 2.x.x mps: True

mps: True 表示 Apple Silicon GPU 加速可用。

下載 SDXL base 模型

SDXL base 約 6.5 GB、是 Stable Diffusion XL 的基礎 model。從 Hugging Face 拉到 ComfyUI 的 models/checkpoints/：

1mkdir -p ~/Projects/ComfyUI/models/checkpoints
2cd ~/Projects/ComfyUI/models/checkpoints
3
4# -L 跟 redirect、--continue-at - 支援中斷後重續、避免 6.5 GB 重下
5curl -L --continue-at - -o sd_xl_base_1.0.safetensors \
6  "https://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0/resolve/main/sd_xl_base_1.0.safetensors?download=true"

下載時間視網速、10-30 分鐘 broadband 都正常。網路中斷時重跑同一個指令、--continue-at - 會從中斷處續傳、不用重下 6.5 GB。完成後：

1ls -lh sd_xl_base_1.0.safetensors
2# 6.5 GB

可選的進階模型：

SDXL 6.5 GB 是「能驗證 + 不過大」的甜蜜點。再小可以選 SD 1.5（4 GB）、跑 Flux 要 24 GB 磁碟 + 16 GB+ 統一記憶體。

啟動 ComfyUI Server

1cd ~/Projects/ComfyUI
2source venv/bin/activate
3python main.py

預期輸出：

1[Prompt Server] Starting ComfyUI...
2Total VRAM 32768 MB, total RAM 32768 MB
3pytorch version: 2.x.x
4Set vram state to: SHARED
5Device: mps
6Using sub quadratic attention for cross-attention
7...
8Starting server
9To see the GUI go to: http://127.0.0.1:8188

Apple Silicon 統一記憶體被 PyTorch 報成 VRAM 是預期、不是 bug：mps backend 把整個統一記憶體當成「GPU 可見記憶體」、所以 32GB Mac 顯示 Total VRAM 32768 MB。實際使用上 ComfyUI、其他 app 跟系統共用同一塊。

關鍵驗證：

• Device: mps → Apple Silicon GPU 啟用
• Starting server + http://127.0.0.1:8188 → server 跑了

開瀏覽器到 http://127.0.0.1:8188、看到節點式 UI 就成功。第一次開啟會載入預設 workflow（一個簡單 text-to-image）。

要對外暴露（讓 LAN 內其他機器連）：

1python main.py --listen 0.0.0.0 --port 8188

跟 0.7 隱私資料流 提的一樣、0.0.0.0 等於暴露給整個區網、家用 OK 公共網路要小心。

跑第一張圖

ComfyUI 預設 workflow 是 text-to-image：

1. CheckpointLoader 節點：選 sd_xl_base_1.0.safetensors。
2. CLIPTextEncode（Prompt）節點：輸入 prompt、例如 a photograph of a cat sitting on a wooden chair, natural lighting。
3. CLIPTextEncode（Negative）節點：輸入 negative prompt、例如 blurry, low quality, artifacts。
4. EmptyLatentImage 節點：設定 1024×1024（SDXL 最佳尺寸）。
5. KSampler 節點：steps=20、cfg=7、sampler=euler 或 dpmpp_2m。
6. VAEDecode 節點：把 latent 轉成 RGB image。
7. SaveImage 節點：存到 output/。

點右側 panel 的 Queue Prompt、開始生成。

實測時間（M4 Pro 32GB、SDXL base、1024×1024、MPS backend）：

16GB Mac 跑 SDXL：每張 60-180 秒、可能會降頻。

生成完成後在 output/ 看到 PNG 檔（如 comfyui-test_00001_.png）。

用 REST API 直接生成（不開瀏覽器）

GUI 適合互動探索、自動化要走 REST API。完整 script 在 scripts/comfyui-test/generate.py、實際驗證指令：

1cd ~/Projects/blog
2python3 scripts/comfyui-test/generate.py --steps 15

腳本流程：

 1def build_workflow(prompt_text, neg_text, steps):
 2    return {
 3        "3": {"inputs": {"seed": 42, "steps": steps, "cfg": 7.0, "sampler_name": "euler",
 4                         "scheduler": "normal", "denoise": 1.0,
 5                         "model": ["4", 0], "positive": ["6", 0],
 6                         "negative": ["7", 0], "latent_image": ["5", 0]},
 7              "class_type": "KSampler"},
 8        "4": {"inputs": {"ckpt_name": "sd_xl_base_1.0.safetensors"},
 9              "class_type": "CheckpointLoaderSimple"},
10        "5": {"inputs": {"width": 1024, "height": 1024, "batch_size": 1},
11              "class_type": "EmptyLatentImage"},
12        "6": {"inputs": {"text": prompt_text, "clip": ["4", 1]},
13              "class_type": "CLIPTextEncode"},
14        "7": {"inputs": {"text": neg_text, "clip": ["4", 1]},
15              "class_type": "CLIPTextEncode"},
16        "8": {"inputs": {"samples": ["3", 0], "vae": ["4", 2]},
17              "class_type": "VAEDecode"},
18        "9": {"inputs": {"filename_prefix": "comfyui-test", "images": ["8", 0]},
19              "class_type": "SaveImage"},
20    }

workflow JSON 結構解釋：

• 每個 key（“3”、“4”、…）是節點 ID。任意整數字串、只要在 workflow 內唯一即可。
• class_type：節點類型（KSampler、CheckpointLoaderSimple、CLIPTextEncode 等）、ComfyUI 內建。
• inputs：節點參數。標量值（如 1024、"euler"）直接寫；連到別的節點輸出用 [node_id, output_index] 形式。
• ["4", 0] 表示「節點 4 的第 0 個 output」。CheckpointLoaderSimple 有三個 output：model（0）、clip（1）、vae（2）、所以 ["4", 0] 是 model、["4", 1] 是 clip、["4", 2] 是 vae。

每個節點做什麼：

• 4 CheckpointLoaderSimple：載 SDXL safetensors、輸出 model / clip / vae 三個東西。是整條 graph 的根。
• 5 EmptyLatentImage：建一張 1024×1024 的空白 latent tensor（不是 RGB 圖、是 4-channel latent space tensor）。SDXL 的 「畫布」。
• 6 CLIPTextEncode (positive)：把 prompt 文字用 CLIP text encoder 轉成 conditioning vector。
• 7 CLIPTextEncode (negative)：同上、但是 negative prompt（要 avoid 的特徵）。
• 3 KSampler：核心 denoising loop。15-30 個 step、把 latent 從噪聲變成跟 conditioning 對齊的 latent。
• 8 VAEDecode：把 latent 用 VAE 解碼成 RGB 圖（1024×1024×3）。
• 9 SaveImage：寫 PNG 到 output/ 目錄、檔名 prefix comfyui-test。

為什麼 graph 結構這樣：

• 為什麼 model / clip / vae 從同一個 checkpoint 拿：SDXL 設計上三個元件互相 train、必須同源。從不同 checkpoint 拿會造成生成品質崩。
• 為什麼 EmptyLatentImage 不直接接 KSampler、要設 batch_size：保留 batch 維度、未來要 batch generation（一次生 4 張）改 batch_size: 4 就好、其他節點不用改。
• 為什麼 sampler 用 euler、scheduler 用 normal：最簡單的組合、SDXL base 上品質可預測。其他選項（dpmpp_2m、karras scheduler 等）品質可能更好但效果各模型不同。
• 為什麼 cfg=7.0：classifier-free guidance scale。SDXL 的標準預設、太低（< 3）模型忽略 prompt、太高（> 12）過 saturated。
• 為什麼 seed=42：固定 seed 讓結果可重現。每次跑同 prompt 同 seed 同 model 結果完全一樣——是調 prompt / 比較 model 的必要條件。

 1def main():
 2    workflow = build_workflow(args.prompt, args.neg, args.steps)
 3    client_id = str(uuid.uuid4())
 4    resp = http_post_json("/prompt", {"prompt": workflow, "client_id": client_id})
 5    prompt_id = resp["prompt_id"]
 6
 7    while True:
 8        time.sleep(2)
 9        history = http_get_json(f"/history/{prompt_id}")
10        if prompt_id in history:
11            outputs = history[prompt_id].get("outputs", {})
12            break
13
14    img = outputs["9"]["images"][0]
15    qs = urllib.parse.urlencode({"filename": img["filename"], "type": "output"})
16    blob = http_get_bytes(f"/view?{qs}")
17    Path(args.out).write_bytes(blob)

每段做什麼：

1. client_id = str(uuid.uuid4())：每個 client 識別碼。ComfyUI 用 client_id 把 progress events 路由給正確 WebSocket subscriber。本 demo 用 polling、client_id 隨意產生即可。
2. POST /prompt：送 workflow + client_id、server 回 prompt_id（這次 job 的 UUID）。Server 把 workflow 丟進 internal queue、立刻 return、不會等 generation。
3. while True: time.sleep(2); GET /history/{prompt_id}：polling 等 job 完成。完成的 job 才會出現在 /history 裡（執行中 / queued 都不算）。
4. if prompt_id in history：完成判讀——history 內出現該 prompt_id 表示 generation 結束。
5. outputs["9"]["images"][0]：節點 9 (SaveImage) 的輸出、含 filename、subfolder、type 等資訊。
6. /view?filename=...&type=output：拿生成的 PNG bytes。type=output 是 ComfyUI 的內部 dir 標記（區分 output / input / temp）。

為什麼這樣設計：

• 為什麼 polling 而不是 WebSocket：WebSocket 要 subscribe events、處理 connection lifecycle、邏輯複雜。Polling 兩行解決、對教學 demo 夠用。Production 自動化系統建議用 WebSocket、知道每個 progress event。
• 為什麼 time.sleep(2)：太短（< 1s）對 server 造成不必要 polling；太長（> 5s）感知延遲明顯。2 秒是 demo 友善平衡。
• 為什麼用 prompt_id 而不是 client_id 查 history：一個 client 可能送多個 job、prompt_id 唯一識別 job。client_id 主要用 WebSocket 訂閱、不是 history query 主鍵。
• 為什麼 Path(args.out).write_bytes(blob)：PNG 是 binary、用 write_bytes 直接寫；改用 open(...).write() 的 text mode 會在編碼轉換時破壞檔案內容。

實測：M4 Pro 32GB、prompt 「a photograph of an orange cat sitting on a wooden chair, soft natural lighting, detailed fur」、15 steps、cfg=7、euler+normal sampler、seed=42 → 106 秒生成 1024×1024 PNG、1.65 MB。

ComfyUI 的 REST API 形狀（無 OpenAI 相容層）

ComfyUI 沒提供 OpenAI 相容 API、它的 API 是自己的 REST + WebSocket：

• POST /prompt：丟一個 workflow JSON、回傳 job id。
• GET /history/{prompt_id}：查看生成結果。
• GET /view?filename=X：拿生成的圖。
• WebSocket：訂閱 job progress events。

API 形狀跟 Diffusion 任務匹配、跟 LLM 的 /chat/completions 完全不同——這正是 4.1 RAG 章節 提到「Diffusion 跟 Transformer 工具鏈互不通用」的具體展現。Ollama / LM Studio 對接 Continue.dev 的 OpenAI 相容路徑、跟 ComfyUI 接 SDXL 是完全平行的兩條路。

常用 Custom Nodes

ComfyUI 的核心功能來自 custom nodes、社群維護。最常用：

安裝方式（透過 ComfyUI-Manager）：

1cd ~/Projects/ComfyUI/custom_nodes
2git clone https://github.com/ltdrdata/ComfyUI-Manager.git
3# 重啟 ComfyUI、UI 多一個 Manager 按鈕、之後用 Manager 裝其他 node

常見坑

Python 版本太新、torch 沒 wheel

PyTorch 對最新 Python（3.13、3.14）的 wheel 發布有 lag、可能 pip install -r requirements.txt 跑 build from source 慢 + 失敗。退到 Python 3.11 / 3.12：

1brew install python@3.11
2python3.11 -m venv venv
3source venv/bin/activate
4pip install -r requirements.txt

mps: False、跑在 CPU 上

確認 PyTorch 是 Apple Silicon 版本（不是 x86_64 emulation）：

1python -c "import platform; print(platform.machine())"
2# arm64 ← 正確；x86_64 ← 走 Rosetta、要重裝

如果是 x86_64、表示 venv 用了 Intel Python。重建 venv：

1deactivate
2rm -rf venv
3arch -arm64 python3 -m venv venv

記憶體不夠、推論時 crash

SDXL 在 16 GB Mac 上吃緊、可能 swap 或 crash。緩解：

1# 降解析度
2python main.py --normalvram   # 預設、~12 GB
3python main.py --lowvram      # 較省、~8 GB、慢
4python main.py --novram       # 極省、~4 GB、極慢、實用上界

或換 SD 1.5（4 GB checkpoint）、記憶體需求 < SDXL 的一半。

Workflow JSON 載入失敗

ComfyUI workflow 是 JSON 描述節點 + 連線。如果是別人分享的 workflow、可能用了你沒裝的 custom node。錯誤訊息會列出缺哪些 node、用 ComfyUI-Manager 補裝。

Port 8188 被佔

1lsof -i :8188
2python main.py --port 8189  # 改 port

跟 LLM stack 並存

ComfyUI 用 port 8188、跟 Ollama (11434) / LM Studio (1234) 完全不撞、可同時跑。實務配置：

各服務獨立、不干擾、可以一台 Mac 跑全部（看記憶體預算）。

何時這篇會過時

• ComfyUI 主分支 API 短期內穩定（大量社群依賴）。
• SDXL base 1.0 不會消失、但會被新版本（SDXL 1.1、Flux 等）取代——「下載 .safetensors 放 models/checkpoints/」流程不變。
• MPS backend 持續優化、效能會提升、但介面不變。
• Python 版本相容性會持續演化、pip install -r requirements.txt 偶爾要降版 Python。

讀的時候若 pip install 失敗、看 ComfyUI GitHub issues 跟 PyTorch release notes 對應的 Python 版本。

跟其他 hands-on 章節的關係：完整 hands-on 系列見 Hands-on 章節索引、跨服務的 lifecycle / 記憶體管理見 Resource management、ComfyUI 跟 Ollama 同台跑的記憶體預算規劃見 0.5 Apple Silicon 記憶體預算。

概念位置

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 一覽：