Inteligjenca artificiale nga piloti në prodhim: pse ngecin pilotët dhe çfarë i zhbllokon

Demoja ishte pjesa e lehtë

Shumica e nismave të inteligjencës artificiale në ndërmarrje ndjekin të njëjtin hark: piloti lë përshtypje në demo, drejtuesit miratojnë fazën tjetër dhe pastaj projekti kalon muaj të tërë në një gjendje as i vdekur, as i dorëzuar në prodhim. Sipas shumicës së vlerësimeve, mbi gjysma e pilotëve nuk arrijnë kurrë në prodhim — dhe përvoja jonë në projekte e konfirmon. Ngecja rrallë shkaktohet nga modeli. Shkaktohet nga gjithçka që demos nuk iu desh të mbijetonte: të dhëna reale të çrregullta, input keqdashës, tavane kostosh, kërkesa auditimi dhe përdorues që nuk kanë qenë në takimin e nisjes.

Zgjidhja fillon me ndryshimin e këndvështrimit. Një pilot dëshmon se një aftësi ekziston. Prodhimi kërkon të dëshmohet se sistemi sillet në mënyrë të pranueshme nën ngarkesë reale, me të dhëna reale dhe me mënyra reale dështimi — dhe ky është problem i inxhinierisë së sistemeve, jo i shkencës së të dhënave.

Zgjidhni rastet e përdorimit sipas kostos së gabimit

Vendimi më me peshë merret para se të shkruhet qoftë edhe një rresht kodi. Pilotët e ndërtuar rreth demos më mbresëlënëse zakonisht ngecin; ata të ndërtuar rreth një mënyre dështimi të tolerueshme zakonisht arrijnë në prodhim. Katër filtra bëjnë pjesën më të madhe të punës:

• Ekziston një pikënisje e matshme — minuta për rast, kosto për tiketë, madhësia e punës së prapambetur — që përmirësimi të jetë numër, jo opinion.
• Gabimet janë të rikuperueshme: një draft i gabuar rishikohet, një klasifikim i gabuar korrigjohet më tej në proces dhe asnjë output i vetëm nuk shkakton veprim të pakthyeshëm.
• Kontrolli njerëzor futet natyrshëm në rrjedhën e punës, jo si shtesë e sforcuar për arsye pajtueshmërie.
• Vëllimi është mjaft i lartë që një fitim efikasiteti prej 30–50% ta justifikojë investimin inxhinierik.

Vini re çfarë mungon: risia. Rasti i parë më i mirë për prodhim është zakonisht ai më pak spektakolari.

Themelet e të dhënave caktojnë tavanin

Cilado qoftë arkitektura — gjenerim i mbështetur në kërkim (RAG), fine-tuning apo nxjerrje e strukturuar — tavanin e cilësisë e caktojnë të dhënat, jo zgjedhja e modelit. Tri themele peshojnë më shumë. Së pari, kontrolli i aksesit duhet zbatuar në momentin e kërkimit: nëse një përdorues nuk mund ta hapë një dokument, sistemi nuk duhet të jetë në gjendje ta citojë atë në një përgjigje — dhe asnjë udhëzim brenda prompt-it nuk e zëvendëson verifikimin e të drejtave në shtresën e kërkimit. Së dyti, freskia dhe prejardhja: sistemi duhet ta dijë cilin version të një politike apo liste çmimesh po lexon, përndryshe do të përgjigjet me bindje të plotë nga të dhëna të vjetruara. Së treti, trajtimi i të dhënave të ndjeshme — fshehja e të dhënave personale, rregullat e ruajtjes, kufizimet e vendndodhjes së të dhënave — duhet projektuar para integrimit të parë, sepse shtimi i tij më vonë do të thotë rindërtim të pipeline-ve.

Vlerësimi i ndan demot nga sistemet

Treguesi më i fortë që shohim për të parashikuar nëse një pilot do të kalojë në prodhim është ekzistenca e një mekanizmi vlerësimi. Ekipet që e gjykojnë cilësinë duke shfletuar output-e nuk mund t'i përgjigjen pyetjes së vetme që ka rëndësi në rishikim: a e bëri ky ndryshim sistemin më të mirë apo më të keq?

• Ndërtoni një set referimi me raste reale — disa qindra input-e me rezultate të pritshme, të rishikuara — para se të optimizoni çfarëdo qoftë.
• Ekzekutoni vlerësimet për çdo ndryshim të prompt-it, modelit apo kërkimit, në CI, saktësisht si një suitë testesh regresioni.
• Automatizoni vlerësimin ku është e mundur, por kalibrojini gjykatësit e automatizuar me rishikime periodike njerëzore, që rezultatet të vazhdojnë të kenë kuptim.
• Ndiqeni cilësinë edhe në prodhim, jo vetëm para publikimit: rishikimi njerëzor me mostra dhe reagimet e përdoruesve janë pjesë e sistemit, jo shtesë e mëvonshme.

Mbrojtjet dhe modelet e integrimit

Në arkitekturën e prodhimit, modeli është një varësi e jashtme jo e besueshme dhe duhet integruar si e tillë: me timeout-e, me riprovime të kufizuara mbi operacione idempotente dhe me një rrugë rezervë deterministe për rastin kur modeli dështon ose degradon. Kufizojeni ndërfaqen në të dy anët — validoni dhe pastroni input-in, kërkoni output të kufizuar me skemë, që validohet para përdorimit dhe nuk analizohet si tekst i lirë me shpresë, dhe jepini modelit aksesin më të ngushtë të mundshëm te veglat. Output-et që shkaktojnë veprime — shkrime në bazën e të dhënave, email-e, transaksione — kalojnë nëpër një shtresë autorizimi që e trajton output-in e modelit si input të pabesuar përdoruesi, sepse pikërisht kjo është.

Model operimi, jo projekt

Pilotët janë projekte; sistemet në prodhim janë produkte. Dikush duhet t'i zotërojë cilësinë, koston dhe incidentet pas nisjes: versionet e modelit dhe të prompt-eve fiksohen dhe ndryshohen vetëm me rishikim, kostoja për kërkesë buxhetohet dhe monitorohet, dhe dikush është në kujdestari për natën kur ofruesi degradon. Ekipet që e caktojnë këtë pronësi para nisjes i mbajnë sistemet e tyre; ato që nuk e bëjnë shohin si cilësia rrëshqet, derisa dikush e fik funksionin në heshtje.

Atë që e zhbllokon një pilot të ngecur rrallë e bën një model më i mirë. E bëjnë një rast përdorimi më i ngushtë, një mekanizëm i vërtetë vlerësimi, mbrojtje që e marrin dështimin si të mirëqenë dhe një pronar me emër. Asgjë nga këto nuk është spektakolare — por pikërisht këto e kthejnë një demo në infrastrukturë.