ตอนที่พวกมันกำลังคิด มันแทบจะเหมือนคนหูหนวกและตาบอด พวกมันไม่สามารถรับรู้สิ่งอื่นใดที่กำลังเกิดขึ้นได้เลย -
ผมรู้สึกงงมากที่ voice agent ส่วนใหญ่ยังคงตัดสินใจจากข้อความถอดเสียง (transcript)
ทุกสายจะถูกแปลงจากเสียงเป็นข้อความก่อนที่ "thinking layer" ของ agent จะมองเห็น การแปลงนั้นทำให้ข้อมูลสูญหาย เหลือรอดแค่คำพูดเท่านั้น ความลังเล เสียง "อืม..." ระดับเสียงที่ตกต่ำลงตอนท้ายประโยค เสียงรบกวนในพื้นหลัง หรือการหันไปพูดกับคนอื่นกลางคัน ทั้งหมดนี้หายไปหมด
agent จึงต้องเดาเอาเอง มันชอบพูดแทรกคนกลางความคิด รอนานเกินไปหลังจากอีกฝ่ายพูดจบ และมองข้ามความโกรธที่ซ่อนอยู่ในประโยคสุภาพ ๆ
ผมคิดว่านี่คือช่องโหว่ที่ใหญ่ที่สุดของ Voice AI ในปัจจุบัน
บทความนี้คือมุมมองของผมต่อสถานการณ์ที่เป็นอยู่ และจะพาไปสำรวจคำถามเหล่านี้:
- Agent จะตัดสินใจได้ดีไหม ถ้ามันไม่เคยได้ยินเสียงสนทนาเลย?
- ทำไมเครือข่าย LLM ถึงยังอุดช่องโหว่นี้ไม่ได้?
- ทำไมไม่ใช้โมเดล speech-to-speech ไปเลย?
- "Thinking layer" ที่ฟังเสียงได้จริง ๆ หน้าตาจะเป็นแบบไหน?
ตลาดตอนนี้อยู่จุดไหน?
https://x.com/jordan_dearsley/status/2085602471918064064
หลายปีที่ผ่านมา ผู้คนคาดการณ์ว่าเสียงจะกลายเป็นวิธีสากลในการพูดคุยกับซอฟต์แวร์ ในปี 2026 คำทำนายนั้นเริ่มเป็นจริงแล้ว AI กำลังจัดการโทรศัพท์ทางธุรกิจนับพันล้านสายในแต่ละปี ต้องขอบคุณบริษัทอย่าง @ElevenLabs และ @DeepgramAI รวมถึง ผลิตภัณฑ์ Voice AI มากกว่า 800 ตัว
แต่ก็เหมือนช่วงแรกของคลื่นเทคโนโลยีทุกลูก การนำไปใช้งานเติบโตเร็วกว่าคุณภาพ มีองค์กรเพียงประมาณ หนึ่งในห้า เท่านั้นที่พอใจกับ agent ที่ใช้งานจริงในระบบอย่างมาก ดังนั้น agent ส่วนใหญ่จึงยึดติดกับสิ่งที่จ่ายไหวและไว้ใจได้ นั่นคือการโทรออกตามสคริปต์ หรือรับสายที่มีคำขอเรียบง่ายพอจะคาดเดาได้
Voice agent เกือบทั้งหมดทำงานแบบเรียงลำดับ (cascaded): แปลงเสียงเป็นข้อความ (STT) แล้วส่งให้ LLM จากนั้นแปลงข้อความเป็นเสียง (TTS) วิศวกรชอบดีไซน์นี้เพราะเลือกโมเดลที่ดีที่สุดสำหรับแต่ละงานได้ อ่านขั้นตอนระหว่างทางได้ทุกขั้น และควบคุมได้อย่างรัดกุมว่า agent จะพูดหรือทำอะไร
แม้ว่า STT และ TTS จะพัฒนาไปไกลมาก ทั้งเรื่องความหน่วงและต้นทุน แต่ส่วนที่ยังอ่อนแอคือ thinking layer
ข้อความถอดเสียงทิ้งอะไรไปบ้าง
หน้าที่ของ thinking layer นั้นเรียบง่าย คือรู้ว่าบทสนทนาอยู่ในสถานะไหน และเลือกการกระทำที่จะพาไปสู่สถานะถัดไปที่ถูกต้อง: พูด, ลงมือทำ, ส่งต่อ, หรือฟังต่อไป
โค้ดของคุณรู้เสมอว่าการโทรอยู่ในขั้นตอนไหนของ workflow แต่สิ่งที่มันไม่รู้คือเกิดอะไรขึ้นกับคนที่อยู่อีกปลายสาย นั่นคือส่วนที่ thinking layer ต้องอ่านให้ออกในทุก ๆ รอบการสนทนา:
- ผู้ใช้พูดจบแล้ว หรือแค่หยุดพักหายใจ?
- พวกเขากำลังพูดภาษาอะไร?
- พวกเขาแค่สงสัย หรือกำลังหัวเสียกับบริการแย่ ๆ?
- นั่นเสียงทีวีในพื้นหลัง หรือเสียงเด็ก ๆ กำลังเล่นกัน?
- พวกเขากำลังคุยกับฉัน หรือคุยกับแฟนของเขา?
- พวกเขาต้องการอะไร: ขอเงินคืน, เปิดบัญชีใหม่, หรือเช็กสถานะ?
คลิปเสียงสองคลิปที่มีข้อความถอดเสียงเหมือนกันเป๊ะว่า "Yes, go ahead." คลิปหนึ่งพูดกับ agent อีกคลิปพูดกับคนอื่นในห้อง มีแค่เสียงเท่านั้นที่แยกสองกรณีนี้ได้
ข้อที่เป็นตัวหนาข้างบนบอกเราว่า พูดอย่างไร ไม่ใช่แค่ พูดอะไร ข้อความถอดเสียงเก็บคำพูดไว้ แต่ทิ้งระดับเสียง จังหวะ การหยุดพัก และสภาพแวดล้อมรอบข้างไป
ลองดูคำถามแรก เราทุกคนรู้ดีว่าคนใกล้จะพูดจบตั้งแต่ก่อนที่ความเงียบจะมาถึง: ระดับเสียงตกลง จังหวะช้าลง เสียงค่อย ๆ แผ่วลง โมเดลที่ได้ยินเสียงจะเรียนรู้การใช้สัญญาณเหล่านี้ได้แม่นยำ (Ekstedt & Skantze, 2022) แต่โมเดลที่อ่านแค่ข้อความถอดเสียงทำไม่ได้ เพราะจังหวะจะโคนเหล่านั้นไม่เคยถูกเขียนลงไป (Rajaa, 2026
เช่นเดียวกับคำถามที่ห้า ตอนที่ Apple ทดสอบ ว่าคำพูดนั้นตั้งใจพูดกับผู้ช่วยของมันหรือไม่ การเพิ่มข้อมูลเสียงเข้าไปในข้อความถอดเสียงช่วยลดข้อผิดพลาดได้ถึง 39% เมื่อเทียบกับการใช้ข้อความอย่างเดียว
การตัดสินใจที่ดีที่สุดต้องใช้ทั้งเสียงและข้อความประกอบกัน แต่น่าเสียดายที่ agent ทุกวันนี้ได้แค่ข้อความ
ใช้แค่ข้อความถอดเสียง: 74.8% ของรอบสนทนาถูกพูดแทรกเร็วเกินไป ใช้เสียง: เหลือ 7.8% Uniphore, arXiv 2609.11066.
ทำไมเครือข่าย LLM ถึงไปชนกำแพง
วิศวกรเลือกทางลัดแบบตะกละเพื่อสร้าง "thinking layer" พวกเขาวิ่งเข้าหาเส้นทางที่ง่ายที่สุดและให้ผลตอบแทนทันทีสูงสุด: จ้าง LLM ระดับท็อปสุดของยุคนั้นมา แล้วโยนคู่มือเล่มยักษ์บอกวิธีทำทุกอย่างให้มัน นี่คือเรื่องราวทั้งหมดของปี 2023-24
แต่มันมีปัญหาอยู่สองสามอย่าง
- อย่างแรก ทีมต่างตระหนักว่า LLM คาดเดาได้ยากและทำงานช้า แถมยัง ทำคำสั่งหล่นหายเมื่ออยู่ใน prompt ที่ยาวและอัดแน่น
- อย่างที่สอง การเรียกใช้ LLM เพียงครั้งเดียวไม่พอที่จะเข้าใจประโยคที่คนพูดออกมา
ดังนั้นก้าวต่อไปที่สมเหตุสมผลคือเครือข่าย LLM ที่เร็วขึ้นและถูกลง: แต่ละตัวรับผิดชอบงานต่างกัน โดยมี orchestrator คอยคุมอยู่ด้านบน เดโมออกมาสวยงามมาก ลูกค้าประทับใจ และรายได้ก็เริ่มไหลเข้ามา
นี่คือ frontier stack ในปัจจุบัน
แต่เมื่อนำไปใช้งานจริง สถาปัตยกรรมนี้ก็เผยรอยร้าวสองจุด:
- ทุกชิ้นส่วนก็ยังอ่านข้อความถอดเสียงชุดเดิม การเพิ่ม LLM เข้าไปไม่ได้ช่วยให้การหยุดพักหรือน้ำเสียงที่ถูกตัดทิ้งไปในข้อความถอดเสียงกลับคืนมาได้
- แต่ละชิ้นส่วนต้องรอซึ่งกันและกัน การเรียกใช้แต่ละครั้งเพิ่มความหน่วง การจับใจความรอบสนทนา ตัดสินใจว่าจะทำอะไร และลงมือทำภารกิจ กินเวลาถึง 80% ของระยะเวลาตอบสนองทั้งหมด
Voice agent แบบ cascaded: เสียงของผู้โทรเข้าจะถูกส่งไปยังระบบแปลงเสียงเป็นข้อความ ตามด้วยการเรียก LLM หลายครั้ง แล้วจึงแปลงข้อความเป็นเสียง ระดับเสียง การหยุดพัก น้ำเสียง พื้นหลัง และตัวบุคคลที่ถูกพูดถึง หายไปตั้งแต่ขั้นตอนแปลงเสียงเป็นข้อความแล้ว
วงการแบ่ง thinking layer ตามประเภทงาน แต่ควรแบ่งตามประเภทอินพุตมากกว่า: การตัดสินใจที่ต้องใช้สัญญาณเสียงควรส่งไปให้โมเดลที่ออกแบบมาเพื่อเสียงโดยเฉพาะ (audio-native) และปล่อยให้ LLM ทำงานกับข้อความเท่านั้น
ทำไมไม่ข้ามข้อความถอดเสียงไปเลยล่ะ?
โมเดล Speech-to-speech (STS) เริ่มแสดงสัญญาณชีวิตให้เห็นชัดในปีนี้ เสน่ห์ของมันชัดเจนมาก: ความหน่วงต่ำลง เข้าใจบทสนทนาได้ดีขึ้น และลดงานวิศวกรรมลง ด้วยการบีบรวม STT, LLM และ TTS ไว้ในโมเดลเดียว
ข้อเสียที่ใหญ่ที่สุดคือการขาดการควบคุมและข้อมูลที่ตรวจสอบได้ คุณไม่สามารถระบุแน่ชัดว่าโมเดล STS จะพูดอะไร และการเรียกใช้เครื่องมือ (tool calls) หรือการรันโค้ดไม่ใช่เรื่องธรรมชาติสำหรับโมเดลที่คิดด้วยเสียง
ผมคิดว่า STS ยังห่างไกลจากความเป็นจริงในระยะสั้น แม้ว่ามันจะพัฒนาเร็วขึ้น แต่ก็คงเหมาะกับ use case เรียบง่าย ๆ อย่างการตอบคำถาม FAQ ก่อนเป็นอันดับแรก นักพัฒนาจะยังคงอยู่กับระบบ cascaded ต่อไป ส่วนหนึ่งเพราะความเคยชิน แต่ส่วนใหญ่เป็นเพราะพวกเขาต้องการการควบคุมและความยืดหยุ่นที่ระบบนี้มี
นั่นคือเหตุผลที่ผมกำลังสร้างโมเดลที่ทำให้ stack แบบ cascaded ควบคุมได้ง่ายขึ้น และสามารถนำไปใช้งานได้จริงทั้งในแง่ต้นทุนและความหน่วง
เลเยอร์ที่รับฟัง
ผมเชื่อว่ามีวิธีควบคุม agent และกำจัดความเทอะทะออกไปได้ นั่นคือ decision models
ถ้าคุณสังเกต GPT-Live ดี ๆ จะพบ decision engine อยู่ที่แกนกลางของมัน หลายครั้งต่อวินาที มันตัดสินใจว่าจะพูด ฟังต่อ หยุดพัก พูดแทรก หรือเรียกใช้เครื่องมือ ระบบ cascaded ก็ต้องการ engine แบบเดียวกัน ในฐานะคอมโพเนนต์ที่คุณมองเห็นและควบคุมได้
Decision model รับสถานะปัจจุบันและชุดตัวเลือกที่กำหนดขอบเขตไว้ (พูดหรือรอ, ส่งต่อหรือทำต่อ, เจตนาไหน) แล้วคืนค่าตัวเลือกเดียวพร้อมความน่าจะเป็น ซึ่งเร็วกว่าและถูกกว่า LLM มาก @typesafeai ทำให้หลายคนประหลาดใจกับผลลัพธ์ที่ยอดเยี่ยมเมื่อใช้วิธีนี้กับข้อความ
ผมขอเสนอแบบนี้:
- Decision model รับฟังการโทรและทำการตัดสินใจที่อยู่ในขอบเขต
- ซอฟต์แวร์ของคุณ ดูแลสถานะ workflow สิทธิ์การเข้าถึง และเครื่องมือต่าง ๆ
- LLM ทำสิ่งที่มันเก่งที่สุด: เขียนคำตอบ หลังจากที่ตัดสินใจได้แล้วว่าจะทำอะไร
Decision model รับข้อมูลเสียง บทสนทนาที่เกิดขึ้นจนถึงตอนนี้ และชุดตัวเลือก แล้วคืนค่าความน่าจะเป็นของแต่ละตัวเลือกออกมา เช่น refund_status 0.91, cancel_order 0.06, escalate 0.03 (ตัวอย่าง)
คะแนนความมั่นใจคือสิ่งที่ทำให้ระบบนี้ทำงานได้ ลองถาม LLM ว่ามันแน่ใจแค่ไหน มันมักจะตอบว่า "แน่ใจมาก" แม้ตอนที่มันผิดก็ตาม (Xiong et al., 2024) แต่คะแนนของ classifier สามารถจูนจนมีความหมายตรงกับที่มันบอกได้: เมื่อ classifier บอกว่าแน่ใจ มันก็มักจะแน่ใจจริง ๆ (Guo et al., 2017
การทดลองเบื้องต้นของเรากับพาร์ทเนอร์ด้านการออกแบบแสดงให้เห็นว่า 30 ถึง 40% ของสิ่งที่ LLM ทำภายใน agent คืองานประเภทนี้พอดี: การจัดเส้นทาง การคัดกรองความเร่งด่วน และการเลือกระหว่างตัวเลือกที่มีขอบเขตชัดเจน
แต่ decision model ในปัจจุบันทำงานกับข้อความหรือรูปภาพ TypeSafe AI รายงาน ว่าทุกโมเดล รวมถึง Jev ด้วย ตัดสินใจได้แย่ลงเมื่อเพิ่ม modality อื่นเข้ามาคู่กับข้อความ และ Jev ก็ยังไม่มีการรองรับข้อมูลเสียงอย่างเป็นทางการ
คุณไม่สามารถแปะระบบเสียงเข้าไปใน decision model สำหรับข้อความเฉย ๆ ได้ การสร้างโมเดลที่รับฟังเสียงได้จริงต้องอาศัยสามสิ่งนี้:
- เสียงสนทนาจริงที่มีการติดป้ายกำกับ (label) ว่าเป็นการตัดสินใจที่ถูกต้องในแต่ละช่วงเวลา
- โมเดลที่ตัดสินใจโดยใช้ทั้งเสียงและข้อความประกอบกัน
- คะแนนความมั่นใจที่ยังคงเชื่อถือได้ไม่ว่าจะเจอสำเนียง เสียงรบกวน หรือสัญญาณโทรศัพท์แย่ ๆ แค่ไหน
Decision model ที่เหมาะสำหรับเสียงคือโมเดลที่รับฟังได้จริง ซึ่งเป็น decision layer แบบ audio-native
อะไรจะเปลี่ยนไปเมื่อ decision layer ได้ยินเสียง
คุณจะปลดล็อก use case เหล่านี้ได้ด้วย decision model แบบ audio-native:
- Agent ที่คุณสามารถ debug ได้. ตอนนี้หลายทีมออกแบบ agent เป็นกราฟของสถานะ: ทักทาย, ยืนยันตัวตน, จัดการคืนเงิน, ส่งต่อเรื่อง แต่ละรอบการสนทนาลงเอยด้วยการตัดสินใจสองอย่าง: บทสนทนาอยู่ในสถานะไหนจริง ๆ และควรย้ายไปสถานะไหนต่อ? ถ้าพลาดอย่างใดอย่างหนึ่ง การโทรทั้งสายก็จะหลุดทิศทางไปเลย
เมื่อมี decision model อยู่ในทุกขั้นตอน การเปลี่ยนผ่านแต่ละครั้งจะกลายเป็นหน่วยย่อยที่อธิบายได้: ได้ยินอะไร มีตัวเลือกอะไรบ้าง เลือกอะไรไป และมั่นใจแค่ไหน เวลาที่การโทรเกิดปัญหา คุณไม่ต้องมานั่ง debug prompt ขนาดยักษ์ คุณแค่หาฟันเฟืองตัวที่ลื่นหลุดแล้วซ่อมเฉพาะจุดนั้น
- คำตอบที่พร้อมก่อนผู้โทรจะพูดจบ. คนเรามักเผยสิ่งที่ต้องการก่อนจะพูดจบประโยค "ฉันโทรมาเรื่องออเดอร์ที่สั่งไปเมื่อสัปดาห์ก่อน..." แค่นี้ก็คือการค้นหาออเดอร์แล้ว Agent ที่เน้นข้อความจะรอให้ผู้ใช้หยุดพูด รอข้อความถอดเสียงสุดท้าย ตัดสินใจว่าจะเรียกเครื่องมือไหน แล้วถึงจะเรียกใช้ ทุกขั้นตอนล้วนเพิ่มความเงียบเข้าไป
ไทม์ไลน์ของผู้โทรที่พูดว่า "ฉันโทรมาเรื่องออเดอร์ของฉันเมื่อสัปดาห์ก่อน" Agent ที่เน้นข้อความจะรอจนจบ แล้วจึงถอดเสียง ตัดสินใจ และเรียก get_order แต่ router ที่รับฟังเสียงจะยิงคำสั่ง get_order ตั้งแต่กลางประโยค และตอบกลับทันทีที่ผู้โทรหยุดพูด ช่วยประหยัดเวลาได้
Decision model ที่รับฟังเสียงจะทำหน้าที่เป็น router ที่ชิงดำเนินการก่อนการโทรจบ มันจับเจตนาได้ตั้งแต่กลางประโยคและยิงคำสั่งค้นหาขณะที่ผู้ใช้ยังพูดอยู่ เพื่อให้รายละเอียดออเดอร์พร้อมทันทีที่พวกเขาหยุดพูด
นักวิจัยจาก Meta และ CMU ได้แสดงให้เห็นถึงผลลัพธ์: การคาดการณ์การเรียกใช้เครื่องมือแบบขนานไปกับเสียงพูดของผู้ใช้ ช่วยลดความหน่วงของเครื่องมือลง 20% และทำให้คำตอบแม่นยำขึ้น
- Personal agent ที่ให้ความรู้สึกฉับไว. Personal agent รับฟังคำสั่งผ่านโน้ตเสียงตลอดทั้งวัน ทั้งในครัว ในรถ และบนถนนที่วุ่นวาย สิ่งที่มันได้ยินส่วนใหญ่ต้องการการตัดสินใจอย่างรวดเร็วเพียงครั้งเดียว: นี่เป็นงาน เป็นการแจ้งเตือน เป็นความคิดแวบขึ้นมา หรือไม่ได้พูดกับฉันเลย?
การส่งทุกประโยคไปให้ frontier LLM นั้นช้าและแพง โมเดลขนาดเล็กที่รับฟังเสียงได้จะตัดสินใจเรื่องนี้ได้ในเวลาที่น้อยกว่ามาก และจะปลุก LLM ขึ้นมาก็ต่อเมื่อมีงานจริง ๆ ให้ทำเท่านั้น Agent จึงให้ความรู้สึกฉับไว เพราะการตัดสินใจครั้งแรกไม่ต้องรอโมเดลตัวใหญ่เลย
https://x.com/signulll/status/2077444321243013306
อนาคตของ Voice AI
เสียงควรจะเป็นอินเทอร์เฟซสากล แต่วันนี้มันใช้งานได้เฉพาะตอนที่บทสนทนานั้นคาดเดาได้เท่านั้น
แต่บทสนทนาที่ไม่มีสคริปต์ก็ไม่ได้ไร้ขอบเขต ในทุกรอบการสนทนา การกระทำที่สมเหตุสมผลมีอยู่ไม่กี่อย่าง: พูด, รอ, ถาม, ลงมือทำ, ส่งต่อ สิ่งที่ไม่ใครเขียนสคริปต์ไว้ได้คือลำดับเหตุการณ์ คุณไม่จำเป็นต้องเขียนสคริปต์บทสนทนาเพื่อควบคุมมัน คุณแค่ต้องตัดสินใจแต่ละครั้งให้ดี จากสิ่งที่คุณได้ยินจริง ๆ
นั่นคือการเปลี่ยนแปลงที่ผมวางเดิมพันไว้: ตัดสินใจก่อน แล้วค่อย prompt โมเดลที่รับฟังเสียงเป็นคนตัดสินใจ ซอฟต์แวร์ของคุณรักษาสถานะ และ LLM เขียนถ้อยคำ ทุกการตัดสินใจมองเห็นได้ รวดเร็ว และวัดผลได้ เมื่อสิ่งนี้ทำงานได้ เสียงจะไม่เป็นแค่ช่องทางสำหรับการโทรธรรมดา ๆ อีกต่อไป แต่จะกลายเป็นวิธีที่ผู้คนใช้พูดคุยกับซอฟต์แวร์
ผมกำลังสร้าง decision layer นั้นอยู่ที่ @tazolabs และจะแชร์ข้อมูลเพิ่มเติมเกี่ยวกับโมเดลของเราในอีกไม่กี่วันข้างหน้า
ถ้าคุณสร้าง voice agent ผมอยากฟังมากว่าทุกวันนี้ agent ของคุณตัดสินใจเรื่องไหนพลาดบ่อยที่สุด และถ้าคุณอินกับวิสัยทัศน์นี้ มาร่วมสร้างมันไปกับเราที่ Tazo Labs ได้เลย
การตัดสินใจเรื่องไหนที่ voice agent ของคุณทำพลาดบ่อยที่สุด?
