# 影片筆記：谷歌內部核彈級洩露！🤫 Carbon 模型橫空出世，Claude 3.5 真的要涼了？🦾


<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->
## ⚠️ 可先使用，仍有待修正項目

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

- 待修正：逐字稿全文快速校讀未完成（已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

## 一句話總結

影片深入剖析谷歌內部代號 **Carbon** 模型與微軟 **Decision** 模型的實際企業應用現狀，指出當前 AI 模型的競爭焦點已從單純的參數規模或單步生成準確率，轉向處理長流程任務的連續工作能力、錯誤糾錯機制、端到端的成本效益以及企業部署的合規與穩定性。

## 核心重點

1.  **Carbon 模型的真實定位**：
    *   目前僅處於內部測試階段，雖在 JetBrains 環境中獲得部分員工積極反饋，但尚未公開參數規模或完整測試數據。
    *   核心價值不在於單次生成的準確性，而在於處理複雜長流程編程任務的能力，以及能否讓其他工程師敢於接手其生成的代碼。
    *   代號（如 ArgonBarium、carbon）與公開產品（Argon）之間存在混淆，代號排序不代表性能自動升級。

2.  **長任務的機率風險與工程挑戰**：
    *   即使單步成功率達 95%，連續 10 個獨立步驟的總成功率僅約 60%。長任務會放大局部失誤。
    *   企業關注重點包括：連續工作能力、錯誤糾錯機制（如代理發現失敗後是否換方法或詢問）、業務規則符合度（如收件人錯誤但郵件發出）。
    *   內部工程師的經驗（知道哪些建議浪費時間）比孤立成績表更具參考價值。

3.  **RSI（遞歸自我改進）的迷思**：
    *   區分三種過程：任務內糾錯、研究輔助、自主系統升級。
    *   目前缺乏證據證明 Carbon 已實現完整的自主遞歸升級（自主提出改進、訓練、評估並確認更好）。
    *   需防止將「熟悉考試」誤認為能力增長，並需留出獨立任務觀察其他能力有無被犧牲。

4.  **微軟 Decision 模型的特點**：
    *   基於 **千問 3.59B** 進行後訓練，專注於決策與分類工作負載。
    *   強調一致性、速度與低成本，適合處理大量重複判斷（如客服分流、代理檢查）。
    *   需謹慎解釋輸出概率（90% 不等於真實性擔保），並需為陌生情況設計「拒絕判斷或交人處理」的出口。

5.  **企業部署的現實關卡**：
    *   評估標準從「感覺像頂級模型」轉向「續費意願」與「端到端流程驗證」。
    *   需考慮成本效益、延遲體驗、數據保密、合規性、遷移成本以及建立可追溯、可回滾的穩定服務體系。
    *   競爭維度轉移：模型廠商證明複雜任務能力，工具平台證明連接可靠，企業證明自動化確實節約總成本。

## 詳細大綱

### 一、 Carbon 模型內部測試與市場反響
*   **消息來源**：Business Insider 報導谷歌內部材料。
*   **測試環境**：員工在內部編程環境 **JetBrains** 中測試，部分員工給予積極評價，但也提醒需要更多測試。
*   **代號與版本**：涉及代號 **ArgonBarium**、**carbon**；公開產品為 **Argon**（分階段開放，受信任網路防禦使用者優先）。
*   **誤區澄清**：代號排序不代表性能自動升級，開發流程中常同時存在多個候選版本。
*   **競爭場景**：員工將 Carbon 表現與 **Opus5.5** 比較，體驗差異受團隊熟悉工具與任務影響，跨行業穩定領先需經公開檢驗。

### 二、 編程模型的真實挑戰：從生成到接手
*   **參數與實力**：谷歌未披露 Carbon 參數規模。「龐然大物」僅表達市場期待。核心問題是能否完成工作，以及完成後別人敢不敢接手。
*   **長流程任務**：區別於獨立小程序，運行多年的系統涉及接口約束、檢查副作用、處理錯誤日誌。風險案例：刪除看似多餘的函數（處理老客戶特殊情況），測試通過但客戶次日發現問題。
*   **內部工程師價值**：比孤立成績表更值得關注。經驗包括知道哪些建議浪費時間、哪些回答看似複雜卻無解。轉化條件為減少反覆解釋與審查後返工。

