Steven
Steven5 minit bacaan

Mengapa AI Notetaker Anda Berhenti Merakam di Pertengahan Mesyuarat

Aplikasi kami sendiri menamatkan dua mesyuarat kami ketika pihak satu lagi masih di tengah ayat. Jejak forensiknya membawa kepada pemasa idle yang berniat baik tetapi hanya boleh mendengar anda — dan pepijat kedua yang boleh mengunci seluruh desktop anda. Kedua-duanya dibetulkan dalam GeekBye v2.0.9.

Kebolehpercayaan
Mesyuarat
Kejuruteraan
Keluaran GeekBye
Mengapa AI Notetaker Anda Berhenti Merakam di Pertengahan Mesyuarat

Pada 2 Julai, GeekBye menamatkan rakaman mesyuarat dengan sendirinya. Baris pangkalan data itu menceritakan segalanya: ended_reason = 'idle', tempoh 519 saat, 99 entri transkrip — yang terakhir ditulis dua saat sebelum aplikasi memutuskan tiada sesiapa di sana.

Peserta satu lagi sedang di tengah penerangan. Baris terakhir transkrip itu benar-benar serpihan ayat: "...executes it or turns it on or so—".

Ia bukan kali pertama. Malam sebelumnya, satu lagi sesi berakhir dengan cara yang sama. Dua mesyuarat, dibunuh oleh ciri kebolehpercayaan kami sendiri. Inilah diagnosis dan pembetulan yang dikeluarkan dalam GeekBye v2.0.9 — serta pepijat kedua yang lebih menakutkan yang kami betulkan dalam keluaran yang sama.

Pemasa berniat baik yang hanya boleh mendengar anda

Auto-tutup idle wujud atas sebab yang baik. Orang terlupa rakaman berjalan semalaman; tab mesyuarat yang dibiarkan terbuka terus menitiskan audio selama-lamanya. Jadi GeekBye memerhatikan ketidakaktifan: selepas 60 saat tanpa aktiviti suara, ia memaparkan gesaan kecil "Still recording?" ("Masih merakam?"), dan 30 saat kemudian, jika tidak dijawab, ia menamatkan sesi — menyimpan segalanya, dengan sopan.

Kecacatannya terletak pada satu perkataan: suara. Jam aktiviti hanya mengira tenaga mikrofon yang berterusan. Itu keputusan reka bentuk yang disengajakan, dan bukan keputusan bodoh — mengira tenaga mentah audio sistem akan membiarkan tab yang disenyapkan tetapi bising mengekalkan sesi mati tanpa had, iaitu kegagalan yang ciri ini wujud untuk mencegahnya. Mesyuarat yang anda kebanyakannya mendengar sepatutnya dilindungi oleh pengesanan tetingkap mesyuarat.

Namun pengesanan mesyuarat tidak dapat melihat setiap mesyuarat. Tab pelayar, klien luar biasa, pembentangan yang anda tonton — tidak dikesan. Dan dalam mesyuarat yang tidak dikesan, apabila anda mendengar selama 90 saat — perkara yang benar-benar normal sementara seseorang menerangkan pipeline Databricks mereka — anda, pada jam idle, tidak dapat dibezakan daripada bilik kosong.

Semak garis masa sesi yang dibunuh itu: transkrip terakhir daripada mikrofon kami tiba 68 saat sebelum penamat. Kemudian 60 saat orang satu lagi bercakap (ditranskripsikan dengan sempurna, diabaikan oleh jam), gesaan yang tidak disedari, kiraan detik 30 saat, dan penamatan — 2 saat selepas kata-kata terakhir mereka.

Pembetulannya: transkrip ialah bukti kehidupan

Pembetulannya hampir memalukan apabila difikirkan semula: transkrip yang masuk ialah bukti paling kukuh yang mungkin bahawa sesi itu tidak idle. Tidak kira siapa yang bercakap. Model pertuturan baru sahaja mengecam perkataan — itulah mesyuarat itu sendiri.

Jadi v2.0.9 mengecap jam aktiviti pada setiap transkrip yang tiba, daripada mana-mana pihak. Tenaga mentah audio sistem masih tidak dikira — muzik, nada tunggu dan dengungan penghawa dingin masih tidak boleh mengabadikan sesi yang mati, dan had keras tempoh rakaman kekal sebagai penyelamat terakhir. Hanya pertuturan yang dikecam mengekalkan sesi hidup, dan itulah sempadan yang betul-betul tepat.

