Belső appok AI-jal · Lecke 05

Kié az app, és ki tartja életben

A belső appok többsége nem technikai hiba miatt áll le, hanem azért, mert a készítője továbblépett. Ilyenkor derül ki, hogy a hozzáférési kulcsok az ő gépén voltak, a dokumentáció pedig a fejében.

Vissza a tananyaghoz


Az első kérdés a gazda

Mielőtt egy prototípusból éles rendszer lesz, négy kérdést teszek fel. Ki lesz a gazdája két év múlva, ha a mostani készítője már máshol dolgozik? Mi történik a folyamattal, ha holnap reggel leáll, és mennyi idő alatt lehet visszaállni a régi módszerre? Milyen adat megy át rajta, és ki fér hozzá ma, a tervezett hozzáférésen túl? Mennyi a belső órák valós ára három évre vetítve?

Ha az első kérdésre nincs név, a többit nem is nézem. Tapasztalatom szerint ez az egy kérdés a belső appok nagyjából harmadát visszaküldi prototípus állapotba, és ez így van rendjén.


A busz faktor

A szoftverfejlesztésben busz faktornak hívják azt a számot, ahány ember kiesése után egy projekt megáll. Avelino és társai 2016-ban 133 ismert nyílt forráskódú projektet vizsgáltak meg a GitHubon, és 65 százalékuknál ez a szám legfeljebb kettő volt. Ezek a projektek nyilvánosak, sok szem látja őket, mégis egy vagy két emberen múlnak.

Egy belső app busz faktora szinte mindig egy. Pécsett egy magánklinikán az időpontokra emlékeztető üzeneteket küldő appot a recepció vezetője építette, és amikor hosszabb betegszabadságra ment, kiderült, hogy az üzenetek az ő személyes fiókjáról mentek ki. Három hétig senki nem tudta újraindítani, és ezalatt érezhetően több páciens maradt el.


Átadás nélkül

  • A kulcsok a készítő gépén vannak
  • A logika a fejében él
  • A hibákat ő javítja, szóban jelezve
  • Ha elmegy, az app vele megy

Átadással

  • A kulcsok céges fiókhoz tartoznak
  • Egy oldal leírás van róla
  • Van egy második ember, aki ismeri
  • A gazda és a karbantartó külön meg van nevezve

Mi kell ahhoz, hogy átadható legyen

Négy dolgot kérek minden belső apphoz, amire mások is támaszkodnak. Kell egy megnevezett üzleti gazda, aki a működéséért felel, és aki nem feltétlenül az informatikán dolgozik. Mellé egy technikai karbantartó, aki hozzá tud nyúlni, ha valami elromlik. Minden kapcsolathoz céges fiók és céges kulcs kell, személyes belépés helyett. Végül egy egyoldalas leírás arról, mit csinál, honnan veszi az adatot, hová ír, és mi a teendő, ha leáll.

A második ember nem luxus. Egy kis cégnél sem kell ehhez külön csapat, elég, ha a készítő mellett egy kolléga egyszer végigcsinálja vele a hibaelhárítást, és a leírásból egyedül is boldogul.


A függőségek is öregszenek

Egy AI segítségével épített app ritkán áll önmagában. Nyelvi modellre, adatbázis szolgáltatásra, tárhelyre és néhány külső programkönyvtárra épül, és ezek mind változnak. A modellszolgáltatók nyilvános menetrend szerint vezetik ki a régi modelleket, az Anthropic például legalább hatvan nappal előre jelzi egy modell kivezetését. Az értesítő levél a regisztráló címére megy, és ha az a kolléga már nincs a cégnél, egy hétfő reggel derül ki, hogy az app nem válaszol.

Ezért a gazda feladata az is, hogy tudja, mire épül az app, és egy listán vezesse. Egy AI rendszer nem egyszeri beruházás, hanem üzemeltetett eszköz, aminek karbantartási ciklusa van.


Források és további olvasnivaló

Avelino, G., Passos, L., Hora, A., Valente, M. T., A Novel Approach for Estimating Truck Factors, ICPC 2016. A négy kérdésről ebben a cikkemben, a modellek kivezetéséről és a függőségi leltárról A modell, amire építettél, nyugdíjba megy című írásomban, a belső felelős szerepéről itt írtam.


← Előző lecke Következő lecke →

Workshop

AI Transformation Day

Egésznapos, vezetőknek szóló program. Feltérképezzük, hol tart a szervezet, mi az első reális lépés, és milyen belső feltételek szükségesek a sikerhez. A nap végén konkrét, priorizált cselekvési lista.

Érdekel a program →