Procjena infrastrukture podataka za AI: Jesu li vaši podaci spremni?

Procjena infrastrukture podataka za umjetnu inteligenciju je strukturirana provjera mogu li vaši podaci podnijeti AI sustav koji želite izgraditi. Odgovara na pet pitanja: postoje li pravi podaci, smijete li ih pravno koristiti za tu svrhu, može li ih model dohvatiti u obliku i brzinom koju sustav traži, jesu li dovoljno točni i dosljedni da se iz njih uči, i može li itko reći odakle su došli. Traje danima, a ne mjesecima, i najjeftiniji je način da otkrijete kako obećavajući AI projekt još nije izvediv.

Nalaz koji timove iznenadi rijetko je taj da podaci nedostaju. Iznenađenje je da podaci postoje u sedam sustava, u četiri formata, s tri nespojive definicije pojma "kupac", a nitko nije zadužen za usklađivanje. Model nikada nije bio teški dio. Teški dio je pred njega postaviti čistu, označenu, pravno upotrebljivu i pouzdano osvježavanu tablicu, a upravo ondje završava većina stvarnog truda u AI projektu.

Što je procjena AI podatkovne infrastrukture?

To je dijagnostički prolaz kroz sloj podataka ispod predloženog use casea: izvori, pipelineovi, pohrana, kvaliteta, vlasništvo i pravna osnova. Rezultat nije preporuka platforme. Rezultat je presuda po use caseu (spreman, spreman nakon točno određenog posla, ili neodrživ na postojećim podacima) uz procijenjen popis onoga što bi zatvaranje praznina zahtijevalo.

Uži je od cjelovitog AI readiness audita, koji uz to vaga izvedivost, ROI, regulatornu izloženost i sposobnost organizacije da sustav uopće usvoji. Spremnost podataka jedna je dimenzija tog audita, ali dimenzija koja najčešće određuje odgovor, pa je vrijedi razumjeti zasebno. Ako birate između to dvoje: širi audit pravi je instrument kada imate više kandidata koje treba rangirati, a fokusirani data assessment kada je use case već odabran i otvoreno je samo mogu li ga podaci ponijeti.

Dvije stvari nije. Nije projekt kvalitete podataka: mjeri kvalitetu, ne popravlja je. I nije program modernizacije. Mnogi AI use caseovi sasvim dobro rade na bazi staroj deset godina uz noćni export, a reći klijentu da mu treba lakehouse prije nego što može klasificirati support tickete znači prodavati infrastrukturu, a ne rješavati problem.

Zašto spremnost podataka odlučuje hoće li AI projekt zaživjeti?

Zato što se problemi s podacima otkrivaju kasno, a procjenjuju rano. Procjena za AI izgradnju piše se prema podacima za koje svi vjeruju da postoje. Posao se zatim radi nad podacima koji stvarno postoje, a razliku između to dvoje upija rokovnik.

Obrazac je dovoljno postojan da se može predvidjeti. Pilot radi na ručno očišćenom izvatku koji je netko jednom, ručno, prebacio u tablicu. Rezultati su dobri. Projekt se odobrava na temelju tih rezultata. Onda produkcija treba iste podatke automatski, svaki dan, iz izvornog sustava, i ispostavi se da je izvadak uključivao četiri ručna joina, jednu prosudbu o tome koji duplikat zadržati i stupac koji kolegica u operativi vodi privatno. Pilot nije dokazao da sustav radi. Dokazao je da radi na podacima koje nijedan pipeline trenutno ne proizvodi.

Zato praznine u podacima nadmašuju gotovo svaki drugi rizik. Problem izvedivosti rješava se pregledom literature. Problem prihvaćanja rješava se s ljudima kojih se tiče. Praznina u podacima mora se izgraditi, a ta izgradnja često je veća od AI projekta koji je trebala poduprijeti. Nekoliko najčešćih pogrešaka pri integraciji AI-ja zapravo su problemi s podacima prerušeni u inženjerske.

Što zapravo znači da su podaci "AI ready"?

Spremnost nije jedna ocjena. To je šest neovisnih svojstava, a use case može pasti na bilo kojem od njih dok na preostalih pet izgleda zdravo.

1. Pristup

Može li sustav čitati podatke programski, po rasporedu, bez čovjeka u petlji? Zvuči trivijalno, a često nije. Podaci zaključani u vendorskom SaaS proizvodu bez export APIja, PLC u pogonu koji govori vlasnički protokol, alat za izvještavanje koji prikazuje brojke ali ih ne ispušta, ili baza koju operativa ne da nikome drugome upitivati tijekom radnog vremena: svaki od tih slučajeva je problem pristupa i svaki pretvara dvotjednu integraciju u pregovore.

