Show HN: บอตเสียงที่ตอบสนองใน 500ms

 (fastvoiceagent.cerebrium.ai)
1 คะแนน โดย GN⁺ 2024-06-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • AI เสียงควรตอบสนองได้ทันทีเหมือนการสนทนาทั่วไปจึงจะรู้สึกเป็นธรรมชาติ เดโมนี้จึงตั้งเป้า การตอบสนองแบบเสียง-ต่อ-เสียงที่ 500ms
  • ความท้าทายหลักคือการลด เวลาแฝง ที่ผู้ใช้รู้สึกได้ ซึ่งได้รับผลกระทบจากทั้งเครือข่ายและเวลาประมวลผลของโมเดล
  • เดโมแสดงให้เห็นว่า การโต้ตอบกับ LLM แบบเวลาแฝงต่ำ สามารถไปได้ไกลแค่ไหนผ่านวิธีการปรับแต่งและการดีพลอย
  • การพัฒนาใช้ Pipecat เฟรมเวิร์กโอเพนซอร์สสำหรับ AI สนทนาแบบเสียงและมัลติโมดัล
  • หากต้องการสร้างบอตเสียงสนทนาในระดับผลิตภัณฑ์จริง ไม่ใช่แค่ประสิทธิภาพของโมเดลเท่านั้นที่สำคัญ แต่การจัดการเวลาแฝงตลอดเส้นทางการเรียกทั้งหมดก็สำคัญเช่นกัน

เดโมที่มุ่งสู่การตอบสนองด้วยเสียงใน 500ms

  • The World's Fastest Voice Bot Demo เป็นเดโมที่แสดงให้เห็นว่าแชตบอต AI แบบใช้เสียงสามารถตอบสนองได้เร็วเพียงใด
  • เป้าหมายคือการทำให้ได้ เวลาในการตอบสนองแบบ voice-to-voice 500ms
  • ผู้คนคาดหวังการตอบกลับที่รวดเร็วในการสนทนาทั่วไป ดังนั้นความเร็วจึงกลายเป็นปัจจัยคุณภาพหลักของอินเทอร์เฟซ AI แบบเสียง

