Miksi AI-muistiinpanotyökalusi lopettaa tallennuksen kesken kokouksen

Heinäkuun 2. päivänä GeekBye päätti kokoustallennuksen omin päin. Tietokantarivi kertoo kaiken: ended_reason = 'idle', kesto 519 sekuntia, 99 transkriptimerkintää — viimeinen niistä kirjoitettu kaksi sekuntia ennen kuin sovellus päätti, ettei paikalla ollut ketään.

Toinen osallistuja oli kesken selityksensä. Transkriptin viimeinen rivi on kirjaimellisesti lauseenkatkelma: "...executes it or turns it on or so—".

Eikä se ollut ensimmäinen kerta. Edellisenä iltana toinen istunto päättyi samalla tavalla. Kaksi kokousta, jotka oma luotettavuusominaisuutemme tappoi. Tässä on diagnoosi ja korjaus, joka lähti ulos GeekBye v2.0.9:ssä — sekä toinen, pelottavampi bugi, jonka korjasimme samassa julkaisussa.

Hyvää tarkoittava ajastin, joka kuuli vain sinut

Idle-automaattisulku on olemassa hyvästä syystä. Ihmiset unohtavat tallennuksia päälle yön yli; auki jäänyt kokousvälilehti tiputtelee ääntä loputtomiin. GeekBye siis vahtii toimettomuutta: kun äänellistä aktiivisuutta ei ole kuulunut 60 sekuntiin, se näyttää pienen "Still recording?" -kehotteen ("Tallennetaanko yhä?"), ja 30 sekuntia myöhemmin, vastausta saamatta, se päättää istunnon — tallentaen kaiken, kohteliaasti.

Vika piili yhdessä sanassa: äänellistä. Aktiivisuuskello laski vain mikrofonin jatkuvaa energiaa. Se oli tietoinen suunnittelupäätös, eikä mikään tyhmä sellainen — järjestelmä-äänen raa'an energian laskeminen antaisi mykistetyn mutta meluisan välilehden pitää kuollutta istuntoa hengissä loputtomiin, mikä on täsmälleen se vika, jota koko ominaisuus on olemassa estämään. Kokoukset, joissa lähinnä kuuntelet, oli tarkoitus kattaa kokousikkunan tunnistuksella.

Paitsi että kokoustunnistus ei näe jokaista kokousta. Selainvälilehdet, epätavalliset asiakasohjelmat, esitys, jota katsot — tunnistamatta. Ja tunnistamattomassa kokouksessa, jossa kuuntelet 90 sekuntia — täysin normaali asia tehdä, kun joku selittää Databricks-putkeaan — olet idle-kellon silmissä erottamaton tyhjästä huoneesta.

Katso tapetun istunnon aikajanaa: viimeinen transkripti meidän mikrofonistamme tuli 68 sekuntia ennen loppua. Sitten 60 sekuntia toisen henkilön puhetta (transkriboitu täydellisesti, kellolta täysin huomiotta), huomaamatta jäänyt kehote, 30 sekunnin lähtölaskenta ja tappo — 2 sekuntia heidän viimeisten sanojensa jälkeen.

Korjaus: transkripti on todiste elämästä

Korjaus on jälkikäteen katsottuna melkein nolo: saapuva transkripti on vahvin mahdollinen todiste siitä, ettei istunto ole toimeton. Sillä ei ole väliä, kuka puhui. Puhemalli tunnisti juuri sanoja — se on se kokous.

Niinpä v2.0.9 leimaa aktiivisuuskellon jokaisesta saapuvasta transkriptista, kummalta puolelta tahansa. Järjestelmä-äänen raaka energia ei edelleenkään kelpaa — musiikki, jonotusäänet ja ilmastoinnin humina eivät vieläkään voi tehdä kuolleesta istunnosta kuolematonta, ja tallennuksen kova yläraja on yhä kaiken takaporttina. Vain tunnistettu puhe pitää istunnon elossa, mikä on täsmälleen oikea raja.

