Miks sinu AI-märkmik lõpetab salvestamise keset koosolekut

2. juulil lõpetas GeekBye koosoleku salvestamise omal käel. Andmebaasirida ütleb kõik: ended_reason = 'idle', kestus 519 sekundit, 99 transkriptikirjet — viimane neist kirjutati kaks sekundit enne, kui rakendus otsustas, et kedagi pole kohal.

Teine osaleja oli parasjagu keset selgitust. Transkripti viimane rida on sõna otseses mõttes lausekatke: "...executes it or turns it on or so—".

See polnud esimene kord. Eelmisel õhtul lõppes teine seanss täpselt samamoodi. Kaks koosolekut, mille tappis meie enda töökindlusfunktsioon. Siin on diagnoos ja parandus, mis läks välja GeekBye v2.0.9-s — pluss teine, hirmutavam viga, mille samas väljalaskes parandasime.

Heade kavatsustega taimer, mis kuulis ainult sind

Jõudeoleku automaatsulgemine on olemas mõjuval põhjusel. Inimesed unustavad salvestused ööseks käima; lahtijäänud koosolekuvaheleht tilgutab heli igavesti. Nii et GeekBye jälgib tegevusetust: pärast 60 sekundit ilma hääleaktiivsuseta näitab ta väikest "Still recording?" ("Kas salvestad veel?") küsimust ja 30 sekundit hiljem, kui vastust pole, lõpetab seansi — salvestades kõik, viisakalt.

Viga peitus ühes sõnas: hääle-. Aktiivsuskell luges ainult püsivat mikrofonienergiat. See oli teadlik disainiotsus, ja sugugi mitte rumal — toore süsteemiheli energia arvestamine laseks vaigistatud-aga-mürarikkal vahelehel surnud seanssi lõputult elus hoida, mis on täpselt see rike, mille ärahoidmiseks funktsioon üldse olemas on. Koosolekud, kus sa peamiselt kuulad, pidi katma koosolekuakna tuvastus.

Ainult et koosolekutuvastus ei näe iga koosolekut. Brauserivahelehed, ebatavalised kliendid, esitlus, mida sa vaatad — tuvastamata. Ja tuvastamata koosolekul, kus sa kuulad 90 sekundit — täiesti normaalne asi, mida teha, kui keegi selgitab oma Databricksi torustikku — oled sa jõudekella jaoks eristamatu tühjast toast.

Vaata tapetud seansi ajajoont: viimane transkript meie mikrofonist tuli 68 sekundit enne lõppu. Siis 60 sekundit teise inimese juttu (täiuslikult transkribeeritud, kella poolt ignoreeritud), märkamata jäänud küsimus, 30-sekundiline pöördloendus ja tapp — 2 sekundit pärast tema viimaseid sõnu.

Parandus: transkript on elumärk

Parandus on tagantjärele peaaegu piinlik: saabuv transkript on tugevaim võimalik tõend, et seanss ei ole jõude. Pole tähtis, kes rääkis. Kõnemudel just tuvastas sõnu — see ongi koosolek.

Nii et v2.0.9 tembeldab aktiivsuskella igal saabuval transkriptil, ükskõik kummalt poolelt. Toores süsteemiheli energia ei lähe endiselt arvesse — muusika, ootetoonid ja ventilatsioonimüra ei suuda surnud seanssi ikka veel surematuks teha, ja salvestamise range ülempiir jääb kõige viimaseks kaitseliiniks. Ainult tuvastatud kõne hoiab seansi elus, mis on täpselt õige piir.

Üks code review'st välja tulnud detail, mida tasub edasi anda: paranduse esimene versioon tembeldas kella kõneleja omistamise rajal — mille osa transkripte võib õigustatult vahele jätta. Review püüdis kinni, et mõni tulevane muudatus võiks vea vaikselt tagasi tuua täpselt nende transkriptide jaoks, mis loevad (teise kõneleja omad). Tempel on nüüd tingimusteta, enne igasugust harunemist, koos testiga, mis kukub läbi, kui keegi selle mujale liigutab.

Sama väljalase parandas midagi hirmutavamat

Neid parandusi testides tabasime valusal moel hoopis teist viga: liideseprotsessi krahh jättis kogu töölaua klikitamatuks.

GeekBye ülekate on läbipaistev, alati-pealmine aken, mis katab su ekraani. Vaikimisi laseb see klikid läbi; liides lülitab selle interaktiivseks, kui kasutad mõnd paneeli. Need lülitused tulevad liideseprotsessist — nii et kui see protsess läks krahhi ajal, mil paneel oli lahti, jäi nähtamatu aken interaktiivsesse režiimi, ilma et selle taga oleks ühtegi elusat UI-d. Iga klikk su töölaual maandus surnud, nähtamatule paanile. Ainus pääsetee oli rakenduse jõuga sulgemine.

v2.0.9 krahhikäsitleja taastab nüüd klikkide läbilaskmise kohe ja laadib liidese uuesti — piiranguga kolm taaslaadimist minutis, et krahhitsükkel ei saaks igavesti pöörelda (pärast piiri ületamist loobub rakendus taaslaadimisest, aga su töölaud jääb kasutatavaks, mis ongi see osa, mis loeb). Code review teritas ka seda parandust: taastumine on piiratud just nimelt ülekatteaknaga, sest klikkide läbilaskmise lauskohaldamine krahhinud tavalisele aknale — näiteks uuendusdialoogile — oleks loonud vastupidise lukustuse.

Seda parandust võid ise jõhkralt kontrollida: ava GeekBye paneel, tapa Activity Monitoris jõuga protsess "GeekBye Helper (Renderer)" ja vaata, kuidas rakendus taastab su töölaua sekundi jooksul.

Mida see veapaar meile õpetas

1. Iga asendusnäitaja küsimusele "kas kasutaja on kohal?" veab kuskil alt. Mikrofonienergia veab alt kuulajate puhul. Aknatuvastus veab alt brauserite puhul. Tuvastatud transkriptid veavad alt... mitte millegi puhul, mida me seni leidnud oleme, sest need pole asendusnäitaja — need on toode ise.
2. Kõik, mida juhib renderer, vajab krahhilugu. Kui surnud UI-protsess võib jätta maha OS-taseme olekut (hiireklikkide kinnipüüdmine, alati-pealmine režiim, sisukaitse), peab lähtestamise eest vastutama põhiprotsess.
3. Olla ise oma kõige raskem kasutaja on veaotsimise strateegia. Mõlemad vead tabasid meid päris koosolekutel enne, kui midagi märkas rohkem kui käputäis kliente. ended_reason veerg, mille olime kuid varem vaadeldavuse jaoks lisanud, on see, mis tegi diagnoosist andmebaasipäringu, mitte oletuse.

Mõlemad parandused jõudsid diagnoosist väljasaadetud, notariseeritud väljalaskeni ühe päevaga, kumbki üle vaadatud PR-is koos regressioonitestidega. Kui oled GeekBye v2 peal, on need sul automaatuuenduse kaudu olemas alates v2.0.9-st.

Selle väljalaske ülejäänud loo jaoks vaata sarjanaabrit miks AI-transkriptsioon kuuleb tehnilisi termineid valesti (v2.0.11), töökindluse aluspõhja artiklis miks sinu AI-märkmik kehva Wi-Fi peal seisma jääb ja seda, kuidas ülekate püsib ekraanijagamise ajal nähtamatu ilma sinu klikke varastamata.