Stanford CS329Z 導讀 Week 6：資料飛輪轉起來——HW1 繳交週

🌏 English version

Week 6 是繳交週。週一（10/26）是主題待定的客座演講，同一天 HW2 發布。週三（10/28，Data for Agentic Systems）的主讀物是 Shreya Shankar 的 Data Flywheels for LLM Applications（2024）。週五（10/30）HW1 截止。緊接著是課上期中展示（11/4）。期中報告在 11/6 到期。

資料飛輪只有一句話：上線後的每一次輸出，都是下一次變強的教材。智慧體每回答一題，就留下一條軌跡：使用者問了什麼、系統走了哪幾步、最後答對還是答錯。把軌跡收好、打上分數，挑好的放回提示當示範，修好的壞例子也放回去。轉完一圈，示範變好、分數變高，下一圈又產出更好的資料。

Shankar 把這一圈拆成三站：評估、監控、持續改進。評估決定成功長什麼樣子，監控確保指標沒有跟現實脫鉤，改進負責把學到的東西放回系統。三站吃的是同一批生產資料，只是用途不同。這篇文章沒有新模型也沒有新演算法，談的是工程紀律：怎麼把每一筆生產資料用到極致。

評估：先看真實輸出，再定指標

指標不能靠空想。作者的建議是先看一批真實輸出，再決定要驗什麼。例子很傳神：某些贅字（像是 delve、crucial）一看就是模型味，你只有看過輸出才會想到要禁它們。這一步沒有捷徑，看資料就是工作本身。

指標分成兩種做法。簡單的用程式寫死，例如數字數算簡潔度。主觀的請模型當評判（LLM-as-a-judge），在評判提示裡附上好壞範例，能顯著改善對齊。作者特別提醒：先從是非題做起。李克特量表看似精細，其實更難對齊，是非題才是人類標註與機器評判都好一致的起點。

更多評估心法，可以看 Hamel Husain 的評估指南，作者本人點名推薦。

多步管線：在圖上放探針

單次呼叫好驗，難的是呼叫組成的圖。前一步的錯會被後面放大，所以驗證要像可觀測性的探針，插在每個節點上。節點分成三種，分類來自 Han Lee：分類器（菱形，管狀態轉換）、寫手（長方形，負責生成）、編譯器（六角形，負責生程式）。作者拿客服機器人示範三種節點怎麼分工。

三種節點的驗法各不相同。分類器看準確率、精確率、召回率這類老指標。寫手最麻煩，標準因任務而異，得寫專屬的驗證器。生程式的節點最幸福： lint、測試、直接執行 SQL 看結果，軟體工程的老工具全都能用。

探針插多了，下一個問題是先修哪裡。做法是幫每個驗證器打標籤，算出每一步的準確率，錯誤在哪裡放大一目了然。作者也承認，多步管線的完整驗證仍是開放問題，這正是下週評估主題的前菜。

輸入也要驗：進去嚴格，出來寬容

業界多半只驗輸出，作者堅持輸入也要驗。擋掉不該進管線的查詢，本身就是強健性。他的座右銘借自 Brendan Dolan-Gavitt：對送進模型的輸入嚴格，對拿到的回應寬容。

做法都很具體：查詢是不是本人的資料、主題在不在支援範圍、語義相似度有沒有過門檻（例如 0.7）。語言支不支援、有沒有夾帶敏感個資或惡意注入，也都要檢查。每一條都小，少了任何一條，上線後都會變成事故回顧裡的一節。

監控：指標集不是死的

指標定好不會一勞永逸。模型供應商會改版，使用者口味會漂移，上線後一定冒出當初沒想到的失敗。這時可以派一個模型代理人，定期讀取已標註的生產資料，提議新增、修改或刪除指標。與作者合作的新創 Alta 正在這麼做：替每位使用者養一套專屬指標。

指標實作也要跟著長大。定期抽樣、人工標註、連時間戳一起入庫，這是整套飛輪最花人力的一步。標註庫養起來後，驗證提示不再寫死：每次按語義相似度撈相關範例，優先撈人和模型曾經意見不一致的，再按新舊加權。新資料權重高是作者的直覺，他也坦承還沒看到有人這樣做。

標註人力省不得，但可以變聰明。LangChain 的做法是模型先標、人工只改：預設每筆資料都有標籤，人想改再改。缺點作者也很誠實：人一偷懶不檢查，對齊度會默默漂掉。這正是下週讀物 Who Validates the Validators（UIST 2024）要處理的問題。

持續改進：把修好的放回去

前面兩站都是為了這一站：讓系統越跑越強。前提是日誌要全：輸出是什麼、各項分數是多少，全部留下來，LangSmith 這類工具負責的就是這件事。接著分人力與自動兩條腿走路。

