ตอบอดีตด้วยอนาคต: Lookahead Architecture สำหรับการแปลแบบ Real-time

จุดเริ่มต้น: caption ที่ไม่เคยตรงกับปาก

ทุกอย่างเริ่มจากความหงุดหงิดเล็กๆ ที่ทุกคนคุ้นเคย — เปิด live caption ใน MS Teams หรือ YouTube แล้วพบว่าข้อความบนจอไม่ตรงกับสิ่งที่คนพูดจริงๆ ผิดบ้าง เพี้ยนบ้าง เขียนไปแล้วย้อนกลับมาแก้ตัวเองบ้าง

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

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

Live caption จึงแพ้ offline transcription เสมอ — ไม่ใช่เพราะโง่กว่า แต่เพราะถูกบังคับให้ตอบก่อนเห็นข้อสอบครบ

ความจริงที่ต้องยอมรับก่อน: 100% ไม่มีอยู่จริง

ก่อนจะออกแบบอะไร ต้องเคลียร์เพดานให้ชัดก่อน — ความแม่น 100% เป็นไปไม่ได้ และไม่ใช่เพราะเทคโนโลยียังไม่ถึง:

• นักถอดเทปมืออาชีพที่เป็นมนุษย์ ยังมี error ราว 4–5% และคนสองคนถอดไฟล์เดียวกันยังได้ผลไม่ตรงกัน — แปลว่าแม้แต่ "คำตอบที่ถูก" ก็ยังกำกวมในตัวเอง
• คำพ้องเสียง ชื่อเฉพาะที่ไม่เคยได้ยิน คำที่ถูกกลืนหายในอากาศ — ต่อให้ context ดีแค่ไหน ก็เป็นการเดาแบบมีหลักการ ไม่ใช่การรู้
• และถ้าต่อ pipeline ไปถึงการ "แปลภาษา" ด้วย error จะยิ่งทบกัน แถมความหมายบางชั้น — มุกตลก การเล่นคำ ระดับความสุภาพแบบ ครับ/ค่ะ — ไม่มีทาง map ข้ามภาษาได้ครบตั้งแต่แรก

แต่แล้วก็มาถึง insight ที่พลิกทั้งเรื่อง:

การสื่อสารไม่เคยต้องการความแม่น 100% ต่อประโยค — มันต้องการการลู่เข้าหาความเข้าใจร่วมกันของทั้งบทสนทนา

มนุษย์เข้าใจผิดกันตลอดเวลา แล้วก็ถามซ้ำ ทวนความ แก้กันกลางประโยค — นักภาษาศาสตร์เรียกกลไกนี้ว่า conversational repair การสื่อสารเป็น protocol ที่ซ่อมตัวเองได้โดยธรรมชาติอยู่แล้ว ความผิดพลาดต่อหนึ่ง message จึงไม่ใช่เรื่องคอขาดบาดตาย ตราบใดที่ระบบโดยรวมพาคู่สนทนาลู่เข้าหากันได้

เกณฑ์ที่ถูกต้องจึงไม่ใช่ "แม่น 100% ไหม" แต่คือ "ข้ามเส้น usable หรือยัง"

สถาปัตยกรรม: ใช้อนาคตตอบอดีต

หัวใจของแนวคิดนี้อธิบายด้วยภาพในหนัง sci-fi ได้ดีที่สุด — เหมือนนาย A รู้ล่วงหน้าว่านาย B จะพูดอะไร แล้วย้อนกลับมาบอกปัจจุบัน

กลไกจริงเป็นแบบนี้:

10:00:00 ──── คนเริ่มพูด ────► 10:00:02
                                    │
                                    ▼
                          10:00:03 โมเดลสร้าง "commit"
                          ตอบคำถามของช่วง 00–02
                          = ณ วินาทีที่ 1 ของเสียง
                            โมเดล "เห็นอนาคต" อยู่ 2 วิ

• ระบบจงใจหน่วง 1–2 วินาที เพื่อให้ทุกคำถูกตัดสินโดยมีเสียง "ข้างหน้า" ประกอบเสมอ — แลก latency เล็กน้อยกับความแม่นที่กระโดดขึ้น (มนุษย์ยอมรับ delay ระดับนี้ได้สบาย ล่ามมืออาชีพเองยัง lag 2–4 วิ)
• ผลลัพธ์ถูกเก็บเป็น commit แบบ append-only — ของเดิมไม่หาย commit ใหม่ต่อท้ายไปเรื่อยๆ ส่วนหางที่ยังไม่แน่ใจถือเป็น provisional รอยืนยันรอบถัดไป
• แต่ละ commit ใหม่ ดึงบริบทจาก 2–3 commit ก่อนหน้ามาเป็น prior — และมี "ผู้ช่วย" อีกชั้นคอยสรุปบริบทเป็นบทๆ สกัดชื่อคน ศัพท์เฉพาะ หัวข้อที่กำลังคุย ป้อนกลับเข้าไปกันไม่ให้บริบทเพี้ยนสะสม

