Token、Embedding、Context Window 是什麼？LLM 基礎一次搞懂（2026 完整懶人包）

為什麼中文 prompt 比較貴？context 都 1M 了，模型怎麼還是會漏看？這篇帶你一次搞懂模型開口之前的三個機制，附兩個不用 API key 的小實驗！

做 LLM 應用的人，遲早會問到這兩個問題。

第一個：同一份客服 prompt，中文版的 token 數就是比英文版多，帳單也跟著多。中文明明字比較少，為什麼比較貴？

第二個：模型的 context 已經到 100 萬 token，整本規章放得進去。可是問第 40 頁的那條規定，模型回答得很篤定，引的卻是另一條。放進去了，為什麼還會漏看？

這兩件事常被算在「模型不夠聰明」頭上。其實它們在模型開始生成之前就決定了一大半：文字先被切成 token；要找資料時，另一個模型把文字轉成向量、挑出最像的幾段；挑出來的東西再排進 context。三個機制，各有一種固定的出錯方式。

這張圖也先釐清一件常被混在一起的事：模型內部有向量，檢索系統也有向量，兩者是不同的東西。下面依序拆這三個機制，每個都附一個你可以自己驗證的方法。

快速回答 中文多花多少 token、檢索找錯版本、長文漏看，在模型開口前就決定了，換更強的模型修不好。token 數由 tokenizer（把文字切成片段的工具）的詞表決定：同一段繁中，OpenAI 的 cl100k_base 切出 222 個 token，為繁中擴充詞表的 Breeze 7B 只要 106 個。檢索用的 embedding 模型只比像不像，不管哪份是現行版本；context 放得下，不代表用得到。這些要在系統裡量、篩、挑。

Token 由詞表決定：繁中在舊版 tokenizer 是英文的 1.73 倍，擴充詞表可降至 0.82 倍

模型不認得「字」。文字進來之後，tokenizer 先把它切成一段一段的片段（token），每個片段對到一個編號，模型只處理這些編號。API 的計費、context window 的上限，單位都是 token。

現在主流的切法叫 BPE（Byte Pair Encoding，位元組對編碼）。它的做法很樸素：先把所有文字拆成最小單位，在一大堆訓練文字裡數哪兩個相鄰單位最常一起出現，就把它們合成一個新單位；再數、再合，一直合到詞表大小用完為止。2016 年 Sennrich 等人把這個壓縮演算法拿來切詞；2019 年的 GPT-2 再往下推一層，從 256 個位元組開始合，這樣任何語言、任何符號都切得進去，不會有「不認得的字」。

這個做法有一個直接的後果：誰在訓練文字裡出現得多，誰就被合得多。英文常見字整個字就是一個 token；出現得少的字，合不起來，只好拆成好幾個位元組片段。

用 tiktoken 打開兩個 OpenAI 的 tokenizer 看看。舊的 cl100k_base（GPT-4、GPT-3.5 用的）把「臺灣」切成 4 個片段，兩個字都被拆開；新的 o200k_base（GPT-4o 之後的模型用的）切成「臺」「灣」兩個。「退貨申請」在舊版是 8 個片段，新版 4 個。罕見一點的字，例如「鬱」，新版還是要 2 個片段。

所以第一個問題的答案是：中文每個 token 的單價和英文一樣，貴在切出來的數量；數量取決於這個 tokenizer 的詞表，而詞表是從它的訓練文字長出來的。

同一個機制也解釋了另一個常見的怪現象：模型數不準字數。請它寫 300 字，常常寫成 260 或 350；問 strawberry 有幾個 r，舊模型常答錯。o200k_base 把 "strawberry" 切成 st、raw、berry 三片，模型從頭到尾沒有看到過一個一個的字母，中文字也一樣，它看到的是片段的編號。研究上對「數錯」的主因還有爭論：有些論文指向 tokenization，也有研究認為難的是「計數」這個動作本身。但工程上的結論相同：字數要用程式數，不要請模型數。

小實驗一：同一段內容，四個 tokenizer 各切幾個

說法要能驗證。這個實驗不需要 API key，只要 Python 和網路（第一次會從 Hugging Face 下載 tokenizer 檔）。

想驗證的三件事：

