AI Agent 應用2026.03.26

LLM 到底怎麼運作?Transformer 架構白話解

Transformer 架構是 GPT、Claude、Gemini、Llama 所有主流 LLM 的共同基礎。這篇用白話拆解它的核心機制 — attention 怎麼運作、token 怎麼計價、context window 怎麼影響產品設計 — 目的是讓你能判斷「這個需求 LLM 做不做得到、成本合不合理」。

為什麼需要搞懂 LLM 的運作原理

一個具體場景:老闆問你「AI 能不能幫客服自動回覆?」你要怎麼判斷?

不懂原理的回答是「應該可以吧,ChatGPT 很厲害」。懂原理的回答是:「可以,但要看幾個條件 — 知識庫有多大(決定要不要用 RAG)、回答需不需要精確數字(LLM 不擅長計算)、客戶問題有沒有超出訓練資料範圍(會產生幻覺)、每月預估查詢量多少(影響 API 成本)。」

兩種回答的差距,就是理解運作原理帶來的判斷力。以下拆解 LLM 的五個核心概念。

深度拆解

Transformer 之前的世界

2017 年之前,自然語言處理的主流架構是 RNN(Recurrent Neural Network)。RNN 的做法是逐字處理文本 — 讀完第 1 個字才能讀第 2 個字,讀完第 99 個字才能讀第 100 個。

這個設計有兩個致命問題。

記憶衰減。處理一段 500 字的文章,RNN 到後半段就記不住前半段的關鍵資訊。技術上叫「梯度消失」(vanishing gradient)— 訊號在長序列中逐漸衰減到接近零。1995 年發明的 LSTM(Long Short-Term Memory)加了「記憶閘門」機制來緩解,但本質沒變。

無法平行運算。第 100 個字必須等前 99 個字處理完才能開始。類比:一條生產線上只有一個工人,每個零件按順序處理。LSTM 是給這個工人一本筆記本讓他記更多東西,但他還是只有一個人。GPU 再多也沒用,因為架構本身是序列的。

Attention 機制 — LLM 的核心引擎

2017 年,Google 團隊發表了 “Attention Is All You Need”(Vaswani et al.),提出 Transformer 架構,直接解決上述兩個問題。

核心思路的差異:RNN 是「一個字一個字讀」,Transformer 是「整段話同時看,然後判斷哪些字跟哪些字有關係」。

舉例:「那隻貓沒有追老鼠,因為不餓」。Self-attention 機制能直接判斷「牠」指的是「貓」而不是「老鼠」,不需要從頭逐字推理。

技術上,每個 token 會產生三個向量 — Query(我在找什麼)、Key(我能提供什麼)、Value(我的實際內容)。透過 Query 和 Key 的比對算出 attention score,決定每個 token 該關注其他哪些 token、關注多少。這不只做一次 — Multi-Head Attention 同時用多組 attention 平行運算,每組捕捉不同類型的關係:有的抓文法結構,有的抓語義關聯,有的抓長距離引用。

為什麼這是革命性的?兩個原因:

  • 平行處理:整個句子的所有 token 同時處理,GPU 的平行運算能力終於能被充分利用。原始論文用 8 張 GPU 訓練 3.5 天就在機器翻譯上超越當時所有最佳模型(WMT 2014 英法翻譯 BLEU 41.8 分)
  • 長距離依賴:能理解跨越整篇文章的引用關係,RNN 做不到

現代 LLM 幾乎都是 Decoder-only 架構(GPT、Claude、Llama、Gemini 皆是)。原始 Transformer 的 Encoder-Decoder 設計主要用在翻譯等任務,而 Google 2018 年的 BERT 是少數 Encoder-only 的代表,主要用於理解任務(分類、情感分析)而非生成。

Token 與 Context Window — 直接影響產品設計和成本

LLM 不是逐字處理文本,而是切成更小的單位叫 token。一個 token 大約是 4 個英文字元,或 0.75 個英文單詞。中文大約 1-2 個字佔 1 個 token(Unicode 編碼較複雜,效率比英文差)。不同模型用不同的 tokenizer(OpenAI 用 tiktoken,Anthropic 和 Google 各有自己的),同一段文字在不同模型上可能產生不同數量的 token — 這直接影響 API 費用計算。

Context Window(上下文窗口)是模型一次能處理的最大 token 數量,包含輸入和輸出。2026 年主流模型的 context window:

  • Claude 系列:200K tokens
  • GPT-5 系列:128K tokens
  • Gemini 2.5 Pro:1M tokens(目前最大)

Context window 越大不代表越好。塞太多資訊可能降低品質(「大海撈針」問題 — 關鍵資訊被大量無關內容淹沒)。如果需求超過 context window 上限,就需要考慮 RAG(Retrieval-Augmented Generation)等架構。

Next Token Prediction — LLM 真正在做的事

這是理解 LLM 最重要的一個概念:LLM 的本質就是「預測下一個 token」。

給它一段文字,它預測最可能接在後面的下一個 token。生成完整回答的過程是:預測第一個 token → 加到輸

