Un ingénieur crée un moteur de recherche innovant pour lutter contre le spam SEO

Wilson Lin : création d’un moteur de recherche en deux mois

Motivé par la perception d’une augmentation du spam SEO dans les moteurs classiques, Wilson Lin a construit un démonstrateur fonctionnel en l’espace de deux mois. « What’s great is the comparable lack of SEO spam. » écrit-il en présentant son prototype.

Approche par embeddings neuronaux

Wilson a choisi les embeddings neuronaux (neural embeddings) comme méthode centrale. Il a d’abord réalisé un test à petite échelle pour valider l’approche et a constaté que cette technique permettait d’améliorer la pertinence des correspondances sémantiques entre requêtes et contenus.

Découpage des contenus

Pour traiter les pages web, il a retenu un découpage au niveau des phrases comme granularité minimale pertinente : cela permet d’identifier la réponse la plus pertinente au sein d’une phrase tout en conservant la possibilité d’agréger des unités au niveau du paragraphe pour le contexte.

Pour résoudre les références indirectes (pronoms, anaphores), il a entraîné un modèle distinct :

“I trained a DistilBERT classifier model that would take a sentence and the preceding sentences, and label which one (if any) it depends upon in order to retain meaning. Therefore, when embedding a statement, I would follow the “chain” backwards to ensure all dependents were also provided in context.

This also had the benefit of labelling sentences that should never be matched, because they were not “leaf” sentences by themselves.”

Identification du contenu principal

Pour isoler le contenu principal (Main Content) d’une page, Wilson s’est appuyé sur les balises HTML classiques, en raison de l’absence généralisée d’HTML sémantique sur de nombreux sites. Il a listé les balises suivantes comme indicatives du contenu utile :

• blockquote — citation
• dl — liste de descriptions
• ol — liste ordonnée
• p — paragraphe
• pre — texte préformaté
• table — tableau de données
• ul — liste non ordonnée

Problèmes de crawling

Le crawling a révélé de nombreux points de fragilité : résolutions DNS défaillantes, types d’URL à exclure et contraintes liées aux formats et longueurs d’URL. Wilson a imposé des règles strictes pour les URL crawlées :

“They must have https: protocol, not ftp:, data:, javascript:, etc.

They must have a valid eTLD and hostname, and can’t have ports, usernames, or passwords.

Canonicalization is done to deduplicate. All components are percent-decoded then re-encoded with a minimal consistent charset. Query parameters are dropped or sorted. Origins are lowercased.

Some URLs are extremely long, and you can run into rare limits like HTTP headers and database index page sizes.

Some URLs also have strange characters that you wouldn’t think would be in a URL, but will get rejected downstream by systems like PostgreSQL and SQS.”

Stockage et performances

Il a d’abord choisi Oracle Cloud pour ses faibles coûts d’egress et l’offre de 10 To gratuits par mois, utile pour stocker des téraoctets sans coûts excessifs. Mais des problèmes d’évolutivité l’ont amené à tester PostgreSQL, puis à adopter finalement RocksDB.

“I opted for a fixed set of 64 RocksDB shards, which simplified operations and client routing, while providing enough distribution capacity for the foreseeable future.

…At its peak, this system could ingest 200K writes per second across thousands of clients (crawlers, parsers, vectorizers). Each web page not only consisted of raw source HTML, but also normalized data, contextualized chunks, hundreds of high dimensional embeddings, and lots of metadata.”

Inférence GPU

Pour générer les vecteurs sémantiques à partir des pages crawlées, Wilson a utilisé des inférences sur GPU. Après un premier recours aux embeddings via l’API d’OpenAI (coûteux à grande échelle), il a opté pour une solution auto-hébergée avec des GPU fournis par Runpod, citant un meilleur rapport performance/prix sur des cartes comme la RTX 4090 exploitées depuis des datacenters de niveau 3.

Moins de spam dans les résultats

Wilson affirme que son moteur affiche moins de spam SEO et illustre cela avec la requête « best programming blogs ». Il ajoute que le moteur peut comprendre des requêtes complexes, y compris des paragraphes entiers, et retrouver des articles pertinents évoquant les sujets du texte soumis.

Quatre enseignements tirés de ce prototype

1. La taille de l’index compte.

   Wilson insiste : « coverage defines quality ». La couverture indexée détermine la capacité d’un moteur à fournir des réponses pertinentes et complètes.

2. Le crawling et le filtrage sont les défis les plus lourds.

   Parcourir un maximum de contenus est nécessaire pour la découverte, mais il faut aussi filtrer le contenu de faible qualité : il s’agit de trouver l’équilibre entre quantité et utilité, en éliminant le contenu inutile ou « junk ». Wilson note que des approches historiques comme PageRank modélisent le comportement des utilisateurs, et que des méthodes modernes devraient combiner évaluation de contenu et analyse de liens.

3. Les limites des petits moteurs indépendants.

   Un petit moteur n’a pas la capacité de crawler l’ensemble du web, ce qui crée des lacunes de couverture et limite la compétition avec les grands indexeurs.

4. Évaluer confiance et authenticité à grande échelle est complexe.

   Wilson écrit :

   “Determining authenticity, trust, originality, accuracy, and quality automatically is not trivial. …if I started over I would put more emphasis on researching and developing this aspect first.

   Infamously, search engines use thousands of signals on ranking and filtering pages, but I believe newer transformer-based approaches towards content evaluation and link analysis should be simpler, cost effective, and more accurate.”

   Il souligne la difficulté d’automatiser l’évaluation de l’originalité, de l’exactitude et de la qualité à partir de données non structurées.

Le projet de Wilson Lin illustre qu’il est techniquement possible, à l’échelle d’un prototype, de réduire le spam SEO et d’améliorer la pertinence grâce aux embeddings neuronaux et à un pipeline soigné de crawling, de traitement et de stockage. Il met également en lumière les contraintes opérationnelles — crawling, stockage, inférences GPU — et les choix d’architecture nécessaires pour faire évoluer un moteur de recherche indépendant.