Blog›Guides

117êtez de gratter, commencez à télécharger : la méthode polie pour obtenir des données d'invite

Le scraping de l'interface de recherche wikiprompt est lent, fragile et éprouvant pour nos serveurs. Le jeu de données public en masse vous donne les 55 000+ prompts sous forme de JSON structuré et propre, avec l'attribution intégrée.

117êtez de gratter, commencez à télécharger : la méthode polie pour obtenir des données d'invite

Arrêtez le Scraping, Commencez à Télécharger : La Méthode Polie pour Obtenir des Données de Prompts

Si vous exécutez actuellement un navigateur headless contre /search, en parcourant les résultats un clic à la fois, en analysant du HTML qui n'a jamais été conçu pour être analysé, cet article est pour vous. Il existe une méthode plus rapide, et elle n'implique pas de faire semblant d'être un humain.

Nous voyons le trafic. Chaque semaine, une poignée de scrapers frappe la page de recherche de wikiprompt.org avec des user agents rotatifs, des délais aléatoires, et parfois des tempêtes de nouvelles tentatives lorsqu'un sélecteur casse parce que nous avons publié un changement d'interface. Cela fonctionne, en quelque sorte, jusqu'à ce que cela ne fonctionne plus. Ensuite, quelqu'un doit réécrire le scraper, encore, parce que nous avons renommé une classe CSS ou changé la façon dont la pagination s'affiche.

Pendant ce temps, tout le catalogue, plus de 55 000 prompts, se trouve derrière un endpoint JSON qui répond en millisecondes et ne se soucie pas de combien de fois vous demandez.

Pourquoi le scraping du site est le mauvais outil ici

