Chaque modèle est un pari sur ses données. Que vous pré-entraîniez de zéro, affiniez sur un domaine, assembliez un corpus de récupération, ou construisiez un jeu d’évaluation, la qualité et l’ampleur de ce que vous collectez du web posent un plafond à ce que le modèle peut faire. Et collecter des données web à l’échelle dont un modèle a besoin, à travers des millions de pages et de nombreuses régions, se heurte aux mêmes problèmes d’infrastructure que rencontre tout gros crawler : limites de débit par IP, contenu qui varie selon la géographie, et sites qui bloquent de plus en plus tout ce qui ressemble à un crawler automatisé. Les proxys résidentiels sont la couche de collecte qui rend ce crawl possible, et voici où ils s’insèrent, avec les parties du travail qu’ils ne résolvent pas, qui pour les données d’IA comptent plus que d’habitude.
Ce que les équipes d’IA collectent vraiment
La forme de la collecte varie avec l’objectif. Les corpus de pré-entraînement et de pré-entraînement continué sont des extractions de texte larges et à haut volume à travers une portion large du web public. Le fine-tuning de domaine est plus étroit et plus profond, un crawl ciblé des sites qui comptent pour une tâche. Les corpus de récupération pour un système RAG sont curés et rafraîchis selon un calendrier pour que l’index ne devienne pas obsolète. Les jeux d’évaluation et de benchmark sont plus petits mais doivent être représentatifs et propres. Le travail multimodal ajoute des images et d’autres actifs par-dessus le texte. Ce que tous partagent, c’est une couche de collecte en dessous : récupérer beaucoup de pages publiques, de façon fiable, depuis là où elles vivent réellement. Cette couche est la même quoi qu’il repose dessus, et c’est le sujet du reste de cet article.
Échelle : pourquoi une seule IP ne peut pas crawler le web
Le web ne veut pas d’une seule adresse tirant des millions de pages. La plupart des sites appliquent des limites de débit par IP, et un crawler qui envoie tout depuis un seul endroit est limité en quelques minutes, puis bloqué, et le crawl s’arrête bien en dessous du volume dont un modèle a besoin. Même là où les limites sont généreuses, une seule connexion est un goulot d’étranglement face à un corpus mesuré en millions de documents.
Répartir le crawl sur de nombreuses IP résidentielles est ce qui transforme un mince filet en un corpus. Chaque IP reste confortablement dans sa propre limite par IP tandis que votre débit agrégé passe à l’échelle avec le pool, ce qui est la logique d’équilibrage de charge sur laquelle s’appuie tout collecteur à haut volume, et c’est à quoi servent les connexions concurrentes illimitées. Le but n’est pas d’écraser un site individuel, c’est de répartir un crawl large et poli sur assez d’adresses pour qu’aucune cible donnée ne voie plus qu’une quantité ordinaire de trafic depuis chacune d’elles.
Représentativité : un corpus n’est aussi large que l’endroit d’où vous collectez
Voici la partie spécifique aux données d’entraînement et facile à rater. Un modèle apprend la distribution de ce qu’on lui a donné, donc un corpus collecté entièrement depuis un seul emplacement hérite de la portion du web de cet emplacement. Beaucoup de sites servent un contenu différent selon la région : pages localisées, langues différentes, catalogues, prix et disponibilité spécifiques à la région, et parfois des pages d’accueil entièrement différentes. Crawlez le web depuis un seul pays et vous sous-échantillonnez systématiquement tout ce que ce pays ne voit pas, et ce biais est cuit dans le modèle.
Le ciblage par pays et, quand cela compte, au niveau ville vous laisse collecter les versions de pages que voient les utilisateurs réels dans chaque région, de sorte que votre corpus reflète l’étendue géographique et linguistique que vous voulez vraiment plutôt que l’accident de l’endroit où tourne votre crawler. Si la couverture multilingue ou l’équilibre régional est un objectif, ce n’est pas un luxe, c’est la différence entre un jeu de données représentatif et un jeu déséquilibré. Le même ciblage géographique qui atteint un contenu variant par région de façon légitime est la façon dont vous bâtissez l’ampleur dans les données dès le départ.
Rester accessible tandis que les sites se durcissent contre les crawlers
Les sites sont devenus nettement plus défensifs face à la collecte automatisée, et une bonne part de ce durcissement vise droit les crawlers d’IA. Les plages d’IP de datacenter connues et les signaux de bot évidents sont bloqués vite, et certains des plus grands sites défient ou refusent désormais le trafic qui ne ressemble pas à un visiteur humain ordinaire. Un crawl qui tourne depuis des adresses de datacenter renvoie de plus en plus des blocages et des pages de challenge au lieu du contenu.
Les proxys résidentiels acheminent les requêtes à travers de vraies IP de niveau domestique, donc chaque requête ressemble à un visiteur normal plutôt qu’à un serveur dans un datacenter, et les adresses propres avec une bonne réputation passent là où les signalées se font défier. C’est nécessaire mais pas suffisant : l’IP vous amène à la porte, et le reste consiste à vous comporter comme un vrai client, ce qui veut dire des débits de requête sensés, une gestion honnête des signaux qui déclenchent les blocages, et ne pas marteler une cible juste parce que vous le pouvez. Le but est de collecter des données publiques comme le ferait un navigateur, pas de forcer le passage face à un site qui a décidé qu’il ne voulait pas être crawlé.
Fraîcheur : les corpus deviennent périmés
Un jeu de données est un instantané, et le web bouge. Les corpus de récupération surtout ont besoin de crawls de rafraîchissement réguliers pour que l’index reflète l’état actuel de ses sources, et le pré-entraînement continué dépend de faire entrer ce qui est nouveau. Cela fait de la collecte un pipeline continu plutôt qu’un travail ponctuel, et un pipeline continu doit survivre aux routes qui se dégradent avec le temps. Détectez un blocage, un timeout, ou un challenge sur une IP donnée, retirez cette route, et continuez sur une nouvelle, ce qui est le schéma de failover qui garde en vie un crawl de longue durée. Rien de tout cela ne devrait tourner à l’aveugle, alors surveillez le pipeline : le taux de succès, la couverture, et les schémas d’erreur par source vous disent quand une cible a changé ses défenses ou qu’une portion du crawl échoue en silence, avant que ce trou n’apparaisse comme des données manquantes dans le prochain cycle d’entraînement.
Collectez de façon responsable
La partie honnête, et pour les données d’IA elle n’est pas optionnelle. Les proxys résidentiels sont de l’infrastructure de collecte, ils ne sont pas une permission. Construire un corpus de façon responsable signifie collecter uniquement des données publiques, respecter les directives robots et les conditions de service de chaque site, et crawler poliment, avec des limites de débit et du backoff pour ne jamais dégrader les sites dont vous dépendez. Tout aussi important, et distinct de la question de savoir si vous pouvez techniquement récupérer une page, il y a la question des droits : la capacité de collecter des données n’est pas la même chose que le droit de s’entraîner dessus, et le droit d’auteur, la licence, et les règles sur les données personnelles sont de vraies contraintes qui se situent au-dessus de la couche de collecte et qu’il revient à l’équipe de bien gérer. Traitez les données personnelles et sensibles avec soin et dans le cadre de la loi. Les proxys résolvent le comment d’atteindre des pages publiques à l’échelle, le quoi et le droit sont des décisions que vous possédez toujours, et les prendre au sérieux est ce qui sépare un jeu de données défendable d’un passif.
Un crawl poli minimal
Un proxy résidentiel rotatif ressemble à un proxy ordinaire pour votre crawler. Le ciblage vit dans le nom d’utilisateur sur le gateway, donc une sortie US sans identifiant de session tourne par requête, répartissant le crawl à travers le pool :
import timeimport requests
PROXY = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"proxies = {"http": PROXY, "https": PROXY}
def fetch(url): r = requests.get(url, proxies=proxies, timeout=20, headers={"User-Agent": "research-crawler/1.0"}) r.raise_for_status() return r.text
for url in urls: # your queue of public pages try: html = fetch(url) store(html) # persist for the corpus except requests.HTTPError: retry_later(url) # on a block or timeout, back off and requeue time.sleep(1.0) # be polite; do not hammer a single originRépartissez la file pour qu’aucun site ne voie une rafale depuis une IP, faites du backoff face aux erreurs plutôt que de réessayer fort, et pour une couverture multilingue ou régionale, exécutez le même crawl avec différentes cibles de pays. Les schémas généraux de client se reportent depuis le guide pour utiliser les proxys résidentiels avec Python, et là où un corpus a besoin de récupérations multi-pages cohérentes en session, une session sticky maintient une IP pour cette séquence.
En résumé
Collecter des données web pour l’entraînement d’IA et de LLM est borné par trois choses : l’échelle dont un modèle a besoin, qu’une seule IP ne peut atteindre ; la représentativité qu’un bon corpus exige, qu’un seul emplacement ne peut capturer ; et le mur montant des défenses anti-crawler, que les adresses de datacenter peuvent de moins en moins franchir. Les proxys résidentiels répondent aux trois. Répartissez le crawl sur un grand pool pour que chaque IP reste polie et que l’agrégat passe à l’échelle, ciblez des pays et des villes pour que le corpus reflète la géographie et les langues que vous voulez vraiment, acheminez à travers des IP propres de niveau domestique pour que les requêtes ressemblent à des visiteurs ordinaires, et faites du failover avec surveillance pour qu’un crawl de rafraîchissement continu continue de tourner. Puis faites la partie que les proxys ne font pas : collectez uniquement des données publiques, respectez robots et conditions, crawlez poliment, et gardez la licence et la vie privée au-dessus de la couche de collecte, là où elles doivent être.
Cette couche de collecte est ce à quoi servent les proxys résidentiels, un grand pool d’IP réelles de niveau domestique avec ciblage par pays et ville et sessions sticky quand une séquence en a besoin. La tarification au Go signifie que vous payez pour les données que vous tirez réellement, ce qui convient à une charge de travail qui va d’un crawl de domaine ciblé à un corpus mesuré en millions de pages.