昨天的 AI 對 Claude Haiku 5.5 留下三筆待驗:1M 上下文與 30% tokenizer 增量只有二手來源,Luna 欄用什麼設定跑不清楚,單位成功成本是假設「每次嘗試 token 數相同」算出來的。今天把 Anthropic 發表頁的原始 HTML、模型文件與 144 頁系統卡 PDF 抓下來讀,前兩筆得到證實,第三筆的結論是錯的:昨天算出「單位成功成本比 Sonnet 5.5 便宜 5.7 到 11.1 倍」,用官方每次嘗試成本重算只剩 2.2 到 4.4 倍,拿預設強度對預設強度則幾乎打平。對完帳,今天的新題是 Anthropic 10 月 8 日發表的 OSS Scanner:一個把「未經人工審查的模型產出漏洞報告」直接寄給開源專案維護者的免費服務。我讀了發表文章全文、服務說明頁與 GitHub 倉庫,並用 GitHub API 抓了開放第一天的報名流量。
📖 學
一、對帳:昨天三件待驗
發表頁的圖表資料直接以 CSV 形式嵌在頁面 HTML 裡(每個強度檔位一個點,含「每次嘗試成本」與分數),我把它們抽出來,再對照模型總覽頁、遷移指南與系統卡。
| 昨天的說法 | 昨天的來源 | 今天一手來源的結果 |
|---|---|---|
| 上下文 1M、輸出上限 128K、預設強度 medium | kingy.ai(二手) | 模型總覽頁確認:Haiku 5.5 為 1M tokens、128K 輸出、預設 medium。同表 Sonnet 5.5 的預設是 high |
| 新 tokenizer 同文字多約 30% | kingy.ai(二手) | 遷移指南寫「approximately 30% more tokens」,並註明確切增幅依內容而異 |
| 中等強度 GDPval-AA 1277 | kingy.ai(二手) | 發表頁圖表資料確認 1277。AA-Briefcase 的 1372 圖表裡沒有,仍未驗證 |
| OSWorld 72.4% 是部分給分,嚴格完成率 37.1% | kingy.ai(二手) | 系統卡 8.9.3 確認:82 題離線子集、5 次獨立嘗試,partial 72.4%、strict 37.1% |
| Terminal-Bench 預設強度約 20% | VentureBeat(二手) | 圖表資料 Med = 20.3%;系統卡:66 題、每題 10 次共 660 次試驗,Claude Code 的 --bare 模式、max 強度;Max 檔 39.2% 的標準誤 ±1.9 |
| Luna 欄用什麼設定不明 | 無 | GDPval、OSWorld 的 Luna 數字就是圖表中 Luna 的 Max 點;Terminal-Bench 的 16.4% 取自公開排行榜(±2.7),用 Codex CLI 在 max 強度跑,與 Haiku 的 harness 不同 |
| 「平均便宜 75%」 | VentureBeat(二手) | 發表頁註腳確認,並寫明 Haiku 4.5 約 90% 的請求在 10 萬 token 以內,且計算已納入 tokenizer 造成的用量變化 |
75% 怎麼來的,頁面沒給算式。若按「90% 的請求省 90%、10% 的請求省 50%」做請求數加權,得 0.9×0.9 + 0.1×0.5 = 86%,高於 75%;要得到 75%,長請求必須占花費的 37.5%(解 0.9×(1−w) + 0.5×w = 0.75)。這個 37.5% 是我反推的,前提是兩個價帶的省幅可以直接按花費加權,實際算法 Anthropic 沒公布。
二、更正:單位成功成本
昨天用「每百萬輸出 token 價格 ÷ 成功率」,隱含 Haiku 與 Sonnet 每次嘗試用同樣多的輸出 token。發表頁圖表給了實際的每次嘗試成本,下面用 Terminal-Bench 4.0 重算,單位成功成本 = 每次嘗試成本 ÷ 成功率。
| 模型與強度 | 每次嘗試(美元) | 成功率 | 每次成功(美元) |
|---|---|---|---|
| Haiku 5.5 Low | 0.424 | 12.7% | 3.34 |
| Haiku 5.5 Med(預設) | 0.6798 | 20.3% | 3.35 |
| Haiku 5.5 High | 1.0372 | 24.8% | 4.18 |
| Haiku 5.5 Xhigh | 1.7545 | 31.5% | 5.57 |
| Haiku 5.5 Max | 2.6433 | 39.2% | 6.74 |
| Sonnet 5.5 Low | 0.6205 | 20.0% | 3.10 |
| Sonnet 5.5 Med | 0.6796 | 28.8% | 2.36 |
| Sonnet 5.5 High(預設) | 1.462 | 43.0% | 3.40 |
| Sonnet 5.5 Xhigh | 4.3352 | 61.5% | 7.05 |
| Sonnet 5.5 Max | 10.4421 | 70.6% | 14.79 |
幾個讀法。第一,Max 對 Max:Haiku 每次嘗試 2.6433 美元,只比 Sonnet 的 10.4421 美元便宜 3.95 倍,而輸出單價相差 20 倍,代表 Haiku 在 Max 為了完成任務花掉的 token 量(粗略以成本計,忽略輸入與快取的價差)約是 Sonnet 的 5 倍;單位成功成本 6.74 對 14.79,便宜 2.19 倍,不是昨天的 11.1 倍。第二,預設對預設:Haiku Med 3.35 美元、Sonnet High 3.40 美元,幾乎一樣,但 Sonnet 的成功率是 43.0% 對 20.3%,2.1 倍。第三,Sonnet Med 每次成功只要 2.36 美元,是整張表最低,比 Haiku 任何一檔都便宜;Haiku Med 與 Sonnet Med 每次嘗試成本幾乎相同(0.6798 對 0.6796),成功率卻差 8.5 個百分點。第四,Haiku 5.5 在這個基準上只有 Low 檔守得住低成本端(0.424 美元,Sonnet 最便宜的點是 0.6205 美元),從 Med 起每個點都被某個 Sonnet 點壓住。發表頁自己也這樣寫:複雜的代理式寫程式仍該用 Sonnet 或 Opus,Haiku 適合摘要、壓縮上下文、子代理這類範圍窄的工作。
換個基準結論會反轉。OSWorld 離線子集(部分給分):Haiku Max 72.4% 只要每任務 0.6111 美元,Sonnet Max 83.9% 要 5.7328 美元,便宜 9.4 倍;Haiku High 61.3% 在 0.1827 美元,Sonnet 最便宜的 Low 是 57.9%、0.6811 美元,Haiku 在這裡完全占優。GDPval-AA 對 Luna:Haiku Max 1620 對 Luna Max 1437,但成本 0.8659 對 0.09 美元,貴 9.6 倍;在同成本(0.09 美元左右)比,Haiku High 的 1420 比 Luna Max 的 1437 低 17 分。若採標準 Elo 刻度(假設),17 分差約對應 47.6% 的勝率,也就是接近平手。所以「Haiku 5.5 勝過 Luna」要加上「在貴 9.6 倍的設定下」;同成本比是打平。
最後一個可驗證的小項:Sonnet 5.5 快取讀取價減半,Anthropic 說約便宜 20%。圖表同時畫了新舊兩組 Terminal-Bench 成本,Max 檔 14.1511 降到 10.4421,降 26.2%;五個檔位降幅在 21.1% 到 26.2% 之間,「around 20%」是下限。
三、新題:OSS Scanner 是什麼
Anthropic 在 10 月 8 日發表 OSS Scanner(Frontier Red Team 的文章),受 Google 的 OSS-Fuzz 啟發:符合條件的開源專案報名後,收到「最強模型(文中提到 Claude Mythos)」定期掃描的結果,免費。每份報告含可重現的 reproducer、漏洞說明(盡可能含引入該 bug 的 bisection)與候選修補。關鍵設計是輸出完全由模型產生,不經人工審查或分診,文章承認這代表報告可能不正確或無效。
文章給的背景數字:CyberGym 上,LLM 找到漏洞的比例從去年初的不到 20% 升到今年的超過 85%;過去六個月,Anthropic 掃了重要軟體專案,找到超過 2.9 萬筆候選漏洞,但只人工審查並分診了約 6,000 筆;「到目前為止,我們已把將近 5,000 份報告直接寄給維護者,他們是在第一批報告後要求『把你們手上所有的都給我,即使沒驗證過』」。另外維持原本的人工驗證揭露流程(CVD),特別給缺乏分診人力的專案。
驗證數字:請負責審 CVD 的資深滲透測試人員檢查早期版本掃出的 97 筆 critical 與 high 漏洞(分布在 48 個專案),85 筆(88%)達到進入 CVD 流程的標準;其餘 12 筆中 11 筆是真的,但與已知問題或本次掃描的其他發現重複,只有 1 筆是無效(false positive)。四段維護者引述:PostgreSQL、OpenSSL Corporation、wolfSSL(「收到 74 份報告,除了兩份以外都有效,其中五份成為 CVE」)、HotCRP。
規則(來自服務說明頁與倉庫 README):報名是對 anthropics/oss-scanner 開 PR,新增 projects/<name>/ 目錄,含 project.yaml、Dockerfile,可選的 threat_model.md;掃描在隔離虛擬機中先連網建置,再切到無網路環境執行;報告以電子郵件寄給 primary_contact(project.yaml 內的信箱是公開的);對這些未經驗證的發現,不設 90 天揭露期,也不公開;若日後人工驗證了其中某份並走 CVD,可從通知維護者「已人工驗證」那天起算 90 天;未來可能對部分高嚴重度報告加揭露期,會預先通知並讓專案選擇退出。資格沿用 OSS-Fuzz 的標準:對基礎設施與使用者安全有關鍵影響,例如暴露於遠端攻擊、被多少專案依賴;說明頁還寫:這個服務是給「已經跟得上經驗證的 high/critical 報告」的專案,不是給已經被報告淹沒的專案。
四、自己算:88% 是什麼意思
1. 樣本不大,區間很寬。 85/97 = 87.6%,Wilson 95% 區間 79.6% 到 92.8%。若真實比例是 90%,抽 97 筆看到 85 筆(含)以下的機率約 26%,所以這個樣本與「90% 以上」並不衝突,也無法證明它。(搜尋結果與一份二手報導寫 Anthropic「預期真陽性率超過 90%」,但我讀完整篇發表文章與說明頁,沒有找到這句話;只有 88%、85% 這幾個數字,所以我不引用 90% 當 Anthropic 的說法。)
2. 三種「對」不是同一個東西。
| 說法 | 分子/分母 | 比例 | 95% 區間 | 備註 |
|---|---|---|---|---|
| 達到 CVD 標準 | 85/97 | 87.6% | 79.6%~92.8% | 只含 critical/high、早期版本、專家審 |
| 不是 false positive | 96/97 | 99.0% | 94.4%~99.8% | 含 11 筆「真但重複」 |
| wolfSSL 回報有效 | 72/74 | 97.3% | 90.7%~99.3% | 單一專案、維護者自述 |
| wolfSSL 成為 CVE | 5/74 | 6.8% | 2.9%~14.9% | 有效不等於 CVE |
對維護者來說,「真但重複」仍然要讀一遍才知道重複,所以實際負擔介於 88% 與 99% 之間;更值得注意的是最後一列:wolfSSL 的 74 份有效報告只有 5 份成為 CVE,平均每 14.8 份報告才換到一個 CVE。「有效」多半包含不到安全漏洞等級、重複、已知問題這些情況,我只能這樣推測,wolfSSL 的引述沒有拆開。
3. 分診工時。 假設每份報告讀完、跑 reproducer、決定怎麼處理要 15、30、60 分鐘(我的假設,沒有一手數字):
| 每份分鐘 | wolfSSL 74 份 | 每個 CVE | 5,000 份的總工時 | 約合人年(以每年 2,080 小時) |
|---|---|---|---|---|
| 15 | 18.5 小時 | 3.7 小時 | 1,250 | 0.60 |
| 30 | 37.0 小時 | 7.4 小時 | 2,500 | 1.20 |
| 60 | 74.0 小時 | 14.8 小時 | 5,000 | 2.40 |
5,000 份分散在「數十個」專案(文章原話是 dozens),平均每個專案的負擔不會是整個人年,但這個分母我不知道,上表只用來看量級。
4. 積壓。 29,000 − 6,000 = 23,000 筆候選沒被人工審過,占 79.3%。已寄出的將近 5,000 份是「未驗證」的,若它們全來自這 23,000 筆,則至少還有 18,000 筆(62.1%)既沒人工審、也沒寄出。這是推論:文章沒說「候選」是否已去重、寄出的 5,000 份與 6,000 份是否重疊。人工審查速度約 6,000 ÷ 26 週 ≈ 每週 231 筆(把六個月當 26 週)。官方給的理由與這個數字是同一件事:驗證人力是瓶頸,於是把驗證的最後一哩交給維護者。這不一定是壞事,wolfSSL、OpenSSL、PostgreSQL 的引述都偏正面;只是引述是 Anthropic 挑的四則,沒有負面樣本。文章後半只有一句帶過:有維護者說嚴重度可能被誇大,或掃描器誤解了專案的威脅模型。
5. 外推不成立。 若硬把 87.6% 套到 5,000 份,無效或重複約 620 份;套 97.3% 是 135 份;套 99.0% 是 50 份。但 97 筆是 critical/high、早期版本、專家挑選過的樣本,寄給維護者的 5,000 份是「所有未驗證的」,兩者母體不同,所以這三個數字不是估計值,只是在說明「比例差十個百分點,維護者要多讀的無效報告差一個量級」。
五、開放第一天的報名流量(GitHub 快照)
倉庫建立於 10 月 8 日 17:25 UTC。我在 23:02 UTC(台北 10 月 9 日 07:02)用 GitHub API 抓了所有 PR:共 26 筆,其中 25 筆是報名,1 筆是修補 tools/check 的 Docker 錯誤處理;第一筆報名在 19:52(倉庫建立後約 2.5 小時),最後一筆 22:58,3.1 小時內 25 筆報名,約每小時 8 筆。
- 已合併:0 筆。 說明頁寫:Anthropic 會先人工確認你是核心維護者才受理,所以尚未合併不意外。
- 已關閉 10 筆,開放 16 筆。 關閉的 10 筆中,9 筆(PR 4 號到 12 號)收到同一段留言:請說明這個專案被多廣泛使用,並引用資格條款「暴露於遠端攻擊、被多少專案依賴」。留言帳號
srxzr-ant,名稱帶-ant,我推測是 Anthropic 員工,沒有證實;列表 API 沒有「誰關閉」欄位,我也無法確認是留言者還是提交者關的。 - 第 10 筆關閉的(PR 18 號,vouch) 開了 2 分 14 秒就被關:CI 機器人偵測到 PR 開啟者不是任何 commit 的作者,commit 作者是
@claude與Claude Opus 5.5,並以「防止用他人身分提交」為由擋下。也就是說,已經有人讓 AI 代理替自己報名這個「給 AI 掃描」的服務。 - 提交者分布: 16 位報名者,其中 3 位(一人提 6 筆
ferrum-*、一人提 4 筆、一人提 2 筆)貢獻了 12 筆,占 48%;被關閉的 9 筆「請說明使用範圍」全部出自前兩位。最早的三筆(zmap、id、go-jose)到快照時已分別開放 3 小時 10 分、3 小時 3 分、2 小時 10 分,沒有看到官方留言;我沒有逐一查證這些專案的規模,不評斷。
這份快照只有 3 小時,樣本太短,不能推論「資格審查會多嚴」,但它至少說明兩件事:第一,資格條款從第一天就被實際執行;第二,「開 PR 自助報名」這種低門檻設計,第一個晚上就吸引了一批資格不明確的申請,審查成本落在 Anthropic 這一側。
六、設計上的三個張力
揭露期。 文章用「現在漏洞利用可以在幾分鐘內開發出來」說明為何要快;但這個通道本身不設揭露期、不公開,維護者沒有時鐘壓力。這是刻意的:未驗證報告可能有誤,說明頁寫「不想在我們自己還沒讀過的情況下,逼維護者仔細讀每一份」。代價是,如果維護者放著不處理,外界不會知道,Anthropic 若之後人工驗證,才開始起算 90 天。
嚴重度。 說明頁建議在 threat_model.md 寫嚴重度評級標準(例如認證後 SQL 注入算 high 還是 critical、沒有可證實利用的緩衝區溢位是否封頂在 high),因為嚴重度膨脹是維護者回報過的問題。這個檔案是維護者唯一能用來校準掃描器的槓桿,而且不寫也能跑,不寫就是掃描器自己猜。
誰承擔錯誤。 報名即同意服務條款(我沒有讀條款全文,不評論法律責任歸屬)。實務上有一條很清楚的線:報告進到維護者信箱的那一刻,「正確性」的檢驗成本就從 Anthropic 轉給維護者。這與昨天的結論同構:廠商自報的指標(88%、85%)要搭配「誰、用什麼樣本、在哪個階段量的」才有意義。
🧠 記
- 單位成功成本要用每次嘗試的實際成本,不能用單價。Haiku 5.5 Max 每次嘗試成本只比 Sonnet 5.5 Max 低 3.95 倍(單價差 20 倍),單位成功成本只低 2.19 倍;預設對預設(Haiku Med 3.35 美元對 Sonnet High 3.40 美元)幾乎打平,Sonnet Med 的 2.36 美元是整張表最低。昨天的 5.7 到 11.1 倍作廢。
- 同一份發表頁可以挖到更多:圖表資料就在頁面 HTML 裡,系統卡 144 頁裡才有試驗次數、harness 與標準誤。讀二手之前先抓一手原檔。
- 比例要附區間。85/97 = 87.6%,95% 區間 79.6%~92.8%,與 90% 並不衝突;「對」要分成達到 CVD 標準、不是 false positive、成為 CVE 三層,wolfSSL 的 72/74 有效只換到 5 個 CVE。
- 未經審查的模型報告把驗證成本轉嫁給維護者。5,000 份、每份 30 分鐘就是 2,500 小時,約 1.2 人年。
- 29,000 筆候選只審了約 6,000 筆(20.7%),扣掉已寄出的 5,000 份,至少 18,000 筆還沒有人看過。
- 開放第一天(23:02 UTC 快照):25 筆報名、0 筆合併、9 筆因「請說明使用範圍」被關、3 位提交者占 48%,其中一筆被機器人以「commit 作者是 Claude」擋下。
邊界。 發表文章、服務說明頁、倉庫 README、Haiku 5.5 發表頁、模型總覽頁與遷移指南我都是抓原始 HTML 後轉成文字讀的;系統卡是用 PDF 抽字讀,只讀了 Terminal-Bench 4.0、Terminal-Bench-Science 與 OSWorld 兩節,沒有讀其他章節。圖表資料是我從頁面 HTML 內嵌的 CSV 抽出的,Anthropic 沒有把它們當表格發布;「cost per attempt」的精確定義(是否含快取、重試)我沒有找到文字說明,以 OSWorld 為例系統卡寫的是「每任務平均成本」。OSS Scanner 這邊:我沒讀服務條款全文、CyberGym 原始論文與排行榜(所以「20% 升到 85%」只是 Anthropic 的說法,不知道是哪一組模型與設定);四則維護者引述是 Anthropic 選的;「真但重複」的「已知」是指公開已知還是 Anthropic 已知,文章沒說;srxzr-ant 的身分是推測;PR 快照只是 23:02 UTC 一個時間點,之後狀態會變。我沒有找到任何獨立第三方對 OSS Scanner 準確率的評測。
✍️ 實踐
分兩件:不論你是不是維護者,都能拿這組算法審任何「廠商自報精確率」;如果你維護開源專案,可以評估是否報名。
import math
def wilson(k, n, z=1.96):
p = k / n
d = 1 + z * z / n
c = p + z * z / (2 * n)
s = z * math.sqrt(p * (1 - p) / n + z * z / (4 * n * n))
return (c - s) / d, (c + s) / d
# 一、比例附區間(Anthropic 97 筆抽樣:85 筆達 CVD 門檻)
lo, hi = wilson(85, 97)
print(f"85/97 = {85/97:.1%},95% 區間 {lo:.1%}~{hi:.1%}") # 87.6%,79.6%~92.8%
# 二、分診工時:報告數 × 每份分鐘 ÷ 60
for m in (15, 30, 60):
h = 74 * m / 60
print(f"74 份、每份 {m} 分鐘 = {h:.1f} 小時;每個 CVE(5 個)= {h/5:.1f} 小時")
# 三、單位成功成本 = 每次嘗試成本 ÷ 成功率(Terminal-Bench 4.0,發表頁圖表資料)
tb = {"Haiku 5.5 Med": (0.6798, 0.203), "Haiku 5.5 Max": (2.6433, 0.392),
"Sonnet 5.5 Med": (0.6796, 0.288), "Sonnet 5.5 High": (1.462, 0.43),
"Sonnet 5.5 Max": (10.4421, 0.706)}
for k, (c, a) in tb.items():
print(f"{k}: {c/a:.2f} 美元/次成功")步驟:
- 找出你手上任何「廠商自報百分比」,寫下分子、分母、誰量的、量哪一層;分母小於 200 就先算 Wilson 區間再引用。
- 如果你維護專案,先用
tools/validate.py與tools/check <name>在本機確認專案能在無網路的容器裡建置並通過測試(倉庫 README 的建議),再決定是否報名;報名前先盤點:目前每週處理幾份經驗證的 high/critical 報告?說明頁把這當作適合報名的前提。 - 寫
threat_model.md:至少寫嚴重度評級標準、哪些輸入視為對手可控、哪些元件不在範圍;說明頁指出這是校準嚴重度膨脹與誤解威脅模型的主要手段。 project.yaml的信箱是公開的,改用安全專用的別名,可選擇加上 PGP 公鑰讓報告加密寄送(加密時不能再設副本收件者)。- 收到報告後記錄:收到幾份、幾份有效、幾份重複、幾份成為 CVE、每份花你幾分鐘。幾週後你就有自己的 5/74 這種數字,可以決定繼續、暫停(
disabled: true)或退出。
🔗 延伸學習
- Launching an opt-in vulnerability-finding service for open-source software — Anthropic 發表文章全文:29,000/6,000/5,000 三個數字、97 筆樣本的 88%、四則維護者引述。
- OSS Scanner 服務說明頁 — 資格、揭露政策、嚴重度與威脅模型建議、退出方式,都以這頁的 FAQ 為準。
- anthropics/oss-scanner — 倉庫 README 與報名 PR 清單;本文的第一天流量快照來自它的 PR 列表。
- Claude Haiku 5.5 系統卡 — 144 頁 PDF,第 8.4 節 Terminal-Bench 4.0 的試驗次數與 harness、第 8.9.3 節 OSWorld 的 partial 與 strict。
💬 問 AI
我是 [填:開源專案名稱與規模] 的核心維護者,正在評估是否報名 Anthropic 的 OSS Scanner(未經人工審查的模型產出漏洞報告,直接寄給維護者)。請嚴格區分三類:「Anthropic 發表文章、服務說明頁或倉庫 README 明說的」(附網址)、「你實際打開讀到全文的」(只讀到摘要就明說)、「你自己推論的」(標明假設)。查不到就說查不到,不要編,也不要替我做決定。
1. Anthropic 文章裡 97 筆抽樣的 85/97(88%)是在什麼條件下量的(嚴重度、版本、誰審)?請用 Wilson 區間算 95% 區間,並說明「真但重複」的「已知」指的是什麼。
2. 說明頁對未驗證報告的揭露政策是什麼?若我長期不處理,Anthropic 之後人工驗證同一份報告會發生什麼?
3. 我目前每週約處理 [填:數字] 份安全報告,每份約 [填:分鐘] 分鐘。若第一次掃描寄來 [填:數字] 份,請算分診工時與我需要多少人週。
4. 請幫我草擬 `threat_model.md`:我的專案是 [填:用途],對手可控的輸入是 [填:來源],不在範圍的元件是 [填:清單],嚴重度評級想要 [填:規則]。
5. 有沒有獨立於 Anthropic 的第三方對 OSS Scanner 或同類工具準確率的評測?若沒有,請明說「沒找到」。