OctoLong 用跨倉庫程式脈絡訓練長上下文模型

寫程式時最常卡住的，不是看不懂單一檔案，而是線索散在另一個 repo、另一個 package，甚至另一層引用裡。一般長上下文模型能吃很多 token，卻不一定真的會追依賴。

OctoLong 用跨倉庫、依賴密集的程式脈絡做中期訓練，讓長上下文模型更會追引用、抓狀態，也更能處理 repo 級任務。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：~6.2B OctoLong tokens，納入約 50B-token mixture
• 突破點：遞迴式程式引用檢索

OctoLong: Mid-Training On Cross-Repository Code Contexts Enhances Long-Context Modeling 走的就是這條路。它不是單純把上下文拉長，而是想辦法讓訓練資料本身更像真實大型程式系統。

它要解的痛點是什麼

這篇論文鎖定的是長上下文模型的資料問題。現在很多模型都能處理更長的輸入，但長上下文語料常常偏向書籍、論文，或是結構比較有限的程式片段。這些資料可以訓練模型「看很多字」，卻不一定會逼模型學會跨檔案、跨 package、跨 repository 追依賴。

對開發者來說，這個差異很實際。很多 coding 任務不是找一段文字，而是找一串關聯：某個 symbol 的定義在哪、這個 API 怎麼被呼叫、另一個 repo 裡的相依套件怎麼影響結果。若訓練資料沒有這種長距離依賴，模型即使上下文窗很大，也可能還是抓不到重點。

OctoLong 的核心想法，就是不要只餵一般長文本，而是製造「依賴關係很重」的 code context。摘要提到，這類 context 最長可以到百萬 token 等級，這跟一般 snippet 或單一 repo 快照不是同一種訓練訊號。

OctoLong 怎麼做

作者把 OctoLong 描述成一個 context engineering pipeline。它串了三個元件：AST parser、language server backend，還有 package manager。三者一起工作，做的是遞迴式引用檢索。

白話說，就是從一段程式碼出發，持續把它依賴到的東西找回來。包含定義、被引用的 symbol、相關檔案、以及 package 層級的脈絡。最後拼出來的，不只是更多 code，而是和真實軟體系統一樣有連結關係的 code。

這也是這篇最重要的技術點。它沒有在摘要裡主打新的 tokenizer，也沒有主打新的 attention 架構。它是在改訓練資料的形狀，讓模型在 mid-training 階段看到更多跨倉庫、依賴密集的結構。

接著，這些資料被用來訓練 OctoLong-Instruct，一組 open long-context language models。摘要提到，這些 base models 的規模從 600M 到 14B 參數不等。訓練分兩階段：先做 context-extension mid-training，資料混合量約 50B tokens，其中約 6.2B tokens 來自 OctoLong code contexts；再做約 10B tokens 的 instruction tuning。

它實際證明了什麼

這篇摘要有規模數字，但沒有公開完整 benchmark 細節。換句話說，如果你想直接看到 leaderboard 式的分數，摘要本身沒有列出來。

不過，摘要還是給了幾個明確訊號。作者說，他們把 OctoLong 的資料拿去做 ablation 和 evaluation，對比了 18 個最先進的 open-weight long-context LMs。結果顯示，只要把傳統 context-extension corpora 裡的 12% 換成 OctoLong 資料，就能在多個任務上帶來明顯提升。

這些任務包括 long-range retrieval、long-term state tracking、repository-level code understanding，還有 downstream agentic tasks。摘要還特別提到，OctoLong 也能改善短上下文 coding 場景中的 API usage。這點很值得注意，因為代表它的收益不只出現在超長 prompt，也可能反映到一般程式使用習慣上。

從研究角度看，這個結果支持一個很實際的判斷：長上下文模型的能力，不只是「能裝多少 token」，而是「訓練時看過什麼樣的依賴關係」。如果資料本身更像真實 repo，模型就更容易學會追引用、保狀態、抓結構。

對開發者的意義

如果你在做 coding assistant、repo agent，或任何要讀大型 codebase 的工具，這篇論文給的訊號很直接：長上下文的品質，關鍵在資料，不只在窗口大小。模型若看過更多依賴密集的 code context，就更有機會跨檔案追線索，也更會用 API。

這對 agentic workflow 特別重要。因為 agent 在工作時，往往不是一次性回答，而是要規劃、檢查、修改、再延續。這種流程最常見的失敗，不是完全沒上下文，而是中途丟掉 repository 裡的關聯。

從訓練策略來看，這篇也提供一個相對務實的方向。摘要指出，只要用 OctoLong 資料替換 12% 的傳統 context-extension corpora，就能看到提升。若這個結果能在更多場景重現，代表你未必需要整個重做長上下文資料管線，才有機會改善 repo 理解。

但它也不是萬靈丹。這套 pipeline 依賴 AST parsing、language server 整合與 package management，代表它很強，但也很專門。這不是隨手抓網頁文本就能複製的資料集，而是高度整理過的工程管線。

還有哪些限制要看清楚

摘要沒有把完整 benchmark 數字公開，所以外界還不能只靠這份摘要判斷提升幅度有多大。它也沒有交代約 50B-token mixture 裡，除了 OctoLong 之外的資料組成細節。

另一個限制是泛化範圍。這篇明確談的是 code contexts，證據也集中在程式理解、檢索、狀態追蹤與 agentic tasks。摘要沒有主張這種做法能直接解決所有領域的長上下文推理。

不過就工程實務來看，這篇的訊息已經很清楚。若你想讓模型更會處理大型 repository，訓練資料就要更像大型 repository。OctoLong 做的事，是把這種依賴結構顯式化，然後在 scale 上拿來訓練。

結論

OctoLong 是一篇很資料導向的長上下文研究。它證明了一件事：把跨倉庫、依賴密集的程式脈絡放進中期訓練，長上下文模型就更能處理 repo 級任務。

對開發者來說，這代表模型不只是多吃一些 token，而是更有機會真的跟上程式碼之間的關聯，像個能追脈絡的助手，而不是只會背上下文長度的工具。