Mengapa Transkripsi AI Tersalah Dengar Istilah Teknikal (dan Bagaimana Kami Membetulkannya)

Pada 2 Julai kami menjalankan sesi ujian dan bertanya kepada GeekBye satu soalan mudah secara lisan: "What is the pointer in C++?"

Transkrip langsungnya menjawab dengan puisi:

[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.

Dalam sesi yang sama, metrik kesihatan menceritakan selebihnya: 3 sambungan transkripsi terputus dalam 163 saat dan lubang 51 saat dalam transkrip. Dan satu lagi petunjuk yang akhirnya paling penting: proses pemulihan pasca-sesi kami — yang mentranskripsi semula audio yang disimpan secara setempat untuk mengisi jurang — hampir mendapat ayat itu dengan betul: "a pointer in plus, plus? What the pointer in plus, plus C++."

Audionya elok sahaja. Cuma model langsung itu tiada sebab untuk menjangkakan C++.

Inilah kisah GeekBye v2.0.11, diceritakan daripada transkrip sebenar dan log pengeluaran.

Mengapa model pertuturan tersalah dengar perbendaharaan kata anda

Pengecaman pertuturan ialah masalah ramalan. Apabila diberikan audio yang kabur, model memilih perkataan yang paling berkemungkinan — dan bagi model tujuan umum, "point in life" (makna hidup) ialah frasa yang jauh lebih berkemungkinan daripada "pointer in C++" (pointer dalam C++). Setiap jurutera yang pernah melihat transkrip mesyuarat menulis Kubernetes sebagai "cube and eddies" sudah kenal kegagalan ini.

Penyelesaiannya bukan mikrofon yang lebih baik. Penyelesaiannya ialah keyterm biasing: memberitahu model, sebelum sesi bermula, perkataan luar biasa yang manakah sebenarnya biasa bagi anda. Penyedia pertuturan kami menyokong sehingga 50 istilah biasing bagi setiap sesi. Bahagian yang memalukan: saluran untuk istilah-istilah itu memang wujud hujung ke hujung dalam stack kami — klien, backend, penyedia — dan tiada apa-apa yang pernah mengisinya. Setiap sesi berjalan tanpa sebarang bantuan domain.

Pembetulan 1: profil anda menjadi perbendaharaan kata model

GeekBye sudah tahu domain anda — ia ada dalam profil aktif anda. v2.0.11 menerbitkan keyterm biasing daripada nama dan perihalan profil: istilah dengan simbol (C++, Node.js), akronim (SQL, AWS), nama camel-case (TypeScript, PostgreSQL), dan kata nama khas. Profil yang menyebut stack anda kini menjadikan stack itu dijangka dan bukannya eksotik.

Hari apabila pembetulan itu memburukkan segala-galanya

Versi pertama kami menganggap setiap perkataan berhuruf besar sebagai kata nama khas. Pada satu build ujian dalaman (ini tidak pernah sampai kepada pelanggan), profil yang ditulis dalam bentuk prosa menghantar senarai biasing ini kepada model:

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

Membiaskan model pertuturan ke arah perkataan "For" lebih teruk daripada tidak membiaskannya langsung. Dalam sesi ujian yang berikutnya, perkataan "speak" — disebut dengan jelas, berkali-kali — kembali sebagai "Clicky", "Hey, Vicky", dan "Peter Paderty". Pengajaran itu merugikan kami satu petang: bias hanya dengan istilah yang distinktif. Perkataan berhuruf besar kini hanya dikira apabila muncul di tengah ayat (isyarat kata nama khas yang tulen); tajuk markdown, yang setiap perkataannya berhuruf besar, tidak pernah menyumbang. Profil yang sama itu kini menerbitkan tepat LinkedIn, AI, CEO, MCP — dan sesi pengesahan mentranskripsi audio berbilang bahasa yang bertukar pantas dengan betul selama 199 saat berturut-turut, 189 segmen transkrip, sifar ralat.

Pembetulan 2: perlumbaan yang memutuskan sambungan

Keyterm menjelaskan perkataan yang tersalah dengar. Ia tidak menjelaskan tiga sambungan yang terputus.

Jejak itu membawa ke tempat yang lebih halus. Penyedia kami meng-commit (memuktamadkan) transkripsi berdasarkan pengesanan aktiviti suaranya sendiri, kira-kira satu saat selepas senyap. Klien kami juga menghantar commit keselamatan 250 milisaat selepas senyap, untuk mengosongkan ayat separa yang tergantung. Pengesahan daripada penyedia bahawa ia sudah meng-commit mengambil masa satu hingga tiga saat untuk sampai kembali. Kiralah sendiri tiga nombor itu: setiap kali penyedia meng-commit dahulu, commit keselamatan kami dilepaskan terhadap penimbal yang hampir kosong — dan tindak balas penyedia terhadapnya bukan sekadar penolakan yang sopan. Ia memutuskan sambungan. Setiap jeda pertuturan ialah lambungan syiling.

v2.0.11 membawa dua lapisan pertahanan terhadapnya:

1. Dalam aplikasi: apabila transkrip yang sudah di-commit tiba, klien kini tahu penimbal penyedia baru sahaja dikosongkan dan melangkau commit keselamatan yang berlebihan itu.
2. Dalam backend kami, pada hari yang sama: proksi yang berada antara aplikasi dan penyedia mencerminkan perakaunan audio penyedia dengan tepat — ia melihat setiap bingkai audio dan setiap pengesahan commit dengan kependaman sifar — dan terus enggan memajukan sebarang commit yang akan ditolak oleh penyedia. Lapisan ini melindungi semua versi klien serentak, termasuk pengguna yang belum mengemas kini.

Kami melihatnya berfungsi dalam pengeluaran dalam masa sejam. Pengawal itu memintas commit gagal yang membawa 178ms dan 256ms audio yang ditimbal — setiap satunya, sebelum hari itu, bermakna sambungan terputus yang pasti dan jurang dalam nota mesyuarat seseorang. Sesi berterusan 60 minit pada petang itu mencatatkan lima pintasan dan sifar sambungan terputus. Sebelum pembetulan, seorang pengguna sebenar pada pagi yang sama telah memulakan semula rakamannya lima kali dalam enam minit melawan pepijat yang sama ini.

Dua pembetulan kecil yang turut serta

Insight AI kini menunggu isi. Serpihan awal yang kucar-kacir itu dahulunya menyuap cip cadangan langsung GeekBye, yang dengan penuh yakin menghasilkan topik seperti "Defining Life's Ultimate Purpose" daripada soalan C++ yang tersalah dengar. Cadangan kini menunggu sehingga sesi mempunyai jisim perbualan yang sebenar.

Teks yang dipulihkan mendapat penutur yang betul. Proses pemulihan yang mentranskripsi soalan C++ kami dengan betul telah mengaitkannya dengan "Them". Garis masa audio yang disimpan secara setempat kini merekodkan siapa yang sedang bercakap, jadi segmen yang dipulihkan dikaitkan dengan betul kepada You atau Them.

Papan mata

Metrik (diukur, bukan anggaran)	Sebelum	Selepas v2.0.11 + pengawal backend
Sambungan terputus dalam sesi ujian	3 dalam 163s	0
Lubang transkrip terpanjang	51s	jurang terburuk ~6s semasa pengesahan
"pointer in C++"	"point in life"	betul, perbendaharaan kata yang dibias
Commit gagal yang sampai kepada penyedia	kesemuanya	0 (dipintas di backend)

Jika anda membina di atas API pertuturan masa nyata

Tiga pengajaran boleh pindah daripada keluaran ini:

1. Suapkan ciri biasing itu. Jika penyedia STT anda menyokong keyterm/phrase hint, mengisinya dengan perbendaharaan kata yang kecil dan distinktif ialah kemenangan ketepatan paling murah yang ada — dan mengisinya dengan perkataan biasa ialah kerugian ketepatan.
2. Jangan sekali-kali berlumba dengan state machine penyedia dari sisi yang salah pada satu perjalanan pergi-balik rangkaian. Klien kami tidak mungkin memenangi perlumbaan maklumat 250ms lawan 3s. Pengawal itu perlu berada di tempat kedua-dua isyarat bertemu — bagi kami, proksi backend.
3. Sahkan pada build langsung sebelum menerbitkan. Regresi keyterm itu dikesan kerana setiap keluaran GeekBye diuji sebagai build yang ditandatangani dan dinotari terhadap pengeluaran sebelum ia dihantar. Versi yang bermasalah itu wujud beberapa jam pada satu mesin dalaman sahaja, bukan pada Mac anda.

GeekBye v2.0.11 sudah tersedia sekarang — jika anda menggunakan v2, anda sudah memilikinya melalui kemas kini automatik. Untuk asas kebolehpercayaan yang menjadi tapak keluaran ini, lihat mengapa AI notetaker anda berhenti apabila Wi-Fi lemah dan apa yang berubah dalam GeekBye v2. Untuk cara transkripsi langsung berfungsi hari demi hari, mulakan dengan transkripsi masa nyata dalam GeekBye.