1. 同樣的內容，繁中切出的 token 比英文多。
2. 繁中比簡中多。
3. 差距主要來自 tokenizer 的詞表：換一個為繁中擴充過詞表的 tokenizer，差距會縮小甚至反轉。

跑出來如果不是這樣，上面的說法就要改。

前提假設：一段約 166 字的繁中內容（一段退貨規定，加一段說明文字），逐句對應寫成簡中與英文（114 個英文字）。只用一段文字，所以倍數會隨內容變動，這個實驗只看方向。比較四個 tokenizer：

先安裝套件，再準備三種語言的同一段文字：

pip install tiktoken transformers sentence-transformers

import tiktoken
from transformers import AutoTokenizer

TEXTS = {
    "繁中": "退貨申請須在收到商品後七天內提出，並附上訂單編號與商品照片。客服確認商品狀況後，款項會在五個工作天內退回原付款方式。若商品已拆封或有使用痕跡，將酌收整理費用。"
          "模型在讀文字之前，會先把句子切成一段一段的小單位。常見的詞會被合成一個單位，少見的字則可能被拆成好幾個位元組。同一段內容換一種語言寫，切出來的數量可能差很多，帳單也跟著不同。",
    "簡中": "退货申请须在收到商品后七天内提出，并附上订单编号与商品照片。客服确认商品状况后，款项会在五个工作天内退回原付款方式。若商品已拆封或有使用痕迹，将酌收整理费用。"
          "模型在读文字之前，会先把句子切成一段一段的小单位。常见的词会被合成一个单位，少见的字则可能被拆成好几个字节。同一段内容换一种语言写，切出来的数量可能差很多，账单也跟着不同。",
    "英文": "Return requests must be made within seven days of receiving the item, with the order number and photos of the item attached. Once customer service has checked the item's condition, the refund will be sent back to the original payment method within five business days. If the item has been opened or shows signs of use, a restocking fee will be charged. "
          "Before a model reads any text, it first cuts each sentence into small pieces. Common words are merged into a single piece, while rare characters may be split into several bytes. Write the same content in another language and the number of pieces can differ a lot, and so can the bill.",
}

接著寫一個小函式：OpenAI 的編碼直接用 tiktoken，開源模型的 tokenizer 從 Hugging Face 載入。兩邊都只數內容本身，不加開頭結尾的特殊 token。

def counter(name):
    if name.endswith("_base"):
        enc = tiktoken.get_encoding(name)
        return lambda s: len(enc.encode(s))
    tok = AutoTokenizer.from_pretrained(name)
    return lambda s: len(tok.encode(s, add_special_tokens=False))


TOKENIZERS = {
    "OpenAI o200k_base": "o200k_base",
    "OpenAI cl100k_base": "cl100k_base",
    "Mistral 7B": "mistralai/Mistral-7B-v0.1",
    "Breeze 7B": "MediaTek-Research/Breeze-7B-Instruct-v1_0",
}
for label, name in TOKENIZERS.items():
    count = counter(name)
    t = {lang: count(text) for lang, text in TEXTS.items()}
    print(f"{label:20s}", "  ".join(f"{k} {v:3d}（{v / t['英文']:.2f} 倍）" for k, v in t.items()))

最後順手看一下切出來的片段長什麼樣子，前面提到的 strawberry 和「臺灣」就是這樣看的：

enc = tiktoken.get_encoding("o200k_base")
for word in ["strawberry", "臺灣", "退貨申請"]:
    pieces = [enc.decode_single_token_bytes(i) for i in enc.encode(word)]
    print(word, [p.decode("utf-8", errors="replace") for p in pieces])

結果畫成圖：

三件事都成立，第三件最明顯。舊的 cl100k_base 下，繁中是英文的 1.73 倍、簡中 1.36 倍；換到 o200k_base，繁中降到 1.16 倍，簡中幾乎和英文一樣。Breeze 7B 則把順序整個翻過來：繁中只要英文的 0.82 倍，比簡中還省。

這和公開的研究方向一致。牛津大學 Petrov 等人 2023 年用 200 種語言的同一批句子比較，簡體中文在 cl100k_base 下的 token 數約是英文的 1.91 倍。OpenAI 在 2024 年發表 GPT-4o 時，也特別列出新 tokenizer 讓中文範例句從 34 個 token 降到 24 個。

