Les robots d'exploration, les moteurs de recherche et la sordide entreprise d'IA générative

Le boom des produits d'IA générative au cours des derniers mois a incité de nombreux sites Web à prendre des contre-mesures.

La préoccupation de base va comme ceci:

Les produits d'IA dépendent de la consommation de gros volumes de contenu pour former leurs modèles de langage (les soi-disant grands modèles de langage, ou LLM en abrégé), et ce contenu doit provenir de quelque part. Les entreprises d'intelligence artificielle considèrent que l'ouverture du Web permet une exploration à grande échelle pour obtenir des données de formation, mais certains opérateurs de sites Web ne sont pas d'accord, notamment Reddit, Stack Overflow et Twitter.

Cette réponse à cette question intéressante sera sans aucun doute débattue devant les tribunaux du monde entier.

Cet article explorera cette question, en se concentrant sur les aspects commerciaux et techniques. Mais avant de plonger, quelques points :

• Bien que ce sujet aborde, et j'inclus dans cet article, quelques arguments juridiques, je ne suis pas avocat, je ne suis pas votre avocat et je ne vous donne aucun conseil d'aucune sorte. Parlez à votre chat avocat préféré si vous avez besoin de conseils juridiques.
• J'ai travaillé chez Google il y a de nombreuses années, principalement dans la recherche sur le Web. Je ne parle en aucun cas au nom de Google, même lorsque je cite quelques exemples de Google ci-dessous.
• C'est un sujet qui évolue rapidement. C'est garanti qu'entre le moment où j'ai fini d'écrire ceci et que vous le lisiez, quelque chose de majeur se serait produit dans l'industrie, et c'est garanti que j'aurais raté quelque chose !

Le "deal" entre les moteurs de recherche et les sites Web

Nous commençons par le fonctionnement d'un moteur de recherche moderne, comme Google ou Bing. En termes trop simplifiés, un moteur de recherche fonctionne comme ceci :

• Le moteur de recherche a une liste d'URL. Chaque URL contient des métadonnées (parfois appelées « signaux ») qui indiquent que l'URL peut être importante ou utile à afficher dans les pages de résultats du moteur de recherche.
• Sur la base de ces signaux, le moteur de recherche dispose d'un robot d'exploration, un bot, qui est un programme qui récupère ces URL dans un certain ordre "d'importance" en fonction de ce que les signaux indiquent. À cette fin, le robot d'exploration de Google s'appelle Googlebot et celui de Bing est Bingbot (et les deux en ont bien d'autres à d'autres fins, comme les publicités). Les deux bots s'identifient dans l'en-tête de l'agent utilisateur, et les deux peuvent être vérifiés par programme par des sites Web pour s'assurer que le contenu est servi au vrai bot du moteur de recherche et non à une usurpation.
• Une fois le contenu récupéré, il est indexé. Les index des moteurs de recherche sont des bases de données complexes qui contiennent le contenu de la page ainsi qu'une énorme quantité de métadonnées et d'autres signaux utilisés pour faire correspondre et classer le contenu aux requêtes des utilisateurs. Un index est ce qui est réellement recherché lorsque vous tapez une requête dans Google ou Bing.

Les moteurs de recherche modernes, du moins les bons polis, donnent à l'opérateur du site Web un contrôle total sur l'exploration et l'indexation.

Le protocole d'exclusion des robots est la façon dont ce contrôle est mis en œuvre, via le fichier robots.txt et les balises méta ou les en-têtes sur la page Web elle-même. Ces moteurs de recherche obéissent volontairement au protocole d'exclusion des robots, prenant la mise en œuvre du protocole par un site Web comme une directive, une commande absolue, et pas seulement un simple indice.

Il est important de noter que la position par défaut du protocole est que toutes les explorations et indexations sont autorisées - il est permissif par défaut. À moins que l'exploitant du site Web ne prenne activement des mesures pour mettre en œuvre l'exclusion, le site Web est réputé permettre l'exploration et l'indexation.