แนวทางการพัฒนาเพื่อลดเวลาแฝง

  • เดโมนี้สร้างขึ้นโดยเน้น การโต้ตอบกับ LLM แบบเวลาแฝงต่ำ
  • แสดงให้เห็นความเป็นไปได้ของแชตบอต AI เสียงที่ได้รับการปรับแต่งและดีพลอยเพื่อลดเวลาแฝงของเครือข่ายและเวลาแฝงของโมเดลให้น้อยที่สุด
  • บอตถูกสร้างด้วย Pipecat
    • Pipecat เป็น เฟรมเวิร์กโอเพนซอร์ส สำหรับ AI สนทนาแบบเสียงและมัลติโมดัล

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-06-28
ความคิดเห็นใน Hacker News

  • เร็วมาก ยอดเยี่ยมและเรียบร้อยดี รู้สึกว่า ความเร็ว ชนะทุกอย่างจริง ๆ กว่าจะรู้สึกตัวว่าเสียงฟังดูเหมือนหุ่นยนต์ก็หลังจากอ่านคอมเมนต์แล้ว
    เคยทำ AI สำหรับงานซัพพอร์ตลูกค้า ซึ่งลดเวลาตอบกลับเฉลี่ยจาก 24–48 ชั่วโมงเหลือไม่กี่วินาที
    มีข้อความแบบ “Hello Bitch, your package will be picked up by USPS today...” ถูกส่งไปให้ลูกค้ารายหนึ่ง แต่ลูกค้าตอบกลับว่า “thank you so much” และให้คะแนน CSAT เต็ม แม้จะพลาดหนักขนาดนี้ ความเร็วก็ชนะทุกอย่าง

    • คิดว่าทุกคนคงไม่ได้ตอบสนองแบบนั้น สำหรับบางคน การเรียกกันว่า bitch อาจเป็นสำนวนพูดปกติจนเข้าไปอยู่ในข้อมูลฝึกได้ แต่สำหรับคนอื่นอาจไม่ใช่เลย
    • ที่ตลกคือพวกเขาแก้ปัญหานี้ด้วยการเพิ่ม แท็ก #profanity แล้วส่งต่อข้อความให้เจ้าหน้าที่คนถัดไป
      แต่กลายเป็นว่าเซลส์เอนจิเนียร์ที่แอคทีฟที่สุดไม่สามารถเดโมให้ลูกค้าเป้าหมายได้อีกต่อไป มีสายที่น่าอึดอัดจำนวนมากที่ AI ไม่ตอบอะไรเลย เพราะนามสกุลของเขาคือ Dick
    • ทางแก้อาจเป็นการส่งข้อความผ่าน LLM อีกตัวเพื่อกรองคำหยาบออกและทำให้สุภาพที่สุดเท่าที่จะทำได้ แต่ดูเหมือนต้นทุนการรันจะมากกว่า 2 เท่า
    • บางทีนั่นอาจเป็นชื่อลูกค้าก็ได้ อย่างน้อยก็อาจเป็นชื่อที่ลูกค้ากรอกไว้แบบนั้น

  • ดีมาก ๆ ถ้าเข้าใจถูก มันดูเหมือนแอปทีเซอร์เพื่อโชว์ Cerebrium แต่มีศักยภาพเป็น killer app สูง ตอนทดสอบบน iPad latency ที่รายงานอยู่ระหว่าง 1400ms ถึง 400ms และที่ค่าต่ำ ๆ ให้ความรู้สึกลื่นไหลมาก
    ถ้าเร็วได้ระดับนี้ ในบาง workflow ของแชตน่าจะจำเป็นหรือเป็นไปได้ที่จะใช้แนวทางหลายขั้นตอน เช่น ตอบกลับอย่างรวดเร็วก่อน ระหว่างที่รัน query ข้อมูล/สารสนเทศ/RAG ที่ยาวกว่าแยกไป แล้วให้ผลลัพธ์ที่มีข้อมูลตามมารับช่วงต่อ
    มนุษย์ก็ทำงานแบบนี้เหมือนกัน เริ่มตอบไปพร้อมกับจัดระเบียบความคิด จึงใช้ คำเติมช่องว่าง หลายแบบ
    ตอนนี้ส่วนใหญ่คือโยนพรอมป์ตครั้งเดียว หรือทำแบบ parse→query→generate ในเบื้องหลัง แต่ถ้าตอบสนอง latency ต่ำได้ flow ที่ดีกว่าน่าจะใกล้เคียงกับ “[Llama 8B ข้างหู 3 วินาที] → query → [Llama 70B/GPT-4 ฯลฯ ความยาว 55 วินาทีที่สะท้อนผล query]”

    • จากฝั่ง Cerebrium ขอบคุณมากสำหรับ feedback และดีใจที่เป็นประสบการณ์ที่ดี
      แอปพลิเคชันนี้ขยายหรือ implement ได้ง่าย จึงปรับแก้ได้ตามต้องการ สามารถเปลี่ยนเป็น LLM, speech recognition, speech synthesis รุ่นอื่น เปลี่ยนพรอมป์ต หรือ implement สิ่งอย่าง RAG ได้
      เราโฟกัสที่วิศวกรร่วมกับ Daily เป้าหมายคือให้ปรับแอปพลิเคชันได้ยืดหยุ่นมากตาม use case และความชอบ พร้อมลดภาระการตั้งค่า infrastructure ที่น่าเบื่อ
      ดูวิธีขยายเพิ่มเติมได้ที่นี่: https://docs.cerebrium.ai/v4/examples/realtime-voice-agents
    • ผมก็สงสัยเรื่องนี้เหมือนกัน เป็นไปได้ไหมที่จะมี LLM ขนาดเล็กและมีประสิทธิภาพที่ประเมิน ความซับซ้อนของงาน โดยทั่วไปได้ โดยไม่ต้องรัน workload จริงทั้งหมด?
      ถ้าให้คะแนนความซับซ้อนเป็นค่าต่อเนื่องได้ ก็จะรู้ว่าควรส่งคำตอบอย่าง “ได้ครับ รอสักครู่ เดี๋ยวผมหาให้” ออกไปก่อน แทนที่จะรอ round trip ยาว ๆ หรือไม่

  • สำหรับโมดูล ตรวจจับกิจกรรมเสียง บนเบราว์เซอร์แบบข้ามแพลตฟอร์ม มี https://github.com/ricky0123/vad ซึ่งเป็นการพอร์ตเครือข่าย VAD ของ Silero ไปเป็น ONNX คำว่าข้ามแพลตฟอร์มในที่นี้หมายถึงทำงานบน Firefox ได้ด้วย แค่เข้าถึงไมโครโฟนก็พอ ไม่ต้องมี WebRTC session จึงง่ายกว่า น่าสนใจเหมือนกันถ้าเบราว์เซอร์จะมีฟีเจอร์นี้เป็นตัวเลือก native
    มีเอนจิน text-to-speech บนเบราว์เซอร์อยู่แล้ว และมันก็เร็วขึ้นกับคุณภาพดีขึ้นเรื่อย ๆ ถ้าเบราว์เซอร์มี TTS ที่ยอดเยี่ยมติดตั้งมาเป็นค่าเริ่มต้นก็คงดี
    GPT-4o ใส่การรู้จำเสียงอัตโนมัติ ความเข้าใจ และการสร้างเสียงตอบกลับไว้ในโมเดลเดียวเพื่อ latency ต่ำ ซึ่งดูเป็นไอเดียที่ค่อนข้างดี การที่ยังไม่ปล่อยออกมา แปลว่าน่าจะมีปัญหาด้าน scalability หรือคุณภาพในรูปแบบใดรูปแบบหนึ่ง
    น่าจะมีคนที่กำลังสร้าง multimodal LLM แบบเปิดที่รวมทั้งอินพุต/เอาต์พุตเสียงและอินพุตภาพในลักษณะคล้ายกันด้วย
    ในแง่การปรับ latency และต้นทุนให้อเหมาะสม ผมสงสัยว่า โมเดลเดี่ยวแบบผูกเข้าด้วยกัน จำเป็นและเหมาะสมที่สุดแค่ไหน
    ตาราง breakdown ที่ให้มาน่าสนใจ ถ้าเป็นไปได้ ดูเหมือนว่าจะดีกว่าถ้ารันโมเดลให้มากขึ้นบนอุปกรณ์ ทั้งการสร้างเสียง และอาจรวมถึงการถอดเสียงหรือความเข้าใจเสียงช่วงต้นด้วย ใครจะอยากรอ STUN กันล่ะ?

    • ผมคิดว่าสภาพแวดล้อมเดสก์ท็อปควรให้บริการ speech-to-text ผ่าน service ที่มีอินเทอร์เฟซมาตรฐาน เหมือน stdin แต่เป็นอินเทอร์เฟซแยกสำหรับเสียง
      แอปโดยปกติจะไม่ได้ฟังอยู่จึงจะเพิกเฉย แต่ตัวถอดเสียงสามารถสลับเปลี่ยนได้และใช้ได้กับทุกแอป
    • ถ้าตัวเลขเป็นตามนี้ ต่อให้ประมวลผลการรู้จำเสียงและการสังเคราะห์เสียงบนอุปกรณ์ หากส่วนที่เหลือยังเหมือนเดิมก็ลดได้แค่ 120ms เท่านั้น อีก 639ms ที่เหลือมาจากฮาร์ดแวร์·network latency และการย้ายข้อมูลเข้าออก LLM ก็ยังช้ากว่าที่ต้องการอยู่ดี
      โดยตรรกะแล้วควรคิดในหน่วย หน่วยเสียง เอาต์พุตของ LLM ต้องไล่ทันหน่วยเสียงสุดท้ายให้เร็วพอ เพื่อให้ทันทีที่ตรวจพบจุดสิ้นสุดก็สามารถตอบกลับได้ “ทันที” และเพื่อทำแบบนั้น ทั้ง chain ต้องมี end-to-end latency ราว 200ms
      ถ้าจะเข้าใกล้จุดนั้น คงต้องใช้สถาปัตยกรรมแบบอื่น คล้ายการประมวลผลเสียงของมนุษย์ คือวิ่งนำ audio stream ไปตามหน่วยเสียงที่คาดการณ์ไว้ก่อนมันมาถึง แล้วใช้เสียงที่รับเข้าจริงเป็นเพียงสัญญาณตรวจสอบแบบเบา ๆ เพื่อตัดสินใจว่าจะปล่อยบัฟเฟอร์เอาต์พุตปัจจุบันหรือประมวลผลใหม่
      speculative decoding อาจพาไปได้ระดับหนึ่ง แต่ pipeline ที่ผสม audio/text น่าจะทำได้ยาก ตั้งแต่แรก การไม่แปลงเสียงเป็นข้อความแล้วแปลงกลับเป็นเสียงอีกจะดีกว่ามาก
    • การประกาศนี้ทำให้สิ่งที่ผมกำลังทำอยู่โดนกลบไปหมดก็จริง แต่ผมมี implementation ผู้ช่วยแบบง่าย ๆ ที่ใช้ rick0123/VAD กับ WebSocket อยู่
      https://github.com/charlesyu108/voiceai-js-starter

  • ลองใช้เองแล้วสนุกดี ช่วงต้นสัปดาห์นี้ได้ลอง june-va แต่เวลาตอบสนองที่ยาวทำให้ความมีประโยชน์ลดลงไปพอสมควร การตอบสนองที่รวดเร็วเป็นฟีเจอร์ที่ยอดเยี่ยม และอันนี้ให้ความรู้สึกเหมือนเป็น การสนทนา มากกว่ามาก
    ที่ตลกคือพอขอให้เล่าเรื่อง มันตอบทีละประโยคเท่านั้น เลยต้องพูดว่า “yes”, “aha”, “please continue” เพื่อฟังบรรทัดถัดไป
    แล้วก็มีบทสนทนาแบบนี้ “อ๋อ ฉันคิดว่ารู้ความลับของคุณแล้ว!” “บอกมาได้เลยครับ/ค่ะ” “คุณรักษาบริบทให้สั้นเพื่อให้ได้เวลาตอบสนองที่สั้นใช่ไหม” “ถูกต้องเลยครับ/ค่ะ”

    • พูดตรง ๆ วิธีนั้นก็โอเคนะ นอกจากบริบทสั้นแล้ว คำตอบสั้น ก็เป็นเรื่องดีแน่นอน ตรงข้ามกับโหมดเสียงของ ChatGPT ตอนนี้ที่พอถามอะไรสักอย่าง ก็ต้องฟังคำตอบยืดยาวสไตล์ GPT เป็นนาที

  • น่าประทับใจมาก เร็วมาก และอาจจะเร็วเกินไปด้วยซ้ำ แต่นั่นคงเป็นประเด็นหลัก สิ่งที่น่าประทับใจที่สุดคือวิธีที่ VAD และการจัดการการพูดแทรก ถูกปรับให้เข้ากัน เท่าที่เคยคุยกับเอเจนต์มา ฟังดูเป็นธรรมชาติที่สุดอย่างชัดเจน ถ้าเปิดให้ใช้เมื่อไหร่ อยากลองใช้แน่นอน

  • ในการตลาดเขียนไว้ว่า 500 แต่คำนวณออกมาได้ 759

    • นั่นแหละที่เรียกว่าการตลาด
    • ในการทดสอบของผมมี outlier หนึ่งครั้งที่ 1400ms และประมาณ 10 ครั้งอยู่ระหว่าง 400~500ms ตัวเลขทางการตลาดดูยุติธรรมดี
    • 500 คือช่วงขั้นตอนถอดเสียง/LLM/TTS หรือเวลาตั้งแต่ข้อมูลมาถึงเซิร์ฟเวอร์จนส่งคำตอบกลับไป ส่วนที่เหลือดูเหมือนเป็น ดีเลย์เสริม ที่ไม่ใช่ AI หลายอย่าง เช่น การเข้ารหัสและทราฟฟิกเครือข่าย
    • latency ในตารางอิงจากฮิวริสติกหรือค่าเฉลี่ยที่สังเกตได้ ในความเป็นจริง องค์ประกอบ latency ที่ใหญ่กว่าบางส่วนอาจต่ำลงมากได้ตามบทสนทนา

  • ผมเองก็ตั้งตารอ การอนุมานด้วยเสียง เหมือนกัน ก่อน OpenAI เปิดตัว GPT-4o ผมทำ implementation ของ Faster Whisper บน WebSocket เอง คอนเซ็ปต์โค้ชสัมภาษณ์ของผม https://intervu.trueforma.ai และโค้ชซ้อม sales pitch https://sales.trueforma.ai ถูกพวกเขากลบไปหมด
    ผมทำให้ VAD ทำงานได้เสถียรไม่ได้ เลยตั้งค่าเริ่มต้นเป็น push-to-talk ทั้งหมดรันบน LattePanda ผมตั้งใจจะเชื่อม Whisper แบบโฮสต์ของ Groq
    เบื่อบทสนทนาแบบองค์กรที่น่าเบื่อ เลยชอบไอเดียใช้ Llama3 ของ Groq ที่ไม่มีการเซ็นเซอร์เป็น LLM อยากลด latency และเรียนรู้จากตัวอย่าง อยากลองเดโมด้วย แต่ดูเหมือนคนจะเยอะเกินไปจนเข้าไปคุยกับบอตไม่ได้
    ถ้ามีแค่ 3 คนพยายามอนุมานพร้อมกัน LattePanda ของผมน่าจะละลายไปเลย

  • ส่วนตัวผมใช้ https://github.com/foges/whisper-dictation คู่กับ llama-70b ของ Groq
    พอเริ่มพูด แล้วไปที่เว็บไซต์ รอโหลดเสร็จ และเลือก llama-70b ก็พูดจบพอดี ทำให้ เวลารอเพิ่มเติม เป็น 0 เพราะการอ่านเร็วกว่าการฟังมาก สำหรับผมจึงเข้ากันได้อย่างสมบูรณ์แบบ

  • ยังใช้ Firefox อยู่

    • ผมเป็นคนทำ UI ฝั่งไคลเอนต์นี้ และอยากรองรับ Firefox จริง ๆ
      จากมุมมองผู้ใช้ปลายทาง เราต้องมีวิธีวัด latency แบบเสียงต่อเสียง และผมเห็นว่า Silero voice activity detection (https://github.com/snakers4/silero-vad) น่าเชื่อถือที่สุดสำหรับตรวจจับว่าผู้ใช้หยุดพูดเมื่อไหร่เพื่อเริ่มจับเวลา และหยุดจับเวลาเมื่อมีเสียงจากบอตเข้ามา
      Silero รันด้วย onnx-runtime และ wasm ใน Firefox ก็พอทำงานได้ระดับหนึ่ง แต่ VAD ทำงานผิดพลาดบ่อยกว่าที่คาด ทำให้ตัวเลข latency ค่อนข้างแปลก ถึงอย่างนั้นก็อยากทำให้มันใช้งานได้จริง และยังพยายามอยู่
      โค้ด UI VAD อยู่ที่นี่: https://github.com/pipecat-ai/web-client-ui/tree/main/src/va...
    • ไม่ต้องเชื่อแค่ข้อความเตือนก็ได้ บน Firefox รุ่นล่าสุดทำงานได้ดี เดโมก็เจ๋งมาก
    • ไม่ชอบที่ทุกคนพัฒนามุ่งแต่ Chromium
    • คิดว่าใน HN น่าจะมีคนใช้ Firefox ค่อนข้างเยอะ
    • บน Firefox 127 ทำงานได้สมบูรณ์แบบ

  • น่าประทับใจจริง ๆ
    Siri ของ Apple ยังทำได้แค่บทสนทนาระดับที่พูดทับกัน หยุดชะงัก ล้มเหลว แล้วสุดท้ายก็ได้แต่หวังว่าจะได้คำตอบขั้นต่ำสุด