ความหน่วงของการแปลสด อธิบายให้เข้าใจ: เวลาหายไปไหนบ้าง

ความล่าช้าส่วนใหญ่ในการแปลสดคือการรอ ทั้งรอสตรีม รอคำถัดไป และรอจนจบประโยค ส่วนเดียวที่คุณควบคุมได้คือโหมดความหน่วง ว่าจะให้ล่าช้าน้อยลงหรือให้มีการแก้ไขข้อความน้อยลง

ผู้ฟังที่อ่านการแปลสดจะเห็นแต่ละบรรทัดหลังจากผู้พูดพูดไปแล้วหลายวินาที ช่องว่างนั้นไม่ได้มาจากความล่าช้าเพียงอย่างเดียว แต่สะสมกันมาตามลำดับของขั้นตอน และส่วนใหญ่คือการรอรูปแบบหนึ่ง การเข้าใจว่าการรอแต่ละช่วงคืออะไร ทำให้การเลือกโหมดความหน่วงเป็นเรื่องง่าย และช่วยให้นักพัฒนาที่สร้างตัวอ่านรู้ว่าควรแสดงอะไร และเมื่อไร

ก่อนดูตัวเลข ควรมีจุดอ้างอิงไว้ก่อน ล่ามพร้อมกัน (simultaneous interpreter) ที่เป็นมนุษย์มักพูดตามหลังผู้พูดราว 2 ถึง 4 วินาที ล่ามเรียกช่องว่างนี้ว่า ear-voice span และเมื่อทำงานกับภาษาที่กริยาอยู่ท้ายประโยค พวกเขาไม่ได้รอให้ถึงกริยา แต่คาดเดากริยาไว้ล่วงหน้า หรือแบ่งประโยคออกเป็นท่อนที่ยืนอยู่ได้ด้วยตัวเอง ความล่าช้าหนึ่งหรือสองวินาทีจึงไม่ใช่ข้อบกพร่องของซอฟต์แวร์ แต่เป็นระดับที่ล่ามที่เก่งจริงทำได้เช่นกัน

ห่วงโซ่ตั้งแต่ไมโครโฟนจนถึงเสียงพูด

การถอดเสียงสดทุกครั้งบน VocalStack ผ่านขั้นตอนเดิมตามลำดับเดิม และแต่ละขั้นต้องรอขั้นก่อนหน้าเสร็จก่อน

1. จับเสียง เสียงเข้ามาจากไมโครโฟน encoder หรือที่อยู่สตรีมที่ VocalStack ดึงเองโดยตรง
2. ร่าง คำที่เพิ่งพูดจะปรากฏทันทีเป็นร่างที่ยังเปลี่ยนแปลงได้
3. ยืนยัน เมื่อเรียบร้อยแล้ว บรรทัดจะกลายเป็นข้อความสุดท้าย พร้อมเวลาของแต่ละคำ
4. ประโยค การยืนยันถูกนำมารวมเป็นประโยคทั้งประโยค ประโยคจะเปิดอยู่ขณะที่ยังขยายต่อ และปิดเมื่อจบประโยค
5. การแปล ประโยคจะถูกแปลเป็นทุกภาษาของการถ่ายทอดสด
6. เสียงพูด หากผู้ฟังขอฟังคำแปล คำแปลของแต่ละประโยคที่ปิดแล้วจะถูกอ่านออกเสียงเป็นคลิปสั้น ๆ

ผู้อ่านจะเห็นข้อความภาษาต้นฉบับแทบพร้อมกับที่พูด คำแปลตามมาอีกหนึ่งหรือสองวินาที และประโยคที่พูดออกเสียงจะมาหลังคำแปล จึงเป็นเหตุผลที่คลิปเสียงมาถึงเป็นอย่างสุดท้ายเสมอ อย่างไรก็ตาม ผลแรกที่มองเห็นได้ของห่วงโซ่นี้เกิดขึ้นก่อนเสียงพูดมาก นั่นคือตัวข้อความเองที่เริ่มขยับ

ร่างเปลี่ยนได้ ส่วนการยืนยันเป็นที่สุด

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

ตัวรู้จำเสียงจะตัดสินคำหนึ่งโดยดูจากสิ่งที่อยู่หลังคำนั้น "I scream" กับ "ice cream" ฟังเหมือนกันจนกว่าจะได้ยินคำถัดไป และเสียง "s" ท้ายคำอาจเป็นของคำนี้หรือของคำถัดไปก็ได้ ก่อนจะมีเสียงทางขวาของคำ การสะกดของคำนั้นจึงเป็นการคาดเดา ดังนั้นคำที่ใหม่ที่สุดในการถอดเสียงสดจึงไม่แน่นอนที่สุดเสมอ ร่างก็คือการคาดเดานั้นที่แสดงออกมาก่อน แทนที่จะซ่อนไว้

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