Yksi koodikatselmoinnista poimittu, eteenpäin kertomisen arvoinen yksityiskohta: korjauksen ensimmäinen versio leimasi kellon puhujantunnistuspolun sisällä — jonka osa transkripteista voi täysin laillisesti ohittaa. Katselmointi huomasi, että tuleva muutos voisi hiljaa tuoda bugin takaisin juuri niille transkripteille, joilla on väliä (toisen puhujan). Leimaus on nyt ehdoton, ennen kaikkia haarautumia, ja mukana on testi, joka kaatuu, jos joku siirtää sen.

Sama julkaisu korjasi jotain pelottavampaa

Näitä korjauksia testatessamme törmäsimme toiseen bugiin kantapään kautta: käyttöliittymäprosessin kaatuminen jätti koko työpöydän klikkauskelvottomaksi.

GeekByen overlay on läpinäkyvä, aina päällimmäisenä pysyvä ikkuna, joka peittää näyttösi. Se on oletuksena klikkaukset läpäisevä; käyttöliittymä kytkee sen interaktiiviseksi, kun käytät paneelia. Nämä kytkennät tulevat käyttöliittymäprosessista — joten kun se prosessi kaatui paneelin ollessa auki, näkymätön ikkuna jäi interaktiiviseen tilaan ilman elävää käyttöliittymää takanaan. Jokainen klikkaus työpöydälläsi osui kuolleeseen, näkymättömään ruutuun. Ainoa ulospääsy oli sovelluksen pakkosulkeminen.

v2.0.9:n kaatumiskäsittelijä palauttaa nyt klikkausten läpäisyn välittömästi ja lataa käyttöliittymän uudelleen — enintään kolme uudelleenlatausta minuutissa, jotta kaatumissilmukka ei voi pyöriä ikuisesti (rajan jälkeen sovellus luovuttaa uudelleenlatausten suhteen, mutta työpöytäsi pysyy käyttökelpoisena, mikä on se olennainen osa). Koodikatselmointi terävöitti tätäkin: palautuminen on rajattu nimenomaan overlay-ikkunaan, koska klikkausten läpäisyn lätkäiseminen summamutikassa kaatuneeseen tavalliseen ikkunaan — vaikkapa päivitysdialogiin — olisi luonut päinvastaisen lukituksen.

Voit todentaa korjauksen itse, raa'asti: avaa GeekBye-paneeli, pakkotapa "GeekBye Helper (Renderer)" -prosessi Activity Monitorissa ja katso, kuinka sovellus palauttaa työpöytäsi sekunnin sisällä.

Mitä tämä bugipari opetti meille

1. Jokainen "onko käyttäjä paikalla?" -kysymyksen sijaismittari pettää jossain. Mikrofonin energia pettää kuuntelijoilla. Ikkunatunnistus pettää selaimilla. Tunnistetut transkriptit pettävät... emme ole vielä löytäneet missä, koska ne eivät ole sijaismittari — ne ovat itse tuote.
2. Kaikki renderer-vetoinen tarvitsee kaatumistarinan. Jos kuollut käyttöliittymäprosessi voi jättää jälkeensä käyttöjärjestelmätason tilaa (hiiren kaappaus, aina päällimmäisenä -tila, sisällön suojaus), pääprosessin on omistettava nollaus.
3. Oman sovelluksen raskaimpana käyttäjänä oleminen on bugienetsintästrategia. Molemmat bugit osuivat meihin oikeissa kokouksissa ennen kuin kourallista useampi asiakas ehti huomata. ended_reason-sarake, jonka olimme lisänneet havainnoitavuutta varten kuukausia aiemmin, teki diagnoosista tietokantakyselyn arvauksen sijaan.

Molemmat korjaukset kulkivat diagnoosista julkaistuun, notarisoituun versioon päivän sisällä, kumpikin katselmoidun PR:n kyydissä regressiotesteineen. Jos käytät GeekBye v2:ta, olet saanut ne v2.0.9:stä lähtien automaattipäivityksen kautta.

Julkaisun tarinan loppuosaan pääset sarjan naapurista miksi AI-transkriptio kuulee tekniset termit väärin (v2.0.11), luotettavuuspohjatöihin artikkelista miksi AI-muistiinpanotyökalusi pysähtyy huonolla wifillä, ja siihen, miten overlay pysyy näkymättömänä näytönjaon aikana varastamatta klikkauksiasi.