當前位置：首頁 > 运维知识 > windows >内容正文

windows

个人编程助手: 训练你自己的编码助手

發(fā)布時間：2023/11/16 windows 64 coder

生活随笔收集整理的這篇文章主要介紹了个人编程助手: 训练你自己的编码助手小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

在編程和軟件開發(fā)這個不斷演變的領(lǐng)域中，對效率和生產(chǎn)力的追求催生了許多卓越的創(chuàng)新。其中一個顯著的創(chuàng)新就是代碼生成模型的出現(xiàn)，如 Codex、StarCoder 和 Code Llama。這些模型在生成類似人類編寫的代碼片段方面表現(xiàn)出驚人能力，顯示出了作為編程助手的巨大潛力。

然而，雖然這些預(yù)訓練模型在各種任務(wù)上已經(jīng)表現(xiàn)出了卓越的性能，但在不遠的未來，我們?nèi)匀豢梢云诖粋€令人興奮的前景: 想象一下，你能夠根據(jù)自己的特定需求定制代碼生成模型，并且這種個性化的編程助手能夠在企業(yè)規(guī)模上得到應(yīng)用。

在這篇博客中，我們將展示如何創(chuàng)建 HugCoder ??，一個在 huggingface GitHub 組織的公共倉庫代碼內(nèi)容上進行微調(diào)的代碼大模型。我們將講述我們的數(shù)據(jù)收集工作流程、訓練實驗，以及一些有趣的結(jié)果。這將使你能夠根據(jù)你的專有代碼庫創(chuàng)建自己的個人編程助手。我們還將為這個項目的進一步擴展留下一些實驗的方向。

讓我們開始吧 ??

數(shù)據(jù)收集的工作流

我們想要的數(shù)據(jù)集在概念上非常簡單，我們像下面所示那樣構(gòu)建它。


倉庫名	倉庫中的文件路徑	文件內(nèi)容
—	—	—
—	—	—

使用 Python GitHub API 從 GitHub 上抓取代碼內(nèi)容是直截了當?shù)摹Ｈ欢@取決于倉庫的數(shù)量和倉庫內(nèi)代碼文件的數(shù)量，通常情況，人們很容易會遇到 API 速率限制等問題。

為了防止這類問題發(fā)生，我們決定將所有公共倉庫克隆到本地，并從中提取內(nèi)容，而不是通過 API。我們使用 Python 的 multiprocessing 模塊并行下載所有倉庫，如這個下載腳本。

一個倉庫通常可能包含非代碼文件，如圖片、演示文稿和其他資料。我們對抓取它們不感興趣。我們?yōu)榇藙?chuàng)建了一個擴展名列表來過濾掉它們。為了解析除了 Jupyter Notebook 之外的代碼文件，我們簡單地使用了 “utf-8” 編碼。對于 notebook，我們只考慮了代碼單元。

我們還排除了所有與代碼不直接相關(guān)的文件路徑。這些包括: .git ， __pycache__ 和 xcodeproj 。

為了保持這些內(nèi)容的序列化相對內(nèi)存友好 (即處理代碼時不會過多占用內(nèi)存)，我們使用了分塊處理方法和 feather 格式 (儲存序列化的數(shù)據(jù))。完整實現(xiàn)請參見這個腳本。

最終的數(shù)據(jù)集可在 Hub 上獲取，它看起來像這個樣子:

對于這篇博客，我們選取了基于點贊數(shù)排名前十的 Hugging Face 公共倉庫。它們分別是:

['transformers', 'pytorch-image-models', 'datasets', 'diffusers', 'peft', 'tokenizers', 'accelerate', 'text-generation-inference', 'chat-ui', 'deep-rl-class']

這是我們用來生成這個數(shù)據(jù)集的代碼，而這是數(shù)據(jù)集在 Hub 上的鏈接。下面是它的一個快照:

為了降低項目復雜性，我們沒有考慮對數(shù)據(jù)集進行去重。如果你對在生產(chǎn)應(yīng)用中應(yīng)用去重技術(shù)感興趣，這篇博客文章是一個極佳的資源，它在代碼大模型的內(nèi)容中詳細討論了這個主題。

微調(diào)你的個人代碼助手

