Blog >>> Techtalk_

Coding.Waterkant: Machine Learning Part 2

Über den coding.waterkant Hackathon und die Grundlagen zu Transformern und Huggingface haben wir bereits berichtet. In diesem Teil stellen wir euch die Projektidee und die Ergebnisse des Hackathons vor.
24.08.2022
Lennart Büttner
Lennart Büttner
Entwickler
Coding.Waterkant: Machine Learning Part 2

Im ersten Teil dieser Blogartikel-Serie sind wir neben einem kurzen Rückblick zum diesjährigen coding.waterkant Hackathon auf die Grundlagen zu Transformern und Huggingface eingegangen. Hier werden wir nun zuerst die Projektidee nochmal kurz vorstellen und dann unsere Ergebnisse des Hackathons erläutern.

Im Rahmen einer No-Code Datenbanklösung sollte evaluiert werden, inwiefern die Abfrage tabellarischer Daten mit einer natürlichen Sprache wie deutsch oder englisch mit Hilfe von sogenanntem Natural Language Processing (NLP) realisierbar ist.

Datensätze

Im Bereich der Abfrage tabellarischer Daten gibt es drei hochwertige Datensätze von besonderer Popularität. Sie unterscheiden sich stark von der Ausrichtung des zu Grunde liegenden Problems, insbesondere im Bezug auf zu lernenden Aggregationen, also beispielsweise COUNT, AVERAGE oder SUM:

Aufgabe Datensatz Beschreibung
Konversation Microsoft Reasearch Sequential Question Answering (SQA) Aufeinanderfolgende, zusammenhängende Fragen. Keinerlei Aggregationen
Schwache Supervision für Aggregation Wiki Table Questions (Stanford) In diesen Fragen sind teilweise Aggregationen enthalten, das Model muss diese allerdings komplett selbst lernen
Starke Supervision für Aggregation WikiSQL (Salesforce) Ebenfalls sind teilweise Aggregationen enthalten, diese sind im Datensatz explizit gekennzeichnet wodurch das Model hier eine Klassifizierung vorgegeben bekommt

Ein Finetuning auf Basis des SQA-Datensatzes lässt sich somit kategorisch ausschliessen, da definitiv Aggregation benötigt werden.

Testdaten

Zum Testen haben wir einen kleinen fiktiven Datensatz von Mitarbeitern einer Firma verwendet. Diesen haben wir noch ein bisschen aufbereitet, da die NLP-Models und Tokenizer in der Regel die Wörter in der Form Job Title deutlich besser verstehen als JOB_TITLE. Dies liegt an den entsprechend genutzten Trainingsdaten.

Tabelle mit Datensätzen

Darüber hinaus wurde eine Sammlung an Testfragen erstellt. Diese sollte möglichst viele Typen von Fragen über eine Tabelle enthalten, also verschiedene Arten von SELECTS und Filterungen durch WHERE, sowie diverse Arten der Aggregation abdecken.

questions = [
    # Filtering for Single Column and Row
    'What is the phone number of the Donald OConnell?',
    # Filter by time
    'Who was hired most recently?',
    # Filtering for Multiple Rows
    'What are the names of all Marketing Representatives?',
    'What are the names of all Programmers?',
    # Filtering for multiple rows by time
    'What are the names of all employees hired in 2004?',
    # Counting the whole table
    'How many employees work in our company?',
    # Counting a subset
    'How many programmers work in our company?',
    # Mean of a column
    'What is the average salary?',
    # Mean of a subset
    'What is the average salary of programmers?',
    # True or False
    'Has every department one manager?',
    # Reframe the above question (1)
    'Which departments have no managers?',
    # Reframe the above question (2)
    'Which departments have more than one manager?',
    # Group by a column and count, then sort by count desc and return the first
    'Which department has the most employees?',
]

Models

Wir haben diverse Models aus der Huggingface Community ausprobiert und versucht, diese anhand der Testdaten und Testfragen qualitativ einzuschätzen.

Dabei sind uns vier Arten von Models, bzw. von Aufgaben augefallen, die prinzipiell alle in die Oberkategorie Sequence-to-sequence Model fallen. Zwei dieser Models versuchen den eingegebenen, englischen Text in SQL zu übersetzen. Die anderen beiden fallen in die Unterkategorie Table-Question-Answering. Hierbei wird die gesamte Tabelle als Zeichenkette, zusammen mit der Frage über die Daten als Input verwendet.

Da wir vorerst von eigenem Training abgesehen haben, waren wir in unserer Auswahl der Models natürlich von dem Angebot der Community abhängig, weswegen sich unsere Ergebnisse der einzelnen Models nur bedingt vergleichen lassen. Dennoch haben wir einen Eindruck über die Einschränkungen und Möglichkeiten bekommen. Wir haben darüber hinaus versucht, einen genaueren Eindruck über die Models zu erhalten, indem wir uns die Wahrscheinlichkeiten der einzelnen Vorhersagen haben ausgeben lassen. Diese gelten zwar nur aus der Perspektive des einzelnen Models, haben aber noch weitere Unzulänglichkeiten aufgedeckt. So kam es beispielsweise bei dem TAPEX Model vor, dass bei einer Frage bei dessen Antwort sich das Model zu 85% sicher war noch das korrekte Ergebnis geliefert wurde. Bei 92% jedoch hingegeben wurde eine falsche Antwort geliefert.

T5, finetuned auf WikiSQL

