這項由JetBrains Research的Maksim Sapronov和Evgeniy Glukhov開展的研究發表于2025年ICLR會議（國際學習表征會議），論文編號為arXiv:2510.13697v1。對于那些想要深入了解技術細節的讀者，可以通過這個編號查詢完整論文。

在現代軟件開發中，程序員們越來越依賴AI來幫助編寫代碼。這就像是有一個非常聰明的助手，能夠理解你正在寫的程序，并在合適的時候提出建議，告訴你下一行應該寫什么。然而，讓AI真正理解一個完整的軟件項目就像讓一個人理解一部復雜的小說一樣——不僅要看懂當前這一頁的內容，還要記住前面所有章節的情節發展。

在編程世界里，大部分AI模型就像只看了小說其中一頁的讀者，它們只能理解單個文件的代碼，卻無法把握整個項目的全貌。這種局限性就好比一個廚師只看到了食譜的一部分，雖然知道如何切菜，卻不清楚最終要做成什么菜。為了解決這個問題，研究人員開始訓練AI模型來理解整個代碼倉庫（repository），讓它們能夠像經驗豐富的項目經理一樣，對整個軟件項目的結構和邏輯了如指掌。

然而，這種"倉庫級訓練"面臨著巨大的挑戰。首先，它需要海量的數據——一些最先進的模型需要3000億個文本單元（token）的訓練數據，這相當于幾百萬本書的文字量。其次，處理這么多信息需要巨大的計算資源，就像試圖同時記住一整個圖書館的內容一樣困難。這讓許多研究團隊和公司望而卻步，因為不是每個人都有Google或微軟那樣的資源。

JetBrains Research的這項研究帶來了一個令人振奮的發現：要讓AI理解項目級代碼，其實并不需要那么多數據和復雜的方法。研究團隊以OpenCoder這個15億參數的模型為起點，通過巧妙的訓練策略，僅用10億個token的精心篩選數據，就讓模型的項目級代碼補全能力達到了與那些使用數千億token訓練的頂級模型相當的水平。

更有趣的是，研究團隊發現了一個顛覆常識的結論：在訓練過程中如何組織和排列代碼文件，對最終效果的影響微乎其微。這就像發現烹飪一道美味佳肴時，食材的擺放順序遠沒有火候控制重要。真正的關鍵在于一個看似技術性的調整——修改模型的位置編碼參數（RoPE scaling parameter），這個調整讓模型能夠處理更長的上下文信息。

一、研究背景：為什么項目級代碼理解如此重要

在軟件開發的世界里，代碼就像建筑圖紙一樣復雜。一個現代軟件項目可能包含成千上萬個文件，每個文件都像拼圖的一片，只有放在正確的位置才能構成完整的圖案。傳統的AI代碼助手就像只看到一片拼圖就要猜測整幅圖案的人，雖然能做出一些有用的建議，但往往缺乏對全局的把握。

當程序員在寫代碼時，他們經常需要調用其他文件中定義的函數或變量。這種跨文件的依賴關系就像一張復雜的人際關系網，每個人都與其他人有著千絲萬縷的聯系。如果AI助手不理解這些關系，就像一個不了解公司組織架構的新員工，雖然能完成一些簡單任務，但在需要協調配合的復雜工作上就會力不從心。

為了解決這個問題，研究人員開始探索"倉庫級預訓練"的方法。這種方法讓AI模型在學習過程中接觸到完整的代碼項目，而不僅僅是零散的代碼片段。這就像讓一個學徒不僅學習如何使用單個工具，還要了解整個工作坊的運作方式。通過這種訓練，模型可以學會理解代碼文件之間的關系，掌握項目的整體架構。

然而，這種訓練方法帶來了新的挑戰。最大的問題是數據需求量的急劇增加。一些最先進的模型，如Qwen2.5 Coder，需要大約3000億個token的倉庫級數據進行訓練。這個數字聽起來可能比較抽象，但可以這樣理解：如果把這些數據打印出來，需要的紙張可能比一座摩天大樓還要高。

除了數據量的挑戰，計算資源的需求也呈指數級增長。處理長序列的計算復雜度隨著序列長度的平方增長，這意味著處理兩倍長的序列需要四倍的計算資源。這就像試圖同時記住越來越多的信息，大腦的負擔會急劇增加。

面對這些挑戰，許多研究團隊開始探索更高效的方法。有些團隊開發了新的注意力機制，如Flash Attention和Ring Attention，這些技術就像更高效的記憶方法，能夠幫助模型更好地處理長序列。但即使有了這些改進，如何有效利用倉庫級信息仍然是一個懸而未決的問題。

