LLM 基本原理：token、上下文、溫度、成本、幻覺

核心概念圖（流程圖）

Step 0：先理解 LLM 的預測流程（輸入 → token 化 → 機率 → 輸出），再開始定義角色、任務與輸出格式，這張圖為 prompt 設計奠定背景。

必懂概念

• Prompt（提示詞）： 你給模型的任務說明與上下文指令。它通常包含「角色、目標、限制、輸出格式、範例」，寫得越清楚，模型輸出越穩定。
• Token： 模型處理文字的最小單位，成本通常以 token 計價。它不是單純「一個詞」就等於一個 token，而是由模型的分詞器（tokenizer）切分：英文常見會接近詞或詞片段（例如 playing 可能被切成 play + ing），中文則常是單字或雙字詞片段（例如「人工智慧」可能被切成「人工」+「智慧」，也可能依模型切成更多片段）。實務上計費通常是「輸入 token + 輸出 token」一起算，所以 prompt 越長、回覆越長，成本就越高。
• 上下文（Context Window）： 模型一次能「看見」的 token 上限。
• 溫度（Temperature）： 溫度越高，模型越可能走創意與發散路線，內容可能更天馬行空，也更容易出現不夠精準或不夠有根據的敘述；溫度越低，模型通常更保守穩定，回答更可控、更接近可驗證資訊。若是知識問答、技術說明、文件生成，通常建議先用較低溫度。
• 推理成本： 輸入 token + 輸出 token 共同決定費用與延遲。
• 幻覺（Hallucination）： 語句看似合理但內容可能不真實。
• 回答迴圈（Response Loop）： 模型在同一語意附近重複輸出、一直繞圈或重述，通常是生成控制或上下文設計問題，和「事實對錯」不完全相同。

實務建議

• 要穩定：溫度先用 0~0.3。
• 要省錢：先縮短 prompt、限制輸出長度。
• 要降幻覺：要求「引用來源」或改用 RAG。
• 要控延遲：優先小模型 + 明確輸出格式（JSON）。

補充：幻覺 vs 回答迴圈

• 幻覺重點在內容真偽：看起來合理，但可能是錯誤資訊。
• 回答迴圈重點在輸出行為：一直重複同一段、同一觀點或同一語句模式。
• 兩者可能同時出現，但排查方式不同：幻覺要加來源驗證；迴圈要調整提示詞、上下文長度與輸出限制。

提示詞工程（Prompt Engineering）怎麼做？

• 先定角色： 先指定模型身份與工作邊界，例如「你是資深 Java 架構師，請用條列方式回答」。
• 再定任務： 明確說明要完成什麼，避免模糊要求，例如「比較 A 與 B，輸出 3 個差異與 1 個建議」。
• 加上限制： 限制字數、語氣、不能做的事，例如「不超過 200 字、避免行銷語、無法確認就明說」。
• 指定輸出格式： 直接要求 JSON、表格或固定段落，能大幅降低回覆漂移。
• 給 1~2 個範例（Few-shot）： 讓模型知道你心中的「好答案長相」。

實務最常用模板：角色 + 任務 + 限制 + 輸出格式 + 範例。這個結構通常比只丟一句問題更穩。