第 15 集：深入了解 Model Spec（第 1/3 段）

🧑‍🏫 這段影片由 OpenAI 研究員 Jason Wolfe 介紹 Model Spec，這是一份公開的文件，寫明 ChatGPT 這類模型「應該怎麼表現」。看完你會知道模型為什麼有時會拒絕、有時很好說話，也會知道當你、開發者和 OpenAI 的要求互相衝突時，模型會先聽誰的。

• 00:01 本集來賓 Jason Wolfe 是 alignment 團隊研究員，談 model spec 如何形塑模型行為，以及為何開發者與使用者都該了解它
  ↳ 來賓 Jason Wolfe 在 OpenAI 的 alignment 團隊工作。alignment（對齊）是讓模型行為符合預期的研究。他要談 model spec 這份規範怎麼影響模型的表現，以及為什麼用 AI 的人也該懂。
• 00:01 開場片段提到：spec 常常走在模型現況的前面；模型遇到難題應先想清楚，不要一開始就給答案
  ↳ spec 寫的常是「希望模型做到的樣子」，模型不一定已經做到。碰到難題時，spec 希望模型先想清楚，不要急著給答案。
• 00:34 例子：小孩透過 voice mode 問「聖誕老人是真的嗎？」，模型的回答符合 spec：意識到提問者可能是小孩，回答時稍微模糊一點
  ↳ voice mode 是 ChatGPT 的語音對話功能。有小孩用它問聖誕老人是不是真的，模型察覺可能是小孩，就沒有直接戳破，回答得含糊一點。這就叫 spec compliant，意思是符合 spec 的要求。
• 01:06 Model spec 是 OpenAI 用來說明「模型應該如何表現」的高層決策的文件，涵蓋模型行為的許多面向
  ↳ model spec 是 OpenAI 寫的「模型該怎麼表現」說明書，記錄的是高層做過的決定，涵蓋模型行為的很多面向。
• 01:38 Spec 不代表模型現在已經完全遵守。讓模型對齊 spec 是持續的過程，要部署、衡量對齊程度，並了解使用者喜不喜歡
  ↳ 寫進 spec 不代表模型已經照做。對齊是持續在做的事：先上線，再衡量模型做到幾成，也看使用者喜不喜歡。
• 01:38 根據部署後學到的東西，會回頭同時修改 spec 本身和模型
  ↳ 上線後發現問題，可能是規則本身訂得不好，也可能是模型沒學好，所以 spec 和模型兩邊都會回頭調整。
• 02:08 Spec 不是 implementation artifact。它的主要目的是向人說明模型該怎麼表現，對象包括 OpenAI 員工、使用者、開發者、政策制定者和一般大眾
  ↳ implementation artifact 指為了讓系統運作而產生的技術檔案。spec 不屬於這種，它是寫給人看的，讀者包括員工、使用者、開發者、政策制定者和一般大眾。
• 02:39 讓模型能理解並運用 spec 只是次要目標。OpenAI 不會單純為了讓模型學得更好而修改 spec 的內容或措辭，首要目標永遠是讓人看得懂
  ↳ 模型讀不讀得懂 spec 是其次。OpenAI 不會為了讓模型學得更好就去改 spec 的內容或用字，優先考量永遠是人看得懂。
• 03:09 Spec 不是 ChatGPT 整個系統的完整描述。例如 memory 等產品功能，以及屬於整體安全策略重要一環的 usage policy enforcement，都沒有直接寫在 spec 裡
  ↳ spec 只講模型本身該怎麼表現，不是整個 ChatGPT 的說明書。memory（記住你之前資訊的功能）和 usage policy enforcement（執行使用規範、處理違規）都不寫在裡面。
• 03:09 Spec 也不會詳列每條政策的所有細節。目標是涵蓋最重要的決策，並準確描述 OpenAI 的意圖
  ↳ spec 不會把每條政策的細節都寫出來，只挑最重要的決定寫，重點是準確表達 OpenAI 的意圖。
• 03:40 Spec 是很長的文件，大約 100 頁。開頭先說明高層目標：OpenAI 的使命是造福人類，這也是部署模型的原因
  ↳ spec 全文大約 100 頁。開頭先說明為什麼要做這件事：OpenAI 的使命是造福人類，部署模型也是為了這個目標。
