Un sistema che estrae dati da un documento ha una risposta corretta: la quota dimensionale sul disegno tecnico è quella che è, e si può verificare. Un motore di raccomandazione musicale non ha questo lusso. Non esiste “il disco giusto” da consigliare, quindi non esiste una risposta di riferimento con cui confrontare l’output e contare gli errori.
Questo cambia il metodo di valutazione, non solo il numero finale.
Il problema che il progetto risolve
La raccomandazione musicale si è sempre retta sul segnale collaborativo: cosa hanno ascoltato utenti simili a te. Quel segnale manca proprio dove servirebbe di più — un album poco ascoltato, una nuova uscita, un utente appena arrivato — e su un catalogo che unisce libreria locale e streaming è spesso la parte più interessante del catalogo quella che resta invisibile.
Il sistema costruito indicizza i contenuti descrittivi del catalogo — metadati, generi, relazioni fra artisti, contenuti editoriali — e recupera per similarità semantica, con la stessa architettura di retrieval descritta per un sistema RAG aziendale, applicata qui non a documenti aziendali ma a un catalogo musicale. Un album può essere raccomandato anche senza storico di ascolti: è esattamente il punto dove il filtro collaborativo non ha nulla da dire.
Perché serve una persona per valutare
Un insieme di prova con le risposte corrette, come si costruisce per un sistema documentale, presuppone che esista una risposta corretta nota in anticipo. Qui non esiste: la qualità di una raccomandazione non è accuratezza. Per questo la valutazione richiede persone reali che giudicano se il suggerimento è pertinente, non solo metriche calcolate a tavolino sullo storico.
Due numeri emergono da questa valutazione, e vanno letti insieme.
Pertinenza: 85% delle raccomandazioni sono state giudicate pertinenti dagli utenti nel campione valutato.
Copertura: 65% di catalogo raggiunto con la nuova logica, rispetto alla logica di raccomandazione precedente.
Perché due numeri, e non uno
Un motore che massimizza solo la pertinenza finisce per raccomandare sempre gli stessi titoli sicuri: il modo più semplice per avere una pertinenza alta è consigliare ciò che piace quasi a tutti. La copertura misura se il sistema sta effettivamente raggiungendo la coda lunga del catalogo, che era il problema di partenza.
Le due grandezze si muovono in direzioni opposte, come accuratezza e copertura in un sistema RAG: ottimizzare l’una senza guardare l’altra produce un risultato che sembra buono su una sola dimensione e vuoto sull’altra. C’è una terza grandezza monitorata a parte — la diversità del catalogo raccomandato — che non ha ancora una cifra pubblicata: una pertinenza alta ottenuta raccomandando sempre gli stessi titoli non sarebbe un progresso, ed è per questo che resta sorvegliata anche senza un numero da mostrare.
Che cosa il sistema non fa
Non inventa titoli. La generazione resta vincolata agli elementi effettivamente presenti nel catalogo e disponibili all’utente: raccomandare un disco inesistente o non riproducibile è peggio che non raccomandare nulla. Ogni suggerimento resta riconducibile al contenuto che lo ha prodotto, quindi spiegabile invece che opaco.
In chiusura
Quando non esiste una risposta corretta da confrontare, la tentazione è smettere di misurare e fidarsi dell’impressione. La risposta più solida è l’opposto: più persone nella valutazione, più grandezze lette insieme, non una sola cifra che nasconde il compromesso.
Il caso completo descrive architettura e implementazione. Se state valutando un sistema di raccomandazione o di ricerca su un catalogo ampio ed eterogeneo, siamo disponibili a un confronto sul metodo di valutazione più adatto al vostro caso.
