Qgelm

Neue Algorithmen für relationales Lernen: Was Deep Learning nicht beherrscht

<html> <header class=„article-header“><h1 class=„articleheading“>Neue Algorithmen für relationales Lernen: Was Deep Learning nicht beherrscht</h1><div class=„publish-info“> Alexander Uhlig, Sören Nikolaus</div></header><figure class=„aufmacherbild“><img src=„https://heise.cloudimg.io/width/700/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/shutterstock_1478949875.jpg-7d29f5fa71b99d76.jpeg“ srcset=„https://heise.cloudimg.io/width/700/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/shutterstock_1478949875.jpg-7d29f5fa71b99d76.jpeg 700w, https://heise.cloudimg.io/width/1050/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/shutterstock_1478949875.jpg-7d29f5fa71b99d76.jpeg 1050w, https://heise.cloudimg.io/width/1500/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/shutterstock_1478949875.jpg-7d29f5fa71b99d76.jpeg 1500w, https://heise.cloudimg.io/width/2300/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/shutterstock_1478949875.jpg-7d29f5fa71b99d76.jpeg 2300w“ alt=„“ class=„img-responsive“ referrerpolicy=„no-referrer“ /><figcaption class=„akwa-caption“>(Bild: issaro prakalung/Shutterstock.com)</figcaption></figure>Feature Learning macht relationale Daten für Machine Learning nutzbar. Hierdurch erschließt sich Unternehmen ein riesiger Datenschatz mit Geschäftspotenzial.Die Idee, Daten in relationalen Strukturen zu speichern, reicht bis in die 1970er-Jahre zurück. Heute bilden relationale Daten das Rückgrat eines jeden modernen Unternehmens. In Datenbanken türmen sich Berge von Unternehmensdaten, die eine zentrale Rolle darin spielen können, das von den Verantwortlichen erkannte KI-Defizit aufzuholen. Doch bei aller Innovationsfreude gilt es zu bedenken: Aus relationalen Daten mit Machine Learning (ML) Werte zu schöpfen ist bisher nur unter enormen Anstrengungen möglich. Das ist ein Umstand, der selbst großen Unternehmen den Zugang zum Machine Learning und zu Geschäftsanwendungen mit Künstlicher Intelligenz (KI) versperrt.Der Schlüssel liegt im Forschungsfeld des relationalen Lernens, das in der Praxis noch kaum eine Rolle spielt. Eine neue Klasse an Algorithmen verspricht hier Abhilfe. Sie überträgt das zentrale Konzept des Feature Learnings aus dem Deep Learning auf relationale Datenstrukturen und macht Unternehmensdaten für moderne Algorithmen im Machine Learning nutzbar.<div class=„a-boxtarget a-boxcontent a-inline-textboxcontent a-inline-textboxcontent–horizontal-layout“ data-collapse-target=„“><figure class=„a-inline-textboximage-container“><img alt=„“ src=„https://heise.cloudimg.io/width/4000/q50.png-lossy-50.webp-lossy-50.foil1/_www-heise-de_/imgs/71/2/8/9/8/5/2/3/shutterstock_1161966886-c893e738e55765fb.jpeg“ srcset=„https://heise.cloudimg.io/width/8000/q30.png-lossy-30.webp-lossy-30.foil1/_www-heise-de_/imgs/71/2/8/9/8/5/2/3/shutterstock_1161966886-c893e738e55765fb.jpeg 2x“ class=„c1“ referrerpolicy=„no-referrer“ /></figure><div class=„a-inline-textboxcontent-container“>Dieser Beitrag ist Teil einer Artikelserie, zu der heise Developer junge Entwickler:innen einlädt – um über aktuelle Trends, Entwicklungen und persönliche Erfahrungen zu informieren. Die Reihe „Young Professionals“ erscheint im monatlichen Rhythmus. Bist du selbst ein „Young Professional“ und willst einen (ersten) Artikel schreiben? Schicke deinen Vorschlag an die Redaktion: developer@heise.de. Wir stehen dir beim Schreiben zur Seite.<ul class=„a-inline-textboxlist“><li class=„a-inline-textboxitem“><a class=„a-inline-textboxtext“ href=„https://www.heise.de/hintergrund/Alpine-js-Das-Schweizer-Taschenmesser-fuer-dynamische-Weboberflaechen-6177628.html“ title=„Alpine.js: Das Schweizer Taschenmesser für dynamische Weboberflächen“>Alpine.js: Das Schweizer Taschenmesser für dynamische Weboberflächen [1]</a></li><li class=„a-inline-textboxitem“><a class=„a-inline-textboxtext“ href=„https://www.heise.de/hintergrund/Developer-Experience-Glueckliche-Entwickler-schreiben-besseren-Code-6150890.html“ title=„Developer Experience: Glückliche Entwickler schreiben besseren Code“>Developer Experience: Glückliche Entwickler schreiben besseren Code [2]</a></li><li class=„a-inline-textboxitem“><a class=„a-inline-textboxtext“ href=„https://www.heise.de/hintergrund/Ethik-und-Kuenstliche-Intelligenz-ein-neuer-Umgang-mit-KI-Systemen-6056059.html“ title=„Ethik und Künstliche Intelligenz: Ein neuer Umgang mit KI-Systemen“>Ethik und Künstliche Intelligenz: Ein neuer Umgang mit KI-Systemen [3]</a></li><li class=„a-inline-textboxitem“><a class=„a-inline-textboxtext“ href=„https://www.heise.de/developer/young-professionals-6065678.html“ title=„Alle Beiträge der Serie finden sich in der Rubrik“>Alle Beiträge der Serie finden sich in der Rubrik „Young Professionals“ [4]</a></li></ul></div></div>Data Scientists stehen in ihrem Projektalltag oft vor einer klassischen Aufgabe: Auf der Grundlage relationaler Ursprungsdaten aus einer Datenbank wie MySQL sollen sie ein <a href=„https://de.wikipedia.org/wiki/Pr%C3%A4diktive_Analytik“ rel=„external noopener“ target=„_blank“>Machine-Learning-Modell zur prädiktiven Analytik [5]</a> entwickeln. Daraus resultierende Modelle kommen branchenübergreifend zum Einsatz und können für die unterschiedlichsten Anwendungen ausgelegt sein, etwa zur Prognose von Kundenabwanderung bei Finanzdienstleistern, Verkaufs- und Bedarfsprognosen im Einzelhandel oder zur prädiktiven Instandhaltung in der verarbeitenden Industrie.Das gemeinsame Problem beim Entwickeln von Prognosemodellen auf relationalen Daten ist, dass diese Daten nicht als Eingangswerte für ML-Modelle geeignet sind. Data Scientists müssen bis zu 90 Prozent ihrer Zeit für manuelle Arbeitsschritte aufbringen, um die relationalen <a href=„https://arxiv.org/abs/1206.5538“ rel=„external noopener“ target=„_blank“>Ursprungsdaten in eine Repräsentation zu überführen [6]</a>, die zur Verwendung in <a href=„https://xgboost.ai/“ rel=„external noopener“ target=„_blank“>Modellen wie XGBoost [7]</a> geeignet ist.Die Entwicklung von Features ist zeitaufwendig, kompliziert und erfordert tiefes Fachwissen. Angewandtes maschinelles Lernen ist Feature Engineering.– Andrew Ng, <a href=„https://www.microsoft.com/en-us/research/wp-content/uploads/2013/01/andrew-ng_machinelearning.pdf“ rel=„external noopener“ target=„_blank“>Deep Learning [8]</a>Feature Learning verspricht, diese Arbeitsschritte zu automatisieren und relationale Daten damit im Rahmen von Machine Learning direkt nutzbar zu machen. Die Erfahrungen aus dem Data-Science-Alltag der Autoren zeigen, dass die Methode es erlaubt, fehleranfällige sowie zeitaufwendige manuelle Schritte zu vermeiden und dabei zu besseren ML-Modellen führt.<h3 class=„subheading“ id=„nav_was_ist0“>Was ist relationales Lernen?</h3>Zum Training eines Prognosemodells mittels überwachten Lernens benötigen Data Scientists einen Datensatz mit ausgewiesener Zielvariable. In vielen Lehrbuch-Beispielen oder Data-Science-Wettbewerben besteht der Datensatz lediglich <a href=„https://en.wikipedia.org/wiki/Flat-file_database“ rel=„external noopener“ target=„_blank“>aus einer flachen Tabelle [9]</a>. Diese Tabelle bildet die <a href=„https://de.wikipedia.org/wiki/Grundgesamtheit“ rel=„external noopener“ target=„_blank“>Grundgesamtheit (Statistical Population) des Modells [10]</a>. Jede Zeile dieser Tabelle entspricht einer unabhängigen Beobachtung, der eine Zielvariable – auch Ausgabewert genannt – und eine feste Anzahl mess- und beobachtbarer Attribute zuzuordnen sind (s. Abb. 1).Diese Attribute bezeichnen Data Scientists als Features, sie bilden die Eingabewerte des Modells. Eine Immobilienpreisprognose veranschaulicht den Zusammenhang zwischen Zielvariable und Features: Die Zielvariable ist hier der Wert des Objekts und ein mögliches Feature ist die Quadratmeterzahl, die zu jeder Immobilie zur Verfügung steht.In der Trainingsphase lernt der Algorithmus die Parameter des Modells und damit einen generalisierten, funktionalen Zusammenhang zwischen Eingabe- und Ausgabedaten. Angewandt auf neue Eingabedaten lässt sich das erlernte Modell anschließend zur Prognose noch unbekannter Ausgabedaten nutzen.<figure class=„a-inline-image a-u-inline“><div><img alt=„“ class=„legacy-img“ height=„343“ src=„https://heise.cloudimg.io/width/525/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/1-caeb919820d28d3b.png“ srcset=„https://heise.cloudimg.io/width/336/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/1-caeb919820d28d3b.png 336w, https://heise.cloudimg.io/width/1008/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/1-caeb919820d28d3b.png 1008w, https://heise.cloudimg.io/width/1050/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/1-caeb919820d28d3b.png 2x“ width=„525“ referrerpolicy=„no-referrer“ /></div><figcaption class=„a-caption“>Beispiel für eine Populationstabelle (Abb. 1)(Bild: getML)</figcaption></figure>Doch liegen in vielen Anwendungsfällen die Eingabedaten nicht ausschließlich in Form einer flachen Tabelle vor. Gerade innerhalb von Unternehmensanwendungen ist es effizienter, die im Prozess anfallenden Informationen in relationalen Datenstrukturen zu organisieren. Statistiken belegen eine weite Verbreitung: Sieben der zehn beliebtesten Datenbanken sind laut dem DB-Engine Ranking relational. Teilen sich die Eingabewerte eines Prognosemodells auf untereinander in Beziehung stehende Tabellen auf, handelt es sich um eine Anwendung aus einem Teilgebiet des statistischen relationalen Lernens.Neben der Populationstabelle gibt es aus Sicht des relationalen Lernens eine weitere Klasse an Tabellen im relationalen Datenschema: periphere Tabellen, die in ihren Zeilen Beobachtungen weiterer Attribute enthalten. Periphere Tabellen können in m:n-Beziehungen zur Populationstabelle stehen. Entsprechend steht eine Zeile aus der Populationstabelle in einer 1:n-Beziehung zu Zeilen der peripheren Tabelle. Beim relationalen Lernen ist es üblich, dass für jede Beobachtungszeile der Populationstabelle eine unterschiedliche Anzahl an zugehörigen Zeilen in den peripheren Tabellen anfällt (s. Abb. 2).Da eine Datenbank in der Praxis oft eine Vielzahl von Tabellen enthält, führen die Beziehungen zwischen den Tabellen zu Komplexität. Visualisiert ergeben sich bekannte Stern- oder Schneeflockenschemata. Ein Beispiel ist eine Kundenabwanderungsprognose: Die Zielvariable kodiert, ob ein Kunde in einem bestimmten Zeitraum eine weitere Bestellung tätigt. Eine periphere Tabelle könnte nun für jede Kundennummer eine variierende Anzahl weiterer Beobachtungen enthalten, beispielsweise vergangene Einkäufe oder digitale Kundenaktivitäten.Doch wie ändert sich die Arbeitsweise von Data Scientists, sobald ihnen für die Entwicklung eines Prognosemodells Trainingsdaten mit relationalen Strukturen vorliegen? Was müssen sie tun, um dennoch ein Prognosemodell entwickeln zu können?<h3 class=„subheading“ id=„nav_wie_machine1“>Wie Machine Learning mit relationalen Daten bislang funktioniert</h3>Mangels zeitgemäßer selbstlernender Algorithmen, die relationale Eingabedaten verarbeiten, bleibt ihnen keine andere Option als die vorliegenden relationalen Daten im ersten Schritt in eine kompatible Repräsentation zu überführen. Doch wieso werden die peripheren Tabellen nicht einfach weggelassen? Das wäre die mit Abstand ungünstigste Herangehensweise. Gerade in diesen Tabellen sind meist Informationen enthalten, die in einem starken Bezug zur Zielvariable stehen, wie die im Beispiel zur Kundenabwanderung genannten historischen Transaktionen eines Kunden. Stünden dem Machine-Learning-Modell in der Trainingsphase diese Informationen nicht zur Verfügung, sänke die Prognosegüte des resultierenden Modells.<figure class=„a-inline-image a-u-inline“><div><img alt=„“ class=„legacy-img“ height=„404“ src=„https://heise.cloudimg.io/width/696/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/2-7a26999b46dc123d.png“ srcset=„https://heise.cloudimg.io/width/336/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/2-7a26999b46dc123d.png 336w, https://heise.cloudimg.io/width/1008/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/2-7a26999b46dc123d.png 1008w, https://heise.cloudimg.io/width/1392/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/2-7a26999b46dc123d.png 2x“ width=„696“ referrerpolicy=„no-referrer“ /></div><figcaption class=„a-caption“>Feature Engineering auf relationalen Daten findet in der Regel in Programmiersprachen wie SQL, Python oder R statt (Abb. 2).(Bild: getML)</figcaption></figure>Sind den Data Scientists alle für die Prognose relevanten Informationen bekannt, können sie die relationale Beziehung zwischen der Populationstabelle und der peripheren Tabelle durch skalare Featurewerte ersetzen. Diese Werte können sie anschließend an das Prognosemodell übergeben. Das Auflösen dieser 1:n-Beziehungen zwischen einer Beobachtung in der Populationstabelle und den peripheren Tabellen heißt Feature Engineering. Hierfür programmieren Data Scientists Aggregationsfunktionen samt Nebenbedingungen.Die Herausforderung im Feature Engineering liegt in der Identifikation der relevanten Aggregationen und Nebenbedingungen. Bezogen auf das Beispiel der Kundenabwanderung entspricht ein Feature beispielsweise der