### 三、 連續工作能力與錯誤處理機制
*   **機率風險模型**：假設 10 個步驟彼此獨立，每步成功率 95%，10 步全部成功機率僅約 6 成。長任務放大局部失誤，單步表現好不等於整體可靠。
*   **成熟系統能力**：允許糾錯（工具執行失敗 -> 代理發現失敗 -> 決定換方法或停下來詢問）。需區分技術執行成功（如發出郵件）與業務結果錯誤（如收件人錯誤）。
*   **評估指標**：關注遇到失敗是否重複同一套方案、面對矛盾文件是否主動查找依據、耗時後是否為求結束而宣稱成功。這些行為比生成答案時的語氣自信更重要。

### 四、 內部測試的條件差異與產品化距離
*   **工程環境貢獻**：谷歌工程環境提供真實任務與教科書外麻煩。若 **gensky**（疑點）提供更好的代碼檢索或上下文準備，體驗包含工具貢獻。評估原則為模型與工程系統應一起評估。
*   **產品化關卡**：內部體驗好不等於正式服務好用。關卡包括可接受時間內完成、用戶增加後質量維持、舊流程不因工具升級而失效。決定因素是續費意願。
*   **Argon 公開與內部差異**：官方介紹分階段開放，截圖風險在於測試界面名稱可能僅為灰度實驗或特定入口。需確認正式文檔可用範圍及實際帳戶能否調用。

### 五、 上下文長度與 RSI（遞歸自我改進）辨析
*   **上下文長度誤判**：放入大量資料僅說明輸入容量擴大。關鍵能力在於找到關鍵證據、區分新版/舊版文件。資料越多，選擇依據能力越重要，可能增加資訊衝突。企業需求為可追溯性（查具體出處、規則更新引用、部門解釋差異）。
*   **RSI 三種過程**：
    1.  模型修改自己剛剛生成的答案（任務內糾錯，如補導入、調函數）。
    2.  研究人員讓模型參與開發（節約時間，但方向與標準由人決定）。
    3.  強說法：系統自主提出改進方案、完成訓練評估、確認新系統更好並繼續下一輪。
*   **結論**：目前缺乏完整過程證據（改什麼、資源多少、未見任務進步、退步處理），自我進化易剩標籤。需防止將熟悉考試當成能力增長，並需留出獨立任務觀察其他能力有無被犧牲。

### 六、 微軟 Decision 模型與專用判斷系統
*   **模型介紹**：定位為決策與分類工作負載，基於 **千問 3.59B** 做後訓練。特點為處理大量重複判斷，不要求所有問題交給最大模型。測試數據覆蓋 36 個基準，約 15 萬道問題，報告相對 **GPT6索爾**（疑點）有延遲優勢。
*   **應用場景**：客服系統判斷應交給哪個業務組；代理檢查根據預設標準分類檢查是否需要人工覆核。優勢為輸出格式穩定，易被程序讀取。組合策略為大模型展開思路 + 專用判斷模型集中計算。
*   **概率謹慎解釋**：90% 不等於真實性擔保。校準討論一批預測與實際結果的關係。風險為業務變化後，原來可靠的概率可能失準（如新詐騙話術）。設計要求給陌生情況留出口（拒絕判斷或交人處理）。
*   **選項設置與錯誤代價**：若只給「執行」與「不執行」，模糊情況會被硬塞。新增選項後需測試是否過度迴避。企業需按錯誤代價設計流程：普通諮詢錯分僅多等幾分鐘；支付操作誤判則後果嚴重。評估重點為看錯在哪裡，而非僅看平均準確率。
*   **成本與延遲現實**：微軟官方定價輸入價格低，輸出不另行收費。隱藏成本包括連接業務數據、維護規則、保存日誌、人工處理。延遲問題為單步快，但整條流程等待資料庫傳輸可能卡住。評估標準為端到端時間，局部性能需放入流程中評估。