台灣這邊有兩個公開的例子。Breeze 7B 的技術報告寫到，他們在 Mistral 的 32,000 個 token 之外，用中文語料跑 BPE、另外加了 29,873 個 token；報告自述在中文語料上的壓縮率約為原本的 2 倍，訓練與推論速度也快了約 2 倍。國科會的 TAIDE 第一版（以 Llama 2 為底）在模型說明裡寫到，額外擴充了 24,720 個中文字元與字詞。兩者做的是同一件事：讓繁中常見的字詞也能被合成一個 token。

對做應用的人，這代表三件事：第一，估成本時用目標模型的 tokenizer 實際數一次，不要用字數換算；第二，同一個 context window，繁中能放的內容比英文少；第三，換模型的時候 token 數可能跟著變，預算要重估。Anthropic 在價目說明裡就寫到，Claude Opus 4.7 之後的模型換了新的 tokenizer，同一段文字大約會多出 30% 的 token。

Embedding 檢索只比語意像不像：4 種問法有 3 種把已失效的舊規定排第一

「embedding」這個詞在 LLM 的討論裡指兩種東西，先分開。

第一種在模型裡面。每個 token 編號會先查表變成一個向量，再經過一層一層的運算，變成考慮上下文之後的表示。這些向量是模型內部用來預測下一個 token 的表示，並非設計來比較兩句話像不像。

第二種是檢索系統用的 embedding 模型，它是另一個、通常小很多的模型。它被訓練成：意思相近的兩段文字，轉出來的向量也要靠近。2019 年的 Sentence-BERT 論文就是在處理這件事：直接把 BERT 內部的輸出平均起來當句子的向量，在語意相似度測試上的分數（54.81）還輸給把 GloVe 詞向量平均的老方法（61.32），要另外訓練才好用。現在做 RAG（檢索增強生成，先找資料再回答）時，把文件和問題轉成向量、算距離、挑最近的幾段，用的都是第二種。

問題在於它學到的是「像不像」。一條規定是不是現行版本、有沒有被新規定取代、這個使用者有沒有權限看，這些都不在「像不像」裡面。

小實驗二：現行規定會贏過語意很像的舊版嗎

想驗證的事：使用者問「現在」的規定時，embedding 會不會把措辭跟問題比較像的舊版排在現行版前面。

前提假設：四份文件，一個小型的多語 embedding 模型（paraphrase-multilingual-MiniLM-L12-v2，支援約 50 種語言、含繁中，把一段文字轉成 384 維的向量，一般筆電的 CPU 就能跑），用餘弦相似度排序。

舊版的措辭是刻意的：它用了「退貨期限」這四個字，和使用者常用的問法一樣。真實的文件庫裡，舊版和新版常常就是這樣，內容只差一個數字，寫法卻各有不同。

程式接在小實驗一後面。把文件和問題都轉成長度為 1 的向量，內積就是餘弦相似度：

from sentence_transformers import SentenceTransformer

DOCS = {
    "現行規定（2026 年起）": "自 2026 年 1 月 1 日起，商品須在到貨後 7 天內提出退貨，逾期恕不受理。",
    "舊版規定（2024 年）": "退貨期限：收到商品後 30 天內都可以申請退貨。",
    "換貨規定": "換貨期限：收到商品後 14 天內可申請換貨。",
    "點數規定": "會員點數可在結帳時折抵，每 1 點折 1 元。",
}
QUERIES = ["現在退貨期限是幾天？", "最新的退貨規定是什麼？", "買了東西多久內可以退？", "2026 年的退貨期限是幾天？"]

model = SentenceTransformer("sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2")
doc_vecs = model.encode(list(DOCS.values()), normalize_embeddings=True)
for q in QUERIES:
    scores = doc_vecs @ model.encode(q, normalize_embeddings=True)
    ranked = sorted(zip(DOCS, scores.tolist()), key=lambda x: -x[1])
    print(q, " > ".join(f"{name} {s:.3f}" for name, s in ranked))

結果：

四種問法裡，三種把舊版排第一。「現在」「最新」對 embedding 來說只是兩個詞，它不會因此去找日期比較新的那份。第三種口語問法更糟，連換貨規定都排在現行規定前面。只有問題裡剛好寫了「2026」，現行規定才贏，靠的是字面上剛好重疊。