人力這條腿是基本功：定期看分數分佈，找低分群，做輸入分佈分析，不同提示拿去做 A/B 測試。自動那條腿是飛輪的精髓：每天或每週修一批低分輸出，修好的連同分數一起入庫。線上推理時，撈出最像的修好案例塞進提示當示範。據作者所知，至少有 5 位實務者已經這樣做，Dosu 的機器人就是這個架構。

這個架構有個漂亮的副作用：提示工程變成了檢索問題。關鍵從提示怎麼寫，轉成怎麼撈到對的範例：對模型最有用，也最合使用者口味。作者還提醒，把好壞拆成多個維度分別打分更值得：標註更一致，驗證器更好對齊，哪裡爛一目了然。

同一批資料，兩種用途

課題名稱就點出三種資料：軌跡、示範與回饋。飛輪文章幫它們分了工：修好的軌跡是示範，拿去優化；打過分的軌跡是考題，拿來評估。兩邊吃同一座標註庫，問的是不同問題。

這也解釋了 HW2 為何緊接著 HW1。HW2（10/26 發布）要你為現成智慧體打造整套評估：程式寫死的評分器、至少一個模型評判，外加錯誤分析。考題用四元組（請求、環境、停止條件、評分器）打造。Week 5 學優化，本週學生產資料，下一步就是評，這是課程的刻意安排。

合成資料：沒有對齊的驗證器，合成只是複印幻覺

主文幾乎不談純合成資料，這句話本身就是答案。飛輪的燃料是被修好的真實輸出，不是模型憑空生的。模型自己改寫、自己標註能不能用，取決於驗證器跟人有多對齊。而這正是作者點名的開放問題：指令調校模型的 token 機率校準很差，直接問模型要信心分數，效果也不好。

想補這塊拼圖，可以讀本週延伸讀物 Tan 等人的綜述（EMNLP 2024）：模型如何當標註員，合成的標註怎麼驗收，用合成資料訓練要注意什麼。三塊內容正好是飛輪缺的那幾頁。

從人機互動收資料：標註是跟人要的

飛輪轉不轉，最終看人願不願意標。作者的觀察第一條就是：人必須定期留在迴圈裡，因為人對輸出的偏好會變。模型先標、人只改的流程省力，但法務想先審提示、惡意查詢可能污染示範庫，這些都是真實世界的摩擦。部落格註腳裡，Han 就點了這兩個風險。

對修課的你來說，這句話有切身意義：你自己就是最便宜的標註員。你用 HW1 智慧體查的每一題、修的每一個答案，都是飛輪的第一批燃料。

怎麼做：繳交週先讓軌跡留下來

怎麼做：給你的 HW1 智慧體加上最小軌跡紀錄：每題存下查詢、檢索到的論文、最終答案，再加你親手打的一個好壞標記。每週留半小時回顧：修好壞例子收進示範庫，常錯的類型寫成下一版指標。HW1 截止前跑完一輪，期中報告規定的失敗案例附錄就有現成素材。

它在課程裡的位置

本週是分水嶺。HW1（10/30 截止）收尾手刻與框架的對照，HW2（10/26 發布）把戰場換到評估。下週（Week 7）繼續加碼。週一讀 SWE-smith（NeurIPS 2025）談如何為軟體工程智慧體量產任務資料，外加 Who Validates the Validators 談驗證器對齊。週三整堂談評估設計。11/4 是課上期中展示。11/6 期中報告到期，原型得先跑起來。

本週 Course Material 對照

• 週一 10/26 Guest Lecture：客座場，無指定讀物。
• 週三 10/28 What Data Do Agents Need?：主讀物 Shankar 資料飛輪（本文已導讀）；延伸閱讀 Tan 等人資料標註與合成綜述（EMNLP 2024）。該綜述把模型當標註員的工作分成三塊：標註怎麼生成、合成標註怎麼驗收、拿合成標註訓練要注意什麼。另附資料型別的分類與既有學習策略的回顧。本文合成資料一節對應的正是這三分法。
• 課表原文：CS329Z 官網 Week 6

參考資料

• 站內：Week 5：多智慧體與優化、CS329Z 總導讀
• 課程：CS329Z 官網課表
• 原文：Shankar, Data Flywheels for LLM Applications (2024)、Tan et al., Large Language Models for Data Annotation and Synthesis, EMNLP 2024、Shankar et al., Who Validates the Validators, UIST 2024
• 延伸：Hamel 的評估指南、LangChain：對齊模型評判與人類偏好、Dosu：把提示工程變成檢索問題、SWE-smith：為軟體工程 agent 量產資料