A tévedés, amivel mindenki kezdi
Amikor egy AI projekt elakad, az első reflex az, hogy a technológiát okoljuk. Nem elég okos a modell, kevés az adat, rossz a promptolás. A tapasztalat viszont mást mutat. A leállított bevezetések nagy részénél a rendszer pontosan azt csinálta, amire tervezték.
A törés máshol van. Senki nem tudja megmondani, mennyit ért a dolog. A kollégák nem használják, mert nem értik, mikor bízhatnak benne. A vezető mást várt, mint ami elkészült. A projekt gazdája elment a cégtől, és nem maradt utána semmi, amiből a következő ember dolgozni tudna.
Ezek nem technikai problémák. Emberi és folyamati problémák, és pont ezért marad rájuk a legkevesebb figyelem egy technikai csapatban.
Amire a csapat figyel
- Melyik modell a legjobb
- Hogyan legyen felépítve a prompt
- Milyen eszközöket kapjon a rendszer
- Mennyire pontos a kimenet
Amin a projekt eldől
- Miért éri meg ezt megcsinálni
- Ki mondja meg, hogy jó lett
- Mikor kell embernek döntenie
- Mi történik vele fél év múlva
A négy visszatérő buktató
A megoldás keres problémát. Valaki látott egy lenyűgöző demót, és utána kereste hozzá a felhasználási esetet. Az így indult projektek szinte mindig megállnak az első valódi akadálynál, mert nincs mögöttük olyan fájdalom, ami átvinné rajta.
Nincs kiindulási mérés. Ha a bevezetés előtt nem tudjuk, mennyi időbe telt eddig egy feladat, akkor utána sem fogjuk tudni, gyorsult-e. Az érzés nem bizonyíték, és a következő költségvetési körben ez ki fog derülni.
Az elvárás sosem lett kimondva. A vezető fejében nyolcvan százalékos pontosság volt, a fejlesztő fejében hatvan is elég lett volna. Egyikük sem mondta ki. A rendszer hetven százalékon teljesít, és mindkettőjüknek igaza van abban, hogy csalódtak.
Nincs gazdája. A bevezetés után marad egy működő rendszer, amihez senki nem ért, és amit senki nem érez a magáénak. Az első hibánál kikapcsolják.
Egy technikailag közepes megoldás, aminek van gazdája, mérése és kimondott elvárása, sokkal tovább él, mint egy technikailag kiváló, aminek nincs.
Mit jelent ez az architekt munkájára
Az AI megoldásarchitekt szerepe félreérthető. A név technikai munkát sugall, a valóságban viszont az idő nagyobbik része fordítás. Üzleti problémát fordítunk technikai megoldásra, aztán technikai kompromisszumot fordítunk vissza üzleti nyelvre, hogy a döntéshozó tudjon dönteni.
Ez a tananyag erről a fordítói munkáról szól. A felderítéstől indul, ahol még nincs megoldás, csak kérdések, és addig tart, amíg a rendszer önállóan él a szervezetben, nélküled is.
Nem a modellválasztásról lesz szó, és nem is a promptolásról. Ezekre külön anyagok vannak. Itt az van, ami ezeken túl dönti el, működik-e a dolog a valóságban.
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, prioritizált cselekvési lista.
Érdekel a program →