Postgres, Luxir et SlopShape : la pile de recherche se reconstruit pendant que le trafic des éditeurs chute

La nouveauté de la semaine dans la pile de recherche ne vient pas d'un moteur de recherche. Le 27 septembre, PlanetScale a publié « Anatomy of a (Postgres) Search Engine », une explication technique du fonctionnement des index inversés dans Postgres et de ce qui les distingue des b-arbres que la plupart des développeurs utilisent en premier réflexe.

Le texte de PlanetScale rappelle que la recherche est désormais une fonction de base de données, pas seulement une catégorie de produit. « Un b-arbre ne sert à rien pour trouver un contenu au milieu d'une chaîne », écrit l'entreprise, avant de montrer le schéma qu'elle veut voir disparaître : une requête qui parcourt chaque ligne d'une table avec un LIKE à joker initial. L'alternative, un index inversé construit sur chaque mot d'un champ, est la méthode utilisée par « pratiquement tous les moteurs de recherche plein texte » pour localiser des documents, selon l'article. Le point d'architecture est mince, ses conséquences sur le temps de réponse d'une base sont grandes. L'explication entre dans le détail de la mécanique. Un index inversé comporte un dictionnaire de termes et des listes de publications, auxquelles s'ajoutent parfois des données de position et de fréquence. Ces listes sont triées puis compressées. PlanetScale prend l'exemple d'un index de 300 000 documents, dont 100 000 contiennent le mot « who ». Stocker chaque identifiant en clair demanderait 19 bits par publication, mais l'écart moyen entre identifiants successifs est de trois, ce qui tient sur deux bits. Les listes denses peuvent aller plus loin et stocker une bitmap, solution optimale dès qu'environ la moitié des documents contiennent un terme. C'est un détail de compression, mais il explique pourquoi la recherche sur de grands corpus reste abordable, et pourquoi le moteur peut calculer l'union ou l'intersection de deux listes de publications en une seule passe O(n). PlanetScale note aussi que les instructions vectorielles des processeurs récents peuvent faire un OR ou un AND sur 128, 256, voire 512 bits en une instruction lorsque les listes sont stockées sous forme de bitmaps.

Luxir présente une recherche à spectre complet dans un seul moteur

Cinq jours plus tôt, le 22 septembre, un autre projet, Luxir, a publié sa propre proposition : un moteur open source qui réunit recherche plein texte, recherche vectorielle et recherche à facettes avec l'analytique en une seule requête. Le site de Luxir pose l'argument en termes de coûts plutôt que de fonctionnalités : le moteur est « conçu pour le plus de recherche par cœur, par gigaoctet et par dollar », et les clients du cloud « paient l'inefficacité pour toujours ».

Les promesses d'architecture sont précises. Un ordonnanceur à vol de travail répartit l'indexation, la fusion et l'exécution des requêtes entre les cœurs. Les entrées-sorties réseau sont asynchrones, pour qu'un client lent ne bloque pas un cœur, et les segments sont immuables et projetés en mémoire, donc lus depuis le cache de pages. Le décodage des publications, le calcul des scores et la distance vectorielle passent par des chemins SIMD, avec élagage block-max pour les requêtes top-k. Luxir prend aussi position sur les compteurs, ce qui compte pour quiconque construit une interface de recherche. Les compteurs de facettes sont « toujours exacts par défaut », affirme le projet, et le total des résultats est exact quand la requête le demande, élagué sinon. Requêtes, facettes et métriques s'exécutent dans la même passe sur la même vue d'index : un seul aller-retour renvoie les documents, les compteurs de la colonne latérale et les chiffres de l'en-tête.

Les deux articles décrivent une plomberie que la plupart des utilisateurs ne voient jamais. C'est pourtant à ce niveau que se décide l'économie de la recherche, et cette économie change vite.

Un détecteur qui lit la structure, pas le vocabulaire