另外拿兩個更大的多語模型（multilingual-e5-small、bge-m3）跑同一組資料，「現在退貨期限是幾天」這一題，兩個也都把舊版排第一；bge-m3 在「最新」那一題選對了，但分數差距很小。這個實驗只有四份文件，數字本身的絕對值沒有意義，要看的是兩件事：第一，分數差距常常只有零點零幾，排名很脆弱；第二，現行與否這件事，從頭到尾不在相似度的計算裡。

所以「找到現行版本」這件事，要交給相似度以外的機制：文件帶上生效日與版本欄位，檢索前先篩掉已失效的；或在排序之後，用規則或另一個模型再核對一次。這些是系統設計的問題，下一篇會接著談。

Context 放得下不代表用得到：完整對話全塞進去，GPT-4.1 答對率從 87.3% 掉到 62.4%

Context window 是模型這一次推論看得到的全部 token：系統指令、對話紀錄、檢索出來的段落，加上它要寫的回答。這兩年它變得很大，到 2026 年 10 月，Claude、Gemini、GPT 的旗艦模型都在 100 萬 token 上下。很多人因此覺得：既然放得下，就全部放進去，不用再挑。

兩份研究告訴你為什麼不行。

第一份是史丹佛等單位 2023 年發表、2024 年刊登在 TACL 的〈Lost in the Middle〉。他們給 GPT-3.5-Turbo 20 份文件，其中一份有答案，然後移動這份文件的位置。答案在第 1 份時，答對率 75.8%；移到第 10 份，掉到 53.8%，比一份文件都不給、讓模型自己憑記憶回答的 56.1% 還低。放在最後一份，回升到 63.2%。開頭和結尾看得比較清楚，中間容易漏。

第二份是向量資料庫公司 Chroma 在 2025 年 7 月發表的〈Context Rot〉。他們測了 18 個模型，包括 GPT-4.1、Claude 4、Gemini 2.5 和 Qwen3，結論寫得很直接：在他們所有的實驗裡，輸入越長，表現就越差，而且任務本身很簡單，例如把一段重複的文字照抄一遍。其中一個實驗用 LongMemEval 這組長對話問答題：同樣 306 題，一種只給和問題相關的段落（平均約 300 token），一種給完整的對話紀錄（平均約 11 萬 token）。依 Chroma 公開的 GPT-4.1 結果檔計算，前者答對 87.3%，後者 62.4%。

Chroma 還有兩個發現，和前一節直接相關。第一，只要加一條「看起來很像答案、其實不是」的干擾句，表現就會比沒有干擾時差。第二，當要找的那句話和周圍的文字語意很接近、混在一起時，模型比較難找到它。換句話說，context 越長，模型要在越多「很像」的段落裡挑出對的那一段，前一節 embedding 遇到的問題，在模型裡又出現一次。

所以第二個問題的答案是：context 的大小決定放不放得下，模型用不用得到，取決於放了什麼、放在哪裡、放了多少。Chroma 測的每個模型都有這個現象，換一個更新的模型，這件事多半還在。

實務落地的三個關鍵決策：實測 Token 預算、按結構切 Chunk、依更新頻率選檢索

上面三個機制，落到專案裡是三個要先做的決定。

決定一：token 預算怎麼估

一次呼叫的 token，是系統指令、檢索段落、對話紀錄、模型回答四塊加起來，每一塊都要算。

• 用目標模型的 tokenizer 實測，不要用字數換算。OpenAI 的模型可以用 tiktoken；開源模型用它在 Hugging Face 上的 tokenizer；其他廠商多半有計算 token 的 API。上面的實驗裡，同一段繁中在不同 tokenizer 下差了一倍。
• 繁中先抓 1.2 到 1.8 倍英文的預算，再用自己的資料實測修正。這個區間是上面實驗的結果，只能當起點。
• 替回答留空間：context 上限包含模型要寫的回答，輸入塞滿了，回答就會被截斷。
• 查清楚長度怎麼計價：有些模型超過某個長度後，整個請求的單價會變高。例如 OpenAI 的價目表把超過 272K 輸入 token 的請求算成長 context，單價較高；Anthropic 則寫明 Claude 4.6 之後多數模型在 100 萬 token 內同一個單價。門檻各家不同，也常改，以當時的價目表為準。
• 長對話要定期收斂：對話紀錄是最容易默默變長的一塊。每隔幾輪把舊紀錄摘要成重點，或只保留和目前任務有關的部分。
• 字數用程式數：產品要求「回答 200 字以內」，就在程式裡數、超過就重寫或截斷，不要相信模型自己的估計。

