เจาะลึกเทคนิคสตรีมมิ่งงานประมวลผล AI ข้ามนาทีด้วย SSE จากประสบการณ์จริงสร้างเครื่องมือตรวจสอบ
ถอดบทเรียนการพัฒนาเครื่องมือตรวจสอบสัญญาด้วย AI ที่ใช้ Server-Sent Events แก้ปัญหาผู้ใช้งานรอนานจนกดรีเฟรชหน้าจอ พร้อมเทรับมือความท้าทายระดับระบบจริง

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- เปลี่ยนจากการใช้สปินนันหมุนเคว้งมาใช้ Server-Sent Events เพื่อส่งข้อมูลแบบเรียลไทม์ทางเดียว
- ออกแบบคำศัพท์เหตุการณ์ให้มีรูปแบบตายตัวผ่าน 4 ประเภทหลักเพื่อความเสถียร
- แยกกระบวนการทำงานเบื้องหลังออกจากช่องทางสตรีมเพื่อรองรับปัญหาการเชื่อมต่อหลุด
- จัดการอัตราการส่งข้อมูลและแรงดันย้อนกลับเพื่อป้องกันหน่วยความจำรั่วในฝั่งเซิร์ฟเวอร์
ในเวอร์ชันแรกของเว็บฟรอนต์ทัณฑ์ spectr-ai นั้นมีเพียงไอคอนหมุนโหลด หรือสปินเนอร์ ผู้ใช้งานทำการอัปโหลดสัญญา สปินเนอร์ก็หมุนไป และอีกหลายนาทีถัดมาผลลัพธ์จึงจะปรากฏหรือไม่ก็ไม่แสดงผลเลย จากการทดสอบใช้งานจริงกับกลุ่มเพื่อนฝั่งผู้ทดสอบมักจะทำสิ่งเดียวกันคือ เมื่อถึงช่วงเวลาประมาณวินาทีที่ 90 พวกเขาจะทำการรีเฟรชหน้าจอ ซึ่งเป็นการตัดกระบวนการตรวจสอบที่กำลังจะเสร็จสิ้นลงทันที สปินเนอร์ที่ไม่มีตัวเลขความคืบหน้าหรือสถานะบอกจึงแทบไม่ต่างอะไรกับการแฮงก์ และผู้ใช้งานย่อมตอบสนองตามประสบการณ์นั้น
ด้วยเหตุนี้จึงได้ทำการสร้างไปป์ไลน์ใหม่โดยใช้ Server-Sent Events หรือ SSE ซึ่งบทเรียนส่วนใหญ่ไม่ได้มาจากบทเรียนสำเร็จรูปทั่วไป เนื่องจากบทเรียนส่วนใหญ่มักสอนแค่การสตรีมผลลัพธ์แชทสิบวินาทีแล้วจบไป แต่งานที่ใช้เวลานานหลายนาทีและมีสถานะจริงนั้นเป็นปัญหาคนละแบบ สิ่งสำคัญจริงๆ ที่ได้เรียนรู้มีรายละเอียดดังต่อไปนี้
การเลือกใช้เทคโนโลยีในลักษณะงานที่มีเวลายาวนาน (Long-running jobs) ฝั่งนักพัฒนาจำเป็นต้องมองข้ามเครื่องมือพื้นฐานที่ออกแบบมาสำหรับงานสั้นๆ เช่น การใช้ HTTP request แบบเดิมที่จะหมดอายุหรือตัดการเชื่อมต่อเมื่อเวลาเกินกำหนด การแยกสถาปัตยกรรมระหว่างตัวประมวลผลงาน (Worker) และช่องทางการสตรีมข้อมูล (SSE stream) จึงเป็นหัวใจสำคัญที่ช่วยให้ระบบมีความทนทานต่อความล้มเหลวในสถานการณ์จริง
สำหรับเวอร์ชันสั้นคือเบราว์เซอร์ไม่จำเป็นต้องส่งข้อมูลกลับมาระหว่างที่งานกำลังดำเนินการ ลูกค้าทำการอัปโหลดสัญญาแล้วรอฟัง นี่คือรูปแบบที่ SSE ถูกสร้างขึ้นมาใช้งาน โดยเป็นการสื่อสารทางเดียวจากเซิร์ฟเวอร์ไปยังไคลเอนต์ผ่าน HTTP ธรรมดา ไม่ต้องมีการอัปเกรดการเชื่อมต่อ ไม่ต้องจัดการวงจรชีวิตของซ็อกเก็ต และ EventSource ของเบราว์เซอร์ยังมอบฟีเจอร์การเชื่อมต่อใหม่อัตโนมัติฟรี ซึ่งเป็นฟีเจอร์ที่มีมูลค่าสูงสุดของโปรโตคอลนี้ทั้งหมด แม้ว่า WebSockets จะใช้งานได้เช่นกัน แต่จะต้องคอยดูแลรักษาเครื่องจักรแบบสองทิศทางเพื่อใช้งานมันเพียงแค่สิบเปอร์เซ็นต์เท่านั้น

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ความพยายามครั้งแรกคือการสตรีมข้อมูลที่ไปป์ไลน์ต้องการจะพ่นออกมา เช่น โทเค็นดิบของโมเดล, บรรทัดบันทึกเหตุการณ์ (log lines) และเศษความคิด ทำให้ฟรอนต์เอนต์กลายเป็นตัวแยกวิเคราะห์รูปแบบที่ไม่มีเอกสารกำกับและเปลี่ยนแปลงตลอดเวลาเมื่อใดก็ตามที่แตะแบ็กเอนด์ ซึ่งเป็นแนวทางที่ไม่ดี
ในการพยายามครั้งที่สอง จึงได้กำหนดคำศัพท์เหตุการณ์ที่มีโครงสร้างตายตัวและปฏิบัติเสมือนเป็น API contract จริง โดยมีเหตุการณ์ 4 ประเภทที่ครอบคลุมทุกอย่าง:
- progress: สื่อสารขั้นตอนเชิงความไม่ใช่เปอร์เซ็นต์ เช่น ข้อความAnalyzing withdraw(), function 3 of 7 ซึ่งช่วยให้ผู้ใช้งานอยู่หน้าจอผ่านนาทีที่สี่ไปได้
- partial-finding: ฟีเจอร์รักษาผู้ใช้งาน โดยไปป์ไลน์จะพบปัญหาทีละรายการและส่งออกทันทีที่ได้รับการตรวจสอบความถูกต้องแล้ว
- error: แยกแยะระหว่างข้อผิดพลาดที่กู้คืนได้กับข้อผิดพลาดร้ายแรง เพื่อให้ระบบทราบว่าต้องลองใหม่หรือยุติการทำงาน
แล็ปท็อปสามารถเข้าสู่โหมดสลีป โทรศัพท์สลับเครือข่าย พร็อกซีตัดการเชื่อมต่อที่ไม่มีการใช้งาน ตลอดระยะเวลาหลายนาที การขาดการเชื่อมต่อถือเป็นเรื่องที่แน่นอนในระดับสเกลใหญ่ และ EventSource จะเชื่อมต่อใหม่อัตโนมัติพร้อมส่งเฮดเดอร์ Last-Event-ID ไปพร้อมกับเหตุการณ์ล่าสุดที่ได้รับ
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น