在這個背景下，JetBrains Research的團隊決定深入研究一個具體但重要的問題：在項目級代碼補全任務中，不同的數據處理策略會產生怎樣的影響。他們選擇了Long Code Arena基準測試中的單行代碼補全任務，這個任務要求模型根據當前文件的內容和整個項目的上下文，預測程序員接下來要寫的那一行代碼。

二、研究方法：巧妙的實驗設計

研究團隊采用了一種類似對比實驗的方法來探索這個問題。他們選擇了OpenCoder 1.5B作為基礎模型，這個模型最初設計用來處理4096個token的上下文長度。可以把這個長度想象成一本中等厚度書籍的篇幅——對于理解單個文件來說足夠了，但要理解整個項目就顯得有些局促。

為了讓模型能夠處理更長的上下文，研究團隊將其上下文窗口擴展到16384個token，這相當于把模型的"記憶容量"增加了四倍。這種擴展就像給一個人增加更大的工作臺面，讓他能夠同時攤開更多的資料進行工作。

在數據準備方面，研究團隊采用了與Long Code Arena基準測試相同的方法。他們從GitHub上收集了開源的Python項目，然后遍歷這些項目的Git提交歷史來提取訓練數據。這個過程就像考古學家挖掘遺址一樣，通過分析每次代碼變更來理解項目的演化過程。

最終的數據集包含了1640個倉庫、160801次提交和361052個待補全的文件。這些數字看起來可能很抽象，但可以這樣理解：這相當于分析了數千個不同規模的軟件項目，涵蓋了各種編程風格和應用場景。

研究的核心創新在于對"上下文組合器"（context composer）的系統性研究。上下文組合器就像一個智能的文件管理員，它的任務是從項目的所有文件中選擇最相關的內容，然后按照某種邏輯順序排列，為模型提供最有用的上下文信息。

研究團隊設計了多種不同的上下文組合器策略。最簡單的是"文件級"策略，它根本不提供任何項目上下文，就像讓一個人在完全不了解背景的情況下續寫故事。另一個重要的策略是"路徑距離"策略，它根據文件之間的路徑相似性來排序，優先選擇與當前文件在目錄結構上最接近的文件。

這種方法的邏輯很直觀：通常情況下，位于相同目錄或相近目錄的文件在功能上更相關。這就像在圖書館里，同一書架上的書通常屬于相同的主題分類。除了路徑距離，這個策略還使用了"交并比"（IoU）作為輔助排序標準，通過計算文件之間共同代碼行的比例來評估相關性。

為了確保訓練過程的有效性，研究團隊采用了特殊的截斷策略。他們確保上下文與待補全內容的token比例至少為3:1，這樣模型就能獲得足夠豐富的上下文信息來進行準確的預測。這種比例設計就像在做菜時保證配菜與主菜的合理搭配，既不能讓配菜搶奪主菜的風頭，也不能讓主菜顯得過于單調。

在模型訓練方面，研究團隊做了一個關鍵的技術調整：將RoPE（旋轉位置編碼）的基礎頻率從10000調整到500000。這個調整聽起來很技術性，但可以這樣理解：這就像調整收音機的頻率來接收更遠距離的電臺信號。通過這種調整，模型能夠更好地理解長序列中不同位置的信息。

整個訓練過程使用了大約10億個token的數據，這個數量雖然看起來很大，但相比那些使用數千億token的模型來說，已經相當節約了。研究團隊在第512個優化步驟保存模型權重作為檢查點，這相當于在訓練過程中設立一個里程碑來評估進展。

三、關鍵發現：顛覆傳統認知的結果

當研究團隊分析實驗結果時，他們發現了一些令人驚訝的模式。首先，在與現有最先進模型的對比中，他們的方法展現出了令人印象深刻的性能。盡管只使用了相對較少的訓練數據，他們的模型在Long Code Arena基準測試上達到了與DeepSeek Coder 1.3B和Qwen2.5-Coder等模型相當的性能水平。

這個結果就像發現了一個神奇的烹飪秘訣：不需要昂貴的食材和復雜的工藝，也能做出米其林星級的美味。在具體的性能指標上，他們的模型在"inproject"類別（需要使用項目內其他文件信息的代碼補全）上獲得了48.8分（滿分100分），在"infile"類別（只需要當前文件信息的代碼補全）上獲得了47.6分。

更令人驚訝的是第二個發現：不同上下文組合器策略對最終性能的影響遠比預期的要小。研究團隊測試了多種不同的組織策略，包括基于路徑距離的排序、基于內容相似性的排序、隨機排序等等。結果顯示，這些策略的性能差異只有3.6分（45.2分到48.8分之間），這個差異在統計學上并不顯著。

