530 - 大型語言模型 (LLM) on 嗡嗡的隨手筆記

【LLM #2】LLM 跟 Encoder / Decoder 的關係 — 為什麼主流 LLM 都是 decoder-only？

Wed, 22 Apr 2026 14:00:00 +0800

前言

寫完上一篇【LLM #1】什麼是 LLM 後，
我腦中其實冒出一個蠢問題：

欸，Transformer 原本不是有 encoder 跟 decoder 嗎？
那現在 LLM 都去哪了？為什麼大家講 GPT 都說它是「decoder-only」？
那 encoder 是不是失業了？ 🫠

查了一下發現這題其實滿多人搞不清楚的，
於是就順手整理成筆記給自己 XD。
（我還是菜，如果有地方寫錯歡迎糾正！）

Transformer 的原始長相（2017 版）

先來個老派的回憶。2017 年那篇著名的「Attention is All You Need」，
原始 Transformer 架構其實不是為了 chatbot 設計的，它是為了機器翻譯。

所以它天然長成這樣：

[輸入句子]  →  Encoder  →  (壓縮後的語意表示)  →  Decoder  →  [輸出句子]

「I love cats」  →  Encoder  →  [...向量...]  →  Decoder  →  「我愛貓」

Encoder：把輸入句吃進去、理解它、壓成一堆向量
Decoder：參考 encoder 給的向量，一個字一個字生出來

用白話比喻：

Encoder 像是「閱讀理解」的人：讀完整段，抓到意思

Decoder 像是「寫作」的人：參考理解好的結果，一邊寫一邊看自己已經寫了什麼

Encoder 跟 Decoder 的關鍵差異

兩邊都用 attention 機制，但注意力的「看法」不同：

特性	Encoder	Decoder
注意力方向	雙向（可看前後所有字）	單向（只能看已生成的前文）
典型任務	理解、分類、embedding	生成、續寫
訓練目標	填空題（mask 掉某個字讓它猜）	接龍（預測下一個字）
輸出結果	一堆向量（高維語意表示）	一連串 token（看得懂的文字）

Decoder 只能看「過去」這件事非常重要，
因為它要模擬「一邊寫一邊決定下一個字」的過程，
不能作弊偷看答案（未來的字），才不會在真的 inference 時失靈。

後來 Transformer 被拆成三個家族

慢慢地，大家發現「不一定要 encoder + decoder 一起用」，
不同任務適合不同變形：

家族	代表模型	擅長的事
Encoder-only	BERT	理解類任務：分類、情感分析、命名實體辨識 (NER；從句子抓出人名、地名、公司名)、語意搜尋
Decoder-only	GPT 系列、Claude、Llama、Qwen、Gemini	生成類任務：寫作、對話、程式碼
Encoder-Decoder	T5、BART、原始 Transformer	明確的「輸入→輸出」轉換：翻譯、摘要

順帶一提（知道會更好，這篇不展開）：

BERT 後來有 RoBERTa、DeBERTa 等變形，訓練策略微調後效果通常更好

T5 / BART 則是 encoder-decoder 在 LLM 時代的代表作，聊三大家族時常被一起提

Encoder-only：閱讀理解專家

BERT 就是代表，2018 出來那時超有名。
這類模型不會自己生東西，你丟一段文字進去，它還你一組向量，
你再接一個小小的 classifier 去做分類。

適合：句子分類、情感分析、命名實體辨識 (NER)、語意搜尋
不適合：要生成一段話（要逼它做會很痛苦）

Decoder-only：一直接龍的模型

這是 GPT、Claude、Llama 的家族。
它的訓練方式很「暴力美學」：看到 N 個字，猜第 N+1 個字。

就這樣用全世界的文字練上幾千億次後，它就學會了語言。

適合：幾乎所有語言任務（只要會轉成「給我接下去寫」的形式）
不適合：~~（好像沒什麼不適合的？這就是它贏的原因 XD）~~

Encoder-Decoder：原汁原味派

T5、BART 這類。明確區分「輸入」和「輸出」。

適合：有明確 source → target 的任務，例如翻譯、摘要、文法糾正
不適合：開放式對話（因為它習慣「轉換」而不是「延續」）

為什麼現在主流 LLM 都是 decoder-only？

