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

ทำไมโมเดลแบบเดิมถึงให้ความรู้สึกว่ามีปัญหา

ผู้ช่วยด้วยเสียงทั่วไปทำงานเหมือนวิทยุสื่อสาร (walkie-talkies): เมื่อคุณพูดจบประโยค อุปกรณ์จะบันทึกเสียง ส่งข้อมูลเสียงไปยังคลาวด์ รอการตอบกลับ แล้วจึงเล่นเสียงนั้นออกมา กระบวนการรับส่งข้อมูลแบบไป-กลับนี้ทำให้เกิดความหน่วง (lag) ที่สังเกตเห็นได้ชัด และบังคับให้ผู้ใช้ต้องหยุดรอจนกว่าจะสามารถพูดแทรกได้ สำหรับคนรุ่นที่เติบโตมากับการส่งข้อความแบบทันทีทันใด ความล่าช้านี้จึงให้ความรู้สึกที่ล้าสมัย

OpenAI แก้ปัญหานี้ด้วยสถาปัตยกรรมแบบ turn-less (ไม่ต้องรอคิว) ในทุกๆ วินาที GPT-Live จะตัดสินใจว่าจะฟังต่อ พูดต่อ หรือหยุดชะงัก ทำให้คุณสามารถพูดแทรกผู้ช่วยได้ในขณะที่กำลังตอบ หรือถามคำถามต่อเนื่องได้โดยไม่ต้องรอให้รอบการตอบกลับเสร็จสมบูรณ์

อธิบายการทำงานของ full-duplex stack แบบเข้าใจง่าย

  1. แยก audio loop และ reasoning path ออกจากกัน – fast path จะจัดการการรับส่งเสียงอย่างต่อเนื่อง ในขณะที่ slow path จะรันงานที่หนักกว่า เช่น การค้นหาเว็บหรือการเรียกใช้เครื่องมือ (tool calls) โดย fast path จะช่วยให้การสนทนาดำเนินต่อไปได้ในขณะที่ slow path กำลังทำงาน ช่วยขจัดช่วงเวลา "เงียบงันขณะกำลังคิด" ที่น่าเบื่อหน่ายออกไป
  2. โปรโตคอล WARP – การเชื่อมต่อเว็บแบบดั้งเดิมต้องมีการทำ handshake หลายครั้งก่อนที่เสียงจะไหลเวียนได้ ซึ่งมักต้องมีการรับส่งข้อมูลไป-กลับถึงหกครั้ง โปรโตคอลที่ OpenAI พัฒนาขึ้นเองจะยุบขั้นตอนเหล่านั้นให้เหลือเพียงการรับส่งข้อมูลเพียงครั้งเดียว ทำให้การเริ่มเซสชันรู้สึกรวดเร็วแทบจะในทันที
  3. เลือกใช้ Go แทน Python เพื่อความเสถียรของ latency – ทีมงานได้ย้ายส่วนประกอบแบบ real-time จาก Python ซึ่งโดดเด่นเรื่องการพัฒนาที่รวดเร็ว ไปเป็น Go ซึ่งให้เวลาในการประมวลผลที่คาดการณ์ได้มากกว่า ในด้าน Voice AI ค่าความหน่วงในกรณีที่แย่ที่สุด (worst-case delay) มีความสำคัญมากกว่าความเร็วเฉลี่ย เพราะการสะดุดเพียงครั้งเดียวก็สามารถทำลายความรู้สึกสมจริงได้ ดังนั้นความเสถียรของ latency จึงเป็นสิ่งที่สำคัญกว่า
  4. การขยายระบบที่มากกว่าแค่ GPU – เมื่อมีผู้ใช้หลายร้อยล้านคน คอขวดได้เปลี่ยนจากหน่วยประมวลผลของโมเดลไปอยู่ที่โครงสร้างพื้นฐานโดยรอบ OpenAI พบว่า CPU และลิงก์เครือข่ายเกิดการอิ่มตัว (saturated) ก่อน GPU พวกเขาจึงเพิ่มการจัดการเส้นทาง (routing) และการจัดการการเชื่อมต่อที่ชาญฉลาดขึ้น เพื่อให้ GPU ได้รับข้อมูลอย่างต่อเนื่องโดยไม่สร้างภาระหนักเกินไปให้กับส่วนประกอบอื่นๆ ในระบบ

สิ่งนี้หมายถึงอะไรสำหรับนักพัฒนา

  • แยกการจัดการเสียงออกจาก business logic – รักษา loop ที่มีน้ำหนักเบาและทำงานตลอดเวลาเพื่อประมวลผลอินพุตจากไมโครโฟนและเอาต์พุตจากลำโพง ส่วนงานใดก็ตามที่รอได้ เช่น การคิวรีฐานข้อมูล หรือการเรียกใช้ API ภายนอก ให้แยกไปไว้ใน thread หรือ service อื่น
  • ให้ความสำคัญกับความเสถียรของ latency – วัดเวลาการตอบสนองโดยมุ่งเน้นไปที่ความล่าช้าในกรณีที่แย่ที่สุด มากกว่าแค่ค่าเฉลี่ย ภาษาและ runtime ที่ให้การควบคุมการจัดตารางงาน (scheduling) ได้ละเอียดกว่า (เช่น Go, Rust) อาจคุ้มค่ากับความพยายามในการเขียนโปรแกรมที่เพิ่มขึ้น
  • ลดภาระการเชื่อมต่อ (connection overhead) – ทุกๆ handshake ที่เพิ่มขึ้นจะสะสมเป็นมิลลิวินาทีที่มากขึ้น การรวมการยืนยันตัวตน (authentication), การเจรจาสตรีม (stream negotiation) และการเลือก codec เข้าไว้ในการแลกเปลี่ยนข้อมูลเพียงครั้งเดียว จะทำให้ผู้ใช้สัมผัสได้ถึงความแตกต่าง

ข้อแลกเปลี่ยนและคำถามที่ยังไม่มีคำตอบ

การออกแบบแบบ full-duplex เพิ่มความซับซ้อนในการทำงาน

สิ่งที่ต้องติดตามต่อไป