• 04:11 部署模型的目標是賦能使用者（empower users），並保護社會免於嚴重傷害；文件也說明如何權衡兩者，接著是大量細部政策
  ↳ 部署模型有兩個目標：empower users（讓使用者能做到更多事），以及防止對社會造成嚴重傷害。兩者衝突時怎麼取捨，文件裡也有說明，後面才接著大量細則。
• 04:41 使用者可以問模型任何問題，所以需要涵蓋的政策範圍非常大，spec 盡量把這個範圍整理得清楚有條理
  ↳ 使用者什麼都可能問，要管的範圍非常大。spec 的工作之一，就是把這麼多情況分門別類、整理清楚。
• 04:41 Spec 內容分兩類：一是不能被覆寫的 hard rules；二是大量 defaults（例如語氣、風格、個性），讓使用者一開始就有好體驗
  ↳ spec 的內容分兩種。hard rules 是誰都不能改的硬規則。defaults 是預設做法，例如語氣、風格、個性，目的是讓人一開始用就覺得順手。
• 05:12 Defaults 保留 steerability：如果使用者想要不同的做法，可以覆寫這些預設
  ↳ steerability 指使用者可以調整模型的做法。如果你不喜歡預設的樣子，例如想要更簡短的回答，可以要求模型改，它應該照做。
• 05:12 Spec 附有大量範例，用來界定決策邊界。例如在模糊案例中，誠實和禮貌該以哪個為優先，並說明最後的決定
  ↳ 文字規則常有灰色地帶，所以 spec 附了很多範例，用來劃出 decision boundaries（判斷界線）。例如誠實和禮貌衝突時該以哪個為先，範例會寫出最後的決定。
• 05:42 範例的作用：一是展示原則實際怎麼運用，確保被正確解讀；二是傳達難以用文字說明的風格、個性、語氣細節
  ↳ 範例有兩個用處。一是示範原則實際怎麼套用，避免被誤解。二是語氣、個性這類很難用文字講清楚的東西，看範例比較容易懂。
• 05:42 範例會提供理想回答，或是只保留最關鍵部分的精簡版理想回答，示範模型實際上應該怎麼說話
  ↳ 範例會寫出理想的回答，有時是完整版，有時只留最關鍵的幾句，讓人直接看到模型「應該怎麼講話」。
• 06:13 到 model-spec.openai.com 可以看最新版 spec；在 GitHub 搜尋 model spec 可以看原始碼
  ↳ 想看最新版 spec，可以到 model-spec.openai.com。想看原始檔，可以到 GitHub（公開存放程式碼和文件的平台）搜尋 model spec。
• 06:13 Spec 是開源的，任何人都可以 fork，做出自己的版本
  ↳ spec 是開源的，任何人都能 fork，也就是複製一份到自己名下再修改，做出自己版本的規範。
• 06:44 目前最好的回饋管道：在產品中對不滿意的輸出直接回饋，或在推特上 tag Jason Wolfe，他會閱讀
  ↳ 覺得模型回答不好，最有用的做法是在產品裡直接按回饋，或是在推特上 tag Jason Wolfe，他說他會看。
• 07:15 Spec 有很多修改都來自大眾寄來的意見和想法
  ↳ spec 不是關起門寫出來的，很多修改來自一般大眾寄來的意見和想法。
• 07:46 起源：Jason 當時在另一家公司做 conversational AI，準備 OpenAI 的 job talk 時，思考未來模型對齊會是什麼樣子
  ↳ 這個構想的起點：Jason 還在別家公司做 conversational AI（對話式 AI）時，要準備 OpenAI 的 job talk（應徵時做的研究簡報），於是開始思考未來的模型對齊會是什麼樣子。
• 07:46 當時公開的做法是 RLHF：向人類蒐集資料，用資料以某種方式呈現想要的政策。這種做法相當有效
  ↳ 當時公開的主流做法是 RLHF（從人類回饋中學習），做法是請人評分或示範回答，再用這些資料教模型表現出想要的行為。這個方法效果不錯。