Provjerite i dosadne blokade. Tko drži pristupne podatke. Postoji li read replica ili svaki upit ide na produkciju. Nije li export koji "radi svake noći" već mjesec dana tiho padao jer nitko ne gleda.

2. Pokrivenost i reprezentativnost

Sadrže li podaci situacije s kojima će se sustav susresti, otprilike u omjerima u kojima će se susretati? Klasifikator grešaka treniran na fotografiranim defektima promašit će one koje nitko nije fotografirao. Model potražnje treniran na 2024. i 2025. mora odgovoriti jesu li te godine bile normalne. Model prijevare treniran na uhvaćenim prijevarama nauči prepoznavati upravo one koje vaše postojeće kontrole ionako hvataju.

Konkretno tražite sustavni izostanak: klasu slučajeva koja nedostaje ne slučajno, nego zbog načina prikupljanja. Nasumične praznine model kvare blago. Sustavne praznine proizvode model koji samouvjereno griješi točno u situacijama koje su bitne.

3. Kvaliteta i dosljednost

Kvaliteta je mjerljiva, a mjerenje traje sate, ne tjedne. Potpunost po stupcu, stopa duplikata, smislenost vremenskih oznaka, rasponi vrijednosti izvan fizički mogućeg i udio zapisa koji krše poslovno pravilo za koje su svi pretpostavljali da se provodi.

Dosljednost je teža polovica. Pitanje je znači li isto polje istu stvar kroz sustave i kroz vrijeme. Statusni kod prenamijenjen 2023. "Regija" koju financije i prodaja definiraju različito. Mjerna jedinica koja se promijenila s promjenom dobavljača. Modeli takve nedosljednosti upijaju kao signal i proizvode ponašanje koje poslije nitko ne zna objasniti.

4. Oznake i ground truth

Supervised learning treba primjere točnog odgovora, a većina organizacija ima ih manje nego što misli. Pitanje nije jesu li ishodi negdje zabilježeni, nego jesu li zabilježeni tako da se vežu na ulaz, s ispravnim vremenskim redoslijedom.

Dva se načina kvara ponavljaju. Prvi je label leakage: polje koje se puni tek nakon što je ishod poznat, zbog čega model izgleda izvrsno u testiranju i beskorisno u produkciji, jer je u trenutku predikcije to polje prazno. Drugi je neslaganje: dva stručnjaka isti slučaj označe različito, što ograničava dosezivu točnost modela na razinu ljudskog slaganja, bez obzira na arhitekturu. Ako nikada niste izmjerili slaganje među ocjenjivačima, još ne znate koja je ciljna točnost uopće dostižna.

Gdje oznaka nema, assessment treba procijeniti trošak njihova stvaranja, jer je taj trošak stvaran i obično najveća pojedinačna stavka projekta.

5. Lineage i governance

Lineage je sposobnost da se odgovori odakle je broj došao, tko ga je transformirao i po kojoj ga pravnoj osnovi držite. Bitno je poslovno, jer modelu čije podrijetlo nitko ne može pratiti nitko neće povjeriti odluku s posljedicama. Bitno je i pravno, jer i GDPR i EU AI Act postavljaju pitanja na koja odgovara jedino lineage.

Praktične provjere: postoji li imenovani vlasnik po izvoru, jesu li osobni podaci identificirani i njihova pravna osnova dokumentirana, jesu li rokovi čuvanja definirani i stvarno primijenjeni, i postoji li zapis o privoli ili ugovornoj osnovi za korištenje tih podataka za treniranje modela, što je često druga svrha od one za koju su prikupljeni. Upravo ta zadnja točka izmakne ljudima. Podaci zakonito prikupljeni radi pružanja usluge nisu automatski zakoniti kao podaci za treniranje, a preklapanje GDPRa i EU AI Acta mjesto je gdje se to pitanje rješava.

6. Put isporuke predikcije

Podaci za treniranje i podaci u produkciji dva su različita problema. Model treniran na tablici u warehouseu mora u trenutku inferencije raditi nad podacima koji stižu živim putem, sa svojom latencijom, dostupnošću i vlastitim načinima otkazivanja. Taj put ocijenite izričito: koliko svjež ulaz mora biti da bi predikcija bila korisna, što se događa kad izvor kasni ili padne, i primjenjuje li se ista logika transformacije na oba mjesta.

