การขยายขอบเขตของวัตถุวิวัฒนาการ จากพารามิเตอร์เชิงตัวเลขสู่ระบบซอฟต์แวร์

ในการปฏิบัติช่วงเริ่มต้นของการคำนวณเชิงวิวัฒนาการ สิ่งที่ถูก "วิวัฒนาการ" แทบทั้งหมดคือพารามิเตอร์เชิงตัวเลข— อัตราการเรียนรู้ ขนาดแบตช์ ความเข้มของการทำ regularization วิธีการตั้งค่าเริ่มต้นของน้ำหนัก พื้นที่การค้นหาก็คือกลุ่มตัวเลข ส่วนการประเมินผลก็คือการฝึกหนึ่งครั้งบวกการตรวจสอบหนึ่งครั้ง เมื่อพลังประมวลผลเพิ่มขึ้นและความสามารถของโมเดลขนาดใหญ่เติบโตเต็มที่ วัตถุที่สามารถวิวัฒนาการได้ก็ขยายออกไปอย่างชัดเจน ทั้งโปรแกรม โครงสร้างโมเดล กลไกอัลกอริทึม ไปจนถึงสถานะทางวิศวกรรมซอฟต์แวร์ทั้งชุด (การตั้งค่า เวอร์ชันของ dependencies สัญญาส่วนติดต่อ และกลยุทธ์การดีพลอยและการทำงาน)

เส้นทางการขยายนี้สามารถแสดงด้วยสายลูกศรที่ชัดเจนได้ว่า พารามิเตอร์เชิงตัวเลข → โปรแกรมและโครงสร้างโมเดล → สถานะทางวิศวกรรมซอฟต์แวร์และตัวเลือกในระดับระบบ ยิ่งอยู่ทางขวามากเท่าไร ความสามารถในการแสดงออกก็ยิ่งสูงขึ้น ครอบคลุมประเภทการเปลี่ยนแปลงได้มากขึ้น และทำให้วิวัฒนาการระดับระบบเป็นไปได้

วัตถุวิวัฒนาการสามระดับ แต่ละระดับมีต้นทุนที่แตกต่างกัน

• ระดับพารามิเตอร์เชิงตัวเลข: ตัวเลือกคือกลุ่มตัวเลข สร้างได้ถูกและประเมินได้เร็ว แต่ตอบได้เพียงว่า "ปรับได้ดีแค่ไหน" ไม่สามารถเติมกลไกที่ขาดหายไปตั้งแต่ต้นได้
• ระดับโปรแกรมและโครงสร้างโมเดล: ตัวเลือกคือโครงสร้างเครือข่าย การผสมตัวดำเนินการ เวิร์กโฟลว์พรอมป์ หรือแพตช์โค้ด การเปลี่ยนแปลงจะเปลี่ยนว่า "ระบบทำอะไรได้" ไม่ใช่แค่ "ทำได้แม่นแค่ไหน"
• ระดับสถานะทางวิศวกรรมซอฟต์แวร์: ตัวเลือกคือการตั้งค่า เวอร์ชันของ dependency สัญญาส่วนติดต่อ และกลยุทธ์การดีพลอย ซึ่งกำหนดโดยตรงว่าระบบจะทำงานได้เสถียรและทำซ้ำได้หรือไม่

การเปลี่ยนจุดเน้น: จาก "จะสร้างตัวเลือกอย่างไร" สู่ "จะรันและประเมินอย่างไร"

เมื่อตัวเลือกเปลี่ยนจากตัวเลขเป็นโปรแกรม ขั้นตอน "การสร้างตัวเลือก" กลับไม่ใช่คอขวดอีกต่อไป เพราะโมเดลขนาดใหญ่สามารถผลิตโครงสร้าง กลไก และแพตช์ออกมาเป็นจำนวนมากได้ สิ่งที่กำหนดว่าวิวัฒนาการจะได้ผลจริงหรือไม่คือกลไกการรันและการประเมิน— ใครสามารถรันตัวเลือกให้ทำงานได้จริง ใครสามารถตัดสินได้ภายในต้นทุนที่ยอมรับได้ว่ามันควรค่าแก่การเก็บไว้หรือไม่

ยิ่งความสามารถในการแสดงออกสูง ภาระในการประเมินก็ยิ่งหนัก พารามิเตอร์เชิงตัวเลขเพียงตัวเดียวใช้การฝึกแค่ครั้งเดียวก็ให้คะแนนได้ แต่แพตช์โค้ดหนึ่งชิ้นต้องผ่านการแยกในแซนด์บ็อกซ์ การทดสอบแบบรีเกรสชัน และการเทียบกับ基準 จึงจะตอบคำถามสามข้อได้ว่า มันได้ผลจริงหรือไม่ ก่อความเสี่ยงหรือไม่ และผลลัพธ์ทำซ้ำได้หรือไม่ แซนด์บ็อกซ์ การทดสอบแบบรีเกรสชัน และ基準 คือกลไกทางวิศวกรรมที่ใช้จำกัดต้นทุน ความเสี่ยง และการทำซ้ำได้ อีกทั้งยังทำให้การเปลี่ยนแปลงถูกเก็บไว้หรือคัดออกได้อย่างเสถียร

การ权衡ทางวิศวกรรม: ตัวเลือกมากขึ้นไม่ได้แปลว่าวิวัฒนาการดีขึ้น

ในทางปฏิบัติของทีม เส้นทางที่พบบ่อยคือเริ่มจากการปรับอัตราการเรียนรู้และไฮเปอร์พารามิเตอร์ก่อน แล้วค่อย ๆ ขยายไปสู่การค้นหาโครงสร้างเครือข่าย การผสมตัวดำเนินการ เวิร์กโฟลว์พรอมป์ หรือแพตช์โค้ด ทุกครั้งที่ขยายขึ้นหนึ่งระดับ ต้องตอบคำถามควบคู่กันไปว่า การประเมินต้องใช้พลังประมวลผลและเวลามากแค่ไหน? ตัวเลือกที่ล้มเหลวจะปนเปื้อนระบบที่มีอยู่หรือไม่? ผลลัพธ์เดิมจะทำซ้ำได้ในครั้งถัดไปหรือไม่? เมื่อสร้างสมดุลระหว่างความสามารถในการแสดงออก ต้นทุนการประเมิน การทำซ้ำได้ และความปลอดภัยได้แล้ว วิวัฒนาการระดับระบบจึงจะเป็นไปได้จริง