ทำไม AI ถอดเสียงถึงฟังศัพท์เทคนิคผิด (และเราแก้มันอย่างไร)

วันที่ 2 กรกฎาคม เราเปิดเซสชันทดสอบและถาม GeekBye ด้วยเสียงพูดด้วยคำถามง่ายๆ: "What is the pointer in C++?" (pointer ใน C++ คืออะไร?)

ทรานสคริปต์สดตอบกลับมาเป็นบทกวี:

[23:16:37] You: Tell me, what is the point in life? [23:16:52] You: Handy Plus. [23:17:02] You: What the pointer in Plus Plus? [23:17:09] You: C.

"pointer in C++" (พอยน์เตอร์ในภาษา C++) กลายเป็น "point in life" (ความหมายของชีวิต) ไปเสียอย่างนั้น เมตริกสุขภาพของเซสชันเดียวกันเล่าเรื่องที่เหลือ: การเชื่อมต่อถอดเสียงหลุด 3 ครั้งใน 163 วินาที และช่องโหว่ 51 วินาทีในทรานสคริปต์ และมีเบาะแสอีกหนึ่งอย่างที่ภายหลังกลายเป็นสิ่งสำคัญที่สุด: กระบวนการกู้คืนหลังจบเซสชันของเรา — ซึ่งถอดเสียงจากไฟล์เสียงที่บันทึกไว้ในเครื่องใหม่อีกรอบเพื่อเติมช่องว่าง — ได้ประโยคนั้นเกือบถูก: "a pointer in plus, plus? What the pointer in plus, plus C++."

เสียงไม่มีปัญหาอะไรเลย โมเดลสดแค่ไม่มีเหตุผลให้คาดหวังว่าจะเจอ C++

นี่คือเรื่องราวของ GeekBye v2.0.11 เล่าจากทรานสคริปต์จริงและ log จาก production

ทำไมโมเดลถอดเสียงถึงฟังคำศัพท์ของคุณผิด

การรู้จำเสียงพูดคือปัญหาการทำนาย เมื่อได้รับเสียงที่กำกวม โมเดลจะเลือกคำที่น่าจะเป็นไปได้มากที่สุด — และสำหรับโมเดลแบบ general-purpose วลี "point in life" น่าจะเป็นไปได้มากกว่า "pointer in C++" หลายเท่า วิศวกรทุกคนที่เคยเห็นทรานสคริปต์การประชุมเขียน Kubernetes เป็น "cube and eddies" ล้วนเคยเจอความล้มเหลวแบบนี้มาแล้ว

ทางแก้ไม่ใช่ไมโครโฟนที่ดีกว่า แต่คือ keyterm biasing: การบอกโมเดลก่อนเริ่มเซสชันว่าคำไหนที่ปกติไม่ค่อยเจอ แต่สำหรับคุณมีโอกาสเจอสูง ผู้ให้บริการถอดเสียงของเรารองรับคำ biasing ได้สูงสุด 50 คำต่อเซสชัน และนี่คือส่วนที่น่าอาย: ท่อส่งข้อมูลสำหรับคำเหล่านั้นมีอยู่ครบแบบ end-to-end ใน stack ของเราแล้ว — ไคลเอนต์ backend ผู้ให้บริการ — แต่ไม่เคยมีอะไรใส่ค่าเข้าไปเลย ทุกเซสชันรันโดยไม่มีความช่วยเหลือด้านโดเมนแม้แต่นิดเดียว

Fix 1: โปรไฟล์ของคุณกลายเป็นคลังคำศัพท์ของโมเดล

GeekBye รู้โดเมนของคุณอยู่แล้ว — มันอยู่ในโปรไฟล์ที่คุณเปิดใช้งาน v2.0.11 สกัด keyterms สำหรับ biasing จากชื่อและคำอธิบายของโปรไฟล์: คำที่มีสัญลักษณ์ (C++, Node.js) ตัวย่อ (SQL, AWS) ชื่อแบบ camel-case (TypeScript, PostgreSQL) และชื่อเฉพาะ โปรไฟล์ที่พูดถึง stack ของคุณ ตอนนี้ทำให้ stack นั้นกลายเป็นสิ่งที่โมเดลคาดหวัง ไม่ใช่สิ่งแปลกปลอม

วันที่การแก้ไขทำให้ทุกอย่างแย่ลง

เวอร์ชันแรกของเราถือว่าทุกคำที่ขึ้นต้นด้วยตัวพิมพ์ใหญ่เป็นชื่อเฉพาะ บน internal test build (สิ่งนี้ไม่เคยไปถึงลูกค้า) โปรไฟล์ที่เขียนเป็นความเรียงส่งรายการ biasing ชุดนี้ไปให้โมเดล:

