Construire un jeu de données de fine-tuning à partir du web : des URL au JSONL

Un bon fine-tuning repose à 90 % sur le jeu de données. Voici le pipeline allant des URL brutes au JSONL propre — acquisition à grande échelle, déduplication, filtres de licence, et le format de chat que les formateurs attendent réellement.

Un fine-tuning n'est aussi bon que les données que vous lui fournissez, et la partie la plus difficile du fine-tuning n'est presque jamais l'entraînement lui-même — c'est la création d'un jeu de données propre. Le web est la source la plus riche de ces données, mais les pages brutes sont désordonnées, dupliquées, non étiquetées et légalement inégales. Ce guide est le pipeline allant des URL au JSONL prêt pour l'entraînement : combien de données vous avez réellement besoin, comment les acquérir à grande échelle, comment les nettoyer et les dédupliquer, comment gérer les licences, et comment les formater dans la structure de chat que les formateurs attendent. Il suppose que vous construisez un fine-tuning d'instructions ou de chat à partir de contenu web public.

De combien de données avez-vous réellement besoin ?

Commencez avec des objectifs réalistes pour ne pas sur- ou sous-construire. Le minimum pratique pour un fine-tuning qui produit des résultats raisonnables est d'environ 100 lignes ; pour une performance solide, vous voulez généralement plus de 1 000. Plus aide généralement, mais seulement si c'est propre — mille exemples bien étiquetés valent mieux que dix mille bruyants. Pour référence d'échelle, le jeu de données classique Alpaca comptait 52 000 paires instruction/réponse, générées en sollicitant un modèle plus fort. Et si vous utilisez un grand modèle pour générer des exemples synthétiques, alimentez-le avec au moins dix exemples écrits à la main pour qu'il apprenne la structure et le ton exacts que vous souhaitez avant qu'il n'en produise plus.

Acquisition : crawl vers un markdown propre

L'objectif à l'étape d'acquisition est le texte propre, pas le HTML brut. Une ligne de fine-tuning veut le fond d'une page — l'article, les docs, le Q&A — sans les barres de navigation, les bannières de cookies et le balisage publicitaire qui polluent un scraping naïf. Alors, explorez vos pages cibles et convertissez-les en markdown à l'ingestion, ce qui élimine le contenu générique tout en conservant la structure comme les titres et les listes. À tout volume réel, vous atteindrez des limites de taux et des blocages IP, alors routez le crawl à travers un pool rotatif. Une Scraper API qui renvoie directement du markdown fait les deux travaux — sortie propre et résistance au blocage — en un seul appel, c'est pourquoi nous le couvrons dans notre guide sur l'alimentation des LLMs avec des données web fraîches.

# Sketch: crawl target URLs to clean markdown, ready for shaping into rows.
import requests

API = "https://api.quantumproxies.io/scrape"   # returns markdown, handles rotation

def fetch_markdown(url):
    r = requests.get(API, params={"url": url, "format": "markdown"},
                     headers={"Authorization": "Bearer YOUR_KEY"}, timeout=60)
    return r.json()["markdown"]

docs = [fetch_markdown(u) for u in seed_urls]   # clean text, no boilerplate

Diagramme de pipeline des URL à un jeu de données de fine-tuning : source vers markdown propre, nettoyage et déduplication, formatage en messages JSONL, puis carte du jeu de données et division entraînement/évaluation — Le modèle ne voit jamais que votre jeu de données, donc chaque étape qui élimine les déchets améliore directement le fine-tuning.

Le format JSONL que les formateurs attendent

La plupart des outils de fine-tuning modernes par défaut utilisent un format JSONL conversationnel : un objet JSON par ligne, chacun avec un tableau messages de paires rôle/contenu, où les rôles sont system, user et assistant et les tours utilisateur/assistant alternent. C'est le format de chat que les formateurs de type Hugging Face et OpenAI ingèrent. Les anciens jeux de données d'instructions utilisent une forme à trois champs (instruction, input, output) — bien pour un tuning supervisé à tour unique — et des formats de conversation multi-tours existent aussi, mais ils se convertissent proprement dans la forme des messages. Choisissez un format cible et standardisez tout à celui-ci.

// One training example per line (.jsonl). Chat / messages format:
{"messages":[
  {"role":"system","content":"You classify support tickets by urgency."},
  {"role":"user","content":"My payment failed three times and the event is tomorrow."},
  {"role":"assistant","content":"high"}
]}
{"messages":[
  {"role":"system","content":"You classify support tickets by urgency."},
  {"role":"user","content":"How do I change my avatar?"},
  {"role":"assistant","content":"low"}
]}

Adaptez le format à l'objectif d'entraînement : texte brut pour le pré-entraînement continu, instruction-plus-sortie ou chat multi-tours pour le fine-tuning supervisé, réponses classées pour les méthodes basées sur les préférences. Si vous construisez un fine-tuning de raisonnement, gardez la question et la réponse mais réécrivez la réponse pour inclure les étapes de raisonnement que vous voulez que le modèle apprenne.

Nettoyage : là où la qualité se gagne

C'est l'étape qui décide de votre résultat, et c'est principalement un filtrage peu glamour. Ne supposez jamais que les lignes provenant du web ou générées par un modèle sont correctes — inspectez-les. Les modes d'échec récurrents sont spécifiques et valent la peine d'être vérifiés par leur nom :

