L’auteur, insatisfait par la dégradation des résultats des moteurs de recherche actuels (spam SEO, manque de pertinence), a relevé le défi de construire son propre moteur de recherche en deux mois, en s’appuyant sur des modèles d’embeddings neuronaux (comme SBERT) pour comprendre le sens des requêtes plutôt que de se limiter à la correspondance de mots-clés. Le projet a impliqué la génération de 3 milliards d’embeddings à l’aide d’un cluster de 200 GPU, l’indexation de 280 millions de pages web, et une architecture distribuée combinant RocksDB et HNSW pour gérer 4 To de RAM et 82 To de stockage SSD, avec un temps de réponse moyen de 500 ms. L’approche innovante inclut une normalisation poussée du HTML, un découpage sémantique des pages pour préserver le contexte, et un crawler optimisé pour éviter les limitations de débit. Le moteur permet de répondre à des requêtes complexes et nuancées, même formulées en langage naturel, en identifiant des réponses précises et pertinentes, y compris dans des contenus obscurs ou peu accessibles. Le billet détaille chaque étape : preuve de concept, normalisation des données, chunking intelligent, optimisation des performances, et déploiement d’un graphe de connaissances. Un demo en ligne est disponible pour tester le résultat.

Forward Proxy vs Reverse Proxy : Le forward proxy agit comme un intermédiaire entre le client et internet, filtrant les requêtes (ex : contrôle d’accès, cache, anonymat) et nécessitant une configuration côté client, tandis que le reverse proxy se place entre internet et le serveur, protégeant ce dernier (ex : équilibrage de charge, sécurité, TLS termination, cache) et masquant son adresse IP. Le premier est utile pour gérer les requêtes sortantes (ex : réseaux d’entreprise), le second pour optimiser et sécuriser les requêtes entrantes (ex : sites web à fort trafic). En résumé, le forward proxy sert le client, le reverse proxy sert le serveur.