Anatomie du moteur de recherche Postgres, alors que les éditeurs se restructurent

L'article est paru à 01h39 UTC le 27 septembre. Le blog technique de PlanetScale a publié « Anatomy of a (Postgres) Search Engine », un guide expliquant comment les index inversés, les dictionnaires de termes et les listes de positions remplacent les scans ligne par ligne qui rendent les requêtes LIKE '%postgres%' coûteuses. Le timing n'est pas anodin pour le secteur médiatique, même si l'article ne mentionne jamais l'édition.

Le trafic de recherche est ce que les éditeurs tentent de remplacer ou de reconstruire, et la conversation sur l'infrastructure a descendu d'un niveau. L'article de PlanetScale rappelle que la mécanique derrière la recherche n'est pas de la magie. Un index B-tree trie les valeurs d'une colonne dans un ordre total et peut trouver une valeur exacte, une plage ou un préfixe. Il ne peut pas correspondre à du contenu au milieu d'une chaîne. Ce travail revient à un index inversé, qui associe chaque mot individuel d'un champ texte aux documents qui le contiennent.

L'article est assez détaillé pour être utile aux ingénieurs et assez spécifique pour être vérifiable. PlanetScale décrit un dictionnaire de termes qui associe tous les termes de tous les documents à des listes de positions, le dictionnaire étant stocké sur disque sous forme de B-tree ou d'une autre structure triée lexicographiquement. Les requêtes avec jokers et floues peuvent balayer une partie ou la totalité de ce dictionnaire : g* cherche à la fois gonna et give, tandis que u~2 cherche tous les termes à deux modifications de caractères, ce qui dans l'exemple de l'article signifie you et up.

Pourquoi la plomberie importe aux éditeurs

Les listes de positions sont presque toujours triées et compressées. PlanetScale donne un exemple chiffré : un index avec 300 000 documents, dont 100 000 contiennent le mot « who », prendrait 19 bits par position si chaque ID était stocké littéralement, mais l'écart moyen entre les IDs triés successifs est de trois, ce qui tient dans deux bits. Les listes denses peuvent être stockées sous forme de bitmaps, un bit par document. L'union et l'intersection des listes triées s'exécutent en un seul passage O(n), et les opérations sur les bitmaps peuvent utiliser des instructions vectorielles pour OUer ou ETer 128, 256 voire 512 bits à la fois.

C'est la même classe de problèmes que les éditeurs rencontrent désormais côté consommation. Le 28 septembre, Digiday a publié un récapitulatif de son Publishing Summit décrivant comment les éditeurs se restructurent pour l'ère post-recherche. Le même matin, cxotoday.com a publié un article soutenant que les médias indépendants sont bridés par Google et d'autres géants de l'IA. Aucun de ces médias n'est cité dans l'article de PlanetScale, et le blog technique n'aborde pas du tout le trafic de renvoi. Le lien est structurel : la recherche est reconstruite des deux côtés de la requête.

Les chiffres qui circulent dans la presse spécialisée médiatique ne sont pas doux. Les titres récents suivis dans le dossier incluent une baisse de 40 % des renvois Google Search pour les éditeurs en glissement annuel, datée du 24 septembre, et un rapport séparé indiquant que le trafic des moteurs de recherche baisse sur le web, avec certains petits sites constatant une chute de 60 %. Ces chiffres proviennent d'une agrégation de titres plutôt que des sources primaires, il faut donc les traiter comme directionnels. La direction est cohérente.

Les alternatives open-source bougent aussi

Luxir, un moteur de recherche hybride open-source publié le 22 septembre, se vend sur la même économie. Son site revendique la recherche en texte intégral, vectorielle et par facettes avec analytique depuis un seul moteur, avec un planificateur de vol de travail qui partage l'indexation, la fusion et l'exécution des requêtes sur tous les cœurs, une E/S réseau asynchrone, et des chemins SIMD pour le décodage des positions, le scoring et la distance vectorielle. Les compteurs de facettes sont exacts par défaut, selon le projet, et les requêtes top-k élaguent avec des bornes block-max lorsque l'appelant ne demande pas un total exhaustif.

La page Luxir est un site produit, pas un papier de benchmark, et ses revendications de performance sont auto-déclarées. C'est la même chose pour l'article de PlanetScale, publié par une entreprise vendant une base de données compatible Postgres. Les deux sont utiles comme descriptions d'architecture et déclarations d'intention. Aucun ne devrait être lu comme une mesure indépendante.

Ailleurs dans le dossier, un papier arXiv du 22 septembre de Jochen Madler chez Sitefire, « SlopShape: Identifying AI-Generated Commercial Web Content », propose un détecteur structurel de contenu marketing écrit par IA. Le papier rapporte 2 250 blogs humains pré-ChatGPT de 268 domaines d'entreprises contre 11 250 miroirs IA de cinq modèles de pointe, détectés avec un macro-F1 de 98.0 sur des entreprises retenues à partir de 187 caractéristiques structurelles seulement, avec une attribution au bon modèle source de 79.3 % contre un taux de hasard de 16.7 %. Le kappa humain-humain était de 0.928 et humain-modèle de 0.946. Le papier est en v2, révisé le 17 septembre.

Cela compte pour la même raison que l'infrastructure de recherche. Si une grande partie du contenu web commercial est générée par machine dans une forme ordonnée et auto-annoncée, alors le corpus que les moteurs de recherche indexent change en même temps que les moteurs. Les éditeurs qui se restructurent pour l'ère post-recherche ne se battent pas seulement pour une place dans une page de résultats. Ils se battent pour une place dans un corpus qui s'écrit de plus en plus lui-même.

Deux éléments plus petits dans le dossier pointent dans la même direction. ParkourNote, un espace de recherche construit par un seul développeur publié le 28 septembre, importe des papiers, livres, pages web et vidéos, les transcrit et traduit, et expose la bibliothèque à Claude, ChatGPT ou Codex via un serveur MCP. GPU-font, également publié le 28 septembre, exécute un petit réseau neuronal dans le navigateur via WebGPU pour correspondre des polices à partir d'une image. Les deux sont des projets individuels, pas des changements de plateforme. Ils sont aussi tous deux des exemples du même motif : plus de capacité, moins de serveur, moins d'intermédiaires.

Pour les éditeurs, la question pratique est inchangée. Les renvois de recherche chutent, le coût technique de la construction d'un produit de recherche chute avec eux, et le volume de contenu synthétique qui concurrence pour les mêmes emplacements d'index augmente. L'article de PlanetScale explique comment l'index trouve un mot. Il n'explique pas qui est trouvé.