Senior, Writing, Direct, For, Includes, Write, Role, Intent…

การ bias โมเดลถอดเสียงไปหาคำว่า "For" แย่ยิ่งกว่าการไม่ bias เลย ในเซสชันทดสอบถัดมาทันที คำว่า "speak" — ที่พูดชัดๆ หลายครั้ง — กลับมาเป็น "Clicky", "Hey, Vicky" และ "Peter Paderty" บทเรียนนี้แลกมาด้วยเวลาหนึ่งบ่าย: bias ด้วยคำที่มีเอกลักษณ์เท่านั้น ตอนนี้คำขึ้นต้นด้วยตัวพิมพ์ใหญ่จะถูกนับก็ต่อเมื่อปรากฏกลางประโยค (ซึ่งเป็นสัญญาณของชื่อเฉพาะจริงๆ) ส่วนหัวข้อ markdown ที่ทุกคำขึ้นต้นด้วยตัวพิมพ์ใหญ่ จะไม่มีวันถูกนำมาใช้ โปรไฟล์เดิมตอนนี้สกัดออกมาได้ตรงเป๊ะ: LinkedIn, AI, CEO, MCP — และเซสชันตรวจสอบถอดเสียงหลายภาษาที่สลับกันเร็วๆ ได้ถูกต้องต่อเนื่อง 199 วินาทีเต็ม 189 เซกเมนต์ทรานสคริปต์ ข้อผิดพลาดเป็นศูนย์

Fix 2: race condition ที่ทำให้การเชื่อมต่อหลุด

keyterms อธิบายคำที่ฟังผิดได้ แต่อธิบายการเชื่อมต่อหลุดสามครั้งไม่ได้

เส้นทางนั้นนำไปสู่จุดที่ละเอียดอ่อนกว่า ผู้ให้บริการของเรา commit (สรุปผล) การถอดเสียงตาม voice-activity detection ของตัวเอง ประมาณหนึ่งวินาทีหลังเข้าสู่ความเงียบ ไคลเอนต์ของเราก็ส่ง safety commit เช่นกันที่ 250 มิลลิวินาทีหลังเข้าสู่ความเงียบ เพื่อ flush ประโยคค้างที่ยังไม่จบ ส่วนการยืนยันจากผู้ให้บริการว่าได้ commit ไปแล้ว ใช้เวลาหนึ่งถึงสามวินาทีกว่าจะเดินทางกลับมา ลองคำนวณจากตัวเลขสามตัวนั้นดู: เมื่อไรก็ตามที่ผู้ให้บริการ commit ก่อน safety commit ของเราจะยิงใส่บัฟเฟอร์ที่แทบจะว่างเปล่า — และการตอบสนองของผู้ให้บริการต่อเรื่องนั้นไม่ใช่แค่การปฏิเสธอย่างสุภาพ มันตัดการเชื่อมต่อทิ้งเลย ทุกจังหวะหยุดพูดกลายเป็นการโยนเหรียญ

v2.0.11 มาพร้อมการป้องกันสองชั้น:

1. ในแอป: เมื่อทรานสคริปต์ที่ commit แล้วมาถึง ไคลเอนต์จะรู้ว่าบัฟเฟอร์ของผู้ให้บริการเพิ่งถูก flush ไป และข้าม safety commit ที่ซ้ำซ้อนนั้นไป
2. ที่ backend ของเรา ในวันเดียวกัน: proxy ที่อยู่ระหว่างแอปกับผู้ให้บริการ ทำสำเนาระบบบัญชีเสียงของผู้ให้บริการแบบเป๊ะๆ — มันเห็นทุกเฟรมเสียงและทุกการยืนยัน commit โดยไม่มี latency — และปฏิเสธที่จะส่งต่อ commit ใดๆ ที่ผู้ให้บริการจะปฏิเสธอยู่แล้ว ชั้นนี้ปกป้องไคลเอนต์ทุกเวอร์ชันพร้อมกันในครั้งเดียว รวมถึงผู้ใช้ที่ยังไม่ได้อัปเดต