Kada treniranje i serving primjenjuju različite transformacije, dobivate training-serving skew, klasu grešaka zbog koje model s dobrim offline rezultatom mjesecima tiho podbacuje u produkciji prije nego što itko shvati zašto.

Kako brzo procijeniti kvalitetu podataka?

Sondiranjem, a ne popisivanjem. Potpuni katalog podataka traje mjesecima i odgovara na pitanja koja niste postavili. Ciljana sonda traje danima i odgovara na ono bitno: može li se ovaj konkretni use case izgraditi na ovim konkretnim podacima.

Redoslijed koji funkcionira:

• Krenite od odluke, ne od podataka. Zapišite koju predikciju sustav mora dati, u kojem trenutku i kojim bi informacijama čovjek u tom trenutku raspolagao. To definira skup značajki i odmah isključuje svako polje koje u trenutku predikcije neće postojati.
• Povucite pravi uzorak, s kraja na kraj. Ne kurirani izvadak. Dvanaest mjeseci produkcijskih podataka kroz stvarni put pristupa koji biste koristili, tako da se trenje pri izvlačenju pokaže u assessmentu, a ne u trećem mjesecu.
• Profilirajte ih strojno. Udjeli nedostajućih vrijednosti, kardinalnost, duplikati, distribucije, kontinuitet vremenskih serija. Posebno tražite skokove u distribuciji, koji obično označavaju migraciju sustava ili promjenu definicije, a ne stvarni događaj.
• Uskladite s poznatom istinom. Uzmite brojku kojoj tvrtka već vjeruje, mjesečnu proizvodnju, prihod ili broj grešaka, i rekonstruirajte je iz sirovih podataka. Ako ne možete reproducirati broj koji organizacija izvještava svaki mjesec, prazninu ste našli prije modela.
• Testirajte oznake. Neka dva stručnjaka neovisno označe istih pedeset slučajeva i izmjerite koliko se često slažu. Ta jedna vježba postavlja realan strop točnosti za cijeli projekt.
• Isprobajte slabu baseline. Namjerno prilagodite nešto jednostavno, logističku regresiju ili gradient boosted tree na očitim značajkama. Ako slab model ne nađe nikakav signal, sofisticiranija arhitektura rijetko spašava stvar. Ako slab model radi sumnjivo dobro, tražite leakage.

Taj posljednji par najvrjedniji je sat cijelog assessmenta. Slaba baseline je istodobno i donja granica i alarm.

Treba li vam data warehouse prije nego što krenete s AI-jem?

Najčešće ne. Zahtjev je pouzdan i ponovljiv put od izvora do modela, a raspoređeni export u object storage to zadovoljava za velik dio prvih projekata. Warehouseovi i lakehouseovi isplate se kada mnogo use caseova dijeli iste podatke, kada governance mora biti centraliziran ili kada analitičarima treba samostalan pristup. To su dobri razlozi. "Treba nam prije nego što možemo raditi AI" nije jedan od njih.

Argument redoslijeda zapravo ide u suprotnom smjeru. Graditi platformu prije validiranog use casea znači projektirati prema zahtjevima koje nagađate. Graditi prvi use case na skromnom pipelineu uči vas što platforma stvarno mora raditi, a pipeline napisan za to rijetko je bačen trud. Iznimka je kada assessment nađe istu prazninu u podacima kako blokira tri ili četiri kandidata odjednom. Tada je zajednički temelj jeftiniji put i treba ga graditi namjerno, a ne kao nuspojavu.

Čuvajte se i obrnutog promašaja. Tim koji potroši osamnaest mjeseci na platformu i nije isporučio nijedan AI sustav nije smanjio nijedan rizik. Pretvorio je AI projekt u infrastrukturni projekt, a infrastrukturni projekti mjere se rokovima isporuke koje platforme za podatke povijesno loše poštuju.

Što EU AI Act traži od vaših podataka?

Za visokorizične sustave EU AI Act postavlja izričite obveze na sloju podataka. Skupovi podataka za treniranje, validaciju i testiranje moraju biti relevantni, dovoljno reprezentativni te u najvećoj mogućoj mjeri bez pogrešaka i potpuni s obzirom na namjenu. Pružatelji moraju primjenjivati prakse upravljanja podacima koje pokrivaju procese prikupljanja, podrijetlo podataka, korake pripreme, formuliranje pretpostavki, procjenu dostupnosti i prikladnosti te ispitivanje pristranosti koja bi mogla utjecati na zdravlje, sigurnost ili temeljna prava.

