Esplora il percorso di Sergey Brin dagli algoritmi di ricerca iniziali di Google all'IA generativa di oggi, con idee chiave su scalabilità, impatto prodotto e domande aperte.
La storia di Sergey Brin è importante non per il gossip o la cronaca aziendale, ma perché traccia una linea diretta dai problemi classici della ricerca (come trovare la risposta migliore sul web aperto) alle domande che i team affrontano oggi con la IA moderna (come generare output utili senza perdere accuratezza, velocità o fiducia). Il suo lavoro sta all’incrocio tra algoritmi, dati e sistemi—proprio dove ricerca e IA generativa si incontrano.
Questo è un viaggio centrato sui concetti e sulle tappe: come idee come PageRank hanno cambiato la rilevanza, come il machine learning ha silenziosamente sostituito regole fatte a mano e perché il deep learning ha migliorato la comprensione del linguaggio. Non è pettegolezzo, drama interno o una timeline di titoli. Lo scopo è spiegare perché questi cambiamenti sono stati importanti e come hanno plasmato i prodotti che le persone utilizzano.
L’IA generativa diventa “su scala” quando deve operare come la ricerca: milioni di utenti, bassa latenza, costi prevedibili e qualità consistente. Significa più di una demo brillante del modello. Include:
Alla fine dovresti essere in grado di collegare l’era della ricerca ai prodotti di tipo chat odierni, capire perché retrieval e generazione si stanno fondendo e prendere in prestito principi pratici per i team di prodotto—misurazione, rilevanza, progettazione di sistema e deployment responsabile—che si trasferiscono tra entrambi i mondi.
Il percorso di Sergey Brin nella ricerca è iniziato in ambito accademico, dove le domande fondamentali non riguardavano “costruire un sito web”, ma come gestire la sovrabbondanza di informazioni. Prima che Google diventasse un’azienda, Brin era immerso nella ricerca informatica che spaziava dai sistemi di database, al data mining, al recupero informazioni—discipline che si chiedono come memorizzare enormi quantità di dati e restituire risposte utili rapidamente.
Brin ha studiato matematica e informatica come undergraduate e poi ha proseguito in graduate a Stanford, un centro per la ricerca sulla scala emergente del web. I ricercatori si confrontavano già con problemi che suonano familiari oggi: dati disordinati, qualità incerta e il divario tra quello che le persone scrivono e quello che intendono davvero.
La ricerca alla fine degli anni ’90 era guidata soprattutto dal matching di parole chiave e da segnali di ranking basilari. Funzionava quando il web era più piccolo, ma peggiorava con la moltiplicazione delle pagine—e con i creatori che imparavano a manipolare il sistema. Le sfide comuni includevano:
L’idea motivante era semplice: se il web è una gigantesca biblioteca, servono più che corrispondenze testuali per ordinare i risultati—servono segnali che riflettano credibilità e importanza. Organizzare l’informazione web richiedeva metodi in grado di inferire utilità dalla struttura stessa del web, non solo dalle parole in una pagina.
Quelle priorità di ricerca iniziali—misurare la qualità, resistere alla manipolazione e operare a scala estrema—hanno posto le fondamenta per i successivi spostamenti nella ricerca e nell’AI, inclusi ranking basati su machine learning e, infine, approcci generativi.
La ricerca ha un obiettivo che suona semplice: quando scrivi una domanda, le pagine più utili dovrebbero emergere in cima. Negli anni ’90 questo era più difficile di quanto sembri. Il web esplodeva e molti motori si affidavano pesantemente a ciò che una pagina diceva di sé—il testo, le keyword e i meta tag. Questo rendeva i risultati facili da manipolare e spesso frustranti da usare.
L’intuizione chiave di Sergey Brin e Larry Page fu trattare la struttura dei link del web come un segnale. Se una pagina linka un’altra, sta dando una specie di “voto”. Non tutti i voti sono uguali: un link da una pagina stimata dovrebbe valere più di uno da una pagina oscura.
Concettualmente, PageRank misura l’importanza chiedendo: quali pagine sono riferite da altre pagine importanti? Questa domanda circolare si traduce in un ranking matematico calcolato su scala web. Il risultato non era “la soluzione” alla rilevanza—ma fu un ingrediente potente.
È facile attribuire troppo merito a PageRank come unico segreto del successo iniziale di Google. In pratica, il ranking è una ricetta: gli algoritmi combinano molti segnali (matching testuale, freschezza, località, velocità e altro) per predire ciò che una persona desidera davvero.
E gli incentivi sono complicati. Appena le classifiche contano, lo spam segue—link farm, keyword stuffing e altri trucchi progettati per sembrare rilevanti senza esserlo. Gli algoritmi di ricerca sono diventati un gioco avversariale in corso: migliorare la rilevanza, rilevare manipolazioni e adattare il sistema.
Il web cambia, il linguaggio cambia e le aspettative degli utenti cambiano. Ogni miglioramento genera nuovi edge case. PageRank non ha finito la ricerca—ha spostato il campo dal semplice matching di parole chiave verso il moderno recupero informazioni, dove la rilevanza viene continuamente misurata, testata e raffinata.
Un’idea di ranking brillante non basta quando il tuo “database” è l’intero web. Ciò che rese la ricerca di Google diversa non fu solo la rilevanza—fu la capacità di fornire quella rilevanza in modo rapido e coerente per milioni di persone contemporaneamente.
La ricerca a scala internet inizia con il crawling: scoprire pagine, rivisitarle e far fronte a un web che non smette mai di cambiare. Poi viene l’indicizzazione: trasformare contenuti variegati e disordinati in strutture interrogabili in millisecondi.
A piccola scala, puoi trattare storage e calcolo come un problema per una singola macchina. A grande scala, ogni scelta diventa un compromesso di sistema:
Gli utenti non percepiscono la qualità della ricerca come un punteggio di ranking—la vivono come una pagina di risultati che si carica subito, ogni volta. Se i sistemi falliscono spesso, i risultati vanno in timeout o la freschezza è lenta, anche ottimi modelli di rilevanza sembrano scadenti in pratica.
Per questo progettare uptime, degradazione graduale e prestazioni coerenti è inseparabile dal ranking. Un risultato leggermente meno “perfetto” fornito in modo affidabile in 200ms può battere uno migliore che arriva tardi o in modo intermittente.
A scala non puoi “semplicemente rilasciare” un aggiornamento. La ricerca dipende da pipeline che raccolgono segnali (click, link, pattern linguistici), eseguono valutazioni e rilasciano cambiamenti gradualmente. L’obiettivo è rilevare regressioni presto—prima che colpiscano tutti.
Un catalogo di biblioteca presume che i libri siano stabili, curati e lenti a cambiare. Il web è una biblioteca in cui i libri si riscrivono, gli scaffali si spostano e nuove stanze appaiono costantemente. La ricerca a scala internet è la macchina che mantiene un catalogo utilizzabile per quel bersaglio in movimento—veloce, affidabile e continuamente aggiornato.
Il ranking iniziale si basava molto su regole: se una pagina ha le parole giuste nel titolo, se è linkata spesso, se si carica velocemente, ecc. Quei segnali contavano—ma decidere quanto ciascuno dovesse pesare era spesso un mestiere manuale. Gli ingegneri potevano regolare pesi, eseguire esperimenti e iterare. Funzionava, ma raggiungeva un tetto man mano che il web (e le aspettative degli utenti) esplodevano.
“Learning to rank” significa lasciare che un sistema impari cosa sono buoni risultati studiando molti esempi.
Invece di scrivere una lunga checklist di regole di ranking, alimenti il modello con molte ricerche passate e i loro esiti—come quali risultati gli utenti tendevano a scegliere, quali abbandonavano rapidamente e quali pagine i revisori umani giudicavano utili. Nel tempo, il modello migliora nel predire quali risultati dovrebbero salire.
Un’analogia semplice: invece di un insegnante che scrive un piano di posti a sedere dettagliato per ogni lezione, l’insegnante osserva quali disposizioni favoriscono discussioni migliori e si adatta automaticamente.
Questo spostamento non ha cancellato segnali classici come link o qualità della pagina—ha cambiato il modo in cui vengono combinati. La parte “silenziosa” è che, per l’utente, la casella di ricerca poteva restare la stessa. Internamente, il baricentro si è mosso dalle formule artigianali ai sistemi che imparano dai dati.
Quando i modelli imparano dai dati, la misurazione diventa la guida.
I team si affidano a metriche di rilevanza (i risultati soddisfano la query?), test A/B online (una modifica migliora il comportamento reale degli utenti?) e feedback umano (i risultati sono accurati, sicuri e utili?). La chiave è trattare la valutazione come continua—perché ciò che le persone cercano e ciò che è “buono” continua a cambiare.
Nota: i dettagli dei modelli e dei segnali interni variano nel tempo e non sono pubblici; il punto importante è il cambiamento di mentalità verso sistemi che apprendono supportati da test rigorosi.
Il deep learning è una famiglia di metodi di machine learning costruiti con reti neurali a più livelli. Invece di codificare a mano regole del tipo (“se la query contiene X, aumenta Y”), questi modelli apprendono pattern direttamente da grandi quantità di dati. Questo cambiamento è stato importante per la ricerca perché il linguaggio è confuso: le persone sbagliano a scrivere, implicano contesti e usano la stessa parola con significati diversi.
I segnali tradizionali di ranking—link, anchor, freschezza—sono potenti, ma non capiscono cosa la query intendeva ottenere. I modelli deep learning sono bravi a imparare rappresentazioni: trasformare parole, frasi e persino immagini in vettori densi che catturano significato e similarità.
In pratica, ciò ha permesso:
Il deep learning non è gratuito. Addestrare e servire modelli neurali può essere costoso, richiedere hardware specializzato e ingegneria attenta. Serve anche dati—etichette pulite, segnali di click e set di valutazione—per evitare che il modello impari scorciatoie errate.
L’interpretabilità è un’altra sfida. Quando un modello cambia il ranking, è più difficile spiegare in una frase semplice perché ha preferito il risultato A rispetto al B, il che complica il debugging e la fiducia.
Il cambiamento più grande è stato organizzativo, non solo tecnico: i modelli neurali hanno smesso di essere esperimenti laterali e sono diventati parte di ciò che gli utenti percepiscono come “qualità della ricerca”. La rilevanza dipendeva sempre più da modelli appresi—misurati, iterati e rilasciati—invece che dalla sola messa a punto manuale dei segnali.
La AI classica per la ricerca riguarda soprattutto ordinare e predire. Data una query e un insieme di pagine, il sistema predice quali risultati sono più rilevanti. Anche quando il machine learning ha sostituito regole fatte a mano, l’obiettivo è rimasto simile: assegnare punteggi come “buona corrispondenza”, “spam” o “alta qualità”, poi ordinare.
L’IA generativa cambia l’output. Invece di selezionare documenti esistenti, il modello può produrre testo, codice, riassunti o immagini. Ciò permette al prodotto di rispondere in una singola risposta, redigere un’email o scrivere un frammento di codice—utile, ma fondamentalmente diverso dal restituire link.
I transformer hanno reso pratico addestrare modelli che prestano attenzione alle relazioni su frasi e documenti interi, non solo alle parole vicine. Con abbastanza dati di addestramento, questi modelli imparano pattern ampi del linguaggio e comportamenti simili al ragionamento: parafrasare, tradurre, seguire istruzioni e combinare idee su argomenti diversi.
Per i grandi modelli, più dati e calcolo spesso portano a prestazioni migliori: meno errori evidenti, scrittura più solida e migliore esecuzione delle istruzioni. Ma i ritorni non sono infiniti. I costi crescono rapidamente, la qualità dei dati diventa un collo di bottiglia e alcuni fallimenti non scompaiono semplicemente rendendo il modello più grande.
I sistemi generativi possono “allucinare” fatti, riflettere bias nei dati di addestramento o essere indotti a produrre contenuti dannosi. Faticano anche con la coerenza: due prompt simili possono dare risposte diverse. Rispetto alla ricerca classica, la sfida si sposta da “Abbiamo classificato la fonte migliore?” a “Possiamo garantire che la risposta generata sia accurata, ancorata e sicura?”
L’IA generativa sembra magica in una demo, ma gestirla per milioni (o miliardi) di richieste è tanto un problema di matematica e operazioni quanto di ricerca. Qui le lezioni dell’era della ricerca—efficienza, affidabilità e misurazione spietata—restano valide.
Addestrare grandi modelli è essenzialmente una catena di montaggio per moltiplicazioni di matrici. “Su scala” di solito significa flotte di GPU o TPU interconnesse in training distribuito così migliaia di chip agiscano come un unico sistema.
Questo introduce vincoli pratici:
L’erogazione è diversa dall’addestramento: agli utenti interessa tempo di risposta e coerenza, non l’accuratezza massima su un benchmark. I team bilanciano:
Poiché il comportamento del modello è probabilistico, il monitoraggio non è solo “il server è su?”. Serve tracciare drift di qualità, nuovi modi di fallire e sottili regressioni dopo aggiornamenti di modello o prompt. Questo spesso include cicli di revisione umana oltre a test automatizzati.
Per contenere i costi, i team usano compressione, distillazione (insegnare a un modello più piccolo a imitare uno più grande) e instradamento (mandare query semplici a modelli più economici e scalare solo quando serve). Questi sono gli strumenti poco glamour che rendono l’IA generativa praticabile nei prodotti reali.
Ricerca e chat spesso sembrano concorrenti, ma è più utile considerarli interfacce diverse ottimizzate per obiettivi utente distinti.
La ricerca classica è ottimizzata per la navigazione veloce e verificabile: “Trova la migliore fonte per X” o “Portami alla pagina giusta”. Gli utenti si aspettano più opzioni, possono scansionare titoli rapidamente e giudicare la credibilità con indizi familiari (editore, data, snippet).
La chat è ottimizzata per sintesi ed esplorazione: “Aiutami a capire”, “Confronta”, “Redigi” o “Cosa dovrei fare dopo?”. Il valore non sta solo nel trovare una pagina—sta nel trasformare informazioni sparse in una risposta coerente, fare domande chiarificatrici e mantenere il contesto nelle turnazioni.
La maggior parte dei prodotti pratici ora mescola entrambi. Un approccio comune è la retrieval-augmented generation (RAG): il sistema cerca prima in un indice attendibile (pagine web, documenti, knowledge base) e poi genera una risposta fondata su ciò che ha trovato.
Quell’ancoraggio è importante perché unisce i punti di forza della ricerca (freschezza, copertura, tracciabilità) e quelli della chat (riassunto, ragionamento, flusso conversazionale).
Quando è coinvolta la generazione, l’interfaccia non può fermarsi a “ecco la risposta”. I design efficaci aggiungono:
Gli utenti notano presto quando un assistente si contraddice, cambia regole a metà strada o non riesce a spiegare da dove provengono le informazioni. Un comportamento coerente, un sourcing chiaro e controlli prevedibili rendono l’esperienza search+chat affidabile—soprattutto quando la risposta influisce su decisioni reali.
L’IA responsabile è più facile da capire quando la si inquadra come obiettivi operativi, non slogan. Per i sistemi generativi significa tipicamente: sicurezza (non produrre istruzioni dannose o molestie), privacy (non rivelare dati sensibili o memorizzare informazioni personali) e equità (non trattare gruppi in modo sistematico che causi danno).
La ricerca classica aveva una forma di valutazione più definita: data una query, ordina i documenti e misura quanto spesso gli utenti trovano ciò di cui hanno bisogno. Anche se la rilevanza era soggettiva, l’output era limitato—link a fonti esistenti.
L’IA generativa può produrre un numero illimitato di risposte plausibili, con modi di fallire sottili:
Questo rende la valutazione meno una singola metrica e più una raccolta di suite di test: controlli di factualità, probe di tossicità e bias, comportamento di rifiuto e aspettative specifiche per dominio (salute, finanza, legale).
Poiché gli edge case sono infiniti, i team spesso usano input umani in più fasi:
Il passaggio chiave dalla ricerca classica è che la sicurezza non è solo “filtrare pagine cattive”. È progettare il comportamento del modello quando gli viene chiesto di inventare, riassumere o consigliare—e dimostrare, con evidenze, che quei comportamenti reggono su scala.
La storia iniziale di Sergey Brin ricorda che i prodotti AI rivoluzionari raramente partono da demo appariscenti—nascono da un lavoro chiaro da svolgere e dall’abitudine a misurare la realtà. Molte di quelle abitudini restano validi quando costruisci con l’IA generativa.
La ricerca ha avuto successo perché i team hanno trattato la qualità come qualcosa che si può osservare, non solo discutere. Hanno eseguito esperimenti infiniti, accettato che piccoli miglioramenti si compongono e tenuto l’intento dell’utente al centro.
Un modello mentale utile: se non riesci a spiegare cosa significa “meglio” per un utente, non puoi migliorarlo in modo affidabile. Questo vale tanto per il ranking delle pagine quanto per il ranking delle risposte candidate di un modello.
La qualità della ricerca classica spesso si riduce a rilevanza e freschezza. L’IA generativa aggiunge nuove dimensioni: factualità, tono, completezza, sicurezza, comportamento di citazione e persino “utilità” nel contesto specifico. Due risposte possono essere ugualmente in tema ma differire enormemente nella fiducia.
Ciò richiede valutazioni multiple—controlli automatici, revisione umana e feedback dal mondo reale—perché nessun singolo punteggio cattura l’esperienza utente completa.
La lezione più trasferibile dalla ricerca è organizzativa: qualità a scala richiede collaborazione stretta. Il prodotto definisce cosa significa “buono”, ML migliora i modelli, l’infrastruttura mantiene costi e latenza sotto controllo, legale e policy stabiliscono limiti e il supporto porta in superficie i problemi reali degli utenti.
Se trasformi questi principi in un prodotto reale, un approccio pratico è prototipare presto l’intero ciclo—UI, retrieval, generazione, hook di valutazione e deployment. Piattaforme come Koder.ai sono pensate per quel flusso “build fast, measure fast”: puoi creare app web, backend o mobile tramite un’interfaccia chat, iterare in modalità planning e usare snapshot/rollback quando gli esperimenti vanno storti—utile quando spedisci sistemi probabilistici che richiedono rollout attenti.
La storia di Sergey Brin traccia un arco chiaro: si parte da algoritmi eleganti (PageRank e analisi dei link), poi si passa al ranking appreso e ora a sistemi generativi che possono redigere risposte invece di indicarle. Ogni passo ha aumentato le capacità—e ampliato la superficie di possibili fallimenti.
La ricerca classica aiutava a trovare fonti. L’IA generativa spesso riassume e decide cosa conta, sollevando questioni più difficili: come misurare la veridicità? Come citare fonti in modo che gli utenti si fidino? E come gestire l’ambiguità—consigli medici, contesti legali o notizie in evoluzione—senza trasformare l’incertezza in testo dal tono sicuro?
Scalare non è solo un esercizio di ingegneria; è un limite economico. Le sessioni di addestramento richiedono enorme compute e i costi di erogazione crescono con ogni query utente. Questo crea pressione per tagliare angoli (contesti più brevi, modelli più piccoli, meno controlli di sicurezza) o per concentrare capacità nelle mani di poche aziende con i budget maggiori.
Man mano che i sistemi generano contenuti, la governance diventa più della moderazione: include trasparenza (quali dati hanno formato il modello), responsabilità (chi è responsabile dei danni) e dinamiche competitive (modelli aperti vs chiusi, lock-in di piattaforma e regolamentazione che può favorire involontariamente gli incumbent).
Quando vedi una demo abbagliante, chiediti: cosa succede nei casi limite difficili? Può mostrare le fonti? Come si comporta quando non sa? Quali sono latenza e costi a livelli di traffico reali—non in laboratorio?
Se vuoi approfondire, considera di esplorare argomenti correlati come scaling dei sistemi e sicurezza su /blog.
È una lente utile per collegare i problemi classici del recupero informazioni (rilevanza, resistenza allo spam, scala) ai problemi attuali della IA generativa (grounding, latenza, sicurezza, costi). L'obiettivo non è biografico: è mostrare che ricerca e AI moderna condividono gli stessi vincoli fondamentali: operare su scala massiva mantenendo la fiducia.
La ricerca è “su scala” quando deve gestire in modo affidabile milioni di query con bassa latenza, alta disponibilità e dati costantemente aggiornati.
L’IA generativa è “su scala” quando deve fare lo stesso generando output, il che aggiunge vincoli extra attorno a:
I motori di ricerca della fine degli anni ’90 si basavano molto sul match di parole chiave e su segnali di ranking elementari, che sono venuti meno con l’esplosione del web.
I guasti comuni erano:
PageRank trattava i link come una sorta di voto di fiducia, con voti ponderati dall’importanza della pagina che linka.
Praticamente, ha:
Perché il ranking coinvolge denaro e attenzione: diventa un sistema avversariale. Appena un segnale di ranking funziona, qualcuno cerca di sfruttarlo.
Questo impone iterazione continua:
A scala web, la “qualità” include le prestazioni dei sistemi. Gli utenti percepiscono la qualità come:
Un risultato leggermente peggiore consegnato in 200ms costanti può battere uno migliore che va in timeout o arriva in ritardo.
Learning to rank sostituisce regole tarate a mano con modelli addestrati sui dati (comportamento di click, giudizi umani e altri segnali).
Invece di decidere manualmente quanto pesa ogni segnale, il modello impara combinazioni che predicono meglio i “risultati utili”. L’interfaccia visibile può restare la stessa, ma internamente il sistema diventa:
Il deep learning ha migliorato come i sistemi rappresentano il significato, aiutando con:
I compromessi sono reali: costi di calcolo più elevati, bisogno di più dati e debugging/spiegabilità più difficili quando il ranking cambia.
La ricerca classica seleziona e ordina documenti esistenti. L’IA generativa produce testo, cambiando i modi di fallimento.
I nuovi rischi includono:
La domanda centrale passa da “Abbiamo classificato la fonte migliore?” a “La risposta generata è accurata, fondata e sicura?”
La retrieval-augmented generation (RAG) recupera prima fonti rilevanti, poi genera una risposta fondata su di esse.
Per farla funzionare in prodotto, i team aggiungono tipicamente:
