Kodėl jūsų AI užrašinė nustoja įrašinėti vidury susitikimo

Liepos 2 d. GeekBye pats užbaigė susitikimo įrašymą. Duomenų bazės eilutė pasako viską: ended_reason = 'idle', trukmė 519 sekundžių, 99 transkripto įrašai — paskutinis įrašytas likus dviem sekundėms iki tol, kol programa nusprendė, kad nieko nėra.

Kitas dalyvis buvo aiškinimo viduryje. Paskutinė transkripto eilutė — tiesiogine prasme sakinio nuotrupa: „...executes it or turns it on or so—".

Tai buvo ne pirmas kartas. Vakare prieš tai kita sesija baigėsi lygiai taip pat. Du susitikimai, nužudyti mūsų pačių patikimumo funkcijos. Štai diagnozė ir pataisa, išleista su GeekBye v2.0.9 — plius antra, baisesnė klaida, kurią ištaisėme tame pačiame leidime.

Gerų ketinimų laikmatis, girdėjęs tik jus

Automatinis uždarymas dėl neveiklumo egzistuoja dėl geros priežasties. Žmonės pamiršta įrašymą įjungtą per naktį; paliktas atviras susitikimo skirtukas gali be galo varvinti garsą. Todėl GeekBye stebi neaktyvumą: po 60 sekundžių be balso aktyvumo parodo mažą užklausą „Still recording?" (vis dar įrašome?), o po 30 sekundžių, negavęs atsakymo, užbaigia sesiją — mandagiai viską išsaugodamas.

Yda slypėjo viename žodyje: balso. Aktyvumo laikrodis skaičiavo tik nuolatinę mikrofono energiją. Tai buvo sąmoningas dizaino sprendimas, ir ne kvailas — skaičiuojant žalią sistemos garso energiją, nutildytas, bet triukšmingas skirtukas galėtų be galo laikyti gyvą mirusią sesiją, o tai kaip tik ta klaida, kuriai užkirsti kelią ši funkcija ir egzistuoja. Susitikimus, kuriuose daugiausia klausotės, turėjo dengti susitikimų langų aptikimas.

Tik štai susitikimų aptikimas mato ne kiekvieną susitikimą. Naršyklės skirtukai, neįprasti klientai, prezentacija, kurią žiūrite — neaptikta. O neaptiktame susitikime, kuriame klausotės 90 sekundžių — visiškai normalus dalykas, kol kažkas aiškina savo Databricks pipeline — neveiklumo laikrodžiui esate neatskiriamas nuo tuščio kambario.

Pažvelkite į nužudytos sesijos laiko juostą: paskutinis transkriptas iš mūsų mikrofono atėjo likus 68 sekundėms iki pabaigos. Tada 60 sekundžių kalbėjo kitas žmogus (transkribuota tobulai, laikrodžio ignoruota), nepastebėta užklausa, 30 sekundžių atgalinis skaičiavimas ir nužudymas — praėjus 2 sekundėms po jo paskutinių žodžių.

Pataisa: transkriptas yra gyvybės įrodymas

Žvelgiant atgal, pataisymas beveik gėdingas: gaunamas transkriptas yra stipriausias įmanomas įrodymas, kad sesija nėra neaktyvi. Nesvarbu, kas kalbėjo. Kalbos modelis ką tik atpažino žodžius — tai ir yra susitikimas.

Todėl v2.0.9 atnaujina aktyvumo laikrodį su kiekvienu atėjusiu transkriptu, iš bet kurios pusės. Žalia sistemos garso energija vis tiek nesiskaito — muzika, laukimo tonai ir ventiliacijos ūžesys vis dar negali įamžinti mirusios sesijos, o kietoji įrašymo trukmės riba ir toliau viską apsaugo. Tik atpažinta kalba laiko sesiją gyvą — ir tai kaip tik teisinga riba.

Viena detalė iš kodo peržiūros, kurią verta perduoti: pirmoji pataisos versija laikrodį atnaujindavo kalbėtojo priskyrimo kelyje — kurį dalis transkriptų gali teisėtai praleisti. Peržiūra pagavo, kad būsimas pakeitimas galėtų tyliai sugrąžinti klaidą kaip tik tiems transkriptams, kurie svarbiausi (kito kalbėtojo). Dabar atnaujinimas besąlygiškas, prieš bet kokį šakojimąsi, su testu, kuris sugriūva, jei kas nors jį perkelia.

Tas pats leidimas ištaisė kai ką baisesnio

Testuodami šias pataisas, kitą klaidą pajutome skaudžiuoju būdu: sąsajos proceso strigtis paliko visą darbalaukį nereaguojantį į paspaudimus.

GeekBye perdanga — tai permatomas, visada viršuje esantis langas, dengiantis jūsų ekraną. Pagal numatytuosius nustatymus jis praleidžia paspaudimus; sąsaja perjungia jį į interaktyvų režimą, kai naudojatės skydeliu. Tie perjungimai ateina iš sąsajos proceso — tad kai tas procesas nulūžo su atidarytu skydeliu, nematomas langas liko interaktyviame režime be jokios gyvos UI už jo. Kiekvienas paspaudimas darbalaukyje nusileisdavo ant mirusios, nematomos plokštės. Vienintelis išsigelbėjimas — priverstinai išjungti programą.

v2.0.9 strigčių apdorotojas dabar iškart atkuria paspaudimų praleidimą ir iš naujo įkelia sąsają — su trijų perkrovimų per minutę riba, kad strigčių ciklas negalėtų suktis amžinai (viršijus ribą programa perkrovimų atsisako, bet darbalaukis lieka naudojamas — o tai ir yra svarbiausia dalis). Kodo peržiūra patobulino ir šią pataisą: atkūrimas apribotas būtent perdangos langu, nes paspaudimų praleidimo įjungimas aklai bet kokiam nulūžusiam įprastam langui — tarkime, atnaujinimo dialogui — būtų sukūręs priešingą užraktą.

Šią pataisą galite patikrinti patys, brutaliai: atidarykite GeekBye skydelį, „Activity Monitor" priverstinai nužudykite procesą „GeekBye Helper (Renderer)" ir stebėkite, kaip programa per sekundę atkuria jūsų darbalaukį.

Ko mus išmokė ši klaidų pora

1. Kiekvienas netiesioginis „ar naudotojas čia?" požymis kur nors sugriūva. Mikrofono energija sugriūva klausantiems. Langų aptikimas sugriūva naršyklėms. Atpažinti transkriptai sugriūva... kol kas nieko neradome, nes tai ne netiesioginis požymis — tai pats produktas.
2. Viskam, ką valdo renderer, reikia strigties scenarijaus. Jei miręs UI procesas gali palikti OS lygmens būseną (pelės perėmimą, „visada viršuje", turinio apsaugą), atstatymą privalo valdyti pagrindinis procesas.
3. Būti pačiam aktyviausiu savo naudotoju — klaidų paieškos strategija. Abi klaidos smogė mums tikruose susitikimuose anksčiau, nei jas pastebėjo daugiau nei saujelė klientų. Stulpelis ended_reason, kurį stebimumui pridėjome prieš kelis mėnesius, diagnozę pavertė užklausa į duomenų bazę, o ne spėliojimu.

Abi pataisos nuo diagnozės iki išleisto, notarizuoto leidimo nukeliavo per vieną dieną, kiekviena — peržiūrėtame PR su regresijos testais. Jei naudojate GeekBye v2, jas turite nuo v2.0.9 per automatinį atnaujinimą.

Likusią šio leidimo istoriją rasite gretimame serijos straipsnyje kodėl AI transkripcija iškraipo techninius terminus (v2.0.11), patikimumo pamatuose straipsnyje kodėl jūsų AI užrašinė sustoja esant prastam Wi-Fi ir tame, kaip perdanga lieka nematoma dalijantis ekranu, nevogdama jūsų paspaudimų.