Vai jūsu AI produkts tiešām darbojas? Kā izstrādāt pareizo metrisko sistēmu

Manā pirmajā kā mašīnmācīšanās (ML) produktu vadītāja amatā, vienkāršs jautājums, kas iedvesmoja kaislīgas debates par funkcijām un vadītājiem: kā mēs zinām, vai šis produkts patiesībā darbojas? Attiecīgais produkts, kuru es pārvaldīju, rūpējās gan par iekšējiem, gan ārējiem klientiem. Modelis ļāva iekšējām komandām noteikt galvenās problēmas, ar kurām saskaras mūsu klienti, lai viņi varētu prioritizēt pareizo pieredzes kopumu klientu problēmu novēršanai. Ar tik sarežģītu iekšējo un ārējo klientu savstarpējo atkarību tīmekli, izvēloties pareizo metriku, lai uztvertu produkta ietekmi, bija kritiska, lai virzītu to uz panākumiem.

Neizslogot, vai jūsu produkts darbojas labi, ir kā lidmašīnas nolaišana bez gaisa satiksmes vadības norādījumiem. Nav absolūti nekāda tā, ka jūs varētu pieņemt apzinātus lēmumus savam klientam, nezinot, kas notiek pareizi vai nepareizi. Turklāt, ja jūs aktīvi nedefinējat metriku, jūsu komanda identificēs savu rezerves metriku. Dangers, ka jums ir vairākas “precizitātes” vai “kvalitātes” metrikas garšas, ir tas, ka ikviens izstrādās savu versiju, kas noved pie scenārija, kurā jūs, iespējams, nestrādājat pie viena un tā paša iznākuma.

Piemēram, kad es pārskatīju savu ikgadējo mērķi un pamatā esošo metriku ar mūsu inženierzinātņu komandu, tūlītēja atgriezeniskā saite bija: “Wager šī ir biznesa metrika, mēs jau izsekojam precizitāti un atceramies.”

Vispirms identificējiet, ko vēlaties uzzināt par savu AI produktu

Kad esat nonācis pie uzdevuma noteikt sava produkta metriku – kur sākt? Pēc manas pieredzes, ML produkta darbības ar vairākiem klientiem sarežģītība nozīmē arī modeļa metrikas noteikšanu. Ko es izmantoju, lai izmērītu, vai modelis darbojas labi? Iekšējo komandu iznākuma noteikšana, lai prioritizētu palaišanu, pamatojoties uz mūsu modeļiem, nebūtu pietiekami ātri; Izmērot, vai klients pieņēma mūsu modeļa ieteiktajus risinājumus, varētu riskēt, ka mēs izdarām secinājumus no ļoti plašas adopcijas metrikas (kas būtu, ja klients nepieņemtu risinājumu, jo viņi tikai vēlējās sasniegt atbalsta aģentu?).

Ātri virzoties uz lielo valodu modeļu laikmetu (LLM)-kur mums nav tikai viena izvade no ML modeļa, mums ir arī teksta atbildes, attēli un mūzika kā izejas. Tā produkta izmēri, kuriem tagad nepieciešama metrika, tagad strauji palielinās – formāti, klienti, ideas… saraksts turpinās.

Visos manos produktos, kad es mēģinu nākt klajā ar metriku, mans pirmais solis ir destilēt to, ko es vēlos uzzināt par tā ietekmi uz klientiem, par dažiem galvenajiem jautājumiem. Pareiza jautājumu kopuma identificēšana ļauj vieglāk identificēt pareizo metrikas kopumu. Šeit ir daži piemēri:

1. Vai klients saņēma izvadi? → pārklājuma metrika
2. Cik ilgs laiks bija vajadzīgs, lai produkts nodrošinātu izvadi? → Latentuma metrika
3. Vai lietotājam patika izvade? → Metrika klientu atsauksmēm, klientu pieņemšana un saglabāšana

Kad esat identificējis galvenos jautājumus, nākamais solis ir identificēt apakšsadaļu komplektu “ievades” un “izvades” signāliem. Izejas metrika ir atpalikušas rādītāji, kur jūs varat izmērīt jau notikušo notikumu. Ievades metriku un vadošos rādītājus var izmantot, lai identificētu tendences vai prognozētu rezultātus. Zemāk skatiet veidus, kā iepriekš minētajiem jautājumiem pievienot pareizos apakšjautājumus par atpalikšanu un vadošajiem rādītājiem. Ne visiem jautājumiem ir jābūt vadošajiem/atpalikušajiem rādītājiem.

1. Vai klients saņēma izvadi? → Pārklājums
2. Cik ilgs laiks bija vajadzīgs, lai produkts nodrošinātu izvadi? → Latentums
3. Vai lietotājam patika izvade? → Klientu atsauksmes, klientu adopcija un saglabāšana
   1. Vai lietotājs norādīja, ka izvade ir pareiza/nepareiza? (izvade)
   2. Vai izeja bija laba/taisnīga? (ievade)

Trešais un pēdējais solis ir identificēt metrikas metodi. Lielākā daļa metrikas tiek apkopoti uz mēroga ar jaunu instrumentu palīdzību, izmantojot datu inženieriju. Tomēr dažos gadījumos (piemēram, iepriekš 3. jautājums), īpaši attiecībā uz ML balstītiem produktiem, jums ir iespēja veikt manuālus vai automatizētus novērtējumus, kas novērtē modeļa rezultātus. Lai gan vienmēr vislabāk ir izstrādāt automatizētus novērtējumus, sākot ar manuālu novērtējumu par “bija izejas labums/godīgs” un izveidojot rubriku labas, godīgas un labas definīcijām, tas arī palīdzēs jums izveidot pamatus stingram un pārbaudītam automatizētam novērtēšanas procesam.

Lietošanas gadījumu piemēri: AI meklēšana, apraksti

Iepriekš minēto ietvaru var izmantot jebkuram ML balstītam produktam, lai identificētu jūsu produkta primāro metriku sarakstu. Apmeklēsim meklēšanu kā piemēru.

Kā būtu ar produktu, lai ģenerētu saraksta aprakstus (neatkarīgi no tā, vai tas ir izvēlnes vienums Doordash vai produktu sarakstā vietnē Amazon)?

Iepriekš aprakstītā pieeja ir paplašināma vairākiem uz ML balstītiem produktiem. Es ceru, ka šī sistēma palīdzēs jums noteikt pareizo metrikas kopumu jūsu ML modelim.

Sharanya Rao ir grupas produktu menedžere vietnē IntutsApvidū