Bonjour tout le monde. Aujourd’hui, je vais vous présenter notre travail de [recherche] « [Apprendre] à raisonner par déduction » : résolution de [problèmes de mots mathématiques] comme [extraction de relation] complexe.
Je m’appelle Allan du laboratoire d’[intelligence artificielle] ByteDance, et ceci est un travail en commun avec Jierui Li de l’Université du Texas à Austin et Wei Lu du [SUTD].
Tout d’abord, j’aimerais parler de notre motivation [pour] le [raisonnement].
Donc ici, nous montrons un exemple où le [raisonnement] en plusieurs étapes est utile.
Ce chiffre est donc tiré de l’[article] [PaLM] où ils incitent à résoudre le [problème] de réseau dans le scénario d’[apprentissage] de quelques prises de vue.
Donc, sur le côté gauche, nous pouvons voir que si nous fournissons quelques exemples avec juste des [questions] et des réponses, nous pourrions ne pas être en mesure d’obtenir les bonnes réponses.
Mais si nous fournissons plus de description du [raisonnement], le [modèle] est capable de prévenir la description du [raisonnement], mais aussi d’effectuer ici une [prévention] correcte.
Il est alors bon d’avoir comme résultat un [raisonnement] à plusieurs étapes [interprétable].
Et nous pensons également que les [problèmes de mots mathématiques] sont une application directe pour évaluer de telles capacités de [raisonnement].
Donc ici, dans notre configuration de [problème], compte tenu des [questions], nous devons résoudre cette [question] et obtenir les réponses numériques.
Ainsi, dans nos [données], nous recevons également l‘expression mathématique qui conduit à cette [réponse] particulière.
Donc, certaines hypothèses s’appliquent également comme dans les travaux [antérieurs].
Nous supposons que la précision des quantités est connue.
Et nous ne considérons que les opérateurs de base tels que l’addition, la soustraction, la multiplication, la division et l’exponentielle.
[En outre], les opérateurs compliqués peuvent effectivement être décomposés en ces opérateurs de base.
Ainsi, le travail [antérieur] dans la résolution de [problèmes de mots mathématiques] peut en effet être classé dans un [modèle] [séquence] à [séquence] et [séquence] à arbre.
Le [modèle] [séquence] à [séquence] traditionnel convertit donc l’expression en une [séquence] spécifique [pour] la [génération].
Il est assez facile à mettre en œuvre et peut être [généralisé] à de nombreux [problèmes] compliqués différents.
Mais les inconvénients sont que la performance n’est généralement pas meilleure que le [modèle] [structuré] et son manque d’[interopérabilité] [pour] la [prévention].
Mais en réalité, cette direction est encore très populaire en raison du [modèle] de [conversion].
Donc, dans les [modèles] à base d’arbre, nous [structurons] en réalité ces expressions sous forme d’arbre et suivons une traversée préordonnée dans les générations d’arbres.
Donc ici, nous continuons à [produire] les opérateurs jusqu’à ce que nous atteignions les feuilles, qui sont les quantités.
Donc ici, la bonne chose est qu’en fait, cela nous donne cette [structure] d’arbre [binaire]. Mais en réalité, c’est assez contre-intuitif parce que nous générons d’abord l’opérateur et ensuite, à la fin, nous générons les quantités.
Et la deuxième chose est que cela contient également des calculs répétitifs.
Donc ici, si nous regardons cette expression, huit fois trois plus trois est en fait [généré] deux fois, mais en réalité, nous devrions réutiliser les résultats.
Ainsi, dans notre [approche] proposée, nous voulons résoudre ces problèmes étape par étape et de manière [interprétable].
[Par] exemple, ici dans la deuxième étape, nous pouvons obtenir ces diviseurs qui sont vingt-sept.
Et nous pouvons également nous référer aux [questions] originales pour trouver le contenu pertinent.
Et dans ces étapes, nous obtenons les diviseurs.
Puis, à cette troisième étape, nous obtenons alors le quotient.
Très bien. Et après ces trois étapes, nous pouvons alors réutiliser les résultats de la deuxième étape, puis obtenir les résultats de la quatrième étape, et enfin, nous pouvons obtenir les dividendes.
Donc ici, nous générons en réalité l’expression entière directement plutôt que de [produire] un seul opérateur ou une seule quantité.
Cela rend le processus plus précis.
Ainsi, dans notre [système] déductif, nous commençons d’abord par un tas de quantités présentées dans les [questions] et incluant également une certaine constante comme notre état initial.
Ainsi, l’expression est représentée par e i j o p.
Où nous effectuons l’opérateur de q_i à q_j, et cette expression est en fait dirigée.
Donc, nous avons également ici la soustraction avec des [mots] pour représenter la direction opposée.
C’est tout à fait [similaire] à l’[extraction de relation].
Donc, dans un [système] déductif formel, à un pas de temps t, on applique l’opérateur entre la paire q_i et q_j, puis on obtient cette nouvelle expression.
Nous l’ajoutons à l’état suivant pour devenir une nouvelle quantité.
Ainsi, ces diapositives visualisent en réalité l’évolution de l’état où nous continuons à ajouter de l’expression à l’état actuel.
Donc, dans nos implémentations de [modèle], nous utilisons d’abord un [modèle] de [langue préformée] qui peut être [BERT] ou Roberta, puis nous [encodons] la [phrase] et obtenons ensuite ces [représentations] de quantité.
Donc, une fois que nous obtenons les [représentations] de quantité, nous pouvons commencer à faire l’[inférence].
Nous montrons ici un exemple de q_1 pour obtenir la [représentation] [pour] q_2 divisée par q_2 multipliée par q_3.
Tout d’abord, nous obtenons la [représentation] de paire, qui n’est essentiellement que l’[enchaînement] entre q_1 et q_2, puis nous appliquons un réseau prédictif qui est paramétré par l’opérateur.
Et enfin, nous obtenons la [représentation] de l’expression q_1 divisée par q_2.
Mais en réalité, dans la pratique, au stade de l’[inférence], nous pourrions également obtenir une expression incorrecte.
Donc ici, toute l’expression possible est égale à trois fois le [nombre] d’opérateurs.
Alors, ce qui est bien ici, c’est que nous pouvons facilement ajouter des contraintes pour contrôler cet espace de [recherche].
[Par] exemple, si cette expression n’est pas autorisée, nous pouvons simplement supprimer cette expression dans notre espace de [recherche].
Donc, dans la deuxième étape, nous faisons la même chose, mais la seule différence est que nous avons une quantité de plus.
Cette quantité provient donc de l’expression calculée [antérieure].
Finalement, nous pouvons obtenir cette expression finale q_3 multipliée par q_4.
Et nous pouvons également voir que le [nombre] de toutes les expressions possibles est différent de l’étape [antérieure].
Ainsi, une telle différence rend difficile l’application de la [beam search] car la distribution de probabilité entre ces deux étapes est déséquilibrée.
La procédure de [formation] est donc [similaire] à la [formation] d’un [modèle] [séquence] à [séquence] où nous optimisons la perte à chaque pas de temps.
Et ici, nous utilisons également ce tau pour représenter le moment où nous devrions mettre fin à ce processus de [génération].
Et ici, l’espace est différent de [séquence] à [séquence] car il est différent à chaque pas de temps, alors que dans le [modèle] [séquence] à [séquence] traditionnel, c’est le [nombre] de [vocabulaire].
Et cela nous permet également d’imposer certaines contraintes à partir de [connaissances] antérieures.
Nous menons donc des expériences sur les [données] de [problèmes de mots mathématiques], [MAWPS], Math23K, [MathQA] et [SVAMP] couramment utilisées.
Et ici, nous montrons brièvement les résultats [comparés] aux meilleures approches [antérieures].
Donc, notre variante la plus performante est Roberta-DeuctiveReasoner.
Et en réalité, nous n’utilisons pas la [beam search] ; au contraire, toutes les approches [antérieures] utilisent la [beam search].
Très bien. Ainsi, les meilleures approches sont souvent un [modèle] à base d’arbre.
Donc, dans l’ensemble, notre raisonneur est capable de dépasser significativement ce [modèle] à base d’arbre.
Mais nous pouvons voir que les nombres absolus sur [MathQA] ou [SVAMP] ne sont pas vraiment élevés.
Nous étudions donc plus en détail les résultats sur [SVAMP].
Et ces [données] sont difficiles parce que l’auteur a essayé d’ajouter [manuellement] quelque chose pour confondre le [modèle] [TAL traitement automatique du langage naturel] comme ajouter des [informations] non pertinentes et des quantités supplémentaires.
Donc, dans notre [prévention], nous trouvons que certaines des valeurs intermédiaires sont en réalité négatives.
[Par] exemple, dans ces [questions], nous demandons « combien de pommes a Jake ? »
Mais nous avons des [informations] supplémentaires comme « dix-sept photos de moins », et « Steven en a huit », ce qui est totalement hors de propos.
Ainsi, notre [modèle] effectue une [prévention] comme celle-ci qui produit des valeurs négatives.
Et nous constatons que ces deux expressions ont en réalité des scores [similaires].
Nous pouvons alors limiter cet espace de [recherche] en supprimant les résultats négatifs afin que nous puissions rendre la [réponse] correcte.
Nous trouvons donc que cette [contrainte] améliore en réalité beaucoup [pour] certains [modèles].
[Par] exemple, [pour] les [Représentations d'encodeurs bidirectionnels à partir de transformateurs], nous améliorons sept points, puis [pour] le [modèle] de base Roberta, nous avons amélioré deux points.
Le meilleur [modèle de langue] a donc de meilleures capacités de [compréhension de la langue] de sorte que le [nombre] ici est plus élevé [pour] Roberta et plus bas [pour] les [Représentations d'encodeurs bidirectionnels à partir de transformateurs].
Et nous essayons également d’analyser la difficulté derrière toutes ces [données].
Nous supposons que le [nombre] de quantités inutilisées peut être considéré ici comme une [information] non pertinente.
Donc ici, nous pouvons voir que nous avons le pourcentage d’échantillons avec des quantités inutilisées, et les [données] [SVAMP] ont la plus grande partie.
Et ici, nous montrons également la performance globale.
[Pour] ces échantillons sans quantités inutilisées, la performance est en réalité supérieure à la performance globale.
Mais avec ces échantillons ayant une quantité inutilisée, c’est en fait bien pire que la performance globale.
[Pour] [MAWPS], nous n’avons pas vraiment trop de cas de test, alors j’ignore simplement cette partie.
Finalement, nous voulons montrer l’[interopérabilité] à travers un exemple de perturbation de [question].
Donc ici, notre [modèle] effectue en réalité une [prévention] erronée à la première étape.
Ainsi, nous pouvons effectivement corréler cette expression avec la [phrase] ici. Très bien.
Nous pensons donc que cette [phrase] pourrait induire le [modèle] en erreur avec des préventions incorrectes.
Donc ici, en planter trente-cinq autres fait penser au [modèle] qu’il devrait être un opérateur d’addition.
Nous essayons alors de réviser la [phrase] pour que cela soit quelque chose comme « le [nombre] de poiriers est inférieur de trente-cinq à celui des pommiers ».
Nous faisons en sorte de transmettre une [sémantique] plus précise afin que le [modèle] soit capable de rendre la [prévention] correcte.
Ainsi, cette étude montre comment les préventions [interprétables] nous aident à comprendre le comportement du [modèle].
Donc, pour conclure notre travail, notre [modèle] est en réalité assez efficace.
Et nous sommes en mesure de fournir une procédure de résolution [interprétable].
Et nous pouvons facilement incorporer des [connaissances] antérieures en tant que [contraintes] qui peuvent aider à améliorer la performance.
Et la dernière chose est que le mécanisme sous-jacent ne s’applique pas seulement aux [tâches] de résolution des [problèmes] de réseau, mais aussi aux autres [tâches] qui impliquent un [raisonnement] à plusieurs étapes.
Nous avons également certaines limites.
Si nous avons un [grand] [nombre] d’opérateurs ou de constantes, la consommation de mémoire pourrait être assez élevée.
Et la deuxième chose est que, comme mentionné, puisque la distribution de probabilité est déséquilibrée entre les différentes étapes de temps, il est donc également assez difficile d’appliquer la stratégie de [beam search].
Nous arrivons donc à la fin de la discussion, et vos [questions] sont les bienvenues. Merci.
Bonjour, je m’appelle Antoine et je suis de l’Université de Maastricht.
Je vais vous présenter mon travail en commun avec Jerry, qui porte sur de nouvelles [données] [pour] l’[extraction] des articles de droit.
Les questions juridiques font partie intégrante de la vie de nombreuses personnes.
Mais la majorité des citoyens ont peu de [connaissances] sur leurs droits et leurs processus juridiques fondamentaux.
En conséquence, de nombreux citoyens vulnérables qui n’ont pas les moyens de se payer l’aide coûteuse d’un expert juridique sont laissés sans protection ou, pire encore, exploités.
Tous les travaux visent à combler le fossé entre les personnes et la loi en développant un [système] d’[extraction] efficace [pour] les articles de droit.
Un tel [système] pourrait fournir un service d’aide juridique professionnel gratuit [aux] personnes non qualifiées.
Avant de plonger dans la principale contribution de ce travail, nous allons d’abord décrire le [problème] d’[extraction] des articles de droit.
Compte tenu d’une simple [question] sur une question juridique telle que : « qu’est-ce que je risque si je viole la confidentialité professionnelle ? »
Un [modèle] est nécessaire pour extraire tous les articles de droit pertinents d’un [grand] corpus législatif.
Cette [tâche] d’[extraction des informations] comporte son propre ensemble de défis.
Tout d’abord, elle traite de deux types de [langue].
La [langue naturelle] commune [pour] les [questions] et la [langue] juridique complexe [pour] les lois.
Cette différence dans les [distributions] de [langue] rend plus difficile [pour] un [système] d’extraire les candidats pertinents, car cela nécessite indirectement un [système] d’interprétation inhérent qui peut traduire une [question] [naturelle] en une [question] juridique correspondant à la [terminologie] des lois.
En outre, le droit écrit n’est pas une pile d’articles indépendants qui peuvent être traités comme une [source] complète d’[informations] par eux-mêmes, contrairement aux [nouvelles] ou aux recettes, [par] exemple.
Au lieu de cela, il s’agit d’un ensemble [structuré] de dispositions juridiques qui n’ont un [sens] entier que lorsqu’elles sont considérées dans le [contexte] global, c’est-à-dire avec les [informations] supplémentaires des articles voisins, les domaines et sous-domaines auxquels elles appartiennent et leur place dans la [structure] de la loi.
Enfin, les articles de droit ne sont pas de petits paragraphes constituant généralement l’unité d’[extraction] typique dans la plupart des travaux d’[extraction].
Ici, il y a de longs [documents] qui peuvent aller jusqu’à six mille [mots].
Les [recent advances] en matière de [TAL traitement automatique du langage naturel] ont suscité un vif intérêt pour de nombreuses [tâches] juridiques, telles que la [prévention] du jugement juridique ou l’examen des contrats de contacts automatisés.
Mais l’[extraction] de l’article de droit est restée essentiellement inchangée en raison du manque de [grandes] [données] [étiquetées] de haute [qualité].
Dans ce travail, nous présentons de nouvelles [données] centrées sur le citoyen natif [français] pour étudier si l’[extraction] des [modèles] peut se rapprocher de l’efficacité et de la fiabilité d’un expert juridique [pour] la [tâche] d’[extraction] de l’article de droit.
Nos [données] d’[extraction] de l’article de droit belge [BSARD] se composent de plus de mille cent [questions] juridiques posées par des citoyens belges.
Ces [questions] couvrent un [wide range] de sujets allant de la famille au logement, à l’argent, au travail et à la sécurité [sociale].
Chacune d’entre elles a été [étiquetée] par des juristes expérimentés avec des références à des articles pertinents d’un [corpus] de plus de vingt-deux mille six cents articles juridiques de codes de droit belge.
Parlons maintenant de la façon dont nous avons collecté ces [données].
Tout d’abord, nous avons commencé par compiler un [grand] [corpus] d’articles juridiques.
Nous avons examiné trente-deux codes belges accessibles au public et [extrait] tous les articles ainsi que les titres de section [correspondants].
Ensuite, nous avons rassemblé les [questions] juridiques avec les références aux lois pertinentes.
Pour ce faire, nous nous associons au cabinet d’avocats belge qui reçoit chaque année environ quatre mille courriels de citoyens belges demandant [des] conseils sur une question juridique personnelle.
Nous avons eu la chance d’avoir accès à leurs sites web, où leur équipe de juristes expérimentés aborde les questions juridiques les plus courantes des Belges.
Nous avons recueilli des milliers de [questions] [annotées] avec des catégories, des sous-catégories et des références juridiques aux lois pertinentes.
Enfin, nous avons fait passer les références juridiques et filtré les [questions] dont les références n’étaient pas des articles dans l’un des codes de droit que nous avons considérés.
Les références restantes ont été appariées et converties aux identifiants d’article [correspondants] de notre [corpus].
Nous nous sommes finalement retrouvés avec mille cent huit [questions], chacune soigneusement [étiquetée] avec les identifiants des articles pertinents de notre [grand] [corpus] de vingt-deux mille six cent trente-trois articles de droit.
De plus, chaque [question] est accompagnée de la catégorie principale et d’un [enchaînement] de sous-catégories.
Et chaque article comporte un [enchaînement] de la rubrique de sous-séquence dans la [structure] de la loi.
Ces [informations] supplémentaires ne sont pas utilisées dans le présent travail, mais pourraient présenter un intérêt [pour] des [recherches] futures sur l’[extraction d’informations] juridiques ou la [classification de textes] juridiques.
Jetons un coup d’œil à certaines caractéristiques de nos [données].
Les [questions] comportent entre cinq et quarante-quatre [mots] avec une moyenne de quatorze [mots].
Les articles sont beaucoup plus longs avec une longueur moyenne de soixante-dix-sept [mots], avec cent quarante-deux d’entre eux dépassant les mille [mots].
Le plus long étant jusqu’à cinq mille sept cent quatre-vingt-dix [mots].
Comme mentionné précédemment, les [questions] couvrent un [wide range] de sujets, dont environ quatre-vingt-cinq pour cent concernent la famille, le logement, l’argent ou la justice.
Alors que les quinze pour cent restants concernent la sécurité [sociale], les étrangers ou le travail.
L’article est également très diversifié car il provient de trente-deux codes belges différents qui couvrent un [grand] [nombre] de sujets juridiques.
Voici le [nombre] total d’articles collectés à partir de chacun de ces codes belges.
Sur les vingt-deux mille six cent trente-trois articles, seuls mille six cent douze sont désignés comme pertinents à au moins une [question] dans les [données].
Et environ quatre-vingts pour cent de ces articles cités proviennent du code civil, des codes judiciaires, des codes d’enquête criminelle ou des codes pénaux.
Pendant ce temps, dix-huit des trente-deux codes ont moins de cinq articles mentionnés comme pertinents pour au moins une [question].
Ce qui peut s’expliquer par le fait que ces codes se concentraient moins sur les individus et leurs préoccupations.
Dans l’ensemble, le [nombre] moyen de citations [pour] ces articles cités est de deux, et moins de vingt-cinq pour cent d’entre eux sont cités plus de cinq fois.
En utilisant toutes les [données], nous avons comparé plusieurs approches d’[extraction], y compris l’architecture [lexicale] et dense.
Étant donné une [requête] et un article, un [modèle] [lexical] attribue un score à la paire d’articles de [requête] en calculant la somme sur les termes de [requête] des [poids] de chacun de ces termes dans cet article.
Nous expérimentons avec les fonctions de classement TF-[IDF] et BM25 standard.
Le principal [problème] de ces approches est qu’elles ne peuvent extraire que les articles contenant des mots-clés présents dans la [requête].
Pour surmonter cette limitation, nous expérimentons une architecture [neuronale] qui peut capturer les relations [sémantiques] entre les [requêtes] et l’article.
Nous utilisons un [modèle] bi-[encodeur] qui cartographie les [requêtes] et les articles en [représentations] [vecteurs] denses et calculons un score de pertinence entre une paire d’articles de [requête] par la [similitude] de leurs [intégrations].
Ces [intégrations] résultent typiquement d’une opération de pooling sur la sortie d’un [modèle] d’[intégration de mots].
Tout d’abord, nous étudions l’efficacité des bi-[encodeurs] siamois dans une configuration d’[évaluation] « zero shot », ce qui [signifie] que des [modèles] d’[intégration de mots] [préformés] sont appliqués immédiatement sans aucun [raffinement] supplémentaire.
Nous expérimentons avec l’[encodeur] de [texte] indépendant du [contexte], [à savoir] [word2vec] et fastText, et des [modèles] d’[intégration] dépendants du [contexte], [à savoir] Roberta et plus précisément [CamemBERT] qui est un [modèle] Roberta [français].
[De plus], nous formons nos propres bi-[encodeurs] de [modèles] basés sur [CamemBERT] sur nos [données].
Notez que [pour] la [formation], nous expérimentons avec les deux modèles de l’architecture bi-[encodeur].
Le siamois, qui utilise un [modèle] d’[intégration de mots] unique cartographiant la [requête] et l’article ensemble dans un [vector space] dense [partagé], et le modèle à deux tours, qui utilise deux [modèles] d’[intégration de mots] indépendants [encodant] la [requête] et l’article séparément dans différents espaces d’[intégration].
Nous expérimentons la mise en commun moyenne, maximale et [CLS], ainsi que le produit et [cosinus] [pour] calculer les similitudes.
Voici le résultat de notre base sur les ensembles de test.
Avec les [méthodes] [lexicales] ci-dessus, les bi-[encodeurs] siamois ont évalué dans une configuration zero shot au milieu, et les bi-[encodeurs] raffinés ci-dessous.
Dans l’ensemble, le bi-[encodeur] raffiné dépasse de manière significative toutes les autres [bases].
Le [modèle] à deux tours s’améliore par rapport à ses variantes siamoises lors du rappel à cent, mais fonctionne de la même manière sur les autres [indicateurs].
Bien que BM25 ait sous-performé le bi-[encodeur] formé de manière significative, ses performances indiquent qu’il s’agit toujours d’une base solide [pour] l’[extraction] spécifique au [domaine].
En ce qui concerne l’[évaluation] zero shot du bi-[encodeur] siamois, nous constatons que l’utilisation directe des [intégrations] d’un [modèle] [CamemBERT] [préformé] sans optimiser [pour] la [tâche] d[’extraction d’informations] donne de mauvais résultats, ce qui est cohérent avec les résultats [antérieurs].
[En outre], nous observons que le bi-[encodeur] basé sur [word2vec] a dépassé de manière significative les [modèles] basés sur fastText et les [Représentations d'encodeurs bidirectionnels à partir de transformateurs], suggérant que peut-être les [intégrations] de niveau [mot] [préformées] sont plus appropriées [pour] la [tâche] que les [intégrations] de niveau caractère ou [sous-mot] lorsqu’elles sont utilisées immédiatement.
Bien que prometteurs, ces résultats suggèrent de nombreuses possibilités [d’]amélioration [comparé] à un expert juridique qualifié qui peut éventuellement extraire tous les articles pertinents à n’importe quelle [question], et ainsi obtenir des scores parfaits.
Concluons en discutant de deux limites de nos [données].
Premièrement, le [corpus] d’article est limité à ceux collectés à partir des trente-deux codes belges considérés, ce qui ne couvre pas l’ensemble du droit belge car les articles des décrets, directives et ordonnances sont manquants.
Au cours de la construction des [données], toutes les références à ces articles non collectés sont ignorées, ce qui fait que certaines [questions] ne se retrouvent qu’avec une fraction du [nombre] initial d’articles pertinents.
Cette [information] implique donc que la [réponse] contenue dans les autres articles pertinents pourrait être incomplète, bien qu’elle soit toujours tout à fait appropriée.
Deuxièmement, il convient de noter qu’on ne peut pas répondre à toutes les [questions] juridiques uniquement par des lois.
[Par] exemple, la [question] « puis-je expulser mes locataires s’ils font trop de bruit ? »
Elle peut ne pas avoir de [réponse] détaillée dans le droit écrit qui quantifie un seuil de bruit spécifique à partir duquel l’expulsion est autorisée.
Au lieu de cela, le propriétaire devrait probablement s’appuyer davantage sur la jurisprudence et trouver des antécédents [similaires] à sa situation actuelle.
[Par] exemple, les locataires font la fête deux fois par semaine jusqu’à deux heures du matin.
[Par conséquent], certaines [questions] sont mieux adaptées que d’autres à la [tâche] d’[extraction] de l’article de droit, et le [domaine] des moins adaptées reste à déterminer.
Nous espérons que nos travaux susciteront l’intérêt pour l’élaboration de [modèles] d’[extraction] d’article de droit pratiques et fiables.
Cela peut aider à améliorer l’accès à la justice [pour] tous.
Vous pouvez consulter notre [article], nos [données] et notre code aux liens suivants. Merci.
Bonjour, nous sommes heureux de vous présenter notre travail sur [VALSE] ; un indice de référence indépendant de la [tâche] destiné à tester les [modèles de langue] et de vision avec des phénomènes [linguistiques] spécifiques.
Pourquoi avons-nous pris la peine de mettre en place cet indice de référence ?
Eh bien, au cours des dernières années, nous avons vu une explosion de la vision basée sur le [transformateur] et des [modèles de langue] [préformés] sur de [grandes] quantités de paires de [textes] d’[images].
Chacun de ces [modèles] pousse les [tâches] de pointe en matière de vision et de langue telles que la [réponse aux questions visuelles], le [raisonnement] de bon [sens] [visuel], l’[extraction] d’[images] et les [bases] de [phrases].
Nous avons donc reçu un message : les précisions sur ces [tâches] et les indices de référence spécifiques augmentent régulièrement.
Mais savons-nous ce que les [modèles] ont réellement appris ?
Qu’est-ce qu’une vision et un [transformateur] de [langue] ont compris lors de l’attribution d’un score élevé [pour] que cette [image] et cette [phrase] correspondent ?
Et le score bas [pour] celle-ci ?
Est-ce que les [modèles de langue] et de vision se concentrent sur la bonne chose ?
Ou se concentrent-ils sur les [biais] comme le montre le travail [antérieur] ?
Pour éclairer davantage cet [aspect], nous [proposons] une direction plus indépendante des [tâches] et introduisons [VALSE] qui teste la sensibilité des [modèles de langue] et de vision à des phénomènes [linguistiques] spécifiques affectant à la fois les [modalités] [linguistiques] et [visuelles].
Nous [ciblons] l’existence, la pluralité, le comptage, les [relations] [spatiales], les actions et la [coréférence] sur les [entités].
Mais comment tester si les [modèles de langue] et de vision ont capturé ce phénomène ?
En pratiquant le foiling sur une [méthode] précédemment appliquée [pour] les [modèles de langue] et de vision seulement [pour] des phrases [nominales] de Ravi Shekhar et de ses collaborateurs, et en comptant par nous dans les travaux [antérieurs].
Effectuer un foiling signifie essentiellement que nous prenons la légende d’une [image] et produisons un foil en modifiant la légende de sorte qu’elle ne décrive plus l’[image].
Et nous apportons ces modifications de [phrases] en nous concentrant sur six éléments spécifiques tels que l’existence, la pluralité, le comptage, les [relations] [spatiales], les actions et la [coréférence] sur les [entités], où chaque élément peut consister en un ou plusieurs instruments, au cas où nous aurions trouvé plus d’une façon intéressante de créer des instances de foil.
[Par] exemple, dans le cas de l’élément d’actions, nous avons deux instruments, un dans lequel le [verbe] d’action est modifié avec une action différente, et un dans lequel les acteurs sont échangés.
Le comptage et la [coréférence] sont également des éléments qui ont plusieurs instruments.
Et nous créons ces foils en nous assurant qu’ils ne décrivent pas l’[image] et que ce sont des [phrases] [grammaticales] et autrement valides.
Ce n’est pas facile à faire car une légende ayant subi un foil peut être moins probable que la légende originale.
[Par] exemple, bien que ce ne soit pas impossible, il est statistiquement moins probable [que] les plantes coupent un homme qu’un homme coupe les plantes, et la [grande] vision et les [modèles de langue] pourraient capter cela.
[Par conséquent], pour obtenir des foils valides, nous devons agir.
Tout d’abord, nous utilisons des [modèles de langue] forts pour [proposer] des foils.
Deuxièmement, nous utilisons l’[inférence de la langue naturelle] ou la [NLI] courte pour filtrer les foils qui pourraient encore décrire l’[image], car lors de la construction des foils, nous devons nous assurer qu’ils ne décrivent pas l’[image].
Pour tester cela [automatiquement], nous appliquons l’[inférence de la langue naturelle] avec la justification suivante.
Nous considérons qu’une [image] est la prémisse et sa légende son hypothèse implicite.
En outre, nous considérons la légende comme la prémisse, et le foil est son hypothèse.
Si un [modèle] [NLI] prévient que le foil est en contradiction ou neutre par rapport à la légende, nous considérons cela comme un indicateur d’un foil valide.
Si une [NLI] prévient le foil à engendrer par la légende, cela ne peut pas être un bon foil, car par transitivité, cela donnera une description véridique de l’[image] et nous filtrons ces foils.
Mais cette procédure n’est pas parfaite, il s’agit simplement d’un indicateur [pour] les foils valides.
[Par conséquent], comme troisième mesure [pour] [produire] des foils valides, nous utilisons des [annotateurs] [humains] pour valider les [données] utilisées dans [VALSE].
Donc, après filtrage et [évaluation humaine], nous avons autant d’instances de test que décrit dans ce tableau.
Notez que [VALSE] ne fournit pas de [données de formation] mais seulement des [données] de test.
Comme il s’agit uniquement d’un indicateur de référence de test zero shot, il est conçu pour tirer parti des capacités [existantes] des [modèles de langue] et de vision après la [préformation].
Le [raffinement] permettrait seulement aux [modèles] d’exploiter des artefacts ou des [biais] [statistiques] dans les [données].
Et nous savons tous que ces [modèles] aiment tricher et prendre des raccourcis.
Et comme nous l’avons dit, cela nous intéresse d'[évaluer] les capacités des [modèles de langue] et de vision après la [préformation].
Nous expérimentons avec cinq [modèles de langue] et de vision sur [VALSE], [à savoir] avec [CLIP], [LXMert], [ViLBERT], [ViLBERT] douze en un, et [VisualBERT].
Deux de nos [indicateurs] d’[évaluation] les plus importants sont la précision des [modèles] dans la [classification] de paires de [phrases] [images] en [légendes] et foils.
Peut-être plus pertinent [pour] cette vidéo, nous présenterons notre indicateur plus permissif, la précision [par paire], qui mesure si le score de [sentence alignment] d’[image] est plus élevé [pour] la bonne paire de [texte] [image] que [pour] sa paire ayant subi un foil.
[Pour] plus d’[indicateurs] et de résultats, consultez notre [article].
Les résultats avec une précision [par paire] sont montrés ici et ils sont cohérents avec les résultats que nous avons obtenus des autres [indicateurs]. La meilleure performance zero shot est obtenue par [ViLBERT] douze en un, suivi de [ViLBERT], [LXMert], [CLIP], et enfin [VisualBERT].
Il est remarquable de voir comment les instruments centrés sur les objets individuels comme l’existence et les phrases [nominales] sont presque résolus par [ViLBERT] douze en un, en soulignant que les [modèles] sont capables d’[identifier] des objets [nommés] et leur présence dans les images.
Cependant, aucun des éléments restants ne peut être résolu de manière fiable dans nos paramètres de foiling [antagonistes].
Nous voyons à partir des instruments de pluralité et de comptage que les [modèles de langue] et de vision ont du mal à distinguer les références à des objets uniques par rapport à plusieurs, ou à les compter dans une [image].
L’élément de [relation] montre qu’ils ont des difficultés à [classer] correctement une [relation] [spatiale] [nommée] entre des objets dans une [image].
Ils ont également du mal à distinguer les actions et à [identifier] leurs participants, même s’ils sont soutenus par des [biais] de plausibilité comme nous le voyons dans l’élément d’actions.
À partir de l’élément de [coréférence], nous découvrons que relever plusieurs références au même objet dans une [image] en utilisant des [pronoms] est également difficile [pour] les [modèles de langue] et de vision.
Pour vérifier la santé mentale, et parce que c’est une expérience intéressante, nous comparons également deux [modèles] à [texte] seulement, [GPT] un et [GPT] deux, pour évaluer si [VALSE] peut être résolu par ces [modèles] unimodaux en calculant la [perplexité] de la légende correcte et ayant subi un foil, sans [image] ici, et en prévenant l’entrée avec la plus faible [perplexité].
Si la [perplexité] est plus élevée [pour] le foil, nous considérons cela comme une indication que la légende ayant subi un foil peut souffrir de biais de plausibilité ou d’autres [biais] [linguistiques].
Et il est intéressant de voir que dans certains cas, les [modèles] [GPT] à [texte] seulement ont capturé la plausibilité du monde mieux que les [modèles de langue] et de vision.
Donc, pour résumer, [VALSE] est un indicateur de référence qui utilise l’objectif des constructions [linguistiques] pour aider la communauté à améliorer les [modèles de langue] et de vision en testant durement leurs capacités de [bases] [visuelles].
Nos expériences montrent que les [modèles de langue] et de vision identifient bien les objets [nommés] et leur présence dans les images, comme le montre l’élément d’existence, mais luttent pour ancrer leur interdépendance et leurs relations dans des scènes [visuelles] lorsqu’ils sont forcés de respecter des indicateurs [linguistiques].
Nous aimerions vraiment encourager la communauté à utiliser [VALSE] [pour] mesurer les progrès vers les [bases] de la [langue] avec des [modèles de langue] et de vision.
Et plus encore, [VALSE] pourrait être utilisé comme une évaluation indirecte des [données], car les [modèles] pourraient être évalués avant et après la [formation] ou le [raffinement] pour voir si des [données] aident les [modèles] à améliorer l’un des aspects testés par [VALSE].
Si vous êtes intéressé, consultez les [données] [VALSE] sur GitHub, et si vous avez des [questions], n’hésitez pas à nous contacter.
Bonjour, je m’appelle Kamezawa de l’Université de Tokyo.
Je vais vous présenter un [article] intitulé [RNSum] : des [données] à [grande] échelle [pour] la [génération] [automatique] de note de version via la [synthèse] des journaux de validation.
Je vais vous expliquer dans cet ordre.
Tout d’abord, je vais présenter la [génération] de note de version [automatique] sur laquelle nous travaillons dans cette [recherche].
Une note de version est un [document] technique qui résume les modifications distribuées à chaque version d’un produit logiciel.
L’[image] montre une note de version [pour] la version deux point six point quatre de la bibliothèque Vuejs.
Les notes de version jouent un rôle important dans le développement [open source], mais elles mettent du temps à être préparées [manuellement].
[Par conséquent], il serait très utile de pouvoir générer [automatiquement] des notes de version de haute [qualité].
Je m’en remettrai à deux recherches [antérieures] sur la [génération] [automatique] de notes de version.
La première est un [système] appelé [ARENA] sorti en deux-mille-quatorze.
Il faut une [approche] basée sur des règles, [par] exemple, en utilisant l’[extracteur] de changement pour extraire toutes les différences, les changements de bibliothèque et les changements de [document] à partir des différences entre les versions, et enfin, en les combinant.
La caractéristique la plus notable de ce [système] est l’[extracteur] de problèmes dans le coin supérieur droit.
Le [système] de suivi des problèmes, qui doit être laissé à Jira, ne peut être appliqué qu’aux projets qui utilisent Jira.
En d’autres [mots], il ne peut pas être utilisé [pour] de nombreux projets sur GitHub.
La seconde est Glyphe, récemment annoncée en deux-mille-vingt.
Elle est disponible sur [internet] et peut être installée via pip.
Ce [système] a un [modèle] de [classification de texte] basé sur l’[apprentissage] simple et [produit] l’une des cinq étiquettes telles que les [fonctions] ou corrections de bugs [pour] chaque message de validation de [saisie].
Cette [image] est un exemple d’utilisation qui renvoie une étiquette de correction ou de débogage.
Les [données de formation] de Glyphe sont assez petites, environ cinq mille, et seront montrées dans les expériences décrites ci-dessous.
Les performances du [modèle] de [classification de texte] ne sont pas élevées.
Je présente deux recherches connexes, mais leurs problèmes sont l’applicabilité limitée et les [ressources] de [données] rares.
Notre [article] résout ces deux problèmes et génère [automatiquement] des notes de version de haute [qualité].
Avec un [problème] d’applicabilité limitée, nous [proposons] une [méthode] de [synthèse] par classe de haute [qualité] en utilisant uniquement des messages de validation comme [saisie].
Cette [méthode] proposée peut être utilisée [pour] tous les référentiels [anglais].
[Pour] le deuxième [problème] de [ressources] de [données] rares, nous avons construit nos [données] [RNSum] composées d’environ quatre-vingt-deux mille éléments de [données] en collectant des [données] à partir de référentiels GitHub publics en utilisant l’[API] GitHub.
Ensuite, je vais décrire nos [données].
Voici un exemple de [données].
Le côté gauche est un message de validation et le côté droit représente les notes de version.
Les notes de version sont [étiquetées] comme améliorations ou correctifs, etc.
Nous avons mis en place une [tâche] qui prend les messages de validation comme [saisie] et [sorties] des notes de version [étiquetées].
Cela peut être considéré comme une [tâche] de [synthèse].
Nous avons prédéfini quatre étiquettes : [fonctions], améliorations, corrections de bugs, suppressions de dépréciations et modifications de rupture.
Celles-ci ont été établies sur la base de la [recherche] [antérieure] et d’autres facteurs.
La note de version en bas à droite est [extraite] de la note de version en bas à gauche.
À ce stade, il est nécessaire de détecter les quatre étiquettes qui ont été mises en place à l’avance.
Mais les étiquettes ne sont pas toujours cohérentes avec chaque référentiel.
[Par] exemple, l’étiquette d’améliorations inclut des améliorations, des perfectionnements, des optimisations, etc.
Nous avons préparé une liste de [vocabulaire] d’une trentaine d’étiquettes [pour] chacune de ces variations de notation.
Il s’agit de détecter la classe de note de version et de collecter le [texte] de la version qui suit en tant que [phrase] de note de version [pour] la classe.
Ensuite, il y a un message de validation.
Les messages de validation ne sont pas liés à chaque version.
Comme le montre l’[image] ci-dessous, si la version actuelle est la version deux point cinq à dix-neuf, nous devons identifier la version deux point cinq à dix-huit [antérieure] et obtenir un diff.
C’est un peu fastidieux et il ne suffit pas d’obtenir une liste de versions et de regarder l’avant et l’après.
Nous avons créé une règle de correspondance [heuristique] pour obtenir les versions [antérieures] et suivantes.
[Analyse] des [données].
En fin de compte, sept mille deux cents dépôts et quatre-vingt-deux mille éléments de [données] ont été recueillis.
En outre, le [nombre] moyen de [gages] de notes de version est de soixante-trois, ce qui est assez élevé [pour] une [tâche] de [synthèse].
De même, le [nombre] de [gages] uniques est assez [grand], s’élevant à huit mille huit cent trente mille.
Cela est dû au [grand] [nombre] de noms de [méthode] ou de classe unique trouvés dans le référentiel.
Ensuite, je vais expliquer la [méthode] proposée.
Le [modèle] de [synthèse] [extractive] puis [abstractive] par classe se compose de deux modules [neuronaux].
Un [classificateur] utilisant [BERT] ou [CodeBERT] et un générateur utilisant [BART].
Tout d’abord, [CEAS] utilise un [classificateur] pour classer chaque message de validation en cinq classes de notes de version, qui utilisent des améliorations, des corrections de bogues, des dépréciations et d’autres.
Les messages de validation classés comme autres sont supprimés.
Ensuite, [CEAS] applique le générateur aux quatre [documents] [étiquetés] indépendamment et génère des notes de version [pour] chaque classe.
Dans cette [tâche], les correspondances directes entre les messages de validation et les notes de version ne sont pas connues.
[Par conséquent], pour former le [classificateur], nous avons réaffecté les enquêtes à chaque message de validation de [saisie] en utilisant les dix premiers caractères de chaque message de validation.
Nous avons modélisé l’[approche] de [synthèse] [abstractive] par classe à travers deux [méthodes] différentes.
Le premier [modèle], que nous appelons [CAS] unique, se compose d’un réseau de six à six unique et génère un seul [texte] de note de version donnant un [enchaînement] de messages de validation de [saisie].
Les [textes] de sortie peuvent être divisés en segments par classe sur la base de symboles de point d’extrémité particuliers, spécifiques à la classe.
La seconde [méthode], que nous appelons [CAS] multiple, se compose de quatre réseaux [seq2seq] différents, dont chacun correspond à l’une des classes de notes de version fixes.
Ok, je vais vous expliquer les expériences.
Cinq [méthodes] ont été [comparées] : [CEAS], [CAS] unique, [CAS] multiple, [regroupement] et étude [antérieure], Glyph.
En ce qui concerne l’[évaluation], dans certains cas, les notes de version sont produites en plusieurs [phrases].
Puisqu’il est difficile de calculer le [nombre] de [phrases] telles qu’elles sont, elles sont combinées avec des espaces et traitées comme une seule [phrase] longue.
Le [BLEU] est pénalisé lorsque le [système] [produit] une [phrase] courte.
Cette pénalité se traduit par une valeur [BLEU] inférieure dans les résultats de l’expérience décrits ci-dessous.
Enfin, nous calculons également la spécificité car [ROUGE] et [BLEU] ne peuvent pas être calculés si les notes de version sont vides.
Une spécificité plus élevée signifie que le [modèle] [produit] correctement un [texte] vide dans les cas où les notes de version sont supposées être vides.
Les résultats sont indiqués ci-après.
Étant donné que les [données] contiennent des adresses électroniques, des valeurs hachées, etc., nous avons également évalué les [données] nettoyées, ce qui les exclut.
Le [CEAS] et le [CAS] ont obtenu des scores de [ROUGE]-L supérieurs de plus de dix points par rapport aux [bases].
En particulier, sur l’ensemble de test propre, l’écart de score entre la [méthode] proposée et les [bases] a atteint plus de vingt points.
Ces résultats indiquent que le [CEAS] et le [CAS] sont considérablement touchés.
Le [CEAS] a obtenu un meilleur score [ROUGE]-L que le [CAS], ce qui suggère que la combinaison d’un [classificateur] et d’un générateur est efficace pour [former] le [classificateur] à l’aide de [pseudo]-étiquettes.
Une couverture élevée du [CEAS] peut être obtenue probablement car le [classificateur] peut se concentrer sur la sélection des messages de validation pertinents [pour] chaque classe.
Le [CAS] multiple tendait à produire plus de [ROUGE]-L que le [CAS] unique.
En suggérant qu’il est également efficace de développer indépendamment et différemment des [modèles] de [abstractive summarization] [pour] chaque classe de note de version.
Voici une [analyse] d’erreur.
Les [méthodes] [CAS] ont tendance à produire des [phrases] plus courtes que les [phrases] de référence [humaines].
Dans la figure de droite, la [phrase] de référence a trois ou quatre [phrases], tandis que le [CAS] n’en a qu’une.
La raison [de] la réticence de ce [modèle] est que dans les [données de formation], seulement trente-trois pour cent des [phrases] sont présentes dans l’étiquette des [fonctions] et quarante pour cent dans l’étiquette des améliorations.
[En outre], les [méthodes] [CAS] ne peuvent pas générer des notes de version précises sans [informations] supplémentaires.
L’exemple en haut à droite est un exemple de message de validation très désordonné, et la [phrase] complète ne peut pas être [générée] sans référence à la progression ou au problème [correspondant(e)].
L’exemple ci-dessous montre que les deux messages de validation dans la [saisie] sont liés et doivent être combinés en une [phrase], mais cela n’est pas fait.
Enfin, passons à la conclusion.
Nous avons construit de nouvelles [données] [pour] la [génération] [automatique] de notes de version.
Nous avons également formulé une [tâche] consistant à saisir des messages de validation et à les [résumer] afin qu’ils soient applicables à tous les projets [écrits] en [anglais].
Nos expériences montrent que la [méthode] proposée génère des notes de version moins bruyantes à une couverture plus élevée que les [bases].
Veuillez consulter nos [données] sur GitHub.
Merci.
Bonjour. Je m’appelle Asaf Harari.
Et je vais vous présenter notre [article] : enrichissement de [données] tabulaires en quelques coups à l’aide d’[architectures] de [transformateurs] raffinées.
Les scientifiques analysent les [données] et se concentrent principalement sur la manipulation des [fonctions] [existantes] des [données].
Mais parfois, ces [fonctions] sont limitées.
La [génération] de fonctions en utilisant une autre [source] de [données] peut ajouter des [informations] substantielles.
Notre objectif de [recherche] est l’enrichissement [automatique] de [données] tabulaires en utilisant des [textes] libres de sources externes.
Supposons que nous ayons des [données] tabulaires et une [base de connaissances].
Nous avons besoin d’un processus [automatique] qui implique la [liaison d’entités] et l’[analyse] de [texte] pour extraire de nouvelles [fonctions] du [texte] libre de la [base de connaissances].
Notre cadre [FeSTE] est exactement ce processus [automatique].
Voyons donc un exemple dans des [données] introduites dans [FeSTE].
Dans cet exemple, les [données] sont des [données] universitaires.
Quand l’objectif est de classer les universités en universités de bas rang et en universités de haut rang.
En tant que [base de connaissances], nous utilisons [Wikipédia].
La première phase de [FeSTE] est la [liaison d’entités].
Lorsque chaque [entité], dans cet exemple, le nom de l’université, est [liée] à une [entité] au sein de la [base de connaissances].
Et le [texte] des [entités] de la [base de connaissances] est [extrait] et ajouté aux [données].
Dans cet exemple, le [texte] est le résumé de la page [Wikipédia].
Maintenant, nous devons générer ou extraire des [fonctions] à partir du [texte] [extrait].
Nous avons donc besoin de la phase d’[extraction] des fonctions qui comprend l’[analyse] de [texte].
Il s’agit de la principale nouveauté de cet [article] et je vais mieux l’expliquer dans les prochaines diapositives.
Après la phase d’[extraction] des fonctions, il y a une phase de [génération] de fonctions lorsque nous utilisons les [fonctions] [extraites] pour générer un petit [nombre] de nouvelles [fonctions].
Générez d’abord les [fonctions] dans le [nombre] de classes des [données] d’origine.
Dans cet exemple, les [données] d’origine ont deux classes.
Ainsi, [FeSTE] génère deux nouvelles [fonctions].
Mais si les [données] ont cinq classes, [FeSTE] génère cinq nouvelles [fonctions].
Chaque fonction représente la probabilité [pour] chaque classe.
Pour analyser le [texte], nous utilisons les [analyses] de [texte] de pointe, qui sont des [modèles de langue] basés sur la [conversion] comme [BERT], [GPT], [XLNet] etc.
Mais il est peu probable que nous puissions former des [modèles de langue] en utilisant les [données] de [saisie].
Ainsi, une [approche] naïve sera le [raffinement] de la [tâche] [cible].
Dans la phase d’[extraction] des fonctions, nous pouvons télécharger des [modèles] de [langue préformée] et raffiner le [modèle de langue] sur les [données] [cibles].
Dans cet exemple, raffiner le [modèle de langue], classer le [texte] en classes, résumer en classes, basses ou hautes.
Recevoir les résultats du [modèle de langue], qui sont la probabilité [pour] chaque classe et les utiliser comme nouvelles [fonctions].
Le [problème] avec cette [approche] est que les [données] peuvent avoir peu d’[entités] / de [textes] distinct(e)s.
Dans notre expérience, près de la moitié des [données] contiennent moins de quatre cents échantillons et les plus petites [données] contiennent trente-cinq échantillons dans un ensemble de [formation].
Donc, pour raffiner un [modèle de langue] sur cela, les [données] seront inefficaces.
Mais nous pouvons utiliser des [connaissances] préalables sur des [données] préanalysées.
Puisque nous appliquons [FeSTE] sur des [données] multiples, nous pouvons utiliser les [données] n moins un pour recueillir des [informations] sur les [données] n moins un, et utiliser ces [informations] lorsque nous analysons les nièmes [données].
Ce que nous suggérons, c’est d’ajouter une autre phase de [raffinement].
Une phase de [raffinement] [multitâche] préliminaire.
Lorsque vous raffinez le [modèle de langue] sur les [données] n moins un.
Et ensuite, nous exécutons une autre phase de [raffinement] qui est un [raffinement] de [tâche] [cible], lorsque nous raffinons le [modèle de langue] sur les nièmes [données] [cibles].
Le [raffinement] [multitâche] de pointe appelé [MTDNN].
Le [MTDNN] maintient les têtes dans le [nombre] de [tâches] dans l’ensemble de [formation].
Donc, dans cet exemple, il y a quatre [tâches] dans l’ensemble de [formation]. Le [MTDNN] maintient alors quatre têtes comme vous pouvez le voir sur l’[image].
Et il échantillonne un lot aléatoire de l’ensemble de [formation].
Et si elles appartiennent à un lot aléatoire, [par] exemple, une seule [tâche] de [classification de phrases], il exécute des chemins d’aller et retour à travers la première tête.
Et si le lot aléatoire appartient à la [tâche] de classement [par paire], il exécute un chemin d’aller et retour dans la dernière tête.
Dans notre scénario, les [données] tabulaires varient dans le [nombre] de classes.
Il y a donc beaucoup de [tâches].
Le [MTDNN] a maintenu le [nombre] de classes, de têtes et de couches de sortie.
Et [en outre], le [MTDNN] doit initialiser de nouvelles têtes [pour] de nouvelles [données] avec une nouvelle [tâche].
Notre [approche], appelée [raffinement] de reformulation de [tâche], est dans notre [raffinement] de reformulation de [tâche] d’[approche]. Au lieu de maintenir plusieurs têtes, nous reformulons chaque [donnée] dans une [phrase] par [problème] de [classification], étant des [tâches] de deux classes.
Prenons donc un exemple.
Voici nos [données] de [saisie] qui se composent d’[entités], de [fonctions], de [texte] et de classes.
Et nous reformulons la [tâche] à partir d’une [classification] du [texte] en bas ou haut pour classer le [texte], le résumé et la classe en vrai ou faux.
Ou en d’autres [mots], nous avons formé le [modèle de langue] pour classer un résumé et une classe en résumé et classe, si le résumé appartient à la classe ou non.
Donc dans ce cas, le [vecteur] d’étiquette consiste toujours en deux classes.
Et il s’agit de l’[algorithme] [pour] notre très bonne [approche] de [raffinement] reformulée.
Voyons le cadre complet.
Les [données] sont introduites dans [FeSTE].
Puis [FeSTE] exécute la phase de [liaison d’entités].
Il extrait le [texte] de la [base de connaissances], qui dans cet exemple est le résumé de la page [Wikipédia].
Ensuite, il a reformulé la [tâche] en une [tâche] de [classification des phrases] [par paire].
Il a appliqué le [modèle de langue] à la nouvelle [tâche] et la probabilité de sortie [pour] chaque classe.
Et maintenant, le [modèle de langue] est déjà raffiné sur des [données] n moins un en utilisant un [raffinement] [multitâche] préliminaire.
Ensuite, nous utilisons le [vecteur] de sortie du [modèle de langue] comme une fonction nouvellement [générée] dans le [nombre] de classes.
Pour évaluer notre cadre, nous utilisons dix-sept [données] de [classification] tabulaires qui varient en taille, [fonctions], équilibre, [domaine] et performance initiale.
Et en tant que [base de connaissances], nous utilisons [Wikipédia].
Nous concevons notre expérience comme une [évaluation] où nous formons [FeSTe] sur seize [données] et l’appliquons à la dix-septième [donnée].
Nous divisons également chaque [donnée] en quatre plis et appliquons une validation croisée de quatre plis.
Ensuite, nous générons les nouvelles [fonctions] et les évaluons en utilisant cinq [classificateurs] d’[évaluation].
Nous utilisons dans nos expériences l’architecture de base des [Représentations d'encodeurs bidirectionnels à partir de transformateurs].
Voici les résultats [de] nos expériences.
Vous pouvez voir que nous comparons notre cadre au [raffinement] des [données] [cibles], au [raffinement] de la [tâche] [cible] et à un [raffinement] préliminaire [MTDNN].
Et notre [raffinement] reformulé [atteint] le meilleur résultat et la meilleure performance.
Alors que le [MTDNN] a obtenu une amélioration de deux pour cent par rapport au [raffinement] des [données] [cibles].
Notre [approche] a obtenu une amélioration de six pour cent.
Lorsque nous regardons les petites [données], nous pouvons voir que la performance du [MTDNN] diminue et l’amélioration de la phase de [raffinement] [multitâche] préliminaire diminue aussi à un virgule cinq pour cent.
Mais notre performance a augmenté à onze pour cent [comparé] au [raffinement] de [tâche] [cible] seul.
[Pour] résumer, [FeSTE] permet un enrichissement en quelques coups à partir de trente-cinq échantillons dans nos expériences.
Il utilise une architecture [pour] toutes les [tâches] et [données].
Et il garde la tête du [modèle].
Mais cela ajoute une phase de reformulation.
Il augmente l’ensemble de formation et a besoin d’une valeur [cible] avec un [sens] [sémantique] afin que nous puissions l’introduire dans le [modèle de langue] et l’utiliser dans le [problème] de [classification] [par paire de phrases].
Merci.