เมื่อโมเดลโอเพ่นซอร์สถูกจำกัด สิ่งแรกที่ทีมสูญเสียคือความสามารถในการเปลี่ยน

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

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

สลับหน้าต่างเพื่อให้เห็นปัญหาก่อน

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

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

การปรับแนวจะช้ากว่าการเปลี่ยนรุ่น

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

นี่คือสาเหตุที่ “วิ่งได้” ไม่ได้หมายความว่า “สามารถโยกย้ายได้” คุณค่าของโมเดลโอเพ่นซอร์สอยู่ที่ความสามารถในการทดแทนได้ แต่การทดแทนไม่ได้จบลงด้วยการกำหนดน้ำหนักให้กับอดีต ตราบใดที่รูปแบบเอาต์พุต การเรียกเครื่องมือ และการกำหนดความยาวสูงสุดยังไม่ถูกทำให้รัดกุมอีกต่อไป การย้ายข้อมูลจะเสร็จสมบูรณ์เพียงครึ่งเดียวเท่านั้น การสลับโมเดลที่ชัดเจนในที่สุดจะกลายเป็นการเปลี่ยนแปลงร่วมกันของคำพร้อมท์, parsers, retryers และ rollback chain

เส้นทางสำรองจะต้องสร้างตามเส้นทางอย่างเป็นทางการ

หากวางแบบจำลองการสำรองข้อมูลไว้ในส่วน “แผนดาวน์เกรด” บางส่วนของเอกสาร ก็เกือบจะสายเกินไปเมื่อถึงเวลาต้องเปลี่ยน แนวทางที่เสถียรกว่าคือการรวมทั้งโมเดลหลักและโมเดลสำรองไว้ในชุดพื้นฐานเดียวกัน: กลุ่มตัวอย่างเดียวกัน ชุดตัวบ่งชี้เดียวกัน Parser เวอร์ชันเดียวกัน และห่วงโซ่ย้อนกลับรีลีสเดียวกัน เมื่อการเปลี่ยนแปลงดังกล่าวเกิดขึ้น สวิตช์จะเปลี่ยนเฉพาะเส้นทางในเส้นทางที่มีการเดินทาง แทนที่จะสร้างระบบใหม่ชั่วคราว

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

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