COUNT

-Aggregation über alle von einem Kunden getätigten Einkäufe in den letzten 90 Tagen. Stattdessen käme auch die

SUM

-Aggregation über den Warenwert der jeweiligen Einkäufe der vergangenen 45 Tage infrage. Das sind zwei relativ einfache Features aus nahezu endlosen Kombinationsmöglichkeiten von Aggregationsfunktionen und beliebig komplexen Nebenbedingungen. Welches der möglichen Features die prognoserelevanten Informationen liefert, ist im Voraus nicht klar und bislang weitgehend händisch auszuprobieren (s. Abb. 3).<figure class=„a-inline-image a-u-inline“><div><img alt=„“ class=„legacy-img“ height=„275“ src=„https://heise.cloudimg.io/width/525/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/3-e57f4e7c1b2a2503.png“ srcset=„https://heise.cloudimg.io/width/336/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/3-e57f4e7c1b2a2503.png 336w, https://heise.cloudimg.io/width/1008/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/3-e57f4e7c1b2a2503.png 1008w, https://heise.cloudimg.io/width/1050/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/3-e57f4e7c1b2a2503.png 2x“ width=„525“ referrerpolicy=„no-referrer“ /></div><figcaption class=„a-caption“>Der Prozess des Feature Engineerings (Abb. 3)(Bild: getML)</figcaption></figure>In der Praxis entpuppt sich Feature Engineering als zeitaufwendiger Prozess: Es erfordert eine enge Zusammenarbeit zwischen Fachexperten mit Prozesswissen und Data Scientists mit Methodenwissen, um prognoserelevante Einflussfaktoren zu identifizieren, sie in eine Logik zu überführen und auf Basis dieser Logik anschließend die Features zu extrahieren. Gute Prognosemodelle erfordern häufig eine dreistellige Anzahl an Features, die jeweils bis zu einigen hundert Zeilen Code umfassen können. Dem Feature Engineering kommt in Machine-Learning-Projekten eine große Bedeutung zu. Die verwendeten Features sind maßgeblich für die Prognosegüte..Letztendlich sind einige Machine-Learning-Projekte erfolgreich und einige scheitern. Was macht den Unterschied aus? Der mit Abstand wichtigste Faktor sind die verwendeten Features.- Pedro Domingos, <a href=„https://dl.acm.org/doi/10.1145/2347736.2347755“ rel=„external noopener“ target=„_blank“>Useful Things to Know About Machine Learning [11]</a>Das Training des Prognosemodells ist mittels AutoML-Anwendungen zwar weitgehend automatisierbar, doch hängt die Prognosegüte in erster Linie von den willkürlichen Annahmen ab, die die Teams im Feature-Engineering-Prozess treffen.Zudem ist es oft nicht zu vermeiden, dass die Bedeutung einzelner Features im Verlauf der Modellanwendung sinkt oder neue Features relevant werden. Dieses Phänomen heißt auch Feature Drift. Also bedarf es einer kontinuierlichen Überwachung und Anpassung der Features sowie regelmäßiger Trainings des darauf aufbauenden Modells.<h3 class=„subheading“ id=„nav_mit_feature2“>Mit Feature Learning relationale Daten in Trainingsdaten verwandeln</h3>Festzuhalten ist, dass gegenwärtig die Qualität einer Machine-Learning-Anwendung auf relationalen Daten von willkürlichen Entscheidungen hinsichtlich der gewählten Aggregationsfunktionen und Nebenbedingungen abhängt, die Menschen im Rahmen des Feature-Engineering-Prozesses getroffen haben (s. Abb. 3).Feature Learning bezeichnet einen Ansatz, bei dem ein statischer Algorithmus die Features auf der Grundlage der Trainingsdaten erlernt. Auf nicht-relationalen Daten findet das Feature Learning bereits erfolgreich statt: Seit 2012 stellt Deep Learning die Automatisierung von Feature Engineering in dem Feld der Computer Vision in zahlreichen Anwendungen unter Beweis.So kamen im ImageNet-Wettbewerb zur Objekterkennung in Bildern bis 2011 ausschließlich von Experten manuell entwickelte Features zum Einsatz. Mit der praktischen Verfügbarkeit immer tieferer neuronaler Netze änderte sich das schlagartig: <a href=„https://www.wired.com/story/fei-fei-li-artificial-intelligence-humanity/“ rel=„external noopener“ target=„_blank“>So sank die Fehlerrate der Algorithmen [12]</a> von über 25 Prozent (Support Vector Machines mit manuellen Features) auf unter drei Prozent (neuronale Netze mit Feature Learning). Feature Learning trug einen Großteil zu diesem Erfolg bei. Das lässt sich erahnen, wenn man einen genaueren Blick auf die Architektur eines neuronalen Netzwerks wirft: So stehen über 99 Prozent aller Berechnungen innerhalb moderner Convolutional Neural Networks (CNN) mit dem Erlernen spezifischer Feature-Repräsentationen in Verbindung. Die erlernten Features liefern die Grundlage, um ohne extern zugeführtes Expertenwissen in der Aufgabenstellung der Objekterkennung eine übermenschliche Trefferquote zu erreichen.<figure class=„a-inline-image a-u-inline“><div><img alt=„“ class=„legacy-img“ height=„552“ src=„https://heise.cloudimg.io/width/696/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/4-577a0f43ba367b6c.png“ srcset=„https://heise.cloudimg.io/width/336/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/4-577a0f43ba367b6c.png 336w, https://heise.cloudimg.io/width/1008/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/4-577a0f43ba367b6c.png 1008w, https://heise.cloudimg.io/width/1392/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/4-577a0f43ba367b6c.png 2x“ width=„696“ referrerpolicy=„no-referrer“ /></div><figcaption class=„a-caption“>Inputdaten variierender Länge sind inkompatibel mit neuronalen Netzen und anderen Modellen (Abb. 4)(Bild: getML)</figcaption></figure>Aus zahlreichen Gründen ist es nicht möglich, Architekturen, die sich im Feature Learning auf unstrukturierten Daten wie beispielsweise Bildern bewährt haben, auf relationale Datenstrukturen zu übertragen. Versucht man beispielsweise Convolutional Neural Networks auf relationalen Daten zur Anwendung zu bringen, misslingt das im ersten Schritt: CNNs erwarten eine konstante Anzahl an Eingangswerten (s. Abb. 4).<h3 class=„subheading“ id=„nav_ein_neues3“>Ein neues ML-Framework für relationales Lernen</h3>Mit dem ML-Framework getML verfolgt das gleichnamige Unternehmen der Autoren das Ziel, relationales Lernen für Data Scientist nutzbar zu machen. Hierzu stellt getML vier neue Feature-Learning-Algorithmen zur Verfügung. Diese Algorithmen erlernen optimale Features im Rahmen einer überwachten Suche auf der Grundlage eines abstrakten Datenmodells, das die relationalen Beziehungen zwischen Tabellen abbildet. Die gelernten Features können nach dieser Aufbereitung auch als Eingabewerte für Prognosemodelle dienen. Eine wichtige Anforderung kam dabei aus der Praxis: Die Algorithmen sollten ohne größeren Konfigurationsaufwand stabile und hochwertige Features liefern.Nach ersten Versuchen wurde dem Entwicklungsteam klar, dass baumbasierte Ansätze die vielversprechendste Option darstellen. <a href=„https://www.wired.com/story/fei-fei-li-artificial-intelligence-humanity/“ rel=„external noopener“ target=„_blank“>Auf strukturierte Daten angewandt sind Entscheidungsbäume neuronalen Netzen vielfach überlegen [13]</a>, und ihre Entwicklung ist durchaus bemerkenswert. In der Praxis bedürfen baumbasierte Modelle aufgrund ihrer geringeren Komplexität eines reduzierten Konfigurationsaufwands, benötigen weniger Trainingsdaten und eine geringere Rechenzeit. All das sind Aspekte, die im Projektalltag eine gewichtige Rolle spielen. Alle Feature-Learning-Ansätze, die getML entwickelt hat, sind baumbasierte Ensemblemethoden. Wobei <a href=„https://docs.getml.com/latest/user_guide/feature_engineering/feature_engineering.html#multirel“ rel=„external noopener“ target=„_blank“>ausgehend von Multirel [14]</a> – einer effizienten Implementierung eines <a href=„https://link.springer.com/chapter/10.1007/978-3-540-48247-5_46“ rel=„external noopener“ target=„_blank“>Multi-Relational Decision Trees [15]</a> bis hin zu <a href=„https://docs.getml.com/latest/user_guide/feature_engineering/feature_engineering.html#relboost“ rel=„external noopener“ target=„_blank“>Relboost [16]</a> – einer Generalisierung des <a href=„https://en.wikipedia.org/wiki/Gradient_boosting“ rel=„external noopener“ target=„_blank“>Gradient-Boosting-Ansatzes für relationale Daten [17]</a> – jeder Ansatz andere Qualitäten besitzt. Das betrifft ihre <a href=„https://docs.getml.com/latest/user_guide/feature_engineering/feature_engineering.html#algorithms“ rel=„external noopener“ target=„_blank“>Skalierbarkeit, Interpretierbarkeit oder ihre Eignung hinsichtlich bestimmter Datenstrukturen [18]</a>. Abbildung 5.1 zeigt beispielhaft den Multirel-Algorithmus.<figure class=„a-u-inline-left a-inline-image a-u-inline“><div><img alt=„“ class=„legacy-img“ height=„417“ src=„https://heise.cloudimg.io/width/696/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/Abb._5_-_Feature_Learning-a8c1ce64bcbb3a6e.png“ srcset=„https://heise.cloudimg.io/width/336/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/Abb._5_-_Feature_Learning-a8c1ce64bcbb3a6e.png 336w, https://heise.cloudimg.io/width/1008/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/Abb._5_-_Feature_Learning-a8c1ce64bcbb3a6e.png 1008w, https://heise.cloudimg.io/width/1392/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/Abb._5_-_Feature_Learning-a8c1ce64bcbb3a6e.png 2x“ width=„696“ referrerpolicy=„no-referrer“ /></div><figcaption class=„a-caption“>Vereinfacht dargestellt: Erlernen eines Features mit dem Multirel-Algorithmus (Abb. 5)(Bild: getML)</figcaption></figure>Die größte Herausforderung in der Entwicklungsphase von getML war eine effiziente Implementierung der Feature-Learning-Algorithmen: Um Features zu lernen, sind potenziell Milliarden an Kombinationen aus Aggregationsfunktion und Nebenbedingungen zu evaluieren. Zur Bewältigung dieser Menge an Informationen nutzen getMLs Algorithmen einen Trick: Sie <a href=„https://docs.getml.com/latest/user_guide/feature_engineering/feature_engineering.html?highlight=incremental%20updates#multirel“ rel=„external noopener“ target=„_blank“>aktualisieren die Verlustfunktion im Laufe des Suchprozesses inkrementell [19]</a>, um unnötige Rechenoperationen zu vermeiden. Im Folgenden bestand das Problem aber nun darin, dass keine existierende Datenbank-Engine Datenstrukturen und Caching-Strategien bot, die solche inkrementellen Aktualisierungen in akzeptabler Geschwindigkeit erlaubten. Das führte zu der Entscheidung, die Algorithmen samt einer auf ihre Bedürfnisse zugeschnittenen In-Memory-Datenbank in C++ von Grund auf neu zu entwickeln.<figure class=„a-u-inline-right a-inline-image a-u-inline“><div><img alt=„“ class=„legacy-img“ height=„342“ src=„https://heise.cloudimg.io/width/696/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/Abb._6_-_End-to-end-0b0d8e8fec8889ed.png“ srcset=„https://heise.cloudimg.io/width/336/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/Abb._6_-_End-to-end-0b0d8e8fec8889ed.png 336w, https://heise.cloudimg.io/width/1008/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/Abb._6_-_End-to-end-0b0d8e8fec8889ed.png 1008w, https://heise.cloudimg.io/width/1392/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/Abb._6_-_End-to-end-0b0d8e8fec8889ed.png 2x“ width=„696“ referrerpolicy=„no-referrer“ /></div><figcaption class=„a-caption“>Machine Learning auf relationalen Daten mit getML: Prozessperspektive. 1. Feature-Learning-Schritt, 2. Prognose-Schritt (Abb. 6).(Bild: getML)</figcaption></figure>Der von getML verwendete Ansatz betrachtet das Prognoseproblem als Ganzes. Er lässt sich als zweistufiger Prozess auffassen (s. Abb 6):<ol class=„rtelist rtelist–ordered“><li>getMLs Feature-Learning-Modelle lernen aus relationalen Daten eine kompatible Repräsentation (Feature-Learning-Schritt)</li><li>Die gelernte Repräsentation dient als Input für State-of-the-Art Machine-Learning-Modelle wie XGBoost, auf deren Basis die eigentlichen Prognosen geschehen (Prognose-Schritt)</li></ol>Im Gegensatz zum manuellen Feature Engineering stellt das Feature Learning bereits für die erste Stufe eine automatisierte, algorithmische Lösung dar. Das hat nicht nur Folgen für die Effizienz, sondern auch für die Güte der resultierenden Modelle: So lässt sich zeigen, dass Feature Learning sowohl <a href=„https://github.com/getml/getml-demo#benchmarks“ rel=„external noopener“ target=„_blank“>manuellem Feature Engineering als auch bisherigen relationalen Lernansätzen in vielen Anwendungsfällen überlegen [20]</a> ist.<h3 class=„subheading“ id=„nav_einführung_in4“>Einführung in relationales Lernen für Praktiker</h3>Eine typische Aufgabe von Data Scientists ist es, Kreditinstitute bei Entscheidungen über die Vergabe von Krediten an Bestandskunden zu unterstützen. Dafür entwickeln sie ein Prognosemodell, das die Ausfallwahrscheinlichkeit eines gewährten Kredits vorhersagen kann. Eine vereinfachte Datengrundlage für die Vergabeentscheidung würde in etwa wie in Abbildung 7 aussehen.Die Information über den Kreditausfall ist die kategoriale Zielvariable. Zur Erinnerung: Die Tabelle mit Beobachtungen der Zielvariable stellt die Population des Prognosemodells dar (Tabelle