在這一部分，我們將展示如何微調(diào)以下模型: bigcode/starcoder (15.5B 參數(shù)) 、bigcode/starcoderbase-1b (1B 參數(shù)) 和 Deci/DeciCoder-1b (1B 參數(shù))。我們將使用一個帶有 40GB 顯存的 A100 Colab Notebook，并使用 ?? PEFT (Parameter-Efficient Fine-Tuning，參數(shù)高效微調(diào)) 進行所有實驗。此外，我們還將展示如何使用 ?? Accelerate 的 FSDP (Fully Sharded Data Parallel，全分片數(shù)據(jù)并行) 集成，在一臺配備 8 個 80GB 顯存的 A100 GPU 的機器上完全微調(diào) bigcode/starcoder (15.5B 參數(shù))。訓練目標是 fill in the middle (FIM) ，其中訓練序列的一部分被移動到序列的末尾，并且重排序后的序列被自回歸地預(yù)測。

為什么選擇 PEFT ？因為全微調(diào)代價高昂。讓我們來看一些數(shù)字以便更好地理解:

全微調(diào)所需的最小 GPU 內(nèi)存:

參數(shù)權(quán)重: 2 字節(jié) (混合精度訓練)
參數(shù)權(quán)重梯度: 2 字節(jié)
使用 Adam 優(yōu)化器時的優(yōu)化器狀態(tài): 4 字節(jié)用于原始 FP32 權(quán)重 + 8 字節(jié)用于一階和二階矩估計
將以上所有內(nèi)容加在一起的每個參數(shù)成本: 每個參數(shù) 16 字節(jié)
15.5B 模型 -> 248GB 的 GPU 內(nèi)存，甚至還沒有考慮存儲中間激活值所需的巨大內(nèi)存 -> 至少需要 4 個 A100 80GB GPU

由于硬件需求巨大，我們將使用 QLoRA 進行參數(shù)高效微調(diào)。下面是使用 QLoRA 進行 Starcoder 微調(diào)的最小 GPU 內(nèi)存需求:

trainable params: 110,428,160 || all params: 15,627,884,544 || trainable%: 0.7066097761926236

基礎(chǔ)模型權(quán)重: 0.5 字節(jié) * 15.51B 凍結(jié)參數(shù) = 7.755GB
適配器 (Adapter) 權(quán)重: 2 字節(jié) * 0.11B 可訓練參數(shù) = 0.22GB
權(quán)重梯度: 2 字節(jié) * 0.11B 可訓練參數(shù) = 0.22GB
使用 Adam 優(yōu)化器時的優(yōu)化器狀態(tài): 4 字節(jié) * 0.11B 可訓練參數(shù) * 3 = 1.32GB
將以上所有內(nèi)容加在一起 -> 9.51GB ~ 10GB -> 需要 1 個 A100 40GB GPU ??。選擇 A100 40GB GPU 的原因是，訓練時長序列長度為 2048，批量大小為 4，這會導致更高的內(nèi)存需求。如下所示，所需的 GPU 內(nèi)存為 26GB，可以在 A100 40GB GPU 上容納。此外，A100 GPU 與 Flash Attention 2 具有更好的兼容性。

在上面的計算中，我們沒有考慮中間激活值檢查點所需的內(nèi)存，這通常是相當巨大的。我們利用 Flash Attention V2 和梯度檢查點來解決這個問題。

對于 QLoRA，加上 flash attention V2 和梯度檢查點，單個 A100 40GB GPU 上模型占用的總內(nèi)存為 26GB， 批量大小為 4。
對于使用 FSDP 進行全微調(diào)，加上 Flash Attention V2 和梯度檢查點，每個 GPU 上占用的內(nèi)存在 70GB 到 77.6GB 之間， 每個 GPU 的批量大小為 1。

請參考 model-memory-usage 以輕松計算在 ?? Hugging Face Hub 上托管的大型模型上進行訓練和推理所需的 vRAM。

全微調(diào)

我們將探討如何使用 PyTorch Fully Sharded Data Parallel (FSDP) 技術(shù)在 8 個 A100 80GB GPU 上完全微調(diào) bigcode/starcoder (15B 參數(shù))。欲了解更多關(guān)于 FSDP 的信息，請參閱 Fine-tuning Llama 2 70B using PyTorch FSDP 和 Accelerate Large Model Training using PyTorch Fully Sharded Data Parallel。

資源

代碼庫: 鏈接。它使用了 Transformers 中最近添加的 Flash Attention V2 支持。
FSDP 配置: fsdp_config.yaml
模型: bigcode/stacoder
數(shù)據(jù)集: smangrul/hf-stack-v1
微調(diào)后的模型: smangrul/peft-lora-starcoder15B-v2-personal-copilot-A100-40GB-colab