Incohérence des étiquettes : la même catégorie écrite comme "Positive" dans une ligne et "positive" dans une autre — normalisez la casse et l'orthographe.
Réponses hors cible : l'assistant renvoie une phrase ou une question de suivi au lieu de l'étiquette exacte ou du format pour lequel vous vous entraînez.
Lignes mal étiquetées : une entrée ambiguë assignée à la mauvaise sortie — le type de bruit le plus dommageable.
Résidus de contenu générique : texte de navigation, avis de cookies ou fragments "lire plus" qui ont survécu à la conversion markdown.
Doublons : exemples identiques ou presque identiques qui gonflent le nombre de lignes et biaisent le modèle vers un contenu répété.

Une bonne habitude est de conserver à la fois le JSONL pré-nettoyé et nettoyé afin de pouvoir mesurer ce que vous avez supprimé. Et équilibrez l'ensemble entre les catégories — une classe sur-représentée apprend au modèle à la sur-prédire.

Déduplication et licences

Les données web sont pleines de répétitions — articles syndiqués, documents en miroir, paragraphes génériques — et les doublons nuisent discrètement à un fine-tuning en surpondérant tout ce qui est répété. Faites deux passages : déduplication exacte en hachant le texte normalisé pour capturer les lignes identiques, puis détection de quasi-doublons (une technique de similarité ou de shingling comme MinHash) pour capturer les copies reformulées qu'un hachage exact manque. Concernant les licences, soyez délibéré : tout ce qui est public n'est pas librement réutilisable. Suivez la source et la licence de chaque document, filtrez le contenu dont les termes interdisent l'utilisation pour l'entraînement, et préférez les sources avec des autorisations de réutilisation claires. Il est bien moins coûteux d'enregistrer la provenance pendant que vous explorez que de la reconstruire après avoir tout mélangé.

Sourcez des données web propres pour les LLMs

Combinez, cartographiez et divisez

Lorsque vous tirez de plusieurs sources, standardisez-les toutes à un format et fusionnez-les en un jeu de données unifié unique avant l'entraînement — un fine-tuning propre sur l'ensemble combiné bat un fine-tuning séquentiel sur chaque source, qui a tendance à éroder ce que le modèle a appris plus tôt. Ensuite, rédigez une carte du jeu de données : un court enregistrement de l'origine des données, comment elles ont été nettoyées, leur taille et distribution des étiquettes, leur licence, et toute limitation connue. C'est ce qui rend le jeu de données reproductible et vérifiable des mois plus tard. Enfin, réservez une division d'évaluation que vous n'entraînez jamais, afin de pouvoir mesurer le fine-tuning honnêtement au lieu de le noter sur des données qu'il a mémorisées. Si vous alimentez un système de récupération plutôt qu'un fine-tuning, notre guide de pipeline RAG couvre le côté rafraîchissement du même problème.

Panneau de statistiques montrant les tailles des jeux de données de fine-tuning : minimum de 100 lignes, plus de 1000 pour optimal, 10 exemples de semence pour la génération synthétique, 52000 lignes Alpaca — En dessous d'environ 100 lignes, un fine-tuning apprend à peine ; au-delà de 1 000 lignes propres, la qualité l'emporte sur la quantité.

Questions fréquemment posées

Combien de lignes dois-je avoir pour fine-tuner un LLM ?

Environ 100 lignes est le minimum pratique pour des résultats raisonnables, et plus de 1 000 est un bon objectif pour une performance solide. Plus aide généralement, mais seulement si les données restent propres — un ensemble plus petit et bien étiqueté vaut mieux qu'un grand bruyant. Pour la génération synthétique, alimentez le générateur avec au moins dix exemples écrits à la main pour qu'il apprenne d'abord votre format exact.

Quel format doit avoir les données de fine-tuning ?

JSONL — un objet JSON par ligne. La plupart des formateurs modernes par défaut utilisent un format conversationnel avec un tableau messages de paires rôle-contenu système/utilisateur/assistant. Les anciens jeux de données d'instructions utilisent des champs instruction/input/output. Choisissez un format cible basé sur votre objectif d'entraînement et standardisez chaque source à celui-ci avant l'entraînement.

Comment nettoyer un jeu de données extrait pour le fine-tuning ?

Convertissez les pages en markdown pour éliminer le contenu générique, puis filtrez manuellement pour les échecs courants : étiquettes incohérentes, réponses hors cible, lignes mal étiquetées, et texte de navigation ou de cookies restant. Dédupliquez avec un hachage exact et un passage de quasi-doublons, équilibrez les catégories, et conservez à la fois les versions brutes et nettoyées pour pouvoir mesurer ce que vous avez supprimé.

Puis-je utiliser n'importe quel contenu web pour entraîner un modèle ?

Pas automatiquement — public ne signifie pas librement réutilisable. Certains contenus comportent des termes qui interdisent l'utilisation pour l'entraînement, et les données personnelles ont leurs propres règles. Suivez la source et la licence de chaque document au fur et à mesure que vous le collectez, filtrez tout ce dont les termes interdisent l'entraînement, et préférez les sources clairement autorisées. Ceci est une information générale, pas un conseil juridique ; consultez un avocat pour les jeux de données commerciaux.

Construire un jeu de données de fine-tuning à partir du web est un pipeline de filtrage : sourcez du markdown propre, façonnez-le dans le format de messages que votre formateur attend, dédupliquez et vérifiez les étiquettes sans pitié, filtrez pour la licence, et cartographiez le résultat. Obtenez environ mille lignes propres et réservez une division d'évaluation honnête, et vous dépenserez votre budget d'entraînement sur le signal au lieu du bruit.

Construisez votre jeu de données avec les données web de QuantumProxies