Das T5 ist ein besonders flexibeler Transformer von Google, der unter anderem gute Ergebnisse bei Table-Question-Answering Tasks geliefert hat. Wir haben eine Variante verwendet, welche auf dem o.g. WikiSQL Datensatz “finetuned“ wurde und direkt SQL liefert. In diesem Fall haben wir es also mit einer Übersetzungsaufgabe von englisch zu SQL zu tun.

Beispiel Ein-/Ausgabe

input = 'What is the phone number of the Donald OConnell?'

# Model gibt zurück:
# '<pad> SELECT Phone FROM table WHERE Incumbent = Donald OConnell</s>'

Die Übersetzung des Models ist offensichtlich nicht wirklich brauchbar. Insgesamt hat dieses Model nicht eine Frage “richtig“ beantwortet. Man muss dazu sagen, dass das Finetuning durch eine Einzelperson aus der Community stattfand und nicht wie bei den später gezeigten von einem Google- oder Microsoft-Team.

TAPAS, finetuned auf WTQ

TAPAS aus dem Hause Google ist ein Model, welches speziell darauf zugeschnitten wurde, Fragen über tabellarische Daten zu beantworten (Table-Question-Answering). Der Name steht für TAble PArSing. Der große Unterschied zu dem zuvor erwähnten Model ist, dass zum einen die gesamte Tabelle als String zusammen mit der eigentlichen Frage über die Daten als Input für das Model verwendet wird. Zum anderen wird die direkte Antwort, bzw. die X- und Y- Koordinaten der Tabelle sowie ein Aggregationsoperator als Rückgabewerte geliefert.

Beispiel Ein-/Ausgabe

input = 'What is the phone number of the Donald OConnell?'

# Model gibt zurück:
# (NONE, [(0, 4)])

Das NONE steht hierbei dafür, dass keine Aggregation verwendet werden soll. Das Tupel (0, 4) sind respektive Zeile und Spalte der Tabelle, was in diesem Fall der korrekten Antwort entspricht. Generell hat dieses Model die besten Ergebnisse geliefert und konnte sowohl eine und meherere Zellen der Tabelle auswählen, als auch alle Mitarbeiter zählen, sowie das durchschnittliche Gehalt von Programmierern ermitteln. Die große Einschränkung ist hier die maximale Menge an Daten, also die Länge des Inputs. In unserem Fall waren ab ungefähr 30 Zeilen der Tabelle keine validen Ausgaben mehr zu erwarten. Das Model ist auch nicht in der Lage, eine GROUP BY Aggregation durchzuführen um zum Beispiel eine Frage über die höchste Anzahl von Mitarbeitern in einer Abteilung beantworten zu können.

TAPEX, finetuned auf WTQ

Das TAPEX (Table Pre-training via Execution) Model von Microsoft Research verfolgt einen ähnlichen Ansatz wie das TAPAS Model. In der Benutzung unterscheidet es sich hier insofern, dass Auswahl und Aggregation der Daten direkt im Model stattfinden, der Rückgabewert ist also direkt die Antwort.

Beispiel Ein-/Ausgabe

input = 'What is the phone number of the Donald OConnell?'

# Model gibt zurück:
# 'doconnel@example.com'

Aus einem schwer nachvollziehbaren Grund hat sich dieses Model für die Email-Addresse statt für die Telefonnummer bei der Beispielfrage entschieden. Allgemein hat es deutlich weniger Fragen korrekt beantworten können, als die Google-Variante Tapas für die selbe Aufgabe.

Fazit

Alles in allem lässt sich sagen, dass man mit den frei-zugänglichen Models aus der Community noch sehr weit davon entfernt ist, eine Natural Language Query in einem Produktivsystem implementieren zu können. Durch die Experimente und den Austausch mit anderen Teilnehmern in der Veranstaltung sind uns einige Möglichkeiten aufgefallen, wie man zur ‘Production Readiness’ kommen könnte.

Die Idee des generativen Datensatzes, welche wir in unserem internen Crew-Hackathon verfolgt haben und mit dem man dann ein spezielles Finetuning pro Tabelle oder Projekt vornehmen kann, ist nach wie vor ein valider Kandidat für die nächste Iteration.

Im Bereich der Chatbots, welche ja prinzipiell eine ähnliche Aufgabe erfüllen müssen, wird häufig eine Vorklassifizierung der Frage, bzw. der Nutzereingabe vorgenommen. Das wäre zum Beispiel eine Möglichkeit, um vor der eigentlichen Prediction festzustellen, um welche Art der Aggregation es sich beispielsweise handelt. Bei komplexeren Fragen, welche zum Beispiel ein GROUP BY oder ein JOIN beeinhalten, wären auch direkt durchgeführte Aggregationen auf Basis der Vorklassifizierung denkbar.

Die beiden untersuchten Arten der Problemformulierung bieten jeweils Vor- und Nachteile. Table Question Answering wirkte bei den vortrainierten Community Models generell deutlich fähiger, hat aber den großen Nachteil, dass die Menge an Eingabedaten stark beschränkt ist. Text2Sql ist hingegen nicht beschränkt durch die Tabellengröße, hat aber nahezu keine richtige Antwort liefern können. Hier ist es notwendig, weitere, ggf. größere Modelle zu betrachten und selbst Finetuning durchzuführen.

Teilen @
Lust auf was Neues?
Aktuelle Stellenangebote >>>