population

, Abb. 7.1). Da die <a href=„https://github.com/getml/getml-demo#benchmarks“ rel=„external noopener“ target=„_blank“>Information über einen Kreditausfall nominalskaliert [21]</a> ist, handelt es sich um ein <a href=„https://de.wikipedia.org/wiki/Klassifikationsverfahren“ rel=„external noopener“ target=„_blank“>Klassifikationsproblem [22]</a>. Das Kreditinstitut hat im Rahmen der Geschäftsbeziehung weitere Daten zur Verfügung, die für die Prognose eines Kreditausfalls relevant sind: dazu gehören die Transaktionen, die sich in der Vergangenheit im Rahmen der bestehenden Kundenbeziehung beobachten ließen (Tabelle

trans

, Abb. 7.2). Um die Darstellung kurz zu halten, beschränkt sich das Beispiel hier auf die Beziehung zwischen

population

und

trans

(Listing 1).<figure class=„a-inline-image a-u-inline“><div><img alt=„“ class=„legacy-img“ height=„524“ src=„https://heise.cloudimg.io/width/696/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/7-0ad35c7ce32b9c24.png“ srcset=„https://heise.cloudimg.io/width/336/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/7-0ad35c7ce32b9c24.png 336w, https://heise.cloudimg.io/width/1008/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/7-0ad35c7ce32b9c24.png 1008w, https://heise.cloudimg.io/width/1392/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/7-0ad35c7ce32b9c24.png 2x“ width=„696“ referrerpolicy=„no-referrer“ /></div><figcaption class=„a-caption“>Das Datenmodell als Basis zur Kreditvergabeentscheidung (Abb. 7).(Bild: getML)</figcaption></figure><h3 class=„subheading“ id=„nav_projekt_setup5“>Projekt-Setup und Daten-Annotationen</h3><pre class=„rtetx–listing listing“>