สำหรับนักพัฒนา นี่คือกฎเดียวที่ realtime API ยืนกรานอย่างเข้มงวด คือแสดงทุกเซ็กเมนต์ที่ยืนยันแล้ว ตามด้วยร่างล่าสุดหลังเซ็กเมนต์เหล่านั้น และล้างร่างเมื่อมีการยืนยันเข้ามา การต่อท้ายร่างแทนการแทนที่จะทำให้ข้อความซ้ำและกระพริบ การยืนยันจึงกินส่วนท้ายไปเลย บทแนะนำ WebSocket สร้างตัวอ่านขึ้นมาจากหลักการนี้โดยตรง

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

ทำไมการแปลต้องรอจนจบประโยค

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

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

การพูดรอนานกว่านั้นอีก มีเพียงประโยคที่ปิดแล้วเท่านั้นที่ถูกอ่านออกเสียง เพราะประโยคที่ยังเปลี่ยนแปลงอยู่จะถูกสังเคราะห์ใหม่ทุกครั้งที่มีการแก้ไข ประโยคยาวจะถูกอ่านเป็นท่อน ๆ ท่อนแรกจึงเล่นได้ขณะที่ท่อนที่เหลือกำลังถูกสร้าง

เมื่อปิดการแปลประโยค แต่ละการยืนยันจะได้เฟรมคำแปลของตัวเองแทน เส้นทางนี้ไม่ต้องรอสิ่งใด แต่ประโยคทั้งประโยคอ่านได้ดีกว่ามาก

ช่วงรอทั้งหมดนี้วัดจากเวลาที่เสียงมาถึง VocalStack สำหรับการถ่ายทอดหลายรายการ เสียงมาถึงช้ากว่านั้นแล้วตั้งแต่ตอนที่มาถึงระบบ

สตรีมเพิ่มความล่าช้าตรงไหน

เมื่อแหล่งที่มาเป็นสตรีมแทนไมโครโฟน เสียงจะล่าช้าอยู่แล้วก่อนที่จะถูกถอดเสียง เสียงจะตามหลัง live edge ซึ่งคือช่วงเวลาใหม่ที่สุดที่สตรีมเผยแพร่แล้ว

สตรีมเสียง HTTP ธรรมดา ซึ่งเป็นรูปแบบที่สถานีวิทยุออนไลน์ส่วนใหญ่ใช้เผยแพร่ มักตามหลังหนึ่งถึงสามวินาที เซิร์ฟเวอร์เก็บ burst buffer ไว้ คือเสียงล่าสุดไม่กี่วินาทีที่ส่งทั้งหมดในครั้งเดียว เพื่อให้เครื่องเล่นของผู้ฟังรายใหม่เริ่มเล่นได้โดยไม่สะดุด ผู้ฟังทุกคน รวมถึง VocalStack ก็เริ่มฟังย้อนหลังไปในระยะนั้นเท่านั้น HLS แย่กว่า เพราะ playlist เริ่มต้นไคลเอนต์ที่ห่างจาก live edge สามเซ็กเมนต์ ซึ่งในทางปฏิบัติหมายถึงหลายวินาทีไปจนถึงครึ่งนาที ขึ้นอยู่กับความยาวของเซ็กเมนต์ DASH มาตรฐานมักอยู่ในช่วงเดียวกับ HLS มีเพียงรูปแบบ low-latency เท่านั้นที่ต่ำกว่ามาก สตรีม "สด" ของสถานีอาจสดได้ในแบบเดียวกับที่จดหมายฉบับหนึ่งถือว่าเป็นปัจจุบัน

ตัวเลขเหล่านี้เป็นค่าโดยประมาณ และเป็นของสตรีม ไม่ใช่ของการถอดเสียง ไม่มีการตั้งค่าใดฝั่ง VocalStack ที่จะดึงวินาทีเหล่านั้นกลับคืนมาได้ หากวินาทีเหล่านั้นสำคัญสำหรับงานหนึ่ง ให้ป้อนเสียงเข้าสู่ระบบจากไมโครโฟนหรือ encoder แทนสตรีมสาธารณะ ความล่าช้าของสตรีมถูกกำหนดไปแล้วก่อนที่ VocalStack จะได้ยินคำแรก ส่วนโหมดความหน่วงคือสิ่งที่คุณปรับได้จริง

Auto, Fast, Accuracy: การเลือกโหมดความหน่วง

โหมดความหน่วงทำหน้าที่เพียงอย่างเดียว คือกำหนดสมดุลระหว่างความล่าช้ากับความแม่นยำ การตั้งค่าอยู่ภายใต้ Advanced เมื่อสร้างการถอดเสียงสด และอยู่ที่แท็บ Speed ขณะที่กำลังทำงาน ที่นั่นป้ายจะแสดงเป็น AUTO, SPEED หรือ ACCURACY (Fast จะปรากฏเป็น SPEED) ผ่าน API คำสั่ง session.update จะเปลี่ยนโหมดนี้ระหว่างที่สตรีมกำลังทำงาน