這是我一開始最想不通的點。既然 encoder 這麼擅長理解，
為什麼不用 encoder-decoder 來做 LLM？答案大概有三層：

1. 一把刀切所有東西：prompt 就能扮演 encoder

Decoder-only 的 prompt 前半段，其實就在做 encoder 的工作。

舉個例子：

請把下面這段英文翻成中文：
I love cats.
→

模型在讀「請把下面這段英文翻成中文」+「I love cats」的時候，
就等於在做理解（等同 encoder 的工作）；
讀完後開始輸出「我愛貓」，這才是生成（decoder 的工作）。

換句話說，decoder-only 是把 encoder 跟 decoder 合併成同一個東西。
一個模型就能做「理解 + 生成」，不用養兩套。

2. Scaling 友善：參數集中在一邊

Encoder-decoder 要維持兩邊的連結（cross-attention），
架構比較複雜，也不太好擴展到超大規模。

Decoder-only 架構單純：一個 stack 堆到底，
scaling law 的實驗也更好做，這在「大就是好」的 LLM 時代是硬優勢。

3. In-context learning 是意外大禮

OpenAI 在 GPT-3 發現一件超威的事：

只要在 prompt 裡塞幾個範例，
decoder-only 模型就能「臨時學會」新任務，
不用重新訓練 — 這就是 few-shot / in-context learning。

這個能力基本上只有 decoder-only 做得到，
而這個能力又徹底改變了 LLM 的使用方式（prompt engineering 就是從這時開始熱門的）。

那 encoder 是不是就失業了？

並沒有 XD。Encoder 在 2026 年依然活得好好的，只是分工變了：

Search / RAG 系統裡的 embedding：用 encoder 把文件變向量做語意搜尋，這塊 encoder 還是主力（生產環境常見的 embedding 模型如 OpenAI 的「text-embedding-3-large」、開源的「bge-m3」，底層都是 encoder）。
輕量的分類任務：BERT 家族在生產環境依然很常見，因為便宜、快、夠用。
專門的翻譯 / 摘要系統：encoder-decoder 架構（T5、BART）依然有優勢。

只是在「通用對話 AI」這個最吸睛的戰場，decoder-only 勝出了。
就像內燃機跟電動車 — 不是內燃機不會動，是電動車在主流乘用市場贏了。

小結

整理完這題，我自己的一點小心得：

Encoder 跟 decoder 是「工具差別」不是「好壞差別」
Decoder-only 贏了是因為它「夠泛用」，不是因為它「最強」

這讓我想起寫程式時的老話：

能用少的組件解決的問題，就不要硬加架構。

Decoder-only 用一個 stack 解決「理解 + 生成」兩件事，
架構簡單、scaling 容易、prompt 就能切換任務 —
在「什麼都要做」的大語言模型時代，這組特性真的太加分。

Reference

【LLM #1】什麼是 LLM (Large Language Model)？給自己的一點入門筆記

Wed, 22 Apr 2026 10:00:00 +0800

前言

最近 AI 工具真的滿山滿谷，
ChatGPT、Claude、Gemini… 感覺不用一下就會被時代丟在後面 🫠

說實在自從 2023 年後，我自己也是大量在用這些工具，
但我發現我好像都「會用」但沒有真的「理解」這些東西是什麼，
於是就想來寫一篇給自己看的筆記 XD。

這篇文章不會深入到數學公式或 Transformer 架構，
純粹是從「使用者」角度，把我自己常被問的幾個關鍵字整理一下。
如果你也是剛開始接觸 LLM 的朋友，希望對你有幫助！

什麼是 LLM？

LLM = Large Language Model，中文翻作大型語言模型。

一句話版本：

一個「吃了超多文字」之後，學會「接下一個字」的機率模型。

然後這個「超多文字」真的是超多，
通常是整個網路上能抓到的大部分公開文本 (書、論文、維基、Reddit、GitHub… 什麼都有)，
模型參數量動輒幾十億 (B) 到幾千億 (T)。

所以它不是真的「理解」什麼事情，
而是「統計上」知道下一個字最有可能是什麼 — 只是這個統計好到讓我們覺得它在思考 XD

常見混淆：LLM ≠ encoder-decoder 架構

這邊順便釐清一個很多人會搞混（包括以前的我）的地方。

