Steven
Stevenโ€ขโ€ข6 menit baca

Mengapa Transkripsi AI Salah Mendengar Istilah Teknis (dan Bagaimana Kami Memperbaikinya)

Sebuah sesi live mendengar "what is the pointer in C++" sebagai "what is the point in life". Inilah jejak forensik dari transkrip itu hingga GeekBye v2.0.11 โ€” keyterm biasing, race timing yang memutus koneksi, dan hari ketika perbaikan kami sendiri justru jadi bumerang.

Transkripsi
Keandalan
Engineering
Rilis GeekBye
Mengapa Transkripsi AI Salah Mendengar Istilah Teknis (dan Bagaimana Kami Memperbaikinya)

Pada 2 Juli kami menjalankan sesi uji dan mengajukan pertanyaan sederhana ke GeekBye dengan suara keras: "What is the pointer in C++?"

Transkrip live-nya 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.

Di sesi yang sama, metrik kesehatan menceritakan sisanya: 3 koneksi transkripsi putus dalam 163 detik dan lubang 51 detik di transkrip. Dan satu petunjuk lagi yang ternyata paling penting: proses pemulihan pasca-sesi kami โ€” yang mentranskripsi ulang audio yang tersimpan lokal untuk mengisi celah โ€” hampir menangkap kalimatnya dengan benar: "a pointer in plus, plus? What the pointer in plus, plus C++."

Audionya baik-baik saja. Model live-nya saja tidak punya alasan untuk mengharapkan C++.

Ini adalah kisah GeekBye v2.0.11, diceritakan dari transkrip asli dan log produksi.

Mengapa model suara salah mendengar kosakata Anda

Pengenalan suara adalah masalah prediksi. Diberi audio yang ambigu, model memilih kata yang paling mungkin โ€” dan bagi model serbaguna, "point in life" (makna hidup) adalah frasa yang jauh lebih mungkin daripada "pointer in C++" (pointer di C++). Setiap engineer yang pernah melihat transkrip meeting menuliskan Kubernetes sebagai "cube and eddies" sudah kenal kegagalan ini.

Solusinya bukan mikrofon yang lebih bagus. Solusinya adalah keyterm biasing: memberi tahu model, sebelum sesi dimulai, kata-kata tidak lazim mana yang justru lazim bagi Anda. Penyedia layanan suara kami mendukung hingga 50 istilah biasing per sesi. Bagian yang memalukan: jalur untuk istilah-istilah itu sudah ada end-to-end di stack kami โ€” klien, backend, penyedia โ€” dan tidak pernah ada yang mengisinya. Setiap sesi berjalan tanpa bantuan domain sama sekali.

Perbaikan 1: profil Anda menjadi kosakata model

GeekBye sudah tahu domain Anda โ€” ada di profil aktif Anda. v2.0.11 menurunkan keyterm biasing dari nama dan deskripsi profil: istilah dengan simbol (C++, Node.js), akronim (SQL, AWS), nama camel-case (TypeScript, PostgreSQL), dan nama diri. Profil yang menyebut stack Anda kini membuat stack itu diharapkan, bukan eksotis.

Hari ketika perbaikan itu memperburuk segalanya

Versi pertama kami memperlakukan setiap kata berhuruf kapital sebagai nama diri. Di sebuah build uji internal (ini tidak pernah sampai ke pelanggan), profil yang ditulis dalam bentuk prosa mengirimkan daftar biasing ini ke model:

Senior, Writing, Direct, For, Includes, Write, Role, Intentโ€ฆ

Membiaskan model suara ke arah kata "For" lebih buruk daripada tidak membiaskannya sama sekali. Di sesi uji berikutnya, kata "speak" โ€” diucapkan dengan jelas, berkali-kali โ€” kembali sebagai "Clicky", "Hey, Vicky", dan "Peter Paderty". Pelajaran itu menghabiskan satu sore kami: lakukan bias hanya dengan istilah yang distingtif. Kata berhuruf kapital kini hanya dihitung jika muncul di tengah kalimat (sinyal nama diri yang asli); heading markdown, yang setiap katanya berhuruf kapital, tidak pernah ikut dihitung. Profil yang sama itu kini menghasilkan persis LinkedIn, AI, CEO, MCP โ€” dan sesi validasi berhasil mentranskripsi audio multibahasa yang berpindah cepat dengan benar selama 199 detik berturut-turut, 189 segmen transkrip, nol kesalahan.

Perbaikan 2: race yang memutus koneksi

Keyterm menjelaskan kata-kata yang salah dengar. Ia tidak menjelaskan tiga koneksi yang putus.

