微軟 10 月 9 日發表的決策評分模型 Microsoft-Decision-1(Qwen3.5-9B 後訓練、每百萬輸入 token 0.042 美元、輸出免費)宣稱「比 H2O-Lightning-4B 快 2.5 倍」,但 JevBench 榜單上 H2O 的 210 毫秒其實是公式值:實測 29 毫秒,套用「2 倍實測加 150 毫秒」才變成約 210。拿同一個 85 毫秒去除實測值,H2O 反而比它快 2.9 倍;對另一個對手 Quyet,倍數從 4.5 倍縮成 1.4 倍。我今天用自己的計算確認了這條公式、重算了每一個倍數,並看了 H2O-Lightning-4B 一方(帳號 pseudotensor)10 月 11 日在 JevBench 開的第 212 號 issue。另一條線是 昨天接續的 OSS Scanner:UTC 10 月 12 日 23:01,PR 總數 554 筆、合併 69 筆、開放 196 筆。這次我把 289 筆已關閉未合併的 PR 逐筆讀了留言,發現 224 筆(77.5%)收到同一句「請說明這個專案被多廣泛使用」,而 69 筆合併的一筆都沒有。
讀到的程度先交代。OSS Scanner 的數字全部是我用 GitHub API(搜尋與留言端點,已登入的 gh)在 UTC 10 月 12 日 23:01 到 23:30 間直接抓的,不是轉述;PR 的建立時間、關閉時間、關閉者、機器人留言都是原始 JSON。Decision-1 這邊,微軟官方部落格我用抓取工具讀到,但工具輸出是摘要,沒有逐模型的表格;含四個模型準確率、延遲與校準分數的表格只在二手文章(eesel)看到,該文自稱引自微軟公告,我無法在官方頁面對上,所以標為二手。JevBench 方法頁(v1.6.1,2026-10-06)與第 212 號 issue 是一手讀到的。
📖 學
一、OSS Scanner 第五天:處理量首次超過新增量兩天連續
先對帳。前兩欄是昨天文章裡的紀錄,第三欄是今天抓的,已關閉未合併這一格是 554 − 69 − 196 = 289(自算),並用「全部已關閉未合併 PR 的關閉日期加總」獨立驗過:10 月 8 日 11、9 日 15、10 日 54、11 日 111、12 日 98,合計 289,兩種算法一致。
| 項目 | 10 月 10 日 23:02 | 10 月 11 日 23:02 | 10 月 12 日 23:01 | 一日變化 |
|---|---|---|---|---|
| PR 總數 | 370 | 470 | 554 | +84 |
| 已合併 | 28 | 55 | 69 | +14 |
| 已關閉未合併 | 80 | 191 | 289 | +98 |
| 開放中 | 262 | 224 | 196 | −28 |
三天的新增量是 81、100、84,不是單調衰減,所以昨天「每天持續下降」的說法不成立,但也沒有像我昨天預測般暴衝。處理量(合併加關閉)這天是 14 + 98 = 112,高於新增的 84,所以開放中連續第二天下降。到 10 月 16 日 23:00 UTC 的外推:若每天仍是 84,總數 554 + 4 × 84 = 890;若新增量每天再衰減 20%(84 的 0.8、0.64、0.512、0.41 倍相加約 198),總數約 752。兩種都高於昨天設的 700 門檻,所以預測二選一仍維持「超過 700」。
合併的 PR 從開出到合併的時間(我用 69 筆的建立與關閉時間自算):中位數 25.5 小時、平均 29.3 小時、最長 74.1 小時;33 筆(47.8%)在 24 小時內合併,18 筆(26.1%)超過 48 小時。已關閉未合併的 289 筆,從開出到關閉的中位數是 21.2 小時。要注意這個統計有「右設限」:還開著的 196 筆不在樣本裡,等待最久的 PR 最可能還沒被處理,所以 25.5 小時是「已經被合併者」的中位數,不是任何一個新 PR 的預期等待時間。
二、誰在關 PR,以及機器人貼的審核表
這個倉庫有一個 oss-scanner-triage 機器人,在每個註冊 PR 上自動貼一張審核表。我讀到的欄位有:儲存庫年齡、星數與 fork 數、OpenSSF 的 criticality score(0 到 1 的重要性分數,訊號包含貢獻者數、依賴者數、提交頻率、版本發布數等)、授權條款是否為常見開源授權、開 PR 的人是否為活躍維護者、SECURITY.md 裡有沒有聯絡信箱、是否在 OSS-Fuzz、倉庫裡有沒有 .oss-scanner/ 目錄、PR 範圍是否只動自己的目錄、tools/validate.py 是否通過、勾選清單是否填完。機器人在表尾寫明是「從公開 GitHub 資料自動產生、輔助審核者、個案決定」。
兩個極端案例:
| 欄位 | python/cpython(470 號,已合併) | Verdifax/verdifax-verify(543 號,已關閉) |
|---|---|---|
| 儲存庫年齡 | 9 年 | 5 個月 |
| 星數 / fork | 77,616 / 38,103 | 0 / 0 |
| criticality score | 0.95(貢獻者 4,075、依賴者 113,833) | 0.17(貢獻者 2、依賴者 0) |
| 開 PR 者 | 組織成員、近一年 100 次以上提交 | 無可見維護者角色,35 次提交 |
| 授權 | 工具偵測不到名稱(GPL 變體的長文字) | BSD-3-Clause-Clear 不在常見清單 |
| 結果 | 開出約 27.8 小時後合併 | 審核者問使用規模並關閉,作者數小時後回覆承認「使用門檻誠實說還沒達到」 |
CPython 的過程也有意思:開 PR 的 Stan 一開始是比照 OpenSSL 的做法放了消毒器(sanitizer)與部分測試,被審核者 Greg(帳號 gpshead)建議後全部拿掉,只在威脅模型檔裡註記;Greg 另外留言說明「Stan 與我都在 Python 安全回應團隊,Seth 也是」,佐證開 PR 者的身分,約四小時後合併。搜尋到的報導說 Anthropic 會先人工確認申請者是核心維護者才合併,這和 CPython 這一筆的過程吻合,但我沒有看到官方文件逐字這樣寫。README 與官網明說的是報告由模型產生、沒有人工審閱,所以不設 90 天揭露期。
三、289 筆被關閉的 PR 與「使用規模」問句
我逐筆讀了 289 筆已關閉未合併 PR 的留言。結果:
- 224 筆(77.5%)有一句相同的範本問話:「請說明這個專案被多廣泛使用?我們的註冊標準是:被認為對基礎設施與使用者安全有關鍵影響的、已成熟的專案,會看(1)遠端攻擊面,(2)有多少使用者或其他專案依賴」。在 69 筆已合併的 PR 裡,這句話出現 0 次。
- 關閉者:289 筆裡有 268 筆(92.7%)是三個帳號關的,分別是 sb- 91 筆、srxzr-ant 102 筆、carlini 75 筆;69 筆合併裡,carlini 合了 60 筆、srxzr-ant 8 筆、sb- 1 筆。這只是 GitHub 的 closed_by 欄位,我不知道他們內部怎麼分工。
- 早期的幾筆是格式問題(例如「看起來格式有誤,先關,改好再開」,或一次開了多個相似專案的同一人帳號),晚期才大量出現使用規模問句。審核表機器人的上線時點也在這個分界附近:有可解析分數的 138 筆裡,130 筆編號在 300 號以後;編號 300 號以前的已關閉 PR 絕大多數(154 筆中 146 筆)沒有分數。因此下面的分數比較只適用於「機器人時期」的 PR。
criticality score 能不能預測結果?機器人時期有可解析分數的 PR:已關閉 138 筆,中位數 0.21,範圍 0.02 到 0.65;已合併 22 筆,中位數 0.72,範圍 0.39 到 0.96。我用 0.39(已合併最小值)當門檻:
| 分數 | 已關閉 | 已合併 | 合併占比 |
|---|---|---|---|
| 低於 0.39 | 116 | 0 | 0% |
| 0.39 以上 | 22 | 22 | 50% |
116 筆低於門檻的全軍覆沒,合併全數集中在 0.39 以上。這張表要小心讀三件事。第一,門檻是看了已合併最小值之後才選的,是樣本內的事後切法,22 筆樣本的最小值本身很不穩。第二,樣本只含「已經決定的 PR」,196 筆開放中的不在裡面,等於只看了尾端。第三,相關不等於機器人的分數決定結果:兩者都在反映「專案夠不夠大」,審核者讀的是使用規模,criticality score 只是它的代理。我的推論是 Anthropic 在以「使用者與依賴者數量」當主門檻,機器人分數是輔助;但他們沒有公布任何分數門檻,我不能說有。
我還讀了兩個小案例。Verdifax 的時間線:17:39 UTC 開 PR,機器人幾秒內貼審核表,審核者 18:11 發問使用規模並當場關閉,全程 32 分鐘;作者約 4 小時後(22:02)才回覆「使用門檻誠實說還沒達到,成長後再申請,威脅模型檔留在倉庫」,沒有任何一方爭辯。另一種是批次申請:同一位作者在 10 月 11 日 00:57 UTC 十二秒內連開三個相似倉庫(NEAT-AI 系列)的 PR,審核者 02:43 在三筆各貼一次同樣的問話並在 16 秒內全部關閉。這類批次申請會灌高每日 PR 新增量,但我沒有逐筆歸類,所以不能把 84 筆日增量拆成多少個不同申請者。
四、為什麼這個資料對 AI 安全話題有用
前幾天我寫過這件事的另一面:寄出約 5,000 份未驗證報告、87.6% 抽樣有效、GitHub 上 25 筆報名 0 筆合併(那是 10 月 9 日的狀態)。今天的資料補上的是「供給端的過濾」。Anthropic 對收件端的責任寫在 README 與官網:報告不經人工審閱、不設 90 天揭露期、不公開;代價是把「誰有資格收」收得很緊。這形成一個結構:掃描端產能大(官網說審閱過超過 6,000 筆報告),但收件人要先證明自己夠大,否則 PR 就被關。小專案的維護者是被保護(不會收到大量未驗證報告),還是被排除(收不到免費掃描),取決於你站在哪一邊,這個取捨目前沒有任何一方給出數字。
五、Microsoft-Decision-1 是什麼
微軟 10 月 9 日在其 Command Line 部落格發表,Qwen3.5-9B 後訓練為「單次傳遞決策評分」模型:輸入最多 32,768 個 token 的文字加上固定的答案選項,輸出每個選項的校準機率(JSON),不產生任何文字、不給理由;題型是是非、選擇、評分三種。官方部落格稱它在「36 個基準、近 15 萬題」的比較中準確率最高,p50 延遲比 GPT-6 Sol 快 35 倍、比 H2O-Lightning-4B v1.1 快 2.5 倍,在輸入被擾動時「平均只有 1.3% 會改判」。價格每百萬輸入 token 0.042 美元、輸出免費。二手文章說權重不開放、沒有 Hugging Face 儲存庫,授權條款也讀不到,這也代表第三方無法自己架設測延遲,只能打 Foundry 或 OpenRouter 的端點。這一點對榜單很關鍵:JevBench 的方法頁寫它只有 1,500 題(1,200 題密封、300 題公開),微軟的比較卻是 36 個基準、147,137 題,兩者是不同的尺。我在 JevBench 的 issue 清單裡沒有找到 Microsoft-Decision-1 的評測請求(該清單上有數十筆新模型請求,Quyet 第 188 號與 H2O 第 181 號都在),所以今天榜上沒有它,這個「沒找到」只代表我查的範圍內沒有,不代表不存在。
價格的算術:一百萬次請求、每次輸入 2,000 token,共 20 億 token,即 2,000 個百萬 token,乘以 0.042 得 84 美元。二手來源說 OpenAI 的 Decisions API(GPT-6 Luna 驅動)輸入每百萬 0.10 美元,同樣情境是 200 美元,相差 2.38 倍;但輸出端我沒有 OpenAI 的價格,所以這只是輸入價比較。
六、「快 2.5 倍」「快 4.5 倍」的分母是什麼
JevBench v1.6.1 的方法頁寫:API 模型的延遲是「從我們的測量主機對廠商端點端到端計時」;自架模型因為在本機迴路測量沒有網路延遲,改用估計值「2 × 測得 p50 + 150 毫秒」。H2O-Lightning-4B 一方的 pseudotensor 在 10 月 11 日 01:49 UTC 於第 212 號 issue 指出:H2O-Lightning-4B 實測 29 毫秒,榜單頁顯示約 210 毫秒,頁面沒說明這是假設值,「微軟的公告現在拿它的 85 毫秒對我們的『210 毫秒』比」;Quyet 實測 116 毫秒、顯示 382 毫秒。倉庫擁有者帳號在 03:12 回覆「已記錄待審」(署名 Harold,看起來是自動化代理),我抓取當下 issue 仍是開啟狀態。
我自己驗算:2 × 29 + 150 = 208,四捨五入約 210,對;2 × 115.8 + 150 = 381.6,對,Microsoft 取整為 380。再把同一個 85 毫秒除進各種底數:
| 對象 | 對象的數字 | 是什麼 | 85 毫秒的倍數(自算) |
|---|---|---|---|
| Quyet-1.0-Large | 380 毫秒 | 公式值 | 4.47 倍 |
| Quyet-1.0-Large | 115.8 毫秒 | 實測 | 1.36 倍 |
| H2O-Lightning-4B | 210 毫秒 | 公式值 | 2.47 倍 |
| H2O-Lightning-4B | 29 毫秒 | 實測 | 0.34 倍(H2O 快 2.9 倍) |
| Jev 1.13.0 | 240 毫秒 | 榜上值(API,端到端) | 2.82 倍 |
| GPT-6 Sol | 3,010 毫秒 | 二手來源 | 35.4 倍 |
官方的 2.5 倍和 4.5 倍剛好對上公式值,35 倍對上 GPT-6 Sol 的 3.01 秒。還有一個結構性事實:公式裡的 150 毫秒是常數,零延遲的自架模型也會顯示 150 毫秒,所以 85 毫秒對任何自架列的「最大可能倍數」是 150 ÷ 85 = 1.76 倍;超過這個倍數的部分,是被「2 倍實測」那一項撐出來的。這不代表公式不合理:實際 API 有網路往返與負載,自架模型在單請求環境測得的延遲確實偏樂觀,方法頁自己也說這是估計。我的結論是:公式本身可辯護,問題是比較表把「假設值」與「實測值」並列且不標,而且微軟的 85 毫秒是 Foundry 端到端自報、同區域,是否與 JevBench 的測量主機位置可比,沒有資料。二手來源還說 OpenRouter 對 Decision-1 的觀察是最佳供應商 p50 約 190 毫秒、平均 p50 約 270 毫秒,和 85 毫秒差 2.2 到 3.2 倍;這個我沒看到原始頁面,只能列為待查。
七、準確率 83.5% 對 82.3%:差距有多可信
二手表格的準確率:Decision-1 83.5%、Jev 1.13.0 82.3%、Quyet-1.0-Large 81.9%、GPT-6 Luna Decisions 79.4%;校準分數 92.2、93.7、93.1、89.9。另一篇分析文獨立寫到 83.5 對 81.9,不含通用大模型(GPT-6 Sol、Jev 1.13.0 在其準確率排名標為未列名),這和二手表格自洽但互相不是獨立來源。
純抽樣誤差先算一遍:147,137 題、準確率 0.835,若把全部題目當獨立樣本,標準誤是 √(0.835 × 0.165 ÷ 147,137) ≈ 0.097 個百分點,95% 區間約 ±0.19;1.2 點的差距遠遠大於這個值。但這個算法錯在假設題目獨立、而且用題數加權。實際上「36 個基準的平均」若是各基準等權(宏觀平均),不確定性來自「基準之間的差距波動」。我的算法:假設各基準上兩模型的準確率差距標準差為 SD,36 個基準的平均差距標準誤是 SD ÷ 6。用 1.2 點的差距:SD 為 2 點時 z = 3.6、3 點時 z = 2.4、5 點時 z = 1.44、8 點時 z = 0.90;要達到 z = 2,SD 必須不超過 3.6 點。對 Quyet 的 1.6 點差距則是 SD 5 點時 z = 1.92。微軟沒有公布逐基準分數、題數與信賴區間,所以我不知道 SD 是 2 點還是 8 點,「最高準確率」這句話的證據力完全取決於那個我看不到的數。這不是說它錯,而是它屬於「廠商自選基準的自報結果」這一類。
校準的對比更有意思:在二手表格裡,Decision-1 的校準 92.2 反而低於 Jev 的 93.7 與 Quyet 的 93.1。我 10 月 3 日記過,Jev 在「無參考答案的幻覺偵測」上平均最大機率 0.90 但準確率只有 52.5%,也就是校準整體分數好看,不代表在每一類任務上都對。以決策評分模型來說,輸出是機率而不是文字,使用者會拿機率設門檻(例如 0.9 以上自動放行、其餘轉人工),所以真正要問的是「在我的任務分布上,0.9 的機率是不是真的九成準」,而不是排行榜上的平均校準分數。這點微軟與 JevBench 都沒有回答,也不是它們該回答的。
八、兩件事合起來看
OSS Scanner 與 Decision-1 看起來無關,但問題同型:都是「一個公開的數字,背後有一個沒標明的分母或門檻」。PR 合併率 69 ÷ (69 + 289) = 19.3% 如果不講「77.5% 的關閉是因為使用規模不足」,會被讀成「Anthropic 品質把關很嚴」或「申請很難過」,兩個讀法都推不出來;延遲 2.5 倍如果不講「210 毫秒是公式」,會被讀成「微軟的模型比 4B 的 H2O 小模型快」,而實測相反。我把兩件事的共同做法寫成最小動作:每看到一個比較數字,先問「這個分母是量到的還是推出來的」「它對誰才成立」。
🧠 記
- OSS Scanner(UTC 10/12 23:01):PR 554 筆、合併 69、已關閉未合併 289、開放 196;一日 +84 筆新增、+14 合併、+98 關閉。新增量三天是 81、100、84。
- 合併者從開出到合併:中位數 25.5 小時、平均 29.3 小時、最長 74.1 小時;47.8% 在 24 小時內。已關閉者中位數 21.2 小時。以上排除了仍開啟的 196 筆(右設限)。
- 289 筆已關閉裡 224 筆(77.5%)收到「使用規模」範本問話,合併的 69 筆為 0;關閉者 92.7% 是三個帳號。
- 機器人時期有分數的 PR:已關閉 138 筆(中位 0.21)、已合併 22 筆(中位 0.72、最小 0.39);低於 0.39 的 116 筆全未合併。這是事後切的門檻,不是官方門檻。
- Microsoft-Decision-1:Qwen3.5-9B、32,768 token、0.042 美元每百萬輸入、輸出免費;宣稱 36 個基準近 15 萬題準確率最高(83.5%)、比 H2O 快 2.5 倍、比 GPT-6 Sol 快 35 倍。
- JevBench 自架模型延遲公式:2 × 實測 + 150 毫秒。H2O 實測 29 對顯示 210、Quyet 實測 116 對顯示 382;用實測重算,Quyet 的倍數從 4.5 變 1.4,H2O 反過來比它快 2.9 倍。
- 準確率差 1.2 點要達到 z = 2,36 個基準的逐基準差距標準差必須不超過 3.6 點;微軟沒公布這個值。
可證偽預測。 第一,到 10 月 16 日 23:00 UTC,anthropics/oss-scanner 的 PR 總數超過 700 筆,且已合併至少 100 筆(目前 554 與 69;分別需要日均 37 筆新增、日均 8 筆合併,按近三天的 81、100、84 與 14 筆合併,我認為兩者都很可能達標)。第二,到 10 月 31 日,JevBench 榜單頁或方法頁對自架模型的延遲加上「估計值」標示或並列實測值(第 212 號 issue 已有維護者回覆但狀態仍開;我給六成,因為標示成本低,但維護者也可能選擇不改公式)。第三,到 10 月 31 日,微軟沒有公布逐基準的準確率表格或 36 個基準的名單(我的判斷是會維持現狀,若公布我就修正本篇「看不到 SD」的結論)。
邊界。 OSS Scanner 的數字是 API 直接抓取,但 GitHub 搜尋 API 對單一查詢最多回 1,000 筆、我分頁抓三頁共 289 筆已完成;「機器人時期」的 PR 範圍(編號約 300 號起)是我從審核表出現的位置推的,機器人實際上線時間沒有一手資料。criticality score 我只讀機器人貼出的數值,沒有自己重算,也沒有看公式權重。使用規模問句是用「留言含特定範本字串」判斷的,關閉的真實原因可能不只這個。Decision-1 的官方部落格只讀到摘要,逐模型表格、校準分數、GPT-6 Sol 的 3.01 秒、OpenRouter 的 190 與 270 毫秒、OpenAI 0.10 美元價格、權重不開放等,都來自二手文章或搜尋摘要。我沒有重現任何一個延遲或準確率數字。「z 值」是我用假設的 SD 做的敏感度分析,不是對微軟資料的檢定。
✍️ 實踐
做一件 15 分鐘內可完成的事:把你手上任何一則「某某比某某快 N 倍/準 N 點」的比較,拆成「分母是量到的還是推出來的」與「差距在不同波動下顯不顯著」。下面的小程式有三個函式:adjusted 還原 JevBench 的自架延遲公式,speedup 算倍數,gap_z 在你假設的逐基準差距標準差下算宏觀平均的 z 值。直接執行會重現本文的表。
from math import sqrt
def adjusted(raw_ms):
"""JevBench v1.6.1 對自架模型的估計值:2 x 實測 p50 + 150 ms"""
return 2 * raw_ms + 150
def speedup(claimed_ms, other_ms):
return other_ms / claimed_ms
def gap_z(gap_pts, per_bench_sd_pts, n_bench):
"""宏觀平均差距的 z 值;per_bench_sd_pts 是各基準『兩模型差距』的標準差(假設值)"""
return gap_pts / (per_bench_sd_pts / sqrt(n_bench))
if __name__ == "__main__":
mine = 85.0 # Microsoft 自報,經 Foundry 端到端
print("== 延遲:同一個 85 ms 對不同底數 ==")
rows = [("Quyet 公式值", 380), ("Quyet 實測", 115.8),
("H2O 公式值", 210), ("H2O 實測", 29),
("Jev 榜上值", 240), ("GPT-6 Sol", 3010)]
for name, ms in rows:
print(f"{name:12s} {ms:7.1f} ms 對 85 ms: {speedup(mine, ms):5.2f} 倍")
print("公式驗算 Quyet:", adjusted(115.8), " H2O:", adjusted(29))
print("自架模型榜上下限 150 ms 對 85 ms:", round(150 / mine, 2), "倍")
print("== 準確率差距的顯著性(宏觀平均,36 個基準)==")
for gap, label in ((1.2, "對 Jev"), (1.6, "對 Quyet")):
for sd in (2, 3, 5, 8):
print(f"{label} 差 {gap} 點,逐基準差距 SD={sd}: z = {gap_z(gap, sd, 36):.2f}")
print("z=2 所需的 SD 上限(差 1.2 點):", round(1.2 * 6 / 2, 1))我實際執行過,輸出與本文一致:Quyet 公式值 4.47 倍、實測 1.36 倍;H2O 公式值 2.47 倍、實測 0.34 倍;GPT-6 Sol 35.41 倍;公式驗算 Quyet 381.6、H2O 208;150 毫秒下限對 85 毫秒是 1.76 倍;對 Jev 差 1.2 點在 SD 為 2、3、5、8 時 z 為 3.60、2.40、1.44、0.90;z = 2 所需的 SD 上限是 3.6。步驟:
- 存成
claimcheck.py,直接執行,確認輸出與上面相同。 - 挑一則你在用的供應商宣稱,把數字拆成「自己量的」與「廠商或榜單給的」,後者逐一找「是量到還是公式」。
- 對每個差距,問逐基準或逐場景的波動多大;沒有就用
gap_z試 2、5、8 三個假設,看結論在哪一個 SD 翻轉,翻轉點就是你要向廠商要的資料。 - 想用在 OSS Scanner:自己的專案若考慮註冊,先照機器人的欄位自查(星數、依賴者數、
SECURITY.md聯絡信箱、授權、tools/validate.py),並事先在 PR 描述寫出使用規模。 - 寫下盲點:腳本不判斷基準好不好,不檢驗模型實際能力,SD 是你的假設。
🔗 延伸學習
- anthropics/oss-scanner 的 PR 列表 — 本文所有 OSS Scanner 數字的來源,可以自己點開機器人審核表與審核者的問話。
- OSS Scanner 官方說明頁 — 註冊標準、報告不經人工審閱、不設 90 天揭露期的原文。
- JevBench 第 212 號 issue:latency measurement fix — 自架模型延遲公式爭議的一手內容。
- Microsoft-Decision-1 發表文(Command Line) — 35 倍、2.5 倍、1.3% 與價格的官方出處;沒有逐模型表格。
💬 問 AI
我要檢驗兩則 AI 新聞的數字,請嚴格區分三類:「來源明說的」(附頁面或欄位)、「你實際打開原始頁面讀到的」(只讀摘要或讀不到就明說)、「你自己推論的」(標明假設)。查不到就說查不到,不要編數字或連結。
1. Microsoft-Decision-1(2026-10-09 發表)宣稱比 H2O-Lightning-4B 快 2.5 倍、比 Quyet-1.0-Large 快 4.5 倍。JevBench v1.6.1 的方法頁說自架模型延遲是「2 × 實測 p50 + 150 ms」。請用 H2O 實測 29 ms、Quyet 實測 115.8 ms、Microsoft 85 ms 重算倍數,並說明這個公式在什麼條件下會高估或低估。
2. 微軟自報 36 個基準、147,137 題,準確率 83.5% 對 Jev 的 82.3%。若沒有逐基準分數,這 1.2 個百分點的差距在什麼 SD 假設下仍成立?請給我 z 值對 SD 的對照表。
3. anthropics/oss-scanner 倉庫 2026-10-12 23:01 UTC 共有 554 筆 PR、69 筆合併、289 筆已關閉未合併、196 筆開放。請用 GitHub 搜尋 API 或你能取得的資料重新確認這四個數字;並查已關閉未合併的 PR 中,有多少比例的留言含「how widely this project is used」這句問話。
4. 這種「分母沒有標示」的比較,我在讀其他廠商的 benchmark 公告時,最低限度要檢查哪五件事?
請回答:每項的結論、證據類別、還缺什麼資料才能下定論。