import getmlgetml.set_project("young_devs")population_train, population_test, _, trans, _ = getml.datasets.load_loans()

</pre>Listing 1: Projekt anlegen und Daten ladenWie beschrieben besteht die Herausforderung beim relationalen Lernen darin, 1:n-Beziehungen zwischen der Populationstabelle und peripheren Tabellen aufzulösen. Im Kreditvergabebeispiel bedeutet das, mehrere mit einem Kundenkonto assoziierte Transaktionen (aus

trans

) zu einem Wert zu bündeln, der anschließend in die Prognose der Kreditausfallwahrscheinlichkeit einfließt.Aus technischer Sicht lässt sich das Bündeln mehrerer Zeilen aus peripheren Tabellen durch das Anwenden von Aggregationsfunktionen umsetzen; ein Beispiel wäre der Durchschnitt aller Kontostände der Vergangenheit. Diese Aggregationsfunktionen werden in der Regel nicht global, sondern unter der Berücksichtigung von Nebenbedingungen angewandt. Listing 2 zeigt beispielhaft ein händisch erzeugtes Feature auf Basis der durchschnittlichen Kontostände 90 Tage vor Kreditbeantragung. Ein Feature, wie es typischerweise im Prozess des Feature Engineerings geschrieben wird, schaut aus wie im folgenden Listing 2.<pre class=„rtetx–listing listing“><code>SELECT AVG(trans.balance)FROM populationINNER JOIN trans ON population.account_id = trans.account_idWHERE trans.date <= population.date_loan AND trans.date >= population.date_loan - 90;</code></pre>Listing 2: Eine SQL-Query mit einem händisch geschriebenen FeatureDoch woher wissen Data Scientists, dass sich der bestmögliche Erklärungsgehalt für ein Modell aus den vergangenen 90 Tagen speist und nicht beispielsweise aus 167,23 Tagen? Der Prozess läuft – wie im Feature Engineering – händisch ab, daher sind sowohl die Auswahl der Spalte, der Aggregationsfunktion als auch die Gestaltung der Nebenbedingung willkürliche Entscheidungen mit ungewissem Ausgang. Feature Learning ermöglicht das algorithmische Erlernen der entsprechenden Aggregationen und auch Nebenbedingungen.Um Features aus relationalen Datenstrukturen lernen zu können, ist es nötig, dem Algorithmus Informationen mitzuteilen, die über die bloßen Datentypen hinaus gehen. Im getML-Framework <a href=„https://docs.getml.com/latest/user_guide/annotating_data/annotating_data.html“ rel=„external noopener“ target=„_blank“>gibt es hierfür das Konzept der Rollen [23]</a>. Eine Rolle lässt sich als Datentyp mit zusätzlichen Metadaten betrachten und definiert, wie der Feature-Learning-Algorithmus eine Spalte zu verwenden hat. Dabei kommen etwa bestimmte Aggregationen wie <code>AVG</code> bei kategorischen Spalten nicht zur Anwendung, zum Erlernen von Nebenbedingungen zieht der Algorithmus sie jedoch immer heran. Für die Tabelle <code>trans</code> (s. Abb. 7.2) heißt das beispielsweise:<ul class=„rtelist rtelist–unordered“><li>Dem Volumen einer Transaktion (<code>amount</code>) ist die Rolle numerical zugewiesen – auf diese Spalte sind numerische Aggregationen (<code>SUM, AVG, …</code>) anwendbar.</li><li>Dem Transaktionstypen (<code>type</code>) kommt die Rolle categorical zu – auf diese Spalte sind keine numerischen Aggregationen anwendbar, sie lässt sich aber zur Bildung von Nebenbedingungen und für bestimmte Aggregationen wie <code>COUNT</code> heranziehen.</li></ul><h3 class=„subheading“ id=„nav_den6“>Den relationalen Suchraum definieren</h3>Neben den konkreten Daten und den Annotationen benötigt ein Feature-Learning-Algorithmus eine weitere Information: das abstrakte Datenmodell, das die Beziehungen zwischen den einzelnen Tabellen beschreibt und so den relationalen Suchraum definiert.Die <a href=„https://docs.getml.com/latest/api_reference/dataframe.html“ rel=„external noopener“ target=„_blank“>Python-API von getML bietet hierfür mehrere Möglichkeiten [24]</a>. In diesem Beispiel nutzen wir die