Jejak itu menuju sesuatu yang lebih halus. Penyedia kami meng-commit (memfinalkan) transkripsi berdasarkan deteksi aktivitas suaranya sendiri, sekitar satu detik setelah hening. Klien kami juga mengirim commit pengaman 250 milidetik setelah hening, untuk membilas kalimat parsial yang menggantung. Konfirmasi dari penyedia bahwa ia sudah meng-commit butuh satu hingga tiga detik untuk kembali. Hitung sendiri tiga angka itu: setiap kali penyedia meng-commit lebih dulu, commit pengaman kami menembak buffer yang nyaris kosong โ€” dan respons penyedia terhadap itu bukan sekadar penolakan sopan. Ia memutus koneksi. Setiap jeda bicara adalah lempar koin.

v2.0.11 membawa dua lapisan pertahanan:

  1. Di aplikasi: ketika transkrip yang sudah di-commit tiba, klien kini tahu buffer penyedia baru saja dikosongkan dan melewati commit pengaman yang redundan.
  2. Di backend kami, di hari yang sama: proxy yang berada di antara aplikasi dan penyedia mencerminkan pembukuan audio penyedia dengan persis โ€” ia melihat setiap frame audio dan setiap konfirmasi commit dengan latensi nol โ€” dan langsung menolak meneruskan commit apa pun yang akan ditolak penyedia. Lapisan ini melindungi semua versi klien sekaligus, termasuk pengguna yang belum memperbarui aplikasi.

Kami melihatnya bekerja di produksi dalam satu jam. Penjaga itu mencegat commit gagal yang membawa 178ms dan 256ms audio ter-buffer โ€” masing-masing, sebelum hari itu, berarti koneksi putus yang pasti terjadi dan lubang di catatan meeting seseorang. Sesi kontinu 60 menit sore itu mencatat lima pencegatan dan nol putus. Sebelum perbaikan, seorang pengguna nyata pagi itu juga sempat me-restart rekamannya lima kali dalam enam menit melawan bug yang persis sama.

Dua perbaikan kecil yang ikut serta

Insight AI kini menunggu substansi. Fragmen awal yang kacau itu dulu memberi makan chip saran live GeekBye, yang dengan percaya diri menghasilkan topik seperti "Defining Life's Ultimate Purpose" dari pertanyaan C++ yang salah dengar. Saran kini menunggu sampai sesi punya massa percakapan yang nyata.

Teks hasil pemulihan mendapat pembicara yang benar. Proses pemulihan yang mentranskripsi pertanyaan C++ kami dengan benar sempat mengatribusikannya ke "Them". Lini masa audio yang tersimpan lokal kini mencatat siapa yang sedang bicara, sehingga segmen hasil pemulihan diatribusikan dengan benar ke You atau Them.

Papan skor

Metrik (terukur, bukan estimasi) Sebelum Setelah v2.0.11 + penjaga backend
Koneksi putus di sesi uji 3 dalam 163s 0
Lubang transkrip terpanjang 51s celah terburuk ~6s saat validasi
"pointer in C++" "point in life" benar, kosakata ter-bias
Commit gagal yang sampai ke penyedia semuanya 0 (dicegat di backend)

Jika Anda membangun di atas API suara realtime

Tiga pelajaran yang bisa dibawa pulang dari rilis ini:

  1. Isi fitur biasing-nya. Jika penyedia STT Anda mendukung keyterm/phrase hint, mengisinya dengan kosakata yang kecil dan distingtif adalah kemenangan akurasi termurah yang tersedia โ€” dan mengisinya dengan kata-kata umum adalah kerugian akurasi.
  2. Jangan pernah berpacu melawan state machine penyedia dari sisi yang salah pada sebuah round-trip jaringan. Klien kami tidak mungkin memenangkan race informasi 250ms lawan 3s. Penjaganya harus berada di titik tempat kedua sinyal bertemu โ€” bagi kami, proxy backend.
  3. Validasi di build live sebelum memublikasikan. Regresi keyterm tertangkap karena setiap rilis GeekBye diuji sebagai build yang ditandatangani dan dinotarisasi terhadap produksi sebelum dikirim. Versi buruknya hanya hidup beberapa jam di satu mesin internal, bukan di Mac Anda.

GeekBye v2.0.11 sudah live sekarang โ€” jika Anda di v2, Anda sudah mendapatkannya lewat auto-update. Untuk fondasi keandalan yang menjadi dasar rilis ini, lihat mengapa AI notetaker Anda berhenti saat Wi-Fi buruk dan apa yang berubah di GeekBye v2. Untuk cara kerja transkripsi live sehari-hari, mulailah dari transkripsi real-time di GeekBye.