啟動訓練的命令在 run_fsdp.sh 中給出。

accelerate launch --config_file "configs/fsdp_config.yaml" train.py \
    --model_path "bigcode/starcoder" \
    --dataset_name "smangrul/hf-stack-v1" \
    --subset "data" \
    --data_column "content" \
    --split "train" \
    --seq_length 2048 \
    --max_steps 2000 \
    --batch_size 1 \
    --gradient_accumulation_steps 2 \
    --learning_rate 5e-5 \
    --lr_scheduler_type "cosine" \
    --weight_decay 0.01 \
    --num_warmup_steps 30 \
    --eval_freq 100 \
    --save_freq 500 \
    --log_freq 25 \
    --num_workers 4 \
    --bf16 \
    --no_fp16 \
    --output_dir "starcoder-personal-copilot-A100-40GB-colab" \
    --fim_rate 0.5 \
    --fim_spm_rate 0.5 \
    --use_flash_attn

總的訓練時間為 9 小時。根據(jù) lambdalabs 的價格，8 個 A100 80GB GPU 的成本為每小時 $12.00，總成本將為 $108。

PEFT

我們將探討如何使用 ?? PEFT 的 QLoRA 方法對 bigcode/starcoder (15B 參數(shù)) 進行微調(diào)，使用的硬件是單個 A100 40GB GPU。有關(guān) QLoRA 和 PEFT 方法的更多信息，請參閱 Making LLMs even more accessible with bitsandbytes, 4-bit quantization and QLoRA 和 ?? PEFT: Parameter-Efficient Fine-Tuning of Billion-Scale Models on Low-Resource Hardware。

資源

代碼庫: 鏈接。它使用了 Transformers 中最近添加的 Flash Attention V2 支持。
Colab notebook: 鏈接。請確保選擇帶有 High RAM 設(shè)置的 A100 GPU。
模型: bigcode/stacoder
數(shù)據(jù)集: smangrul/hf-stack-v1
QLoRA 微調(diào)模型: smangrul/peft-lora-starcoder15B-v2-personal-copilot-A100-40GB-colab

啟動訓練的命令在 run_peft.sh 中給出。總的訓練時間為 12.5 小時。根據(jù) lambdalabs 的價格，每小時 $1.10，總成本將為 $13.75。這真是太棒了??！從成本上講，它比全微調(diào)的成本低了 7.8 倍。

對比

下面的圖展示了 QLoRA 與全微調(diào)的評估損失、訓練損失和學習率調(diào)度器。我們觀察到，全微調(diào)的損失略低，收斂速度也略快一些，與 QLoRA 相比。PEFT 微調(diào)的學習率是全微調(diào)的 10 倍。

為了確保我們的 QLoRA 模型不會導致災(zāi)難性遺忘，我們在其上運行了 Python Human Eval。以下是我們得到的結(jié)果。 Pass@1 評估了單個問題的通過率，考慮了每個問題僅生成一個代碼候選。我們可以觀察到，在 humaneval-python 上，基礎(chǔ)模型 bigcode/starcoder (15B 參數(shù)) 和微調(diào)后的 PEFT 模型 smangrul/peft-lora-starcoder15B-v2-personal-copilot-A100-40GB-colab 的性能是可比的。


模型	Pass@1
bigcode/starcoder	33.57
smangrul/peft-lora-starcoder15B-v2-personal-copilot-A100-40GB-colab	33.37

現(xiàn)在讓我們來看一些定性的樣本。在我們的手動分析中，我們注意到 QLoRA 導致了輕微的過擬合，因此我們通過使用 PEFT 的 add_weighted_adapter 工具，創(chuàng)建一個權(quán)重為 0.8 的新加權(quán)適配器 (Adapter) 來降低其權(quán)重。

我們將看兩個代碼填充的例子，其中模型的任務(wù)是填充由 <FILL_ME> 占位符表示的部分。我們將考慮從 GitHub Copilot、QLoRA 微調(diào)模型和全微調(diào)模型的填充完成。

定性示例 1

在上面的示例中，GitHub Copilot 的補全是正確的，但幫助不大。另一方面，QLoRA 和全微調(diào)模型的補全正確地填充了整個函數(shù)調(diào)用及其必要的參數(shù)。然而，它們之后也添加了許多噪聲。這可以通過后處理步驟來控制，以限制補全到閉括號或新行。注意，QLoRA 和全微調(diào)模型產(chǎn)生的結(jié)果質(zhì)量相似。

定性示例 2

