Najvažnija odluka o AI-ju rijetko je prompt. Promptovi su važni, ali nalaze se na rubu sustava. Pozadinski sustav određuje hoće li AI funkcionalnost postati korisna mogućnost proizvoda ili impresivan demo kojemu se ne može vjerovati, koji se ne može poboljšavati niti imati pod vlastitom kontrolom.

Ta razlika mijenja način na koji tehnički lideri trebaju razmišljati o radu s AI-jem. Umjesto pitanja: „Koji model bismo trebali koristiti?”, počnite težim pitanjem: „Iz čega će ovaj proizvod učiti, kako ćemo ga evaluirati i tko je odgovoran kada pogriješi?”

Treniranje AI-ja nije samo podešavanje težina modela. U većini timova za razvoj proizvoda praktičan se rad sastoji od izgradnje tokova podataka, povratnih sprega, pravila i operativnih navika koje omogućuju sustavu da se sigurno poboljšava tijekom vremena.

Počnite od odluke, a ne od modela

AI funkcionalnost trebala bi podržati konkretnu korisničku odluku ili smanjiti konkretan dio posla. „Dodajte chatbot” nije zahtjev za proizvod. „Pomozite agentima korisničke podrške da pronađu relevantno pravilo prije odgovora” bliže je tome. Time se definiraju korisnik, trenutak potrebe i ishod koji se može procijeniti.

Ta jasnoća trebala bi oblikovati pozadinski sustav. Ako sustav treba predložiti odgovor, zasebno pohranite ulazne podatke, dohvaćeni kontekst, generirani prijedlog, konačnu ljudsku radnju i ishod. Prihvaćanje, uređivanje ili odbacivanje prijedloga od strane korisnika vrijedna je povratna informacija o proizvodu. Tretiranje svih tih ishoda kao jednakih odbacuje signal potreban za poboljšanje funkcionalnosti.

Prije dizajniranja procesa definirajte kako izgleda dobro. Ovisno o slučaju upotrebe, to može uključivati točnost, potpunost, vrijeme odgovora, usklađenost s pravilima ili količinu potrebne ljudske dorade. Jedinstvena ocjena kvalitete može biti primamljiva, ali često skriva važne kompromise. Brz odgovor koji samouvjereno navodi pogrešno pravilo nije uspjeh.

Izgradite pozadinski sustav koji čuva signale za učenje

AI aplikacije često tiho ne uspijevaju jer pozadinski sustav bilježi premalo konteksta. Zapis u dnevniku koji kaže da je zahtjev uspio koristan je za operacije, ali nije dovoljan za učenje. Sustav treba trajni zapis verzioniranih sastojaka koji su proizveli ishod.

• Ulaz: korisnički zahtjev ili poslovni događaj, uz zaštitu ili uklanjanje osjetljivih polja prema potrebi.
• Kontekst: dokumenti, zapisi, alati ili strukturirani podaci dostupni modelu.
• Konfiguracija: model, verzija prompta ili upute, postavke dohvaćanja i oznake funkcionalnosti korištene za to izvođenje.
• Izlaz: generirani rezultat, uključujući strukturirana polja ondje gdje ih proizvod zahtijeva.
• Ishod: ljudske izmjene, izričite ocjene, dovršavanje naknadnih koraka, eskalacija ili drugi signali povezani s izvornim izvođenjem.

Ovo nije argument za prikupljanje svega. Minimizacija podataka i dalje je zahtjev dizajna. Pohranite samo ono što ima jasnu svrhu, uspostavite pravila zadržavanja i odvojite produkcijski pristup od pristupa za evaluaciju. Pravo pitanje nije jesu li podaci korisni apstraktno; nego je li određeno polje potrebno za poboljšanje proizvoda ili istraživanje neuspjeha.

Verzioniranje je jednako važno. Ako se nakon uvođenja pojavi problem s kvalitetom, tim bi trebao moći utvrditi točnu uputu, konfiguraciju modela i ponašanje dohvaćanja koji su bili uključeni. Bez verzioniranih tragova dijagnostika postaje nagađanje: ljudi uspoređuju anegdote umjesto dokaza.

Dizajnirajte povratne informacije kao tijek proizvoda

Kontrolu palca gore lako je dodati, a lako joj je i pridati preveliku vrijednost. Korisnici rijetko daju povratne informacije osim ako interakcija nije bila iznimno dobra ili frustrirajuća. Bolji su signali često ugrađeni u sam tijek rada.