Cela nous donne le cadre de base de l'accord entre les moteurs de recherche et les sites Web : par défaut, un site Web sera exploré et indexé par un moteur de recherche, qui, à son tour, dirigera les internautes directement vers le site Web d'origine dans leurs résultats de recherche pour les requêtes pertinentes. .

Cet accord est fondamentalement un échange économique : les coûts de production, d'hébergement et de diffusion du contenu sont supportés par le site Web, mais l'idée est que le trafic qu'il obtient en retour le rembourse avec un bénéfice.

Remarque : J'ignore intentionnellement toute une série d'arguments connexes ici, sur qui a plus de pouvoir dans cet échange, qui gagne plus d'argent, l'équité, et bien plus encore. Je ne les minimise pas - je ne veux tout simplement pas détourner l'attention du sujet central de cet article.

Cette approche d'indexation du trafic apparaît ailleurs, par exemple lorsque les moteurs de recherche sont autorisés à indexer le contenu derrière un paywall. C'est la même idée : le site Web partage du contenu en échange de son affichage dans les résultats de recherche qui redirigent directement les internautes vers le site Web.

Et à chaque étape du processus de cet accord, si l'éditeur souhaite bloquer tout ou partie de l'exploration ou de l'indexation de quelque manière que ce soit, alors l'éditeur dispose de plusieurs outils utilisant le protocole Robots and Exclusion Protocol. Tout ce qui est encore autorisé à être exploré et indexé est dû au fait que le site Web tire un avantage direct de son affichage dans les résultats de recherche.

Cet argument sous une forme ou une autre a en fait été utilisé devant les tribunaux, dans ce qui est devenu connu sous le nom de "défense robots.txt" et a été essentiellement retenu ; voir cette courte liste d'affaires judiciaires, dont beaucoup impliquent Google, et cet article de 2007 qui n'en est pas entièrement satisfait.

Les LLM ne sont pas des moteurs de recherche

Il devrait maintenant être très clair qu'un LLM est une bête différente d'un moteur de recherche.

La réponse d'un modèle linguistique ne renvoie pas directement au(x) site(s) Web dont le contenu a été utilisé pour former le modèle. Il n'y a pas d'échange économique comme on le voit avec les moteurs de recherche, et c'est pourquoi de nombreux éditeurs (et auteurs) sont mécontents.

Le manque de citations de sources directes est la différence fondamentale entre un moteur de recherche et un LLM, et c'est la réponse à la question très courante de "pourquoi Google et Bing devraient-ils être autorisés à récupérer du contenu mais pas OpenAI?" (J'utilise une formulation plus polie de cette question.).

Google et Bing essaient d'afficher des liens sources dans leurs réponses génératives d'IA, mais ces sources, si elles sont affichées, ne sont pas l'ensemble complet.

Cela ouvre une question connexe : pourquoi un site Web devrait-il autoriser l'utilisation de son contenu pour former un modèle de langage s'il n'obtient rien en retour ?

C'est une très bonne question – et probablement la plus importante à laquelle nous devrions répondre en tant que société.