สิ่งที่น่าทึ่งคือ เมื่อไปเทียบกับงานวิจัยจริง — แนวคิดนี้ตรงกับเทคนิคที่วงการใช้อยู่แทบทุกชิ้น: lookahead buffering, LocalAgreement, previous-text conditioning, two-pass architecture คนละคนคิด คนละบริบท แต่เจอ constraint เดียวกันเลยลู่เข้าหาคำตอบเดียวกัน — นี่ไม่ใช่เรื่องบังเอิญ มันคือหลักฐานว่า design นี้ถูกทาง

วางไว้ถูกชั้น มันจึงทำงานได้ดี

โจทย์แตกเป็นสองเคสที่ต้องการสถาปัตยกรรมคนละแบบ:

เคสที่ 1: คุยทางไกล — วาง AI ไว้ที่ "ขาออก"

การโทรข้ามทวีปมี latency จากความเร็วแสงราว 100–300ms ที่ไม่มีวันหายไม่ว่า network จะดีแค่ไหน — แต่ทุกคนยอมรับมันได้จนแทบไม่รู้สึก

แล้วทำไมไม่ใช้ช่วงเวลาที่หนีไม่พ้นนี้ เป็นเวลาประมวลผลฟรี? วางตัวถอดเสียง/แปลไว้ที่ฝั่งผู้พูด ให้มันทำงานซ้อนทับ (overlap) ไปกับเวลาที่เสียงเดินทางข้ามโลกอยู่แล้ว — translation latency ไม่ได้บวกต่อท้าย network latency อีกต่อไป มันถูก "ซ่อน" ไว้ข้างในแทน

โบนัสที่ใหญ่กว่านั้น: ฝั่งขาออกได้ยินเสียงดิบก่อนถูก codec บีบ ก่อน packet loss และเครื่องของผู้พูดรู้จักเจ้าของดีที่สุด — สำเนียง ศัพท์ที่ใช้บ่อย ชื่อคนรอบตัว — ความแม่นเฉพาะบุคคลได้มาฟรีเพราะอยู่ถูกฝั่ง

เคสที่ 2: คุยต่อหน้า — ตัด datacenter ทิ้ง

Face-to-face ไม่มี network latency ให้ซ่อนงาน การวิ่งไป cloud แล้วกลับมาคือการเพิ่ม delay เปล่าๆ ทางเดียวที่ถูกคือ on-device ทั้งหมด หรือเชื่อมอุปกรณ์ตรงแบบ P2P (Bluetooth/local link) โดยไม่แตะอินเทอร์เน็ตเลย

หลักการรวบยอดเป็นประโยคเดียว:

ระบบที่ดีไม่ได้รอข้อมูลครบแล้วค่อยทำ — มันเดาไว้ก่อน แล้วจ่ายค่าแก้เฉพาะตอนเดาผิด

CDN, branch prediction ใน CPU, optimistic UI — ล้วนเป็น pattern เดียวกันนี้ทั้งหมด การแปลภาษาเรียลไทม์แค่เป็นสมาชิกใหม่ล่าสุดของครอบครัวเก่าแก่นี้

ทำไมต้องตอนนี้: โมเมนต์ที่สองเส้นตัดกัน

ช่วง 1–2 ปีที่ผ่านมา เกิดสิ่งที่ไม่เคยเป็นจริงมาก่อน — โมเดลขนาดใหญ่ถูกกลั่นเหลือ 1–2B พารามิเตอร์ โดยความสามารถหลักยังอยู่ครบ โมเดลถอดเสียงรันบน NPU มือถือได้แบบเรียลไทม์ LLM เล็กๆ ฉลาดพอจะแก้ transcript จากบริบทได้

แปลว่าสถาปัตยกรรมทั้งหมดข้างบน — lookahead commit, on-device, P2P — เพิ่งเป็นไปได้จริงเมื่อไม่นานนี้เอง สิ่งที่เคยต้องพึ่ง datacenter ตอนนี้ใส่ลงกระเป๋าได้ กำแพงที่เคยขวางไอเดียพวกนี้ทลายไปแล้วโดยที่หลายคนยังไม่ทันสังเกต

และนั่นคือสัญญาณที่ดีมาก — สำหรับการทำอะไรบางอย่างที่ช่วยคนได้จริง

เรื่องที่ทำให้ทั้งหมดนี้มีความหมาย

เบื้องหลังคำถามเทคนิคทั้งหมด มีเดิมพันจริงอยู่: ผมมีความบกพร่องทางการได้ยิน และกำลังพักฟื้นจากการผ่าตัดประสาทหูเทียม