決定二：chunk 怎麼切

做檢索時，文件要先切成一塊一塊（chunk）再轉向量。切法直接決定找不找得到。

• 依文件結構切：規章一條一塊、FAQ 一題一塊、手冊一個小節一塊。固定每 500 字一刀，很容易把一條規定的條件和例外切到兩塊裡。
• 一塊回答一件事：塊太大，向量會被好幾個主題平均掉，什麼都像一點；塊太小，缺少上下文，看不出它在講哪條規定。
• 對齊 embedding 模型的長度上限：小實驗二用的模型最多只讀 128 個 token，超過的部分直接截掉，後半段等於沒被索引。選模型時先查它的上限，再決定一塊切多大。
• 每塊帶上身分：文件名稱、章節路徑、版本、生效日、來源編號。這些欄位讓你在檢索前篩掉失效的版本，也讓回答能附上出處。
• 補一句上下文：Anthropic 2024 年公開的 Contextual Retrieval 做法，是在建索引前替每一塊補一小段「這塊出自哪份文件、在講什麼」的說明；他們的實驗裡，前 20 筆找不到正確段落的比例降了 35%。
• 拿舊版來考它：建好之後，刻意準備幾組「新舊版本並存」的問題，看現行版本是否排在前面。小實驗二就是這個測試的縮小版。

其中「補一句上下文」這一步，Anthropic 在原文畫成一張流程圖：切塊照舊，只是每一塊在進索引之前，先由 Claude 讀過整份文件，替它寫一段說明。

換句話說，切法不必改，改的是每一塊進索引時帶了什麼；代價是建索引時每一塊都要多讓模型讀一次全文。

決定三：直接放長 context，還是先檢索

兩者不互斥，常見的做法是先檢索、再把挑出來的段落放進一個夠大的 context。但起手式可以依下表判斷：

不管選哪一邊，都有幾個共通的做法：把最重要的資料（任務規則、關鍵條文）放在開頭或結尾；不相關的歷史紀錄別帶著走；能先篩掉的就先篩掉。Chroma 那組 87.3% 對 62.4% 的差距，大部分來自「只放相關的段落」這一個動作。

破除三個常見誤解：中文不等於一字一 Token，向量最像不等於現行，Context 大仍得篩選

「中文一個字就是一個 token」。在 o200k_base 下，上面那段繁中平均一個字約 0.9 個 token；在 cl100k_base 下約 1.3 個。常見詞會合成一個，罕見字會拆成兩三個片段，平均數會隨內容變動。

「向量資料庫找到的，就是最相關的」。它找到的是最像的。像，是措辭和主題接近；相關，還要是現行的、你有權限看的、真的回答了問題的。後面這幾件事要另外設計。

「context 夠大，就不用挑資料」。放得下只是第一關。資料放的位置、總長度、裡面有多少相似的干擾，都會影響模型用不用得到。

結論：問題多在模型開口前就已發生，先量 Token、測檢索並清理 Context，別急著換模型

這三個機制有一個共同點：它們都發生在模型開口之前，問題也多半出在這裡。所以下一次遇到中文太貴、找錯版本、長文漏看，先別急著換模型。用目標模型的 tokenizer 數一次，用一組新舊版本並存的問題考一次檢索，把 context 裡不相關的東西拿掉一次。這三件事加起來不用一個下午，做完之後，你會知道問題出在哪一層。

模型會越來越強，但它看到的，永遠是你切好、挑好、排好的那些 token。

這三個機制怎麼組合成一個系統、什麼時候該用檢索、什麼時候該寫成固定流程或交給 Agent，接著讀〈RAG、Workflow、Agent 差在哪？什麼時候真的需要 Agent？（2026 完整比較）〉。

常見問題

為什麼中文的 token 比英文多？

