Low-Fidelity-Designs erstellen, indem Sie mit Ihrem Computer sprechen

Wir hatten einen Traum ...#

TeleportHQ wurde 2016 mit dem Ziel gegründet, Technologie menschlicher zu gestalten. Wir stellten ein Team aus internationalen Designern, Entwicklern und Datenwissenschaftlern zusammen, das sich zum Ziel gesetzt hat, leistungsstarke Tools zu entwickeln, die das gesammelte Wissen der Menschheit bewahren und nutzen und so den Prozess der Benutzeroberflächenerstellung zunehmend automatisieren.

Eine unserer ersten Ideen auf der Forschungs-Wunschliste war, Websites allein durch Gespräche mit einem Computer zu erstellen. Jüngste Durchbrüche im Bereich der KI machten die Generierung von Benutzeroberflächen erstmals greifbar.

Um eine erfolgreiche Lösung für maschinelles Lernen zu entwickeln, benötigten wir zwei wesentliche Elemente: eine große Datenmenge und ein „Übersetzungswerkzeug zwischen Mensch und Computer“, das natürliche Sprache erkennt und in Programmiersprachen umwandelt. Besonders schwierig gestaltete sich die Suche nach einem geeigneten Übersetzungswerkzeug. Wir versuchten es mit Tools wie IBM Watson oder Google Dialogflow, doch diese erwiesen sich für unsere Zwecke als ungeeignet.

Gleichzeitig entwickelte unser Engineering-Team die Playground, eine neue visuelle Entwicklungsplattform für Benutzeroberflächen. Die Technologie von Playground ermöglichte es Entwicklerinnen und Entwicklern, Designerinnen und Designern sowie Produktteams, gemeinsam an einem Projekt zu arbeiten und den resultierenden Code ihrer gemeinsamen Arbeit sofort in Echtzeit zu sehen.

Playground setzte sich durch, gewann an Bedeutung und baute eine wachsende Nutzergemeinschaft auf. Die Plattform basiert auf der User Interface Development Language UIDL, der Zwischendarstellungssprache von TeleportHQ, sowie einer Reihe von Open-Source-Codegeneratoren.

Wie diese Komponenten zusammenwirken, sehen Sie in unserem REPL, in dem Sie die UIDL bearbeiten und die Codegenerierung in Echtzeit in verschiedenen JavaScript-Varianten verfolgen können.

Die Entwicklung von Playground brachte einen zusätzlichen Vorteil mit sich: Die UIDL und die Open-Source-Codegeneratoren lieferten den entscheidenden Teil der Infrastruktur, der unseren ursprünglichen Forschungsansatz voranbrachte. Für Data Scientists war die UIDL als domänenspezifische Sprache deutlich einfacher zu handhaben als reiner Code, der schon beim kleinsten Syntaxfehler abstürzen und anschließend manuell repariert werden muss.

Dank dieses Vorteils hat TeleportHQ bei der Entwicklung von Websites durch Gespräche mit einem Computer bedeutende Fortschritte erzielt. Hier sehen Sie ein Video mit unseren neuesten Entwicklungen:

https://www.youtube.com/embed/fq1RPJUI_GM

Wir stehen kurz davor, unseren Traum Wirklichkeit werden zu lassen, und möchten im folgenden Blogbeitrag einige entscheidende Schritte unserer Forschung vorstellen.

Das Ziel festlegen: Die Ausgabe des Modells definieren#

Unser erster Schritt bestand darin, die Ausgabe zu definieren, für die wir unser Modell trainieren wollten. Um das Problem zu vereinfachen, entschieden wir uns für einen sogenannten „semantischen“ Ansatz: eine Menge von Begrenzungsrahmen mit ihren Typen und absoluten Positionen. Dieses Format nannten wir „Low-Fidelity-Design“, da es eine Teilmenge dessen darstellt, was üblicherweise als High-Fidelity-Design bezeichnet wird (das auch Farben, Formen, Schriftarten und weitere visuelle Merkmale umfasst). Man könnte sagen, unser Low-Fidelity-Design verhält sich zum High-Fidelity-Design wie eine Struktur aus einfachen HTML-Tags zu einer Webseite mit all ihren Texten und CSS-Eigenschaften.

Datenaufbereitung: Aufbau des Trainingsdatensatzes#

Parallel zur Entwicklung unseres Playgrounds begannen wir, Millionen von Webseiten zu sammeln und aufzubereiten, um uns kontinuierlich kuratierte Daten bereitzustellen, die wir für unser Wireframe-zu-Code- Projekt verwendeten.

