Postgres, Luxir e SlopShape: lo stack di ricerca si ricostruisce mentre il traffico degli editori cala

La novità più recente nello stack di ricerca di questa settimana non è arrivata da un motore di ricerca. Il 27 settembre PlanetScale ha pubblicato "Anatomy of a (Postgres) Search Engine", una spiegazione tecnica su come funzionano gli indici invertiti dentro Postgres e su come differiscono dai b-tree a cui la maggior parte degli sviluppatori ricorre per prima cosa.

Il testo di PlanetScale ricorda che la ricerca è ormai una funzione del database, non solo una categoria di prodotto. "Un b-tree è inutile per trovare contenuto nel mezzo di una stringa", scrive l'azienda. Poi mostra lo schema che vuole far smettere di usare agli sviluppatori: una query che controlla ogni riga di una tabella con un LIKE e un carattere jolly iniziale. L'alternativa è un indice invertito, indicizzato per ogni singola parola di un campo. È il modo in cui "praticamente tutti i motori di ricerca full-text" individuano i documenti, secondo il post. Un dettaglio architetturale piccolo, con conseguenze grandi sulla rapidità con cui un database risponde a una domanda.

La spiegazione è insolitamente concreta sulla macchina. Un indice invertito ha un dizionario dei termini e delle posting list, e può aggiungere sopra dati posizionali e di frequenza. Le posting list sono ordinate, poi compresse. PlanetScale porta l'esempio di un indice con 300.000 documenti, 100.000 dei quali contengono la parola "who". Memorizzare ogni ID per esteso richiederebbe 19 bit per posting, ma il divario medio tra ID successivi è tre, che sta in due bit. Le liste dense possono spingersi oltre e memorizzare una bitmap, che diventa ottimale quando circa la metà di tutti i documenti contiene un termine. È un dettaglio di compressione, ma spiega perché la ricerca su grandi corpora sia sostenibile e perché il motore di query possa fare l'unione o l'intersezione di due posting list in un solo passaggio O(n). PlanetScale osserva anche che le istruzioni vettoriali sulle CPU recenti possono fare OR o AND su 128, 256 o persino 512 bit in una sola istruzione, quando le liste sono memorizzate come bitmap.

Luxir propone la ricerca a spettro completo in un solo motore

Cinque giorni prima, il 22 settembre, un progetto separato chiamato Luxir ha pubblicato la propria proposta: un motore open source che unisce ricerca full-text, vettoriale e a faccette con l'analytics in una sola richiesta. Il sito di Luxir inquadra la questione in termini di costi, non di funzioni. Il motore è "progettato per ottenere il massimo di ricerca per core, per gigabyte e per dollaro", e i clienti cloud "pagano l'inefficienza per sempre".

Le affermazioni sull'architettura sono precise. Uno scheduler con work-stealing distribuisce indicizzazione, merging ed esecuzione delle query tra i core. L'IO di rete è asincrono, così un client lento non occupa un core. I segmenti sono immutabili e mappati in memoria, quindi vengono letti dalla page cache. La decodifica delle posting, lo scoring e la distanza vettoriale passano su percorsi SIMD, con block-max pruning per le richieste top-k. Luxir prende anche posizione sui conteggi, cosa che conta per chi costruisce un'interfaccia di ricerca. I conteggi delle faccette sono "sempre esatti per impostazione predefinita", dice il progetto. I conteggi totali dei risultati sono esatti quando la richiesta lo chiede e potati quando non lo fa. Query, faccette e metriche girano nello stesso passaggio sulla stessa vista dell'indice, così un solo round trip restituisce documenti, conteggi della barra laterale e numeri dell'intestazione insieme.

Entrambi i post descrivono impianti che la maggior parte degli utenti non vede mai. Ma sono lo strato dove si decide l'economia della ricerca, e quell'economia sta cambiando in fretta.

Un rilevatore che legge la struttura, non il lessico

