# Créer un jeu de données d’entraînement à partir de vos documents existants

Rassemblez des tickets d’assistance ou des documents approuvés, puis préparez un jeu de données JSONL vérifiable, avec des références aux sources, une détection des doublons et des ensembles d’évaluation distincts.

Canonical page: https://beeuni.ai/blog/fr/build-ai-training-dataset-jsonl

Votre historique d’assistance peut servir à entraîner un modèle de classement des demandes, mais les informations sont dispersées entre les tickets et les réponses. Beeuni peut rassembler les conversations choisies, les transformer en exemples étiquetés et vérifier les champs manquants et les doublons. Vous examinez les étiquettes incertaines, puis récupérez un jeu de données JSONL, avec un enregistrement JSON par ligne et des liens vers les tickets d’origine.

## Définissez le comportement avant le format du fichier

Supposons que vous souhaitiez qu’un modèle classe les demandes entrantes. Chaque exemple doit comprendre une demande et une catégorie approuvée. Si vous voulez obtenir des réponses fondées sur un guide, chaque exemple doit inclure une question, un texte justificatif et une réponse vérifiée. Transformer chaque paragraphe en question ne garantit pas que les réponses soient exactes ou utiles.

Connectez le service qui héberge les documents ou donnez à l’agent accès au dépôt de documentation. Commencez par une collection nommée ou une plage de dates. Pour la documentation publique, indiquez le site et les sections à inclure. Avant de passer en revue les premiers exemples, demandez à l’agent de répertorier les sources recueillies et les pages qu’il n’a pas pu lire.

## Commencez par un petit exercice d’étiquetage

Prenons l’exemple fictif d’une équipe d’assistance qui prépare un classificateur de demandes. Elle souhaite utiliser quatre étiquettes : facturation, accès au compte, aide sur le produit et à examiner. Grâce à un connecteur d’assistance autorisé, l’agent consulte les tickets clôturés sur une plage de dates convenue. Ne recueillez que les champs nécessaires à l’étiquetage et au suivi des sources, sans inclure les coordonnées ni les pièces jointes sans rapport avec la demande. La file à laquelle un ticket a été affecté ne correspond pas nécessairement à sa bonne étiquette : un agent de facturation a peut-être répondu à une question de connexion transférée.

Enregistrez une copie des sources dans l’ordinateur avec les références des tickets, la règle de sélection et l’heure de collecte. Lancez la conversion à partir de cette copie afin qu’un ticket modifié en cours de vérification ne change pas les exemples à votre insu. L’agent peut écrire et exécuter les scripts d’extraction et de validation, puis fournir ensemble le jeu de données, les scripts et le rapport de vérification.

Commencez par des demandes comprenant des messages courts, de longs échanges ou plusieurs sujets. Déterminez ce que le modèle recevra au moment de la prédiction. Si le modèle ne voit que le premier message du client, n’intégrez pas la résolution finale à l’entrée d’entraînement. Sinon, il apprendra à partir d’informations auxquelles votre application n’aura pas accès lors de l’arrivée d’une nouvelle demande.

| Demande fictive | Étiquette proposée | Décision d’étiquetage |
| --- | --- | --- |
| J’ai été facturé deux fois ce mois-ci. | Facturation | Contestation de frais |
| Je ne reçois jamais le courriel de réinitialisation. | Accès au compte | La demande concerne la connexion |
| Je n’arrive pas à me connecter pour annuler avant mon prochain renouvellement. | À examiner | Déterminer quelle intention est prioritaire |
| Ça ne fonctionne toujours pas. | À examiner | Contexte insuffisant pour classer la demande |

Établissez la règle pour la troisième ligne avant de demander à l’agent d’étiqueter le reste. Vous pouvez classer les demandes selon le problème immédiat ou envoyer à l’examen celles qui comportent plusieurs intentions. Ces deux politiques peuvent être raisonnables. Si les annotateurs les appliquent de manière incohérente, le modèle recevra des exemples contradictoires.

## Appuyez-vous sur les désaccords pour améliorer le guide d’étiquetage

Demandez à deux personnes d’étiqueter indépendamment le même petit lot. Conservez leurs étiquettes initiales et la décision finale. En cas de désaccord, indiquez-en la raison : contexte manquant, catégories qui se chevauchent ou erreur d’étiquetage. Un agent peut rassembler ces cas dans un fichier de vérification, mais la personne responsable du processus doit trancher la politique de routage.

Si une décision entraîne une modification du guide d’étiquetage, repassez en revue les exemples antérieurs concernés par cette règle. Pour le classificateur fictif, choisir le « problème immédiat » classe la demande d’annulation dans la catégorie « accès au compte ». Les autres messages qui combinent des problèmes de connexion et de paiement doivent désormais être traités de la même façon. Corriger uniquement la ligne contestée laisserait subsister l’incohérence dans les exemples précédents.

Conservez séparément les messages sources et leurs variantes synthétiques. Reformuler une demande dix fois peut aider à couvrir différentes tournures, mais ne crée pas dix situations indépendantes. Si vous générez des variantes, indiquez leur exemple parent et vérifiez leur sens. Un petit changement, comme remplacer « j’ai été facturé » par « je serai facturé », peut modifier l’étiquette attendue.

## Conservez une trace de vérification avant de produire les données d’entraînement

Utilisez un schéma intermédiaire qui associe chaque exemple à sa source. Voici à quoi pourrait ressembler une fiche de vérification fictive pour un jeu de données de questions-réponses. La question et la réponse de votre jeu de données doivent provenir de vos propres documents vérifiés.

```
{"id":"sample-001","source":"sample-handbook.txt","section":"Opening hours","question":"When does the desk open?","answer":"The desk opens at 9 a.m.","review_status":"pending","split":"unassigned"}
```

Il s’agit d’un schéma de travail, et non d’une charge utile pour une API d’entraînement. Après vérification, convertissez les fiches approuvées au format requis par votre outil d’entraînement. Si cet outil n’accepte que des messages ou des paires entrée-sortie, conservez les références aux sources et les décisions de vérification dans un fichier associé.

## Confiez à l’agent des contrôles qu’il peut effectuer

- **Structure :** analysez chaque ligne JSONL et exigez les champs et types de valeurs attendus.
- **Sources :** vérifiez que chaque exemple renvoie à une source et à une section existantes.
- **Doublons :** comparez les textes normalisés, puis vérifiez séparément les quasi-doublons. Des formulations similaires peuvent tout de même décrire des faits différents.
- **Confidentialité :** recherchez les informations personnelles et les identifiants, puis examinez les fiches signalées avant l’exportation.
- **Couverture :** comptez les exemples par catégorie et répertoriez celles pour lesquelles les données vérifiées sont rares ou inexistantes.

Un script peut vérifier qu’une référence à une source existe. Il ne peut pas prouver que la réponse découle de cette source. Vérifiez les réponses, y compris celles qui manquent de contexte ou s’appuient sur des passages contradictoires. Gardez les exemples générés séparés des fiches approuvées.

## Évitez de placer le même cas dans les données d’entraînement et de test

Déterminez ce que l’évaluation doit mesurer. Pour tester les performances sur des documents jamais vus, placez tous les exemples d’un même document dans le même ensemble. Si plusieurs fichiers décrivent le même cas, regroupez plutôt les exemples par cas. Une répartition aléatoire des lignes peut placer dans l’entraînement une réponse d’évaluation presque identique à une autre.

Demandez train.jsonl, validation.jsonl, un manifeste des sources et un rapport de validation. Le rapport doit inclure le nombre de fiches, celles qui ont été rejetées, les groupes de doublons et la règle de répartition. Une fois ces contrôles réussis, vous pouvez demander à Beeuni [de lancer une expérience de réglage fin sur votre ordinateur d’entraînement connecté](/blog/fr/run-model-fine-tuning-with-beeuni).

Pour le classificateur, un livrable exploitable comprend les définitions des étiquettes, les champs d’entrée et la règle applicable aux demandes ambiguës, en plus des fichiers JSONL. Incluez le script de préparation et ses paramètres afin qu’un autre développeur puisse reproduire la conversion. Indiquez le lot de sources à l’origine de l’exportation : un fichier nommé final.jsonl ne permet pas de savoir ce qui a changé depuis la dernière exportation.

Si les sources se trouvent d’abord dans une feuille de calcul, le [guide de nettoyage CSV](/blog/fr/clean-messy-csv-without-losing-rows) explique comment traiter les identifiants et les valeurs manquantes. Pour intégrer la préparation des jeux de données à votre propre interface, commencez par le [guide du SDK](/docs/fr/sdk).