Um diese wachsende Datenbank zu verwalten und auf sie zuzugreifen, entwickelten wir einen eigenen Web-Parser, der bis zu 6.000 Seiten pro Minute verarbeiten kann. Mehr zu diesem Thema erfährst du in diesem Blogbeitrag.

Wir beschlossen, die Webseiten schrittweise zu generieren – beginnend mit der Navigationsleiste und endend mit der Fußzeile. Dazu extrahierten wir aus unserem Hauptdatensatz mit Webseiten eine Teilmenge von 850.000 Abschnitten, die verschiedene semantische Bereiche der Webseiten repräsentieren. Hier ein Beispiel:

Daten und Screenshot eines Low-Fidelity-Hero-Bereichs

Erste Versuche: Sequenz-zu-Sequenz-Autoencoder#

Ende 2019 begannen wir mit einem einfachen, unüberwachten Ansatz auf Basis eines Sequenz-zu-Sequenz-Autoencoders. In der Mitte dieser Architektur befindet sich ein Engpass, in dem die Abschnitte in ein eindimensionales Array kodiert werden. Dieser Engpass wird üblicherweise zur Generierung neuer Daten verwendet. Daher dachten wir, dass sich daraus neue Designs erzeugen ließen, indem wir seine Werte zufällig abtasten.

Leider funktionierte es nicht wie erwartet. Obwohl das System das Kodieren und Dekodieren erlernen konnte, versagte es bei neuen Beispielen oder mit einer zufälligen Kodierung völlig.

Wir probierten einige weitere Ansätze und Architekturen aus, darunter Variations-Autoencoder, GANs und graphneuronale Netze. Doch nach neun Monaten voller Versuche und Fehlschläge waren die Ergebnisse nicht praktikabel.

Autoencoder-Architektur

Der Wendepunkt: Der Einzug der GPT-3-Technologie#

Anfang dieses Jahres veröffentlichte OpenAI eine neue Version des Generative Pretrained Transformer (GPT-3). Das System setzt neue Maßstäbe und erzielt Spitzenresultate bei einer Reihe von Benchmarks, etwa bei der Beantwortung von Fragen und der maschinellen Übersetzung.

GPT-3 erzeugt auf Grundlage eines vorgegebenen Kontexts Folgen diskreter Werte. Ausgehend von diesem Kontext vervollständigt das Modell die Sequenz, indem es sie Token für Token fortsetzt.

Da das Modell mit dem gesamten Internettrainiert wurde, erzielt es erstaunliche Ergebnisse bei vielfältigen Aufgaben – von Philosophie bis Medizin. Eine bestimmte Anwendung hat jedoch besonders unsere Aufmerksamkeit geweckt: die Codegenerierung.

Zwei Beispiele stachen besonders hervor. Im ersten wurde GPT-3 zur Generierung von Bash-Befehleneingesetzt. Im zweiten generierte das Modell JSX-Code. Diese beiden Beispiele begeisterten unser Team, denn das Modell hatte offensichtlich die Daten von Stack Overflow erfolgreich verarbeitet. Dies war ein unwiderlegbarer Beweis dafür, dass die GPT-Technologie es ermöglichen könnte, mit einer Maschine zu sprechen und Benutzeroberflächen zu erstellen.

GPT-3 generiert Bash-Befehle aus natürlicher Sprache

Rückenwind: Die Möglichkeiten von GPT nutzen#

Begeistert vom Potenzial dieser Technologie bat TeleportHQ um frühzeitigen Zugang zu GPT-3, erhielt jedoch eine Absage. Dennoch waren wir überzeugt, dass die GPT-Architektur die Lösung für unsere Herausforderungen im Bereich maschinelles Lernen bot. Deshalb beschlossen wir, eine eigene Version zu entwickeln. Nach einiger Recherche entschieden wir uns für minGPT, eine schlanke Implementierung von GPT.

Ein Bild sagt mehr als tausend Worte: GPT vs. minGPT

Mit den verfügbaren Daten und der Einfachheit von minGPT konnten wir unsere Daten sehr schnell in das Netzwerk einspeisen. Zu unserer größten Überraschung funktionierte es einfach.

In diesem ersten Experiment lernte das Modell, die Abschnitte unserer Seite Zeichen für Zeichen zu generieren – einschließlich der Tiefe und der Koordinaten jedes Elements.

Mit dem Kontext „DIV 0 0.5 0.5 1.0 1.0“ konnte das Modell die Daten eines Abschnitts automatisch vervollständigen. Anschließend ließ sich die folgende Baumansicht rekonstruieren:

Erster mit GPT-UI aus dem Kontext „DIV 0 0.5 0.5 1.0 1.0“ generierter Abschnitt

