為 PEFT 做貢獻

我們很高興接受對 PEFT 的貢獻。如果您計劃貢獻，請閱讀本文件以使過程儘可能順利。

安裝

對於 PEFT 的程式碼貢獻，您應該選擇“從原始碼”安裝方法。

如果您是第一次建立拉取請求，請遵循 GitHub 上的建立拉取請求指南。

測試和程式碼質量檢查

無論貢獻型別如何（除非只涉及文件），您都應在建立 PR 之前執行測試和程式碼質量檢查，以確保您的貢獻不會破壞任何內容並遵循專案標準。

我們提供了一個 Makefile 來執行必要的測試。執行以下程式碼進行單元測試

make test

執行以下命令之一，可以僅檢查程式碼質量和樣式，或檢查並修復它們

make quality  # just check
make style  # check and fix

您還可以設定 pre-commit，使其作為 Git 提交鉤子自動執行這些修復。

$ pip install pre-commit
$ pre-commit install

執行所有測試可能需要一些時間，因此在開發過程中，僅執行與您的更改相關的特定測試會更有效率，例如透過

pytest tests/<test-file-name> -k <name-of-test>

這將更快完成並允許更快的迭代。

如果您的更改特定於某種硬體設定（例如，需要 CUDA），請檢視 tests/test_gpu_examples.py 和 tests/test_common_gpu.py，以確定是否有必要在那裡新增測試。如果您的更改可能影響模型的儲存和載入，請使用 --regression 標誌執行測試以觸發迴歸測試。

在您處理 PR 的過程中，底層程式碼庫可能會因其他更改被合併而發生變化。如果發生這種情況——尤其是在出現合併衝突時——請用最新更改更新您的分支。這可以是一個合併或一個 rebase，一旦準備好，我們將壓縮併合並 PR。如果可能，請避免強制推送以方便審查。

PR 描述

在開啟 PR 時，請為您提議的更改提供一個良好的描述。如果它與其他問題或 PR 相關，請引用它們。提供一個好的描述不僅有助於審閱者更好更快地審查您的程式碼，還可以作為後續提交訊息的基礎，這有助於專案的長期維護。

如果您的程式碼進行了一些非平凡的更改，最好在程式碼中添加註釋來解釋這些更改。例如，如果您因為最顯而易見的方式行不通而不得不多次迭代您的實現，這表明需要新增程式碼註釋。

錯誤修復

請描述導致該錯誤的具體情況。如果已有相關 issue，請連結到它（例如，“解決 #12345”）。

理想情況下，提供錯誤修復時，應附帶針對該錯誤的測試。該測試應在當前程式碼下失敗，在修復後透過。在測試中添加註釋，引用相關 issue 或 PR。沒有測試，未來更難防止迴歸。

新增新的微調方法

新的引數高效微調方法層出不窮。如果您想向 PEFT 新增一種新的、有前景的方法，請遵循以下步驟。

1. 在開始實施新方法之前，請在 GitHub issue 中提出您的建議。這樣，維護者可以給您一些早期反饋。
2. 請新增該方法的來源連結（通常是一篇論文）。論文應處於最終狀態，以避免在開發過程中因審稿人反饋等原因導致需求變更。
3. 在實施該方法時，尋找現有的實現作為指導是有意義的。此外，在組織程式碼時，請參考其他 PEFT 方法。例如，如果您的方法與 LoRA 相似，那麼類似地組織程式碼，甚至在合理的情況下重用一些函式或類都是有意義的（一些程式碼重複是可以接受的，但不要過度）。
4. 理想情況下，除了新方法的實現之外，還應該有
   • 示例（筆記本、指令碼）
   • 文件
   • 詳盡的測試套件，證明該方法能正確整合到 PEFT 中
   • 實驗設定，以執行基準測試
5. 一旦您有了看起來可行的東西，即使它尚未處於可合併狀態，也不要猶豫建立草稿 PR。維護者很樂意在此過程中為您提供反饋和指導。

新增其他功能

最好先在 GitHub 上開一個 issue，提出新增新功能的建議。這樣，您可以在花費太多時間實施之前，與維護者討論新增該功能是否合理。

新功能通常應附有測試和文件或示例。沒有後者，使用者將很難發現您酷炫的新功能。

對程式碼的更改應以向後相容的方式實現。例如，現有程式碼在功能合併後應繼續以同樣的方式工作。