Jeu de données, collection de tâches, benchmark et environnement
Un jeu de données est un ensemble de documents, par exemple des textes, des tableaux et des fichiers, utilisé pour entraîner ou analyser. Une collection de tâches est un ensemble de problèmes extraits de ces documents, chacun avec un état de départ et un résultat défini. Un benchmark, ou jeu d’évaluation, est une collection de tâches tenue à l’écart de l’entraînement afin de mesurer les capacités. Un environnement exécutable ajoute des outils, un état de travail et un contrôle programmatique : un modèle peut ainsi tenter une tâche de nombreuses fois et être noté à chaque tentative.
Une archive de documents est un jeu de données. Elle devient une collection de tâches lorsque quelqu’un décide quelle était la question et à quoi ressemble une bonne réponse, et elle devient un environnement lorsqu’une tentative peut être exécutée et notée sans personne dans la boucle.
Ce qu’un document doit contenir pour devenir une tâche
Quatre éléments doivent pouvoir être retrouvés : la demande telle qu’elle est arrivée, les éléments dont disposaient alors les personnes concernées, la décision qu’elles ont prise et ce qui s’en est suivi. Si l’un manque, le document peut rester utile comme texte, mais il ne peut pas être noté comme tâche.
Une tâche est calée sur le moment de la décision. Tout ce qui a été écrit plus tard, par exemple un plan révisé, un e-mail de clôture ou un rapport d’action corrective, peut révéler la réponse.
Un exemple de déroulement
Cet exemple a été inventé pour cette page et ne provient ni des archives d’une entreprise ni d’un jeu de données proposé. Un client envoie une demande de prix pour un support sur une ligne d’emballage, avec une spécification en révision A. Un devis part. L’examen du client revient avec une modification, et la spécification passe en révision B, qui change un schéma de perçage. Le bureau d’études met à jour le modèle CAO et le plan et dépose un ordre de modification qui liste les ensembles utilisant le support. Quatorze mois plus tard, une intervention de service est clôturée avec un code de panne.
Une seule chaîne sert de base à plusieurs tâches, chacune calée sur un autre moment avec d’autres informations. Au devis, la tâche consiste à chiffrer le travail et le contrôle est le résultat consigné. À l’ordre de modification, elle consiste à trouver les ensembles concernés et le contrôle est la liste approuvée par le bureau d’études. À l’intervention de service, elle consiste à trouver la cause probable et le contrôle est l’ordre de travail clôturé.
Fichiers CAO isolés et flux d’ingénierie reliés
Un modèle CAO montre ce qui a été conçu. L’historique des révisions, les remarques des relecteurs, l’ordre de modification et la correspondance avec les fournisseurs montrent comment et pourquoi il a changé : c’est un signal de processus que des fichiers finis ne peuvent pas fournir. Un modèle entraîné ou testé sur des fichiers isolés peut apprendre la géométrie.
Les fichiers isolés conviennent encore aux tâches qui n’exigent que de la géométrie, comme vérifier qu’un modèle se reconstruit ou qu’un ensemble s’assemble. Les tâches sur l’impact d’une modification, le choix d’un fournisseur ou l’analyse de cause racine demandent les documents environnants, reliés entre eux et à la pièce.
Un contrôle peut être exact, jugé ou mixte
Certains contrôles sont exacts : un modèle se reconstruit ou échoue, un bilan de matière et d’énergie se boucle, un schéma et une liste d’entrées et sorties concordent repère par repère. D’autres comparent une tentative à une exigence écrite avant le début du travail, par exemple une ligne de spécification ou un essai de réception. D’autres encore la comparent à une décision humaine consignée, ce qui fait appel au jugement.
Un vérificateur n’est déterministe que si une même tentative reçoit toujours la même note et que rien dans le contrôle ne dépend d’un modèle ou du hasard. Un contrôle bruité entraîne un comportement bruité : chaque tâche devrait donc dire ce que son contrôle mesure et où il peut être contourné.
Questions à poser à tout fournisseur
D’où vient le matériau, et pourrait-il déjà figurer dans les données d’entraînement d’un modèle ? Que contient chaque tâche : l’état de départ, les outils, la limite d’information ? Que mesure le contrôle, est-il exact ou jugé, et comment a-t-il été testé sur des tentatives qui semblent justes et ne le sont pas ? Quelles tâches sont réservées à l’évaluation, et qui peut les voir ?
Qui a autorisé l’usage, quels usages sont permis et qui peut recevoir le matériau ? Comment les données personnelles sont-elles traitées, et que laisse-t-on au contrat plutôt qu’à l’anonymisation ? Quelles tâches se sont révélées trop faciles ou insolubles dans un échantillon, et qu’en a-t-on fait ?
Où les données réelles aident, et où elles n’aident pas
Les tâches synthétiques sont moins chères à produire et plus faciles à vérifier. Laquelle entraîne mieux une capacité donnée est une question empirique, et les données réelles ne gagnent pas toutes les comparaisons.
Environnements RL pour le travail industriel →