ผู้เขียน: 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 บทคัดย่อ โมเดลภาษาขนาดใหญ่ (LLMs) ที่ได้รับการฝึกฝนเกี่ยวกับโค้ดกำลังปฏิวัติกระบวนการพัฒนาซอฟต์แวร์ LLMs ที่เกี่ยวกับโค้ดกำลังถูกรวมเข้ากับสภาพแวดล้อมการพัฒนาซอฟต์แวร์มากขึ้นเรื่อยๆ เพื่อปรับปรุงประสิทธิภาพของโปรแกรมเมอร์มนุษย์ และตัวแทนที่ใช้ LLM กำลังเริ่มแสดงให้เห็นถึงศักยภาพในการจัดการงานที่ซับซ้อนโดยอัตโนมัติ การตระหนักถึงศักยภาพเต็มที่ของ code LLMs จำเป็นต้องมีความสามารถที่หลากหลาย รวมถึงการสร้างโค้ด การแก้ไขข้อบกพร่อง การอธิบายและจัดทำเอกสารโค้ด การดูแลรักษาคลังเก็บโค้ด และอื่นๆ ในงานนี้ เราขอแนะนำซีรีส์ Granite ของโมเดลโค้ดแบบ decoder-only สำหรับงานสร้างโค้ด ซึ่งได้รับการฝึกฝนด้วยโค้ดที่เขียนด้วยภาษาโปรแกรม 116 ภาษา ตระกูลโมเดล Granite Code ประกอบด้วยโมเดลที่มีขนาดตั้งแต่ 3 ถึง 34 พันล้านพารามิเตอร์ เหมาะสำหรับการใช้งานที่หลากหลายตั้งแต่การปรับปรุงแอปพลิเคชันที่ซับซ้อนไปจนถึงกรณีการใช้งานที่ต้องการหน่วยความจำบนอุปกรณ์ การประเมินในชุดงานที่ครอบคลุมแสดงให้เห็นว่าโมเดล Granite Code ให้ประสิทธิภาพที่ทันสมัยอย่างสม่ำเสมอในบรรดา code LLMs โอเพนซอร์สที่มีอยู่ ตระกูลโมเดล Granite Code ได้รับการปรับให้เหมาะสมสำหรับเวิร์กโฟลว์การพัฒนาซอฟต์แวร์ระดับองค์กร และทำงานได้ดีในงานการเขียนโค้ดหลากหลายประเภท (เช่น การสร้างโค้ด การแก้ไข และการอธิบาย) ทำให้เป็น code model ที่หลากหลายแบบ "รอบด้าน" เราเผยแพร่โมเดล 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)) อย่างไรก็ตาม ยังคงมีช่องว่างที่สำคัญในสาขา code LLMs ในปัจจุบัน โดยเฉพาะอย่างยิ่งในบริบทของการพัฒนาซอฟต์แวร์ระดับองค์กร ประการแรก แม้ว่า LLMs ทั่วไปที่มีขนาดใหญ่มากจะสามารถให้ประสิทธิภาพในการเขียนโค้ดที่ยอดเยี่ยมได้ แต่ขนาดของโมเดลก็ทำให้มีค่าใช้จ่ายสูงในการใช้งาน โมเดลที่เน้นโค้ดขนาดเล็ก ( , ; , ; , ; , ; , ) สามารถให้ประสิทธิภาพการสร้างโค้ดที่ยอดเยี่ยมในแพ็คเกจที่เล็กกว่าและยืดหยุ่นกว่า แต่ประสิทธิภาพในงานการเขียนโค้ดนอกเหนือจากการสร้าง (เช่น การแก้ไขและการอธิบาย) อาจตามหลังประสิทธิภาพการสร้างโค้ด Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 ในหลายบริบทขององค์กร การนำ code LLM มาใช้งานอาจซับซ้อนยิ่งขึ้นจากปัจจัยนอกเหนือจากประสิทธิภาพของโมเดล ตัวอย่างเช่น แม้แต่โมเดลโอเพนซอร์สบางครั้งก็ขาดความโปร่งใสเกี่ยวกับแหล่งข้อมูลและวิธีการประมวลผลข้อมูลที่ใช้ในโมเดล ซึ่งอาจบั่นทอนความเชื่อมั่นในโมเดลในบริบทที่สำคัญต่อภารกิจและถูกควบคุม นอกจากนี้ เงื่อนไขใบอนุญาตใน LLMs โอเพนซอร์สปัจจุบันอาจเป็นอุปสรรคและทำให้องค์กรใช้งานโมเดลได้ยากขึ้น ในที่นี้ เรานำเสนอโมเดล Granite Code ซึ่งเป็นชุดของ code LLMs ที่มีความสามารถสูง ออกแบบมาเพื่อสนับสนุนการพัฒนาซอฟต์แวร์ระดับองค์กรในงานการเขียนโค้ดที่หลากหลาย โมเดล Granite Code มีสองรูปแบบหลักที่เราเผยแพร่ในสี่ขนาด (3B, 8B, 20B และ 34B): โมเดลพื้นฐานสำหรับงานที่เกี่ยวข้องกับโค้ด Granite Code Base: โมเดลที่ปรับแต่งตามคำสั่ง (instruction following) โดยใช้การผสมผสานระหว่าง Git commits ที่จับคู่กับคำแนะนำจากมนุษย์และชุดข้อมูลคำสั่งโค้ดสังเคราะห์แบบโอเพนซอร์ส Granite Code Instruct: โมเดลพื้นฐานในซีรีส์นี้ได้รับการฝึกฝนตั้งแต่ต้นด้วยกลยุทธ์การฝึกสองระยะ ในระยะที่ 1 โมเดลของเราได้รับการฝึกฝนด้วยโทเค็น 3 ถึง 4 ล้านล้านโทเค็นที่มาจากภาษาโปรแกรม 116 ภาษา เพื่อให้เข้าใจภาษาโปรแกรมและไวยากรณ์ได้อย่างครอบคลุม ในระยะที่ 2 โมเดลของเราได้รับการฝึกฝนเพิ่มเติมด้วยโทเค็น 500 พันล้านโทเค็นด้วยการผสมผสานข้อมูลคุณภาพสูงจากโดเมนโค้ดและภาษาธรรมชาติที่ออกแบบมาอย่างดี เพื่อปรับปรุงความสามารถในการให้เหตุผลของโมเดล เราใช้การเรียนรู้ภาษาแบบไม่มีผู้สอน (unsupervised language modeling objective) เพื่อฝึกโมเดลพื้นฐานในทั้งสองระยะของการฝึก โมเดล instruct ได้รับการปรับแต่งเพิ่มเติมโดยการ fine-tuning โมเดลพื้นฐานที่ฝึกแล้วด้วยการผสมผสานระหว่าง 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 เราดำเนินการประเมิน code 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 โดยรวมแสดงประสิทธิภาพที่แข็งแกร่งมากในทุกขนาดโมเดลและเกณฑ์มาตรฐาน (มักจะทำผลงานได้ดีกว่า code โมเดลโอเพนซอร์สอื่นๆ ที่มีขนาดใหญ่กว่า Granite ถึงสองเท่า) เพื่อเป็นตัวอย่าง รูปที่ (ด้านบน) แสดงการเปรียบเทียบ Granite-8B-Code-Base กับ code 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 โดยให้ผลงานที่ดีกว่าโมเดล instruct โอเพนซอร์ส (โค้ด) อื่นๆ ซึ่งแสดงให้เห็นถึงประโยชน์สำหรับงานการเขียนโค้ดที่หลากหลายพร้อมคำแนะนำภาษาธรรมชาติ (ดูรูปที่ (ด้านล่าง)) 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 ให้ประสิทธิภาพที่แข่งขันได้หรือทันสมัยในงานที่เกี่ยวข้องกับโค้ดประเภทต่างๆ รวมถึงการสร้างโค้ด การอธิบาย การแก้ไข การแก้ไขโค้ด การแปลงโค้ด ฯลฯ แสดงให้เห็นถึงความสามารถในการแก้ปัญหาการเขียนโค้ดที่หลากหลาย Code LLM ที่รอบด้าน : โมเดลทั้งหมดของเราได้รับการฝึกฝนจากข้อมูลที่ได้รับอนุญาตภายใต้ใบอนุญาต ซึ่งรวบรวมตามหลักการ AI Ethics ของ IBM และได้รับการชี้นำโดยทีมกฎหมายของ IBM สำหรับการใช้งานในองค์กรที่เชื่อถือได้ โมเดล Granite Code ทั้งหมดจะถูกเผยแพร่ภายใต้ใบอนุญาต Apache 2.0 LLM ที่เชื่อถือได้สำหรับระดับองค์กร 1 เราจะอธิบายกระบวนการรวบรวมข้อมูล การกรอง และการประมวลผลล่วงหน้าทั้งหมดของเราในส่วน . ส่วน อธิบายรายละเอียดเกี่ยวกับสถาปัตยกรรมโมเดล ตามด้วยรายละเอียดการฝึกในส่วนที่ . ส่วน ให้รายละเอียดเกี่ยวกับการปรับแต่งตามคำสั่ง และส่วนที่ อธิบายการทดลองและผลลัพธ์ที่เปรียบเทียบโมเดล Granite Code กับ LLMs โอเพนซอร์สอื่นๆ 2 3 4 5 6 2 การรวบรวมข้อมูล ในส่วนนี้ เราจะอธิบายกระบวนการรวบรวมและกรองข้อมูล (ส่วนที่ ), การขจัดข้อมูลซ้ำ (ส่วนที่ ), การกรอง HAP/PII (ส่วนที่ ) ที่ใช้ในการเตรียมข้อมูลโค้ดสำหรับการฝึกโมเดล นอกจากนี้ เรายังให้ภาพรวมของข้อมูลภาษาธรรมชาติคุณภาพสูงที่ใช้เพื่อเพิ่มความเข้าใจภาษาและทักษะการให้เหตุผลทางคณิตศาสตร์ของโมเดล 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 APIs และเก็บเฉพาะไฟล์ที่มีใบอนุญาตที่อนุญาตสำหรับการฝึกโมเดล 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, มัลแวร์ เพื่อลดโอกาสในการสร้างภาษาแสดงความเกลียดชัง การล่วงละเมิด หรือภาษาหยาบคาย (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 ( , ): การทำให้เป็นปกติที่ใช้กับอินพุตของบล็อก attention และ MLP Vaswani et al. 2017 1 Xiong et al. 2020 : โมเดลที่เล็กที่สุดในตระกูล Granite-code ได้รับการฝึกฝนด้วย RoPE embedding ( , ) และ Multi-Head Attention ( , ) โมเดลนี้ใช้ฟังก์ชันการเปิดใช้งาน swish ( , ) กับ GLU ( , ) สำหรับ MLP ซึ่งมักเรียกกันว่า swiglu สำหรับการทำให้เป็นปกติ เราใช้ RMSNorm ( , ) เนื่องจากมีประสิทธิภาพในการคำนวณมากกว่า LayerNorm ( , ) โมเดล 3B ได้รับการฝึกฝนด้วยความยาวบริบท 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 ให้การแลกเปลี่ยนที่ดีกว่าระหว่างประสิทธิภาพของโมเดลและประสิทธิภาพในการอนุมานในขนาดนี้ เราฝึกโมเดล 8B ด้วยความยาวบริบท 4096 โทเค็น 8B Ainslie et al. 2023 : โมเดลโค้ด 20B ได้รับการฝึกฝนด้วย learned absolute position embeddings เราใช้ Multi-Query Attention ( , ) ระหว่างการฝึกเพื่อประสิทธิภาพในการอนุมานในภายหลัง สำหรับบล็อก MLP เราใช้ฟังก์ชันการเปิดใช้งาน GELU ( , ) สำหรับการทำให้ค่าที่เปิดใช้งานเป็นปกติ เราใช้ LayerNorm ( , ) โมเดลนี้ได้รับการฝึกฝนด้วยความยาวบริบท 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 ซึ่งตรงข้ามกับสิ่งที่สังเกตได้โดย ประสิทธิภาพนี้ได้รับการกู้คืนอย่างรวดเร็วหลังจากที่เราฝึกโมเดล 34B ที่เพิ่มขนาดต่อ คล้ายกับโมเดล 20B เราใช้บริบท 8192 โทเค็นระหว่างการฝึก 2 Kim et al. 4 การฝึกเบื้องต้น (Pretraining) ในส่วนนี้ เราให้รายละเอียดเกี่ยวกับการฝึกสองระยะ (ส่วนที่ ), วัตถุประสงค์การฝึก (ส่วนที่ ), การปรับให้เหมาะสม (ส่วนที่ ) และโครงสร้างพื้นฐาน (ส่วนที่ ) ที่ใช้ในการฝึกโมเดลเบื้องต้น 4.1 4.2 4.3 4.4 4.1 การฝึกสองระยะ โมเดล Granite Code ได้รับการฝึกฝนด้วยข้อมูลโค้ด 3.5T ถึง 4.5T โทเค็น และชุดข้อมูลภาษาธรรมชาติที่เกี่ยวข้องกับโค้ด ข้อมูลจะถูกแปลงเป็นโทเค็นผ่าน 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 เราได้รวมข้อมูลสาธารณะคุณภาพสูงเพิ่มเติมจากหลากหลายโดเมน รวมถึงเอกสารทางเทคนิค คณิตศาสตร์ และเว็บ เพื่อปรับปรุงประสิทธิภาพของโมเดลในการให้เหตุผลและทักษะการแก้ปัญหา ซึ่งจำเป็นสำหรับการสร้างโค้ด เราฝึกโมเดลทั้งหมดของเราด้วย 500B โทเค็น (80% โค้ดและ 20% ข้อมูลภาษา) ในการฝึกระยะที่ 2 ระยะที่ 2 (การฝึกโค้ด + ภาษา) 4.2 วัตถุประสงค์การฝึก สำหรับการฝึกโมเดลทั้งหมดของเรา เราใช้ causal language modeling objective และ Fill-In-the-Middle (FIM) ( , ) objective วัตถุประสงค์ FIM มีหน้าที่ทำนายโทเค็นที่แทรกเข้าไปพร้อมกับบริบทที่กำหนดและข้อความที่ตามมา เราฝึกโมเดลของเราให้ทำงานกับทั้งโหมด PSM (Prefix-Suffix-Middle) และ SPM (Suffix-Prefix-Middle) โดยใช้โทเค็นควบคุมการจัดรูปแบบที่เกี่ยวข้อง เช่นเดียวกับ StarCoder ( , ) Bavarian et al. 2022 Li et al. 2023a โดยรวมแล้ว Loss จะคำนวณเป็นผลรวมถ่วงน้ำหนักของ 2 วัตถุประสงค์: เราตั้งค่า = 0.5 ในระหว่างการฝึก และพบว่าค่านี้ทำงานได้ดีในทางปฏิบัติ ทำให้ได้ประสิทธิภาพ SOTA ทั้งในงาน code completion และ code infilling ควรสังเกตว่าวัตถุประสงค์ FIM จะใช้เฉพาะในการฝึกเบื้องต้นเท่านั้น อย่างไรก็ตาม เราจะยกเลิกการใช้งานในการ fine-tuning ตามคำสั่ง กล่าวคือ เราตั้งค่า = 1 α α 4.3 การปรับให้เหมาะสม เราใช้นักปรับให้เหมาะสม AdamW ([Kingma & Ba](#_bookmark80),(#_bookmark80)) โดยมี β1 = 0.9, β2 = 0.95 และ