### 七、 企業部署與採購的綜合考量
*   **競爭路線**：Carbon 承擔複雜生成和編程工作；Decision 使高頻選擇便宜而穩定。工作流同時需要兩類能力，保留重要審批。採購對象為一整套任務完成方案，模型間如何分工。
*   **責任追溯與日誌**：風險為分類系統分錯任務，大模型解決錯誤問題；大模型輸出不完整，後續評分建立在缺失材料上。解決方案為記錄每個階段看到什麼、做出什麼選擇。升級判斷原則為失敗在檢索就不換貴模型；規則模糊先修規則；確屬能力不足才升級模型。
*   **對照測試與選擇偏差**：偏差為員工將容易任務交給 AI，複雜任務留給自己。公平比較需考慮不同任務難度，避免未經校正的報表推動錯誤用工決定。版本管理上，模型更新後重測，關鍵分類可能變差；重要任務允許暫時保留舊版本。成本評估需覆蓋失敗任務，計算成功一次調用費用會漏掉重試；計算生成速度會漏掉人工檢查。商業決策數字為完成合格任務總花費、嚴重錯誤頻率。
*   **公開測試與產品上線**：公開測試關注任務是否覆蓋真實倉庫、條件是否一致、失敗記錄是否完整。產品上線關注普通付費用戶獲得條件、內部員工驚喜 vs. 可持續服務體驗。
*   **任務定義與需求澄清**：模糊請求如客戶說「頁面更快」可能指加載時間或操作步驟。系統能力為識別缺失條件、只問必要問題。詢問頻率上，每一步都要求人確認效率低；什么都不問易走偏。風險閾值按任務風險設置不同閾值。
*   **長任務與狀態恢復**：時間跨度上，資料明天可能被更新，用戶中途改變要求。系統要求知道哪些工作可保留、哪些已廢止；保存工作狀態同時允許目標變化。中斷恢復需處理網路斷開是否重複步驟、操作提交但確認消息未返回是否再提交。機制設計為應用記錄操作狀態阻止重複提交，模型決定下一步。結合原則為確定性程序負責確定性約束，模型處理需要理解和選擇的部分。

### 八、 數據保密、合規與遷移成本
*   **數據保密與合規**：內容含代碼倉庫商業邏輯、文檔含客戶信息。需查清數據保存方式、服務條款。模型路由經過不同供應商時，需確認資料流向。合規差異為使用效果相似，合規條件可能完全不同。
*   **遷移成本與接口設計**：問題為調好提示和評分規則後，換模型未必有效；輸出格式變化導致下游程序出錯。解決方案為保留共同任務接口，為不同模型做適配。採購策略為避免只挑自己擅長任務；按真實任務占比構建測試集；關注高難問題但代表日常成本。
*   **等待分布與業務適配**：平均耗時不錯，偶爾卡住很久會破壞工作安排。業務差異為客服和實時業務需看慢請求；研究型任務能容忍更長等待。路由系統觀察為不能為省調用費讓後面產生更多返工。價值體現為合格交付成本下降，而非僅某個組件便宜。

### 九、 個人開發者驗證與安全邊界
*   **個人驗證方法**：選已知解決方法的舊問題，隱藏答案，讓新工具獨立嘗試。比較使用時間、修改範圍、有無新增問題。目的為無法替代專業基準，但能判斷是否適合手上項目，減少僅憑宣傳切換工具的成本。
*   **網路安全與權限**：能力為發現複雜軟體問題對防禦工作有幫助。檢查使用者身份和操作權限必須被檢查。區分授權研究與未經許可操作不能因調用同一模型而混在一起。安全發布難點為讓有益能力進入正確工作流程，所有能力封成聊天窗口用戶難察差別，企業必須知道哪些是建議、哪些改變系統。審批差異為代碼審查可人工確認；生產配置修改需更嚴格審批。界面展示上，產品越接近實際執行，界面上越應清楚展示動作範圍。

### 十、 未來競爭與結論
*   **競爭維度轉移**：不再只停留在模型排行榜。模型廠商需證明複雜任務能力；工具平台需證明連接可靠；企業需證明自動化確實節約總成本。風險為任何一環跟不上，領先技術可能停在演示階段。
*   **Carbon 信號與結論**：信號為谷歌內部編程候選模型獲得積極反饋，值得追蹤但不足以寫成全面領先事實。微軟 Decision 提供另一個觀察角度，AI 產品向具體判斷任務細分，規模和專用化可能帶來價值。最終標準為企業離放心交出工作還有距離，因為交付涉及連續判斷且錯誤有真實代價。最有說服的證明為幫助用戶在可承受成本下完成合格任務，能被覆核、能被回滾、下一次還能穩定做對。

