Im heutigen Wochenrückblick schauen wir auf einen spannenden Essay, ein interessantes Tool für Code-Migrationen und ein neues Open-Source-LLM für große Sequenzlängen.
The Rise of the AI Engineer
Beginnen wir den heutigen Wochenrückblick mit einem Artikel, der in der Woche disktutiert wurde. swyx hat auf Latent Space den Artikel The Rise of the AI Engineer veröffentlicht. Im Artikel geht es um die Entstehung eines komplett neuen Berufszweiges: dem AI Engineer. Dabei ist der AI Engineer die Weiterentwicklung des Prompt Engineers und wird im Essay auf einer Skala eingeordnet. Der AI Engineer beschäftigt sich wenig mit der genauen Funktionsweise von ML-Modellen, vielmehr versteckt ihm die API wie z. B. von OpenAI die technischen Details und ermöglicht ihm, sich auf das Wesentliche zu konzentrieren: sein Produkt.
War es vor zehn Jahren noch ein forschungsnahes Vorhaben, ein Produktempfehlungssystem zu entwerfen, ist es durch die Verfügbarkeit von schnell einsetzbaren Diensten heutzutage möglich, die gewünschte Funktionalität zu integrieren. Integration, das ist es, was den AI Engineer ausmacht. Er muss nicht wissen, wie ein LLM genau funktioniert, er muss nur wissen, was es tut. Insbesondere erwähnt der Autor des Essays, dass die Few-Shot-Modelle dazu geführt haben, dass ML-Forscher selber nicht mehr das Modell wie GPT-4 auf den Einsatzzweck abstimmen, sondern diese Aufgabe von Anwendern übernommen wird, die Zeit mit dem Modell und der Schnittstelle verbringen und ausprobieren, was man damit tun kann.
Das alles wird nicht einfach sein, vor allem, da klassische ML-Forscher über lange Zeit hinweg dieses Feld noch belächeln werden. Behält man diesen Wandel allerdings im Hinterkopf, kann man sich schon jetzt darauf einstellen und wird nicht überrascht, wenn in fünf Jahren Menschen, deren Vollzeitjob die Integration von ML-Systemen ist, hohe Gehälter und einen substantiellen Einfluss auf den Geschäftsbetrieb vieler Firmen erhalten.
GPT-Migrate
Wie so eine konkrete Anwendung aussehen kann, zeigt bereits GPT-Migrate. Hier handelt es sich um ein interessantes Produkt, das eine Codebase von einer Programmiersprache in eine andere umwandelt.
Das Projekt selber setzt auch nur auf bestehende LLMs, nutzt sie aber in einer besonders abgestimmten Art und Weise. Der Code soll nicht nur starr umgewandelt, sondern auch idiomatisch sinnvoll ausgegeben werden. Wandelt man beispielsweise ein Python-Projekt in eine Node.js-Application um, besteht die Arbeit aus mehr als nur einer 1:1-Umwandlung der Statements. Vielmehr müssen die Frameworks beachtet werden mit ihrer individuellen Weise, Lösungen abzubilden.
Betrachten wir ein solches Projekt aus der akademischen Sicht, ist so ein Projekt ein Himmelfahrtskommando: Wir können nicht mit hinreichender Sicherheit sagen, ob es immer zuverlässig funktioniert. In der Praxis hat dieser Umstand für den durchschnittlichen Anwender allerdings eine untergeordnete Rolle: wenn es auch nur regelmäßig funktioniert, bringt es viele Entwickler für ihre Durchschnittsprojekte schon weiter. So sind Informatiker heutzutage auch nicht durchgängig mehr damit beschäftigt, richtige Algorithmen für z. B. Sortierung zu entwerfen, sondern reihen eher fertige Programmfragmente und -prozeduren aneinander. Eine unbeaufsichtigte Dienstleistung für Codeumwandlung sollte dennoch nicht auf so einem einfachen System aufgebaut werden. Die Abstimmung, die feinen Anpassungen und die Risikoanalyse - auch das werden in meinen Augen Aufgaben des AI Engineers sein.
Salesforce XGen
Neue Modelle sollen auch in diesem Wochenrückblick nicht fehlen. In dieser Woche haben wir diesbezüglich wieder einen alten Bekannten dabei: Salesforce, bekannt von BLIP2 oder CodeT5. Diesmal hat sich das Forschungsteam rund um Nijkamp, Xie, Hayashi, Pang und Xia mit Open-Source-LLMs für besonders hohe Sequenzen beschäftigt.
Die Sequenzlänge als maximale Länge einer Eingabe für das LLM ist neben der Parameterzahl einer der wichtigsten numerischen Einflussfaktoren für die Leistungsfähigkeit von LLMs. Soll ein solches Modell beispielhaft einen Text zusammenfassen, kann ein LLM mit 8 Tsd. Tokens Sequenzlänge deutlich mehr Text in einem Zug verarbeiten als ein LLM mit 2 Tsd. Tokens Sequenzlänge. Dass die Sequenzlänge in Tokens statt Wörtern gemessen wird, ist auf die mathematische Darstellung der Eingaben für LLMs zurückzuführen. Im Wochenrückblick der vergangenen Woche habe ich für diese Thematik Lehrmaterial vorgestellt.
Salesforce hat unter dem Namen XGen-7B Modelle mit einer Sequenzlänge von 8 Tsd. Tokens und einer Parameterzahl von 7 Mrd. trainiert, die den bisherigen Open-Source-Modellen mit nur 2 Tsd. Tokens wie LLaMA, MPT oder Falcon in standardisierten Benchmarks wie MMLU oder SCROLLS mindestens gleichauf sind. Die kommerzielle Konkurrenz kommt mit GPT-4 auf 32 Tsd. Tokens oder mit Claude auf 100 Tsd. Tokens. Das Training wurde mit 1,5 Billionen Tokens (hier nicht Sequenzlänge, sondern Anzahl der Tokens, auf deren Basis trainiert wurde) durchgeführt und hat über 150.000 US-Dollar gekostet.
Weitere Informationen zu XGen sind im Blogartikel von Salesforce Research zu finden. Die XGen-7B-Modelle sind in verschiedenen Varianten auf HuggingFace unter der Apache-2.0-Lizenz verfügbar, der zugrundeliegende Code kann unter GitHub abgerufen werden.
Und so geht wieder eine spannende Woche zu Ende, in der wir beobachten konnten, wie einerseits weiterhin neue Open-Source-Modelle mit Verbesserungen veröffentlicht werden und andererseits die Anwendung solcher Modelle zunehmend in den Vordergrund tritt. Schauen wir, was uns auch in den nächsten Tagen wieder erwartet!
