L'anatomia dei motori di ricerca Postgres, mentre gli editori si reinventano

L'articolo è uscito alle 01:39 UTC del 27 settembre. Sul blog di ingegneria di PlanetScale è apparso "Anatomy of a (Postgres) Search Engine", una guida su come indici invertiti, dizionari dei termini e liste di postings sostituiscono le scansioni riga per riga che rendono costose le query LIKE '%postgres%'. Il tempismo non è casuale per il settore dei media, anche se il post non menziona mai l'editoria.

Il traffico da ricerca è ciò che gli editori cercano di sostituire o ricostruire. La conversazione sull'infrastruttura è scesa di un livello. L'articolo di PlanetScale ricorda che la meccanica dietro la ricerca non è magia. Un indice b-tree ordina i valori di una colonna in un ordine totale e può trovare un valore esatto, un intervallo o un prefisso. Non può però corrispondere al contenuto in mezzo a una stringa. Questo compito spetta a un indice invertito, che mappa ogni singola parola di un campo testuale ai documenti che la contengono.

Il post è abbastanza dettagliato da essere utile agli ingegneri e abbastanza specifico da essere verificabile. PlanetScale descrive un dizionario dei termini che mappa ogni termine in tutti i documenti alle liste di postings. Il dizionario è memorizzato su disco come b-tree o un'altra struttura ordinata lessicograficamente. Le query wildcard e fuzzy possono scansionare parte o tutto quel dizionario: g* cerca sia gonna che give, mentre u~2 cerca ogni termine entro due modifiche di caratteri, che nell'esempio del post significa you e up.

Perché l'ingegneria idraulica interessa agli editori

Le liste di postings sono quasi sempre ordinate e compresse. PlanetScale fornisce un esempio pratico: un indice con 300.000 documenti, dei quali 100.000 contengono la parola "who", richiederebbe 19 bit per ogni posting se ogni ID fosse memorizzato letteralmente. La distanza media tra ID ordinati successivi è tre, che sta in due bit. Le liste dense possono essere memorizzate come bitmap, un bit per documento. Unione e intersezione di liste ordinate si eseguono in un singolo passaggio O(n). Le operazioni su bitmap possono usare istruzioni vettoriali per OR o AND 128, 256 o persino 512 bit alla volta.

È la stessa classe di problemi che gli editori affrontano ora sul lato del consumo. Il 28 settembre, Digiday ha pubblicato un riassunto del suo Publishing Summit, descrivendo come gli editori si stiano ricostruendo per l'era post-ricerca. La stessa mattina, cxotoday.com ha pubblicato un articolo che sostiene che i media indipendenti siano strozzati da Google e altri giganti dell'IA. Nessuna delle due testate è citata nel post di PlanetScale, e il blog tecnico non affronta affatto il traffico di referral. Il collegamento è strutturale: la ricerca sta venendo ricostruita su entrambi i lati della query.

I numeri circolanti nella stampa commerciale non sono gentili. I titoli recenti tracciati nella dossier includono un calo del 40% anno su anno nei referral da Google Search per gli editori, datato 24 settembre. C'è anche un rapporto separato sul calo del traffico dei motori di ricerca su tutto il web, con alcuni piccoli siti che vedono un calo del 60%. Quelle cifre provengono dall'aggregazione dei titoli piuttosto che dalle fonti primarie, quindi vanno trattate come direzionali. La direzione è coerente.

Anche le alternative open source si muovono

Luxir, un motore di ricerca ibrido open source pubblicato il 22 settembre, si vende sulla stessa economia. Il suo sito rivendica ricerca full-text, vettoriale e sfaccettata con analisi da un unico motore. Include uno scheduler work-stealing che condivide indicizzazione, merging ed esecuzione delle query su tutti i core, I/O di rete asincrono e percorsi SIMD per la decodifica dei postings, lo scoring e la distanza vettoriale. I conteggi delle facce sono esatti di default, secondo il progetto. Le richieste top-k potano con limiti block-max quando il chiamante non chiede un totale esaustivo.

La pagina di Luxir è un sito di prodotto, non un paper di benchmark, e le sue affermazioni sulle prestazioni sono auto-dichiarate. Lo stesso vale per il post di PlanetScale, pubblicato da un'azienda che vende un database compatibile con Postgres. Entrambi sono utili come descrizioni di architettura e come dichiarazioni di intenti. Nessuno dei due dovrebbe essere letto come una misurazione indipendente.

Altrove nella dossier, un paper arXiv del 22 settembre di Jochen Madler di Sitefire, "SlopShape: Identifying AI-Generated Commercial Web Content", offre un rilevatore strutturale per i copy di marketing scritti da IA. Il paper riporta 2.250 post di blog umani pre-ChatGPT da 268 domini aziendali contro 11.250 specchi AI da cinque modelli frontier. Il rilevamento avviene al 98.0 macro-F1 su aziende tenute da parte, usando solo 187 caratteristiche strutturali. L'attribuzione al modello sorgente corretto è al 79,3%, contro una probabilità del 16,7%. Il kappa umano-umano era 0.928 e umano-modello 0.946. Il paper è una v2, rivista il 17 settembre.

Questo conta per la stessa ragione per cui conta l'infrastruttura di ricerca. Se una grande parte del contenuto web commerciale è generato da macchine in una forma ordinata e auto-annunciante, il corpus che i motori di ricerca indicizzano sta cambiando nello stesso tempo in cui cambiano i motori. Gli editori che si ricostruiscono per un'era post-ricerca non stanno solo competendo per un piazzamento in una pagina di risultati. Stanno competendo per un piazzamento in un corpus che sempre più spesso si riscrive da solo.

Due elementi minori nella dossier puntano nella stessa direzione. ParkourNote, un ambiente di ricerca costruito da un singolo sviluppatore postato il 28 settembre, importa paper, libri, pagine web e video, li trascrive e traduce, ed espone la libreria a Claude, ChatGPT o Codex attraverso un server MCP. GPU-font, anche questo postato il 28 settembre, esegue una piccola rete neurale nel browser tramite WebGPU per abbinare font da un'immagine. Sono entrambi progetti individuali, non spostamenti di piattaforma. Sono anche entrambi esempi dello stesso pattern: più capacità, meno server, meno intermediari.

Per gli editori, la domanda pratica non è cambiata. I referral da ricerca stanno calando, il costo tecnico di costruire un prodotto di ricerca sta calando con loro, e il volume di contenuto sintetico che compete per gli stessi slot di indice sta crescendo. Il post di PlanetScale spiega come l'indice trova una parola. Non spiega chi viene trovato.