StarSchema

-Klasse, die es erlaubt, mit wenigen Zeilen Code ein Sternschema zu modellieren. Die API enthält außerdem

TimeSeries

zur Modellierung von Zeitreihen und ein allgemeines

DataModel

, das es erlaubt, relationale Probleme beliebiger Komplexität (wie Schneeflockenschemata) zu modellieren (Listing 3).<pre class=„rtetx–listing listing“><code>schema=getml.data.StarSchema( train=population_train, test=population_test, alias=„population“,)schema.join( trans, on=„account_id“, time_stamps=(„date_loan“, „date“),)</code></pre>Listing 3: Definition des abstrakten Datenmodells<code>StarSchema</code> erhält als Parameter die Populationstabelle (im Beispiel bereits aufgeteilt in Trainings- und Testdaten: <code>population_train</code>, <code>population_test</code>), sowie einen Alias (<code>population</code>), der es erlaubt, abstrakt – unabhängig vom Split – auf die Population zu referenzieren. Anschließend gilt es, die peripheren Tabellen – die Zacken des Sterns – via <code>join</code> zum Schema hinzuzufügen und so mit der Populationstabelle – dem Zentrum des Sterns – in Beziehung zu bringen. Hierzu wird <code>join</code> ein Join Key übergeben (<code>on</code>). Außerdem ist es möglich <code>join</code> als zusätzliche Restriktion Zeitstempel zu übergeben (<code>time_stamps</code>), um die Plausibilität des Modells sicherzustellen.Für den konkreten Fall heißt das, dass nur solche Transaktionen Berücksichtigung finden, die vor den Kreditvergaben durchgeführt wurden (<code>date <= date_loan</code>). Zu beachten ist hier auch, dass die Algorithmen Joins im abstrakten Datenmodell nach dem Prinzip der Lazy Evaluation ausführen: an diesem Punkt finden also noch keine konkreten Operationen statt. Erst, wenn die Feature-Learning-Algorithmen Feature-Repräsentationen lernen, materialisieren die Algorithmen die im abstrakten Datenmodell beschriebenen Joins.<h3 class=„subheading“ id=„nav_relationales7“>Relationales Lernen findet in der Pipeline statt</h3><pre class=„rtetx–listing listing“><code>multirel = getml.feature_learning.Multirel( loss_function=getml.feature_learning.loss_functions.CrossEntropyLoss,)xgboost = getml.predictors.XGBoostClassifier()pipe = getml.pipeline.Pipeline( data_model=schema.data_model, feature_learners=multirel, predictors=xgboost,)</code></pre>Listing 4: Zusammenfügen der Komponenten in der PipelineZuletzt sind die Modelle zu definieren, die in dem mehrstufigen Lernproblem zur Anwendung kommen sollen: erstens ein Feature-Learning-Algorithmus (hier <code>Multirel</code>), zweitens ein Prognose-Algorithmus – hier <code>XGBoost</code> (Listing 4).Nun haben die Data Scientists alle Zutaten beisammen, um – ausgehend vom Problem in relationaler Form – eine End-to-End-Pipeline aufzubauen. Eine solche Pipeline bildet das Prognoseproblem vollumfänglich ab. An sie können Data Scientists anschließend das Datenmodell aus dem <code>StarSchema</code> (<code>data_model</code>), das Feature-Learning-Modell (<code>feature_learners</code>), sowie das Prognosemodell (<code>predictors</code>) übergeben (Listing 5).<pre class=„rtetx–listing listing“>