入裡 → 預測第二個 token → 以此類推。這叫自迴歸生成(autoregressive generation)。

它不是「理解」問題然後「思考」答案,而是基於訓練數據中的統計模式預測最可能的下一個 token。Temperature 參數控制這個預測的隨機性 — 設 0 永遠選機率最高的(確定但可能重複),設 1 按機率分佈隨機取樣(多樣但可能偏題),實務上通常設 0.3-0.7。

理解這個本質,能直接推導出 LLM 的能力邊界:

  1. LLM 不是資料庫。它不「儲存」事實,而是學到文本中的統計模式。所以它可能很有自信地說出不正確的事(幻覺 / hallucination)
  2. 知識截止日。訓練資料有時間範圍,超過的事情它不知道
  3. 不擅長精確計算。它在做 token 預測,不是數學運算
  4. 輸出品質高度依賴 prompt 品質。同一個模型,不同的 prompt 可以產生天差地遠的結果

模型大小 vs 能力 vs 成本 — 三角取捨

Scaling Law 的核心發現:增加模型參數數量、訓練資料量和計算量,模型表現會可預測地提升。GPT-2(2019)1.5B 參數,GPT-3(2020)175B 參數,GPT-4(2023)推測數千億到兆級。但不是無限線性提升 — 存在收益遞減。

更值得注意的是湧現能力(Emergent Abilities):模型到達某個規模後,突然展現出小模型完全沒有的能力 — 少量範例學習(few-shot learning)、思維鏈推理(chain-of-thought)、程式碼生成。這讓模型的能力邊界變得難以預測。

但能力越強,成本越高。2026 年 3 月的主流模型 API 定價:

模型 輸入(每百萬 token) 輸出(每百萬 token) Context Window
Claude Opus 4.6 $5.00 $25.00 200K
Claude Sonnet 4.6 $3.00 $15.00 200K
Claude Haiku 4.5 $1.00 $5.00 200K
GPT-5.2 $1.75 $14.00 128K
GPT-4o Mini $0.15 $0.60 128K
Gemini 2.5 Pro $1.25 $10.00 1M
Gemini 2.0 Flash Lite $0.075 $0.30 1M

幾個省錢策略:輸出 token 比輸入貴 3-8 倍,限制最大輸出長度直接省錢。Prompt caching 讓重複使用的 system prompt 省下最多 90% 的費用。最有效的是模型路由(routing)— 簡單任務走便宜模型,複雜任務才用貴的,通常能省 60-80%。

我的觀點

理解「next token prediction」這個本質,能幫你快速判斷一個任務適不適合用 LLM。

文本摘要、分類、改寫、翻譯 — 這些本質上都是「給一段文字,預測最可能的輸出」,跟 LLM 的運作機制高度匹配。精確計算、即時數據查詢、需要 100% 正確性的場景 — 這些跟 token 預測的本質衝突,強行使用會出問題。

最常見的 AI 專案失敗原因不是技術不行,是需求端沒搞清楚 LLM 能做什麼。LLM 像一個讀過大量資料的實習生 — 語言能力極強、知識面很廣,但可能會自信地說出錯誤的事、不會做數學、也不知道昨天發生了什麼。用對場景它是超強工具,用錯場景它是昂貴的錯誤來源。

常見問題 FAQ

不懂程式的人需要理解 Transformer 架構嗎?

不需要理解數學細節,但需要理解設計邏輯。你不需要知道 attention score 的計算公式,但需要知道:LLM 能同時「看見」整段文字並判斷關聯性(所以擅長理解上下文)、它是靠 token 預測運作的(所以會產生幻覺)、context window 有上限(所以資料量太大需要其他方案)。這三個認知就足夠你做出合理的技術決策。

怎麼判斷一個任務適不適合用 LLM 來做?

問三個問題。第一,這個任務的本質是不是「給一段輸入,產生一段文字輸出」?如果是,LLM 大概能做。第二,容錯空間有多大?如果錯一次就會造成嚴重後果(醫療診斷、法律條文引用),LLM 單獨使用風險很高。第三,需不需要即時數據?LLM 有知識截止日,需要即時資訊的場景要搭配外部資料來源(如 RAG)。

評估一個 AI 專案可行性,最少要問哪些問題?

五個最基本的。資料有多大?(決定 context stuffing 還是 RAG。)輸入輸出是什麼語言?(影響 token 成本,中文比英文貴。)每月預估多少次呼叫?(算 API 月費。)容錯率多少?(決定需不需要人工審核環節。)有沒有現成的 API 或工具能直接用?(不是所有問題都需要從零建 pipeline。)

相關文章

AI Agent 應用
AI 系統做完了然後呢?從 UAT 到 Rollout 的導入實戰紀錄
2026.03.25
AI Agent 應用
AI 專案撞牆紀錄:零成本社群監測的天花板在哪裡
2026.03.25
AI Agent 應用
AI 系統架構設計:為什麼我選純 API 不用 Agent 框架
2026.03.25
AI Agent 應用
不懂當地語言怎麼做海外市場?一個品牌人的 AI 解決方案拆解
2026.03.25