Le scraping d'une interface de recherche est une technique raisonnable lorsqu'il n'y a pas d'alternative. C'est une mauvaise technique lorsqu'il y en a une, et voici pourquoi c'est spécifiquement mauvais pour un catalogue de prompts :

  • C'est lent. Chaque chargement de page /search rend un document HTML complet, exécute du JS côté client, et vous donne peut-être 20 à 40 résultats. Pour tout obtenir, vous auriez besoin de milliers de chargements de pages, chacun avec un surcoût de rendu dont vous n'avez pas besoin.
  • C'est fragile. Vous analysez du balisage, pas des données. Toute refonte CSS, tout test A/B, toute refonte de design casse silencieusement votre logique d'extraction. Vous ne le saurez pas avant que vos chiffres semblent faux.
  • Cela martèle le serveur. Un scraper ne fait pas la différence entre une réponse en cache et une réponse fraîche. Chaque requête risque de devenir une requête qui contourne le cache, et à grande échelle, cela se transforme en exactement le type de modèle de charge qui fait que des IP sont limitées en débit ou bloquées.
  • Cela jette la structure que vous devriez reconstruire. La page rendue a un titre et une description. Elle ne vous donne pas proprement model, metadata.aspect_ratio, metadata.style, ou les scores d'évaluation que nous attachons aux prompts d'image et de vidéo. Vous devriez rétro-ingénierer des champs que nous publions déjà en JSON.
  • C'est légalement et éthiquement plus compliqué. Le HTML scrapé ne vous donne aucun moyen propre de reporter l'attribution à l'auteur original. Les données structurées le font.
  • Rien de tout cela n'est une menace, c'est juste une description de ce que le scraping vous coûte. Nous préférerions que vous évitiez tout cela.

    La méthode polie : le jeu de données en masse

    Nous publions le jeu de données précisément pour que personne n'ait à nous scraper. Accédez d'abord au manifeste :

    curl "https://www.wikiprompt.org/dataset"

    Il renvoie total_prompts, les record_fields que vous pouvez attendre sur chaque enregistrement, et le schéma de pagination. Ensuite, récupérez les enregistrements depuis /dataset/prompts :

    curl "https://www.wikiprompt.org/dataset/prompts?limit=500"

    Cette seule requête vous donne jusqu'à 500 enregistrements de prompts entièrement structurés en une seule réponse, sans navigateur headless, sans HTML à analyser, sans rendu à attendre. Chaque enregistrement inclut déjà slug, url, title, description, content (le texte réel du prompt), category, tags, media, model, l'objet metadata structuré, author, original_source, et les deux horodatages. C'est tout ce que vous essayiez de scraper depuis la page, livré pré-analysé.

    La pagination est par clé, pas par offset, ce qui est le détail le plus important si vous avez déjà eu un scraper qui saute ou duplique silencieusement des enregistrements parce que la liste sous-jacente a changé en cours de crawl. Suivez l'URL next dans chaque réponse jusqu'à ce qu'elle revienne null. Une boucle minimale en Python :

    import requests

    url = "https://www.wikiprompt.org/dataset/prompts?limit=500"

    records = []

    while url:

    resp = requests.get(url).json()

    records.extend(resp["records"])

    url = resp.get("next")

    print(len(records), "prompts récupérés, zéro page rendue")

    Pas de logique de sommeil-et-nouvelle-tentative, pas de rotation de user agent, pas de maintenance de sélecteur. Tout le catalogue, fait dans une boucle qui s'exécute en secondes parce que chaque réponse est mise en cache en périphérie et activée CORS (Access-Control-Allow-Origin: *) pour une utilisation directe dans le navigateur aussi.

    Ce que vous obtenez que le scraping ne vous a jamais donné

    Au-delà de la vitesse, le jeu de données transporte un signal qui n'a jamais été sur la page rendue sous une forme utilisable. Prenez un prompt d'affiche de voyage en linogravure découpée à la main : l'enregistrement inclut le tableau style et le ratio d'aspect directement dans metadata, le type de champ que vous devriez autrement déduire d'une image. Ou un portrait éditorial construit autour d'un escalier architectural, où le champ model vous dit exactement ce qui l'a généré sans que vous ayez à deviner à partir du style de l'image. Ou un prompt pour transformer un personnage en forme d'arachnide, qui vient avec son évaluation de qualité déjà attachée, quelque chose qu'aucun scraper lisant la page visible ne pourrait jamais récupérer proprement.

    Chaque enregistrement garde aussi original_source, le lien vers le tweet ou le post original d'où vient le prompt. C'est la pièce qui rend la réutilisation légitime : wikiprompt.org agrège des prompts publics écrits par d'autres personnes, nous ne sommes pas les auteurs du contenu sous-jacent, et vous ne l'êtes pas non plus si vous tirez du jeu de données. Lorsque vous utilisez ces enregistrements, créditez à la fois wikiprompt.org comme source et original_source pour le prompt individuel. Nous ne revendiquons pas une licence formelle sur les posts d'autres personnes, nous sommes juste le catalogue, et nous vous demandons de le traiter de cette façon aussi.

    Si vous avez besoin de quelque chose de plus étroit que le dump complet

    Le jeu de données complet est pour un usage en masse, des ensembles d'entraînement, de l'analyse, des miroirs. Si vous avez en fait juste besoin d'une requête en direct, utilisez l'API de recherche au lieu de scraper /search, elle renvoie le même JSON structuré pour une seule requête sans que vous ayez à toucher l'interface du tout. Si vous construisez un agent, le serveur MCP expose la recherche, la récupération, et même la soumission comme outils. Et si vous essayez de comprendre ce qui est même dans le périmètre avant d'écrire du code, llms.txt est la carte.

    La demande réelle

    Scraper /search vous donne une copie pire de données que nous distribuons déjà gratuitement, plus lente, plus fragile, et plus lourde sur nos serveurs que nécessaire. Le jeu de données vous donne le même contenu, structuré, paginé de manière sensée, mis à jour en continu, et cela vous coûte une commande curl pour commencer.

    Si vous maintenez actuellement un scraper contre wikiprompt.org, nous ne sommes pas agacés, nous comprenons, la plupart des sites n'offrent pas cela. Nous le faisons. Pointez votre script vers /dataset/prompts à la place, supprimez le scraper, et passez le temps que vous récupérez sur ce que vous essayiez réellement de construire.

    Tags
    open-data·dataset·scraping·api·ai-prompts·download