這個發現就像發現在烹飪某道菜時，香料的添加順序對最終味道的影響遠沒有火候控制重要。無論是精心設計的智能排序策略，還是簡單的隨機排列，最終的效果竟然相差無幾。這個結果挑戰了許多研究人員的直覺，也讓人重新思考什么才是倉庫級代碼理解的核心要素。

通過進一步的分析，研究團隊發現了真正的關鍵因素：RoPE參數的調整。當他們比較使用原始RoPE參數（基礎頻率10000）和調整后參數（基礎頻率500000）的模型時，發現后者在長上下文任務上的性能有了質的飛躍。原始模型在處理16K token長度的上下文時完全失效（得分接近0），而調整后的模型即使只進行文件級訓練，也能獲得45.2分的成績。

這個發現揭示了一個重要的洞察：讓模型學會處理長上下文的關鍵不在于復雜的數據組織策略，而在于調整模型的基礎架構使其能夠理解位置信息。這就像發現要讓一個人記住更多信息，關鍵不在于記憶內容的排列方式，而在于提升大腦的記憶容量。

研究團隊還發現了另一個有趣的現象：即使使用最簡單的文件級訓練（不提供任何項目上下文），模型在評估時仍然能夠有效利用項目級上下文信息。這種現象被稱為"倉庫上下文提升"（repository-context boost），文件級訓練的模型獲得了19.3分的提升，而最佳策略只能額外提供3.5分的改進。

這個結果表明，模型的上下文理解能力很大程度上是一種泛化能力，而不是通過特定訓練策略獲得的專門技能。這就像一個受過良好教育的人，即使在陌生的環境中也能快速理解和適應，因為關鍵能力在于學習能力本身，而不是對特定環境的熟悉程度。

四、深入分析：為什么簡單的方法如此有效

為了更深入地理解這些發現，研究團隊進行了廣泛的補充實驗。他們測試了總共11種不同的上下文組合器策略，涵蓋了從完全隨機到高度優化的各種方法。這些策略包括基于代碼相似性的排序、只保留函數聲明的過濾、移除注釋和文檔的精簡等等。

令人驚訝的是，即使是一些看似不合理的策略也取得了不錯的效果。例如，"反向排序"策略（故意將最不相關的文件放在前面）仍然能夠提供顯著的性能提升。這個現象就像發現即使用錯誤的地圖，只要有足夠的導航能力，仍然能找到目的地。

這些結果指向了一個重要的結論：模型的長上下文理解能力主要來自于其架構調整，而不是訓練數據的精心組織。具體來說，RoPE參數的調整使模型能夠正確理解長序列中不同位置的信息，這是利用長上下文的必要條件。一旦具備了這種能力，模型就能從各種形式的上下文信息中學習，無論這些信息是如何組織的。

研究團隊還探索了模型在不同上下文長度下的表現。他們發現，經過16K token訓練的模型能夠很好地擴展到更長的序列，甚至在32K token的上下文下仍然表現良好。這種擴展能力類似于一個人學會了騎自行車后，很快就能適應不同類型的自行車。

另一個有趣的發現涉及損失函數的選擇。在某些訓練策略中，研究團隊只對待補全的代碼部分計算損失（masked loss），而忽略上下文部分的預測誤差。但實驗表明，這種精細的調整對最終性能的影響很小，大多數情況下使用完整損失函數（full loss）的效果相當。

這個結果進一步強化了"簡單方法同樣有效"的主題。就像發現在某些烹飪過程中，過度精細的溫度控制并不會帶來顯著的味道改善，有時候最直接的方法就是最好的方法。

五、實際意義：為代碼AI研究開辟新道路

這項研究的意義遠遠超出了技術細節本身。首先，它為資源有限的研究團隊和公司提供了希望。在AI領域，特別是大規模語言模型的研究中，往往需要龐大的計算資源和數據集。這種高門檻讓許多有潛力的研究者望而卻步，就像只有富人才能參與的游戲。

然而，這項研究證明了在代碼理解這個特定領域，巧妙的方法可以彌補資源的不足。使用僅僅10億token的精心篩選數據，就能達到與使用數千億token訓練模型相當的性能，這為更多研究團隊參與這個領域提供了可能性。

其次，研究結果挑戰了該領域的一些基本假設。長期以來，研究人員認為復雜的數據預處理和精心設計的訓練策略是提升模型性能的關鍵。但這項研究表明，在某些情況下，簡單的方法可能同樣有效，甚至更加實用。這種發現促使研究社區重新審視現有的方法論。

