Ehm... no Antonio: anzitutto non è così semplice. Ogni token può rappresentare anche più di una parola, non solo dei frammenti di parola. Poi ogni ad ogni token il dizionario associa non un singolo numero, ma un vettore sparso i cui componenti non zero rappresentano (semplificando enormemente) statistiche relative alle occorrenze di altri token in diversi contesti.
Ma soprattutto, la mappatura fra le parole e i vettori è bidirezionale. Sempre semplificando enormemente alla sequenza di 4 parole A B C D corrisponde una matrice di 4 righe tipo [0 123 0 14 ...], [41 0 0 0 ...], [0 0 0 18 ...], [0 0 99 0 ...] Questa matrice viene ridotta ad un nuovo vettore [0 2 7 0 ...] che corrisponde ad un'altra parola, che verrà accodata all'output ed utilizzata anche come input. In qualunque caso, i vettori associati a ciascun token sono rappresentazioni dei percorsi presenti nei testi sorgente: è sempre possibile (pur essendo più o meno probabile a seconda di molte variabili runtime) percorrere quei vettori riproducendo il testo utilizzato in input (magari con qualche errore). Naturalmente è tutto MOLTO più compresso di così. Ma ciò non toglie che, poiché esiste sempre una mappatura fra vettore e parola e l'output è calcolato sulla base della frequenza con cui si ogni token si trovava in relazione con gli altri token nei testi sorgente, i testi sono presenti nel LLM. Si tratta di un'algoritmo di compressione lossy, ma pur tuttavia talvolta la "decompressione" di determinati frammenti riproduce verbatim frammenti più o meno vasti del testo originale (e ancor più frequentemente, piccole variazioni sintattiche dello stesso, ad esempio cambiando gli identificatori di un sorgente Python, senza cambiarne in alcun modo la semantica) Ma non fidarti delle mie parole, guarda con i tuoi occhi: https://peertube.opencloud.lu/w/eW497u3UYXmQwcQu9LYEDR Giacomo Il giorno Mon, 2 Oct 2023 12:58:25 +0200 Antonio <anto...@piumarossa.it> ha scritto: > > > Sto semplicemente dicendo che quei testi sono in gran parte > > > presenti nel LLM seppure codificati con perdita di informazione. > ... > > OK, su cosa succede tecnicamente, ovvero sul tipo di elaborazione e > > immagazzinamento dei testi _elaborari_, credo sia tutto > > sufficientemente chiaro. > > No, aspettate, forse mi sono perso qualche puntata precedente. > I testi non sono per nulla presenti nell'LLM, neanche in forma > "compressa". Il "model" non è altro che un enorme contenitore di > "numeri". Nel caso di GPT3-175B, 175 miliardi di numeri, fine. Questi > numeri si chiamano "pesi" ma sempre numeri sono. Provo con qualche > esempio. > > Prompt: Quante lune ha Giove? > La prima operazione che fa un LLM è la tokenizzazione, nel caso > dell'esempio: Token array: Array > ( > [Qu] => 4507 > [ante] => 12427 > [Ġl] => 300 > [une] => 1726 > [Ġha] => 387 > [ĠGi] => 8118 > [ove] => 659 > [?] => 30 > ) > > Il dizionario usato da OpenAI è pubblico e contiene 50257 token, > quindi i numeri qui sopra sono quelli che realmente entrano nel > processo di "inferenza" di ChatGPT. > > Quello che ChatGPT fa non è altro che aggiungere UN numero a quella > sequenza (ovviamente sulla base di migliaia di calcoli che non sto > qui a dettagliare). Il numero trovato (su una versione mininale di > ChatGPT) è 33704. ChatGPT prende questo numero e lo accoda a 30, e > così via ... Alla fine, la sequenza completa di ChatGPT sarà: 33704, > 659, 387, 334, 2108, 498, 434, 68, 9225, 300, 1726, 1013, 7780, 378, > che "detokenizzato", diventa: "Giove ha ufficialmente 79 lune > confermate". > > Ciao, > Antonio > > _______________________________________________ > nexa mailing list > nexa@server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