有人問「LLM 是什麼？」時，反射動作常常會從架構角度答：
「它是 Transformer，有 encoder 跟 decoder…」

這個回答其實不太精準。

LLM 最核心的定義是它「做什麼」，不是「怎麼做」。
最乾淨的版本就是上面那句：「能一直接下一個字的大模型」。

現代主流 LLM（GPT、Claude、Llama 家族）架構上其實都是 decoder-only，沒有 encoder。
「encoder-decoder」的印象來自 2017 年原始的 Transformer 論文（那篇是為機器翻譯設計的），
但 LLM 後來演化成另一種樣子了。

架構是實作細節，定義是它做什麼。
講定義時先給「生下一個字」，架構的部分可以之後再補。

這題其實滿值得展開，我寫在了系列第二篇：【LLM #2】LLM 跟 Encoder / Decoder 的關係。

LLM 能做什麼

老實說目前大家也還在摸索邊界，但以我日常用到的來看：

寫程式：寫 code、debug、解釋別人的 code、不同程式語言互轉
整理資訊：摘要長文、抓重點、翻譯、改寫
文字創作：寫文章初稿、email、slogan、社群貼文
閱讀助手：丟一份論文/文件問它裡面的內容
Agent 類應用：串工具 (檔案系統、瀏覽器、API) 幫你跑任務

對我個人影響最大的其實不是「產出」，
而是「能隨時問一個不會不耐煩的對象」這件事 XDD

幾個一定會遇到的關鍵字

Token

LLM 不是用「字」或「word」在算，而是用 Token (子詞)。

英文大約 1 個 token ≈ 0.75 個單字
中文常常 1 個字 ≈ 1~2 個 token (看 tokenizer)

為什麼要知道這個？

因為 LLM 的計費、輸入長度限制，通通是按 token 算。

Context Window

又叫做「上下文視窗」，指的是模型一次最多可以「看進去」多少 token。

常見的幾個數字：

早期 GPT-3.5：4K tokens (差不多幾千字)
現在主流：128K ~ 200K tokens
部分旗艦：1M tokens (可以丟整本小說進去)

超過 context window 的內容，模型就「看不到」了，
這也是為什麼長對話久了會覺得它開始「失憶」的原因。

Prompt

就是你丟給模型的輸入。

聽起來很簡單，但其實「怎麼寫 prompt」本身已經演化成一門學問，
大家叫它 Prompt Engineering。
簡單的心法：

把「角色」、「任務」、「限制條件」、「輸出格式」講清楚
給 1~2 個範例 (few-shot) 通常會比空口白話好很多

Hallucination (幻覺)

這是 LLM 最有名的毛病：

它會「一本正經地胡說八道」，
語氣非常自信，但內容是錯的、甚至是它自己編的。

所以重要的事情還是要驗證，尤其是：

具體的人名、書名、論文、API 規格
法律、醫療、財務類建議
冷門領域的事實

用 LLM 的一個心態我覺得滿重要：
把它當成「很強但有點唬爛的實習生」，
能大幅提升效率，但不能全然信任。

常見的幾家 LLM

快速流水帳版本 (2026 年初視角)：

家族	公司	特色
GPT 系列	OpenAI	最有名，生態最大
Claude 系列	Anthropic	長文處理、寫作品質我自己最愛
Gemini 系列	Google	多模態強，整合 Google 產品
Llama 系列	Meta	開源大宗，能自己部署
Qwen / DeepSeek	阿里 / DeepSeek	中文開源模型代表
Mistral	Mistral AI	歐洲開源，小而美

我的使用習慣是 Claude 寫東西、GPT 問一些快答案、
本地小任務跑 Qwen 之類的開源模型，
看你的需求與預算來選就好！

小結：以「做筆記的站長」視角看 LLM

這個網站的初衷是「幫我自己整理筆記」，
AI 崛起後我一度懷疑這件事還有沒有意義 (畢竟什麼都可以問 LLM 了 🫠)，
但用了這麼多它之後，我反而覺得：

LLM 給的是「即時但可能錯」的答案
自己的筆記是「慢慢累積但被自己驗證過」的答案

兩者並不衝突，甚至互補 —
我現在常常把 LLM 當成「第一層草稿機」，
然後再自己整理成能放上網站的筆記，效率高很多。

佛系經營 + AI 輔助，似乎是個滿舒服的組合 🌿