Pročitane kao inženjerski zahtjevi, a ne kao pravni tekst, te se obveze prevode u stvari koje data assessment može provjeriti već sada: dokumentirano podrijetlo po izvoru, pisani zapis koraka pripreme i transformacije, ispitivanje pristranosti prema skupinama na koje sustav utječe, i dokaz da podaci odražavaju okruženje u kojem će sustav raditi. Obveze bilježenja iz članka 12. dodaju još jedan zahtjev, da sustav bilježi što je radio, što je odluka u dizajnu pipelinea i bolno se naknadno ugrađuje.

Je li vaš sustav visokorizičan ovisi o njegovoj namjeni, a to je vrijedno riješiti rano jer mijenja arhitekturu podataka. Klasifikacija vašeg AI sustava prema okviru rizika objašnjava kako se ta prosudba donosi, a zahtjevi za čuvanje dokumentacije AI sustava objašnjavaju koliko dugo nastali zapisi moraju preživjeti. U reguliranim područjima poput zdravstva MDR i IVDR dolaze povrh svega toga i dodatno podižu razinu dokaza. Ovo je rad na spremnosti, a ne pravni savjet, ali obaviti ga prije nego što se arhitektura zamrzne razlika je između projektiranja za usklađenost i naknadne pregradnje.

Koje su najčešće praznine u podatkovnoj infrastrukturi?

Kroz assessmente se ponavlja nekolicina istih:

• Nema ground trutha. Ishodi se znaju neformalno, ali nikad nisu zabilježeni uz slučaj koji ih je proizveo. Često u održavanju, gdje je popravak evidentiran, a način kvara nije.
• Ručni koraci skriveni unutar pipelinea. Tablica, preimenovanje, osoba koja odlučuje koji duplikat ostaje. Nevidljivo u pilotu, blokirajuće u produkciji.
• Nema povijesne dubine. Sustav koji drži podatke prepisuje umjesto da dodaje, pa postoji trenutno stanje i nikakva povijest za učenje. Otkriti to u prvom tjednu je dobar tjedan. Otkriti u četvrtom mjesecu nije.
• Pomak definicije. Polje kojem se značenje promijenilo bez migracije, pa u jednom stupcu žive dva razdoblja.
• Nedokumentirani osobni podaci. Slobodna tekstualna polja s imenima, bilješkama ili identifikatorima koje nitko nije klasificirao, a isplivaju u pregledu usklađenosti i zaustave lansiranje.
• Nema nadzora. Pipelineovi koji padaju tiho. Ako ništa ne javi da jučerašnje učitavanje nije stiglo, model neprimjetno servira predikcije na zastarjelom ulazu.
• Senzorski i edge podaci koji nikad ne napuste stroj. Često u proizvodnji, gdje signal postoji, ali povezivosti za prikupljanje nema, pa je projekt prikupljanja zapravo prvi projekt. Prediktivno održavanje stoji i pada upravo na tome.

Praktična lista provjere spremnosti podataka

Ocijenite svaku stavku za jedan konkretan use case. Sve što je odgovoreno s "ne" ili "ne znamo" radna je stavka s troškom, a ne detalj koji se rješava poslije.

• Predikcija, njezin trenutak i informacije dostupne u tom trenutku su zapisani.
• Svako potrebno polje dohvatljivo je automatiziranim putem, s imenovanim vlasnikom.
• Postoji barem jedan puni poslovni ciklus povijesti, uz dokumentirane poznate praznine.
• Ground truth postoji, veže se na ulazni zapis i bio je dostupan tek nakon trenutka predikcije.
• Slaganje među ocjenjivačima je izmjereno, ili su oznake objektivne.
• Postoji izvještaj profiliranja: nedostajuće vrijednosti, duplikati, rasponi, pomaci distribucije kroz vrijeme.
• Poslovna brojka je rekonstruirana iz sirovih podataka i usklađuje se.
• Osobni podaci su identificirani, s pravnom osnovom za baš ovu svrhu i definiranim rokom čuvanja.
• Produkcijski put isporuke predikcije je opisan, uključujući zahtjeve svježine i ponašanje pri kvaru.
• Treniranje i serving dijele jednu implementaciju transformacija.
• Kvarovi pipelinea podižu alarm koji prima imenovana osoba.
• Slaba baseline je prilagođena, a rezultat pregledan i zbog signala i zbog leakagea.

