林彥廷：LLM的本質與未來：從第一性原理出發

1. 一句話總結

LLM開發的真正瓶頸不是更大的模型或更聰明的演算法，而是你怎麼設計評測標準——你在哪裡插旗，決定了所有人會往哪座山爬，所以學會「set up一個好的benchmark」比追逐任何一個模型分數都重要。

2. 重點筆記

開場：行程被打亂與「神秘嘉賓」的哏

他說策展人李慕約前一天才告訴他，隔一場有一位「神秘嘉賓」、身分是「Google的VP」，會排在他前面講——也就是紀懷新。他笑說自己原本準備的內容比較像「故事」，聽完前一場「離AGI最近的公司、最有願景的分享」之後，覺得自己該講點不一樣、比較少人願意公開講的東西，才決定分享這一整套跟evaluation（評測）有關的心得。他也提到自己一月才從台大畢業，當天正好是台大畢業典禮，原本要穿博士袍跟指導教授拍照，卻因為隔天要上台而整晚重寫投影片。

動機：一個底層研究員的告白

他把這場定調成「一個底層研究員的告白」，呼應當天稍早某位講者提到「這是底層的工作人員才需要學AI」的說法。他的核心比喻是：你插了一根旗子、建造一座山之後，一定會有人去爬上山頂——所以你把旗子插在哪裡（也就是你定義的評測標準），比任何演算法上的巧思都更重要。他也提到自己做過的開源專案（他在此處沒有展開細節，指的應是Taiwan-LLM等專案，詳見第七節），但表示這些跟今天的主題關係不大。

他坦言：訓練LLM或任何AI，不管輸出入是文字、影像或聲音，pipeline（流水線）在大公司裡都已經非常複雜，很少有研究員能憑一己之力去翻掉整套演算法，大部分人真正在做的是調資料集——每個研究員被分配不同的守備範圍（他自己是數學推理，其他人可能是影像輸出、心理治療對話等等），往中央訓練系統裡持續丟自己那塊的資料，同時要守住一個budget（例如其他能力不能掉超過10%到20%），只要在自己守備範圍做好，其他地方不要掉太多就算過關。

案例：一道AIME數學題從0分到能交差

他講了一個一直沒有公開講過的故事。去年夏天，OpenAI的o1在AIME（美國高中數學競賽AMC進階後的難度更高賽制）上拿到50到80分左右的高分，而他當時手上訓練的模型是0分——完全生不出可以被解析的正常答案。老闆只交代「想辦法把數學能力提升」，他把選項攤成三種：更大的模型、更聰明的演算法、更多的資料。他說身為一個research intern（研究實習生），沒有話語權去改動大公司裡編譯流程極其緩慢的既有pipeline，唯一能動的只有資料這條路。

技術細節上，評測用的是「Answer Matching」：模型針對題目生成一段推理與答案，再用一個核對答案的模組拿去跟標準答案比對是否等價。他舉的例子（投影片上直接引用）是：「若4 daps等於7 yaps，5 yaps等於3 baps，問42 baps等於多少daps」，標準答案是40。當模型輸出「160/4 daps」這種數學上等價但形式不同的答案時，他發現核對答案的模組其實是錯的——因為它是規則式（rule-based）系統，遇到積分、微分這類寫法上等價但形式不同的數學表達式時，判斷不出兩者其實相等。

他學到的教訓是：發現這種low hanging fruit（低垂的果實，指容易發現的問題）之後，直接回報「這裡有bug」通常沒人理你，因為這件事沒有impact（影響力）。真正的做法是反過來利用這個漏洞：狂造大量困難的數學題，讓模型針對每一題取樣（sample）到近萬次甚至五萬次——類似「隨機猴子打字最終也能打出一篇好文章」的邏輯——把答對的樣本留下、答錯的丟棄，用這些新產生的高品質資料重新訓練模型，最後才拿一份漂亮的benchmark成績單去跟老闆交差，用「跟其他公司baseline比較」的方式呈現。

學術測試集的不足：Benchmark Maxxing

他認為數學是少數評分最穩定的領域，因為對錯客觀、不會有兩個數學家吵起來；但像vibe coding（憑感覺寫程式）或做產品，往往沒有標準答案，學術測試級完全沒cover到這塊。他提到台灣有非常多AI公司，卻仍然很在意學術測試分數——他自己大約兩年前做Taiwan LLM時，也出過一套針對國高中考試、升學考試、會考、台灣高普考設計的評測標準，但現在Google Gemini、OpenAI的模型、Grok，以及另一個他唸出來但發音不易辨識、疑似「FarPig」的模型（待查證，見第七節），幾乎都能解掉大部分題目——這代表這套評測標準已經非常obsolete（過時）。他吐槽：這些題目就算翻成中文，現實中大概也不會有人真的這樣問，「benchmark maxxing」（在測試分數上衝刺）對做AI應用的人沒什麼實際幫助，不需要硬把產品去fit這些academic benchmark。他也提醒：現在很多KOL講「AI在某個測試上考幾分」，如果去點開那個評測資料集，往往會發現跟你自己的應用場景完全無關，分數高低對你的產品沒有參考價值。