Les LLM présentent des avantages malgré les lacunes majeures de la génération actuelle de LLM (telles que les hallucinations, le mensonge aux opérateurs humains et les préjugés, pour n'en nommer que quelques-uns), et ces avantages ne feront qu'augmenter avec le temps pendant que les lacunes seront résolues.

Mais pour cette discussion, le point important est de réaliser qu'un pilier fondamental du fonctionnement actuel du Web ouvert n'est pas adapté aux LLM.

La sordide

Ce n'est apparemment pas un problème pour les entreprises d'IA qui ne souhaitent former de grands modèles que pour leur propre bénéfice économique.

OpenAI a utilisé plusieurs ensembles de données comme entrées de données de formation (détails ici pour GPT3), et OpenAI ne divulgue intentionnellement pas les ensembles de données de formation pour GPT4.

Bien qu'OpenAI utilise de nombreux arguments pour justifier de ne pas divulguer d'informations sur les données d'entraînement de GPT4 (abordées ici), le point clé pour nous demeure : nous ne savons pas quel contenu a été utilisé pour l'entraîner, et OpenAI ne le montre pas dans les réponses de ChatGPT.

La collecte de données d'OpenAI obéit-elle au protocole d'exclusion des robots ? Inclut-il du texte protégé par des droits d'auteur, comme des manuels ou d'autres livres ? Ont-ils obtenu la permission d'un site Web ou d'un éditeur ? Ils ne disent pas.

L'approche super ombragée de Brave Software

Si l'approche d'OpenAI est problématique, Brave Software (le fabricant du navigateur Brave et du moteur de recherche Brave) adopte une approche et une position encore plus problématiques en ce qui concerne les données de recherche et de formation à l'IA.

Le moteur de recherche Brave dépend fortement de ce qu'on appelle le projet de découverte Web. L'approche est assez élaborée et documentée ici, mais je soulignerai un fait clé : Brave ne semble pas avoir de crawler centralisé qu'il exploite, et aucun des crawls ne s'identifie comme des crawlers pour Brave, et (assoyez-vous pour cela) Brave vend le contenu scrapé avec des droits que Brave accorde à l'acheteur pour la formation à l'IA.

Il y a beaucoup dans cette phrase, alors analysons-la.

La recherche Brave utilise le navigateur Brave comme un robot d'exploration distribué. Comme documenté dans cet article d'aide, il y a cette question et réponse de la FAQ :

Le projet de découverte Web est-il un robot ?

D'une certaine manière, oui. Le projet de découverte Web traite les tâches de récupération du robot d'exploration Web de Brave. Toutes les quelques secondes ou minutes, le navigateur peut être invité à récupérer une page Web et à renvoyer le code HTML à Brave . Cependant, cette récupération n'a aucun impact sur votre historique de navigation ou sur les cookies. Elle s'effectue sous la forme d'un appel d'API de récupération privée. Pour plus de sécurité, les domaines de travail de récupération sont présélectionnés à partir d'un petit ensemble de domaines inoffensifs et réputés.

Qu'est-ce que le projet de découverte Web ? - Recherche courageuse

L'API Fetch est une fonctionnalité Web standard intégrée aux moteurs de navigateur modernes, y compris celui utilisé par Brave. Son utilisation courante consiste à récupérer du contenu à montrer aux utilisateurs dans le navigateur. Pour nos besoins, nous savons immédiatement qu'il s'agit du navigateur d'un utilisateur qui demande le contenu du site Web au nom du moteur de recherche de Brave.

Fait intéressant, un fil Reddit de juin 2021 ajoute plus de détails et de confusion. Une réponse d'un représentant de Brave est très intéressante (met en évidence la mienne):

Nous avons notre propre robot d'exploration, mais il ne contient pas de chaîne d'agent utilisateur (tout comme Brave, le navigateur, ne contient pas non plus de chaîne d'agent utilisateur unique ) pour éviter toute discrimination potentielle. Cela dit, nous avons parlé de la possibilité d'identifier le crawler aux administrateurs qui voudraient savoir quand/où il atterrit sur leurs propriétés. Nous respectons également robots.txt , donc si vous ne voulez pas que Brave Search explore votre site, ce ne sera pas le cas.

C'est une mine d'or de faits :

1. Ils ont leur propre robot d'exploration, qui peut faire référence à un robot centralisé ou au projet Web Discovery basé sur un navigateur distribué.
2. Ce crawler ne s'identifie pas comme un crawler, mais il obéit en quelque sorte au protocole d'exclusion des robots (sous la forme du fichier robots.txt). Comment un opérateur de site Web peut-il rédiger une directive d'exclusion des robots si le navigateur ne s'identifie pas ? Quel jeton d'agent utilisateur (comme on l'appelle) serait utilisé dans le fichier robots.txt pour spécifier des directives spécifiques au robot d'exploration de Brave ? Je n'ai trouvé aucune documentation de Brave.
3. Ce qu'ils appellent la discrimination est en fait la façon dont les éditeurs contrôlent l'exploration. Le protocole d'exclusion des robots est un mécanisme permettant aux éditeurs de faire la distinction entre ce à quoi les utilisateurs et les robots d'exploration sont autorisés à accéder, et de faire la distinction entre différents robots d'exploration (par exemple, autoriser Bingbot à explorer mais pas Googlebot). En prétendant qu'ils veulent éviter la discrimination, Brave dit en fait qu'ils décident de ce qu'ils explorent et indexent, pas l'éditeur.

Pour en revenir à l'API Fetch : par défaut, l'API Fetch utilise la chaîne d'agent utilisateur du navigateur. Nous savons déjà que le navigateur Brave ne s'identifie pas avec un en-tête d'agent utilisateur unique, utilisant à la place la chaîne générique d'agent utilisateur produite par le moteur de navigateur sous-jacent.

La chaîne de l'agent utilisateur peut être personnalisée, pour le navigateur en général et l'API Fetch, mais je n'ai trouvé aucune indication que Brave le fasse (et en effet, la réponse Reddit citée ci-dessus indique explicitement qu'il n'y a pas d'identifiant unique).