Razmotrite AI asistenta koji sastavlja odgovor korisniku. Pozadinski sustav može usporediti nacrt s porukom koja je naposljetku poslana, uzimajući u obzir uobičajene promjene oblikovanja. Je li agent zadržao preporučeni sljedeći korak? Je li zamijenio činjeničnu tvrdnju? Je li razgovor ponovno otvoren ubrzo nakon toga? To su nesavršeni signali, ali su više povezani sa stvarnim radom nego općenita ocjena.

Ljudska provjera trebala bi biti promišljena ondje gdje pogreške imaju značajne posljedice. Izradite redove za nesigurne izlaze, kategorije osjetljive na pravila i novouvedene tijekove rada. Recenzenti trebaju dovoljno konteksta za procjenu rezultata, a njihove bi ispravke trebalo zabilježiti u formatu koji može poboljšati upute, dohvaćanje, pravila, skupove za evaluaciju ili buduće podatke za treniranje.

Nemojte automatski svaku ispravku tretirati kao temeljnu istinu. Recenzent možda odgovara na informacije koje sustav nije imao ili može donijeti nedosljednu odluku. Kvalitetni podaci za učenje proizlaze iz jasnih kriterija provjere, kalibriranih recenzenata i periodičnih provjera neslaganja.

Odvojite eksperimentiranje od odgovornosti u produkciji

Brzina izrade prototipa vrijedna je, ali produkcijski AI treba uobičajenu inženjersku disciplinu. Učinite eksperimente ponovljivima. Zadržite reprezentativni skup za evaluaciju odvojenim od primjera korištenih za oblikovanje rješenja. Prije objave testirajte značajne promjene na tom skupu i pregledajte neuspjehe umjesto oslanjanja samo na zbirni rezultat.

Korisni proces objave postavlja jednostavna pitanja:

1. Koji korisnički problem ova promjena treba poboljšati?
2. Koji bi primjeri mogli postati lošiji?
3. Koje mjerljive zaštitne granice moraju ostati unutar prihvatljivih okvira?
4. Kako tim može onemogućiti ili vratiti promjenu?
5. Tko pregledava rezultate nakon objave?

Oznake funkcionalnosti i postupno uvođenje osobito su korisni kada je ponašanje probabilističko. Omogućuju timovima usporedbu ishoda, ograničavanje izloženosti i promjenu smjera bez pretvaranja svake prilagodbe u hitnu objavu. Također čine vlasništvo konkretnim: netko je odgovoran za praćenje funkcionalnosti nakon što dosegne korisnike.

Omogućite udaljenim timovima operativni model

Rad s AI-jem obuhvaća proizvod, inženjerstvo, dizajn, operacije i domensko stručnjake. U distribuiranom timu nejasnoće se brzo umnožavaju. Zajednički zapis odluka može spriječiti ponavljane rasprave: navedite slučaj upotrebe, očekivano ponašanje, izvore podataka, poznata ograničenja, metodu evaluacije, vlasnika i put eskalacije.

Neka primjeri budu dio sučelja između disciplina. Stručnjaci za proizvod i domenu mogu pridonijeti reprezentativnim slučajevima i neprihvatljivim ishodima. Inženjeri te slučajeve mogu pretvoriti u automatizirane provjere. To je produktivnije od traženja od netehničkih partnera da odobre nejasnu tvrdnju da model „dobro radi”.

Vlasništvo bi također trebalo uključivati neuspjehe. Kada funkcionalnost proizvede neprikladan odgovor, odgovor nije samo prilagoditi prompt. Utvrdite je li neuspjeh nastao zbog podataka koji nedostaju, slabog dohvaćanja, nejasnog pravila, neobrađenog stanja tijeka rada, neadekvatne provjere ili nerealnog očekivanja od proizvoda. Rješenje često pripada izvan sloja modela.

Izgradite sustav koji možete neprestano poboljšavati

Trajna prednost AI proizvoda nije pametan prompt skriven u repozitoriju. To je pozadinski sustav koji stvarnu upotrebu pretvara u odgovorne dokaze, omogućuje timovima evaluaciju promjena i čini neuspjehe razumljivima.

Takav je pristup nekoliko dana sporiji od dema, a brži od oporavka od funkcionalnosti koju nitko ne može objasniti ili sigurno poboljšati. Gradite za sljedivost, povratne informacije, evaluaciju i jasno vlasništvo. Tada prompt postaje ono što bi trebao biti: jedna korisna komponenta u sustavu proizvoda osmišljenom za učenje.