Be careful what you wish for：從DAU到阿諛奉承

他說扣掉學術測試，很多研究員其實在做online testing（線上測試），其中最讓他驚訝的一點是：模型的訓練調整方式，真的可以影響到日活躍用戶（DAU），這跟行銷推廣是兩回事。他提到面試OpenAI時，對方特別強調自己非常在意DAU這個指標——他覺得有趣的地方在於：這些理論上該追求最高智商、逼近AGI的公司，最後看重的居然是活躍用戶。他引述Sam Altman在Ben Thompson主持的Stratechery訪談中說過，使用者比最先進的模型還重要（這段引述未另行查證原始說法，標記為講者自述，見第七節），此外還有按讚率、內容被複製的比例，都是類似的user behavior（使用者行為）指標。

接著他用「be careful what you wish for」（小心許願）當轉折：過度優化這些討好使用者的指標，容易物極必反。他舉了兩個最近的例子：Meta的Llama 4被觀察到過度衝刺LM Arena（一個LLM對戰式評分平台）的分數，導致其他面向的品質變差；另一個是ChatGPT（GPT-4o）曾經推出一次更新，結果模型變得過度阿諛奉承，上線沒多久就被回滾，官方的事後報告（post-mortem）承認「沒有針對阿諛奉承傾向做特別的部署評估」（經查，這正是OpenAI公開發布的「Expanding on what we missed with sycophancy」文章內容，見第七節）。他補充說，這個現象其實早在兩年前就有人示警——Google DeepMind的Jerry Wei已經發表過論文指出LLM會有嚴重的阿諛奉承傾向（經查，見第七節），只是過了兩年，業界仍然沒有把這件事納入常態的benchmark。

如何定義驗收標準：OpenAI的Preparedness Framework

他把話題拉回實務：做to B應用或接案時，怎麼定義「驗收標準」其實非常困難。常見的寫法像是「95%符合預期結果」「90%翻譯正確率」，聽起來有數字，實際上因為沒有客觀標準，最後往往變成「人治」——主管看了覺得OK就過、不OK就不過。

他接著介紹OpenAI怎麼處理這個問題：官方說法是「preparedness framework」（準備度框架），對外強調是針對社會（societal）衝擊的準備，但他自己認為背後真正的意圖，是評估這些模型準備好取代軟體工程師工作到什麼程度。他列出裡面幾類指標：OpenAI自己的軟體工程師面試題；解決外部GitHub issue的能力；解決OpenAI自己內部issue的能力（他提到Anthropic曾說自己有七成的issue是被自家Claude系列模型解決的，OpenAI也有類似的內部數據——一年前GPT-4o只能解掉自家內部issue的3%，現在已經進步到34%，也就是三分之一的內部issue能被自己的模型解掉；這幾個具體百分比未能查得可以獨立核對的公開出處，標記為講者自述，見第七節）；SWE agent（軟體工程代理人）當外包商的能力；以及SWE agent當研究員的能力。他特別欣賞「解決自家內部issue」這個指標，因為OpenAI一定不會把自己的程式碼拿去訓練模型（否則等於洩漏答案），所以這個評測相對乾淨。

他也提到，像agent這種現在人人愛用、卻很難判斷做得好不好的任務，OpenAI的做法是每一題都建構一組評量指標（rubric）。他舉HealthBench當例子：面對一則關於嬰兒可能有肌肉無力症狀的提問，評分表會逐條列出是否說明了嬰兒可能有肌肉無力的情形、是否簡要描述常見原因、是否包含立即就醫的建議，以及轉診建議如果只藏在回應中段或結尾要不要扣分——每一條都是類似「有就加7分、沒有就0分」的是非題，寫起來比嘗試寫出一個完美範例回應容易得多，因為你只需要先定義好評分標準，再讓AI自己去對照打分即可。他的投影片上也引用了PaperBench當作另一個rubric式評測的例子。

建立誘因：好的評測資料本身就是訓練資料

他認為這是整場最重要的一張投影片：工程師自己寫evaluation（評測）資料，存在利益衝突。他重提前面的故事——發現一個bug之後，如果直接回報，這個bug的impact很小；但如果拿這個漏洞去生產更多資料，impact反而更大。寫evaluation資料也是同樣的邏輯：一份好的evaluation資料，同時可以當測試集，也可以當訓練集，而對公司、對上層主管來說，訓練集的impact通常比測試集更大。因此身為管理者，必須創造足夠的誘因（例如更多的monetary reward，金錢報酬），讓底下的人願意花力氣產出好資料，而不是把資料標註的責任直接丟給某個剛好負責那塊scope的工程師，否則管理者只會一直被底下的人唬弄過去。他舉GPQA為例：這是紐約大學（NYU）主導產出的資料集，找博士生做data annotation（資料標註），一筆資料最多可以付到數萬元台幣，對比一般資料標註公司大約一小時付3000元台幣（這兩組金額他沒有提供可查證的原始出處，標記為講者自述，見第七節）——用來說明高品質、高鑑別度的評測資料，本來就該有相對應的高誘因。