De plus, Brave continue de vendre les données extraites spécifiquement pour la formation à l'IA, et pas seulement comme résultats de recherche (par exemple, pour alimenter une fonction de recherche de site).

La visite de la page d'accueil de l'API Brave Search montre plusieurs niveaux de prix, dont certains appelés "Données pour l'IA". Ces forfaits de données incluent des options pour les « données avec droits de stockage » qui permettent à l'abonné de « mettre en cache/stocker des données pour former des modèles d'IA », les données comprenant des « extraits alternatifs supplémentaires pour l'IA » et des « droits d'utilisation des données pour l'inférence de l'IA ». ”

En résumé, sur la base des déclarations publiques de Brave et du manque de documentation, Brave explore le Web de manière furtive, sans moyen évident de le contrôler ou de le bloquer, et continue à revendre le contenu analysé pour la formation à l'IA.

Ou pour reformuler cela plus crûment, Brave s'est nommé distributeur à but lucratif de contenu protégé par le droit d'auteur sans licence ni autorisation des éditeurs de sites Web .

Est-ce acceptable ? Je le vois comme un grattoir sordide en tant que service.

Initiative de contrôle des éditeurs de Google

Il pourrait y avoir un nouveau type de robot d'exploration Web à venir, un spécifiquement pour l'IA générative.

Il semble que Google ait reconnu l'incompatibilité discutée ci-dessus, à savoir que l'utilisation du contenu récupéré par Googlebot pour la recherche sur le Web peut ne pas convenir à la formation de modèles d'IA.

Google a annoncé qu'il souhaitait lancer une discussion communautaire pour créer des contrôles AI Web Publisher (hé, Google, je me suis inscrit, laissez-moi entrer s'il vous plaît !). Je soutiens de tout cœur cette conversation, et bravo Google pour avoir ouvert la porte à cette conversation.

Comme nous en sommes aux premiers jours, il est important de signaler que les défauts et les capacités de ces contrôles seront essentiels à leur succès ou à leur échec. Je soupçonne que de nombreux éditeurs et auteurs auront des opinions bien arrêtées sur le fonctionnement de ces contrôles de l'IA.

Qu'en est-il des LLM open source ?

Un aspect important de l'argument ci-dessus est l'échange économique. Mais que se passe-t-il si l'organisation derrière le modèle de langage publie le modèle librement sans en tirer profit ?

