Mali model ima smisla procjenjivati samo uz jasno omeđen poslovni zadatak i vlastiti reprezentativni uzorak rada. Odluka ne počinje pitanjem koji je model popularniji, nego pitanjem može li sustav isporučiti prihvatljiv izlaz unutar potrebnog vremena, na raspoloživom uređaju ili uz raspoloživu vezu. Za ERP i operativne procese vrijedi dodatno pravilo: model može pripremiti prijedlog, ali službena transakcija mora ostati pod odgovornošću ovlaštene osobe.
Uski zadatak ima prepoznatljiv ulaz, ograničen izlaz i osobu koja može provjeriti rezultat. Primjeri mogu uključiti razvrstavanje kratkih upita prema unaprijed određenim kategorijama, izdvajanje polja iz standardiziranog dokumenta ili sastavljanje nacrta odgovora prema odobrenoj bazi znanja.
Takav zadatak nije isto što i otvoreno savjetovanje, tumačenje nejasnih pravila ili samostalno knjiženje. Što je poslovna posljedica veća, to su važniji kontrola ulaza, pregled izlaza, pravilo iznimke i trag odluke.
Apple u dokumentaciji Foundation Models opisuje Foundation Models za razvoj aplikacija. Ta dokumentacija može biti relevantna pri razmatranju implementacije u aplikaciji. Podržane uređaje, jezike, uvjete dostupnosti i stvarno ponašanje za konkretan slučaj potrebno je provjeriti prije projektne odluke. Iz same opće dokumentacije ne treba izvoditi zaključak o prikladnosti za pojedini poslovni proces.
Dobar pilot ne polazi od općenitog zahtjeva poput "uvesti AI". Polazi od jedne radne odluke.
Opišite zadatak u jednoj rečenici:
Primjer je hipotetski: računovodstveni tim želi iz opisa ulaznog dokumenta izdvojiti predloženu kategoriju za pregled. Model ne knjiži dokument i ne mijenja šifarnik. Operater provjerava prijedlog, odabire konačnu kategoriju i vodi službenu ERP transakciju. Takav raspored omogućuje mjerenje korisnosti bez prijenosa odgovornosti na model.
Ako zadatak nema jedinstven prihvatljiv izlaz, najprije treba razdvojiti slučajeve. Možda su potrebna različita pravila za domaću i stranu dokumentaciju, drugačiji postupak za nepotpune zapise ili zaseban tok za iznimke. Screening poslovnog procesa pomaže utvrditi gdje počinje i završava odluka prije izbora tehnologije.
Procjena malog modela za poslovni zadatak traži usporedbu stvarnih alternativa na istom uzorku. Alternativa može biti ručni postupak, postojeće pravilo, drugi način rada aplikacije ili model. Usporedba bez istog zadatka i istog kriterija prihvata ne daje korisnu odluku.
Kvalitetu treba vezati uz poslovni izlaz. Za klasifikaciju to može biti podudaranje s potvrđenom oznakom. Za izdvajanje polja to može biti točnost vrijednosti i cjelovitost obveznih polja. Za nacrt odgovora to može biti pridržavanje odobrenih izvora i odsutnost nedopuštenih tvrdnji.
Rezultat ne treba svesti na jednu prosječnu brojku. Zabilježite vrstu pogreške. Pogrešno razvrstavanje, propušteno obvezno polje, uvjerljiv ali nepotkrijepljen tekst i neprepoznata iznimka nose različite operativne posljedice.
Kašnjenje nije samo vrijeme stvaranja izlaza. Uključuje pripremu ulaza, slanje zahtjeva ako ga ima, čekanje odgovora, pregled operatera, ispravak i prijenos u sljedeći korak. Kratak odgovor bez potrebnog konteksta može povećati ukupno trajanje posla.
Odredite trenutak početka i trenutak završetka mjerenja. Primjerice, mjerenje može krenuti pri otvaranju radnog predmeta, a završiti pri spremnom prijedlogu za pregled. Za proces s korisnikom koji čeka važna je i stabilnost trajanja, ne samo prosjek.
Pitanje rada na uređaju ili uz vezu nije tehnički dodatak. Ono utječe na dostupnost, tok podataka i ponašanje u prekidu rada.
Kod obrade na uređaju provjerite može li konkretni uređaj izvršiti potrebni zadatak u prihvatljivom vremenu te kako aplikacija postupa pri nedostatku resursa. Kod obrade uz vezu provjerite što se događa pri slaboj ili prekinutoj vezi, kako korisnik dobiva status obrade i postoji li jasan povratak na ručni postupak.
Ne pretpostavljajte da je jedan pristup sam po sebi prikladniji. Odgovor ovisi o zadatku, uređajima u uporabi, uvjetima veze, osjetljivosti ulaza i ulozi čovjeka u kontroli izlaza.
Lokalna evaluacija jezičnog modela znači testirati ga na uzorku koji predstavlja vlastiti proces, uz kontroliran pristup podacima i jasan zapis očekivanog ishoda. "Lokalna" ne mora opisivati samo mjesto izvršavanja modela. U ovom kontekstu označava evaluaciju ukorijenjenu u stvarnim poslovnim zapisima i pravilima procesa.
Prije testiranja odredite vlasnike:
Uzorak ne mora biti velik za korisnu procjenu, ali mora pokriti stvarni raspon posla. Odvojite skup za pripremu uputa i pravila od skupa za konačnu provjeru. U protivnom postoji rizik prilagodbe upravo zapisima kojima se zatim dokazuje uspjeh.
Za svaki zapis čuvajte ulaz u odobrenom obliku, očekivani ishod ili dopušteni raspon ishoda, izlaz sustava, odluku pregledavatelja i oznaku vrste pogreške. Ako ulaz sadrži osjetljive podatke, vlasnik podataka treba odrediti minimalni potreban sadržaj uzorka i dopušteni način obrade.
Rang-lista ne odgovara na pitanje odgovara li određeni način rada vašem zadatku. Korisniji je jednostavan okvir odluke.
Nastavite prema ograničenoj primjeni kada uzorak pokazuje prihvatljivu kvalitetu prema unaprijed odobrenom kriteriju, trajanje odgovara stvarnom tijeku rada, iznimke imaju dodijeljen put i korisnik razumije kada izlaz ne smije koristiti bez provjere.
Vratite se oblikovanju zadatka kada se pogreške ponavljaju u istoj skupini ulaza, kada referentni ishod nije dovoljno jasan ili kada operater troši više vremena na provjeru nego što postupak štedi.
Zadržite ručni ili postojeći postupak kada kvaliteta, trajanje ili uvjeti rada ne podupiru poslovnu svrhu. Takav je nalaz vrijedan rezultat procjene. Sprječava uvođenje dodatnog sloja rada bez jasne koristi.
ORKA pristup razdvaja odgovornosti: ORKA vodi svakodnevnu suradnju i procesni okvir, ERP ostaje mjesto službenih transakcija, a Trueforce pokriva specijalizirani inženjerski rad kada je potreban. Ta podjela pomaže očuvati jasnu granicu između prijedloga sustava i poslovne odluke.
Mali model može dati koristan rezultat na standardnom zadatku, a ipak biti neprikladan za iznimke. Pilot ne smije skrivati teške slučajeve niti ih proglašavati uspjehom bez pregleda.
Kvaliteta može varirati s jezikom, formatom dokumenta, duljinom ulaza i nejasnim pojmovima. Dostupnost funkcije može ovisiti o uređaju, postavkama aplikacije, vezi ili drugim uvjetima koje treba provjeriti za projekt. Promjena uputa, aplikacije ili radnog toka može promijeniti rezultat, pa nakon značajne promjene treba ponoviti relevantnu provjeru.
Najvažnije ograničenje ostaje odgovornost. Model ne poznaje poslovni kontekst izvan dostavljenog ulaza i ne preuzima odgovornost za posljedicu izlaza. Proces mora imati osobu ili pravilo koje zaustavlja, dopunjuje ili odbacuje nepouzdan rezultat.
Prije odluke o ograničenom uvođenju zabilježite sljedeće:
Ako proces još nema jasan ulaz, vlasnika odluke ili put iznimke, prvo uredite proces. Nakon toga razgovarajte s ORKA timom o screeningu i evaluaciji na vlastitom uzorku, bez preskakanja odgovornosti koje ERP i operativni rad zahtijevaju.