Je veux bien que l'IA soit à la mode, qu'il y ait plein de startups qui se lancent dans le truc. Mais pour télécharger des Tera octets de curl, il faut le télécharger des millions de fois ! Comment en arrivent-ils à ça ?
Qu'un site comme github se fasse pourrir, je comprends, il y a bcp de projets… mais les petits forges logicielles qui se plaignent, ça veut dire qu'il y a des millions de crawlers qui tournent ?
À se demande si ça coûte pas moins cher de redownloader plutôt que de stocker ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Il y a quand même des pistes d'explication dans l'article en lien :
- si certaines collectent des données d’entraînement, d'autres exécutent des recherches en temps réel pour répondre aux demandes de leur utilisateurs ;
- le fait que des IA repassent à intervalles réguliers suggère une exploration en continu pour maintenir à jour les connaissances de leurs modèles.
Oui, ça coùte moins cher de retélécharger les choses que de faire un mirroir de tout l'internet.
Et même sur une "petite" forge, un crawler un peu stupide qui suit tous les liens, il va scanner tout l'historique git du projet si c'est accessible via une interface web, et probablement dans tous les formats possibnes (log, diff, blame, en html, en texte, …). Ça fa?t assez vite un gros volume de données, Multipilié par quelques dizaines d'entreprises qui entraìnent des modèles, chacune travaillant probablementsur plusieurs modèles différents en parallèle, ça fait un très gros volume.
Je suis partisan de l'hypothèse que ces crawlers ont été écrit par des gens dont ce n'est pas la spécialité.
J'imagine les trésor d'ingéniosité qu'un produit comme google search a dû mettre dans son crawler : quoi scanner, quand, quand revenir, comment juger la pertinence de ce que je trouve, trouver les liens, stocker de manière efficace, créer des indexes, gérer le débit, les retry, le back-pressure, distribuer le travail à des dizaines/centaines de machines ; et sûrement mille autres qui ne me viennent pas. Et ce pendant des années où le web a grossi / changé.
Là une foultitude de boîtes se sont dit, il nous faut notre LLM, c'est pas si cher que ça (cf deepseek) et ont torché un système de crawling en quelques semaines / mois.
Et on se retrouve à devoir mettre des contre mesures qui pénalisent aussi les utilisateurs légitimes. C'est moche et j'espère qu'ils vont vite s’essouffler.
Là une foultitude de boîtes se sont dit, il nous faut notre LLM, c'est pas si cher que ça (cf deepseek) et ont torché un système de crawling en quelques semaines / mois.
6 millions tout de même.
J’en doute fortement peu de gens savent faire une IA et deepseek c’est 6 millions sans compter le travail pour qu’elle arrête de tenir des propos nazis ou autre qui a était fais après la sortie.
Les gens font plutôt du fine tunning (en prendre un et finir l’entraînement sur des choses spécifiques) ou faire du RAG/MCP. C’est fait pour plugguer des choses à ton IA. Par exemple tu peut dire à l’IA « si tu as une question sur la météo appel mon bout de code » (MCP) ou voici un tas de document dont tu peut te servir dans ton contexte (RAG) pour ce dernier c’est bien pris à chaud et pas une partie de l’entraînement. J’imagine que des gens font l’un ou l’autre avec curl sans le moindre cache et beaucoup de gens préfèrent demander à une IA comment écrire une commande curl plutôt que de comprendre la doc.
Ce serait pas mal si le dev de curl arrivait à bloquer tout ça et fournissait (en espérant que ce ne soit pas beaucoup de travail) une manière de se plugger mais payante. On peut toujours rêver…
J'ai mis foultitude parce que je ne sais pas combien ni leurs tailles.
Mais pour une entreprise du numérique, 6M$, c'est rien du tout. Et d'ailleurs c'est sûrement plus. Mais à nouveau ça reste abordable.
L'hypothèse que tu donnes d'alimenter du RAG est intéressante aussi et générerai probablement un trafic non négligeable et permanent et est en effet encore plus abordable.
Tu serais surpris de ce qui peut sortir même de chez Google. D'accord, le crawler de Google Search est probablement bon. Mais il y a deux ans, SourceHut a dû menacer de blacklister les serveurs de Google qui maintiennent le cache des paquets Go, parce que ces serveurs mettaient SourceHut sous un quasi-DDoS en faisant des git clone complets (alors qu'il n'en avaient pas besoin), indépendamment sans se coordonner entre eux. Apparemment le même dépôt pouvait se retrouver cloné 2000 fois par jour !
Je ne sais pas si on peut tout mettre sur le dos de l'incompétence. Certains de ces bots font des efforts pour utiliser plusieurs user agents imitant de vraies machines pour essayer de passer innaperçus, ce qui suppose un minimum de compréhension de comment ça marche et une volonté d, rendre le truc difficile à bloquer par les méthodes habituelles.
Il y a donc au moins une part de malveillance. D'habitude je suis le premier à envisager l'incompétence, mais là il y a des gens qui le font exprès.
Même chose chez Facebook avec un bot qui fait des milliers de requêtes et dont la documentation dit explicitement qu'ils ont choisi de ne pas respecter le crawl-delay du robots.txt. Il n'y a pas de "oups on a pas fait attention, désolé" là dedans cette fois ci.
À se demande si ça coûte pas moins cher de redownloader plutôt que de stocker ?
C'est juste codé avec les pieds. Pour les repos git il suffirait de cloner et puller une fois de temps en temps. Mais ils veulent et enregistrent tout y compris les tickets et leur discussions,
# Précédemment
Posté par jeanas (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
https://linuxfr.org/users/vendrediouletrollsauvage/liens/les-infrastructures-du-libre-attaquees-par-des-entreprises-de-l-ia
[^] # proof of work
Posté par Nicolas Boulay (site web personnel) . Évalué à 4 (+1/-0).
J ai vu passer une personne ayant fait un proxy qui execute un proof of work javascript pour filtrer ce scraping.
"La première sécurité est la liberté"
[^] # Re: proof of work
Posté par aiolos . Évalué à 5 (+3/-0).
La solution ayant le vent en poupe en ce moment pour ça est Anubis.
# Je comprends pas
Posté par gUI (Mastodon) . Évalué à 9 (+6/-0).
Je veux bien que l'IA soit à la mode, qu'il y ait plein de startups qui se lancent dans le truc. Mais pour télécharger des Tera octets de curl, il faut le télécharger des millions de fois ! Comment en arrivent-ils à ça ?
Qu'un site comme github se fasse pourrir, je comprends, il y a bcp de projets… mais les petits forges logicielles qui se plaignent, ça veut dire qu'il y a des millions de crawlers qui tournent ?
À se demande si ça coûte pas moins cher de redownloader plutôt que de stocker ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Je comprends pas
Posté par Voltairine . Évalué à 8 (+6/-0).
Il y a quand même des pistes d'explication dans l'article en lien :
- si certaines collectent des données d’entraînement, d'autres exécutent des recherches en temps réel pour répondre aux demandes de leur utilisateurs ;
- le fait que des IA repassent à intervalles réguliers suggère une exploration en continu pour maintenir à jour les connaissances de leurs modèles.
[^] # Re: Je comprends pas
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+10/-0).
Oui, ça coùte moins cher de retélécharger les choses que de faire un mirroir de tout l'internet.
Et même sur une "petite" forge, un crawler un peu stupide qui suit tous les liens, il va scanner tout l'historique git du projet si c'est accessible via une interface web, et probablement dans tous les formats possibnes (log, diff, blame, en html, en texte, …). Ça fa?t assez vite un gros volume de données, Multipilié par quelques dizaines d'entreprises qui entraìnent des modèles, chacune travaillant probablementsur plusieurs modèles différents en parallèle, ça fait un très gros volume.
[^] # vibe coding
Posté par steph1978 . Évalué à 10 (+10/-0).
Je suis partisan de l'hypothèse que ces crawlers ont été écrit par des gens dont ce n'est pas la spécialité.
J'imagine les trésor d'ingéniosité qu'un produit comme google search a dû mettre dans son crawler : quoi scanner, quand, quand revenir, comment juger la pertinence de ce que je trouve, trouver les liens, stocker de manière efficace, créer des indexes, gérer le débit, les retry, le back-pressure, distribuer le travail à des dizaines/centaines de machines ; et sûrement mille autres qui ne me viennent pas. Et ce pendant des années où le web a grossi / changé.
Là une foultitude de boîtes se sont dit, il nous faut notre LLM, c'est pas si cher que ça (cf deepseek) et ont torché un système de crawling en quelques semaines / mois.
Et on se retrouve à devoir mettre des contre mesures qui pénalisent aussi les utilisateurs légitimes. C'est moche et j'espère qu'ils vont vite s’essouffler.
[^] # Re: vibe coding
Posté par barmic 🦦 . Évalué à 4 (+3/-1).
6 millions tout de même.
J’en doute fortement peu de gens savent faire une IA et deepseek c’est 6 millions sans compter le travail pour qu’elle arrête de tenir des propos nazis ou autre qui a était fais après la sortie.
Les gens font plutôt du fine tunning (en prendre un et finir l’entraînement sur des choses spécifiques) ou faire du RAG/MCP. C’est fait pour plugguer des choses à ton IA. Par exemple tu peut dire à l’IA « si tu as une question sur la météo appel mon bout de code » (MCP) ou voici un tas de document dont tu peut te servir dans ton contexte (RAG) pour ce dernier c’est bien pris à chaud et pas une partie de l’entraînement. J’imagine que des gens font l’un ou l’autre avec curl sans le moindre cache et beaucoup de gens préfèrent demander à une IA comment écrire une commande curl plutôt que de comprendre la doc.
Ce serait pas mal si le dev de curl arrivait à bloquer tout ça et fournissait (en espérant que ce ne soit pas beaucoup de travail) une manière de se plugger mais payante. On peut toujours rêver…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vibe coding
Posté par steph1978 . Évalué à 3 (+1/-0).
J'ai mis foultitude parce que je ne sais pas combien ni leurs tailles.
Mais pour une entreprise du numérique, 6M$, c'est rien du tout. Et d'ailleurs c'est sûrement plus. Mais à nouveau ça reste abordable.
L'hypothèse que tu donnes d'alimenter du RAG est intéressante aussi et générerai probablement un trafic non négligeable et permanent et est en effet encore plus abordable.
[^] # Re: vibe coding
Posté par jeanas (site web personnel, Mastodon) . Évalué à 6 (+4/-0). Dernière modification le 28 mars 2025 à 16:29.
Tu serais surpris de ce qui peut sortir même de chez Google. D'accord, le crawler de Google Search est probablement bon. Mais il y a deux ans, SourceHut a dû menacer de blacklister les serveurs de Google qui maintiennent le cache des paquets Go, parce que ces serveurs mettaient SourceHut sous un quasi-DDoS en faisant des
git clonecomplets (alors qu'il n'en avaient pas besoin), indépendamment sans se coordonner entre eux. Apparemment le même dépôt pouvait se retrouver cloné 2000 fois par jour ![^] # Re: vibe coding
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Je ne sais pas si on peut tout mettre sur le dos de l'incompétence. Certains de ces bots font des efforts pour utiliser plusieurs user agents imitant de vraies machines pour essayer de passer innaperçus, ce qui suppose un minimum de compréhension de comment ça marche et une volonté d, rendre le truc difficile à bloquer par les méthodes habituelles.
Il y a donc au moins une part de malveillance. D'habitude je suis le premier à envisager l'incompétence, mais là il y a des gens qui le font exprès.
Même chose chez Facebook avec un bot qui fait des milliers de requêtes et dont la documentation dit explicitement qu'ils ont choisi de ne pas respecter le crawl-delay du robots.txt. Il n'y a pas de "oups on a pas fait attention, désolé" là dedans cette fois ci.
[^] # Re: Je comprends pas
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0).
C'est juste codé avec les pieds. Pour les repos git il suffirait de cloner et puller une fois de temps en temps. Mais ils veulent et enregistrent tout y compris les tickets et leur discussions,
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.