Mire való a prototípus
Az FDE munkájának egyik jellemző mozzanata, hogy gyorsan, kézzel foghatóan megmutatja, mi lehetséges. A prototípus nem öncél, hanem eszköz egy döntéshez. Arra a kérdésre válaszol, hogy a keretezett probléma megoldható-e egyáltalán a cég LLM platformján, elfogadható minőséggel és a valós adaton. Ez a 0-1 lépés, a semmiből a működő elsőig. Nem az a tét, hogy szép legyen vagy teljes, hanem hogy igazolja vagy cáfolja a feltevést, amelyet a felfedezés megfogalmazott.
Épp ezért a prototípus mérőeszköz is. Amint valós bemeneten fut, azonnal láthatóvá teszi, hol tart a minőség, hol bukik el a modell, és hol van szükség visszakeresésre, jobb kontextusra vagy más felépítésre. Egy demó szavakkal is meggyőző lehet, de a prototípus a valós adaton mutatja meg az igazságot. Ez a különbség adja a szerep egyik erejét. A mérnök nem beszél a lehetőségről, hanem megépíti, és a működő darab dönti el a vitát.
A vékony vertikális szelet
A leggyakoribb hiba, hogy a csapat vízszintesen kezd építeni, vagyis előbb egy általános adatréteget, egy teljes felületet, egy mindenre felkészített orkesztrációt, és csak a végén köti össze őket. Ilyenkor sokáig nincs semmi, ami tényleg működne. Az FDE ehelyett egy vékony vertikális szeletet (thin vertical slice) épít. Ez azt jelenti, hogy a teljes láncot végigviszi, de csak egyetlen, szűk eseten. A bemenettől a visszakeresésen és a modellhíváson át a felhasználó által látott kimenetig minden réteg jelen van, de mindegyik a lehető legszűkebb formában.
A vékony szelet előnye, hogy a legrövidebb úton ad valódi, végpontig működő eredményt. Mivel a lánc minden része szerepel benne, azonnal kiderül, hol van a valós nehézség. Sokszor nem ott, ahol a csapat várta. Előfordul, hogy a modell könnyen megbirkózik a feladattal, de az adathoz való hozzáférés a szűk keresztmetszet, vagy fordítva. A vertikális szelet ezeket a meglepetéseket az első napokban hozza felszínre, nem hetekkel később, amikor már drága a változtatás.
A platform primitíveire építve, nem nulláról
Az FDE gyorsaságának egyik titka, hogy nem talál fel újra mindent. A cég AI platformja kész építőelemeket, primitíveket kínál, például modellhívást, strukturált kimenetet, eszközhasználatot, visszakeresést és ügynöki mintákat. A jó mérnök ezekből komponál, ahogy a Palantir gyakorlata is leírja, ahol a kész elemek nagy részét out of the box össze lehet illeszteni, és nem kell minden ügyfélnél újraépíteni ugyanazt. Az energia így nem az infrastruktúrára megy el, hanem a helyes felépítés összerakására és a valós problémára.
Ebből fakad egy fontos szabály a prototípusra. Alapból a platform képességeire támaszkodunk, és csak ott építünk sajátot, ahol az ügyfél valós igénye ezt indokolja. A prototípus szakaszban különösen igaz, hogy minden egyedi komponens lassít és kockázatot visz be. A cél a lehető leggyorsabb út a működő eredményig, mert a prototípus értéke a tanulásban van, és minél hamarabb fut, annál hamarabb tanulunk belőle.
Szintetikus adat, majd valós adat
A prototípus gyakran nem azonnal fér hozzá a teljes éles adathoz, mert a jogosultságok, a hozzáférés és a biztonsági jóváhagyás időbe telik. Ezt nem kell megvárni. Egy bevett minta, hogy a korai scoping és prototípus szakaszban szintetikus vagy mintaadaton épül a szelet, amely elég jól utánozza a valós adat szerkezetét ahhoz, hogy a felépítést tesztelni lehessen. Így a mérnök a hozzáférés rendezése közben is halad, és a lánc már működik, mire az éles adat megnyílik.
A szintetikus adat viszont csak híd, nem cél. A valódi tanulás akkor kezdődik, amikor a prototípus először fut az ügyfél valós adatán. Ekkor jönnek elő a hiányos mezők, az inkonzisztens rekordok és a peremesetek, amelyeket egy tiszta mintaadat sosem mutatna meg. A jó FDE ezért a szintetikus adatot a felépítés próbájaként kezeli, a valós adatra váltást pedig külön, tudatos lépésként, amelytől a minőségről szóló első őszinte képet várja.
Ami megöli a prototípust
- Vízszintes építés, sokáig semmi sem működik végig
- Minden komponens sajátból, a platform helyett
- Teljes lefedettség és skálázás már az első körben
- Csiszolt felület, mielőtt a minőség bizonyított volna
- Csak demóban, sosem valós adaton fut
Ami életre kelti
- Egyetlen vékony szelet, végpontig működik
- A platform primitíveire épít, csak ott saját, ahol kell
- Egy szűk eset, tudatosan kihagyott peremesetekkel
- Nyers felület, de valós, mérhető kimenet
- Mielőbb a valós adaton fut, onnan tanul
A prototípus mint közös nyelv
A működő prototípus a mérnök és az ügyfél között közös nyelvet teremt. Egy specifikációt sokféleképp lehet érteni, egy futó megoldást viszont mindenki ugyanúgy lát. Amint a felhasználó a saját adatán próbálja ki, konkrét visszajelzést ad, ez a válasz jó, ez nem, ez itt hiányzik. Ez a visszajelzés sokkal pontosabb, mint bármilyen előzetes követelménylista, mert a valós használatból fakad. Az FDE ezt a visszajelzést gyorsan beépíti, és rövid körökben iterál.
Így a prototípus szakasz nemcsak technikai igazolás, hanem a bizalom és az irány közös finomítása is. Néhány kör után tisztázódik, mi az igazán értékes, hol elég jó a minőség, és mi marad ki. Ekkor válik felelős döntéssé a következő lépés, a robusztus megoldásarchitektúra megtervezése, amely a bizonyított szeletet viszi el a megbízható éles rendszerig. Erről szól a következő lecke.
A tét a bizonyíték, nem a teljesség. A prototípus akkor jó, ha a legrövidebb úton, valós adaton megmutatja, hogy a keretezett probléma megoldható. Ami ezen túlmutat, teljes lefedettség, csiszolt felület, korai skálázás, az ebben a szakaszban nem érték, hanem kockázat.
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 →