ข้ามไปเนื้อหาหลัก

เจาะลึกเทคนิคสตรีมมิ่งงานประมวลผล AI ข้ามนาทีด้วย SSE จากประสบการณ์จริงสร้างเครื่องมือตรวจสอบ

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

เรียบเรียงโดย AI
Inewgen
26 Jul 2026ที่มา: Dev.to3 นาทีอ่าน (0 ครั้ง)อัปเดตล่าสุด 29 Aug 2026
แชร์
เจาะลึกเทคนิคสตรีมมิ่งงานประมวลผล AI ข้ามนาทีด้วย SSE จากประสบการณ์จริงสร้างเครื่องมือตรวจสอบ

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

ขนาดตัวอักษร
  • เปลี่ยนจากการใช้สปินนันหมุนเคว้งมาใช้ Server-Sent Events เพื่อส่งข้อมูลแบบเรียลไทม์ทางเดียว
  • ออกแบบคำศัพท์เหตุการณ์ให้มีรูปแบบตายตัวผ่าน 4 ประเภทหลักเพื่อความเสถียร
  • แยกกระบวนการทำงานเบื้องหลังออกจากช่องทางสตรีมเพื่อรองรับปัญหาการเชื่อมต่อหลุด
  • จัดการอัตราการส่งข้อมูลและแรงดันย้อนกลับเพื่อป้องกันหน่วยความจำรั่วในฝั่งเซิร์ฟเวอร์

ในเวอร์ชันแรกของเว็บฟรอนต์ทัณฑ์ spectr-ai นั้นมีเพียงไอคอนหมุนโหลด หรือสปินเนอร์ ผู้ใช้งานทำการอัปโหลดสัญญา สปินเนอร์ก็หมุนไป และอีกหลายนาทีถัดมาผลลัพธ์จึงจะปรากฏหรือไม่ก็ไม่แสดงผลเลย จากการทดสอบใช้งานจริงกับกลุ่มเพื่อนฝั่งผู้ทดสอบมักจะทำสิ่งเดียวกันคือ เมื่อถึงช่วงเวลาประมาณวินาทีที่ 90 พวกเขาจะทำการรีเฟรชหน้าจอ ซึ่งเป็นการตัดกระบวนการตรวจสอบที่กำลังจะเสร็จสิ้นลงทันที สปินเนอร์ที่ไม่มีตัวเลขความคืบหน้าหรือสถานะบอกจึงแทบไม่ต่างอะไรกับการแฮงก์ และผู้ใช้งานย่อมตอบสนองตามประสบการณ์นั้น

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

การเลือกใช้เทคโนโลยีในลักษณะงานที่มีเวลายาวนาน (Long-running jobs) ฝั่งนักพัฒนาจำเป็นต้องมองข้ามเครื่องมือพื้นฐานที่ออกแบบมาสำหรับงานสั้นๆ เช่น การใช้ HTTP request แบบเดิมที่จะหมดอายุหรือตัดการเชื่อมต่อเมื่อเวลาเกินกำหนด การแยกสถาปัตยกรรมระหว่างตัวประมวลผลงาน (Worker) และช่องทางการสตรีมข้อมูล (SSE stream) จึงเป็นหัวใจสำคัญที่ช่วยให้ระบบมีความทนทานต่อความล้มเหลวในสถานการณ์จริง

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

developer workspace code laptop

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

ไม่อยากพลาดข่าวใหม่?

สมัครรับสรุปข่าวสารใหม่ทางอีเมล ไม่บ่อยจนรำคาญ

โฆษณา

ความพยายามครั้งแรกคือการสตรีมข้อมูลที่ไปป์ไลน์ต้องการจะพ่นออกมา เช่น โทเค็นดิบของโมเดล, บรรทัดบันทึกเหตุการณ์ (log lines) และเศษความคิด ทำให้ฟรอนต์เอนต์กลายเป็นตัวแยกวิเคราะห์รูปแบบที่ไม่มีเอกสารกำกับและเปลี่ยนแปลงตลอดเวลาเมื่อใดก็ตามที่แตะแบ็กเอนด์ ซึ่งเป็นแนวทางที่ไม่ดี

ในการพยายามครั้งที่สอง จึงได้กำหนดคำศัพท์เหตุการณ์ที่มีโครงสร้างตายตัวและปฏิบัติเสมือนเป็น API contract จริง โดยมีเหตุการณ์ 4 ประเภทที่ครอบคลุมทุกอย่าง:

  • progress: สื่อสารขั้นตอนเชิงความไม่ใช่เปอร์เซ็นต์ เช่น ข้อความAnalyzing withdraw(), function 3 of 7 ซึ่งช่วยให้ผู้ใช้งานอยู่หน้าจอผ่านนาทีที่สี่ไปได้
  • partial-finding: ฟีเจอร์รักษาผู้ใช้งาน โดยไปป์ไลน์จะพบปัญหาทีละรายการและส่งออกทันทีที่ได้รับการตรวจสอบความถูกต้องแล้ว
  • error: แยกแยะระหว่างข้อผิดพลาดที่กู้คืนได้กับข้อผิดพลาดร้ายแรง เพื่อให้ระบบทราบว่าต้องลองใหม่หรือยุติการทำงาน

แล็ปท็อปสามารถเข้าสู่โหมดสลีป โทรศัพท์สลับเครือข่าย พร็อกซีตัดการเชื่อมต่อที่ไม่มีการใช้งาน ตลอดระยะเวลาหลายนาที การขาดการเชื่อมต่อถือเป็นเรื่องที่แน่นอนในระดับสเกลใหญ่ และ EventSource จะเชื่อมต่อใหม่อัตโนมัติพร้อมส่งเฮดเดอร์ Last-Event-ID ไปพร้อมกับเหตุการณ์ล่าสุดที่ได้รับ

ที่มา: Dev.to

ความคิดเห็น

แสดงความคิดเห็น
0/2000

พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้