เราเห็นมันทำงานใน production ภายในหนึ่งชั่วโมง guard ดักจับ commit ที่จะพังซึ่งมีเสียงในบัฟเฟอร์เพียง 178ms และ 256ms — ก่อนหน้าวันนั้น แต่ละรายการคือการเชื่อมต่อหลุดแบบการันตี และช่องว่างในโน้ตการประชุมของใครสักคน เซสชันต่อเนื่อง 60 นาทีในบ่ายวันนั้นบันทึกการดักจับได้ 5 ครั้ง และการหลุดเป็นศูนย์ ก่อนการแก้ไข ผู้ใช้จริงคนหนึ่งในเช้าวันเดียวกันต้องรีสตาร์ตการอัดถึงห้าครั้งในหกนาที เพราะสู้กับบั๊กตัวนี้ตัวเดียวเลย

การแก้ไขเล็กๆ อีกสองอย่างที่ติดมาด้วย

AI insights รอจนกว่าจะมีเนื้อหาจริง เศษข้อความเพี้ยนๆ ช่วงต้นเซสชันเคยถูกป้อนเข้า suggestion chips แบบสดของ GeekBye ซึ่งผลิตหัวข้ออย่างมั่นใจ เช่น "Defining Life's Ultimate Purpose" (นิยามเป้าหมายสูงสุดของชีวิต) จากคำถาม C++ ที่ฟังผิด ตอนนี้คำแนะนำจะรอจนกว่าเซสชันจะมีเนื้อหาบทสนทนาจริงมากพอ

ข้อความที่กู้คืนได้ระบุผู้พูดถูกต้อง กระบวนการกู้คืนที่ถอดคำถาม C++ ของเราได้ถูกต้อง กลับระบุว่าเป็นของ "Them" (อีกฝ่าย) ตอนนี้ไทม์ไลน์เสียงที่บันทึกในเครื่องจะบันทึกด้วยว่าใครกำลังพูด ทำให้เซกเมนต์ที่กู้คืนมาระบุเป็น You หรือ Them ได้ถูกต้อง

สกอร์บอร์ด

ตัวชี้วัด (วัดจริง ไม่ใช่ประมาณการ)	ก่อน	หลัง v2.0.11 + backend guard
การเชื่อมต่อหลุดในเซสชันทดสอบ	3 ครั้งใน 163 วินาที	0
ช่องโหว่ทรานสคริปต์ยาวสุด	51 วินาที	ช่องว่างแย่สุด ~6 วินาทีตอนตรวจสอบ
"pointer in C++"	"point in life"	ถูกต้อง ด้วยคำศัพท์ที่ bias แล้ว
commit ที่จะพังซึ่งไปถึงผู้ให้บริการ	ทั้งหมด	0 (ถูกดักจับที่ backend)

ถ้าคุณกำลังพัฒนาบน realtime speech API

บทเรียนสามข้อจากรีลีสนี้ที่นำไปใช้ที่อื่นได้:

1. ป้อนข้อมูลให้ฟีเจอร์ biasing ถ้าผู้ให้บริการ STT ของคุณรองรับ keyterms/phrase hints การใส่คลังคำศัพท์ที่เล็กและมีเอกลักษณ์คือชัยชนะด้านความแม่นยำที่ถูกที่สุดที่หาได้ — และการใส่คำธรรมดาทั่วไปคือการสูญเสียความแม่นยำ
2. อย่าแข่งกับ state machine ของผู้ให้บริการจากฝั่งที่เสียเปรียบของ network round-trip ไคลเอนต์ของเราไม่มีทางชนะการแข่งขันข้อมูลระหว่าง 250ms กับ 3 วินาที guard ควรอยู่ตรงจุดที่สัญญาณทั้งสองมาบรรจบกัน — สำหรับเราคือ backend proxy
3. ตรวจสอบบน live build ก่อนเผยแพร่ regression ของ keyterms ถูกจับได้เพราะทุกรีลีสของ GeekBye ถูกทดสอบในรูปแบบ build ที่ sign และ notarize แล้วกับ production ก่อนปล่อยออกไป เวอร์ชันที่มีปัญหามีชีวิตอยู่แค่ไม่กี่ชั่วโมงบนเครื่องภายในหนึ่งเครื่อง ไม่ใช่บน Mac ของคุณ

GeekBye v2.0.11 ปล่อยแล้วตอนนี้ — ถ้าคุณใช้ v2 อยู่ คุณได้รับมันผ่าน auto-update เรียบร้อยแล้ว สำหรับงานด้านความเสถียรที่เป็นรากฐานของรีลีสนี้ อ่านทำไม AI notetaker ของคุณถึงหยุดทำงานบน Wi-Fi ห่วยๆ และมีอะไรใหม่ใน GeekBye v2 ส่วนวิธีใช้การถอดเสียงสดในชีวิตประจำวัน เริ่มที่การถอดเสียงแบบเรียลไทม์ใน GeekBye