Hallo zusammen. Heute werde ich unsere [Forschung]sarbeit [Learning] to Reason Deductively: [Math Word Problem] Solving as Complex [Relation Extraction] vorstellen.
Ich bin Allan vom ByteDance [AI] Lab, und dies ist eine gemeinsame Arbeit mit Jierui Li von der University of Texas in Austin und Wei Lu von [SUTD].
Zunächst möchte ich über unsere Motivation [für] das [Argumentieren] sprechen.
Deshalb zeigen wir hier ein Beispiel, bei dem mehrstufiges [Argumentieren] hilfreich ist.
Diese Abbildung stammt aus dem [PaLM]-[Paper], in dem sie Prompting durchführen, um das Netzwerk[problem] in einem Few-Shot-[Lern]szenario zu lösen.
Auf der linken Seite können wir also sehen, dass wenn einige Beispiele nur aus [Frage] und Antworten bestehen, dann bekommen wir nicht die richtigen Antworten.
Wenn wir jedoch eine weitere [Argumentation]sbeschreibung hinzufügen, ist das [Modell] in der Lage, die [Argumentation]sbeschreibung vorherzusagen und hier auch eine korrekte [Vorhersage] zu treffen.
Es ist also gut, eine [interpretierbare] mehrstufige [Argumentation] als Ergebnis zu haben.
Wir denken auch, dass [mathematische Wortprobleme] eine einfache Anwendung sind, um solche [Argumentation]sfähigkeiten zu bewerten.
In unserem [Problem]-Setup müssen wir also angesichts der [Fragen] diese [Frage] lösen und die numerischen Antworten erhalten.
In unseren [Datensätzen] finden wir auch den mathematischen Ausdruck, der uns zu dieser bestimmten [Antwort] führt.
Es gelten also auch hier bestimmte Annahmen wie in [früheren] Arbeiten.
Wir gehen davon aus, dass die Genauigkeit der Mengen bekannt ist.
Und wir betrachten nur grundlegende Operatoren wie Addition, Subtraktion, Multiplikation, Division und Exponentialrechnung.
[Darüber hinaus] können komplizierte Operatoren in diese Grundoperatoren zerlegt werden.
Die [früheren] Arbeiten zum Lösen von [mathematischen Wortproblemen] lassen sich also in [Sequenz]-zu-[Sequenz]- und [Sequenz]-zu-Baum-[Modell] einteilen.
Das traditionelle [Sequenz]-zu-[Sequenz]-[Modell] wandelt also den Ausdruck in eine spezifische [Sequenz] [für] die [Generierung] um.
Es ist ziemlich einfach zu implementieren und kann für viele verschiedene komplizierte [Probleme] [verallgemeinert] werden.
Die Nachteile sind jedoch, dass die Leistung im Allgemeinen nicht besser ist als die des [strukturierten] [Modells] und dass es an [Interpretierbarkeit] [für] [Vorhersagen] mangelt.
Aber eigentlich ist diese Richtung immer noch recht beliebt wegen des [Transformer][modell]s.
In baumbasierten [Modellen] [strukturieren] wir diese Ausdrücke in Baumform und folgen einem geordneten Traversal in Baumgenerationen.
Hier fahren wir also fort, die Operatoren zu [generieren], bis wir die Blätter erreichen, die die Mengen darstellen.
Das Gute daran ist, dass wir dadurch diese [binäre] Baum[struktur] erhalten. Sie ist eigentlich ziemlich kontraintuitiv, weil wir zuerst den Operator und dann am Ende die Mengen generieren müssen.
Zudem enthält sie auch einige sich wiederholende Berechnungen.
Wenn wir uns also diesen Ausdruck ansehen, wird 8 x 3 + 3 eigentlich zweimal [generiert], aber eigentlich sollten wir die Ergebnisse wiederverwenden.
In unserem vorgeschlagenen [Ansatz] wollen wir diese Probleme schrittweise und auf [interpretierbare] Art und Weise lösen.
Hier im zweiten Schritt [zum] Beispiel können wir diese Teiler erhalten, was 27 ergibt.
Wir können auch auf die ursprünglichen [Fragen] zurückgreifen, um die relevanten Inhalte zu finden.
In diesen Schritten erhalten wir die Teiler.
Und in diesem dritten Schritt erhalten wir dann den Quotienten.
Okay. Nach diesen drei Schritten können wir die Ergebnisse des zweiten Schritts wiederverwenden, dann die Ergebnisse des vierten Schritts erhalten und schließlich die Dividenden erhalten.
Hier wird also der gesamte Ausdruck direkt [generiert] und nicht nur ein einzelner Operator oder eine Menge.
Dadurch wird der Prozess genauer.
In unserem deduktiven [System] beginnen wir also zunächst mit einer Reihe von Mengen, die in den [Fragen] vorgestellt werden, und schließen auch mit einer Konstante als Anfangszustand.
Der Ausdruck wird also durch e i j o p dargestellt.
Wir führen den Operator von q_i nach q_j aus, und dieser Ausdruck ist tatsächlich geregelt.
Wir haben hier also auch eine Subtraktion mit [Wörtern], um die umgekehrte Richtung darzustellen.
Dies ist der [Beziehungsextraktion] recht [ähnlich].
In einem formalen deduktiven [System] wenden wir also in einem Zeitschritt t den Operator zwischen dem Paar q_i und q_j an und erhalten dann diesen neuen Ausdruck.
Wir fügen ihn dem nächsten Zustand hinzu, um eine neue Menge zu erhalten.
Diese Folien veranschaulichen also die Entwicklung des Zustands, wobei wir dem aktuellen Zustand immer neue Ausdrücke hinzufügen.
In unseren [Modell]implementierungen verwenden wir also zunächst ein [vortrainiertes Sprach][modell], bei dem es sich um [BERTs] oder Robertas handeln kann, und dann [kodieren] wir den [Satz] und erhalten diese Mengen[darstellungen].
Sobald wir also die Mengen[darstellungen] haben, können wir mit der [Inferenz] beginnen.
Hier zeigen wir ein Beispiel für q_1, um die [Darstellung] [für] q_2 geteilt durch q_2 und dann mal q_3 zu erhalten.
Zunächst erhalten wir die Paar[darstellung], die im Grunde nur die [Verkettung] zwischen q_1 und q_2 ist, und dann wenden wir ein Feedforward-Netzwerk an, das durch den Operator parametrisiert ist.
Und dann erhalten wir schließlich die Ausdrucks[darstellung] q_1 geteilt durch q_2.
Aber in der Praxis könnten wir in der [Inferenz]phase auch den falschen Ausdruck erhalten.
Hier sind also alle möglichen Ausdrücke gleich dem Dreifachen der [Anzahl] der Operatoren.
Das Schöne daran ist, dass wir leicht Einschränkungen hinzufügen können, um diesen [Such]raum zu kontrollieren.
Wenn dieser Ausdruck [zum] Beispiel nicht erlaubt ist, können wir ihn einfach aus unserem [Such]raum entfernen.
Im zweiten Schritt machen wir das Gleiche, aber der einzige Unterschied ist, dass wir nur eine Menge mehr haben.
Diese Menge stammt also aus dem [vorherigen] berechneten Ausdruck.
So können wir schließlich diesen endgültigen Ausdruck q_3 mal q_4 erhalten.
Wir können auch sehen, dass die [Anzahl] aller möglichen Ausdrücke anders ist als beim [vorherigen] Schritt.
Ein solcher Unterschied erschwert die Anwendung von einer [Beam Search], da die Wahrscheinlichkeitsverteilung zwischen diesen beiden Schritten unausgewogen ist.
Das [Trainings]verfahren ist also [ähnlich] dem [Training] eines [Sequenz]-zu-[Sequenz]-[Modells], bei dem wir den Verlust bei jedem Zeitschritt optimieren.
Auch hier verwenden wir dieses Tau, um darzustellen, wann wir diesen [Generierung]sprozess beenden sollten.
Hier unterscheidet sich der Raum von [Sequenz] zu [Sequenz], weil der Raum bei jedem Zeitschritt anders ist, während im traditionellen [Sequenz]-zu-[Sequenz]-[Modell] dies die [Anzahl] des [Vokabulars] ist.
Es erlaubt uns auch, bestimmte Beschränkungen aus dem Vor[wissen] aufzuerlegen.
Daher führen wir Experimente mit den häufig verwendeten [Datensätzen] der [mathematischen Wortprobleme] durch, [MAWPS], Math23K, [MathQA] und [SVAMP].
Hier zeigen wir kurz die Ergebnisse [im Vergleich zu] den [bisherigen] besten Ansätzen.
Unsere leistungsstärkste Variante ist also Roberta-DeductiveReasoner.
Tatsächlich verwenden wir keine [Beam Search], im Gegensatz zu allen [früheren] Ansätzen, die [Beam Search] verwendet haben.
Okay. Daher sind die besten Ansätze oft baumbasierte [Modelle].
Insgesamt ist unser Reasoner also in der Lage, dieses baumbasierte [Modell] signifikant zu übertreffen.
Aber wir können sehen, dass die absoluten Zahlen bei [MathQA] oder [SVAMP] nicht wirklich hoch sind.
Deshalb untersuchen wir die Ergebnisse bei [SVAMP] weiter.
Dieser [Datensatz] ist eine Herausforderung, weil der Autor versucht hat, [manuell] etwas hinzuzufügen, um das [NLP]-[Modell] zu verwirren, wie z. B. das Hinzufügen irrelevanter [Informationen] und zusätzlicher Mengen.
In unserer [Vorhersage] stellen wir also fest, dass einige der Zwischenwerte eigentlich negativ sind.
[Zum] Beispiel geht es in diesen [Fragen] darum, wie viele Äpfel Jake hat.
Aber wir haben einige zusätzliche [Informationen] wie 17 Bilder weniger, und Steven hat acht Bilder, was völlig irrelevant ist.
Unser [Modell] macht also eine [Vorhersage] wie diese, die negative Werte ergibt.
Wir stellen fest, dass diese beiden Ausdrücke tatsächlich [ähnliche] Werte haben.
Wir können also diesen [Such]raum eingrenzen, indem wir die negativen Ergebnisse entfernen, damit die [Antwort] richtig ist.
Wir stellen also fest, dass eine solche [Bedingung] [für] einige [Modelle] tatsächlich eine erhebliche Verbesserung darstellt.
[Bei] [BERT] haben wir uns [zum] Beispiel um sieben Punkte verbessert und [beim] Roberta-Basis[modell] haben wir uns sogar um zwei Punkte verbessert.
Ein besseres [Sprachmodell] hat also bessere [Sprachverständnis]fähigkeiten, sodass die [Zahl] hier höher [bei] Roberta und niedriger [bei] [BERT] ist.
Wir versuchen auch, die Schwierigkeiten hinter all diesen [Datensätzen] zu analysieren.
Wir gehen davon aus, dass die [Anzahl] der ungenutzten Mengen hier als irrelevante [Informationen] betrachtet werden kann.
Hier können wir also sehen, dass wir den Prozentsatz der Proben mit ungenutzten Mengen haben, und der [SVAMP]-[Datensatz] hat den größten Anteil.
Hier zeigen wir auch die Gesamtleistung.
[Bei] den Proben ohne ungenutzte Mengen ist die Leistung sogar höher als die Gesamtleistung.
Aber bei diesen Proben mit ungenutzten Mengen ist sie eigentlich viel schlechter als die Gesamtleistung.
[Bei] [MAWPS] haben wir nicht wirklich viele Testfälle, also ignoriere ich diesen Teil einfach.
Schließlich wollen wir die [Interpretierbarkeit] anhand eines [Frage]-Störungsbeispiels zeigen.
Hier macht unser [Modell] also tatsächlich eine falsche [Vorhersage] im ersten Schritt.
Wir können diesen Ausdruck also tatsächlich mit dem [Satz] hier korrelieren. Okay.
Wir denken also, dass dieser [Satz] das [Modell] zu falschen Vorhersagen verleiten könnte.
Hier führt eine weitere 35 dazu, dass das [Modell] denkt, dass es ein Additionsoperator sein sollte.
Wir versuchen also den [Satz] so umzuformulieren, dass die [Anzahl] der Birnbäume um 35 weniger als die der Apfelbäume ist.
Wir sorgen also dafür, dass eine genauere [Semantik] vermittelt wird, sodass das [Modell] in der Lage ist, die [Vorhersage] korrekt zu treffen.
Diese Studie zeigt also, wie uns die [interpretierbaren] Vorhersagen helfen, das [Modell]verhalten zu verstehen.
Um unsere Arbeit abzuschließen: Zunächst ist unser [Modell] tatsächlich ziemlich effizient.
Wir sind in der Lage, ein [interpretierbares] Lösungsverfahren anzubieten.
Wir können einfach einiges Vor[wissen] als [Bedingung] einbeziehen, was zur Verbesserung der Leistung beitragen kann.
Schließlich gilt der zugrundeliegende Mechanismus nicht nur für das Lösen von Netzwerk[problemen], sondern auch für andere [Aufgaben], die mehrstufiges [Argumentieren] erfordern.
Auch sind uns gewisse Grenzen gesetzt.
Wenn wir eine [große] [Anzahl] von Operatoren oder Konstanten haben, könnte der Speicherverbrauch ziemlich hoch sein.
Wie bereits erwähnt ist es zudem aufgrund der unausgewogenen Wahrscheinlichkeitsverteilung zwischen den verschiedenen Zeitschritten eine ziemliche Herausforderung, die [Beam Search]-Strategie anzuwenden.
Wir sind am Ende des Vortrags angekommen und freuen uns auf etwaige [Fragen]. Vielen Dank!
Hallo, mein Name ist Antoine und ich bin von der Universität Maastricht.
Ich werde meine gemeinsame Arbeit mit Jerry vorstellen, bei der es um einen neuen [Datensatz] [für] das [Retrieval] von Gesetzesartikeln geht.
Rechtsfragen sind ein wesentlicher Bestandteil des Lebens vieler Menschen.
Aber die Mehrheit der Bürger verfügt nur über wenig [Wissen] über ihre Rechte und grundlegende rechtliche Verfahren.
Dies hat zur Folge, dass viele schutzbedürftige Bürger, die sich die kostspielige Hilfe eines Rechtsexperten nicht leisten können, schutzlos bleiben oder schlimmstenfalls ausgebeutet werden.
Unsere Arbeit zielt darauf ab, die Kluft zwischen den Menschen und dem Gesetz zu überbrücken, indem ein effektives [Retrieval]-[System] [für] Gesetzesartikel entwickelt wird.
Ein solches [System] könnte einen kostenlosen professionellen Rechtshilfedienst [für] unerfahrene Menschen anbieten.
Bevor wir uns dem Hauptbeitrag dieser Arbeit widmen, wollen wir zunächst das [Problem] des [Retrievals] von Gesetzesartikeln beschreiben.
Eine einfache [Frage] zu einer Rechtsangelegenheit wäre: „Was riskiere ich, wenn ich das Berufsgeheimnis verletze?“
Hier wird ein [Modell] benötigt, um alle relevanten Gesetzesartikel aus einem [großen] Bestand an Rechtsvorschriften abzurufen.
Diese [Informationsbeschaffung]s[aufgabe] bringt eine Reihe von Herausforderungen mit sich.
Erstens: Es geht um zwei Arten von [Sprache].
Die gemeinsame [natürliche Sprache] [für] die [Fragen] und die komplexe juristische [Sprache] [für] die Gesetze.
Dieser Unterschied bei den [Sprach][verteilungen] macht es [für] ein [System] schwieriger, relevante Kandidaten zu finden, da es indirekt ein inhärentes Interpretations[system] erfordert, das eine [natürliche] [Frage] in eine rechtliche [Frage] übersetzen kann, die der [Terminologie] der Gesetze entspricht.
Außerdem ist das Recht keine Ansammlung unabhängiger Artikel, die für sich allein als vollständige [Information]s[quelle] betrachtet werden können, anders als [beispielsweise] [Nachrichten] oder Rezepte.
Vielmehr handelt es sich um eine [strukturierte] Sammlung von Rechtsvorschriften, die nur im Gesamt[kontext], d. h. zusammen mit den ergänzenden [Informationen] aus den Nachbarartikeln, den Bereichen und Teilbereichen, denen sie angehören, und ihrer Stellung im [Aufbau] des Gesetzes, eine vollständige [Bedeutung] haben.
Schließlich handelt es sich bei den Gesetzesartikeln nicht um kleine Absätze, die in den meisten [Retrieval]-Arbeiten die typische [Retrieval]-Einheit darstellen.
Hier gibt es lange [Dokumente], die bis zu 6.000 [Wörter] umfassen können.
Die [jüngsten Fortschritte] im Bereich [NLP] haben großes Interesse an vielen juristischen [Aufgaben] geweckt, z. B. an der [Vorhersage] juristischer Urteile oder der automatisierten Prüfung von Verträgen.
Doch das [Retrieval] von Gesetzesartikeln ist aufgrund des Mangels an [großen] und [qualitativ] hochwertig [markierten] [Datensätzen] weitgehend unberührt geblieben.
In dieser Arbeit stellen wir einen neuen [Datensatz] in der [französischen] Muttersprache vor, mit dem wir [Retrieval][modelle] untersuchen und analysieren, ob sie [bei] der [Aufgabe] der [Suche] nach Gesetzesartikeln an die Effizienz und Zuverlässigkeit eines Rechtsexperten rankommen können.
Unser belgischer [Datensatz] für das [Retrieval] von Gesetzesartikeln, [BSARD], besteht aus mehr als 1.100 juristischen [Fragen], die von belgischen Bürgern gestellt wurden.
Diese [Fragen] decken ein [breites Spektrum] an Themen ab, von Familie, Wohnen, Geld bis hin zu Arbeit und [sozialer] Sicherheit.
Jede von ihnen wurde von erfahrenen Juristen mit Verweisen auf relevante Artikel aus einem [Korpus] von mehr als 22.600 Rechtsartikeln aus belgischen Gesetzbüchern [markiert].
Lassen Sie uns nun darüber sprechen, wie wir diesen [Datensatz] gesammelt haben.
Zunächst haben wir einen [großen] [Korpus] von Rechtsartikeln zusammengestellt.
Wir haben 32 öffentlich zugängliche belgische Gesetzbücher berücksichtigt und alle Artikel sowie die [entsprechenden] Abschnittsüberschriften [extrahiert].
Dann haben wir rechtliche [Fragen] mit Verweisen auf einschlägige Gesetze zusammengestellt.
Zu diesem Zweck arbeiten wir mit einer belgischen Anwaltskanzlei zusammen, die jedes Jahr etwa 4.000 E-Mails von belgischen Bürgern erhält, die [um] Rat in einer persönlichen Rechtsangelegenheit bitten.
Wir hatten das Glück, Zugang zu ihren Websites zu erhalten, auf denen ihr Team aus erfahrenen Juristen die häufigsten Rechtsangelegenheiten der Belgier behandelt.
Wir haben Tausende von [Fragen] gesammelt und mit Kategorien, Unterkategorien und Verweisen auf einschlägige Gesetze [annotiert].
Schließlich haben wir die rechtlichen Verweise überprüft und die [Fragen] herausgefiltert, deren Verweise nicht in einem der von uns berücksichtigten Gesetzbücher enthalten waren.
Die übrigen Referenzen wurden zusammengeführt und in die [entsprechenden] Artikel-IDs aus unserem [Korpus] umgewandelt.
Am Ende hatten wir 1.108 [Fragen], jede sorgfältig [markiert] mit den IDs der relevanten Artikel aus unserem [großen] [Korpus] von 22.630 Gesetzesartikeln.
Darüber hinaus enthält jede [Frage] eine Hauptkategorie und eine [Verkettung] von Unterkategorien.
Jeder Artikel hat eine [Verkettung] mit der anschließenden Überschrift im [Aufbau] des Gesetzes.
Diese zusätzlichen [Informationen] werden in der vorliegenden Arbeit nicht verwendet, könnten aber [für] künftige [Forschungen] zum juristischen [Informationen-Retrieval] oder zur juristischen [Textklassifikation] von Interesse sein.
Schauen wir uns einige Merkmale unseres [Datensatzes] an.
Die [Fragen] sind zwischen fünf und 24 [Wörter] lang, mit einem Mittelwert von 14 [Wörtern].
Die Artikel sind mit einer durchschnittlichen Länge von 77 [Wörtern] sehr viel länger, wobei 142 von ihnen mehr als 1.000 [Wörter] umfassen.
Der längste von ihnen hat bis zu 5.790 [Wörter].
Wie bereits erwähnt decken die [Fragen] ein [breites Spektrum] an Themen ab, wobei etwa 85 Prozent der Fragen entweder die Familie, das Wohnen, Geld oder die Gerechtigkeit betreffen.
Die restlichen 15 Prozent betreffen entweder [soziale] Sicherheit, Ausländer oder Arbeit.
Die Artikel sind auch sehr vielfältig, da sie aus 32 verschiedenen belgischen Gesetzbüchern stammen, die eine [große] [Reihe] von Rechtsthemen abdecken.
Hier ist die Gesamt[zahl] der Artikel, die aus diesen belgischen Gesetzbüchern gesammelt wurden.
Von den 22.633 Artikeln werden nur 1.612 als relevant für mindestens eine [Frage] im [Datensatz] genannt.
Etwa 80 Prozent dieser zitierten Artikel stammen entweder aus dem Zivilgesetzbuch, dem Gerichtsgesetzbuch, dem Gesetzbuch für strafrechtliche Ermittlungen oder dem Strafgesetzbuch.
Bei 18 von 32 Gesetzbüchern werden weniger als fünf Artikel als relevant für mindestens eine [Frage] bestimmt.
Dies lässt sich dadurch erklären, dass diese Gesetzbücher weniger auf den Einzelnen und seine Anliegen ausgerichtet waren.
Insgesamt liegt der Durchschnitt der [Anzahl] der Zitate [bei] zwei, und weniger als 25 Prozent der zitierten Artikel werden mehr als fünfmal zitiert.
Unter Verwendung aller [Datensätze] haben wir verschiedene [Retrieval]-Ansätze, einschließlich [lexikalischer] und dichter Architektur, einem Benchmarking unterzogen.
Bei einer [Abfrage] und einem Artikel weist ein [lexikalisches] [Modell] dem [Abfrage]-Artikel-Paar eine Punktzahl zu, indem es die Summe der [Gewichtungen] von jedem der Begriffe in diesem Artikel über die [Abfrage]-Termini berechnet.
Wir experimentieren mit den Standard-Ranking-Funktionen TF-[IDF] und BM25.
Das Haupt[problem] bei diesen Ansätzen ist, dass sie nur Artikel finden können, die Schlüsselwörter enthalten, die in der [Anfrage] vorkommen.
Um diese Einschränkung zu überwinden, experimentieren wir mit einer [neuronal]-basierten Architektur, die [semantische] Beziehungen zwischen [Abfragen] und Artikeln erfassen kann.
Wir verwenden ein Bi-[Encoder]-[Modell], das [Abfragen] und Artikel in dichten [Vektor]-[Darstellungen] abbildet und einen Relevanzwert zwischen einem [Abfrage]-Artikel-Paar anhand der [Ähnlichkeit] ihrer [Einbettungen] berechnet.
Diese [Einbettungen] resultieren in der Regel aus einer Pooling-Operation auf der Ausgabe eines [Worteinbettung]s[modells].
Zunächst untersuchen wir die Effektivität von Siamesischen Bi-[Encodern] in einem Zero-Shot-[Evaluation]-Setup, [d. h.] dass [vortrainierte] [Worteinbettung]s[modelle] ohne zusätzliche [Feinabstimmung] sofort angewendet werden.
Wir experimentieren mit [kontext]unabhängigen [Text][encodern], [wie] [word2vec] und fastText, und [kontext]abhängigen [Einbettung]s[modellen], [wie] Roberta und insbesondere [CamemBERT], einem [französischen] Roberta-[Modell].
[Darüber hinaus] trainieren wir unser eigenes, auf [CamemBERT] basierendes [Modell], Bi-[Encoder], auf unserem [Datensatz].
Beachten Sie, dass wir [beim] [Training] mit den beiden Varianten der Bi-[Encoder]-Architektur experimentieren.
Siamese, das ein einzigartiges [Worteinbettung]s[modell] verwendet, das die [Abfrage] und den Artikel zusammen in einem [geteilten] dichten [Vektorraum] abbildet, und Two-Tower, das zwei unabhängige [Worteinbettung]s[modelle] verwendet, die die [Abfrage] und den Artikel getrennt in verschiedenen [Einbettung]sräumen [kodieren].
Wir experimentieren mit Mittelwert, Maximalwert und [CLS]-Pooling sowie mit Produkt und [Kosinus] [für] die Berechnung von Ähnlichkeiten.
Hier sind die Ergebnisse unserer Baseline auf den Testsätzen.
Die [lexikalischen] [Methoden] werden oben, die Siamesischen Bi-[Encoder] in einem Zero-Shot-Setup in der Mitte und die fein abgestimmten Bi-[Encoder] werden unten ausgewertet.
Insgesamt übertrifft der fein abgestimmte Bi-[Encoder] alle anderen [Baselines] deutlich.
Das Two-Tower-[Modell] verbessert sich gegenüber seinen Siamesischen Varianten beim Recall um 100, schneidet aber bei den anderen [Metriken] ähnlich gut ab.
Obwohl BM25 deutlich schlechter abschnitt als der trainierte Bi-[Encoder], zeigte seine Leistung, dass er immer noch eine gute Basis [für] ein [domänen]spezifisches [Retrieval] ist.
Bezüglich der Zero-Shot-[Evaluation] des Siamesischen Bi-[Encoders] stellen wir fest, dass die direkte Verwendung der [Einbettungen] eines [vortrainierten] [CamemBERT]-[Modells] ohne Optimierung [für] die [Informationen-Retrieval]-[Aufgabe] schlechte Ergebnisse liefert, was mit [früheren] Erkenntnissen übereinstimmt.
[Darüber hinaus] stellen wir fest, dass der [word2vec]-basierte Bi-[Encoder] die fastText- und [BERT]-basierten [Modelle] signifikant übertrifft, was darauf hindeutet, dass [vortrainierte] [Wort]-Ebenen-[Einbettungen] vielleicht besser [für] die [Aufgabe] geeignet sind als Zeichen- oder [Unterwort]-Ebenen-[Einbettungen], wenn sie direkt verwendet werden.
Obwohl diese Ergebnisse vielversprechend sind, lassen sie [im Vergleich zu] einem erfahrenen Rechtsexperten [auf] ein großes Verbesserungspotenzial schließen, der früher oder später alle relevanten Artikel zu jeder [Frage] abrufen kann und somit perfekte Ergebnisse erzielt.
Abschließend möchte ich auf zwei Einschränkungen unseres [Datensatzes] eingehen.
Erstens ist der Artikel[korpus] auf die Artikel der 32 herangezogenen belgischen Gesetzbücher beschränkt, was nicht das gesamte belgische Recht abdeckt, da Artikel aus Dekreten, Richtlinien und Verordnungen fehlen.
Bei der Erstellung des [Datensatzes] werden alle Verweise auf diese nicht erfassten Artikel ignoriert, was dazu führt, dass sich einige [Fragen] am Ende nur auf einen Bruchteil der ursprünglichen [Anzahl] der relevanten Artikel beziehen.
Diese [Information] impliziert also, dass die [Antwort], die in den übrigen relevanten Artikeln enthalten ist, unvollständig sein könnte, obwohl sie immer noch völlig angemessen ist.
Zweitens sollten wir beachten, dass nicht alle rechtlichen [Fragen] allein mit Gesetzen beantwortet werden können.
[Zum] Beispiel die [Frage]: „Kann ich meinen Mietern kündigen, wenn sie zu viel Lärm machen?“
Möglicherweise gibt es im Gesetz keine detaillierte [Antwort], die eine bestimmte Lärmschwelle festlegt, ab der eine Räumung zulässig ist.
Stattdessen sollte sich der Vermieter wahrscheinlich eher auf das Fallrecht stützen und Präzedenzfälle finden, die seiner aktuellen Situation [ähnlich] sind.
[Zum] Beispiel veranstalten die Mieter zwei Partys pro Woche bis zwei Uhr morgens.
Einige [Fragen] eignen sich [daher] besser als andere für die [Aufgabe] des [Retrievals] von Gesetzesartikeln. Die [Domäne] der weniger geeigneten Fragen muss noch bestimmt werden.
Wir hoffen, dass unsere Arbeit das Interesse an der Entwicklung praktischer und zuverlässiger [Modelle] für das [Retrieval] von Gesetzesartikeln weckt.
Sie kann dazu beitragen, den Zugang zur Justiz [für] alle zu verbessern.
Sie können unser [Paper], den [Datensatz] und die Gesetzbücher unter den folgenden Links einsehen. Vielen Dank!
Hallo, wir freuen uns, Ihnen unsere Arbeit über [VALSE] vorstellen zu können. Das ist ein [Aufgaben]-unabhängiger Benchmark, der [für] das Testen von Seh- und [Sprachmodellen] mit spezifischen [sprachlichen] Phänomenen konzipiert ist.
Warum haben wir uns die Mühe gemacht, diesen Benchmark einzurichten?
In den letzten Jahren haben wir eine explosionsartige Zunahme von [Transformer]-basierten Seh- und [Sprachmodellen] erlebt, die mit [großen] Mengen an [Bild]-[Text]-Paaren [vortrainiert] wurden.
Jedes dieser [Modelle] treibt den Fortschritt bei Seh- und [Sprach][aufgaben] voran, wie z. B. die [visuelle Fragenbeantwortung], das [Argumentieren] mit [visuellem] [Menschenverstand], [Bild]-[Retrieval], [Phrasen]-[Erdung].
Wir haben also die Nachricht erhalten, dass die Genauigkeiten bei diesen [Aufgaben] und spezifischen Benchmarks stetig steigen.
Aber wissen wir, was die [Modelle] tatsächlich gelernt haben?
Was hat ein Seh- und [Sprach-][Transformer] verstanden, wenn er [für] dieses [Bild] und diesen [Satz] eine hohe Punktzahl zuweist?
Und [hier] eine niedrige Punktzahl?
Konzentrieren sich Seh- und [Sprachmodelle] auf die wesentlichen Punkte?
Oder konzentrieren sie sich auf [Verzerrungen], wie in [früheren] Arbeiten aufgezeigt wurde?
Um diesen [Aspekt] näher zu beleuchten, [schlagen] wir eine eher [aufgabenbezogene] agnostische Richtung vor und führen [VALSE] ein, das die Empfindlichkeit von Seh- und [Sprachmodellen] für spezifische [sprachliche] Phänomene testet, die sowohl die [sprachlichen] als auch die [visuellen] [Modalitäten] betreffen.
Wir [zielen] auf Existenz, Pluralität, Zählung, [räumliche] [Beziehungen], Handlungen und [Entity]-[Koreferenz] ab.
Doch wie lässt sich überprüfen, ob die Seh- und [Sprachmodelle] dieses Phänomen erfasst haben?
Das Verfälschen einer [Methode] wurde zuvor von Ravi Shekhar und Mitarbeitern nur [für] [Substantiv]phrasen [in] den Seh- und [Sprachmodellen] und beim Zählen von uns in [früheren] Arbeiten angewandt.
Verfälschen bedeutet im Grunde, dass wir die Beschriftung eines [Bildes] nehmen und eine Verfälschung erzeugen, indem wir die Beschriftung so verändern, dass sie das [Bild] nicht mehr beschreibt.
Wir führen diese Veränderungen der [Phrase] durch, indem wir uns auf sechs spezifische Teile konzentrieren, wie Existenz, Pluralität, Zählung, [räumliche] [Relationen], Handlungen und [Entität]-[Koreferenz], wobei jeder Teil aus einem oder mehreren Instrumenten bestehen kann, falls wir mehr als einen interessanten Weg gefunden haben, um Verfälschungsinstanzen zu erzeugen.
[Zum] Beispiel haben wir im Fall des Handlungsteils zwei Instrumente, eines, bei dem das Handlungs[verb] durch eine andere Handlung ersetzt wird, und eines, bei dem die Aktanten ausgetauscht werden.
Zählung und [Koreferenz] sind auch Teile, die mehr als ein Instrument haben.
Wir erstellen diese Verfälschungen, indem wir sicherstellen, dass sie das [Bild] nicht beschreiben, dass sie [grammatikalisch] richtig sind und auch korrekte [Sätze] bilden.
Das ist nicht einfach zu bewerkstelligen, denn eine verfälschte Beschriftung ist weniger wahrscheinlich als die ursprüngliche Beschriftung.
Es ist zwar [zum] Beispiel nicht unmöglich, aber statistisch gesehen ist es unwahrscheinlicher, [dass] Pflanzen einen Menschen schneiden, als dass ein Mensch Pflanzen schneidet. [Große] Seh- und [Sprachmodelle] könnten dies erkennen.
[Daher] müssen wir handeln, wenn wir gültige Verfälschungen erhalten wollen.
Erstens nutzen wir starke [Sprachmodelle], um Verfälschungen [vorzuschlagen].
Zweitens verwenden wir die [Inferenz der natürlichen Sprache] oder kurz [NLI], um Verfälschungen herauszufiltern, die das [Bild] noch beschreiben könnten. Bei der Konstruktion von Verfälschungen müssen wir sicherstellen, dass sie das [Bild] nicht beschreiben.
Um dies [automatisch] zu testen, wenden wir die [Inferenz der natürlichen Sprache] mit der folgenden Logik an.
Wir betrachten ein [Bild] als die Prämisse und seine Beschriftung als die daraus abgeleitete Hypothese.
Darüber hinaus betrachten wir die Beschriftung als Prämisse und die Verfälschung als ihre Hypothese.
Wenn ein [NLI]-[Modell] vorhersagt, dass die Verfälschung der Beschriftung widerspricht oder neutral ist, ist das für uns ein Indikator für eine gültige Verfälschung.
Wenn ein [NLI] vorhersagt, dass die Verfälschung die Beschriftung beinhaltet, kann es keine gute Verfälschung sein, da sie durch Transitivität eine wahrheitsgemäße Beschreibung des [Bildes] liefert. Wir filtern diese Verfälschungen heraus.
Dieses Verfahren ist aber nicht perfekt, sondern nur ein Indikator [für] gültige Verfälschungen.
[Daher] setzen wir als dritte Maßnahme [zur] [Generierung] gültiger Verfälschungen [menschliche] [Annotatoren] ein, um die in [VALSE] verwendeten [Daten] zu validieren.
Nach dem Filtern und der [menschlichen Evaluation] haben wir also so viele Testinstanzen, wie in dieser Tabelle beschrieben.
Beachten Sie hier, dass [VALSE] keine [Trainingsdaten], sondern nur Test[daten] liefert.
Da es sich um einen reinen Zero-Shot-Test-Benchmark handelt, ist er so konzipiert, dass er die [bestehenden] Fähigkeiten der Seh- und [Sprachmodelle] nach dem [Vortraining] nutzt.
Die [Feinabstimmung] würde es den [Modellen] nur ermöglichen, Artefakte oder [statistische] [Verzerrungen] in den [Daten] auszunutzen.
Wir alle wissen, dass diese [Modells] gerne schummeln und Abkürzungen nehmen.
Wie wir schon erwähnten, sind wir an der [Bewertung] interessiert, welche Fähigkeiten die Seh- und [Sprachmodelle] nach dem [Vortraining] haben.
Wir experimentieren mit fünf Seh- und [Sprachmodellen] auf [VALSE], [nämlich] mit [CLIP], [LXMert], [ViLBERT], [ViLBERT] zwölf in einem und [VisualBERT].
Zwei unserer wichtigsten [Evaluation]s[metriken] sind die Genauigkeit der [Modelle] bei der [Klassifikation] von [Bild]-[Satz]-Paaren in Bild[beschreibungen] und Verfälschungen.
Vielleicht ist es [für] dieses Video relevanter, unsere tolerantere Metrik vorzustellen, die [paarweise] Genauigkeit. Diese misst, ob die [Bild]-[Satz-Ausrichtung] [für] das korrekte [Bild]-[Text]-Paar größer ist als [für] sein Verfälschungspaar.
Weitere [Metriken] und Ergebnisse [dazu] finden Sie in unserem [Paper].
Die Ergebnisse mit [paarweiser] Genauigkeit werden hier gezeigt und stimmen mit den Ergebnissen überein, die wir von den anderen [Metriken] erhalten haben, nämlich dass die beste Zero-Shot-Leistung von [ViLBERT] zwölf zu eins erreicht wird, gefolgt von [ViLBERT], [LXMert], [CLIP] und schließlich [VisualBERT].
Es ist bemerkenswert, wie Instrumente, die sich auf die einzelnen Objekte konzentrieren, wie Existenz und [Substantiv]phrasen, von [ViLBERT] zwölf zu eins fast gelöst werden. Das unterstreicht, dass [Modelle] in der Lage sind, [benannte] Objekte und ihre Existenz in Bildern zu [identifizieren].
Keines der verbleibenden Teile kann jedoch in unseren [gegnerischen] Verfälschungseinstellungen zuverlässig gelöst werden.
Wir sehen an den Instrumenten der Pluralität und der Zählung, dass Seh- und [Sprachmodelle] Schwierigkeiten haben, Verweise auf einzelne und mehrere Objekte zu unterscheiden oder sie in einem [Bild] zu zählen.
Der [Relationen]-Teil zeigt, dass sie Schwierigkeiten haben, eine [benannte] [räumliche] [Relation] zwischen Objekten in einem [Bild] richtig zu [klassifizieren].
Sie haben auch Schwierigkeiten, Handlungen zu unterscheiden und ihre Teilnehmer zu [identifizieren], selbst wenn sie durch Plausibilitäts[bias] unterstützt werden, wie wir bei dem Handlung-Teil sehen.
Beim [Koreferenz]-Teil geht hervor, dass die Verfolgung mehrerer Verweise auf dasselbe Objekt in einem [Bild] unter Verwendung von [Pronomen] auch [für] die Seh- und [Sprachmodelle] schwierig ist.
Zur Überprüfung der Korrektheit und weil es ein interessantes Experiment ist, vergleichen wir auch zwei reine [Text][modelle], [GPT] 1 und [GPT] 2. So wollen wir feststellen, ob [VALSE] durch diese unimodalen [Modelle] lösbar ist. Wir berechnen die [Perplexität] der korrekten und der verfälschten Beschriftung, ohne [Bild], um den Eintrag mit der niedrigsten [Perplexität] vorherzusagen.
Wenn die [Perplexität] [bei] der Verfälschung höher ist, ist das für uns ein Hinweis, dass die verfälschte Beschriftung möglicherweise unter Plausibilitätsverzerrungen oder anderen [sprachlichen] [Verzerrungen] leidet.
Es ist interessant zu sehen, dass in einigen Fällen die [GPT]-[Modelle] mit reinem [Text] die Plausibilität der Welt besser erfasst haben als die Seh- und [Sprachmodelle].
Zusammenfassend lässt sich sagen, dass [VALSE] ein Benchmark ist, der durch das Objektiv von [linguistischen] Konstrukten schaut, um die Gemeinschaft bei der Verbesserung von Seh- und [Sprachmodellen] zu unterstützen, indem er ihre [visuelle] [Erdung] hart testet.
Unsere Experimente zeigen, dass Seh- und [Sprachmodelle] [benannte] Objekte und ihre Existenz in Bildern gut erkennen, wie der Existenzteil zeigt. Sie haben aber Schwierigkeiten damit, ihre gegenseitige Abhängigkeit und Beziehungen in [visuellen] Szenen zu begründen, wenn sie gezwungen sind, [sprachliche] Indikatoren zu berücksichtigen.
Wir möchten die Community wirklich dazu ermutigen, [VALSE] [für] die Messung des Fortschritts von [Sprach-] [Erdung] mit Seh- und [Sprachmodellen] zu nutzen.
Zudem könnte [VALSE] als indirekte Bewertung von [Datensätzen] verwendet werden, da [Modelle] vor und nach dem [Training] oder der [Feinabstimmung] bewertet werden könnten. So kann kontrolliert werden, ob ein [Datensatz] dazu beiträgt, dass sich [Modelle] in einem der von [VALSE] getesteten Aspekte verbessern.
Wenn Sie Interesse haben, schauen Sie sich die [VALSE]-[Daten] auf GitHub an. Wenn Sie irgendwelche [Fragen] haben, zögern Sie nicht, uns zu kontaktieren.
Hallo, mein Name ist Kamezawa von der Universität Tokio.
Ich werde folgendes [Paper] vorstellen: [RNSum]: A [Large]-Scale [Dataset] [for] [Automatic] Release Note [Generation] via Commit Logs [Summarization].
Ich werde es in dieser Reihenfolge erklären.
Zunächst werde ich die [automatische] [Generierung] von Versionshinweisen vorstellen, an der wir in dieser [Forschung] arbeiten.
Ein Versionshinweis ist ein technisches [Dokument], das die Änderungen zusammenfasst, die mit jeder Version eines Softwareprodukts vertrieben werden.
Das [Bild] zeigt einen Versionshinweis [für] Version 2.6.4 der Vuejs-Bibliothek.
Versionshinweise spielen bei der [Open-Source-]Entwicklung eine wichtige Rolle, aber ihre Erstellung ist [manuell] zeitaufwändig.
[Daher] wäre es sehr nützlich, wenn man [automatisch] [qualitativ] hochwertige Versionshinweise generieren könnte.
Ich werde zwei [frühere] Untersuchungen zur [automatischen] [Generierung] von Versionshinweisen erwähnen.
Zuerst gibt es ein [System] mit dem Namen [ARENA], das im Jahr 2014 veröffentlicht wurde.
Es verfolgt einen regelbasierten [Ansatz], indem es [zum] Beispiel den Change-[Extractor] verwendet, um alle Unterschiede, Bibliotheksänderungen und [Dokument]änderungen aus den verschiedenen Versionen zu extrahieren und sie schließlich zu kombinieren.
Die auffälligste Funktion dieses [Systems] ist der Ausgabe-[Extraktor] in der oberen rechten Ecke.
Dies muss Jira, dem Fehlerverwaltungs[system], überlassen werden und kann nur auf Projekte angewendet werden, die Jira verwenden.
Mit anderen [Worten]: Es kann nicht [für] viele Projekte auf GitHub verwendet werden.
Das zweite ist Glyph, das kürzlich in 2020 angekündigt wurde.
Es ist im [Internet] verfügbar und kann über pip installiert werden.
Dieses [System] verfügt über ein einfaches, [lern]basiertes [Textklassifikation]s[modell] und [gibt] eine von fünf Markierung wie [Funktionen] oder Fehlerbehebungen [für] jede [eingegebene] Commit-Nachricht aus.
Dieses [Bild] ist eine Stichprobe, das eine Markierung für eine Korrektur oder Fehlerbehebung zurückgibt.
Die [Trainingsdaten] von Glyph sind ziemlich klein, etwa 5.000, und werden in den unten beschriebenen Experimenten gezeigt.
Die Leistung des [Textklassifikation]s[modells] ist nicht hoch.
Ich stelle zwei verwandte Forschungsarbeiten vor, deren Probleme jedoch die begrenzte Anwendbarkeit und die knappen [Daten][ressourcen] sind.
Unser [Paper] löst diese zwei Probleme und erzeugt [automatisch] [qualitativ] hochwertige Versionshinweise.
Aufgrund des [Problems] der begrenzten Anwendbarkeit [schlagen] wir eine [qualitativ] hochwertige, klassenweise [Zusammenfassung]s[methode] vor, die nur Commit-Nachrichten als [Eingabe] verwendet.
Diese vorgeschlagene [Methode] kann [für] alle [englischen] Repositories verwendet werden.
[Für] das zweite [Problem] der knappen [Daten][ressourcen] haben wir unseren [RNSum]-[Datensatz] erstellt, der aus etwa 82.000 [Daten] besteht. Diese wurden aus den [Daten] der öffentlichen GitHub-Repositories mithilfe der GitHub-[API] gesammelt.
Als Nächstes werde ich unseren [Datensatz] beschreiben.
Hier ist ein Beispiel für die [Daten].
Auf der linken Seite ist eine Commit-Nachricht und auf der rechten Seite sind die Versionshinweise.
Versionshinweise sind als Verbesserungen, Korrekturen usw. [markiert].
Wir haben eine [Aufgabe] eingerichtet, die die Commit-Nachricht als [Eingabe] aufnimmt und die [Ausgabe] ist ein [markierter] Versionshinweis.
Dies kann als eine [Zusammenfassung]s[aufgabe] betrachtet werden.
Wir haben vier Markierungen vordefiniert: [Funktionen], Verbesserungen, Fehlerbehebungen, Beseitigung von Verwerfungen und bahnbrechende Änderungen.
Diese wurden auf der Grundlage von [früheren] [Forschungen] und anderen Faktoren festgelegt.
Die Versionshinweise unten rechts wurde aus den Versionshinweisen unten links [extrahiert].
Zu diesem Zeitpunkt müssen die vier Markierungen, die im Voraus erstellt wurden, erkannt werden.
Die Markierungen sind jedoch nicht immer mit jedem Repository konsistent.
Die Markierung „Verbesserungen“ umfasst [beispielsweise] Verbesserungen, Erweiterungen, Optimierungen und so weiter.
Wir haben eine [Wortschatz]liste mit etwa 30 Markierungen [für] jede dieser Notationsvarianten erstellt.
Diese dient dazu, die Klasse des Versionshinweises zu erkennen. Sie sammelt den [Text] des Versionshinweises, der als Versionshinweis[satz] [für] die Klasse folgt.
Als Nächstes folgt eine Commit-Nachricht.
Commit-Nachrichten sind nicht an die einzelnen Versionen gebunden.
Wenn die aktuelle Version 2.5 bis 19 ist, müssen wir, wie im [Bild] unten gezeigt, die [frühere] Version 2.5 bis 18 identifizieren und eine Diff erhalten.
Dies ist etwas mühsam und es reicht nicht aus, nur eine Liste von Versionen zu erstellen und die Vorher-Nachher-Bilanz zu betrachten.
Wir haben eine [heuristische] Abgleichsregel erstellt, um die [vorherige] und die nächste Version zu bekommen.
Die [Analyse] des [Datensatzes].
Am Ende wurden 7.200 Repositories und 82 [Daten] gesammelt.
Außerdem liegt die durchschnittliche [Anzahl] der Versionshinweis-[Token] bei 63, was [für] eine [Zusammenfassung]s[aufgabe] recht hoch ist.
Auch die [Anzahl] der einzigartigen [Token] ist mit 830.000 recht [groß].
Dies ist auf die [große] [Anzahl] von eindeutigen Klassen- oder [Methoden]namen im Repository zurückzuführen.
Als Nächstes werde ich die vorgeschlagene [Methode] erläutern.
Das klassenweise [extraktive] und dann [abstrahierende Zusammenfassung]s[modell] besteht aus zwei [neuronalen] Modulen.
Ein [Klassifikator] verwendet [BERT] oder [CodeBERT] und ein Generator verwendet [BART].
Zuerst verwendet [CEAS] einen [Klassifikator], um jede Commit-Nachricht in fünf Klassen von Versionshinweisen zu klassifizieren, die Verbesserungen, Fehlerbehebungen, Verwerfungen und eine weitere Klasse enthalten.
Die als „Sonstiges“ eingestuften Commit-Nachrichten werden verworfen.
Dann wendet [CEAS] den Generator auf die vier [markierten] [Dokumente] unabhängig voneinander an und erstellt Versionshinweise [für] jede Klasse.
In dieser [Aufgabe] sind die direkten Korrespondenzen zwischen Commit-Nachrichten und Versionshinweisen nicht bekannt.
Um den [Klassifikator] zu trainieren, haben wir [daher] jeder [eingegebenen] Commit-Nachricht eine Umfrage zugewiesen und dabei die ersten zehn Zeichen jeder Commit-Nachricht verwendet.
Wir haben den klassenweisen [abstrakten Zusammenfassung]s[ansatz] durch zwei verschiedene [Methoden] modelliert.
Das erste [Modell], das wir [CAS]-Single nennen, besteht aus einem einzigen 6-zu-6-Netzwerk und generiert einen einzigen Versionshinweis[text], der eine [Verkettung] von [eingegebenen] Commit-Nachrichten ergibt.
Die ausgegebenen [Texte] können auf der Grundlage spezieller klassenspezifischer Endpunktsymbole in klassenweise Segmente unterteilt werden.
Die zweite [Methode], die wir [CAS]-Multi nennen, besteht aus vier verschiedenen [seq2seq]-Netzwerken, von denen jedes einer der festen Versionshinweisklassen entspricht.
Ich werde nun die Experimente erklären.
Fünf [Methoden] wurden [verglichen]: [CEAS], [CAS]-Single, [CAS]-Multi, [Clustering] und Glyph aus einer [früheren] Studie.
Was die [Evaluation] betrifft, so werden in einigen Fällen die Versionshinweise in mehreren [Sätzen] ausgegeben.
Da es schwierig ist, die [Anzahl] von [Sätzen] zu berechnen, werden sie mit Leerzeichen kombiniert und als ein langer [Satz] behandelt.
Der [BLEU] wird benachteiligt, wenn das [System] einen kurzen [Satz] [ausgibt].
Dieser Abzug führt zu einem niedrigeren [BLEU]-Wert in den nachfolgend beschriebenen Versuchsergebnissen.
Schließlich berechnen wir auch die Spezifität, da [ROUGE] und [BLEU] nicht berechnet werden können, wenn die Versionshinweise leer sind.
Eine höhere Spezifität bedeutet, dass das [Modell] in Fällen, in denen die Versionshinweise leer sind, einen leeren [Text] korrekt [ausgibt].
Hier sind die Resultate.
Da der [Datensatz] E-Mail-Adressen, Hash-Werte usw. enthält, haben wir auch den bereinigten [Datensatz] ausgewertet, der diese ausschließt.
[CEAS] und [CAS] erreichten [ROUGE]-L-Werte, die mehr als zehn Punkte über den [Baselines] lagen.
Insbesondere beim bereinigten Testsatz ist der Abstand zwischen der vorgeschlagenen [Methode] und den [Baselines] auf mehr als zwanzig Punkte angestiegen.
Diese Ergebnisse zeigen, dass [CEAS] und [CAS] signifikant betroffen sind.
[CEAS] erzielte bessere [ROUGE]-L-Werte als [CAS], was darauf hindeutet, dass die Kombination eines [Klassifikators] und eines Generators beim [Training] des [Klassifikators] mit [Pseudo]-Markierungen effektiv ist.
Eine hohe Abdeckung von [CEAS] kann wahrscheinlich erreicht werden, weil sich der [Klassifikator] auf die Auswahl relevanter Commit-Nachrichten [für] jede Klasse konzentrieren kann.
[CAS]-Multi ergab tendenziell mehr [ROUGE]-L-Werte als [CAS]-Single.
Wir schlagen vor, dass es auch effektiv ist, unterschiedliche [abstrakte Zusammenfassung]s[modelle], die unabhängig voneinander sind, [für] jede Klasse von den Versionshinweisen zu entwickeln.
Hier ist eine Fehler[analyse].
[CAS]-[Methoden] geben tendenziell kürzere [Sätze] aus als [menschliche] Referenz[sätze].
In der Abbildung rechts besteht der Referenz[satz] aus drei oder vier [Sätzen], während [CAS] aus nur einem besteht.
Der Grund [für] die Reluktanz dieses [Modells] ist, dass in den [Trainingsdaten] nur 33 Prozent der [Sätze] in der Markierung [Funktionen] und 40 Prozent in der Markierung Verbesserung zu finden sind.
[Darüber hinaus] können [CAS]-[Methoden] ohne zusätzliche [Informationen] keine genauen Versionshinweise erstellen.
Oben auf der rechten Seite ist ein Beispiel für eine sehr unübersichtliche Commit-Nachricht. Der vollständige [Satz] kann nicht ohne Bezug auf den [entsprechenden] Fortschritt oder das Problem [generiert] werden.
Das folgende Beispiel zeigt, dass die beiden Commit-Nachrichten in der [Eingabe] zusammenhängen und zu einem [Satz] zusammengefasst werden sollten, was jedoch nicht gelingt.
Nun kommen wir zum Fazit.
Wir haben einen neuen [Datensatz] [für] die [automatische] [Generierung] von Versionshinweisen erstellt.
Wir haben auch eine [Aufgabe] für die Eingabe von Commit-Nachrichten und deren [Zusammenfassung] formuliert, sodass sie für alle auf [Englisch] [geschriebene] Projekte anwendbar ist.
Unsere Experimente zeigen, dass die vorgeschlagene [Methode] weniger verrauschte Versionshinweise mit höherem Abdeckungsgrad als die [Baselines] erzeugt.
Bitte sehen Sie sich unseren [Datensatz] auf GitHub an.
Vielen Dank!
Hallo! Mein Name ist Asaf Harari.
Ich werde unser [Paper] vorstellen: Few-Shot Tabular [Data] Enrichment Using Fine-Tuned [Transformers] [Architectures].
[Daten]wissenschaftler analysieren [Daten] und konzentrieren sich hauptsächlich auf die Manipulation der [bestehenden] [Funktionen] von [Daten].
Aber manchmal sind diese [Funktionen] begrenzt.
Die [Generierung] von Funktionen unter Verwendung einer anderen [Daten][quelle] kann wesentliche [Informationen] hinzufügen.
Unser [Forschung]sziel ist die [automatische] Anreicherung tabellarischer [Daten] mit freiem [Text] aus externen Quellen.
Angenommen, wir haben einen tabellarischen [Datensatz] und eine [Wissensbasis].
Wir brauchen einen [automatischen] Prozess, der [Entity Linking] und eine [Text][analyse] umfasst, um neue [Funktionen] aus dem freien [Text] der [Wissensbasis] zu extrahieren.
Unser Rahmen [FeSTE] ist genau dieser [automatische] Prozess.
Sehen wir uns also ein Beispiel in einem [Datensatz] an, der in [FeSTE] eingespeist wird.
In diesem Beispiel ist der [Datensatz] der Universitäts[datensatz].
Das Ziel besteht darin, die Universitäten nach niedrigem und hohem Rang einzuteilen.
Als [Wissensbasis] verwenden wir [Wikipedia].
Die erste Phase von [FeSTE] ist [Entity Linking].
Jede [Entität], in diesem Beispiel der Name der Universität, ist mit einer [Entität] innerhalb der [Wissensbasis] [verknüpft].
Der [Text] der [Entitäten] aus der [Wissensbasis] wird [extrahiert] und dem [Datensatz] hinzugefügt.
In diesem Beispiel ist der [Text] das Abstract der [Wikipedia]-Seite.
Nun müssen wir [Funktionen] aus dem [abgerufenen] [Text] generieren oder extrahieren.
Wir müssen also eine Phase der Funktions[extraktion] einleiten, zu der die [Text][analyse] gehört.
Das ist die wichtigste Neuerung dieses [Papers], auf die ich auf den nächsten Folien näher eingehen werde.
Nach der Phase der Funktionsextraktion folgt eine Phase der Funktions[generierung], in der wir die [extrahierten] [Funktionen] verwenden, um eine kleine [Anzahl] neuer [Funktionen] zu erzeugen.
Zunächst werden [Funktionen] in der [Anzahl] der Klassen des ursprünglichen [Datensatzes] generiert.
In diesem Beispiel hat der ursprüngliche [Datensatz] zwei Klassen.
[FeSTE] generiert also zwei neue [Funktionen].
Wenn der [Datensatz] jedoch fünf Klassen hat, generiert [FeSTE] fünf neue [Funktionen].
Jede Funktion stellt die Wahrscheinlichkeit [für] jede Klasse dar.
Um den [Text] zu analysieren, verwenden wir die aktuellste [Text][analyse], die auf [Transformer]-basierten [Sprachmodellen] wie [BERT], [GPT], [XLNet] und anderen beruht.
Es ist aber unwahrscheinlich, dass wir [Sprachmodelle] mit den [eingegebenen] [Datensätzen] trainieren können.
Ein naiver [Ansatz] ist also eine [Feinabstimmung] des [Ziel][datensatzes].
In der Phase der Funktions[extraktion] können wir also [vortrainierte Sprach][modelle] herunterladen und das [Sprachmodell] über den [Ziel][datensatz] feinabstimmen.
In diesem Beispiel zur Feinabstimmung des [Sprachmodells] klassifizieren wir den [Text] in Klassen, d. h. wir klassifizieren das Abstract in die Klassen niedrig oder hoch.
Wir erhalten die Ausgabe des [Sprachmodells], die die Wahrscheinlichkeit [für] jede Klasse darstellt, und verwenden sie als neue [Funktionen].
Das [Problem] bei diesem [Ansatz] ist, dass [Datensätze] möglicherweise nur wenige unterschiedliche [Entitäten]/[Texte] beinhalten.
In unserem Experiment enthält fast die Hälfte der [Datensätze] weniger als 400 Stichproben und der kleinste [Datensatz] enthält 35 Stichproben in einem [Training]ssatz.
Die Feinabstimmung eines [Sprachmodells] über diesen [Datensatz] ist also unwirksam.
Aber wir können vorherige [Kenntnisse] über bereits analysierte [Datensätze] nutzen.
Da wir [FeSTE] auf mehrere [Datensätze] anwenden, können wir die „n minus 1“-[Datensätze] verwenden, um [Informationen] über die „n minus 1“-[Datensätze] zu sammeln, und diese [Informationen] verwenden, wenn wir den n-ten [Datensatz] analysieren.
Wir schlagen vor, eine weitere [Feinabstimmung]sphase hinzuzufügen.
Das war eine vorläufige [Multitask]-[Feinabstimmung]sphase.
Die Feinabstimmung des [Sprachmodells] geht über die „n minus 1“-[Datensätze].
Dann führen wir eine weitere [Feinabstimmung]sphase durch, die eine [Feinabstimmung] des [Ziel][datensatzes] ist, wenn wir das [Sprachmodell] über den n-ten [Ziel][datensatz] feinabstimmen.
Die modernste [Multitask]-[Feinabstimmung] wird [MTDNN] genannt.
Bei der [MTDNN] bleiben die Überschriften in der [Reihe] der [Aufgaben] im [Training]ssatz.
In diesem Beispiel gibt es also vier [Aufgaben] im [Training]ssatz. Das [MTDNN] enthält also vier Überschriften, wie Sie auf dem [Bild] sehen können.
Es nimmt sich eine Zufallsstichprobe aus dem [Training]ssatz heraus.
Wenn die Zufallsstichprobe [zum] Beispiel zu einer einzelnen [Satzklassifikation]s[aufgabe] gehört, führt sie Vorwärts- und Rückwärtspfade durch die erste Überschrift aus.
Wenn die Zufallsstichprobe zur [paarweisen] Ranking-[Aufgabe] gehört, führt sie den Vorwärts- und Rückwärtspfad über die letzte Überschrift aus.
In unserem Szenario variieren tabellarische [Datensätze] in der [Anzahl] der Klassen.
Es gibt also viele [Aufgaben].
[MTDNN] enthält eine [Anzahl] von Klassen, Überschriften und ausgegebenen Ebenen.
Und [zusätzlich] muss [MTDNN] neue Überschriften [für] einen neuen [Datensatz] mit einer neuen [Aufgabe] initialisieren.
Unser [Ansatz], genannt [Feinabstimmung]sreformulierungs[aufgabe], besteht darin, dass wir, anstatt mehrere Überschriften beizubehalten, jeden [Datensatz] in einen [Satz] pro [Klassifikations]s[problem] umformulieren, was zwei Klassen[aufgaben] entspricht.
Schauen wir uns ein Beispiel an.
Hier ist unser [eingegebener] [Datensatz], der aus [Entitäten], [Funktionen], [Text] und Klassen besteht.
Wir formulieren die [Aufgabe] von einer [Klassifizierung] des [Textes] in niedrig oder hoch zu einer Klassifizierung des [Textes], des Abstracts und der Klasse in wahr oder falsch um.
Mit anderen [Worten]: Wir haben das [Sprachmodell] so trainiert, dass es ein Abstract und die Klasse als Abstract und die Klasse klassifiziert, wenn das Abstract zur Klasse gehört oder nicht.
So bleibt die [Vektor]-Markierung in diesem Fall bestehen, die immer aus zwei Klassen besteht.
Das ist der [Algorithmus] [für] unseren neu formulierten [Finabstimmung]s[ansatz].
Schauen wir uns also den gesamten Rahmen an.
Der [Datensatz] wird in [FeSTE] eingespeist.
Dann führt [FeSTE] die [Entity-Linking]-Phase aus.
Es extrahiert den [Text] aus der [Wissensbasis], die in diesem Beispiel das Abstract der [Wikipedia]-Seite ist.
Dann formulierte es die [Aufgabe] in eine [paarweise] [Satzklassifikation]s[aufgabe] um.
Das [Sprachmodell] wird auf die neue [Aufgabe] und die Ausgabewahrscheinlichkeit [für] jede Klasse angewandt.
Nun ist das [Sprachmodell] bereits über den „n minus 1“-[Datensatz] mithilfe einer vorläufigen [Multitask]-[Feinabstimmung] feinabgestimmt.
Dann verwenden wir den Ausgabe-[Vektor] des [Sprachmodells] als eine neu [generierte] Funktion in der [Anzahl] der Klassen.
Zur Evaluation unseres Rahmens verwenden wir 17 tabellarische [Klassifikation]s[datensätze], die sich in Größe, [Funktionen], Ausgewogenheit, [Domäne] und anfänglicher Leistung unterscheiden.
Als [Wissensbasis] verwenden wir [Wikipedia].
Wir konzipieren unser Experiment als Leave-One-Out-[Evaluation], bei dem wir [FeSTe] mit 16 [Datensätzen] trainieren und auf den 17. [Datensatz] anwenden.
Außerdem teilen wir jeden [Datensatz] in vier Brüche auf und wenden eine vierfache Kreuzvalidierung an.
Dann generieren wir die neuen [Funktionen] und bewerten sie mit fünf [Evaluations]s[klassifikatoren].
Wir verwenden in unseren Experimenten die Basisarchitektur [BERT].
Hier sind die Ergebnisse [unserer] Experimente.
Sie können sehen, dass wir unseren Rahmen mit der [Feinabstimmung] des [Ziel][datensatzes], mit der [Feinabstimmung] der [Ziel][aufgabe] und einer vorläufigen [MTDNN]-[Feinabstimmung] vergleichen.
Unsere neu formulierte [Feinabstimmung] [erreicht] das beste Ergebnis und die beste Leistung.
[MTDNN] erreichte zwei Prozent Verbesserung gegenüber der [Feinabstimmung] des [Ziel][datensatzes].
Mit unserem [Ansatz] haben wir eine Verbesserung von sechs Prozent erreicht.
Wenn wir uns den kleinen [Datensatz] anschauen, sehen wir, dass die Leistung von [MTDNN] abnimmt und die Verbesserung der vorläufigen [Multitask]-[Feinabstimmung]sphase auf 1,5 Prozent sinkt.
Aber unsere Leistung stieg auf elf Prozent [im Vergleich zu]r [Feinabstimmung] des [Ziel][datensatzes] allein.
[Für] die Summierung ermöglicht [FeSTE] in unseren Experimenten eine Few-Shot-Anreicherung aus 35 Proben.
Es verwendet eine Architektur [für] alle [Aufgaben] und [Datensätze].
Und es behält den Hauptteil des [Modells].
Aber es fügt eine Reformulierungsphase hinzu.
Es erweitert den Trainingssatz und benötigt einen [Ziel]wert mit [semantischer] [Bedeutung], damit wir ihn in das [Sprachmodell] einspeisen und für das [Satzpaar]-[Klassifikations][problem] verwenden können.
Vielen Dank!