• Auto ซึ่งเป็นค่าเริ่มต้น จะหาสมดุลนั้นให้คุณ แท็กบนแดชบอร์ดคือ ADAPTIVE: "The pipeline trades delay against accuracy on its own, line by line."
• Fast ทำให้ความล่าช้าต่ำที่สุดเท่าที่ทำได้ แท็กคือ LOWEST DELAY "Text reaches listeners as fast as the pipeline allows. Accuracy drops on hard audio," เช่นในห้องที่มีเสียงรบกวน
• Accuracy ให้ความสำคัญกับความแม่นยำตลอดทั้งการถอดเสียง แม้จะทำให้ความล่าช้ามากขึ้นก็ตาม แท็กคือ HIGHEST ACCURACY

การแลกเปลี่ยนเป็นไปตามที่ชื่อบอก Fast ส่งข้อความออกไปได้เร็วขึ้น แต่แก้ไขข้อความมากกว่า ส่วน Accuracy ใช้เวลานานขึ้นเล็กน้อยและแก้ไขน้อยลง ผู้ชมที่นั่งอ่านคำบรรยายที่แปลแล้วแทบไม่สังเกตว่ามีความล่าช้าเพิ่มอีกหนึ่งวินาที แต่จะสังเกตได้ทันทีเมื่อคำเปลี่ยนไปเรื่อย ๆ ดังนั้น Accuracy จึงมักเป็นการตั้งค่าที่เป็นมิตรกว่า ตราบใดที่กราฟความล่าช้ายังเรียบ Auto เผยการทำงานของมันออกมา บรรทัดที่มันเร่งขึ้นเพื่อปิดช่องว่างจะมีป้าย FAST MODE ในบันทึกการถอดเสียงของโฮสต์ พร้อมหมายเหตุว่าความแม่นยำอาจต่ำกว่าในบรรทัดนั้น

ไม่ว่าจะเป็นโหมดใด การถอดเสียงต้องพร้อมก่อนคำแรก และการเตรียมความพร้อมนั้นคือความล่าช้าเพียงอย่างเดียวที่ห่วงโซ่จ่ายเพียงครั้งเดียว

การเริ่มต้นแบบเย็น

บางแพ็กเกจใช้เวลาไม่กี่วินาทีก่อนที่การถอดเสียงสดจะเริ่มทำงาน ระยะเวลาขึ้นอยู่กับแพ็กเกจ: แถว Start-up speed ในหน้า หน้าราคา ไล่ตั้งแต่การเริ่มแบบเย็นสูงสุด 15 วินาทีในแพ็กเกจจ่ายตามการใช้งาน ไปจนถึงแบบอุ่นตลอดเวลาในแพ็กเกจ Enterprise

ผ่าน API การรอนี้จะปรากฏเป็นเฟรม session.loading ขณะที่เซสชันเริ่มทำงาน แล้วตามด้วย session.ready ไคลเอนต์จะส่งเสียงหลังจากนั้นเท่านั้น ผู้ฟังที่เปิดลิงก์ระหว่างนี้จะเห็นข้อความว่า "Live. The first line appears in a moment." เมื่อการถอดเสียงทำงานแล้ว ความล่าช้าช่วงนี้ก็ผ่านไป และคำถามเดียวที่เหลือคือคุณกำลังแบกความล่าช้าที่เหลืออยู่มากแค่ไหน

อ่านค่าความล่าช้า

ขณะที่การถอดเสียงสดกำลังทำงาน แท็บ Speed ของโฮสต์จะแสดงผลรวมทั้งหมดนี้ คือช่องว่างปัจจุบันระหว่างผู้พูดกับข้อความ พร้อมป้ายโหมดอยู่ข้าง ๆ และกราฟของช่องว่างนั้นตลอดการบันทึก พร้อมค่าเฉลี่ยและค่าสูงสุด ในตัวการถอดเสียงเอง บรรทัดที่ไปถึงผู้ฟังช้าจะมีป้ายแสดงจำนวนวินาทีระหว่างตอนที่พูดกับตอนที่ไปถึง

กราฟที่ต่ำและเรียบหมายความว่าโหมดนั้นเหมาะกับเสียง กราฟที่ไต่ขึ้นหมายความว่าระบบกำลังตามไม่ทัน ในโหมด Accuracy นั่นอาจเป็นจังหวะที่ควรเปลี่ยนไปใช้ Auto ซึ่งแลกความแม่นยำบางส่วนเพื่อความเร็ว จนกว่าช่องว่างจะปิดลง

สำหรับนักพัฒนา จะได้ตัวเลขเพียงค่าเดียวแทน เมื่อเซสชันแบบเรียลไทม์จบลง session.done จะมี stats.realtimeFactor ซึ่งคือความยาวของเสียงที่ถอดแล้ว หารด้วยเวลาที่ใช้ในการถอดเสียงนั้น ข้อควรระวังเรื่องข้อตกลงการวัด: ในเอกสารการรู้จำเสียงพูด real-time factor มักหมายถึงค่ากลับกัน คือเวลาประมวลผลหารด้วยความยาวเสียง และค่าที่น้อยกว่าดีกว่า VocalStack รายงานกลับด้านจากนั้น ดังนั้นที่นี่ค่าที่สูงกว่าจึงดีกว่า เซสชันสดจะอยู่ใกล้ 1 และค่าต่ำกว่า 1 หมายความว่าเสียงมาถึงเร็วกว่าที่ระบบจะถอดได้ทัน

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