Satu perincian daripada semakan kod yang berbaloi dikongsikan: versi pertama pembetulan itu mengecap jam di dalam laluan atribusi penutur — yang boleh dilangkau secara sah oleh sesetengah transkrip. Semakan mendapati perubahan pada masa hadapan boleh secara senyap menghidupkan semula pepijat itu untuk transkrip yang paling penting (milik penutur satu lagi). Cap itu kini tanpa syarat, sebelum sebarang cabangan, dengan ujian yang gagal jika sesiapa mengalihkannya.

Keluaran yang sama membetulkan sesuatu yang lebih menakutkan

Semasa menguji pembetulan ini, kami terlanggar pepijat lain dengan cara yang paling pahit: crash dalam proses antara muka meninggalkan seluruh desktop tidak boleh diklik.

Overlay GeekBye ialah tetingkap lutsinar, sentiasa di atas, yang meliputi skrin anda. Secara lalai ia membenarkan klik menembusinya (click-through); antara muka menukarnya kepada interaktif apabila anda menggunakan panel. Arahan penukaran itu datang daripada proses antara muka — jadi apabila proses itu crash semasa panel terbuka, tetingkap halimunan itu kekal dalam mod interaktif tanpa sebarang UI hidup di belakangnya. Setiap klik pada desktop anda mendarat pada panel mati yang tidak kelihatan. Satu-satunya jalan keluar ialah memaksa aplikasi itu ditutup.

Pengendali crash v2.0.9 kini memulihkan click-through serta-merta dan memuatkan semula antara muka — dengan had tiga kali muat semula seminit supaya gelung crash tidak boleh berpusing selama-lamanya (melepasi had itu, aplikasi berputus asa memuat semula tetapi desktop anda kekal boleh digunakan, dan itulah bahagian yang penting). Semakan kod turut menajamkan yang ini: pemulihan dihadkan khusus kepada tetingkap overlay, kerana menerapkan click-through secara membuta tuli pada tetingkap biasa yang crash — contohnya dialog kemas kini — akan mewujudkan sekatan yang sebaliknya pula.

Anda boleh mengesahkan pembetulan ini sendiri, secara kejam: buka panel GeekBye, force-kill proses "GeekBye Helper (Renderer)" dalam Activity Monitor, dan saksikan aplikasi memulihkan desktop anda dalam masa sesaat.

Apa yang pasangan pepijat ini ajarkan kepada kami

  1. Setiap proksi untuk "adakah pengguna masih di sini?" gagal di suatu tempat. Tenaga mikrofon gagal untuk pendengar. Pengesanan tetingkap gagal untuk pelayar. Transkrip yang dikecam gagal untuk... tiada apa-apa yang kami temui setakat ini, kerana ia bukan proksi — ia produk itu sendiri.
  2. Apa-apa sahaja yang dipandu renderer memerlukan kisah crash. Jika proses UI yang mati boleh meninggalkan keadaan peringkat OS (tangkapan tetikus, sentiasa di atas, perlindungan kandungan), proses utama mesti memiliki set semula itu.
  3. Menjadi pengguna paling tegar produk sendiri ialah strategi mencari pepijat. Kedua-dua pepijat mengenai kami dalam mesyuarat sebenar sebelum lebih daripada segelintir pelanggan menyedarinya. Lajur ended_reason yang kami tambahkan untuk kebolehcerapan berbulan-bulan sebelumnya itulah yang menjadikan diagnosis ini satu pertanyaan pangkalan data dan bukannya tekaan.

Kedua-dua pembetulan bergerak daripada diagnosis kepada keluaran yang diterbitkan dan dinotari dalam masa sehari, masing-masing dibawa oleh PR yang disemak dengan ujian regresi. Jika anda menggunakan GeekBye v2, anda sudah memilikinya sejak v2.0.9 melalui kemas kini automatik.

Untuk baki kisah keluaran ini, lihat jiran sirinya mengapa transkripsi AI tersalah dengar istilah teknikal (v2.0.11), asas kebolehpercayaan dalam mengapa AI notetaker anda berhenti pada Wi-Fi yang lemah, dan bagaimana overlay kekal halimunan semasa perkongsian skrin tanpa mencuri klik anda.