從工程實踐的角度來看，這些發現具有重要的指導意義。軟件公司在開發代碼AI助手時，可以專注于架構層面的優化，而不必過度投入在復雜的數據工程上。這就像發現建造堅固房屋的關鍵在于地基的穩固，而不是裝飾的精美。

研究還顯示了遷移學習的強大威力。OpenCoder模型原本只能處理4K token的上下文，但通過相對簡單的調整和適量的額外訓練，就能有效處理16K token的長上下文。這種能力的快速獲得表明，許多現有的模型可能都具有被開發的潛力，只是需要正確的方法來釋放這種潛力。

對于實際的軟件開發來說，這項研究預示著更好的代碼AI助手的到來。當前的代碼補全工具雖然有用，但往往缺乏對項目全局的理解。有了項目級的上下文理解能力，未來的AI助手將能夠提供更智能、更相關的建議，就像一個真正理解項目架構的資深開發者。

六、局限性與未來方向

盡管這項研究取得了令人鼓舞的結果，研究團隊也誠實地指出了其局限性。最主要的限制是研究只在OpenCoder模型上進行了驗證，尚不清楚這些發現是否適用于其他架構的模型。這就像一個醫學發現可能在特定人群中有效，但需要更廣泛的驗證才能確認其普適性。

另一個局限是研究專注于Python編程語言和特定類型的代碼補全任務。不同編程語言有著不同的語法特點和編程范式，項目結構也可能差異很大。因此，這些發現在其他編程語言或任務上的有效性還需要進一步驗證。

研究團隊也指出，他們使用的基準測試雖然具有代表性，但仍然只是真實編程場景的一個子集。實際的軟件開發涉及更復雜的上下文理解需求，包括跨語言依賴、動態生成的代碼、第三方庫的使用等等。

盡管存在這些局限，研究為未來的發展指明了幾個有前景的方向。首先，可以將類似的方法應用到其他代碼相關任務上，如代碼修復、重構建議、安全漏洞檢測等。如果簡單的上下文擴展策略在這些任務上也同樣有效，那將進一步證實研究發現的價值。

其次，可以探索更高效的檢索策略來進一步提升性能。雖然當前研究顯示不同組織策略的差異不大，但這并不意味著不存在更好的方法。未來的研究可能會發現真正能夠顯著提升性能的上下文組織策略。

另一個有趣的方向是研究模型在更長上下文下的行為。當前研究主要關注16K token的上下文，但現代AI模型的上下文處理能力正在快速發展。理解模型在處理整個大型代碼庫時的行為模式，將為開發更強大的代碼AI提供指導。

最后，這項研究為"小而美"的AI模型發展提供了啟示。在追求更大、更強模型的同時，探索如何讓較小的模型在特定任務上達到優異性能，可能是一個更具可持續性的發展方向。

說到底，這項來自JetBrains Research的研究為我們展示了一個重要的道理：在AI研究中，有時候最簡單的方法可能就是最有效的方法。與其花費巨大資源追求復雜的解決方案，不如深入理解問題的本質，找到真正的關鍵因素。對于整個AI代碼助手領域來說，這個發現不僅節約了研發成本，也為更多研究者和開發者參與這個激動人心的領域降低了門檻。

當我們回顧這項研究時，最令人印象深刻的可能不是具體的技術細節，而是它所體現的研究哲學：保持開放的心態，質疑既有假設，用實證的方法尋找真相。在AI技術快速發展的今天，這種嚴謹而務實的研究態度顯得尤為珍貴。對于那些希望深入了解這項研究技術細節的讀者，可以通過論文編號arXiv:2510.13697v1查找完整的研究報告。

Q&A

Q1：OpenCoder模型如何在只用10億token數據的情況下達到頂級性能？

A：關鍵在于RoPE位置編碼參數的調整，將基礎頻率從10000改為500000，這讓模型能夠理解更長的上下文。研究發現，模型架構的調整比復雜的數據組織策略更重要，即使用簡單的文件級訓練也能獲得顯著的性能提升。

Q2：為什么不同的上下文組合策略效果差不多？

A：研究團隊測試了11種不同策略，發現性能差異只有3.6分。這表明模型的長上下文理解能力主要來自架構調整，而非訓練數據的精心組織。一旦模型具備了處理長序列的基礎能力，就能從各種形式的上下文中學習。

Q3：這項研究對普通程序員有什么實際意義？

A：這意味著未來的AI代碼助手將能更好地理解整個項目結構，提供更智能的代碼建議。同時，這種"用更少資源達到更好效果"的方法將讓更多公司能夠開發高質量的代碼AI工具，最終讓程序員們受益于更強大、更便宜的AI助手。