เกินกว่าขีดจำกัดการใช้งาน: การขยายการเข้าถึง Codex และ Sora
โดย Jonah Cohen สมาชิกทีมงานด้านเทคนิค
ในปีที่ผ่านมา Codex และ Sora ได้รับการยอมรับอย่างรวดเร็ว โดยการใช้งานเพิ่มขึ้นเกินกว่าที่เราคาดไว้ เราเห็นรูปแบบที่สม่ำเสมอ ผู้ใช้เริ่มใช้งานทันที พบคุณค่าจริง และจากนั้นก็ติดลิมิตการใช้งาน
การจำกัดอัตราสามารถช่วยให้ความต้องการใช้งานราบรื่นและเข้าถึงได้อย่างเป็นธรรม อย่างไรก็ตาม เมื่อผู้ใช้ได้รับประโยชน์ การหยุดใช้งานอย่างกะทันหันอาจทำให้รู้สึกหงุดหงิด เราต้องการวิธีให้ผู้ใช้สามารถดำเนินการต่อไปได้ ในขณะที่ปกป้องประสิทธิภาพของระบบและความไว้วางใจของผู้ใช้ในแนวทางของเรา
เพื่อแก้ปัญหานี้ เราได้สร้างเครื่องมือการเข้าถึงแบบเรียลไทม์ที่สามารถนับการใช้งานได้ หนึ่งในชั้นของเครื่องมือนั้นคือความสามารถในการซื้อเครดิต เมื่อผู้ใช้เกินลิมิตการใช้งาน เครดิตจะช่วยให้พวกเขายังคงใช้ผลิตภัณฑ์ของเราได้โดยการใช้ยอดคงเหลือเครดิต
ภายใต้ระบบนี้คือระบบที่ซับซ้อนที่รวมข้อจำกัด การติดตามการใช้งานแบบเรียลไทม์ และยอดคงเหลือเครดิตไว้ในโมเดลการเข้าถึงเดียว โพสต์นี้อธิบายว่าทำไมการขยาย Codex และ Sora จึงต้องพิจารณาการควบคุมการเข้าถึงใหม่ ระบบที่ถูกต้องตามหลักการในแบบเรียลไทม์ผสานการจำกัดอัตราและเครดิตต่อคำขออย่างไร และรากฐานนี้ช่วยปลดล็อกการเข้าถึงเพิ่มเติมสำหรับทั้งสองผลิตภัณฑ์ได้อย่างไร
เมื่อมองภาพรวม โมเดลการเข้าถึงแบบดั้งเดิมมักจะบังคับให้เลือกอย่างใดอย่างหนึ่ง:
- ลิมิตการใช้งาน อาจมีประโยชน์ในตอนแรก แต่จะทำให้ผู้ใช้รู้สึกไม่ดีเมื่อถึงขีดจำกัด: “กรุณากลับมาใหม่ภายหลัง”
- การเรียกเก็บเงินตามการใช้งาน มีความยืดหยุ่น แต่ทำให้ผู้ใช้ต้องจ่ายตั้งแต่ Token แรก ไม่เหมาะสำหรับการสนับสนุนการสำรวจในช่วงเริ่มต้น
สำหรับ Codex และ Sora ไม่มีสิ่งใดเพียงพอด้วยตัวเอง หากเราเพียงแค่เพิ่มลิมิตการใช้งาน เราจะสูญเสียการควบคุมที่สำคัญในการปรับความต้องการให้ราบรื่นและความเป็นธรรม และจะไม่มีความจุเพียงพอที่จะให้บริการทุกคน หากเราอาศัยการเรียกเก็บเงินตามการใช้งานแบบอะซิงโครนัสทั้งหมด เราจะทำให้เกิดความล่าช้า ค่าบริการเกิน หรือปัญหาในการกระทบยอด ซึ่งเป็นปัญหาที่ผู้ใช้สังเกตเห็นได้ชัดเจนเมื่อพวกเขามีส่วนร่วมมากที่สุด
สิ่งที่เราต้องการจริงๆ คือระบบไฮบริดแบบครบวงจรที่ผสานรวมการจำกัดการใช้งานแบบเรียลไทม์เข้ากับการเข้าถึงแบบจ่ายตามการใช้งาน:
ระบบนี้ต้องทำสิ่งต่อไปนี้:
- บังคับใช้ลิมิตการใช้งานจนกระทั่งถึงขีดจำกัด
- เปลี่ยนไปยังเครดิตได้อย่างราบรื่นภายในคำขอเดียวกัน
- ตัดสินใจเรื่องนั้นในเวลาจริง
- ติดตามการใช้เครดิตอย่างแม่นยำและสามารถตรวจสอบได้
หนึ่งในการเปลี่ยนแปลงเชิงแนวคิดที่สำคัญที่เราทำคือการจำลองการเข้าถึงเป็นลำดับขั้นการตัดสินใจ แทนที่จะถามว่า สิ่งนี้อนุญาตหรือไม่ เราถามว่า “อนุญาตได้เท่าไร และมาจากที่ใด” เมื่อระบบนับการใช้งาน ระบบจะดำเนินการตามลำดับดังนี้:
โมเดลนี้สะท้อนให้เห็นถึงวิธีที่ผู้ใช้สัมผัสประสบการณ์กับผลิตภัณฑ์จริงๆ ขีดจำกัดการใช้งาน แพ็กเกจฟรี เครดิต โปรโมชัน และสิทธิ์การใช้งานระดับองค์กร ล้วนเป็นเพียงชั้นต่างๆ ในสแต็กการตัดสินใจเดียวกัน จากมุมมองของผู้ใช้ พวกเขาไม่ได้ 'เปลี่ยนระบบ' พวกเขาแค่ใช้งาน Codex และ Sora ต่อไป นั่นคือเหตุผลที่เครดิตดูเหมือนไม่มีตัวตน: มันเป็นเพียงองค์ประกอบหนึ่งในกระบวนการเท่านั้น
เราได้ประเมินแพลตฟอร์มการเรียกเก็บเงินและการวัดการใช้งานของบุคคลที่สามเพื่อจัดการการบริโภคเครดิต เหมาะสำหรับการออกใบแจ้งหนี้และการรายงาน แต่ไม่ตรงตามข้อกำหนดสำคัญสองประการ:
เมื่อผู้ใช้ถึงขีดจำกัดและมีเครดิตพร้อมใช้งาน ระบบต้องทราบทันที การนับแบบพยายามอย่างเต็มที่หรือการนับแบบล่าช้า ส่งผลให้เกิดปัญหาที่ไม่คาดคิด ยอดคงเหลือไม่สอดคล้องกัน และค่าใช้จ่ายที่ไม่ถูกต้อง สำหรับผลิตภัณฑ์แบบโต้ตอบ เช่น Codex และ Sora ความล้มเหลวเหล่านั้นจะเห็นได้ชัดเจนและน่าหงุดหงิดใจ
เรายังจำเป็นต้องให้ความโปร่งใสในทุกผลลัพธ์
- ทำไมคำขอถึงได้รับอนุญาตหรือถูกบล็อก
- ใช้ไปเท่าไร
- ข้อจำกัดหรือยอดคงเหลือใดที่ถูกนำมาใช้
ความสามารถนี้จำเป็นต้องผสานรวมอย่างแนบแน่นเข้ากับลำดับการตัดสินใจของเรา แทนที่จะแก้ไขปัญหาแบบแยกส่วนบนแพลตฟอร์มการเรียกเก็บเงินที่แยกต่างหาก ซึ่งมองเห็นเพียงบางส่วนของสิ่งที่เกิดขึ้น เพื่อให้ผู้ใช้สามารถเข้าถึงผลิตภัณฑ์ของเราได้โดยไม่สูญเสียความไว้วางใจ เราจำเป็นต้องมีการควบคุมอย่างเต็มที่ในด้านความถูกต้อง เวลา และการสังเกตการณ์ สิ่งนั้นผลักดันให้เราเลือกใช้โซลูชันที่พัฒนาภายในองค์กร
เพื่อให้ระบบนี้ทำงานได้ เราได้พัฒนาระบบการใช้งานและยอดคงเหลือแบบกระจายที่ออกแบบมาโดยเฉพาะสำหรับการตัดสินใจการเข้าถึงแบบซิงโครนัส
ในภาพรวม ระบบ:
- ติดตามการใช้งานต่อผู้ใช้ต่อฟีเจอร์
- รักษาหน้าต่างลิมิตการใช้งาน
- รักษายอดคงเหลือเครดิตในเวลาจริง
- หักบัญชียอดคงเหลือแบบไอดีมโพเทนต์ผ่านตัวประมวลผลอะซิงโครนัสแบบสตรีมมิง
ทุกคำขอจะผ่านเส้นทางการประเมินเพียงเส้นทางเดียว ซึ่งจะตัดสินใจแบบเรียลไทม์ว่าการใช้งานได้รับอนุญาตได้มากเพียงใด โดยจะหักจากอัตราการจำกัดแบบซิงโครนัส และหากจำเป็นก็จะตรวจสอบว่าเครดิตเพียงพอ จากนั้นจะส่งคืนผลลัพธ์ที่ชัดเจนเพียงหนึ่งเดียว พร้อมทั้งชำระบัญชีการหักเครดิตแบบอะซิงโครนัส สิ่งนี้ช่วยให้การทำงานมีความสม่ำเสมอในทุกผลิตภัณฑ์ และขจัดตรรกะที่ซ้ำซ้อนระหว่างทีม
หนึ่งในหลักการออกแบบที่สำคัญของระบบนี้คือ เราต้องสามารถพิสูจน์ได้ว่าการเรียกเก็บเงินของเราถูกต้อง สิ่งนี้สะท้อนถึงรากฐานของการสนับสนุนด้านเครดิตของเรา ซึ่งมีจุดเริ่มต้นจากลูกค้าองค์กร ในแผนภาพระบบด้านบน เรามีชุดข้อมูลสามชุดที่เชื่อมโยงกัน:
- เหตุการณ์การใช้งานผลิตภัณฑ์: สิ่งที่ผู้ใช้ทำจริง
- เหตุการณ์การสร้างรายได้: สิ่งที่เราเรียกเก็บเงินจากผู้ใช้สำหรับการใช้งานของเขา
- การอัปเดตยอดคงเหลือ: จำนวนเงินที่เราปรับยอดเครดิตของผู้ใช้และเหตุผลที่ทำให้เกิดการปรับ
ชุดข้อมูลเหล่านี้ไม่ใช่ผลพลอยได้ทั่วไป แต่เป็นตัวขับเคลื่อนระบบ โดยที่แต่ละชุดข้อมูลจะกระตุ้นชุดถัดไป การแยกสิ่งที่เกิดขึ้น ค่าธรรมเนียมที่เกี่ยวข้อง และสิ่งที่เราเดบิต ช่วยให้เราสามารถตรวจสอบแบบอิสระ เล่นซ้ำ และกระทบยอดได้ในทุกเลเยอร์ นี่เป็นการแลกเปลี่ยนที่ตั้งใจไว้ โดยเราให้ความสำคัญกับความถูกต้องที่พิสูจน์ได้เป็นอันดับแรก ซึ่งแลกกับการที่การอัปเดตยอดคงเหลือเครดิตอาจล่าช้าเล็กน้อย เราทำสิ่งนี้สำเร็จได้อย่างไร:
- เหตุการณ์การใช้งานผลิตภัณฑ์จะเผยแพร่สำหรับกิจกรรมของผู้ใช้ทั้งหมด ไม่ว่าจะทำให้เกิดการใช้เครดิตหรือไม่ สิ่งนี้ช่วยจัดทำบันทึกการตรวจสอบสำหรับกิจกรรมของผู้ใช้ และช่วยให้เราอธิบายได้ว่าทำไมเราจึงเรียกเก็บหรือไม่ได้เรียกเก็บเครดิต
- ทุกเหตุการณ์มีคีย์ idempotency ที่เสถียร ดังนั้นการลองใหม่ การเล่นซ้ำ หรือการรีสตาร์ทเวิร์กเกอร์จะไม่สามารถหักยอดคงเหลือซ้ำได้ ซึ่งช่วยป้องกันการเรียกเก็บเงินซ้ำซ้อน สิ่งนี้ยังช่วยให้เราทำการกระทบยอดแบบแบตช์เพื่อยืนยันงานของเราแบบออฟไลน์ได้
- เราอัปเดตยอดคงเหลือแบบอะซิงโครนัส (แต่ยังเกือบเรียลไทม์) แทนการอัปเดตแบบซิงโครนัสเพื่อสร้างบันทึกการตรวจสอบ เรายอมรับความล่าช้าเล็กน้อยในการอัปเดตยอดคงเหลือของผู้ใช้ เพื่อพิสูจน์ว่าระบบทำงานได้ตามปกติ และสร้างความมั่นใจให้ผู้ใช้ว่าเราไม่ได้เรียกเก็บเงินผิดพลาด เมื่อเกิดความล่าช้าสั้นๆ ที่ทำให้เราหักเกินยอดเครดิตของผู้ใช้ เราจะคืนเงินโดยอัตโนมัติ เราเลือกความถูกต้องที่พิสูจน์ได้และความไว้วางใจของผู้ใช้มากกว่าการบังคับใช้อย่างเข้มงวด
- เราลดยอด Credit Balance และเพิ่มเรคคอร์ด Balance Update ในการทำธุรกรรมฐานข้อมูลแบบอะตอมิกเพียงครั้งเดียว การอัปเดตยอดคงเหลือจะถูกจัดลำดับตามบัญชี ดังนั้นคำขอที่เกิดขึ้นพร้อมกันจะไม่สามารถแข่งขันกันเพื่อใช้เครดิตเดียวกันได้ ระเบียน Balance Update ประกอบด้วยจำนวนเงินเดบิตและการอ้างอิงกลับไปยังเหตุการณ์การสร้างรายได้ที่กระตุ้นให้เกิดการอัปเดต การรวมสิ่งนี้ไว้ในธุรกรรมฐานข้อมูลเดียวรับประกันว่าเรามีร่องรอยการตรวจสอบสำหรับการปรับยอดคงเหลือเครดิตทุกครั้ง
ความเข้มงวดทั้งหมดนี้สนับสนุนเป้าหมายเดียว คือการทำให้การเข้าถึงง่ายและปลอดภัย เมื่อผู้คนกำลังสร้างสรรค์หรือเขียนโค้ด พวกเขาไม่ควรต้องสงสัยว่าคำขอจะผ่านหรือไม่ จะถูกเรียกเก็บเงินเกินจริงหรือไม่ หรือยอดคงเหลือถูกต้องหรือไม่ ด้วยการทำให้การใช้งาน การเรียกเก็บเงิน และยอดคงเหลือถูกต้องอย่างตรวจสอบได้ เรามอบระบบที่ไม่รบกวนประสบการณ์ของคุณ นั่นคือสิ่งที่ทำให้เราสามารถแทนที่การหยุดชะงักแบบตัดจบด้วยการเข้าถึงอย่างต่อเนื่อง และทำให้เครดิตสามารถใช้งานได้ระหว่างการทำงานจริง ไม่ใช่แค่บนใบแจ้งหนี้
หลักการสำคัญที่อยู่เบื้องหลังแนวทางของเราคือการรักษาความต่อเนื่องของผู้ใช้ ทุกการตัดสินใจด้านสถาปัตยกรรมล้วนเชื่อมโยงกลับไปยังผลลัพธ์ที่ผู้ใช้มองเห็นได้ ยอดคงเหลือแบบเรียลไทม์ช่วยป้องกันการขัดจังหวะที่ไม่จำเป็น การใช้งานแบบอะตอมมิกช่วยป้องกันการเรียกเก็บเงินซ้ำ และตรรกะการเข้าถึงแบบรวมศูนย์ช่วยให้มั่นใจได้ถึงพฤติกรรมที่คาดการณ์ได้ ผลลัพธ์คือผู้คนสามารถทำงานได้นานขึ้น สำรวจได้ลึกซึ้งยิ่งขึ้น และพัฒนาโครงการไปได้ไกลขึ้น โดยไม่ต้องเผชิญกับการหยุดชะงักหรือการเปลี่ยนแผนก่อนเวลาอันควร
เมื่อผู้ใช้มีส่วนร่วม ระบบควรช่วยให้พวกเขาดำเนินการต่อไป ไม่ใช่ขัดขวาง ข้อจำกัดและเครดิตเลือนหายไปในเบื้องหลัง
การสร้างประสบการณ์นั้นต้องอาศัยการคิดใหม่เกี่ยวกับการเข้าถึง การใช้งาน และการเรียกเก็บเงินให้เป็นระบบเดียวกัน และสร้างโครงสร้างพื้นฐานที่ให้ความสำคัญกับความถูกต้องเป็นฟีเจอร์หลักของผลิตภัณฑ์ รากฐานเดียวกันนี้สามารถขยายไปสู่ผลิตภัณฑ์อื่นๆ ได้มากขึ้นเมื่อเวลาผ่านไป Codex และ Sora เป็นเพียงจุดเริ่มต้นเท่านั้น