在上面的第二個示例中， GitHub Copilot 沒有給出任何補全。這可能是因為 ?? PEFT 是一個最近的庫，還沒有成為 Copilot 訓練數(shù)據(jù)的一部分，這 正是我們試圖解決的問題類型。另一方面，QLoRA 和全微調(diào)模型的補全正確地填充了整個函數(shù)調(diào)用及其必要的參數(shù)。再次注意，QLoRA 和全微調(diào)模型提供的生成質(zhì)量相似。全微調(diào)模型和 PEFT 模型的各種示例的推理代碼分別可在 Full_Finetuned_StarCoder_Inference.ipynb 和 PEFT_StarCoder_Inference.ipynb 中找到。

因此，我們可以觀察到，兩種變體的生成都符合預(yù)期。太棒了！??

怎么在 VS Code 中使用?

你可以輕松地使用 ?? llm-vscode VS Code 擴展配置一個自定義的代碼補全大模型，并通過 ?? Inference EndPoints 托管模型。我們將在下面逐步介紹所需的步驟。你可以在推理端點文檔中了解有關(guān)部署端點的更多詳細信息。

設(shè)置推理端點

下面是我們創(chuàng)建自定義推理端點時遵循的步驟的截圖。我們使用了我們的 QLoRA 模型，導出為一個可以輕松加載到 transformers 中的全尺寸的 merged 模型。

設(shè)置 VS Code 擴展

只需按照安裝步驟操作。在設(shè)置中，將下面字段中的端點替換為你部署的 HF 推理端點的地址。

使用起來如下所示:

微調(diào)你自己的代碼聊天助手

到目前為止，我們訓練的模型特別是作為代碼完成任務(wù)的個人助手培訓。它們沒有被訓練來進行對話或回答問題。 Octocoder 和 StarChat 是這類模型的絕佳示例。本節(jié)簡要描述了如何實現(xiàn)這一點。

資源

代碼庫: 鏈接。它使用了 Transformers 中最近添加的 Flash Attention V2 支持。
Colab notebook: 鏈接。請確保選擇帶有 High RAM 設(shè)置的 A100 GPU。
模型: bigcode/stacoderplus
數(shù)據(jù)集: smangrul/code-chat-assistant-v1。混合了 LIMA+GUANACO 并以適合訓練的格式正確格式化。
訓練好的模型: smangrul/peft-lora-starcoderplus-chat-asst-A100-40GB-colab

LoRA 的組合

如果你曾經(jīng)涉足 Stable Diffusion 模型和 LoRAs，以及用于制作你自己的 Dreambooth 模型，你可能會熟悉將不同的 LoRAs 與不同的權(quán)重結(jié)合起來的概念，使用一個與其訓練基模型不同的 LoRA 模型。在文本/代碼領(lǐng)域，目前仍是未被探索的領(lǐng)域。我們在這方面進行了實驗，并觀察到了非常有趣的發(fā)現(xiàn)。你準備好了嗎？我們出發(fā)吧！??

混合匹配 LoRAs

PEFT 目前支持 3 種結(jié)合 LoRA 模型的方式，linear 、 svd 和 cat 。更多細節(jié)，請參考 tuners#peft.LoraModel.add_weighted_adapter。

我們的 notebook Dance_of_LoRAs.ipynb 提供了所有推理代碼，并展示了多種 LoRA 模型的加載組合。例如，它展示了如何在 starcoder 模型上加載聊天助手適配器 (Adapter)，盡管 starcoderplus 是我們用于微調(diào)的基礎(chǔ)模型。

這里，我們將考慮 2 種能力 ( 聊天/問答 和 代碼完成 ) 在 2 種數(shù)據(jù)分布 ( 前 10 公共 hf 代碼庫 和 通用代碼庫 ) 上。這給了我們 4 個軸，我們將在上面進行一些定性評估分析。

首先，讓我們考慮`聊天/問答` 任務(wù)。

如果我們禁用適配器 (Adapter)，我們觀察到對于兩個數(shù)據(jù)集來說任務(wù)都失敗了，因為基模型 ( starcoder ) 僅用于代碼完成，不適合 聊天/問答 。啟用 copilot 適配器 (Adapter) 的表現(xiàn)類似于禁用的情況，因為這個 LoRA 也是專門為代碼完成而微調(diào)的。

現(xiàn)在，讓我們啟用 assistant 適配器 (Adapter)。

基于生成代碼的 QA

基于 HF 代碼的 QA

