模型訓練與程式碼 AI
OctoLong 以跨程式庫依賴鏈訓練長上下文模型，8B 版 RepoQA 得分升至 64.63
OctoLong 不再把單一程式庫直接串接成長文本，而是沿 AST、語言伺服器及套件相依關係遞迴收集實作。研究團隊釋出 600M 至 14B 模型，實驗顯示依賴密集資料同時改善程式碼檢索、狀態追蹤與 API 使用。
長上下文模型支援 128K token，不代表它能追蹤散落於多個套件的真正依賴。OctoLong 的做法是先挑選至少 15 顆 GitHub 星、超過五名貢獻者的 Python 專案，再於裝好相依套件的容器內結合 AST 查詢、JEDI 語言伺服器與套件管理器，從種子函式一路找回被呼叫的類別及實作。產生的 57,993 個樣本平均約 107K token，共 62 億 token；作者以 LongPPL 診斷認為，其上下文敏感關鍵 token 比一般長文本高 3 至 23 倍。
團隊把這批資料加入約 500 億 token 的長上下文中期訓練混合，占比約 12%，再進行約 100 億 token 指令微調。五款模型以 Qwen3 稠密底座建成，參數量由 600M 至 14B，透過調高 RoPE base frequency 將上下文從 32K 延伸至 128K；為減少短輸入能力退化，還把原始與中期訓練檢查點按 1:9 線性合併。
在作者統一設定下，OctoLong-8B 的 LooGLE V2 Code、LongCodeQA 與 RepoQA 平均分別為 29.76、65.01、64.63；移除跨程式庫資料後降為 26.38、62.17、61.58。14B 版在三項測試則達 39.88、77.98、76.01。不過這不是全面勝出：4B 版在一般長文本測試落後同底座 Qwen3-4B，14B 的 AA-LCR 也低於 Qwen2.5-14B-1M。資料只涵蓋英文與 Python，128K 以上及 ABI、FFI 跨語言呼叫尚未驗證；工程團隊下一步應關注訓練資料與管線是否完整公開，以及在真實單體倉庫、私有套件和多語言建置系統上的重現結果。