De quoi s'agit-il
Un jeu de données est une collection nommée d'exemples d'entraînement. Dans Scalata, la plupart des exemples sont des échanges : la conversation, plus le choix des réponses de l'assistant qui servent de cibles. Un jeu de données peut également contenir des documents pour en extraire des faits. Tout ce qui suit s'y réfère : vous préparez un jeu de données, vous entraînez sur les fichiers préparés et vous évaluez le modèle qui en résulte.
Un instantané, et non un lien
Lorsqu'une conversation est ajoutée à un jeu de données, ses messages y sont copiés. Dès lors, le jeu de données et la conversation sont indépendants : poursuivre l'échange, le modifier ou le supprimer ne change rien au jeu de données.
C'est délibéré. Un cycle d'entraînement peut prendre des heures, une évaluation est lue des jours plus tard, et un modèle peut rester en service pendant des mois. Si le jeu de données pouvait changer en cours de route, vous ne pourriez plus affirmer sur quoi un modèle a été entraîné ; deux cycles à partir du « même » jeu de données pourraient avoir traité des données différentes ; et la suppression d'une conversation pourrait effacer silencieusement des exemples sur lesquels vous comptiez.
Corrections au sein du jeu de données
Vous pouvez corriger une réponse au sein d'un jeu de données. Le texte corrigé est celui qui est entraîné, et l'original est conservé à ses côtés. Conserver les deux est utile au-delà de l'archivage : l'original et la correction forment une paire de préférences prête à l'emploi, où la correction est privilégiée. Une correction est l'un des signaux les plus forts que vous puissiez donner à un modèle, car il s'agit d'une personne indiquant exactement ce qui n'allait pas.
- Réponse initiale : « Allez dans les paramètres. »
- Votre correction : « Ouvrez Paramètres → Notifications et désactivez 'Résumé hebdomadaire'. »
- Le fine-tuning supervisé apprend la correction.
- L'alignement des préférences peut utiliser la paire : correction privilégiée, version initiale rejetée.
Conversations importées
Les conversations exportées depuis d'autres applications de messagerie peuvent également être importées. Importer le même export une seconde fois n'ajoute aucun doublon. Les doublons ont plus d'importance qu'il n'y paraît : une conversation qui apparaît deux fois compte double lors de l'entraînement, et ses copies pourraient se retrouver des deux côtés de la répartition de validation, ce qui fausserait l'évaluation à la hausse.
Autres sources d'exemples
- Conversations synthétiques. Le Dataset Builder utilise un modèle performant pour planifier divers scénarios à partir d'un brief et rédiger des exemples de conversations. Vous les examinez avant de les ajouter, et elles portent la mention Synthétique afin de pouvoir les distinguer des conversations réelles.
- Jeux de données publics. Les lignes d'un jeu de données Hugging Face peuvent être importées sous forme de conversations une fois que Scalata a déterminé quelles colonnes contiennent la question et la réponse. Les importations volumineuses s'exécutent en arrière-plan.
- Retours sur les conversations. Les pouces levés et baissés attribués dans le chat deviennent des exemples : une réponse appréciée devient une réponse dont le modèle peut apprendre, et une réponse appréciée associée à une réponse non appréciée pour la même question forment une paire de préférences.
- Documents. Fichiers importés, fichiers déjà présents dans Scalata, pages web publiques, lignes en texte brut d'un jeu de données Hugging Face, ou fichiers issus d'une source de données connectée. Leur texte est lu une seule fois ; un modèle peut ensuite rédiger des exemples de questions-réponses à partir de celui-ci, ou des modèles ouverts peuvent s'entraîner directement sur le texte (pré-entraînement continu).
Chaque source a son propre piège. Les conversations synthétiques sont plus propres que les réelles, mélangez-les donc avec des données réelles lorsque vous le pouvez, et gardez les conversations réelles pour les tests. Les lignes importées ne valent que ce que vaut leur source. Les documents enseignent ce qui est vrai, et non la manière de répondre ; ils interviennent donc généralement avant, ou en parallèle, de l'entraînement sur les conversations.
De nouvelles versions plutôt que des modifications infinies
Pour un changement substantiel — un nouveau domaine de produit, un nouveau lot de conversations, un style différent —, il est généralement plus clair de créer un nouveau jeu de données que de remodeler sans cesse un ancien. Nommez les versions pour que la différence soit évidente (« Support v2 — facturation ajoutée »), et archivez l'ancienne version plutôt que de la supprimer, afin que les modèles antérieurs pointent toujours vers ce sur quoi ils ont été entraînés.
Erreurs courantes
- S'attendre à ce qu'une correction apportée dans la conversation d'origine se répercute sur un jeu de données créé antérieurement.
- Supprimer un ancien jeu de données ayant servi à entraîner un modèle que vous utilisez toujours, perdant ainsi la trace de ce qu'il a appris.
- Mélanger des tâches sans rapport dans un même jeu de données sans suffisamment d'exemples pour chacune.
- Laisser une réponse erronée comme cible au lieu de la corriger dans le jeu de données.
Références et lectures complémentaires
Les sources externes s'ouvrent dans un nouvel onglet.
- 01Datasheets for DatasetsGebru et al., 2018 · arXiv · arxiv.orgL'importance de documenter la méthode de collecte et le contenu de chaque jeu de données.
- 02DatasetsHugging Face docs · huggingface.coComment l'écosystème open source stocke, versionne et partage les données d'entraînement.
- 03Deduplicating Training Data Makes Language Models BetterLee et al., 2021 · arXiv · arxiv.orgPourquoi il est utile de supprimer les exemples en double.