Model deprecation

การปลดระวางโมเดล คือขั้นตอนที่ผู้ให้บริการโมเดล AI ประกาศอย่างเป็นทางการว่าจะเลิกซัพพอร์ตโมเดลรุ่นหนึ่งบน api ของตัวเอง เอกสารของ Anthropic แบ่งสถานะของโมเดลไว้สี่ระดับคือ active ซึ่งใช้งานได้เต็มที่และแนะนำให้ใช้ legacy ซึ่งจะไม่ได้รับอัปเดตใหม่อีกและมีโอกาสถูกประกาศ deprecated ในอนาคต deprecated ซึ่งยังทำงานได้แต่ไม่แนะนำให้ใช้ต่อและถูกกำหนดวันปลดระวางไว้แล้ว และ retired ซึ่งเรียกใช้ไม่ได้อีกต่อไป ทุกคำขอที่เรียกชื่อรุ่นนั้นจะได้รับ error กลับมาทันที พูดง่ายๆ คำนี้คือวันหมดอายุของชื่อรุ่นโมเดลตัวหนึ่ง ไม่ใช่วันหมดอายุของความสามารถ AI โดยรวม เพราะผู้ให้บริการยังเปิดรุ่นใหม่ให้ใช้แทนอยู่เสมอ แต่ระบบใดที่ยังฝังชื่อรุ่นเก่าไว้ในโค้ดตรงๆ จะหยุดทำงานทันทีที่ถึงวันปลดระวาง

ตัวอย่างที่ยืนยันได้ชัดที่สุดคือ Claude Opus 4.1 ซึ่งมีชื่อรุ่นในระบบว่า claude-opus-4-1-20250805 Anthropic แจ้งแผนปลดระวางไว้ล่วงหน้าตั้งแต่วันที่ 5 มิ.ย. 2026 แล้วปลดระวางจริงในวันที่ 5 ส.ค. 2026 บันทึกการเปลี่ยนแปลงของบริษัทลงวันที่ 5 ส.ค. 2026 ระบุตรงๆ ว่าโมเดลนี้ถูกปลดระวางแล้ว คำขอทุกครั้งที่ยังเรียกชื่อรุ่นนี้บน API จะได้รับ error กลับมาแทน พร้อมแนะนำให้ย้ายไปใช้ Claude Opus 5 ส่วนตารางประวัติการปลดระวางในเอกสารซึ่งเขียนไว้ตั้งแต่วันประกาศเมื่อเดือน มิ.ย. 2026 ยังระบุรุ่นแทนไว้ว่า claude-opus-4-8 เพราะตอนนั้น Opus 5 ยังไม่เปิดตัว ตัวอย่างนี้บอกอีกอย่างว่ารุ่นที่ผู้ให้บริการแนะนำให้ย้ายไปใช้ก็เปลี่ยนได้ระหว่างทาง ควรเช็คหน้าประกาศอีกครั้งตอนจะย้ายจริง ช่วงเวลาแจ้งล่วงหน้าราวสองเดือนนี้ไม่ใช่เรื่องบังเอิญ เพราะ Anthropic ระบุนโยบายไว้ว่าจะแจ้งลูกค้าที่ยังมีการใช้งานโมเดลนั้นอยู่ ล่วงหน้าอย่างน้อย 60 วันก่อนปลดระวางโมเดลที่เปิดใช้งานสาธารณะแล้ว รูปแบบเดียวกันนี้ไม่ได้จำกัดอยู่แค่ตัวโมเดลภาษาเท่านั้น เพราะ OpenAI เองก็ประกาศปิดผลิตภัณฑ์ AI ของตัวเองตามกำหนดเวลาที่ตั้งไว้ในลักษณะเดียวกัน อย่างเบราว์เซอร์ ChatGPT Atlas ที่ประกาศเลิกให้บริการเมื่อวันที่ 9 ก.ค. 2026 แล้วปิดจริงในวันที่ 9 ส.ค. 2026 OpenAI เตือนผู้ใช้ไว้ตั้งแต่ก่อนถึงวันปิดว่าหลังจากวันนั้น Atlas อาจเปิดไม่ได้ ท่องเว็บไม่ได้ และรองรับงานแบบ agent ผ่านเบราว์เซอร์ไม่ได้อีกต่อไป และ bookmark ก็ไม่ย้ายไปแอปอื่นให้อัตโนมัติ ผู้ใช้ต้อง export เก็บไว้เองก่อนถึงวันปิด กรณีนี้เป็นการปลดระวางผลิตภัณฑ์ทั้งตัว คนละระดับกับการปลดระวางรุ่นโมเดลเดี่ยวๆ แต่สิ่งที่คนใช้เจอมีรูปแบบเดียวกันคือของที่เคยใช้ได้จู่ๆ ก็ใช้ไม่ได้ตามกำหนดเวลาที่ผู้ให้บริการเป็นคนตั้งเอง

