Un ingénieur logiciel de New York en a tellement marre des résultats non pertinents et du spam de référencement dans les moteurs de recherche qu'il a décidé d'en créer un meilleur. Deux mois plus tard, il a un moteur de recherche de démonstration opérationnel. Voici comment il l'a fait, et quatre idées importantes sur ce qu'il ressent sont les obstacles à la création d'un moteur de recherche de haute qualité.
L'un des motifs de création d'un nouveau moteur de recherche était la perception que les moteurs de recherche traditionnels contenaient une quantité croissante de spam de référencement. Après deux mois, l'ingénieur logiciel a écrit sur leur création:
« Ce qui est génial, c'est le manque comparable de spam de référencement. »
Intégres neuronaux
L'ingénieur logiciel, Wilson Lin, a décidé que la meilleure approche serait les intérêts neuronaux. Il a créé un test à petite échelle pour valider l'approche et a noté que l'approche d'incorporation avait réussi.
Contenu
La phase suivante était de savoir comment traiter les données, comme devraient-elles être divisées en blocs de paragraphes ou de phrases? Il a décidé que le niveau de la phrase était le niveau le plus granulaire qui avait du sens car il a permis d'identifier la réponse la plus pertinente au sein d'une phrase tout en permettant la création de plus grandes unités d'intégration au niveau des paragraphes pour le contexte et la cohérence sémantique.
Mais il avait toujours des problèmes d'identification du contexte avec des références indirectes qui ont utilisé des mots comme «it» ou «le», il a donc franchi une étape supplémentaire pour pouvoir mieux comprendre le contexte:
«J'ai formé un modèle de classificateur Distilbert qui prendrait une phrase et les phrases précédentes, et étiqueterait la personne (le cas échéant) pour conserver le sens. Par conséquent, lors de l'intégration d'une déclaration, je suivrais la« chaîne »en arrière pour garantir que toutes les personnes à charge étaient également fournies en contexte.
Cela avait également l'avantage d'étiqueter des phrases qui ne devraient jamais être égalées, car ce n'étaient pas des phrases «feuilles» par elles-mêmes.
Identifier le contenu principal
Un défi pour ramper a été de développer un moyen d'ignorer les parties non contenues d'une page Web afin d'indexer ce que Google appelle le contenu principal (MC). Ce qui a rendu cela difficile, c'est le fait que tous les sites Web utilisent un balisage différent pour signaler les parties d'une page Web, et bien qu'il ne l'ait pas mentionné, tous les sites Web n'utilisent pas le HTML sémantique, ce qui faciliterait que les robots des robots ne soient pas plus faciles à identifier où se trouve le contenu principal.
Il comptait donc essentiellement sur des balises HTML comme la balise de paragraphe
Pour identifier les parties d'une page Web contenaient le contenu et quelles pièces ne l'ont pas fait.
Ceci est la liste des balises HTML sur lesquelles il s'est appuyé pour identifier le contenu principal:
- Blockquote – une citation
- DL – une liste de description (une liste de descriptions ou de définitions)
- OL – une liste commandée (comme une liste numérotée)
- P – élément de paragraphe
- Pré – Texte préformaté
- Tableau – L'élément pour les données tabulaires
- UL – une liste non ordonnée (comme des puces)
Problèmes avec ramper
La rampe était une autre partie qui est venue avec une multitude de problèmes à résoudre. Par exemple, a-t-il découvert, à sa grande surprise, que la résolution du DNS était un point d'échec assez fréquent. Le type d'URL était un autre problème, où il devait empêcher toute URL de ramper qui n'utilisait pas le protocole HTTPS.
Ce sont quelques-uns des défis:
«Ils doivent avoir HTTPS: Protocole, pas FTP :, Data:, JavaScript:, etc.
Ils doivent avoir un ETLD et un nom d'hôte valides, et ne peuvent pas avoir de ports, noms d'utilisateur ou mots de passe.
Canonicalisation est effectuée pour déduir. Tous les composants sont décodés en pourcentage puis réencodés avec un charse cohérent minimal. Les paramètres de requête sont supprimés ou triés. Les origines sont basées en bas.
Certaines URL sont extrêmement longues et vous pouvez rencontrer des limites rares comme les en-têtes HTTP et la taille des pages d'index de base de données.
Certaines URL ont également des personnages étranges qui, selon vous, ne seraient pas dans une URL, mais seront rejetés en aval par des systèmes comme PostgreSQL et SQS. »
Stockage
Au début, Wilson a choisi Oracle Cloud en raison du faible coût de transfert de données (coûts de sortie).
Il a expliqué:
«J'ai d'abord choisi Oracle Cloud pour les besoins infra en raison de leurs coûts de sortie très bas avec 10 To gratuits par mois. Comme j'en stockerais des téraoctets de données, c'était une bonne rassurance que si jamais j'avais besoin de déplacer ou d'exporter des données (par exemple, les sauvegardes), tout en étant un trou dans mon portefeuille fiable.» Leur calcul était également beaucoup moins cher que d'autres nuages, tout en étant un trou de Wallet.
Mais la solution Oracle Cloud a rencontré des problèmes de mise à l'échelle. Il a donc déplacé le projet à PostgreSQL, a connu un ensemble différent de problèmes techniques et a finalement atterri sur RocksDB, qui a bien fonctionné.
Il a expliqué:
«J'ai opté pour un ensemble fixe de 64 éclats de RocksDB, ce qui a simplifié les opérations et le routage des clients, tout en fournissant une capacité de distribution suffisante dans un avenir prévisible.
… À son apogée, ce système pourrait ingérer 200 000 écritures par seconde sur des milliers de clients (robots, analyseurs, vecteurs). Chaque page Web consistait non seulement en HTML à source brute, mais aussi des données normalisées, des morceaux contextualisés, des centaines d'incorporation de grande dimension et beaucoup de métadonnées. »
GPU
Wilson a utilisé l'inférence alimentée par GPU pour générer des intégres vectoriels sémantiques à partir de contenu Web rampé à l'aide de modèles de transformateur. Il a d'abord utilisé des intégres Openai via l'API, mais cela est devenu cher à mesure que le projet a évolué. Il est ensuite passé à une solution d'inférence auto-hébergée en utilisant des GPU d'une entreprise appelée Runpod.
Il a expliqué:
«À la recherche de la solution évolutive la plus rentable, j'ai découvert Runpod, qui propose des GPU à haut rendement par monde comme le RTX 4090 à des taux beaucoup moins chers par heure que AWS et Lambda. Celles-ci ont été exploitées à partir de DC de niveau 3 avec un réseau rapide stable et beaucoup de capacité de calcul fiable.»
Manque de spam SEO
L'ingénieur logiciel a affirmé que son moteur de recherche avait moins de spam de recherche et a utilisé l'exemple de la question des «meilleurs blogs de programmation» pour illustrer son point. Il a également souligné que son moteur de recherche pouvait comprendre des requêtes complexes et a donné l'exemple de saisir un paragraphe entier de contenu et de découvrir des articles intéressants sur les sujets du paragraphe.
Quatre plats à emporter
Wilson a énuméré de nombreuses découvertes, mais en voici quatre qui peuvent intéresser les spécialistes du marketing numérique et les éditeurs intéressés par ce parcours de création d'un moteur de recherche:
1. La taille de l'indice est importante
L'une des plats les plus importants à retenir que Wilson a appris de deux mois de construction d'un moteur de recherche est que la taille de l'indice de recherche est importante car, selon ses mots, «la couverture définit la qualité». Ce qui a rendu cette partie difficile, c'est qu'il y avait tellement de choses qu'il n'avait pas besoin de ramper, ce qui mène à la prochaine idée, filtrant.
2. Radrer et filtrage sont des problèmes les plus difficiles
Bien que ramper autant de contenu que possible soit important pour faire surface du contenu utile, Wilson a également appris que le filtrage du contenu de faible qualité était difficile car il nécessitait d'équilibrer le besoin de quantité contre l'inutilité de ramper un réseau apparemment sans fin de contenu inutile ou indemne. Il a découvert qu'un moyen de filtrer le contenu inutile était nécessaire.
C'est en fait le problème que Sergey Brin et Larry Page résolus avec le rang de page. Comportement de l'utilisateur modélisé par le rang de page, le choix et les votes des humains qui valident les pages Web avec des liens. Bien que le rang de page ait près de 30 ans, l'intuition sous-jacente reste si pertinente aujourd'hui que la perplexité du moteur de recherche d'IA en utilise une version modifiée pour son propre moteur de recherche.
3. Limites des moteurs de recherche à petite échelle
Un autre point à retenir qu'il a découvert est qu'il y a des limites au succès d'un petit moteur de recherche indépendant. Wilson a cité l'incapacité de ramper tout le Web comme une contrainte qui crée des lacunes de couverture.
4. juger la confiance et l'authenticité à grande échelle est complexe
La détermination automatique de l'originalité, de la précision et de la qualité à travers les données non structurées est non triviale
Wilson écrit:
«La détermination automatique de l'authenticité, de la confiance, de l'originalité, de la précision et de la qualité n'est pas triviale.… Si je recommençais, je mettrais davantage l'accent sur la recherche et le développement de cet aspect en premier.
Tristement célèbre, les moteurs de recherche utilisent des milliers de signaux sur les pages de classement et de filtrage, mais je crois que de nouvelles approches basées sur les transformateurs vers l'évaluation du contenu et l'analyse des liens doivent être plus simples, rentables et plus précises. »
Vous souhaitez essayer le moteur de recherche? Vous pouvez le trouver ici et vous pouvez lire comment les détails techniques complets de la façon dont il l'ont fait ici.