Dvanaest stavki, većina odgovoriva u dan ili dva. Vrijednost nije u ocjeni. Vrijednost je u tome što svako "ne znamo" postane vidljivo prije nego što postane probijeni rok.

Što učiniti kada podaci nisu spremni?

Nisu spremni je nalaz, a ne presuda. Obično su na raspolaganju tri odgovora, a assessment treba reći koji vrijedi.

Suzite use case. Često podaci podnose manju verziju iste ideje. Umjesto predviđanja kvarova u cijelom pogonu, predviđajte ih na dva tipa strojeva s instrumentiranom poviješću. Uski sustav koji zaživi bolji je od širokog koji čeka.

Prvo pokrenite fazu prikupljanja. Ako je praznina u oznakama ili povijesti, prvi projekt postaje uredno bilježenje podataka, a AI izgradnja se planira kada se nakupi dovoljno. To je neglamurozna preporuka koja spašava cijele budžete, a rok treba iznijeti pošteno: ako vam treba godina sezonskih podataka, treba vam godina.

Promijenite pristup. Neke su praznine arhitektonske, a ne apsolutne. Weak supervision, transfer learning, sintetička augmentacija ili sustav na pravilima uz human-in-the-loop mogu premostiti oskudne oznake. Svaki ima svoju cijenu i svaki je legitiman odgovor, pod uvjetom da je odabran promišljeno, a ne da se izbjegne loša vijest.

Ono što nije nijedan od ta tri: nastaviti svejedno i nadati se da će se podaci popraviti. To je put opisan u tekstu kako izbjeći neuspjeh AI projekta, i svaki put završi jednako.

Iskren zaključak

Spremnost podataka ograničenje je koje određuje koji AI možete izgraditi, a doznaje se unaprijed, uz djelić troška koji nosi otkrivanje usred izgradnje. Assessment je namjerno neglamurozan: povucite prave podatke pravim putem pristupa, profilirajte ih, uskladite ih s brojkom kojoj tvrtka vjeruje, izmjerite slažu li se vaši stručnjaci međusobno, prilagodite nešto jednostavno i zapišite što nedostaje.

Izlazi use case koji je izvediv odmah, onaj koji je izvediv nakon točno određenog i procijenjenog posla, ili jasna izjava da podaci tu ideju još ne mogu ponijeti. Sva tri ishoda su korisna. Samo je jedan skup ako se sazna kasno.

Ako još odlučujete pripada li AI uopće na roadmap, rani signali spremnosti za AI jeftinije su prvo štivo, a realan ROI strojnog učenja postavlja očekivanja o tome što sustav koji radi zapravo vraća. Kada je pitanje podataka riješeno, integracijski rad koji slijedi troši svoj budžet na stvarnu neizvjesnost, a ne na ponovno otkrivanje da se brojke nikad nisu slagale.

Česta pitanja

Trebamo li data warehouse prije nego krenemo s AI-jem?

Za prvi projekt obično ne. Warehouse pomaže analitici u velikom opsegu, ali jedan dobro shvaćen izvor često je dovoljan da se primjena dokaže. Graditi warehouse prvo odgađa AI posao tromjesečjima i često optimira za pitanja izvještavanja, a ne za ona koja model treba.

Koliko traje procjena podatkovne infrastrukture?

Obično dva do četiri tjedna, ovisno o broju sustava u opsegu i brzini odobrenja pristupa. Odobrenja su najčešće najdulja stavka, a ne analiza, zbog čega je pronaći vlasnika podataka u prvom tjednu važnije od bilo kojeg tehničkog koraka.

Što ako su nam podaci razasuti po sustavima koji međusobno ne komuniciraju?

To je uobičajeno polazno stanje, a ne diskvalifikacija. Procjena utvrđuje koja su spajanja primjeni doista potrebna umjesto da pretpostavi da se sve mora ujediniti. Većina prvih projekata treba dva ili tri povezana izvora, a ne program integracije na razini cijele tvrtke.

Možemo li procijeniti spremnost bez davanja vanjskom partneru pristupa produkcijskim podacima?

Možete. Sheme, broj redaka, opisi polja i mali anonimizirani ili sintetički uzorak odgovaraju na većinu pitanja o spremnosti. Puni pristup postaje važan pri prijelazu s procjene na izgradnju, a tada je opseg dovoljno uzak da opravda uredan ugovor o podacima.