Lo stesso giorno del lancio di Luxir, un paper su arXiv ha puntato il mirino sul contenuto che riempie questi indici. "SlopShape: Identifying AI-Generated Commercial Web Content", inviato il 14 settembre e rivisto il 17 settembre, si chiede se il testo generato dall'AI possa essere identificato dalle firme strutturali, cioè da come vengono presentate le informazioni, in quale ordine, con quali prove e con quale voce. L'autore, Jochen Madler di Sitefire, ha replicato il lavoro StoryScope di Russell et al. sul contenuto commerciale: 2.250 post di blog umani precedenti a ChatGPT, da 268 domini aziendali, contro 11.250 speculari generati dall'AI da cinque modelli di frontiera. Uno strumento con 214 feature, applicato da un LLM e validato in una sessione di annotazione umana di riferimento con kappa uomo-uomo di 0,928 e kappa uomo-modello di 0,946, ha individuato i post AI dalle sole 187 feature strutturali con un macro-F1 di 98,0 su aziende tenute fuori dal campione. Riscrivere ogni post AI con il suo stesso modello ha lasciato il punteggio invariato a 98,1.

Il paper rivendica anche l'attribuzione. I post AI condividono "una forma ordinata e auto-annunciata", il 79,3 per cento è attribuito al modello di origine corretto contro un tasso casuale del 16,7 per cento, e i post umani occupano configurazioni strutturali rare. La pipeline, lo strumento, i prompt e il codice sono rilasciati.

Il risultato conta per la ricerca perché la struttura è esattamente ciò che consumano i sistemi di ranking e i motori di risposta basati sull'AI. Se il contenuto commerciale sul web ha una forma rilevabile, allora il corpus che i motori di ricerca indicizzano sta diventando più uniforme nello stesso momento in cui gli strumenti per indicizzarlo diventano più veloci ed economici.

A pagare sono gli editori

I titoli che circondano il dossier puntano nella direzione opposta. La copertura recente citata nel dossier include un rapporto secondo cui il calo della ricerca Google si è inasprito fino al 40 per cento anno su anno per gli editori, datato 24 settembre, e un altro elemento secondo cui i badge del profilo di Google Search espongono la crisi del traffico degli editori, datato 16 settembre. Voci più vecchie descrivono il traffico dai motori di ricerca in calo in tutto il web, con alcuni piccoli siti che vedono un calo del 60 per cento, e la ricerca AI di Google che minaccia i piccoli editori mentre l'AI conversazionale taglia il traffico ai siti. Alcune di quelle date cadono fuori dall'ultima settimana, quindi sono sfondo, non notizia. Ma fissano la cornice per i rilasci tecnici descritti sopra: il costo di costruire un indice di ricerca continua a scendere, e il traffico che quell'indice rimanda agli editori scende insieme a esso.

Altri due elementi del dossier mostrano quanto largo sia diventato il campo. Il 26 settembre CleanTechnica ha aperto le candidature per la propria divisione editoriale libraria. Agli autori offre una via alla pubblicazione per una tariffa anticipata da 3.000 a 5.000 dollari più una percentuale su ogni libro venduto, con un Google Hangout fissato per il 30 settembre. Il 24 settembre l'hub di contenuti tecnici di Wiley ha pubblicato un white paper, sponsorizzato da Hendrix by Marmon Utility, sulla costruzione delle uscite in sottostazione. Il paper sostiene che l'affidabilità nei primi tratti fuori da una stazione ha un peso insolito, perché un singolo guasto da contatto lì può interrompere molti circuiti in una volta.

Nessuno dei due è una storia di ricerca di per sé. Ma entrambi sono contenuti commerciali rivolti a un pubblico specifico, prodotti sotto il nome di uno sponsor o il marchio di un editore, cioè la stessa categoria che il paper SlopShape cerca di classificare. La tesi del paper è che questo contenuto abbia una forma: un ordine particolare, un tipo particolare di prove, una voce particolare. Se regge, la prossima generazione di motori di ricerca dovrà decidere cosa farne.

Per ora il lato infrastrutturale si muove più in fretta del lato politico. PlanetScale sta distribuendo TIN, il suo indice di ricerca full-text per Postgres, e annuncia un articolo più approfondito su funzioni, prestazioni e implementazione. Luxir è scaricabile, con un'API HTTP/JSON sulla porta 9.400 e una directory dati per la persistenza. Il paper su arXiv è pubblico, con codice e artefatti allegati.

Quello che nessuno di loro risolve è dove vadano i lettori. I motori di ricerca stanno diventando più bravi a trovare documenti, e gli editori riferiscono che sempre meno persone arrivano a leggerli. Quel divario è la storia a cui gli strumenti non hanno ancora risposto.