จากการเลือกโมเดลเอง สู่ระบบจัดเส้นทางตามงาน
GitHub Copilot Fusion คือระบบจัดเส้นทางและประสานการทำงานของโมเดลปัญญาประดิษฐ์หลายตัว โดยประเมินบริบทของงานพัฒนาซอฟต์แวร์แล้วเลือกรูปแบบการทำงานที่เหมาะสมแทนการบังคับให้นักพัฒนาเลือกโมเดลเดิมด้วยตนเอง ระบบนี้เปิดให้ใช้งานทั่วไปเมื่อ 28 ตุลาคม 2026 โดยพัฒนาต่อจาก Project HydraFusion และรวมความสามารถเลือกโมเดลอัตโนมัติเข้ากับการจัดการโมเดลเบื้องหลัง แก่นสำคัญไม่ใช่การเพิ่มตัวเลือกในเมนู แต่คือการให้ระบบตัดสินใจว่าเอเจนต์เขียนโค้ดควรใช้โมเดลใด และควรให้โมเดลเหล่านั้นทำงานร่วมกันอย่างไร สำหรับผู้ใช้ทั่วไป นี่ช่วยลดการสลับโมเดลไปมาระหว่างงาน และอาจทำให้การใช้ AI เขียนโค้ดลื่นไหลขึ้น พร้อมช่วยควบคุมค่าใช้จ่าย โดยคิดตามการใช้งานของโมเดลที่เรียกใช้จริงและไม่มีค่าบริการ Fusion เพิ่มต่างหาก
สามวิธีทำงาน เพื่อให้เหมาะกับงานคนละแบบ
Fusion ไม่ได้ยึดติดกับโมเดลตัวเดียว แต่เลือกวิธีประมวลผลตามลักษณะงานและระดับความพยายามที่ผู้ใช้กำหนด ได้แก่ Standard, High และ Max รูปแบบ Single ให้โมเดลเดียวจัดการตั้งแต่ต้นจนจบ จึงเหมาะกับงานที่ไม่จำเป็นต้องมีหลายด่านตรวจ ส่วน Cascade เริ่มจากโมเดลที่ประหยัดกว่าเพื่อร่างคำตอบ แล้วให้ระบบตรวจว่าจำเป็นต้องส่งต่อไปยังโมเดลที่เก่งขึ้นหรือไม่ สำหรับ Critique โมเดลหนึ่งสร้างคำตอบ โมเดลอีกตัวช่วยรีวิว ก่อนให้ตัวแรกปรับแก้ แนวทางนี้มีเหตุผลกว่าการเรียกโมเดลที่ทรงพลังที่สุดกับทุกคำสั่ง เพราะงานแก้โค้ดเล็กน้อยกับงานซับซ้อนต้องการทรัพยากรไม่เท่ากัน อย่างไรก็ดี ความสะดวกแลกมากับการมองเห็นกระบวนการน้อยลง ผู้ใช้จึงอาจไม่รู้ล่วงหน้าว่าแต่ละงานจะถูกส่งให้โมเดลใด
ระบบเปิดให้ใช้ใน Visual Studio Code, แอป GitHub Copilot, Copilot CLI และสภาพแวดล้อมพัฒนา JetBrains ผู้ดูแลองค์กรยังควบคุมรายชื่อโมเดลที่อนุญาตได้ ทำให้การเลือกอัตโนมัติไม่ได้แปลว่าองค์กรต้องเปิดทางให้ทุกโมเดลโดยไม่มีข้อจำกัด
คะแนนน่าสนใจ แต่ยังไม่ใช่คำตอบแทนการทดสอบ
ผลทดสอบภายนอกที่ถูกรายงานชี้ว่า Fusion ระดับ Max ทำคะแนน 60 บน Coding Agent Index ใน Copilot CLI ใกล้กับ Claude Code ที่ใช้ Opus 5.5 ซึ่งได้ 62 แต่ตัวเลขคะแนนเพียงอย่างเดียวไม่ควรกลบข้อจำกัดของการทดสอบ เมื่อแยกตามชุดทดสอบ Fusion ได้ 71 ใน Terminal-Bench 4.0, 51 ใน FrontierCode ซึ่งเป็นอันดับสาม และ 57 ใน SWE-Atlas-QnA-AA โดยคะแนนเหล่านี้สะท้อนงานตามเกณฑ์ของชุดทดสอบ ไม่ได้รับประกันว่าจะทำงานได้ดีเท่ากันในทุกโค้ดเบสหรือทุกเวิร์กโฟลว์ ตัวเลขต้นทุนที่รายงานก็ไม่ควรนำมาใช้เป็นคำมั่นสำหรับผู้ใช้ทุกคน เพราะขึ้นกับโมเดลที่ถูกเลือก ปริมาณงาน และเงื่อนไขการทดสอบ อีกทั้งมีส่วนลดชั่วคราวที่อาจเปลี่ยนแปลงได้ จึงควรมองผลดังกล่าวเป็นสัญญาณให้น่าทดลอง ไม่ใช่เหตุผลให้เปลี่ยนระบบทั้งองค์กรทันที
ประเด็นที่ควรจับตาจึงไม่ใช่แค่ว่าโมเดลใดได้คะแนนสูงสุด แต่คือระบบจัดเส้นทางเลือกเครื่องมือได้คุ้มและเหมาะกับงานจริงเพียงใด สำหรับทีมพัฒนา การตัดสินใจใช้ Fusion ควรอิงผลลัพธ์ในคลังโค้ดและขั้นตอนทำงานของตน ไม่ใช่คะแนนมาตรฐานเพียงชุดเดียว
ทดลองก่อนตั้งเป็นค่าเริ่มต้น
ข้อเสนอที่รอบคอบคือทดลองใช้กับงานจริงประมาณสองสัปดาห์ แล้วเปรียบเทียบค่าใช้จ่ายกับอัตราคำขอเปลี่ยนแปลงโค้ดที่ผ่านการรีวิว ก่อนตั้ง Fusion เป็นค่าเริ่มต้นให้ทั้งองค์กร การประเมินควรครอบคลุมทั้งงานทั่วไป งานแก้บั๊ก และงานซับซ้อน เพื่อดูว่าการเลือกโมเดลอัตโนมัติช่วยลดเวลาหรือเพิ่มภาระตรวจทานในกรณีใดบ้าง นอกจากนี้ควรตรวจนโยบายข้อมูลและกำหนดให้ชัดว่างานส่งไปยังโมเดลจากผู้ให้บริการรายใดได้ โดยเฉพาะเมื่อเงื่อนไขส่วนลดชั่วคราวสิ้นสุดลง สรุปแล้ว GitHub Copilot Fusion เป็นพัฒนาการที่มีประโยชน์ เพราะเปลี่ยนภาระจากการเลือกโมเดลทุกครั้งมาเป็นการจัดเส้นทางให้เหมาะกับงาน แต่คุณค่าที่แท้จริงจะตัดสินได้จากคุณภาพโค้ด ค่าใช้จ่าย และความสอดคล้องกับข้อกำหนดของแต่ละทีมเท่านั้น
