Hugging Face 用 Codex + 開源 OCR + Jobs 處理 3 萬篇論文：真正有價值的不是 OCR 本身，而是把『論文可聊天化』做成一條可批量執行的產線

這篇來源雖然是 Threads 轉貼 Hugging Face 文章，但真正值得整理的是文章本身：Hugging Face 為了讓更多論文支援「chat with paper」，用 Codex、開源 OCR 模型 Chandra-OCR 2，以及 Hugging Face Jobs，批量處理了約 3 萬篇論文。

這件事的價值，不只是 OCR 多大規模，而是它把一條很典型的 AI 內容基礎設施流程走完了。

1. 問題定義非常清楚：不是為了 OCR，而是為了讓 paper 可以被 chat

Hugging Face 原本在 paper page 上提供 HuggingChat integration，但前提是 arXiv 論文要有可轉成 Markdown 的 HTML 頁面。

問題是：

大量論文沒有對應 HTML，因此沒辦法直接 chat。

所以真正的目標不是「做 OCR」，而是：

讓更多論文變成可被 LLM 消化的結構化文本。

OCR 只是達成這件事的中間步驟。

2. 流程設計很值得學：benchmark → model → infra → agent

他們的做法有一條很清楚的決策鏈：

• 先用 OlmOCRBench 看當下開源 OCR 模型 leaderboard
• 選擇表現最好的 Chandra-OCR 2
• 用 Hugging Face Jobs 當 serverless GPU 執行層
• 再直接讓 Codex 根據文件與 skill 幫忙寫大規模跑批腳本

這個流程很有代表性，因為它不只是「選一個模型來跑」，而是把：

• 評估
• 模型選型
• 執行基礎設施
• 代理式程式生成

串成一個完整工作流。

3. 真正值得注意的是：agent 已經開始接手一次性 infra glue work

文中最有時代感的一句話其實是：

既然現在是 2026，就直接把文件、模型卡、CLI skill 丟給 Codex，讓它自己把腳本寫出來。

這個訊號比 OCR 本身更大。

因為它代表一種工作模式正在成熟：

人類不一定親手寫 glue code，而是負責定義任務、給對文件、給對約束，然後讓 coding agent 自己把批量任務兜起來。

我的判斷

這篇最值得保留的觀察是：

Hugging Face 這次做的不只是 OCR 3 萬篇論文，而是示範了一條「把內容轉成 LLM 可聊天形式」的批量產線：用 benchmark 選模型、用 serverless GPU 跑大規模任務、再用 coding agent 補齊實作 glue。真正的價值在產線，而不只是 OCR。

原始來源： Threads：https://www.threads.com/@oneday0013/post/DXODCFlkyuS?xmt=AQF0gc-3KwjEjDCTQ5tedvclZe_99CpCfbqtXHaQQHdwG5tFzgkJ8TSc0YzLWg6UYUvEh_jH&slof=1 文章：https://huggingface.co/blog/nielsr/ocr-papers-jobs