## 工具 / 模型 / 名詞整理

*   **Carbon**：谷歌內部代號模型，主要關注編程與生成能力，目前處於內部測試階段。
*   **Argon**：谷歌公開亮相的模型，採用分階段開放安排，受信任網路防禦使用者優先。
*   **ArgonBarium**：逐字稿提及的內部代號之一，與 carbon 並列。
*   **Opus5.5**：逐字稿提及，用於與 Carbon 進行編程表現比較（疑點：可能為 Claude Opus 系列與數字的混稱）。
*   **Claudeopus5.5**：逐字稿提及，用於與 Carbon 進行編程表現比較（疑點：可能為 Claude 系列與 Opus 的混稱或聽寫錯誤）。
*   **JetBrains**：員工進行內部測試的編程環境。
*   **Business Insider**：報導谷歌內部材料的媒體。
*   **gensky**：逐字稿提及，假設提供更好代碼檢索的工具或環境（疑點：名稱不常見，需查證）。
*   **RSI (Recursive Self-Improvement)**：遞歸自我改進，指系統自主提出改進方案、完成訓練評估並確認新系統更好的過程。
*   **微軟 Decision**：微軟推出的模型，關注決策與分類工作負載。
*   **千問 3.59B**：Decision 模型基於的基礎模型。
*   **GPT6索爾**：逐字稿提及，Decision 測試中比較的對標對象（疑點：可能為 GPT-4o 或特定模型名稱的聽寫錯誤）。

## 操作流程整理

1.  **評估 Carbon 模型行為**：
    *   觀察遇到失敗時是否重複同一套方案。
    *   檢查面對矛盾文件時是否主動查找依據。
    *   確認耗時後是否為求結束而宣稱成功。
    *   評估重點在於行為指標而非生成答案時的語氣自信。

2.  **部署 Decision 模型流程**：
    *   基於千問 3.59B 進行後訓練，專注決策與分類。
    *   應用於客服系統分流或代理檢查分類。
    *   設計選項時需包含「拒絕判斷或交人處理」出口，避免模糊情況被硬塞。
    *   評估重點為看錯在哪裡，而非僅看平均準確率，並需考慮錯誤代價設計流程。

3.  **企業採購與驗證步驟**：
    *   個人驗證：選已知解決方法的舊問題，隱藏答案，讓新工具獨立嘗試，比較使用時間與修改範圍。
    *   對照測試：考慮不同任務難度，避免選擇偏差，建立包含高難問題但代表日常成本的測試集。
    *   責任追溯：記錄每個階段看到什麼、做出什麼選擇，建立可追溯、可回滾的穩定服務體系。
    *   成本評估：計算成功一次調用費用時需漏掉重試，計算生成速度時需漏掉人工檢查，最終關注完成合格任務總花費與嚴重錯誤頻率。

## 值得注意的限制或風險

1.  **長任務機率風險**：即使單步成功率達 95%，連續 10 個獨立步驟的總成功率僅約 60%，長任務會放大局部失誤。
2.  **RSI 證據不足**：目前缺乏完整過程證據證明 Carbon 已實現完整的自主遞歸升級，自我進化易剩標籤。
3.  **概率誤解風險**：90% 的概率不等於真實性擔保，業務變化後原來可靠的概率可能失準。
4.  **選擇偏差**：員工可能將容易任務交給 AI，複雜任務留給自己，導致未經校正的報表推動錯誤用工決定。
5.  **安全與權限混淆**：所有能力封成聊天窗口用戶難察差別，企業必須清楚區分哪些是建議、哪些改變系統，生產配置修改需更嚴格審批。
6.  **延遲與成本隱患**：單步快，但整條流程等待資料庫傳輸可能卡住；隱藏成本包括連接業務數據、維護規則、保存日誌、人工處理。

## 逐字稿辨識疑點

1.  **Claudeopus5.5**：逐字稿原文。可能為「Claude Opus 5.5」或「Claude 3.5 Sonnet」等模型的聽寫錯誤，但無法確定具體型號，故標為疑點。
2.  **ArgonBarium**：逐字稿原文。Argon