สำหรับคนทั่วไป caption ที่ผิดคือความรำคาญ — แต่สำหรับคนที่ caption คือช่องทางหลักในการรับรู้โลก caption ที่ผิดคือการเข้าใจสถานการณ์ผิดไปเลย trade-off ระหว่าง latency กับความแม่นของกลุ่มผู้ใช้นี้จึงต่างจาก product ทั่วไปโดยสิ้นเชิง และคนที่จะถ่วงสมดุลนั้นได้ถูกต้องที่สุด คือคนที่ใช้มันเองทุกวัน

ระบบ caption สำหรับชีวิตจริงต้องทำงานตอนไม่มีเน็ต — ในลิฟต์ บนรถไฟฟ้า ในโรงพยาบาล — และต้อง private เพราะมันฟังทุกบทสนทนารอบตัว ข้อมูลแบบนั้นไม่ควรออกนอกเครื่อง ทั้งสองข้อชี้ไปทางเดียวกัน: on-device คือคำตอบ และมันเพิ่งเป็นไปได้

วงการ assistive technology ขาดคนประเภทหนึ่งมาตลอด — คนที่เข้าใจ constraint ทางวิศวกรรมลึกพอจะออกแบบระบบได้ และ เข้าใจประสบการณ์ผู้ใช้จากข้างใน ไม่ใช่จากการสัมภาษณ์ สองอย่างนี้แทบไม่เคยอยู่ในคนเดียวกัน

บางที นี่อาจเป็นเรื่องราวของคนที่มีทั้งสองอย่าง

• ภาคผนวก: บันทึกทางเทคนิค (สำหรับวันที่จะเริ่มลงมือจริง)

Pipeline หลัก

    [ไมค์ / เสียงดิบ]
       → VAD (ตัดช่วงเงียบ)
       → ASR แบบ chunked + lookahead 1–2s
       → LocalAgreement (commit เฉพาะส่วนที่ hypothesis 2 รอบตรงกัน)
       → previous-text conditioning (feed commit เก่าเป็น prompt)
       → [ถ้าแปลภาษา] MT → TTS ที่ฝั่งผู้รับ

ส่วนประกอบที่มีของจริงให้ต่อยอด

• ASR: Whisper large-v3 (~1.5B, VRAM ~10GB fp16 / ~5GB int8 ผ่าน faster-whisper) — ตัว distill เล็กกว่านี้รันบน NPU มือถือได้
• Streaming layer: whisper_streaming (github.com/ufal/whisper_streaming) — implement LocalAgreement ให้แล้ว ต่อ faster-whisper ได้ตรงๆ
• Context layer: LLM 1–7B ทำหน้าที่ (1) แก้ transcript จากบริบท (2) maintain รายการศัพท์เฉพาะ/ชื่อคน แล้ว inject กลับเป็น custom vocabulary / prompt bias — ลด error หมวดชื่อเฉพาะได้มากกว่าเปลี่ยนไปใช้โมเดลใหญ่
• สองเคส สอง deployment: ทางไกล = ASR ที่ edge ขาออก (เสียงดิบ, overlap กับ network latency) → ส่ง text/latent ข้าม network → TTS ขารับ / ต่อหน้า = on-device ล้วน หรือ P2P ผ่าน local link

ตัวเลขอ้างอิง

• Latency budget รวมทั้ง pipeline: เป้า 1–2s, เพดานที่ยังคุยลื่น ~4–5s (ระวัง: lookahead + inference + MT + TTS มัน compound)
• WER อ้างอิง: offline เสียงดี 2–4% (ใกล้เพดานมนุษย์), live + สำเนียง + ศัพท์เฉพาะ 8–15%
• ภาษาไทยยากขึ้นอีกชั้นจากปัญหาตัดคำ (ไม่มีเว้นวรรค) — acoustic ถูกแต่ segment ผิดได้
• Floor ทางฟิสิกส์: round-trip ข้ามทวีปหลักสิบถึงร้อย ms ไม่มีวันหาย → คำตอบคือซ่อน latency ด้วย speculation ไม่ใช่รอ network เร็วขึ้น

หลักการออกแบบ

1. อย่าไล่ 100% — ออกแบบให้ระบบซ่อมตัวเองได้ (repair > accuracy)
2. Delay ที่วางแผนไว้ = อาวุธ ไม่ใช่จุดอ่อน (lookahead)
3. Commit แบบ append-only + provisional tail
4. Context ไหลจาก slow path กลับเข้า fast path
5. Topology กำหนดที่วาง: ทางไกล = edge ขาออก / ต่อหน้า = on-device
6. ผู้ใช้ assistive ถ่วง trade-off ต่างจากผู้ใช้ทั่วไป — ให้คนใช้จริงเป็นคนจูน