主流的 BPE 切法會把訓練文字裡常一起出現的片段合成一個 token；出現得少的字合不起來，就拆成好幾個片段。token 單價一樣，中文貴在數量。用一段約 166 字的繁中測，cl100k_base 切出的 token 是對應英文的 1.73 倍，新的 o200k_base 是 1.16 倍。只用一段文字，只看方向。

估 LLM API 成本時，中文要抓多少 token？

用目標模型的 tokenizer 實際數一次，不要用字數換算。沒數之前，繁中可以先抓英文的 1.2 到 1.8 倍當起點，再用自己的資料修正；為繁中擴充詞表的 Breeze 7B 反而比英文少。換模型要重估：Anthropic 說 Claude Opus 4.7 之後換了新 tokenizer，同一段文字約多 30% 的 token。

向量檢索為什麼會找到舊版的規定？

檢索用的 embedding 模型被訓練成比「像不像」，哪份是現行版本不在計算裡。在一個四份文件的小實驗裡，四種問法有三種把措辭較像的舊版排第一，「現在」「最新」只被當成兩個詞。要讓文件帶上生效日與版本欄位，檢索前先篩掉失效的，或排序後再用規則核對。

context window 有 100 萬 token，資料還需要挑嗎？

要。〈Lost in the Middle〉的實驗裡，GPT-3.5-Turbo 拿到 20 份文件，答案在第 1 份時答對 75.8%，移到第 10 份剩 53.8%。Chroma 2025 年測 GPT-4.1：只給相關段落答對 87.3%，給完整對話紀錄（約 11 萬 token）只剩 62.4%。重要資料放開頭或結尾，無關的拿掉。

延伸閱讀

• RAG、Workflow、Agent 差在哪？什麼時候真的需要 Agent？（2026 完整比較）
• Context Engineering 是什麼？Agent 一直犯同樣的錯怎麼辦？（2026 完整懶人包）
• 新模型出來了要不要換？AI 功能答錯時，換模型多半沒用（2026 除錯懶人包）
• AI Demo 很成功，為什麼一上線就出事？五條失敗路徑一次看懂（2026）

參考資料

Tokenizer 與 BPE

• Rico Sennrich, Barry Haddow, Alexandra Birch (2016). Neural Machine Translation of Rare Words with Subword Units. ACL 2016.
• Alec Radford et al. (2019). Language Models are Unsupervised Multitask Learners. OpenAI（GPT-2，byte-level BPE）.
• Aleksandar Petrov, Emanuele La Malfa, Philip H.S. Torr, Adel Bibi (2023). Language Model Tokenizers Introduce Unfairness Between Languages. NeurIPS 2023.
• OpenAI (2024-05-13). Hello GPT-4o（Language tokenization 一節）.
• OpenAI. tiktoken（model.py 的模型與編碼對應，2026-10-16 檢視）.
• MediaTek Research (2024). Breeze-7B Technical Report. arXiv；詞表說明另見 Breeze-7B-Instruct-v1_0 模型說明.
• TAIDE. TAIDE-LX-7B 模型說明（Hugging Face，2026-10-16 檢視）.
• Tairan Fu et al. (2024). Why Do Large Language Models (LLMs) Struggle to Count Letters?. arXiv.
• Xiang Zhang, Juntai Cao, Chenyu You (2024). Counting Ability of Large Language Models and Impact of Tokenization. arXiv.

Embedding 與檢索

• Nils Reimers, Iryna Gurevych (2019). Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks. EMNLP 2019.
• sentence-transformers. paraphrase-multilingual-MiniLM-L12-v2（模型說明，2026-10-16 檢視）.
• Anthropic (2024-09-19). Introducing Contextual Retrieval.

長 context

• Nelson F. Liu et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the ACL 12, 157–173.
• Anthropic. Pricing（long context pricing 與 tokenizer 說明）、Models overview（2026-10-16 檢視）.
• OpenAI. Pricing（short／long context 分界，2026-10-16 檢視）.
• OpenAI. Models；Google. Gemini models（context window 規格，2026-10-16 檢視）.
• Kelly Hong, Anton Troynikov, Jeff Huber, Chroma (2025-07-14). Context Rot: How Increasing Input Tokens Impacts LLM Performance；結果檔見 chroma-core/context-rot.