pipe.fit(population_table=population_train, peripheral_tables={"trans": trans})

</pre>Listing 5: Trainieren der PipelineIm nächsten Schritt gilt es, mit

fit

die konkreten Daten an die Pipeline zu übergeben. Der Methodenaufruf startet das Schätzen der Modelle. Im Rahmen von

fit

erlernt die Pipeline, basierend auf den Trainingsdaten, in einem ersten Schritt die Logik hinter den Features. Hierfür traversieren die Algorithmen die im abstrakten Datenmodell beschriebenen Pfade und lösen die Joins stückweise auf. Aus den nun materialisierten Daten ziehen die Algorithmen in der Folge wiederholt Stichproben und erlernen auf deren Basis die Logik eines Features. Zum Erlernen weiterer Features <a href=„https://en.wikipedia.org/wiki/Ensemble_learning“ rel=„external noopener“ target=„_blank“>kommen Ensemblemethoden zum Einsatz [25]</a>. Nach dem Erlernen der Features transformiert die Pipeline die gelernte Logik in konkrete Featurewerte.Sie dienen im zweiten Schritt dem Prognosealgorithmus (XGBoost) als Eingangsdaten. Mit einer geschätzten Pipeline (nach

fit

) ist es möglich, Prognosen auf ungesehene Daten vorzunehmen (

predict

), die Prognosegüte des Modells zu bestimmen (

score

) oder die Featurewerte zu materialisieren (

transform

). Letzteres erlaubt es, eigene Modelle zur Prognose (<a href=„https://scikit-learn.org/stable/“ rel=„external noopener“ target=„_blank“>beispielsweise aus scikit-learn [26]</a>) zu verwenden. Möglich ist hier aber prinzipiell die Nutzung eines jeden Modells, für das eine Python-API verfügbar ist.<h3 class=„subheading“ id=„nav_mit_feature8“>Mit Feature Learning zum Durchbruch</h3>Die Data Scientists des Kreditinstituts können mithilfe der Pipeline schließlich die Kreditausfallwahrscheinlichkeit potenzieller Kreditnehmer auf Basis der Transaktionshistorie einzelner Kunden berechnen. Hierfür müssen sie lediglich neue Daten an <code>predict</code> übergeben. Das Besondere: Die Data Scientists müssen selbst keine Transformationen an den Daten vornehmen, kein Feature manuell erstellen, keine Zeile SQL schreiben. Sie müssen lediglich die Rohdaten und die verfügbaren Metainformationen – Datenmodell und Annotationen – an die API übergeben. Eine typische Anforderung in der Praxis ist die Möglichkeit, die gelernte Logik hinter einem Feature zu untersuchen.<div class=„a-boxtarget a-boxcontent a-inline-textboxcontent a-inline-textboxcontent-container“ data-collapse-target=„“>Das vorgestellte Beispiel sowie über zwanzig weitere Beispiele sind in getMLs Demo-Repository auf Github verfügbar. Die getML-Engine steht als Free Trial <a href=„https://getml.com“ rel=„external noopener“ target=„_blank“>auf der Website von getML zum Download bereit [27]</a>. Auf Try GetML lassen sich alle <a href=„https://try.getml.com“ rel=„external noopener“ target=„_blank“>Beispiel-Notebooks interaktiv in einer JupyterLab-Umgebung [28]</a> im Browser ausführen.</div>Dadurch ist es möglich, die Geschäftslogik eines Features zu validieren. Das getML-Framework bietet die Möglichkeit, Features, aber auch ganze Pipelines, in verschiedene SQL-Dialekte zu transpilieren und beispielsweise auf einem Spark-Cluster auszuführen. Listing 6 zeigt exemplarisch die transpilierte Logik eines von Multirel auf Basis der Beziehung zwischen <code>population</code> und <code>trans</code> gelernten Features: Das Minimum des Kontostandes unter Berücksichtigung bestimmter Transaktionsarten und -zeitpunkte.<pre class=„rtetx–listing listing“>

CREATE TABLE feature_1_61 ASSELECT MIN(trans.balance) AS feature_1_61FROM populationINNER JOIN trans ON population.account_id = trans.account_idWHERE (trans.date &lt;= population.date_loan)  AND (((trans.operation NOT IN ('VYBER')         OR trans.operation IS NULL)        AND (trans.amount &gt; 18278.000000))       OR ((trans.operation IN ('VYBER'))           AND (population.date_loan - trans.date &gt; 7557120.000000)           AND (trans.balance &gt; 28786.000000))       OR ((trans.operation IN ('VYBER'))           AND (population.date_loan - trans.date &gt; 7557120.000000)           AND (trans.balance &lt;= 28786.000000                OR trans.balance IS NULL)           AND (trans.balance &lt;= 1681.000000))       OR ((trans.operation IN ('VYBER'))           AND (population.date_loan - trans.date &lt;= 7557120.000000)))GROUP BY population.account_id;

</pre>Listing 6: Ein von Multirel gelerntes Feature als SQL-Query – „VYBER“ klassifiziert BargeldabhebungenDas Beispiel zeigt einen typischen Anwendungsfall des relationalen Lernens – die Kreditvergabeentscheidung einer Bank – in einer vereinfachten Form. Data Scientists haben die Möglichkeit Feature-Learning-Algorithmen zur Entwicklung von beliebigen Prognosemodellen auf relationalen Daten oder Zeitreihen einzusetzen – unabhängig von der Industrie oder dem Anwendungsfall. Feature Learning birgt das Potenzial, durch eine algorithmische Ende-zu-Ende-Automatisierung eine zentrale Rolle innerhalb unternehmerischer ML-Anwendungen einzunehmen.<div class=„a-boxtarget a-boxcontent a-inline-textboxcontent“ data-collapse-target=„“><figure class=„a-inline-textboximage-container“><img alt=„Alexander Uhlig, getML“ src=„https://heise.cloudimg.io/width/1597/q50.png-lossy-50.webp-lossy-50.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/portrait-alex-483a85ddcfa00029.jpeg“ srcset=„https://heise.cloudimg.io/width/3194/q30.png-lossy-30.webp-lossy-30.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/portrait-alex-483a85ddcfa00029.jpeg 2x“ class=„c1“ referrerpolicy=„no-referrer“ /></figure><div class=„a-inline-textboxcontent-container“>Alexander Uhligist einer der Gründer von getML. Er studierte Physik (M.Sc.) in Leipzig und arbeitete nach seinem Studium in dem VW Data:Lab, einer KI-Abteilung innerhalb der Volkswagen AG. Seit 2017 entwickelt er mit seinem Team das Machine-Learning-Framework getML und brachte es in zahlreichen Kundenprojekten erfolgreich zur Anwendung.</div></div><div class=„a-boxtarget a-boxcontent a-inline-textboxcontent“ data-collapse-target=„“><figure class=„a-inline-textboximage-container“><img alt=„Sören Nikolaus, getML“ src=„https://heise.cloudimg.io/width/1188/q50.png-lossy-50.webp-lossy-50.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/portrait-soeren-e04131fa59166b6c.jpg“ srcset=„https://heise.cloudimg.io/width/2376/q30.png-lossy-30.webp-lossy-30.foil1/_www-heise-de_/imgs/18/3/4/4/3/5/0/9/portrait-soeren-e04131fa59166b6c.jpg 2x“ class=„c1“ referrerpolicy=„no-referrer“ /></figure><div class=„a-inline-textboxcontent-container“>Sören Nikolausarbeitet seit 2020 als Data Scientist Developer Advocate und Entwickler bei getML. Er vermittelt zwischen Kunden, Nutzern und getMLs Entwicklungsteam. Er studierte Volkswirtschaftslehre (M.Sc.) in Leipzig.</div></div>() <hr />URL dieses Artikels:

https://www.heise.de/-6655369

Links in diesem Artikel:

<strong>[1]</strong>&#160;https://www.heise.de/hintergrund/Alpine-js-Das-Schweizer-Taschenmesser-fuer-dynamische-Weboberflaechen-6177628.html

<strong>[2]</strong>&#160;https://www.heise.de/hintergrund/Developer-Experience-Glueckliche-Entwickler-schreiben-besseren-Code-6150890.html

<strong>[3]</strong>&#160;https://www.heise.de/hintergrund/Ethik-und-Kuenstliche-Intelligenz-ein-neuer-Umgang-mit-KI-Systemen-6056059.html

<strong>[4]</strong>&#160;https://www.heise.de/developer/young-professionals-6065678.html

<strong>[5]</strong>&#160;https://de.wikipedia.org/wiki/Pr%C3%A4diktive_Analytik

<strong>[6]</strong>&#160;https://arxiv.org/abs/1206.5538

<strong>[7]</strong>&#160;https://xgboost.ai/

<strong>[8]</strong>&#160;https://www.microsoft.com/en-us/research/wp-content/uploads/2013/01/andrew-ng_machinelearning.pdf

<strong>[9]</strong>&#160;https://en.wikipedia.org/wiki/Flat-file_database

<strong>[10]</strong>&#160;https://de.wikipedia.org/wiki/Grundgesamtheit

<strong>[11]</strong>&#160;https://dl.acm.org/doi/10.1145/2347736.2347755

<strong>[12]</strong>&#160;https://www.wired.com/story/fei-fei-li-artificial-intelligence-humanity/

<strong>[13]</strong>&#160;https://www.wired.com/story/fei-fei-li-artificial-intelligence-humanity/

<strong>[14]</strong>&#160;https://docs.getml.com/latest/user_guide/feature_engineering/feature_engineering.html#multirel

<strong>[15]</strong>&#160;https://link.springer.com/chapter/10.1007/978-3-540-48247-5_46

<strong>[16]</strong>&#160;https://docs.getml.com/latest/user_guide/feature_engineering/feature_engineering.html#relboost

<strong>[17]</strong>&#160;https://en.wikipedia.org/wiki/Gradient_boosting

<strong>[18]</strong>&#160;https://docs.getml.com/latest/user_guide/feature_engineering/feature_engineering.html#algorithms

<strong>[19]</strong>&#160;https://docs.getml.com/latest/user_guide/feature_engineering/feature_engineering.html?highlight=incremental%20updates#multirel

<strong>[20]</strong>&#160;https://github.com/getml/getml-demo#benchmarks

<strong>[21]</strong>&#160;https://github.com/getml/getml-demo#benchmarks

<strong>[22]</strong>&#160;https://de.wikipedia.org/wiki/Klassifikationsverfahren

<strong>[23]</strong>&#160;https://docs.getml.com/latest/user_guide/annotating_data/annotating_data.html

<strong>[24]</strong>&#160;https://docs.getml.com/latest/api_reference/dataframe.html

<strong>[25]</strong>&#160;https://en.wikipedia.org/wiki/Ensemble_learning

<strong>[26]</strong>&#160;https://scikit-learn.org/stable/

<strong>[27]</strong>&#160;https://getml.com

<strong>[28]</strong>&#160;https://try.getml.com

<strong>[29]</strong>&#160;mailto:sih@ix.de

Qgelm

Seiten-Werkzeuge

Webseiten-Werkzeuge

Benutzer-Werkzeuge

Neue Algorithmen für relationales Lernen: Was Deep Learning nicht beherrscht