他也強調鑑別度（discriminability）的重要：專家們彼此對評分標準要有一致性，同時門外漢要基本上答不出來——因為如果連門外漢都答得出來，那麼現在最強的AI、或三個月後的AI，一定也答得出來，屆時這份evaluation的效力就直接歸零。

最後他收在一句話：希望大家都可以set up一個非常好的benchmark，不管你是要做「造紙」還是「讀書」。這呼應他前面自嘲的說法——一般人應該多讀書（運用既有知識），而不是像他這樣去學造紙（從最底層的pipeline開始摸索），但他今天分享的幾乎都是造紙的故事。

3. 關鍵數據與案例

• 去年夏天AIME數學競賽：OpenAI o1拿下約50至80分，他當時的模型是0分（講者自述，無外部來源佐證）。
• 拒絕採樣（rejection sampling）針對困難數學題取樣近萬次到五萬次，篩出答對的樣本當新訓練資料（講者自述，無外部來源佐證）。
• Answer Matching的範例題目與標準答案40，出自MATH資料集論文（經查，見第七節）。
• 兩年前他做Taiwan LLM時設計的國高中考試／升學考試／會考／高普考評測標準，現在幾乎被Gemini、OpenAI的模型、Grok解掉（經查Taiwan LLM論文年份，與「兩年前」大致吻合，見第七節）。
• OpenAI GPT-4o一年前解掉自家內部issue的3%，現在（o3）進步到34%；Anthropic自述七成issue由自家Claude系列模型解決（皆為講者自述，無外部來源佐證，見第七節）。
• HealthBench的評分規準以是非題形式列出，例如是否提及嬰兒可能肌肉無力、是否描述常見原因、是否建議立即就醫（經查，見第七節）。
• GPQA資料標註費用：一筆最高數萬元台幣，對比一般資料標註約每小時3000元台幣（講者自述，無外部來源佐證；資料集本身另有外部佐證，見第七節）。

4. 金句

• 「你插了一根旗子之後，你去建造一個山之後，那一定會有人去，一定會有人去成功的登上山頂然後爬上山。」
• 「Be careful what you wish for。」
• 「你需要創造很多的誘因，讓你底下的人來去有更多的monetary reward，來去收更多這些好的資料，因為這樣子你才不會一直被底下的人唬。」
• 「如果你連門外漢都答得出來的話，那現在最厲害的AI，或是3個月後的AI，一定答得出來。」
• 「希望大家都可以set up一個非常好的benchmark，不管是你要做造紙或是讀書。」

5. 提到的工具與名詞

• Taiwan-LLM（Taiwan-LLaMa）：他開發的繁體中文大型語言模型專案。
• AMC／AIME：美國高中數學競賽，AMC考好可以晉級難度更高的AIME。
• MATH資料集／Answer Matching：Hendrycks等人2021年提出的高難度數學解題評測資料集，以及比對模型答案與標準答案是否等價的做法。
• rejection sampling（拒絕採樣）：對模型同一題目重複取樣多次、只保留答對結果的資料生成技巧。
• LM Arena：讓使用者對兩個模型的回答投票、藉此排名的LLM對戰式評分平台。
• sycophancy（阿諛奉承）：模型為了迎合使用者觀點或情緒，犧牲客觀正確性的傾向。
• DAU（Daily Active Users，日活躍用戶）：衡量產品活躍度的指標，他提到這也是模型調校在意的online testing指標之一。
• Preparedness framework（準備度框架）：OpenAI用來追蹤模型能力與風險的評估框架。
• SWE-bench／GitHub issue解題能力：評測AI解決真實軟體工程issue能力的方式。
• HealthBench：OpenAI推出的醫療領域rubric式評測基準。
• PaperBench：OpenAI推出的評測AI複現學術論文能力的基準。
• GPQA：研究生等級、號稱「Google也搜不到答案」的高難度問答評測資料集。
• rubric（評分規準）：針對單一問題逐條列出的評分標準，可讓AI擔任評分者。

6. 延伸觀察

這場的衝擊力其實比炫技demo更大，因為他講的是每個做AI應用的人遲早會撞到的牆：你以為在做模型或做產品，其實一直在做的是「你要相信哪組數字」的政治決定。他那句「插旗子在哪裡，決定了大家往哪座山爬」，比任何一頁投影片上的benchmark分數都更值得記住。

AIME那個故事也把「發現bug該不該馬上講」這件事重新翻出來檢視一次——他給的答案很功利，卻也很誠實：光是舉手講問題不會有人理你，你得先把問題變成一個更大的機會，再一起端出來。這跟前面幾場講team文化、講產品開發的場次，其實是同一件事的另一面。

7. 資料來源