Learning Objectives
- 用 user／assistant 訊息對在提示詞裡放範例（few-shot）
- 要求模型列出步驟，比較答對次數與 token 用量
- 舉出範例與步驟沒有幫助的情況
- 用同一題多跑幾次、用標註資料算準確率，而不是只看一次回答
兩個常見的技巧，以及怎麼判斷它們有沒有用
上一課把提示詞寫清楚。這一課看兩個常見的技巧：
- Few-shot： 在提示詞裡放幾個「輸入 → 正確輸出」的範例。Brown 等人 2020 年介紹 GPT-3 的論文 Language Models are Few-Shot Learners，就是用文字提示和少量示範來指定任務，不重新訓練模型。
- 逐步推理（chain-of-thought）： 讓模型先寫出中間步驟再給答案。Wei 等人 2022 年的論文 Chain-of-Thought Prompting Elicits Reasoning in Large Language Models 在提示詞裡放含有推理過程的範例，在算術、常識與符號推理的任務上看到明顯的進步。
這兩篇研究用的是當時的模型，結果不能直接套到今天的模型。我們的範例也比較簡單：逐步推理只加一句指令，沒有放完整的範例。
所以這一課不直接告訴你「這樣寫比較好」，而是用 gpt-5.6-luna 實際測，也測它們沒有幫助的情況。回答是 2026-11-03 錄下來的真實輸出。
逐步看：範例有用的任務與沒用的任務
範例是放在 messages 裡的 user、assistant 訊息對，看起來就像之前的對話。
這裡有兩個任務：課表代碼的格式是我們虛構的，只看文字猜不到；分信的類別意思很清楚。
範例適合用來說明格式與規則
| 任務 | 沒範例 | 有範例 |
|---|---|---|
| 課表代碼（格式是自訂的） | 3 次都不對，還有三種不同格式 | 3 次都對 |
| 分信（類別意思清楚） | 4 / 4，輸入 247 tokens | 4 / 4，輸入 471 tokens |
第一個任務，範例說明了難以用文字描述的格式。第二個任務，模型本來就會，範例只讓輸入的 token 接近翻倍，而且每一次呼叫都要付這個費用。
接下來看比較麻煩的情況：標準是我們自己定的，而且不容易一句話說完。
逐步看：三種範例，各跑一輪 6 題
系辦要決定信的處理順序。我們虛構一個標準：三天內有期限是「今天」，三天後才到期是「本週」，沒有期限是「有空」。標準沒有寫進提示詞，只靠範例傳達。
第三組範例全部是「今天」。先猜猜看：它的結果應該最差嗎？
逐步看：同樣兩句各跑 5 次
上一個範例的 6 / 6 是真的嗎？挑出三種寫法答案不同的其中兩句，每種寫法各跑 5 次，把答案數一數。
另外說明：上一個範例原本有 8 句，為了控制範例大小才刪成 6 句，刪掉的兩句三種寫法都答對。8 句時的分數是 5 / 8、6 / 8、8 / 8，所以差距沒有 6 句時看起來那麼大。
只看一次會看錯
把上面的輸出整理成答對次數：
| 範例 | 「成績申訴」（正解本週） | 「英文姓名拼錯」（正解有空） | 合計 |
|---|---|---|---|
| 沒範例 | 2 / 5 | 0 / 5 | 2 / 10 |
| 平均的範例 | 1 / 5 | 0 / 5 | 1 / 10 |
| 只有今天的範例 | 5 / 5 | 1 / 5 | 6 / 10 |
這個結果有幾點值得注意：
- 6 / 6 有運氣成分。 「英文姓名」這句在第一輪答對，多跑幾次只有 1 / 5 答對。
- 我們的預期沒有出現。 我們原本以為全部是「今天」的範例會把答案帶偏，在這個測試裡沒有看到。這不代表範例不會帶來偏差，只代表這幾句、這幾次沒有看到，原因我們也不清楚。
- 放了平均的範例也沒有比較好。 只看這兩句，它甚至沒有贏過沒範例。
這裡只有 2 句、每組 5 次，而且是挑過的題目，不足以下結論說哪一種寫法比較好。比較提示詞時，要用夠多的標註資料、每種寫法跑多次、算出數字，第 20 課會把這件事做完整。
逐步看：要求列步驟，答對與費用怎麼變
一題要多步計算（84.78），一題很簡單（6）。每題每種指令各跑 5 次。注意答對次數，也注意輸出用了多少 token。
列步驟有幫助的地方，以及它的費用
| 題目 | 指令 | 答對 | 5 次的輸出 token |
|---|---|---|---|
| 加權平均 | 只回答數字 | 0 / 5 | 30 |
| 加權平均 | 列步驟 | 4 / 5 | 411 |
| 學分相加 | 只回答數字 | 5 / 5 | 20 |
| 學分相加 | 列步驟 | 5 / 5 | 80 |
- 這一題多步驟的計算，列步驟有明顯的差別。 不准寫過程時，五次答案都不對，彼此也不一致。
- 簡單的任務沒有差別， 只是輸出變成 4 倍。
- 列了步驟還是可能錯： 其中一次算成 83.22。
- 真的要計算，就交給程式。 加權平均用 Python 算一定對，也不花 token；第 15 課會讓模型呼叫工具來算。
順帶一提，「最後一行只寫答案」模型也不是每次都照做，5 次裡有一次寫成「答案：6」。程式解析時要留意，下面的實作題會處理這種情況。
提示詞不是越長越好
長度本身不是目標。每多一段都要回答：它解決了哪一個實際看到的錯誤？
| 情況 | 建議 |
|---|---|
| 模型本來就做得好 | 不加範例也不加步驟，省 token |
| 格式或標準難以用文字描述 | 加幾個範例，再用標註資料確認有改善 |
| 多步驟的推理 | 要求列步驟，並把答案放在固定位置 |
| 精確計算 | 用程式算，不要靠模型 |
修改的流程：找出答錯的例子 → 改一處 → 用同一批資料重跑多次 → 看數字。一次改很多處，就不知道是哪一處有效。
實作：計算分類準確率
比較提示詞要靠數字。這一題不呼叫模型，ANSWERS 是寫死的回答字串。
完成兩個函數：
normalize(answer)：去掉前後空白，再拿掉類別：和。。accuracy(golds, answers)：逐題比較清理後的答案與正解。答錯時用起始碼註解裡的print印出來，最後回傳答對的比例。
小測驗：什麼時候有幫助
Few-shot 的範例在 Chat API 裡通常怎麼放？
「分信」任務裡，沒範例和有範例都是 4 / 4，這代表什麼？
第一輪 6 題，「只有今天的範例」答對 6 題。接著該怎麼做？
加權平均的題目，模型列步驟時 4 / 5 答對。實際應用裡最可靠的做法是什麼？
下面的程式會印出什麼？
gold = ["A", "B", "C", "D"]
got = ["A", "C", "C", "A"]
correct = 0
for i in range(len(gold)):
if got[i] == gold[i]:
correct += 1
print(correct / len(gold))
重點整理
- Few-shot 用 user／assistant 訊息對放範例，適合說明難以描述的格式與規則；模型本來就會的任務，範例只是多花 token。
- 要求列步驟對多步驟的題目有幫助，代價是輸出變多；簡單題沒有差別。列了步驟還是可能錯，精確計算要交給程式。
- 提示詞不是越長越好。每一段都要對應實際看到的問題。
- 同一題要多跑幾次，用標註資料算出數字。一次的滿分可能是運氣，直覺也可能猜錯。
下一課： 開始寫程式呼叫 Chat API，看 messages 與回應物件的細節。