Ciao Damiano, On Wed, 22 Feb 2023 09:39:06 +0100 Damiano Verzulli wrote:
> Mi aggancio alla discussione in corso su altri thread sulla natura
> statistica/probabilistica di ChatGPT e sulle relative implicazioni
> (non puo' "sapere"; non produce "informazione", quindi non può
> errare; non ha "conoscenza", etc.).
Confermo:
- non produce e non elabora informazione, solo dati.
- non può errare esattamente quanto non può "fare giusto" [1]
> Da tecnico, rilevo che la "qualita'" delle risposte sia fortemente
> determinata dal dominio della domanda. Se chiedi la biografia di
> Pinco Pallino da Pennapiedimonte, è un conto. Se chiedi cos'é un
> "inner join" è un altro conto. Trovo che la cosa sia molto simile al
> mio carattere personale: se alle superiori mi interrogavano su
> Manzoni... facevo una fatica bestiale; se mi chiedevano di disegnare
> una funzione, era un gioco da ragazzi.
Anzitutto Damiano, credo sia doveroso farti notare che paragonarti ad
una macchina (per altro per difenderla) potrebbe evidenziare una
profonda alienazione in corso.
Non sei una macchina.
ChatGPT non ti assomiglia e tu non assomigli a ChatGPT.
Non merita la tua empatia o la tua difesa.
Mi rendo conto che il passaggio
- dato -> informazione
- informazione -> dato
è talmente naturale ed inconsapevole per la nostra mente da confondere
le due entità. Eppure puoi certamente distinguere la rappresentazione
delle parole che stai leggendo dall'informazione che veicolano.
Poi da tecnico dovresti rilevare che in realtà la qualità attribuita
alla risposta dipende anzitutto dalla preparazione di chi la interpreta.
Prediamo il tuo aneddoto come caso di studio:
> =================
>
> Domanda: "I have a database containing two tables "elementi" and
> "proprietari" in elementi i have rows that refers to multiple
> proprietari and vice versa, what can be the best way to use reference
> keys in this scenarios?"
>
> Risposta: "In a scenario where you have a many-to-many relationship
> between the "elementi" and "proprietari" tables, the best way to use
> reference keys is to create a third table that acts as a bridge
> between the two tables. This is commonly referred to as a junction
> table or an associative table.
> The junction table should contain foreign keys that reference the
> primary keys of the "elementi" and "proprietari" tables. This table
> can also contain additional columns that relate to the relationship
> between the two tables, such as the date the relationship was
> established or the nature of the relationship.
> For example, you could create a junction table called
> "elementi_proprietari" with columns "id", "elemento_id", and
> "proprietario_id". The "id" column would be the primary key of the
> junction table, while "elemento_id" and "proprietario_id" would be
> foreign keys that reference the "id" column of the "elementi" and
> "proprietari" tables, respectively.
> In this way, each row in the junction table represents a relationship
> between a single "elemento" and a single "proprietario". To represent
> relationships between multiple "proprietari" and a single "elemento",
> you would simply add additional rows to the junction table with the
> same "elemento_id" but different "proprietario_id" values.
> By using a junction table, you can easily query and update the
> relationships between "elementi" and "proprietari" using standard SQL
> commands"
>
> =================
>
> Ai non-tecnici che potrebbero non percepire la qualita' della
> risposta, segnalo che non solo è _PERFETTA_, ma la trovo anche
> qualitativamente migliore di molte altre spiegazioni che circolano in
> aria all'inizio dei corsi universitari sui database relazionali.
La risposta non è affatto perfetta.
L'esempio che propone è proprio sbagliato, tanto da evidenziare
l'assoluta assenza di comprensione dell'algebra relazionale.
Se metti come chiave primaria nella junction table un id
(assumo, numerico autoincrementale) e non poni alcun vincolo di
univocità sulle altre due chiavi, permetti l'inserimento di una stessa
relazione più volte, costringendo l'applicativo a gestire i duplicati.
Visto che non si sta parlando di un DBMS in particolare e non possiamo
assumere ridicoli limiti implementativi, la risposta corretta sarebbe
stata di impostare come chiave primaria la coppia proprietario_id,
elemento_id.
Una chiave diversa può aver senso in presenza di attributi di relazione
che possano rendere non univoca la coppia (come una data di scadenza, o
altri attributi specifici della relazione in questione).
Ma anche in tale caso, un db relazionale che si curi della consistenza
dei dati, dovrebbe imporre vincoli specifici che esprimano tale
consistenza.
E anche in presenza di limiti del DBMS in questione che impongano una
chiave primaria costituita da una sola colonna (limite che spero ormai
sia una reminiscenza di tempi oscuri) dovresti specificare la necessità
di un vincolo di univocità della coppia di riferimenti.
Al tuo amico, la risposta può sembrare perfetta, ma non lo è.
Se un collega mi proponesse una simile soluzione, gli farei un lungo
pippotto sul fatto che la junction table proposta non rappresenta
una relazione (in termini matematici) né una proprietà del modello
e ci esporrebbe a diversi bug applicativi.
> Ora io non voglio mettere in dubbio il fatto che ChatGPT risponda
> seguendo logiche statistiche o probabilistiche. Voglio solo dire che
> per _MOLTI_ ambiti (quelli strettamente piu' "tecnici") si fa
> veramente fatica a dire che il suo "output" segua esclusivamente tale
> logica o --per tornare ai thread in corso-- che ChatGPT non "sappia"
> come implementare una relazione N a M nei contesti dei database
> relazionali.
Eppure, come dimostra l'output stesso del tuo esempio, non lo sa.
> E comunque --qualora si volesse insistere su questo
> punto [come mi pare alcuni vogliano fare]-- anche se cosi' fosse...
> tendenzialmente al mio amico non gliene frega un granché [perché la
> risposta alla sua domanda _TECNICA_, è _PERFETTA_].
Non lo è.
E se il tuo amico seguirà il consiglio di ChatGPT si ritroverà prima o
poi con un database inconsistente.
I bug in cui può incappare sono innumerevoli.
Banalmente, se erroneamente una relazione venisse inserita due volte
nella junction table e successivamente solo una delle righe che la
rappresentano venisse aggiornata a valle di un cambiamento di
relazione, il database esprimerebbe due relazioni dove ce n'è una sola.
Nella migliore delle ipotesi, ciò comporterebbe un errore applicativo
da cui l'utente non potrebbe uscire.
Nella peggiore, la relazione erronea avrebbe conseguenze dispositive a
valle, come l'esecuzione di ordini short in finanza etc...
Se al tuo amico "non gliene frega un granché" della consistenza del
database di cui è responsabile, fa bene ad affidarsi a ChatGPT.
Ma forse il suo datore di lavoro dovrebbe esserne informato.
> Aggiungo --infine-- che pur avendo conseguito una laurea in Scienze
> dell'Informazione nel lontano 1995, ho scoperto cosa fosse un
> Gerber-File soltanto nel ~2016. Ed è stato soltanto grazie al mio
> amico (quello del carro), che ho scoperto l'esistenza della
> "Saldatura a TIG" un paio di anni fa e che, a dispetto della
> pressione, a temperatura ambiente non è possibile liquefare il metano
> (il propano si, invece). Insomma: a 52 anni riesco ancora facilmente
> ad "apprendere" cose molto tecniche/specifiche.... Allo stesso tempo
> (continuo) a far fatica a metabolizzare la biografia del Manzoni o
> gli scritti di Dante.
Un proverbio che mia mamma mi ripeteva spesso da giovane era:
"La vecchia aveva cent'anni, e aveva ancora qualcosa da imparare"
ammetto che solo diventando genitore ho iniziato a comprenderne la
profondità.
Purtuttavia il tuo parallelo non sembra aggiungere molto.
Sei finito, nello spazio, nel tempo e nell'esperienza.
E questa è una caratteristica che ti accomuna a ChatGPT e ad un ameba.
Ma contrariamente a ChatGPT e all'ameba, tu sei ANCHE intelligente.
Puoi essere convinto che di non esserlo o di esserlo quanto ChatGPT.
Ma rimarrai un essere umano, dotato di intelligenza e autonomia.
> Mi sorge il dubbio, che anche il mio cervello funzioni --da qualche
> parte-- con logiche statistico/probabilistiche.
Stai confondendo il modello con la realtà modellata.
Tu puoi certamente descrivere alcuni comportamenti del tuo cervello
"con logiche statistico/probabilistiche". Lui continuerà ad essere un
cervello che fa un po' quel che gli pare, seguendo istinti primordiali,
riflessioni, esperienze sensoriali o mistiche etc...
Invece ChatGPT è un software programmato statisticamente.
Tu puoi comportarti come ChatGPT, come un gatto o come una ameba.
Rimani un essere umano, dotato di una mente che elabora informazioni.
ChatGPT rimane un software programmato statisticamente.
Un software che elabora meccanicamente dati che non può comprendere.
> Un'ultima nota: ho letto piu' volte, in lista, di organizzare forme
> di "resistenza" a questo fenomeno. [...] nutro fortissimi dubbi che
> da questa lista, per questo ambito specifico, possano uscire cose
> piu' concrete degli Archives della lista stessa.
Beh come da qualsiasi mailing list, suppongo.
Ma le persone che partecipano a questa comunità possono fare molto
per diffondere consapevolezza sulla natura di questi agenti cibernetici.
Possono persino influenzare la loro regolamentazione futura.
Ad esempio, potrebbero spiegare ai politici l'urgenza di vientarne
l'utilizzo in ambito medico, educativo o legale.
O l'importanza di imporre pene severe e responsabilità precise in capo
a chi li esegue per i danni prodotti dall'interpretazione del loro
output, "giusto" o "sbagliato" che appaia ex-post.
Se per esempio un paziente fraintendesse l'output di un LLM medico [2]
e subisse un danno dalla terapia adottata, ne dovrebbe rispondere
civilmente e penalmente chi ha prodotto ed eseguito quel LLM.
> Aldila' del fatto che trovo il termine "resistenza"
> non-brillantissimo
Puoi elaborare? In che senso?
Giacomo
[1]: persino meno di uno studente che abbia studiato a memoria il libro
del professore che lo interroga e lo sappia ripetere a menadito pur
non avendo compreso una parola: lo studente ha la possibilità
teorica, in futuro, di rielaborare le nozioni memorizzate e
comprenderle, ChatGPT no.
[2]: Non è un'ipotesi così astratta, Microsoft conta molto sul NON dover
rispondere dei danni: https://github.com/microsoft/BioGPT
pgpGHxczm9M6t.pgp
Description: OpenPGP digital signature
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
