目錄
今日總覽
今天三篇論文從評測、鷹架、除錯三個不同切入點,同時戳破一個假設——只要 Agent 系統的分數好看,它就是可信的。GAUGE 稽核業界最常用的「模擬使用者 + LLM 評審」上線關卡,發現高達 57.5% 被評為「滿意」的對話其實任務失敗了,而且評測關卡在最關鍵的「勢均力敵候選」情境下最不可靠。Harness or Model? 做了少見的同模型換鷹架對照實驗,結論是官方鷹架並沒有站得住腳的平均優勢,但中立鷹架反而貴 1.2 到 1.6 倍。Continual Search 則指出,連「找出 Agent 哪裡壞掉」這件事本身也需要重新設計——一次性 LLM 判官會太早停止搜尋,把真正的根因留在沒讀到的證據裡。三篇的證據成熟度不盡相同:GAUGE 經過同行審查、規模最大;Harness or Model 的主結論紮實,但最吸睛的交互作用結果自己標註為初步;Continual Search 的增益集中在作者自建的小型新 benchmark 上,短流程場景甚至可能適得其反。合起來看,我們平常用來判斷 Agent 有沒有變好的三種手段——上線評測、鷹架選型、故障除錯——全部都比想像中脆弱。
讀這篇前該知道的詞
| 詞 | 白話解釋 |
|---|---|
| LLM 評審(LLM-as-a-Judge) | 讓另一個大型語言模型讀對話紀錄、打分數,取代人工評分或直接量測任務有沒有做成 |
| 鷹架(Harness) | 把聊天模型變成能自主執行任務的 Agent 的那層程式——包含工具定義、prompt、控制流程,不含模型本身 |
| 可驗證獎勵(Verifiable Reward) | 不靠語言模型判斷,而是直接查資料庫狀態或程式跑出來的結果,客觀認定任務有沒有真的做成 |
| 根因歸因(Root-Cause Attribution, RCA) | Agent 執行失敗後,從一長串動作紀錄裡找出「第一個出錯的地方」,而不是只看「最後結果失敗了」 |
| Post-hoc 切分 | 先看過資料結果、才決定怎麼分組比較,這種分法容易找出巧合的規律,需要事先設計好的重複實驗才能確認是真的效應 |
| 防汙染任務集(Contamination-Controlled Suite) | 確保測試題目沒有出現在模型訓練資料裡的任務集合,常見做法是用私有題目或訓練截止日期之後才公開的題目 |
論文一｜GAUGE:別急著相信 LLM 評審——滿意度跟任務有沒有做成幾乎沒關係
GAUGE: When Not to Trust LLM-as-a-Judge in User-Simulated Evaluation of Task-Oriented Agents Umesh Bodhwani, Thanh Tran, Kai Wei（Amazon） · arxiv: 2609.12191
TL;DR
25 個 Agent、6 個供應商在 τ²-bench 與 SimulatorArena 上的稽核顯示,LLM 評審打出的「滿意」對話有 57.5% 其實任務失敗;在勢均力敵的候選之間,評測關卡選錯 Agent 的機率高達 31%(相較懸殊候選時 <1%)。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | Accepted to EMNLP 2026(Industry Track)——已同行審查並接受 |
| 引用速度 | 發布約 6 天;Semantic Scholar API 本輪持續回傳 429 限流,無法查得引用數,以發布時間推估仍在個位數 |
| 機構 | Amazon(Umesh Bodhwani, Thanh Tran, Kai Wei 皆掛名 Amazon) |
| 社群反應 | 本輪未見於 HuggingFace Daily Papers 或 Papers with Code;以 EMNLP Industry Track 接受作為主要背書 |
| 可信度 | 通過 — 25 個 Agent、6 個供應商、兩個 benchmark(τ²-bench、SimulatorArena)、約 3,700 筆對話,以可驗證的非 LLM 獎勵(資料庫狀態核對)做基準,並區分 ranking validity 與 construct validity 兩種效度 |
| 證據成熟度 | 較完整 — 涵蓋滿意度-成功落差、跨供應商排名穩健度、評審自我偏好、校準後追蹤(calibrate-then-trust)四組互相印證的分析,並在第 4.6 節主動報告負向結果 |
| 可復現性 | 未提供 — 本輪查無公開程式碼或資料釋出連結;τ²-bench、SimulatorArena 本身雖是公開 benchmark,但作者自建的稽核協定與轉錄資料未見公開 |
| 為什麼選這篇 | 直接 — 直接檢驗業界最常見的「模擬使用者 + LLM 評審」上線關卡是否真的可信 |
| 方向新意 | 實質增量 — 首次在釋出決策的單位上,把這套關卡的排名拿去對照可驗證的非 LLM 獎勵做稽核,並量化滿意度與任務成功的落差 |
| 今日重要性 | 高 — 幾乎所有用 LLM-judge 做 CI 品質關卡的團隊都在依賴這套邏輯,而論文顯示它在最關鍵的「勢均力敵候選」情境下最不可靠 |
| 實務連結 | 明確 — 論文提出「校準後追蹤」節奏:定期用可驗證獎勵校準關卡的可信範圍,而不是每次決策都直接信任關卡分數 |
| 編輯信心 | 高 — 57.5% 與 31% 兩個核心數字都附有跨評審族群、跨 benchmark 的一致性檢驗,論文也明確承認再校準無法跨設定轉移 |
| 閱讀建議 | 必讀 — 任何用 LLM-judge 或使用者模擬器做 Agent 上線關卡的團隊 |
| 主要限制 | 校準後的信任區間無法跨設定轉移(第 4.6 節的負向結果),意味著這套稽核協定本身需要在每次配置變動後重新執行,而不是校準一次就能長期沿用 |
領域背景
比較 Agent 品質的業界標準做法,是讓人設模擬的使用者跟候選 Agent 對話,再用 LLM 當評審打分數決定要不要升版——這套流程跑在 CI 裡,一次只要幾分錢,不需要人工標註。過去的研究驗證過 LLM 評審跟人類偏好的相關性,但很少有人拿它跟「任務到底有沒有真的做成」這個客觀事實做對照,尤其是在真正決定升版與否的那個單位上。
中階導讀
- 問題:想像你要決定該升級客服 Agent A 還是 Agent B。你讓兩者各自跟一批模擬顧客對話,再請另一個 AI 讀對話紀錄打滿意度分數,分數高的那個就升版上線。問題是:一段對話讀起來「賓主盡歡」,不代表顧客真正要辦的事有辦成。
- 方法:GAUGE 在 τ²-bench(零售、航空)與 SimulatorArena(數學家教)兩個有客觀對錯的 benchmark 上,讓 25 個來自 6 家供應商的 Agent 各自跑過完整流程,同時收集四種評分:LLM 評審的分數、LLM 扮演人類的分數、真人盲測面板的分數,以及不靠語言模型判斷、直接查資料庫狀態或核對答案的「可驗證獎勵」。GAUGE 把這四組分數放在一起比,分別檢驗「排名是否一致」(ranking validity)跟「有沒有測到真正想測的東西」(construct validity)。
- 為什麼重要:這代表你的 CI 品質關卡可能「內部一致」——LLM 評審跟真人打分數的方向一樣——卻同時「測錯東西」,因為真人跟 LLM 都容易被一段讀起來順暢的對話唬過去,而這個盲點在最需要精準判斷的「兩個候選其實差不多強」的情境下最嚴重。
深入要點
- 57.5% 被盲測面板評為「滿意」(7 分制 ≥5 分)的對話,其實客觀查核下任務失敗了,這個落差跨五個評分者族群、兩個 benchmark、所有主觀評分維度都存在
- 整體排名的相關性其實不差(ρ=0.94),但決策分歧率在懸殊候選之間 <1%,在勢均力敵候選之間跳到 31%——而勢均力敵候選正是實際做升版決策時最常遇到的情境
- 同家族評審對自家模型有 +0.75/7 分的自我偏好加成 ⚠️(作者自測,未見外部團隊複現)
- 一個完全不用 LLM、零成本的「有沒有把對話完整跑完」訊號,對抓「模型被截斷」這類嚴重退化的效果(ρ=0.87)比滿意度分數(ρ=0.80)還準
- 落地門檻:需要至少一個有客觀對錯答案的 benchmark 才能做這種稽核,如果你的產品完全沒有可驗證的正確答案,這套方法沒有直接的施力點
- Limitation:校準後的信任區間換一套設定就要重新校準,作者自己在第 4.6 節報告這個跨設定轉移失敗的負向結果
Reviewer 一句話評
在釋出決策的單位上第一次把「模擬使用者+LLM評審」這套業界標準跟可驗證獎勵放在一起稽核,25 個 Agent、近 3,700 筆對話的規模加上 EMNLP 同行審查,是今天最紮實的一篇;但校準後的信任區間無法跨設定轉移,代表這套稽核協定本身需要持續維運,而不是做一次就能一勞永逸。
給你的 take-away
- 如果你用 LLM-judge 或使用者模擬器做 Agent 升版關卡:找一個哪怕只是部分場景有客觀對錯的子集,定期用它稽核你的評審關卡,尤其要盯緊「兩個候選分數很接近」的情境,那正是關卡最容易失準的地方
- 如果你在解讀滿意度分數:把滿意度當成一個需要單獨驗證的訊號,不要預設「使用者說滿意」等於「任務真的做成了」
論文二｜鷹架重要,還是模型重要?一場同模型換鷹架的受控實驗
Harness or Model? Isolating the Harness Effect in Agentic Coding with a Contamination-Controlled Private Suite Mohsen Arjmandi（evolutionID GmbH, Germany） · arxiv: 2609.11987
TL;DR
在 256 個防汙染的私有任務上,把模型固定、只換鷹架(claude-agent-sdk vs deepagents、openai-codex SDK vs deepagents),兩組對照都沒能確立官方鷹架的平均優勢(Opus 4.8 的 95% 信賴區間為 [-10.0, +7.5] pp),但中立鷹架每個解決任務的成本反而高 1.2–1.6 倍。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(未經同行審查;ACM 分類標記顯示以會議投稿格式準備,但未見接受紀錄) |
| 引用速度 | 修訂版發布約 8 天(原始 8 月版因遙測缺陷已撤回重發);Semantic Scholar API 本輪持續限流,無法查得引用數 |
| 機構 | evolutionID GmbH, Germany——獨立研究者 Mohsen Arjmandi 個人研究,非學術機構或大型實驗室掛名 |
| 社群反應 | 本輪未見於 HuggingFace Daily Papers 或 Papers with Code |
| 可信度 | 通過 — 256 個防汙染任務(179 個私有 repo 任務 + 77 個 cutoff 後競賽題)、792/800 次規劃執行經 Docker 隔離的 oracle 評分,附任務層級 bootstrap 信賴區間與凍結池的機制性選案規則 |
| 證據成熟度 | 初步 — 核心的「無穩定平均優勢」結論證據完整,但最有意思的「Opus 在 repo 任務落後、在競賽任務反超」交互作用是資料出來後才選定的切分(post-hoc),作者自己標註需要設計過的重複實驗才能確立 |
| 可復現性 | 部分產物 — 公開 orchestrator、Docker 隔離 oracle、reanalysis 程式碼與衍生匯總數據;核心的 256 個任務題目本身為防汙染考量維持私有 |
| 為什麼選這篇 | 直接 — 直接檢驗「官方鷹架一定比中立鷹架強」這個 Agent 工程界普遍假設是否站得住腳 |
| 方向新意 | 實質增量 — 首次在同模型固定、只換鷹架的配對設計下,同時測容量與每個解決任務的成本,並公開一套遙測缺陷的自我修正紀錄 |
| 今日重要性 | 高 — 許多團隊在 vendor-native SDK 與 LangGraph 類中立鷹架之間做選型時,正是預設官方配對比較強,這篇論文的證據直接挑戰這個預設 |
| 實務連結 | 明確 — 論文的配對成本數字(1.2–1.6 倍)可以直接餵進「該不該換鷹架」的採購或架構決策 |
| 編輯信心 | 中 — 「無穩定平均優勢」這個主結論證據紮實;但交互作用與帳務計價順序兩個更吸睛的子結論,論文自己都標註為尚未解決,語氣需要對應降低 |
| 閱讀建議 | 必讀 — 正在選型或比較 Agent 鷹架(claude-agent-sdk、openai-codex、LangGraph 類方案)的團隊 |
| 主要限制 | 核心任務題目保持私有,外部團隊無法用完全相同的任務重跑;Opus 4.8 在 58 次執行上遺失用量紀錄,導致帳務計價順序本身仍「未解決」 |
領域背景
Coding agent 領域近來吵得最兇的問題之一,是「鷹架」(把模型接上工具、prompt、控制流程的那層軟體)到底有沒有價值——供應商都主張自家模型配自家鷹架效果最好,但業界一直沒有在同一個模型上只換鷹架做過乾淨的對照實驗,大多數比較都是連模型帶鷹架一起換,分不清楚差異是哪邊造成的。
中階導讀
- 問題:想像你已經決定要用 Claude Opus 4.8,現在要選:用 Anthropic 官方的 claude-agent-sdk,還是用中立的 deepagents(基於 LangGraph)?供應商會告訴你官方配對「就是比較懂自家模型」,但這個說法從沒被乾淨地測過。
- 方法:作者固定模型不變,只換鷹架:Opus 4.8 分別跑在 claude-agent-sdk 跟 deepagents 上,GPT-5.5 分別跑在 openai-codex SDK 跟 deepagents 上,同一批 256 個防汙染任務(179 個私有 repo 任務加上 cutoff 後才公開的 77 個競賽題),讓兩種鷹架在完全相同的沙箱、任務、prompt 下對打,792 次執行由跟研究團隊無關的隔離 oracle 評分。
- 為什麼重要:這代表「用官方鷹架比較保險」這個選型時常見的預設,目前沒有紮實證據支持——兩組對照的信賴區間都含零,意味著看不出哪邊穩定贏;但中立鷹架卻實實在在貴 1.2 到 1.6 倍,如果團隊只因為「官方配對聽起來比較安全」就多付這筆錢,這篇論文提供了重新算一次帳的理由。
深入要點
- Opus 4.8:官方鷹架 48.8% vs 中立鷹架 50.0%,差距 -1.25 個百分點,95% 信賴區間 -10.0, +7.5
- GPT-5.5:官方鷹架 55.6% vs 中立鷹架 54.4%,差距 +1.25 個百分點,95% 信賴區間 -4.4, +6.9
- Opus 4.8 的平均數字背後藏著方向相反的兩群:官方鷹架在 61 個 repo 任務上落後 9.0 個百分點,卻在 19 個競賽任務上反超 23.7 個百分點(排列檢定 p=0.003)⚠️(這個切分是看過資料後才選定的 post-hoc 切分,作者自己標註需要設計過的重複實驗才能確立)
- 中立鷹架每個解決任務的成本,Opus 4.8 上高 1.2–2.1 倍(依計價基準不同)、GPT-5.5 上高 1.05–1.33 倍;但 Anthropic 帳號有 58 次執行遺失用量紀錄,把這筆帳分給任一邊都會讓比值在 0.7 到 2.3 之間移動,帳務計價順序本身仍「未解決」
- 落地門檻:核心 256 個任務保持私有以防汙染,外部團隊沒辦法用完全相同的題目重跑,只能重跑作者釋出的 orchestrator 跟 oracle 在自己的任務集上
- Limitation:這是一份修訂版論文——8 月的原始版本的成本結論建立在自家遙測系統的一個用量語意缺陷上(不同 SDK 對 cache token 的計算慣例不同,正規化器誤把一種慣例套用到全部三套鷹架),這次版本重新從原始逐輪事件推算所有成本數字並公開了修正紀錄
Reviewer 一句話評
同模型換鷹架的配對設計、KVM microVM 隔離、任務層級 bootstrap 信賴區間,加上主動公開並修正自己先前版本的遙測缺陷,這種自我校正的透明度在單人研究裡相當難得;但最吸睛的「官方鷹架在競賽任務反超」這個交互作用是資料出來後才選定的切分,以及 58 次執行遺失用量紀錄讓帳務計價順序未解決,兩者都提醒讀者不要把這篇論文的每個數字都當成定論。
給你的 take-away
- 如果你在幫團隊選 Agent 鷹架:不要預設官方配對就是保險牌,先看清楚你的任務更接近「repo 修復」還是「封閉題目求解」——這篇論文顯示官方鷹架的優劣勢方向在這兩種任務型態上可能是相反的
- 如果你在算 Agent 平台的營運成本:中立鷹架不見得比較便宜,在把「可移植性」當成換鷹架的理由之前,先把帳算清楚,尤其留意你自己的計費系統有沒有跟這篇論文一樣的 cache token 語意陷阱
論文三｜根因分析其實是個搜尋問題——讓判官別太早停止找證據
Root-Cause Attribution Is a Search Problem: Continual Search for Long-Horizon Agent Failures Harsh Raj, David Lee, Anas Mahmoud et al.（Scale AI） · arxiv: 2609.13463
TL;DR
在自建的 MegaRCA-Mix(50 筆長流程失敗案例,執行紀錄中位數 286K token)上,讓判官在多輪對話中持續挑戰自己現有的診斷、搜尋還沒讀過的證據,把 GPT-5.5 的根因歸因 F1 從 0.349 拉高到 0.498,而且同一世代裡,調度得當的較低階模型有時能贏過較高階的模型。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(cs.AI/cs.HC/cs.LG/cs.SE 跨列,未經同行審查) |
| 引用速度 | 發布約 5 天;Semantic Scholar API 本輪持續限流,無法查得引用數 |
| 機構 | Scale AI(全部 10 位作者皆掛名 Scale AI) |
| 社群反應 | HuggingFace Daily Papers 已收錄(檢視時 0 upvotes、1 則討論);本輪未見 Papers with Code |
| 可信度 | 通過 — 在 TRAIL、TELBench、AgentRx、Who&When 四個既有 benchmark 加上自建的 MegaRCA-Mix 上做評測,對照 self-consistency、異質判官小組等既有 baseline,並明確報告方法在短流程上反而會讓正確判斷被翻案的負面案例 |
| 證據成熟度 | 初步 — 核心增益集中在自家新提出的 MegaRCA-Mix(僅 50 筆案例)與另一個長流程 benchmark TELBench,在既有的短流程 benchmark 上效果不明顯甚至變差 |
| 可復現性 | 未提供 — 本輪查無 MegaRCA-Mix 資料集或程式碼的公開釋出連結 |
| 為什麼選這篇 | 直接 — 直接處理「Agent 出包了,但要花多少力氣才能找到真正原因」這個除錯痛點 |
| 方向新意 | 實質增量 — 把根因歸因重新定義成搜尋問題而非一次性判斷,並引入專門針對長流程(百萬 token 級)執行紀錄設計的新 benchmark |
| 今日重要性 | 中 — 對維運大規模 Agent 機隊、需要事後歸因失敗的團隊直接有用,但對還沒累積大量長流程執行紀錄的團隊迫切性較低 |
| 實務連結 | 明確 — 論文的核心建議可以直接落地:讓除錯判官做多輪持續搜尋而非一次性判斷,且明確指出這在短流程任務上可能適得其反 |
| 編輯信心 | 中 — 「持續搜尋在長流程上有效」證據清楚;但「低階模型能贏過高階模型」這個更驚人的子結論,樣本量(50 筆案例)偏小,論文本身也承認短流程上方法可能讓判斷變差 |
| 閱讀建議 | 略讀 — 已在營運長流程、大規模 Agent 系統並需要建立除錯機制的團隊優先讀;一般讀者可先看深入要點 |
| 主要限制 | MegaRCA-Mix 是作者自建、僅 50 筆案例的新 benchmark,尚無外部團隊驗證;方法在短流程 benchmark(AgentRx、Who&When)上因判官被迫重新檢視既有判斷,反而更容易把正確答案翻案成錯誤答案 |
領域背景
隨著 Agent 系統走向自我改進——從失敗軌跡裡學習、迭代修正自己的行為,甚至修改自己的架構——「找出失敗的真正原因」(root-cause attribution)變成一個反過來餵養整個系統持續變好的關鍵環節。但過去的自動化 RCA 方法幾乎都是一次性的 LLM 判官讀完整段執行紀錄、給一個診斷,對短流程還算堪用,對長流程就開始失準。
中階導讀
- 問題:想像一個 Agent 跑了一個橫跨數千步、留下數十萬 token 執行紀錄的長任務,最後失敗了。真正出錯的地方可能發生在流程很早期、被淹沒在後面幾百個看起來正常的動作裡。你請一個 LLM 讀完整段紀錄後告訴你哪裡出錯——但它讀到一半就覺得「大概是這裡」然後定案,後面還有更關鍵的證據根本沒被看到。
- 方法:作者把這個問題重新定義成搜尋問題:除了原本一次性的判官,額外設計 Continual Search,讓判官在後續每一輪都被要求主動挑戰自己現有的答案、去找還沒讀過的證據,而不只是被動地重新確認一次(Passive Continuation)。他們同時發布 MegaRCA-Mix——50 筆執行紀錄中位數高達 286K token 的長流程失敗案例,填補既有 benchmark 普遍偏短的空白。
- 為什麼重要:這代表「除錯」本身不是把整段紀錄塞給 LLM 讀一遍就好,而是需要專門設計成持續搜尋的流程;而且更值得注意的是,在流程夠長的情況下,調度得當的較低階模型有時能追上甚至贏過較高階模型——代表搜尋策略,而不是模型規模,才是長流程 RCA 的瓶頸。
深入要點
- MegaRCA-Mix 上,Continual Search 把 GPT-5.5 的 F1 從 0.349 拉高到 0.498,增幅超過 40%,對照組 Passive Continuation 只到 0.401
- 在另一個長流程 benchmark TRAIL 上,四輪之後把 GPT-5.5 的 Weighted F1 從 0.426 拉到 0.500,Passive Continuation 只到 0.451
- 同一組四輪裡,Continual Search 讀到的去重證據從 42K 成長到 58K token,Passive Continuation 卻只長到 48K——多出來的增益直接對應到判官真的讀了更多沒看過的證據 ⚠️(作者自測,MegaRCA-Mix 是本篇作者自建的新 benchmark,尚無外部團隊複現)
- 在既有的短流程 benchmark(AgentRx、Who&When)上,額外的搜尋輪次不但沒有幫助,反而讓判官在證據已經讀得差不多的情況下,被迫重新檢視答案,把原本正確的判斷翻案成錯誤
- 落地門檻:方法本身不需要重新訓練模型,是 prompt 層級的多輪搜尋策略,但需要判官能存取完整的執行紀錄與工具,對只保留最終結果、沒留執行紀錄的系統無法直接套用
- Limitation:MegaRCA-Mix 只有 50 筆案例,而且是作者自己從 Harbor Index 執行紀錄裡整理標註的,論文本身也承認方法在短流程上可能適得其反,不是全面優於既有方法
Reviewer 一句話評
把根因歸因重新框成搜尋問題,在四個既有 benchmark 加上自建的長流程 benchmark 上都做了對照,並誠實報告方法在短流程上會讓判官被說服翻案的負面結果,這種邊界意識值得肯定;但核心增益集中在只有 50 筆案例、尚無外部驗證的自建 benchmark 上,「搜尋勝過模型規模」這個更大膽的結論還需要更大樣本才能站穩。
給你的 take-away
- 如果你在維運長流程、大規模的 Agent 系統:除錯判官不要只跑一次性診斷,可以參考 Continual Search 的設計,讓判官在後續輪次主動去找還沒讀過的證據,而不是只被動確認前一輪的答案
- 如果你的任務流程偏短(數十步以內):這篇論文明確提醒額外的搜尋輪次可能反而讓判官把正確答案翻案成錯誤,不要不分場景照搬這套方法
今日收穫
之前以為只要 Agent 系統的分數夠好看——評測過關、鷹架選對、除錯有交代——就代表系統值得信任。今天發現這三件事本身的量測工具全部都比想像中脆弱:LLM 評審打出的「滿意」有一半以上其實是任務失敗;換鷹架看似合理的選型決策,在乾淨的對照實驗下根本測不出穩定優勢;連「找出哪裡壞掉」這個除錯動作本身,都要靠讓判官別太早停止搜尋才做得到。真正該懷疑的不是 Agent 有沒有出錯,而是我們用來確認「它有沒有出錯」的那把尺,夠不夠準。
參考資料
- GAUGE: When Not to Trust LLM-as-a-Judge in User-Simulated Evaluation of Task-Oriented Agents
- Harness or Model? Isolating the Harness Effect in Agentic Coding with a Contamination-Controlled Private Suite
- Root-Cause Attribution Is a Search Problem: Continual Search for Long-Horizon Agent Failures
- arXiv cs.AI new submissions, Tuesday 15 September 2026(來源公告批次)
- arXiv cs.CL new submissions, Tuesday 15 September 2026(來源公告批次)
- arXiv cs.MA new submissions, Tuesday 15 September 2026(來源公告批次)
- HuggingFace Daily Papers
Loading...