Le jour même du lancement de Luxir, un article sur arXiv s'est attaqué au contenu qui remplit ces index. « SlopShape: Identifying AI-Generated Commercial Web Content », soumis le 14 septembre et révisé le 17 septembre, pose la question de savoir si un texte généré par IA peut être identifié à partir de signatures structurelles, c'est-à-dire la manière dont l'information est présentée, dans quel ordre, avec quelles preuves et avec quelle voix. L'auteur, Jochen Madler de Sitefire, a répliqué les travaux StoryScope de Russell et al. sur du contenu commercial : 2 250 billets de blog humains antérieurs à ChatGPT, issus de 268 domaines d'entreprise, contre 11 250 miroirs générés par cinq modèles de pointe. Un instrument à 214 caractéristiques, appliqué par un LLM et validé lors d'une session d'annotation humaine avec un kappa humain-humain de 0,928 et un kappa humain-modèle de 0,946, a détecté les billets IA à partir de ses seules 187 caractéristiques structurelles, avec un macro-F1 de 98,0 sur des entreprises mises de côté. Reformuler chaque billet IA avec son propre modèle a laissé le score inchangé, à 98,1.

L'article revendique aussi l'attribution. Les billets IA partagent « une forme nette, qui s'annonce elle-même », 79,3 pour cent sont attribués au bon modèle source contre un taux de hasard de 16,7 pour cent, et les billets humains occupent de rares configurations structurelles. Le pipeline, l'instrument, les prompts et le code sont publiés.

Ce résultat compte pour la recherche, car la structure est exactement ce que consomment les systèmes de classement et les moteurs de réponse par IA. Si le contenu commercial du web a une forme détectable, le corpus indexé par les moteurs devient plus uniforme au moment même où les outils pour l'indexer deviennent plus rapides et moins chers.

Ce sont les éditeurs qui paient

Les gros titres qui entourent ce dossier vont dans l'autre sens. Parmi les articles récents cités figure un rapport selon lequel le recul de Google Search s'est aggravé jusqu'à 40 pour cent en glissement annuel pour les éditeurs, daté du 24 septembre, et un autre élément indiquant que les badges de profil Google Search exposent la crise du trafic des éditeurs, daté du 16 septembre. Des éléments plus anciens décrivent un trafic issu des moteurs en baisse sur le web, certains petits sites perdant 60 pour cent, et la recherche IA de Google menaçant les petits éditeurs à mesure que l'IA conversationnelle réduit le trafic vers les sites. Certaines de ces dates sortent de la dernière semaine : ce sont des éléments de contexte, pas des nouvelles. Mais ils posent le cadre des sorties techniques ci-dessus. Le coût de construction d'un index de recherche baisse sans cesse, et le trafic que cet index renvoie aux éditeurs baisse avec lui.

Deux autres éléments du dossier montrent l'ampleur du terrain. Le 26 septembre, CleanTechnica a ouvert les soumissions pour sa propre branche d'édition de livres. L'offre donne aux auteurs une voie vers la publication moyennant des frais initiaux de 3 000 à 5 000 dollars, plus un pourcentage sur chaque livre vendu, avec un Google Hangout prévu le 30 septembre. Le 24 septembre, le hub de contenu technique de Wiley a publié un livre blanc, sponsorisé par Hendrix by Marmon Utility, sur la construction des sorties de poste. Il y soutient que la fiabilité des premières portées sortant d'une station pèse d'un poids particulier, car un seul défaut par contact à cet endroit peut interrompre plusieurs circuits d'un coup.

Aucun des deux n'est un sujet de recherche à première vue. Mais tous deux sont du contenu commercial visant un public précis, produit sous le nom d'un sponsor ou sous la marque d'un éditeur, soit exactement la catégorie que l'article SlopShape cherche à classer. Sa thèse est que ce contenu a une forme : un ordre particulier, un type de preuve particulier, une voix particulière. Si elle tient, la prochaine génération de moteurs de recherche devra décider quoi en faire.

Pour l'instant, l'infrastructure avance plus vite que les règles. PlanetScale livre TIN, son index de recherche plein texte pour Postgres, et annonce un article plus approfondi sur ses fonctionnalités, ses performances et sa mise en œuvre. Luxir est téléchargeable, avec une API HTTP/JSON sur le port 9400 et un répertoire de données pour la persistance. L'article arXiv est public, code et artefacts joints.

Aucun d'eux ne règle la question de savoir où vont les lecteurs. Les moteurs de recherche trouvent de mieux en mieux les documents, et les éditeurs rapportent que moins de gens arrivent jusqu'à eux. Cet écart est l'histoire à laquelle l'outillage n'a pas encore répondu.