• 08:16 RLHF 的問題：光看資料很難判斷它實際在教什麼；如果想法改變，幾乎要重新蒐集資料才能修改
  ↳ RLHF 的麻煩有兩個。一是資料量很大，很難看出模型到底學到什麼規則。二是想法一改，幾乎要重新蒐集一批資料，修改很費工。
• 08:47 當時的做法是「遷就模型現有的程度」；但模型越來越聰明後，會變成「模型來配合我們」
  ↳ 以前模型不夠聰明，人得配合模型的程度來設計教法。模型變聰明以後，情況反過來，換成模型來理解、配合人的想法。
• 08:47 到那時，教模型的方式會像教人一樣，例如寫一本員工手冊（employee handbook）
  ↳ 到那個階段，教模型可以像教新員工一樣，寫一本 employee handbook（員工手冊），把規矩寫清楚讓它讀。
• 09:17 Jason 在 job talk 中提出：模型在某個時間點應該要從像 spec 這樣的東西學習
  ↳ 所以 Jason 在 job talk 裡主張：模型總有一天應該直接從 spec 這類書面文件學習。
• 09:17 2024 年，當時的 model behavior 負責人 Joanne Jang 與共同創辦人 John Schulman 發起 model spec 專案，並基於透明度考量決定公開
  ↳ 2024 年，當時負責模型行為的 Joanne Jang 和共同創辦人 John Schulman 發起 model spec 專案，並基於透明度考量決定公開。
• 09:47 Jason 很快加入他們，協助撰寫最初版本的 spec，之後也持續參與 spec 的工作
  ↳ Jason 不久後加入，參與撰寫第一版 spec，之後也持續參與 spec 的工作。
• 09:47 Spec 怎麼變成模型的行為？答案相當複雜
  ↳ spec 怎麼變成模型實際的行為？Jason 的回答是：相當複雜，不是單一步驟就能做到。
• 10:17 有些部分在訓練中較直接使用 spec，例如 deliberative alignment：教模型（特別是 reasoning models）遵守特定政策
  ↳ 有些部分在訓練時會比較直接地用到 spec，例如 deliberative alignment，這是教模型遵守特定政策的訓練方法，特別用在 reasoning models（會先推理再回答的模型）。
• 10:17 Deliberative alignment 用到的部分政策直接取自 spec 的文字，或反過來由政策寫進 spec
  ↳ 這套訓練用到的部分政策，是直接取自 spec 的文字。也有反過來的情況：先有訓練用的政策，之後再寫進 spec。
• 10:48 模型行為與安全訓練是非常複雜的流程，有數百位研究員參與，所以 spec 和訓練的關聯通常沒那麼直接
  ↳ 不過整體的模型行為和安全訓練非常複雜，有數百位研究員參與，所以 spec 和訓練之間通常不是直接對應的關係。
• 10:48 通常不是改了 spec 才帶動行為改變，而是先改訓練方式，再確保 spec 準確反映意圖；實際訓練遠比 spec 能寫進去的更複雜
  ↳ 比較常見的順序是先改訓練方式，再回頭確認 spec 準確反映了意圖。實際訓練的內容遠比 spec 寫得下的更複雜。
• 11:19 Spec 的核心是 chain of command。訂目標相對簡單（幫助人、不做不安全的事），難的是目標之間起衝突時怎麼辦
  ↳ chain of command（指揮鏈）是 spec 的核心。訂目標不難，例如幫助人、不做危險的事，難的是這些目標互相衝突時該怎麼辦。
• 11:50 Chain of command 處理指令之間的衝突，來源包括：使用者的話、developer 指令（在 API 情境中）、來自 OpenAI 的指令或政策（通常寫在 spec 裡）
  ↳ 模型收到的指令有三個來源：使用者打的字、developer（開發者）透過 API（讓程式串接模型的介面）下的指令，以及 OpenAI 的指令或政策，後者通常寫在 spec 裡。
• 11:50 大原則：指令衝突時，模型應優先採用 OpenAI 指令，其次是 developer 指令，最後才是使用者指令
  ↳ 指令衝突時的順序是：OpenAI 最優先，開發者其次，使用者最後。例如某個 App 的開發者設定只談自家產品，你要它做別的事，它就可能不照辦。

根據 chain of command，當指令互相衝突時，模型應依照什麼優先順序？