คนที่ไม่ได้เขียนโค้ดเองก็ควรรู้จักคำนี้ไว้ เพราะอาการที่เจอจริงมักมาในรูปงานอัตโนมัติที่เคยรันทุกเช้าแล้วอยู่ๆ เงียบไปเฉยๆ มากกว่าข้อความแจ้งเตือนที่อ่านรู้เรื่อง โดยเฉพาะระบบที่ทีมพัฒนาฝังชื่อรุ่นโมเดลไว้ในโค้ดตรงๆ ตั้งแต่ตอนเขียน Anthropic เองแนะนำวิธีป้องกันไว้ในเอกสารเดียวกันคือให้ export รายงานการใช้งานเป็นไฟล์ CSV จากหน้า Usage บน Claude Console แล้วไล่ดูว่า API key และโมเดลไหนของทีมยังเรียกรุ่นที่ถูกปลดระวางอยู่บ้าง ก่อนจะสายเกินไป ข้อควรระวังคือกำหนดเวลาที่แต่ละผู้ให้บริการให้ไว้ไม่เท่ากันเสมอไป และแม้แต่โมเดลตัวเดียวกันก็มีวันปลดระวางต่างกันได้ตามช่องทางที่เรียกใช้ เพราะเอกสารของ Anthropic ระบุว่าวันที่บนหน้าประกาศใช้กับแพลตฟอร์มที่ Anthropic ดูแลเอง ส่วน Amazon Bedrock และ Google Cloud ตั้งตารางปลดระวางของตัวเอง Anthropic รับปากแจ้งล่วงหน้าอย่างน้อย 60 วันสำหรับโมเดลที่เปิดสาธารณะแล้ว ส่วนกรณี Atlas ซึ่งเป็นการปิดผลิตภัณฑ์ทั้งตัว ไม่ใช่การปลดระวางรุ่นโมเดลบน API มีช่วงแจ้งล่วงหน้าประมาณหนึ่งเดือนเท่านั้น ยิ่งองค์กรผูกระบบเข้ากับชื่อรุ่นของผู้ให้บริการรายเดียวมากเท่าไหร่ ก็ยิ่งเจอความเสี่ยงแบบนี้บ่อยขึ้น ซึ่งเป็นด้านหนึ่งของ vendor-lock-in ที่มักถูกมองข้าม และแรงงานเวลาที่ทีมต้องเสียไปกับการย้ายระบบซ้ำๆ ทุกครั้งที่มีการปลดระวาง ก็ควรถูกนับรวมเป็นส่วนหนึ่งของ total-cost-of-ownership ตั้งแต่ต้น สิ่งที่ทำได้จริงวันนี้คือถามทีมพัฒนาว่ามีชื่อรุ่นโมเดลฝังอยู่ในระบบไหนบ้าง แล้วย้ายไปไว้ที่ค่าตั้งค่าที่แก้ได้โดยไม่ต้อง deploy ใหม่ พร้อมติดตามหน้าประกาศ deprecation ของผู้ให้บริการที่องค์กรใช้อยู่เป็นระยะ

ตัวอย่างจากบทสนทนาจริง

ฝ่ายปฏิบัติการ: เมื่อเช้าบอทสรุปยอดขายที่เคยส่งเข้ากลุ่มไลน์ทุกวันหายไปเฉยๆ ตั้งแต่เมื่อวาน เซิร์ฟเวอร์ล่มหรือเปล่า

ทีมไอที: เช็คแล้วครับ ไม่ใช่เซิร์ฟเวอร์ล่มครับ ผู้ให้บริการโมเดลที่บอทเรียกใช้ปลดระวางรุ่นนั้นไปเมื่อวานนี้พอดี ทุกคำขอที่เรียกชื่อรุ่นเดิมเลยได้ error กลับมาแทน

ฝ่ายปฏิบัติการ: แล้วทำไมไม่มีใครเตือนล่วงหน้าเลย

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

ระวังสับสนกับ

• vendor-lock-in : vendor lock-in คือความเสี่ยงเชิงโครงสร้างจากการผูกระบบไว้กับผู้ให้บริการรายเดียวจนย้ายออกยาก ส่วนการปลดระวางโมเดลคือเหตุการณ์เฉพาะจุดที่เกิดขึ้นได้แม้จะอยู่กับผู้ให้บริการเจ้าเดิมต่อไป เพราะเจ้าเดิมเองก็เปลี่ยนรุ่นที่เปิดให้เรียกใช้อยู่เรื่อยๆ
• knowledge-cutoff : knowledge cutoff คือวันที่ข้อมูลซึ่งใช้เทรนโมเดลสิ้นสุดลง เป็นข้อจำกัดเรื่องความรู้ของโมเดล ไม่เกี่ยวกับว่าจะเรียกใช้โมเดลนั้นได้อีกนานแค่ไหน โมเดลที่มี knowledge cutoff เก่ามากก็ยังอยู่ในสถานะ active ได้ ส่วนโมเดลที่เพิ่งออกไม่นานก็ถูกปลดระวางได้เช่นกัน ถ้าผู้ให้บริการต้องการเคลียร์ทางให้รุ่นใหม่