我們可以觀察到，關(guān)于 scrapy 的通用問題得到了妥善的回答。然而，它未能解答與 HF (Hugging Face) 代碼相關(guān)的問題，因為這不是它預(yù)訓練數(shù)據(jù)的一部分。

現(xiàn)在讓我們考慮 `代碼補全` 任務(wù)。

在禁用適配器 (Adapter) 時，我們觀察到對于通用的兩數(shù)之和問題，代碼補全如預(yù)期般工作正常。然而，對于 HF 代碼補全任務(wù)，由于基礎(chǔ)模型在其預(yù)訓練數(shù)據(jù)中未曾見過，所以在向 LoraConfig 傳遞參數(shù)時出現(xiàn)了錯誤。啟用 assistant 的表現(xiàn)與禁用時相似，因為它是在自然語言對話的基礎(chǔ)上訓練的，這些對話中沒有任何 Hugging Face 代碼倉庫的內(nèi)容。

現(xiàn)在，讓我們啟用 copilot 適配器 (Adapter)。

我們可以觀察到，在兩種情況下 copilot 適配器 (Adapter) 都得到了正確的結(jié)果。因此，無論是在處理 HF (Hugging Face) 特定代碼庫還是通用代碼庫時，它都能如預(yù)期地完成代碼補全任務(wù)。

現(xiàn)在，作為用戶，我希望能結(jié)合 assistant 和 copilot 的能力。這將使我能夠在 IDE 中編碼時使用它進行代碼補全，同時也能將它作為聊天機器人來回答我關(guān)于 API、類、方法、文檔的問題。它應(yīng)該能夠提供對問題的答案，如 我該如何使用 x ，請在我的代碼的基礎(chǔ)上 為 Y 編寫一段代碼片段 。

PEFT 允許你通過 add_weighted_adapter 來實現(xiàn)這一點。讓我們創(chuàng)建一個新的適配器 code_buddy ，給予 assistant 和 copilot 適配器相同的權(quán)重。

結(jié)合多種適配器 (Adapter)

現(xiàn)在，讓我們看看 code_buddy 在 聊天/問答 任務(wù)上的表現(xiàn)。

我們可以觀察到 code_buddy 的表現(xiàn)比單獨的 assistant 或 copilot 適配器要好得多！它能夠回答 編寫代碼片段 的請求，展示如何使用特定的 HF 倉庫 API。然而，它也出現(xiàn)了錯誤鏈接/解釋的幻覺，這仍然是大型語言模型面臨的一個開放性挑戰(zhàn)。

下面是 code_buddy 在代碼補全任務(wù)上的表現(xiàn)。

我們可以觀察到 code_buddy 的表現(xiàn)與專門為這個任務(wù)微調(diào)的 copilot 不相上下。

將 LoRA 模型遷移到不同的基礎(chǔ)模型

我們還可以將 LoRA 模型遷移到不同的基礎(chǔ)模型上。
我們將取剛出爐的 Octocoder 模型，并在其上應(yīng)用我們之前用 starcoder 基礎(chǔ)模型訓練的 LoRA。請查看以下 notebook PEFT_Personal_Code_CoPilot_Adapter_Transfer_Octocoder.ipynb，了解全部代碼。

代碼補全任務(wù)上的表現(xiàn)

我們可以觀察到 octocoder 的表現(xiàn)很好。它能夠完成 HF (Hugging Face) 特定的代碼片段。如 notebook 中所見，它也能夠完成通用的代碼片段。

聊天/問答任務(wù)上的表現(xiàn)

由于 Octocoder 被訓練用來回答有關(guān)編程的問題和進行對話，讓我們看看它是否能使用我們的 LoRA 適配器來回答 HF (Hugging Face) 特定的問題。

太棒了！它詳細正確地回答了如何創(chuàng)建 LoraConfig 和相關(guān)的 peft 模型，并且正確地使用了模型名稱、數(shù)據(jù)集名稱以及 LoraConfig 的參數(shù)值。當禁用適配器時，它未能正確使用 LoraConfig 的 API 或創(chuàng)建 PEFT 模型，這表明它不是 Octocoder 訓練數(shù)據(jù)的一部分。

我如何在本地運行它？

我知道，在經(jīng)歷了這一切之后，你想在你自己的代碼庫上微調(diào) starcoder 并在本地使用，比如在帶有 M1 GPU 的 Mac 筆記本電腦上，或者帶有 RTX 4090/3090 GPU 的 Windows 電腦上……別擔心，我們已經(jīng)為你準備好了。