Obwohl vielversprechend, war das Problem noch nicht gelöst: Der Kontext ließ sich noch nicht als Nutzerabsicht definieren. Daher verfeinerten wir das Modell, indem wir den zu generierenden Inhalt (z. B. die Anzahl der Bilder, Absätze oder Divs) an den Anfang der Sequenz setzten.

Und wieder: Es funktionierte einfach.

Unten sehen wir einige ausgewählte Abschnitte, die mit diesem verbesserten Modell generiert wurden. In allen Fällen waren nicht nur die Baumansichten und Begrenzungsrahmen stimmig, sondern die generierten Abschnitte enthielten auch die angeforderten Inhalte.

Ein Beispiel für den neuen Kontext sieht so aus: „IMG 2 P 2 H1 2 $“. Fügte man ihn einfach vor dem Abschnitt selbst ein, konnte das Modell nach dem ersten „$“ ansetzen und den gesamten Abschnitt automatisch generieren.

Drei Abschnitte aus den frühen Phasen unserer Experimente

Anschließend gingen wir noch einen Schritt weiter und fügten zusätzliche Informationen am Anfang der Sequenz ein, um den Prompt anzureichern. Daraufhin konnte das System lernen, Abschnitte mit bestimmten Höhen, Ausrichtungen und Funktionen zu generieren.

Unsere erste funktionsfähige Architektur

Es fehlte nur noch ein letztes Element: eine Benutzeroberfläche, über die ein Mensch mithilfe natürlicher Sprache mit dem Computer kommunizieren kann. Wir entwickelten folgendes Setup, bei dem die Absicht des Nutzers über ein Formular eingegeben wird.

Das erste Formular für die Interaktion mit dem Modell

Nachdem wir das Formular erstellt hatten, ergänzten wir eine programmatische Ebene, die die natürlichsprachlichen Befehle (z. B. „Hey TeleportHQ, erstelle für mich einen Abschnitt vom Typ Navbar mit 1 Bild und 4 Links mit einer Höhe von 65 Pixeln“) in Kontexte umwandelte (z. B. „NAVBAR $ h 65 $ IMAGE 1 LINK 4 $“).

Unten sehen Sie eine Demo unserer aktuellen Benutzeroberfläche. Sie ermöglicht es Nutzern, mit dem Modell zu interagieren und in wenigen Minuten eine Webseite zu erstellen.

GPT-UI-Prototyp

Neue Horizonte: Auf ins Jahr 2021 …#

Vor vier Jahren gehörte TeleportHQ zu den wenigen Teams, die daran glaubten, dass sich Benutzeroberflächen mithilfe natürlicher Sprache erstellen lassen. Seitdem arbeiten wir kontinuierlich daran, die Grundlagen für eine reibungslose Kommunikation zwischen Mensch und Maschine zu schaffen. Unsere Ergebnisse bringen uns unserem ursprünglichen Ziel immer näher: den Prozess der Erstellung von Benutzeroberflächen vollständig zu automatisieren.

Heute verfügen wir über einen voll funktionsfähigen GPT-UI-Prototyp. Er umfasst 6 Millionen Parameter – im Vergleich zu den gewaltigen 175 Milliarden Parametern von GPT-3.

GPT-3 wird zwar für seine enorme Leistungsfähigkeit geschätzt, da es praktisch jede Aufgabe in englischer Sprache bewältigen kann, doch unser Modell ist dank seiner kleineren, agileren Größe spezialisierter und reaktionsschneller.

Mit den richtigen Daten und dank des restlichen Trainings zur Teleport-Architektur konnte unsere GPT-UI mit der Zeit beim Erstellen von Benutzeroberflächen aus natürlichsprachlichen Eingaben mit GPT-3 mithalten. Dabei bietet sie den zusätzlichen Vorteil, vollständig anpassbar zu sein und nur einen Bruchteil der Ressourcen zu benötigen, die für den Betrieb des Modells erforderlich sind.

TeleportHQ nutzt bereits denselben Ansatz, um weitere neue Modelle zu entwickeln, die auf das Erstellen bestimmter Komponenten und vollständiger mobiler Designs spezialisiert sind.

Wir sind begeistert von seinem Potenzial und zuversichtlich, dass wir in naher Zukunft vollständige, detailgetreue Webseiten mit einer einzigen Anfrage generieren können.

Wenn Sie eine private Demo anfragen, eine Zusammenarbeit vorschlagen oder uns Feedback geben möchten, kontaktieren Sie uns gerne unter hello@teleporthq.io .

💡

Wenn Ihnen dieser Artikel gefallen hat, interessieren Sie sich vielleicht auch für unsere früheren Ergebnisse zum automatischen Generieren von Code aus Wireframes mithilfe von maschinellem Lernen.

https://www.youtube.com/embed/ZD8Cnzc6KlY