```html ผู้แต่ง: Mayank Mishra⋆, IBM Matt Stallone⋆, IBM Gaoyuan Zhang⋆, IBM Yikang Shen, IBM Aditya Prasad, IBM Adriana Meza Soria, IBM Michele Merler, IBM Parameswaran Selvam, IBM Saptha Surendran, IBM Shivdeep Singh, IBM Manish Sethi, IBM Xuan-Hong Dang, IBM Pengyuan Li, IBM Kun-Lung Wu, IBM Syed Zawad, IBM Andrew Coleman, IBM Matthew White, IBM Mark Lewis, IBM Raju Pavuluri, IBM Yan Koyfman, IBM Boris Lublinsky, IBM Maximilien de Bayser, IBM Ibrahim Abdelaziz, IBM Kinjal Basu, IBM Mayank Agarwal, IBM Yi Zhou, IBM Chris Johnson, IBM Aanchal Goyal, IBM Hima Patel, IBM Yousaf Shah, IBM Petros Zerfos, IBM Heiko Ludwig, IBM Asim Munawar, IBM Maxwell Crouse, IBM Pavan Kapanipathi, IBM Shweta Salaria, IBM Bob Calio, IBM Sophia Wen, IBM Seetharami Seelam, IBM Brian Belgodere, IBM Carlos Fonseca, IBM Amith Singhee, IBM Nirmit Desai, IBM David D. Cox, IBM Ruchir Puri†, IBM Rameswar Panda†, IBM บทคัดย่อ Large Language Models (LLMs) ที่ได้รับการฝึกฝนเกี่ยวกับโค้ดกำลังปฏิวัติกระบวนการพัฒนาซอฟต์แวร์ LLMs สำหรับโค้ดกำลังถูกรวมเข้ากับสภาพแวดล้อมการพัฒนาซอฟต์แวร์มากขึ้นเรื่อยๆ เพื่อเพิ่มผลิตภาพของโปรแกรมเมอร์ และเอเจนต์ที่ใช้ LLM กำลังเริ่มแสดงความหวังในการจัดการงานที่ซับซ้อนได้อย่างอิสระ การทำให้ศักยภาพสูงสุดของ LLMs สำหรับโค้ดเป็นจริงได้นั้น จำเป็นต้องมีความสามารถที่หลากหลาย รวมถึงการสร้างโค้ด การแก้ไขข้อผิดพลาด การอธิบายและจัดทำเอกสารโค้ด การบำรุงรักษาที่เก็บโค้ด และอื่นๆ ในงานนี้ เราขอแนะนำซีรีส์ Granite ของโมเดลโค้ดแบบ decoder-only สำหรับงานสร้างโค้ด ซึ่งได้รับการฝึกฝนด้วยโค้ดที่เขียนด้วยภาษาโปรแกรม 116 ภาษา ตระกูลโมเดล Granite Code ประกอบด้วยโมเดลที่มีขนาดตั้งแต่ 3 ถึง 34 พันล้านพารามิเตอร์ เหมาะสำหรับการใช้งานที่หลากหลาย ตั้งแต่งานปรับปรุงแอปพลิเคชันที่ซับซ้อนไปจนถึงกรณีการใช้งานที่ต้องการหน่วยความจำจำกัดบนอุปกรณ์ การประเมินบนชุดงานที่ครอบคลุมแสดงให้เห็นว่าโมเดล Granite Code ได้รับประสิทธิภาพที่ล้ำสมัยอย่างสม่ำเสมอในบรรดา LLMs สำหรับโค้ดโอเพนซอร์สที่มีอยู่ ตระกูลโมเดล Granite Code ได้รับการปรับให้เหมาะสมสำหรับเวิร์กโฟลว์การพัฒนาซอฟต์แวร์ระดับองค์กร และทำงานได้ดีในงานโค้ดที่หลากหลาย (เช่น การสร้างโค้ด การแก้ไข และการอธิบาย) ทำให้เป็นโมเดลโค้ดที่ใช้งานได้หลากหลายแบบ "รอบด้าน" เราเผยแพร่โมเดล Granite Code ทั้งหมดของเราภายใต้ใบอนุญาต Apache 2.0 สำหรับทั้งการวิจัยและการใช้งานเชิงพาณิชย์ https://github.com/ibm-granite/granite-code-models 1 บทนำ ในช่วงหลายทศวรรษที่ผ่านมา ซอฟต์แวร์ได้กลายเป็นส่วนสำคัญของทุกแง่มุมในสังคมของเรา เมื่อความต้องการในการพัฒนาซอฟต์แวร์เพิ่มสูงขึ้น การเพิ่มผลิตภาพในการพัฒนาซอฟต์แวร์จึงมีความสำคัญอย่างยิ่ง และ LLMs ก็เป็นหนทางที่มีแนวโน้มในการเสริมศักยภาพโปรแกรมเมอร์ที่เป็นมนุษย์ กรณีการใช้งานระดับองค์กรที่โดดเด่นสำหรับ LLMs ในด้านผลิตภาพการพัฒนาซอฟต์แวร์ ได้แก่ การสร้างโค้ด การอธิบายโค้ด การแก้ไขโค้ด การสร้าง unit test และเอกสารประกอบ การปรับปรุงแอปพลิเคชัน การตรวจจับช่องโหว่ การแปลโค้ด และอื่นๆ ในช่วงไม่กี่ปีที่ผ่านมา มีความก้าวหน้าอย่างรวดเร็วในความสามารถของ LLM ในการสร้างและจัดการโค้ด และมีโมเดลที่มีความสามารถด้านโค้ดที่น่าประทับใจมากมายในปัจจุบัน โมเดลมีตั้งแต่ไม่กี่พันล้านพารามิเตอร์ (เช่น Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024) เป็นต้น) ไปจนถึงหลายแสนล้าน: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere) และมีความแตกต่างกันในการใช้งานทั่วไป โดยบางโมเดลมีเป้าหมายเพื่อครอบคลุมการใช้งานที่หลากหลายนอกเหนือจากโค้ด ในขณะที่บางโมเดลเน้นไปที่งานที่เกี่ยวข้องกับโค้ดเป็นหลัก (เช่น StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), และ CodeGemma (CodeGemma Team et al., 2024)) อย่างไรก็ตาม ยังมีช่องว่างที่สำคัญในสาขา LLMs สำหรับโค้ดในปัจจุบัน โดยเฉพาะอย่างยิ่งในบริบทของการพัฒนาซอฟต์แวร์ระดับองค์กร ประการแรก แม้ว่า LLMs ทั่วไปขนาดใหญ่มากจะสามารถให้ประสิทธิภาพด้านโค้ดที่ยอดเยี่ยมได้ แต่ขนาดของมันทำให้มีค่าใช้จ่ายสูงในการใช้งาน โมเดลโค้ดขนาดเล็กที่เน้นโค้ดเป็นพิเศษ ( , ; , ; , ; , ; , ) สามารถให้ประสิทธิภาพการสร้างโค้ดที่ยอดเยี่ยมในแพ็คเกจที่เล็กกว่าและยืดหยุ่นกว่า แต่ประสิทธิภาพในงานโค้ดนอกเหนือจากการสร้าง (เช่น การแก้ไขและการอธิบาย) อาจตามหลังประสิทธิภาพการสร้างโค้ด Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 ในบริบทขององค์กรหลายแห่ง การนำ LLMs โค้ดมาใช้งานอาจซับซ้อนยิ่งขึ้นจากปัจจัยนอกเหนือจากประสิทธิภาพของโมเดล ตัวอย่างเช่น แม้แต่โมเดลโอเพนซอร์สบางครั้งก็ขาดความโปร่งใสเกี่ยวกับแหล่งข้อมูลและวิธีการประมวลผลข้อมูลที่ใช้ในการสร้างโมเดล ซึ่งอาจกัดกร่อนความไว้วางใจในโมเดลในบริบทที่สำคัญต่อภารกิจและมีการควบคุมดูแล นอกจากนี้ ข้อกำหนดใบอนุญาตใน LLMs โอเพนซอร์สในปัจจุบันอาจเป็นภาระและทำให้การใช้งานโมเดลขององค์กรมีความซับซ้อน ที่นี่ เรานำเสนอโมเดล Granite Code ซึ่งเป็นซีรีส์ของ LLMs โค้ดที่มีความสามารถสูง ออกแบบมาเพื่อรองรับการพัฒนาซอฟต์แวร์ระดับองค์กรในงานโค้ดที่หลากหลาย โมเดล Granite Code มีสองเวอร์ชันหลักที่เราเผยแพร่ในสี่ขนาดที่แตกต่างกัน (3B, 8B, 20B และ 34B): โมเดลพื้นฐานสำหรับงานที่เกี่ยวข้องกับโค้ด Granite Code Base: โมเดลที่ฝึกฝนคำสั่ง (instruction following) โดยใช้การผสมผสานระหว่าง commit ของ Git ที่จับคู่กับคำแนะนำจากมนุษย์ และชุดข้อมูลคำแนะนำโค้ดที่สร้างขึ้นแบบสังเคราะห์แบบโอเพนซอร์ส Granite Code Instruct: โมเดลพื้นฐานในซีรีส์นี้ได้รับการฝึกฝนตั้งแต่ต้นด้วยกลยุทธ์การฝึกสองเฟส ในเฟสที่ 1 โมเดลของเราได้รับการฝึกฝนด้วยโทเค็น 3 ถึง 4 ล้านล้านโทเค็นที่มาจากภาษาโปรแกรม 116 ภาษา เพื่อให้เข้าใจภาษาโปรแกรมและไวยากรณ์ได้อย่างครอบคลุม ในเฟสที่ 2 โมเดลของเราได้รับการฝึกฝนเพิ่มเติมด้วยโทเค็น 500 พันล้านโทเค็น ด้วยการผสมผสานข้อมูลคุณภาพสูงจากทั้งโค้ดและภาษาธรรมชาติที่ออกแบบมาอย่างดี เพื่อปรับปรุงความสามารถในการให้เหตุผลของโมเดล เราใช้ objective การสร้างแบบจำลองภาษาแบบไม่มีการดูแล (unsupervised language modeling) เพื่อฝึกฝนโมเดลพื้นฐานในทั้งสองเฟสของการฝึก โมเดล instruct ได้รับการสร้างขึ้นโดยการปรับแต่งเพิ่มเติมโมเดลพื้นฐานที่ได้รับการฝึกฝนมาแล้ว โดยใช้การผสมผสานระหว่างเวอร์ชันที่กรองแล้วของ CommitPack ( , ), ชุดข้อมูลการทำตามคำสั่งภาษาธรรมชาติ (OASST ( , ), HelpSteer ( , )) และชุดข้อมูลคณิตศาสตร์โอเพนซอร์ส (MathInstruct ( , ) และ MetaMathQA ( , )) รวมถึงชุดข้อมูลโค้ดที่สร้างขึ้นแบบสังเคราะห์ เพื่อปรับปรุงความสามารถในการทำตามคำสั่งและการให้เหตุผล Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 เราดำเนินการประเมิน LLMs โค้ดของเราอย่างครอบคลุมบนชุดเกณฑ์มาตรฐานที่ครอบคลุม รวมถึง HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ) และอื่นๆ ชุดเกณฑ์มาตรฐานนี้ครอบคลุมงานโค้ดหลายประเภทนอกเหนือจากการสังเคราะห์โค้ดใน Python เช่น การแก้ไขโค้ด การอธิบายโค้ด การแก้ไขโค้ด การแปลโค้ด ฯลฯ ในภาษาโปรแกรมหลักส่วนใหญ่ (Python, JavaScript, Java, Go, C++, Rust ฯลฯ) Muennighoff et al. 2023 Austin et al. 2021 Liu et al. 2023a Liu et al. 2023b Wang et al. 2022 ผลการวิจัยของเราแสดงให้เห็นว่าในบรรดาโมเดลโอเพนซอร์ส โมเดล Granite Code โดยรวมแสดงประสิทธิภาพที่แข็งแกร่งมากในทุกขนาดโมเดลและเกณฑ์มาตรฐาน (มักจะทำได้ดีกว่าโมเดลโค้ดโอเพนซอร์สอื่นๆ ที่มีขนาดใหญ่เป็นสองเท่าเมื่อเทียบกับ Granite) เพื่อเป็นตัวอย่าง รูปที่ (ด้านบน) แสดงการเปรียบเทียบ Granite-8B-Code-Base กับ LLMs โค้ดพื้นฐานโอเพนซอร์สอื่นๆ รวมถึง LLMs พื้นฐานทั่วไปที่มีประสิทธิภาพสูงล่าสุด เช่น Mistral ( , ) และ LLama-3 ( , ) บน HumanEvalPack ( , ) ในขณะที่ CodeGemma และ StarCoder2 ทำงานได้ดีพอสมควรในการสร้างโค้ด แต่ประสิทธิภาพต่ำกว่าอย่างมากในส่วนของการแก้ไขโค้ดและการอธิบายโค้ดของ HumanEvalPack โดยเฉลี่ย Granite-8B-Code-Base มีประสิทธิภาพดีกว่าโมเดล CodeGemma-8B ที่แข่งขันได้มากที่สุดเกือบ 12 จุดบน HumanEvalPack (33.2% เทียบกับ 21.3%) แม้ว่าจะได้รับการฝึกฝนด้วยโทเค็นจำนวนน้อยกว่าอย่างมาก (4.5T เทียบกับ 7.5T โทเค็น) นอกจากโมเดลพื้นฐานแล้ว โมเดล Granite Code ที่ปรับแต่งคำสั่งแล้ว ยังแสดงประสิทธิภาพที่แข็งแกร่งบน HumanEvalPack โดยมีประสิทธิภาพดีกว่า (โค้ด) โมเดลคำสั่งโอเพนซอร์สอื่นๆ ซึ่งแสดงให้เห็นถึงประโยชน์ต่องานโค้ดที่หลากหลายด้วยคำแนะนำภาษาธรรมชาติ (ดูรูปที่ (ด้านล่าง)) 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 นอกจากนี้ เนื่องจากเหตุผลเป็นสิ่งสำคัญสำหรับการแก้ปัญหาและงานที่ซับซ้อน เราจึงทดสอบโมเดล Granite-8B-Code-Base ของเราบนเกณฑ์มาตรฐานคณิตศาสตร์หกรายการ รวมถึง MATH ( , ), GSM8K ( , ) และการแก้ปัญหาด้วยการเข้าถึงเครื่องมือคำนวณ ซึ่งโมเดล Granite 8B ของเราให้ประสิทธิภาพที่ดีกว่า LLMs 7B หรือ 8B ที่ทันสมัยที่สุดส่วนใหญ่ ตัวอย่างเช่น Granite-8B-Code-Base มีประสิทธิภาพดีกว่า Llama-3-8B-Base ประมาณ 12 จุดบน GSM8K และประมาณ 6 จุดบน MATH (ดูตารางที่ ) Cobbe et al. 2021 Cobbe et al. 2021 15 ข้อได้เปรียบหลักของโมเดล Granite Code ได้แก่: : โมเดล Granite Code ได้รับประสิทธิภาพที่แข่งขันได้หรือล้ำสมัยในงานที่เกี่ยวข้องกับโค้ดประเภทต่างๆ รวมถึงการสร้างโค้ด การอธิบาย การแก้ไข การแก้ไขโค้ด การแปล ฯลฯ แสดงให้เห็นถึงความสามารถในการแก้ปัญหางานโค้ดที่หลากหลาย LLM โค้ดที่รอบด้าน : โมเดลทั้งหมดของเราได้รับการฝึกฝนบนข้อมูลที่อนุญาตให้ใช้ใบอนุญาต ซึ่งรวบรวมตามหลักการจริยธรรม AI ของ IBM และได้รับคำแนะนำจากทีมกฎหมายองค์กรของ IBM สำหรับการใช้งานระดับองค์กรที่เชื่อถือได้ โมเดล Granite Code ทั้งหมดจะถูกเผยแพร่ภายใต้ใบอนุญาต Apache 2.0 LLM เกรดองค์กรที่เชื่อถือได้ 1 เราอธิบายไปป์ไลน์การรวบรวม การกรอง และการประมวลผลล่วงหน้าข้อมูลทั้งหมดของเราในส่วน . ส่วน อธิบายรายละเอียดของสถาปัตยกรรมโมเดล ตามด้วยรายละเอียดการฝึกอบรมในส่วนที่ . ส่วนที่ ให้รายละเอียดเกี่ยวกับการปรับแต่งคำสั่ง และส่วนที่ อธิบายการทดลองและผลลัพธ์เปรียบเทียบโมเดล Granite Code กับ LLMs โอเพนซอร์สอื่นๆ 2 3 4 5 6 2 การรวบรวมข้อมูล ในส่วนนี้ เราจะอธิบายกระบวนการรวบรวมและกรอง (ส่วนที่ ), การลบลายซ้ำ (sec. ), การกรอง HAP/PII (sec. ) ที่ใช้ในการเตรียมข้อมูลโค้ดสำหรับการฝึกโมเดล เรายังให้ภาพรวมของข้อมูลภาษาธรรมชาติคุณภาพสูงที่ใช้เพื่อปรับปรุงความเข้าใจภาษาและทักษะการให้เหตุผลทางคณิตศาสตร์ของโมเดล 2.1 2.2 2.3 2.1 การรวบรวมและกรองข้อมูล ข้อมูลโค้ดสำหรับ pretraining ได้รับมาจากชุดข้อมูลสาธารณะเช่น Github Code Clean , StarCoderdata และคลังโค้ดสาธารณะและประเด็นเพิ่มเติมจาก GitHub เรากรองข้อมูลดิบเพื่อเก็บรายชื่อภาษาโปรแกรม 116 ภาษาจากกว่า 300 ภาษา ดังแสดงในภาคผนวก การกำหนดข้อมูลให้กับภาษาโปรแกรมจะดำเนินการตามนามสกุลไฟล์เท่านั้น เช่นเดียวกับ StarCoder ( , ) หลังจากการกรองภาษา เราใช้กฎการกรองที่สำคัญสี่ข้อเพื่อกรองโค้ดคุณภาพต่ำ ( , ): (1) ลบไฟล์ที่มีอักขระตัวอักษรน้อยกว่า 25% (2) ยกเว้นภาษา XSLT ให้กรองไฟล์ที่สตริง “<?xml version=” ปรากฏภายใน 100 อักขระแรก (3) สำหรับไฟล์ HTML ให้เก็บเฉพาะไฟล์ที่มีข้อความที่มองเห็นได้คิดเป็นอย่างน้อย 20% ของโค้ด HTML และมีความยาวขั้นต่ำ 100 อักขระ (4) สำหรับไฟล์ JSON และ YAML ให้เก็บเฉพาะไฟล์ที่มีจำนวนอักขระตั้งแต่ 50 ถึง 5000 ตัวอักษร เรายังกรองประเด็น GitHub โดยใช้ชุดเมตริกคุณภาพซึ่งรวมถึงการลบข้อความที่สร้างขึ้นโดยอัตโนมัติ การกรองประเด็นที่ไม่ใช่ภาษาอังกฤษ การยกเว้นความคิดเห็นจากบอท และการใช้จำนวนผู้เข้าร่วมในการสนทนาเป็นตัวบ่งชี้คุณภาพ เรายังใส่คำอธิบายประกอบไฟล์โค้ดแต่ละไฟล์พร้อมข้อมูลใบอนุญาตที่เกี่ยวข้องกับคลังเก็บนั้นๆ ซึ่งค้นหาได้ผ่าน GitHub API และเก็บเฉพาะไฟล์ที่มีใบอนุญาตที่อนุญาตสำหรับการฝึกโมเดล 2 3 A Li et al. 2023a Li et al. 2023a 2.2 การลบลายซ้ำแบบตรงและแบบคลุมเครือ เราใช้กลยุทธ์การลบลายซ้ำที่เข้มงวด รวมถึงการลบลายซ้ำทั้งแบบตรงและแบบคลุมเครือ เพื่อลบเอกสารที่มีเนื้อหาโค้ด (ใกล้เคียง) เหมือนกันในชุดฝึกของเรา สำหรับการลบลายซ้ำแบบตรง เราจะคำนวณแฮช SHA256 บนเนื้อหาเอกสารก่อน แล้วจึงลบรายการที่มีแฮชเหมือนกัน หลังจากการลบลายซ้ำแบบตรง เราจะใช้การลบลายซ้ำแบบคลุมเครือ โดยมีเป้าหมายเพื่อลบไฟล์โค้ดที่มีความแตกต่างเล็กน้อยและทำให้ข้อมูลมีความเป็นกลางมากขึ้น เราใช้วิธีการสองขั้นตอนสำหรับสิ่งนี้: (1) คำนวณ MinHashes ของเอกสารทั้งหมด จากนั้นใช้ Locally Sensitive Hashing (LSH) เพื่อจัดกลุ่มเอกสารตามลายนิ้วมือ MinHash ของเอกสาร (2) วัดความคล้ายคลึง Jaccard ระหว่างแต่ละคู่ของเอกสารในกลุ่มเดียวกัน และใส่คำอธิบายประกอบเอกสารยกเว้นหนึ่งรายการว่าเป็นรายการที่ซ้ำกันตามเกณฑ์ความคล้ายคลึง 0.7 เราใช้กระบวนการลบลายซ้ำใกล้เคียงนี้กับทุกภาษาโปรแกรม รวมถึงประเด็น GitHub เพื่อเพิ่มความสมบูรณ์และความหลากหลายของชุดข้อมูลฝึก 2.3 การกรอง HAP, PII, Malware เพื่อลดโอกาสในการสร้างภาษาที่แสดงความเกลียดชัง การล่วงละเมิด หรือการสบประมาท (HAP) จากโมเดล เราได้ใช้ความพยายามอย่างเต็มที่เพื่อกรองเนื้อหา HAP ออกจากชุดฝึก เราสร้างพจนานุกรมของคำหลัก HAP ก่อน จากนั้นจึงใส่คำอธิบายประกอบเอกสารโค้ดแต่ละฉบับด้วยจำนวนครั้งที่พบคำหลักดังกล่าวในเนื้อหา รวมถึงความคิดเห็น เรากรองเอกสารที่เกินเกณฑ์ HAP ซึ่งคำนวณจากการวิเคราะห์การกระจาย และการตรวจสอบด้วยตนเองของไฟล์โค้ด นอกจากนี้ เพื่อปกป้องความเป็นส่วนตัว เราปฏิบัติตาม StarCoder ( , ) และใช้ความพยายามอย่างเต็มที่ในการลบข้อมูลที่ระบุตัวตนได้ (PII) ออกจากชุดฝึก โดยเฉพาะอย่างยิ่ง เราใช้โมเดล StarPII เพื่อตรวจจับที่อยู่ IP, คีย์, ที่อยู่อีเมล, ชื่อ, ชื่อผู้ใช้ และรหัสผ่านที่พบในเนื้อหา ขั้นตอนการลบ PII จะแทนที่ข้อความ PII ด้วยโทเค็น NAME , EMAIL , KEY , PASSWORD ที่สอดคล้องกัน และเปลี่ยนที่อยู่ IP ด้วยที่อยู่ IP ที่สร้างขึ้นแบบสังเคราะห์ เช่นเดียวกับใน Li et al. (2023a) เรายังสแกนชุดข้อมูลของเราเพื่อระบุและลบมัลแวร์ในซอร์สโค้ด Li et al. 2023a 4 2.4 ชุดข้อมูลภาษาธรรมชาติ นอกเหนือจากการรวบรวมข้อมูลโค้ดสำหรับการฝึกโมเดลแล้ว เรายังได้รวบรวมชุดข้อมูลภาษาธรรมชาติคุณภาพสูงที่มีอยู่มากมาย เพื่อปรับปรุงความสามารถของโมเดลในการทำความเข้าใจภาษาและการให้เหตุผลทางคณิตศาสตร์ ชุดข้อมูลที่เป็นตัวแทนภายใต้หมวดหมู่นี้ ได้แก่ เอกสารเว็บ (Stackexchange, CommonCrawl), ข้อความเว็บคณิตศาสตร์ (OpenWeb-Math; ( ), StackMathQA; ( )), ข้อความทางวิชาการ (Arxiv, Wikipedia) และชุดข้อมูลการปรับแต่งคำสั่ง (FLAN; ( ), HelpSteer ( , )) เราไม่ลบลายซ้ำชุดข้อมูลภาษาธรรมชาติที่ประมวลผลล่วงหน้าเหล่านี้ Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 สถาปัตยกรรมโมเดล เราฝึกโมเดลโค้ดซีรีส์ที่มีขนาดต่างกัน โดยอิงตามสถาปัตยกรรม transformer decoder ( , ) ไฮเปอร์พารามิเตอร์ของโมเดลสำหรับโมเดลเหล่านี้แสดงอยู่ในตารางที่ สำหรับสถาปัตยกรรมโมเดลทั้งหมด เราใช้ pre-normalization ( , ): การ normalize ที่ใช้กับอินพุตของ attention และ MLP blocks Vaswani et al. 2017 1 Xiong et al. 2020 : โมเดลที่เล็กที่สุดในตระกูลโมเดล Granite-code ได้รับการฝึกฝนด้วย RoPE embedding ( , ) และ Multi-Head Attention ( , ) โมเดลนี้ใช้ swish activation function ( , ) พร้อม GLU ( , ) สำหรับ MLP ซึ่งมักเรียกว่า swiglu สำหรับ normalization เราใช้ RMSNorm ( , ) เนื่องจากมีประสิทธิภาพมากกว่า LayerNorm ( , ) ในเชิงคำนวณ โมเดล 3B ได้รับการฝึกฝนด้วย context length 2048 โทเค็น 3B Su et al. 2023 Vaswani et al. 2017 Ramachandran et al. 2017 Shazeer 2020 Zhang & Sennrich 2019 Ba et al. 2016 : โมเดล 8B มีสถาปัตยกรรมคล้ายกับโมเดล 3B ยกเว้นการใช้ Grouped-Query Attention (GQA) ( , ) การใช้ GQA ให้ trade-off ที่ดีกว่าระหว่างประสิทธิภาพโมเดลและการอนุมานที่มีประสิทธิภาพในขนาดนี้ เราฝึกโมเดล 8B ด้วย context length 4096 โทเค็น 8B Ainslie et al. 2023 : โมเดลโค้ด 20B ได้รับการฝึกฝนด้วย learned absolute position embeddings เราใช้ Multi-Query Attention ( , ) ระหว่างการฝึกเพื่อการอนุมาน downstream ที่มีประสิทธิภาพ สำหรับ MLP block เราใช้ GELU activation function ( , ) สำหรับการ normalize activations เราใช้ LayerNorm ( , ) โมเดลนี้ได้รับการฝึกฝนด้วย context length 8192 โทเค็น 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : เพื่อฝึกโมเดล 34B เราปฏิบัติตามแนวทางของ สำหรับการเพิ่มความลึกของโมเดล 20B โดยเฉพาะอย่างยิ่ง เราจะทำซ้ำโมเดลโค้ด 20B ที่มี 52 เลเยอร์ก่อน จากนั้นจึงลบ 8 เลเยอร์สุดท้ายออกจากโมเดลเดิมและ 8 เลเยอร์แรกออกจากสำเนาเพื่อสร้างสองโมเดล 34B Kim et al. สุดท้าย เราจะเชื่อมต่อทั้งสองโมเดลเพื่อสร้างโมเดล Granite-34B-Code ที่มี 88 เลเยอร์ (ดูรูปที่ สำหรับภาพประกอบ) หลังจากการเพิ่มความลึก เราสังเกตว่าการลดลงของประสิทธิภาพเมื่อเทียบกับโมเดล 20B นั้นเล็กน้อย ซึ่งตรงข้ามกับสิ่งที่สังเกตได้โดย ประสิทธิภาพนี้ได้รับการฟื้นฟูค่อนข้างเร็วหลังจากเราดำเนินการ pretraining ต่อของโมเดล 34B ที่เพิ่มขนาดขึ้น เช่นเดียวกับ 20B เราใช้ context 8192 โทเค็นในการ pretraining 2 Kim et al. 4 การฝึกเบื้องต้น (Pretraining) ในส่วนนี้ เราให้รายละเอียดเกี่ยวกับการฝึกสองเฟส (ส่วนที่ ), objectives การฝึก (ส่วนที่ ), การปรับแต่ง (optimization) (ส่วนที่ ) และโครงสร้างพื้นฐาน (infrastructure) (ส่วนที่ ) ที่ใช้ในการฝึกโมเดลเบื้องต้น 4.1 4.2 4.3 4.4 4.1 การฝึกสองเฟส โมเดล Granite Code ได้รับการฝึกฝนด้วยข้อมูลโค้ด 3.5T ถึง 4.5T โทเค็น และชุดข้อมูลภาษาธรรมชาติที่เกี่ยวข้องกับโค้ด ข้อมูลถูก tokenize ผ่าน byte pair encoding (BPE, ( , )) โดยใช้ tokenizer เดียวกันกับ StarCoder ( , ) ตาม ( , ; , ) เราใช้ข้อมูลคุณภาพสูงที่มีสองเฟสของการฝึกดังนี้ Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : ในระหว่างเฟส 1 ทั้งโมเดล 3B และ 8B ได้รับการฝึกฝนด้วยข้อมูลโค้ด 4 ล้านล้านโทเค็น ซึ่งประกอบด้วย 116 ภาษา โมเดลพารามิเตอร์ 20B ได้รับการฝึกฝนด้วยโค้ด 3 ล้านล้านโทเค็น โมเดล 34B ได้รับการฝึกฝนด้วยโทเค็น 1.4T หลังจากการเพิ่มขนาดความลึก ซึ่งดำเนินการบน checkpoint 1.6T ของโมเดล 20B เฟส 1 (การฝึกเฉพาะโค้ด) • : ในเฟส 2 เราได้รวมข้อมูลคุณภาพสูงที่มีอยู่สาธารณะเพิ่มเติมจากโดเมนต่างๆ รวมถึงเอกสารทางเทคนิค คณิตศาสตร์ และเว็บ เพื่อปรับปรุงประสิทธิภาพของโมเดลในการให้เหตุผลและทักษะการแก้ปัญหา ซึ่งจำเป็นต่อการสร้างโค้ด เราฝึกโมเดลทั้งหมดของเราด้วยโทเค็น 500 พันล้านโทเค็น (80% โค้ดและ 20% ภาษา) ในเฟส 2 ของการฝึก เฟส 2 (การฝึกโค้ด + ภาษา) 4.2 Training Objective สำหรับการฝึกโมเดลทั้งหมดของเรา เราใช้ causal language modeling objective และ Fill-In-the-Middle (FIM) ( , ) objective FIM objective มีหน้าที่ทำนายโทเค็นที่แทรกเข้ามาพร้อมกับบริบทและข้อความที่ตามมา เราฝึกโมเดลของเราให้ทำงานกับทั้งโหมด PSM (Prefix-Suffix-Middle) และ SPM (Suffix-Prefix-Middle) พร้อมด้วย control tokens รูปแบบที่เกี่ยวข้อง เช่นเดียวกับ StarCoder ( , ) Bavarian et al. 2022 Li et al. 2023a loss โดยรวมคำนวณจากผลรวมถ่วงน้ำหนักของ 2 objectives: เราตั้งค่า = 0.5 ในการทดลองระหว่างการฝึก และพบว่าวิธีนี้ได้ผลดีในทางปฏิบัติ ทำให้ได้ประสิทธิภาพ SOTA ทั้งในงาน code completion และ code infilling ควรสังเกตว่า FIM objective ใช้เฉพาะในการ pretraining เท่านั้น แต่เราจะยกเลิกในการ fine-tuning คำสั่ง นั่นคือ ตั้งค่า = 1 α α 4.3 การปรับแต่ง