我們將使用這個超酷的開源庫 mlc-llm ??。具體來說，我們將使用這個分支 pacman100/mlc-llm，它進行了一些修改，可以與 VS Code 的 Hugging Face 代碼完成擴展配合使用。在我的搭載 M1 Metal GPU 的 Mac 筆記本上，15B 模型運行得非常慢。因此，我們將縮小規(guī)模，訓練一個 PEFT LoRA 版本以及一個完全微調(diào)版本的 bigcode/starcoderbase-1b 。以下是訓練用的 Colab notebook 鏈接:

全微調(diào)和 PEFT LoRA 微調(diào) starcoderbase-1b 的 Colab notebook: 鏈接

下面繪制了訓練損失、評估損失以及學習率計劃圖:

現(xiàn)在，我們將看看詳細步驟，本地托管合并后的模型 smangrul/starcoder1B-v2-personal-copilot-merged 并使用 ?? llm-vscode VS Code 擴展。

克隆倉庫

git clone --recursive https://github.com/pacman100/mlc-llm.git && cd mlc-llm/

安裝 mlc-ai 和 mlc-chat (在編輯模式):

pip install --pre --force-reinstall mlc-ai-nightly mlc-chat-nightly -f https://mlc.ai/wheels
cd python
pip uninstall mlc-chat-nightly
pip install -e "."

通過以下方式編譯模型:

time python3 -m mlc_llm.build --hf-path smangrul/starcoder1B-v2-personal-copilot-merged --target metal --use-cache=0

在 dist/starcoder1B-v2-personal-copilot-merged-q4f16_1/params/mlc-chat-config.json 中更新配置，設(shè)定以下的值:

{
    "model_lib": "starcoder7B-personal-copilot-merged-q4f16_1",
    "local_id": "starcoder7B-personal-copilot-merged-q4f16_1",
    "conv_template": "code_gpt",
- "temperature": 0.7,
+ "temperature": 0.2,
- "repetition_penalty": 1.0,
    "top_p": 0.95,
- "mean_gen_len": 128,
+ "mean_gen_len": 64,
- "max_gen_len": 512,
+ "max_gen_len": 64,
    "shift_fill_factor": 0.3,
    "tokenizer_files": [
        "tokenizer.json",
        "merges.txt",
        "vocab.json"
    ],
    "model_category": "gpt_bigcode",
    "model_name": "starcoder1B-v2-personal-copilot-merged"
}

運行本地服務(wù):

 python -m mlc_chat.rest --model dist/starcoder1B-v2-personal-copilot-merged-q4f16_1/params --lib-path dist/starcoder1B-v2-personal-copilot-merged-q4f16_1/starcoder1B-v2-personal-copilot-merged-q4f16_1-metal.so

將 VS Code 中的 HF Code Completion 擴展的端點更改為指向本地服務(wù)器:

在 VS Code 中打開一個新文件，粘貼下面的代碼，并將光標放在文檔引號之間，這樣模型就會嘗試填充文檔字符串:

瞧！??

這篇文章開頭的演示就是這個 1B 模型在我的 Mac 筆記本上本地運行的效果。

結(jié)論

在這篇博客中，我們探索了如何對 starcoder 進行微調(diào)，從而創(chuàng)建了一個能理解我們代碼的個人編程助手。我們稱之為 ?? HugCoder，因為它是在 Hugging Face 的代碼上進行訓練的 ?? 在回顧了數(shù)據(jù)收集流程之后，我們對比了使用 QLoRA 和全面微調(diào)進行訓練的效果。我們還嘗試了組合不同的 LoRAs，這在文本和代碼領(lǐng)域是一項尚待開發(fā)的技術(shù)。在部署方面，我們研究了使用 ?? Inference Endpoints 進行遠程推理，并且還展示了如何在 VS Code 和 MLC 上本地執(zhí)行一個較小的模型。

如果你將這些方法應(yīng)用到了你自己的代碼庫，請告訴我們！

致謝

我們要感謝 Pedro Cuenca、Leandro von Werra、Benjamin Bossan、Sylvain Gugger 和 Loubna Ben Allal 在撰寫這篇博客時提供的幫助。

英文原文: https://hf.co/blog/personal-copilot

原文作者: Sourab Mangrulkar, Sayak Paul

譯者: innovation64

審校/排版: zhongdongy (阿東)

總結(jié)

以上是生活随笔為你收集整理的个人编程助手: 训练你自己的编码助手的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇： Linux socket API
下一篇： Welcome to YARP - 7.