Il existe de nombreux modèles open source de ce type, et ils sont formés sur des ensembles de données qui chevauchent considérablement les ensembles de données utilisés pour former des modèles propriétaires commerciaux. De nombreux modèles open source sont actuellement assez bons pour certains cas d'utilisation, et ils ne font que s'améliorer.

Pourtant : est-il juste que le contenu d'un site Web soit utilisé sans autorisation pour former un LLM open source ?

C'est peut-être une question plus délicate, et je pense que la réponse repose actuellement sur ce que le protocole d'exclusion des robots permet. Il est possible qu'une meilleure réponse émerge sous la forme d'une approche bien conçue des contrôles AI Web Publisher de Google ou d'une autre initiative similaire.

Surveillez cet endroit.

Alors, que peut faire un éditeur maintenant ?

Cette situation actuelle est une situation que de nombreux éditeurs ne veulent ni n'acceptent. Que peuvent-ils faire?

Ici, nous devons revenir au blocage des crawlers/bots à l'ancienne. Il existe généralement deux types de crawlers :

1. Crawlers qui s'identifient. Ils peuvent ou non obéir au protocole d'exclusion des robots, mais au moins le serveur a un identifiant à vérifier pour décider de bloquer ou non la requête. Les exemples incluent Googlebot et Bingbot.
2. Les robots furtifs, qui ne sont pas utilisés pour les moteurs de recherche polis. Ils ne s'identifient pas et/ou n'obéissent pas au protocole d'exclusion des robots. Les exemples sont le grattoir de spam de n'importe quel script kiddie ou le robot d'exploration de Brave Search.

Il y a deux choses complémentaires que vous pouvez faire :

1. Si le robot d'exploration obéit au protocole d'exclusion des robots, vous pouvez le bloquer si vous pensez que le contenu qu'il explore alimente les données d'entraînement de l'IA. Il y a deux approches ici :
   • Bloquez tous les robots d'exploration et n'autorisez que ceux que vous souhaitez autoriser pour vos besoins (comme Googlebot et Bingbot). Ceci est dangereux pour les performances d'un site Web dans la recherche organique. Vous devez être extrêmement prudent avec cela, mais il est efficace pour ces robots.
   • Autorisez toutes les explorations et bloquez celles que vous souhaitez bloquer. Cette approche plus permissive est moins dangereuse, mais bien sûr, votre contenu peut être récupéré par l'IA ou d'autres crawlers que vous ne souhaitez peut-être pas.
2. Utilisez un détecteur de bot furtif côté serveur et utilisez-le pour bloquer ces robots. De nombreux produits peuvent le faire. Si vous utilisez un réseau de distribution de contenu (CDN) comme le font de nombreux éditeurs, il est probable que ce type de fonctionnalité soit disponible via celui-ci (par exemple, Akamai, Cloudflare, Fastly).

L'approche que je commence à adopter avec les sites Web que j'exploite et dont je discute avec les clients est une combinaison des options (1a) et (2), à savoir utiliser un fichier robots.txt restrictif avec des contrôles CDN.

Ce n'est peut-être pas la meilleure approche pour chaque éditeur, mais je pense que cela vaut la peine d'être sérieusement envisagé.

Qu'est-ce que tout cela signifie?

Nous vivons une époque qui restera comme l'une des plus influentes de l'histoire. Les gens prédisent littéralement le destin de l'humanité à partir de l'IA. Nous avons tous un rôle à jouer pour façonner l'avenir.

Pour notre part en tant que créateurs de contenu original, nous devons réfléchir à la manière de réagir, de suivre et de nous adapter à cette partie de l'industrie en évolution rapide. Décider comment le contenu que nous créons est créé, distribué et consommé est désormais un mélange complexe de stratégie, de technologie, de finances, d'éthique et plus encore.

Quelle que soit votre réponse, vous prenez position à un moment historique. Je sens ton fardeau.