做代碼生成、倉庫級問答、長鏈路 Bug 排查時一個非常典型的瓶頸是模型在單個文件內(nèi)的局部語義理解已經(jīng)不錯一旦需要跨文件、跨模塊甚至跨倉庫組合上下文輸出質(zhì)量就明顯下滑。這個問題的根源往往不在模型結(jié)構(gòu)本身而在于訓練數(shù)據(jù)的形態(tài)以及訓練階段的安排方式。OctoLong 這個研究方向正是從這個角度切入通過 Mid-Training中期訓練在跨倉庫代碼上下文上繼續(xù)訓練讓模型的長上下文建模能力得到針對性增強。本文會圍繞這條技術路線拆解它的核心概念、數(shù)據(jù)構(gòu)建思路、訓練方法并給出可落地的工程實操示例幫助你理解并復現(xiàn)類似方案。這篇文章適合以下幾類讀者正在做代碼大模型訓練、微調(diào)和評測的算法工程師。想給已有模型增加長上下文能力的開發(fā)者和研究者。對代碼數(shù)據(jù) pipeline 感興趣想搞清楚“跨倉庫上下文”到底怎么構(gòu)造的技術人。做 Code Review 助手、倉庫級問答、項目級代碼生成的后端開發(fā)者。讀完本文你將掌握OctoLong 要解決什么問題Mid-Training 在訓練流程中的定位。跨倉庫代碼上下文的數(shù)據(jù)構(gòu)造思路。如何用常見工具鏈搭建一條可運行的長上下文訓練與評測鏈路。實際訓練中的效率問題、評測方法和避坑清單。1. 背景與核心概念1.1 長上下文建模的價值在真實軟件開發(fā)中一個功能的實現(xiàn)往往散落在多個文件和倉庫中。比如一個 Java 后端接口通常包含 Controller、Service、Mapper、Entity、配置文件、數(shù)據(jù)庫表定義而工具類或公共 SDK 可能來自另一個內(nèi)部倉庫。如果模型不能同時“看到”這些跨倉庫的代碼片段它就只能靠記憶補全準確性會受到很大影響。長上下文建模Long-Context Modeling要解決的正是這種“輸入長度超過模型默認訓練長度”時的信息利用問題。它的價值體現(xiàn)在幾個典型場景倉庫級代碼補全與生成根據(jù)整個倉庫的代碼風格、依賴關系和相似實現(xiàn)來生成新代碼。跨文件調(diào)試給出報錯信息時模型需要理解多個文件之間的調(diào)用關系。項目文檔生成從分散在多個模塊的代碼中總結(jié)出系統(tǒng)設計。代碼 Review需要同時看主倉變更、依賴 SDK 的接口定義、歷史修改記錄。這些場景都要求模型能處理幾千到幾十萬 token 的輸入并且能夠在長輸入中準確定位關鍵信息。1.2 現(xiàn)有代碼模型的短板目前很多代碼大模型包括一些知名開源模型在實際評測中仍然有幾個明顯短板。第一有效上下文遠低于宣傳窗口。很多模型宣稱支持 128K 甚至 200K 上下文但實際測試中當關鍵信息位于長文本中段時準確率會大幅下降。這在學術上常被稱為“l(fā)ost in the middle”問題。第二訓練數(shù)據(jù)以單文件為主。通用代碼預訓練語料通常來自公開倉庫的單個文件模型沒有充分見過“多個倉庫、多個文件拼成一個長序列”的樣本形態(tài)。因此即使把窗口長度撐大模型也不知道該如何利用跨文件信息。第三短上下文和長上下文能力不一致。模型可能在 8K 以內(nèi)表現(xiàn)良好但一旦超過訓練長度注意力計算、位置編碼、相對位置推斷都會出現(xiàn)退化。OctoLong 這類工作想證明的核心觀點是通過 Mid-Training專門用結(jié)構(gòu)化的跨倉庫代碼上下文去訓練模型可以顯著改善上述短板而且不需要重新做完整預訓練。1.3 OctoLong 的核心思路從標題可以看出OctoLong 的關鍵詞是三個Mid-Training中期訓練介于預訓練和指令微調(diào)之間的一個訓練階段。Cross-Repository Code Contexts跨倉庫代碼上下文。Long-Context Modeling長上下文建模。把三者串起來OctoLong 的做法可以理解為在基礎模型已經(jīng)具備一定代碼能力的條件下構(gòu)建專門的數(shù)據(jù)集這些數(shù)據(jù)不是簡單從單個文件里截取而是按照倉庫依賴、符號引用、模塊調(diào)用等關系把多個倉庫中相關的代碼片段組合成超長訓練樣本。然后在這個數(shù)據(jù)上繼續(xù)訓練讓模型學會在長跨度上關聯(lián)信息。這種做法的本質(zhì)是把“長上下文能力”當成一個可以定向增強的技能而不是天然從預訓練中長出來的能力。2. Mid-Training一個被低估的訓練階段2.1 從預訓練到微調(diào)訓練流程的四階段當前大語言模型的主流訓練流程可以分成四個階段階段目標數(shù)據(jù)特點典型成本預訓練學習通用語言與知識海量、低質(zhì)量、無標注極高Mid-Training / 繼續(xù)預訓練強化某一領域能力領域語料、中等規(guī)模中高指令微調(diào)學會遵循指令高質(zhì)量指令數(shù)據(jù)低對齊RLHF/DPO符合偏好與安全要求偏好數(shù)據(jù)低Mid-Training 在很多開源模型里也被叫做 “domain-adaptive continued pretraining” 或“二次預訓練”。它的位置正好在預訓練和指令微調(diào)之間。2.2 Mid-Training 的定位與作用Mid-Training 要解決的問題是基礎模型在通用語料上學習了大量知識但這些知識在特定領域的組織方式、術語體系和推理模式與通用場景差異很大。直接在通用模型上做指令微調(diào)效果往往有限因為模型根本沒有見過足夠多的領域長文本結(jié)構(gòu)。舉個例子。一個模型可能理解“函數(shù)”“調(diào)用”“異常”這些詞但它不一定見過“某個項目的 service 層大量依賴另一個倉庫的 common 模塊且異常類型要統(tǒng)一處理”這種真實的跨倉庫代碼模式。通過 Mid-Training模型先把這種模式學進來之后再做指令微調(diào)任務表現(xiàn)會穩(wěn)定很多。OctoLong 選擇在代碼領域做 Mid-Training而且專門使用跨倉庫上下文數(shù)據(jù)。這樣做有兩個好處訓練數(shù)據(jù)與推理場景一致推理時需要長輸入訓練時也喂給模型長輸入。強化信息關聯(lián)能力模型學會在長文本中維護多文件引用關系而不是只做局部建模。2.3 為什么代碼場景特別適合 Mid-Training代碼和自然語言有一個非常大的區(qū)別代碼有嚴格的結(jié)構(gòu)和明確的引用關系。一個函數(shù)是另一個文件里定義的這個關系是可以從語法分析、依賴圖中精確抽取出來的。因此代碼領域可以“主動構(gòu)造”出高質(zhì)量的長上下文訓練樣本而不是簡單地把隨機文本拼接在一起。自然語言領域也要做長上下文增強比如拼接多篇文檔但段落之間的邏輯關系往往較弱。代碼不同跨文件調(diào)用是強邏輯關系。模型如果能學到這種關系長上下文能力會有質(zhì)的提升。所以OctoLong 選擇代碼場景實踐 Mid-Training不只是因為代碼數(shù)據(jù)好獲取更重要的是代碼本身提供了“可驗證的上下文關聯(lián)信號”。3. 跨倉庫代碼上下文數(shù)據(jù)與建模思想3.1 從單文件到跨倉庫數(shù)據(jù)形態(tài)的跨越大多數(shù)代碼預訓練語料處理流程是這樣的把每個文件看成一個獨立文本切分成 token 序列加入訓練。這種處理方式忽略了三個層面文件內(nèi)函數(shù)之間的調(diào)用關系。同一倉庫內(nèi)文件之間的 import 關系。不同倉庫之間通過依賴管理工具建立的引用關系。跨倉庫代碼上下文就是把第三個層面納入訓練樣本。一個典型的訓練樣本可能長這樣[倉庫A] /payment-service/src/main/java/com/example/PaymentController.java [倉庫B] /common-lib/src/main/java/com/example/Result.java [倉庫B] /common-lib/src/main/java/com/example/ResultCode.java [倉庫A] /payment-service/src/main/java/com/example/PaymentService.java這些文件并不是隨機拼接而是因為PaymentController調(diào)用了PaymentService且返回類型使用了Result所以在同一個上下文窗口中出現(xiàn)。3.2 跨倉庫依賴的構(gòu)建方式要構(gòu)建這種樣本核心是構(gòu)建“代碼依賴圖”。步驟可以拆解如下克隆或拉取目標倉庫集合。解析每個文件的 import / require / include 語句。解析符號定義和使用關系函數(shù)定義、類定義、函數(shù)調(diào)用、類型引用。建立文件到文件的引用邊。建立倉庫到倉庫的依賴邊通過包名、模塊名、命名空間。做反向依賴查詢找出“誰用了誰”。這一套邏輯在 GitHub 上有很多現(xiàn)成工具支持比如 tree-sitter 可以做語言級語法解析部分語言可以通過編譯數(shù)據(jù)庫拿到更精確的依賴。3.3 上下文打包策略得到依賴關系后還需要把相關文件組裝成訓練樣本。這里有兩個關鍵設計點樣本長度分布和樣本格式。在樣本長度上建議按混合比例構(gòu)建讓模型同時見到不同長度的樣本。比如一部分樣本控制在 4K 到 8K一部分在 8K 到 32K還有一部分超過 32K。這樣模型既不會丟失短文本能力又能逐步適應長序列。在樣本格式上需要設計清晰的文件邊界標記。一種常見做法是使用特殊 token 標記文件路徑和文件內(nèi)容。下面是一個簡化的樣本格式示例repo namepayment-service file pathPaymentController.java ...代碼... /file /repo repo namecommon-lib file pathResult.java ...代碼... /file /repo這樣的格式可以讓模型在長上下文中區(qū)分出“哪個倉庫、哪個文件、哪段代碼”避免文件邊界混亂。4. 環(huán)境準備與工具鏈4.1 環(huán)境要求實際的 OctoLong 訓練規(guī)模取決于基座模型大小和 GPU 資源。本文以復現(xiàn)實驗和學習驗證為目的以 7B 到 13B 級別的代碼模型為例推薦環(huán)境如下操作系統(tǒng)LinuxUbuntu 20.04 或 22.04GPU至少 4 張 24GB 顯存顯卡如 RTX 3090 / 4090 / A10G建議使用 A100 或 H800CPU16 核以上內(nèi)存64GB 以上磁盤至少 200GB 剩余空間用于存放模型權(quán)重和數(shù)據(jù)集需要強調(diào)的是具體資源要結(jié)合模型大小、序列長度和訓練策略調(diào)整。如果只是跑通驗證流程也可以使用更小的 1B 級模型和小規(guī)模語料。4.2 工具清單本文的實戰(zhàn)環(huán)節(jié)會用到以下工具它們都是當前生態(tài)中比較通用的選擇Python 3.10PyTorch 2.xTransformersDatasetsAcceleratePEFT用于 LoRA 訓練tree-sitter用于代碼解析networkx用于依賴圖構(gòu)建vllm用于推理加速可選版本需要根據(jù)你的項目實際情況調(diào)整本文示例以常見環(huán)境為例重點演示配置思路。4.3 示例項目結(jié)構(gòu)建議按下面的結(jié)構(gòu)組織項目octolong-lab/ ├── configs/ │ └── train.yaml ├── data/ │ └── raw_repos/ # 存放克隆的倉庫 │ └── processed/ # 存放構(gòu)建好的訓練樣本 ├── scripts/ │ ├── build_dependency.py │ ├── build_context.py │ └── train_lora.py ├── src/ │ └── octolong/ │ ├── dependency_graph.py │ └── sample_builder.py └── output/ └── checkpoints/這樣一個結(jié)構(gòu)可以支持從數(shù)據(jù)構(gòu)建到模型訓練的全流程便于后續(xù)擴展。5. 實戰(zhàn)構(gòu)建跨倉庫訓練樣本5.1 解析倉庫結(jié)構(gòu)我們先用 tree-sitter 做 Python 代碼的 import 解析。這個步驟的目標是從每個源碼文件中提取出它導入了哪些模塊。下面是一個最小示例代碼路徑為scripts/build_dependency.pyimport os import glob from tree_sitter import Language, Parser # 這里假設你已經(jīng)編譯好了 python.so 語言文件 PY_LANGUAGE Language(build/python.so, python) parser Parser(PY_LANGUAGE) def extract_imports(file_path): with open(file_path, r, encodingutf-8, errorsignore) as f: source f.read().encode(utf-8) tree parser.parse(source) imports [] def walk(node): if node.type import_statement: # 拿到 import 后面的模塊名 text node.text.decode(utf-8) imports.append(text) elif node.type import_from_statement: text node.text.decode(utf-8) imports.append(text) for child in node.children: walk(child) walk(tree.root_node) return imports def scan_repository(repo_root): all_imports {} for file_path in glob.glob(os.path.join(repo_root, **, *.py), recursiveTrue): rel_path os.path.relpath(file_path, repo_root) try: imports extract_imports(file_path) all_imports[rel_path] imports except Exception as e: print(f解析失敗: {file_path}, 錯誤: {e}) return all_imports if __name__ __main__: repo data/raw_repos/example_project result scan_repository(repo) for file, imports in result.items(): print(file, -, imports)這段代碼演示了最基礎的 import 提取。實際使用中還需要對相對導入、別名導入做歸一化處理并且對 Java、TypeScript、Go 等語言分別配置 tree-sitter 語法。5.2 提取依賴關系得到所有文件的 import 之后下一步是把這些 import 映射到具體文件建立“文件到文件”的依賴圖。import networkx as nx import os def build_dependency_graph(repo_root, import_map): graph nx.DiGraph() # 先把所有文件作為節(jié)點加入 for rel_path in import_map.keys(): graph.add_node(rel_path) # 建立模塊名到文件路徑的映射 module_to_file {} for rel_path in import_map.keys(): module_name rel_path.replace(os.sep, .).replace(.py, ) module_to_file[module_name] rel_path # 解析 import 關系 for rel_path, imports in import_map.items(): for imp in imports: # 簡單提取 import 后的第一個模塊名 # 真實場景需要處理 from x import y, import x.y.z 等情況 for candidate, target_file in module_to_file.items(): if candidate in imp and candidate ! rel_path.replace(os.sep, .).replace(.py, ): graph.add_edge(rel_path, target_file, typeimport) return graph # 使用示例 # graph build_dependency_graph(data/raw_repos/example_project, import_map) # print(nx.info(graph))這個階段的產(chǎn)出是一個有向圖節(jié)點是文件邊是依賴關系。之后可以在圖上做 BFS 或 DFS找出與某個文件強相關的文件集合。5.3 組裝跨倉庫上下文樣本假設我們需要為PaymentService.java構(gòu)造一個訓練樣本可以按照依賴關系找到它依賴的公共類文件再按順序拼接到一起。這里給出一個簡化版樣本構(gòu)建腳本的核心邏輯路徑為scripts/build_context.pydef build_training_sample(anchor_file, graph, repo_roots): anchor_file: 主文件路徑 graph: networkx 依賴圖 repo_roots: 倉庫根路徑到文件路徑的映射 # 使用 BFS 找與 anchor_file 相關的文件限制遍歷深度為 2 related_files [] for depth, nodes in enumerate(nx.bfs_layers(graph, anchor_file)): if depth 2: break related_files.extend(nodes) # 組裝上下文 sample_parts [] for file_path in related_files: repo_name get_repo_name(file_path, repo_roots) rel_path get_rel_path_in_repo(file_path, repo_roots) with open(file_path, r, encodingutf-8, errorsignore) as f: code f.read() sample_parts.append(frepo name\{repo_name}\\n) sample_parts.append(ffile path\{rel_path}\\n) sample_parts.append(code) sample_parts.append(\n/file\n/repo\n) return .join(sample_parts)這里需要注意BFS 遍歷深度需要控制否則樣本會過大。最終樣本長度需要通過 tokenizer 做截斷或拼接控制在目標上下文窗口內(nèi)。需要做樣本去重避免模型在訓練集和評測集之間發(fā)生數(shù)據(jù)泄漏。6. 實戰(zhàn)Long-Context 模型訓練6.1 模型與長度擴展選擇對于已有的開源代碼模型直接做長上下文訓練通常需要解決位置編碼問題。常見處理方式有兩種如果模型本身支持 RoPE可以通過調(diào)整 RoPE 的 base 頻率來擴展窗口例如把 base 從 10000 改成 500000 或 1000000。如果模型支持 ALiBi 或相對位置編碼本身對長度外推比較友好擴展成本更低。在 Transformers 中加載模型時可以通過rope_scaling參數(shù)做長度擴展。下面是一個基于 Llama 架構(gòu)的示例from transformers import AutoModelForCausalLM, AutoTokenizer model_path your-code-model-path tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypeauto, device_mapauto, rope_scaling{type: linear, factor: 2.0}, )這里把 RoPE 的縮放因子設為 2.0可以支持大約 2 倍于原始窗口的長度。實際生產(chǎn)環(huán)境建議對縮放方式做實驗對比。6.2 LoRA 訓練腳本Mid-Training 如果從頭訓練全部參數(shù)成本非常高。更常見的是先用 LoRA 或 QLoRA 做參數(shù)高效微調(diào)驗證數(shù)據(jù)效果。下面給出一個可運行的訓練腳本核心片段路徑為scripts/train_lora.pyfrom transformers import ( AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer, DataCollatorForSeq2Seq, ) from datasets import load_dataset from peft import LoraConfig, get_peft_model model_path your-code-model-path data_path data/processed/train.jsonl model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypebfloat16, device_mapauto, rope_scaling{type: linear, factor: 2.0}, ) tokenizer AutoTokenizer.from_pretrained(model_path) tokenizer.pad_token tokenizer.eos_token # LoRA 配置 lora_config LoraConfig( r32, lora_alpha64, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) def preprocess_function(examples): texts examples[text] model_inputs tokenizer( texts, max_length32768, truncationTrue, paddingFalse, return_tensorsNone, ) model_inputs[labels] model_inputs[input_ids].copy() return model_inputs dataset load_dataset(json, data_filesdata_path, splittrain) tokenized_dataset dataset.map(preprocess_function, batchedTrue, remove_columnsdataset.column_names) training_args TrainingArguments( output_diroutput/checkpoints, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate2e-4, warmup_steps100, logging_steps10, save_steps500, num_train_epochs1, bf16True, gradient_checkpointingTrue, optimadamw_torch, ) trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_dataset, data_collatorDataCollatorForSeq2Seq(tokenizer, paddingTrue), ) trainer.train()這段代碼有幾個關鍵點max_length32768是訓練時的目標序列長度需要根據(jù)顯存調(diào)整。gradient_checkpointingTrue能顯著降低顯存占用但會帶來一點訓練速度損失。per_device_train_batch_size1長序列訓練下通常只能做到這種級別要靠梯度累積來模擬大的 batch size。LoRA 的target_modules需要根據(jù)模型架構(gòu)調(diào)整不同模型名稱可能不同。6.3 訓練時的效率與穩(wěn)定性長序列訓練最直接的挑戰(zhàn)是顯存。即使 batch size 為 132K 長度、7B 模型的激活值也可能超過單卡 40GB。這里有幾個工程手段使用 FlashAttention-2 替代標準 attention顯存占用和速度都會有明顯改善。使用序列打包sequence packing把多個短樣本拼成一個長序列減少 padding 浪費。使用 DeepSpeed ZeRO-2 或 ZeRO-3 做參數(shù)分片。數(shù)據(jù)加載時使用 memory-mapped dataset避免把整個數(shù)據(jù)集讀入內(nèi)存。訓練過程中要重點觀察兩個指標loss 是否穩(wěn)定下降以及梯度范數(shù)是否出現(xiàn)異常放大。如果 loss 突然升高優(yōu)先檢查是否有樣本長度分布不合理的問題。6.4 評測驗證Mid-Training 的效果不能只看訓練 loss還需要做針對性的評測。長上下文代碼評測可以分為三類評測類型說明示例通用長文本評測檢驗長文本理解基本能力LongBench、L-Eval代碼推理評測檢驗跨文件理解和修復能力CrossFileBench、RepoBench代碼生成評測檢驗長上下文下的生成質(zhì)量HumanEval、MBPP如果只做最簡單的驗證可以構(gòu)造一組“跨文件問答”測試集。比如給定兩個文件的內(nèi)容問模型第二個文件中的某個函數(shù)被誰調(diào)用或者某段邏輯的返回類型是什么。這類問題對模型的跨文件關聯(lián)能力非常敏感。下面給一個簡單的評測腳本思路from transformers import AutoModelForCausalLM, AutoTokenizer model_path output/checkpoints/your-lora-checkpoint tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained(model_path, device_mapauto) prompt repo namepayment-service file pathPaymentController.java ...代碼... /file /repo repo namecommon-lib file pathResult.java ...代碼... /file /repo 請回答PaymentController 中調(diào)用 PaymentService.createOrder 時返回的 Result 對象中code 字段在什么情況下為 500 inputs tokenizer(prompt, return_tensorspt).to(cuda) output model.generate(**inputs, max_new_tokens256) print(tokenizer.decode(output[0], skip_special_tokensTrue))這種評測方式不夠系統(tǒng)但能很直觀地看出模型在跨倉庫上下文上的表現(xiàn)差異適合在訓練過程中做快速回歸。7. 常見問題與排查思路在復現(xiàn)和訓練過程中很容易遇到各類問題。下面整理一張排查表。問題現(xiàn)象常見原因解決思路訓練時 OOM序列過長、batch size 太大、attention 顯存過高開啟 gradient checkpointing使用 FlashAttention-2降低 max_length增大梯度累積步數(shù)loss 快速下降后震蕩學習率過高、樣本長度分布不均勻降低學習率檢查數(shù)據(jù)集中超長樣本占比做長度分層采樣位置編碼外推后效果差RoPE 縮放方式不適配當前模型用 NTK 或 YaRN 替代 linear scaling做小規(guī)模消融實驗評測時模型忽略中間內(nèi)容模型沒有真正學到長距離關聯(lián)增加長樣本占比強化樣本中的文件邊界信息數(shù)據(jù)集樣本重復率高依賴圖構(gòu)建過于簡單同一批文件反復組合增加隨機采樣策略限制每個文件被選為 anchor 的次數(shù)跨倉庫文件路徑解析錯誤倉庫克隆結(jié)構(gòu)不一致路徑映射錯誤統(tǒng)一倉庫目錄結(jié)構(gòu)建立 repo 到根目錄的映射表訓練速度過慢attention 計算量過大數(shù)據(jù)加載成為瓶頸使用 FlashAttention-2開啟多進程數(shù)據(jù)加載使用預分詞緩存最常被忽視的問題是數(shù)據(jù)質(zhì)量。很多情況下模型表現(xiàn)不佳不是訓練參數(shù)不對而是訓練樣本本身沒有體現(xiàn)真正的跨倉庫依賴關系只是把多個文件機械地拼在一起。這種樣本對模型來說就像一段亂序文本學不到有效信息。8. 最佳實踐與工程建議8.1 數(shù)據(jù)質(zhì)量優(yōu)先先做小規(guī)模驗證跨倉庫樣本的構(gòu)建質(zhì)量直接決定 Mid-Training 的效果。建議先用 500 到 2000 條樣本做小規(guī)模實驗對比訓練前后模型在跨文件任務上的表現(xiàn)。只有數(shù)據(jù)構(gòu)建邏輯驗證通過后再擴大規(guī)模。驗證時可以人工檢查樣本同一個樣本中的文件之間是否有真實的調(diào)用關系文件邊界標記是否清晰樣本是否覆蓋了不同層級的長上下文4K、8K、16K、32K是否存在訓練集與真實任務分布不一致的問題8.2 訓練策略窗口長度逐步拉升不要在訓練一開始就使用 32K 的長序列。比較穩(wěn)定的做法是分階段第一階段以 8K 為主讓模型適應跨文件樣本格式。第二階段混合 8K 和 16K逐步加入更長樣本。第三階段加入 32K 以上的樣本鞏固極端長度下的表現(xiàn)。這個思路和人類學習類似先掌握結(jié)構(gòu)再應對更長的信息跨度。同時每階段訓練結(jié)束都要做一次評測回歸防止災難性遺忘。8.3 評測與回歸建立長上下文基線訓練前后要固定同一套評測集。建議包含三類數(shù)據(jù)單文件代碼生成任務用來監(jiān)測短上下文能力是否退化。跨文件代碼理解任務用來驗證 Mid-Training 的核心收益。超長輸入壓力測試檢測模型在長文本中定位關鍵信息的能力。每次實驗只改一個變量比如只改數(shù)據(jù)構(gòu)建方式或只改訓練長度。這樣才能定位出真正影響效果的因素。8.4 生產(chǎn)落地的邊界跨倉庫上下文訓練開銷較大落地上要關注幾個問題模型推理時的 KV Cache 顯存長輸入會有很大的 KV Cache生產(chǎn)環(huán)境要配合 vllm 等推理框架管理顯存。數(shù)據(jù)更新頻率倉庫代碼變化快訓練數(shù)據(jù)不能一成不變需要設計定期的數(shù)據(jù)重建流程。權(quán)限與合規(guī)使用真實業(yè)務倉庫數(shù)據(jù)做訓練時必須遵守代碼保密協(xié)議確保有合法授權(quán)。涉及敏感代碼的場景建議使用脫敏后的代碼片段進行訓練。回滾機制Mid-Training 后的模型如果在下游任務上出現(xiàn)退化要能快速回退到訓練前版本。建議在發(fā)布流程中保留原模型和中間 checkpoints。8.5 可復現(xiàn)性為了讓實驗可復現(xiàn)建議在項目里固定三樣東西依賴的 commit hash 或版本號。數(shù)據(jù)構(gòu)建腳本的版本。訓練配置文件的完整參數(shù)。每次數(shù)據(jù)更新或訓練配置變化都打一個版本號。長期實驗多了之后這能幫你快速定位是哪一次變更導致的效果波動。9. 總結(jié)OctoLong 給我們展示了一條清晰的路線在通用預訓練和指令微調(diào)之間增加一個針對性的 Mid-Training 階段用跨倉庫代碼上下文數(shù)據(jù)來增強模型的長上下文建模能力。這個思路的核心不在于“把窗口撐大”而在于讓模型真正學會利用分布在不同文件、不同倉庫中的信息。如果要在自己的項目中復現(xiàn)類似方案優(yōu)先級是這樣先做好數(shù)據(jù)構(gòu)建真實的依賴圖組裝有邏輯關系的跨倉庫樣本。再選好訓練策略用 LoRA 先驗證再決定是否做全參數(shù)訓練。最后完善評測設計能體現(xiàn)跨文件能力的評測集避免只盯著訓練 loss。實際落地中最值得花時間的不是訓練本身而是數(shù)據(jù)構(gòu)造和評測設計。訓練代碼和參數(shù)都有成熟模板但“哪些文件應該出現(xiàn)在同一個上下文里”這個問題需要結(jié)合真實的代碼依賴關系去回答。如果你正打算給代碼模型做長上下文增強建議先克隆幾個真實項目跑一遍依賴構(gòu)建流程看看能產(chǎn)生多少有價值的跨倉庫樣本。這個實驗本身成本不高但對后續(xù)訓練方案的設計會很有幫助。如果你在實際操作中遇到其他問題歡迎在評論區(qū)留言交流。也可以把本文收藏起來在做跨倉庫上下文訓練時隨時翻閱。