Tech-Talk: LLMs Eat Coding

Gibt man grossen Sprachmodellen (LLMs) Programmieraufgaben, erhält man praktisch immer eine Antwort, formuliert in einer Programmiersprache nach Wahl. Das Coden – also das Erzeugen von maschinenausführbaren Programmen – scheint sich zu einer an die sogenannte Künstliche Intelligenz delegierbaren Aufgabe zu entwickeln. Für den Informatik-Studiengang einer Fachhochschule stellt sich daher die Frage, welche Programmierfähigkeiten in Zukunft (noch) vermittelt werden sollten.

Zunächst bleibt festzuhalten, dass der oft gehörte Begriff «Coden» eigentlich einen falschen Schwerpunkt setzt. Die Schwierigkeit bei der Programmierung heutzutage liegt nicht darin, einen im Detail verstandenen Lösungsansatz oder algorithmischen Ablauf in eine maschinenlesbare Form zu übersetzen (also zu codieren), sondern darin, sinnvoll programmierbare Lösungen überhaupt zu finden und präzise zu kommunizieren.

Tatsächlich wurden Programmiersprachen in der Anfangszeit der Informatik nicht ausschliesslich für die Kommunikation mit Maschinen entwickelt, sondern auch als Kommunikationsmittel, um algorithmische Ideen nicht als englischen Text, sondern in einer mathematisch präzisen und konzisen Form publizieren zu können.

So betrachtet, liefern LLMs einen in einer solchen formalen Sprache dargestellten Lösungsansatz, den es zu verstehen, zu überprüfen und zu bewerten gilt. Künstliche Intelligenz kann nicht Verantwortung für ihre Produkte übernehmen. Erstens, weil den Sprachmodellen der Bezug zu objektiver Wahrheit fehlt, zweitens, weil ein Sprachmodell keinerlei Konsequenzen von durch Produkte entstandene Schäden trägt – weder zivil- noch strafrechtlich.

In Tat und Wahrheit ist «Programmieren» viel mehr als pures Erzeugen eines ausführbaren Programms. Nebst Verständnis für das formale Kommunikationsmittel (Programmiersprache), muss man in der Lage sein, sich in Programmbibliotheken zu orientieren. Die hier benötigten Fähigkeiten sind vor allem das systematische Lesen von Dokumentationen, damit die bestgeeigneten Operationen ausgewählt und mit den richtigen Argumenten genutzt werden können. Für Aufgaben, die im Wesentlichen im Verbinden von solchen vorhandenen Operationen bestehen, enthalten Literatur und Internet-Foren auch viele Anwendungsbeispiele, die in das Training der Sprachmodelle eingeflossen sind. Wohl deswegen lassen sie sich auch gut zur Beschleunigung solcher Arbeiten nutzen.

Eine andere Art der Programmierung setzt algorithmisches Denken voraus. Bei derartigen Aufgaben ist die Variabilität grösser und damit der Anteil an notwendigen Transferleistungen, falls überhaupt genügend ähnliche Muster zur Verfügung stehen. Verlangt ist die Konstruktion eines Lösungswegs auf Basis nur weniger konzeptueller Elemente. In der prozeduralen oder imperativen Programmierung sind das: Sequenzen von Zuweisungen an Variablen als Speicherplätze, berechenbare Ausdrücke, Fallunterscheidungen und Wiederholungsanweisungen. Daraus muss die Lösung einer Aufgabe zusammengesetzt werden können, egal mit welchem Formalismus man das am Ende darstellt.

Im Folgenden wollen wir uns auf das Finden und Formulieren von algorithmischen Lösungen konzentrieren.

Heute soll, wer ein Informatik-Studium absolviert hat, gewisse grundlegende Algorithmen und ihre Eigenschaften kennen (von Binärer Suche bis Tiefen- und Breitensuche in Graphen, beispielsweise) und diese selbst für konkrete Aufgaben auswählen, modifizieren und korrekt implementieren können. Dazu gehört Handwerkszeug für exaktes Arbeiten und rigoroses Argumentieren, um erstens Fehler zu vermeiden und zweitens Anderen gegenüber über die Korrektheit argumentieren zu können. Austausch und Dialog über solche programmierten Lösungen sind wichtig für Review-Prozesse und zur Bildung von Vertrauen in Ingenieurs-Produkte.

An Übungs- und Prüfungsaufgaben aus unserem grundlegenden Modul über Algorithmen und Datenstrukturen lässt sich zeigen, dass grosse Sprachmodelle je nach Modell und Prompting-Technik unterschiedliche Antworten liefern. So erhält man unter Umständen eine Lösung mit linearem Aufwand, wo auch eine mit logarithmischem Aufwand möglich wäre. Antworten von Sprachmodellen strahlen immer sehr viel «Überzeugung» aus. Einfache Rückfragen, ob es auch bessere Lösungen gäbe, und selbst hartnäckiges Nachfragen führen selten zu fundamental anderen Ergebnissen als die ursprüngliche Antwort. Es braucht das klare Wissen um bessere Lösungsansätze, um sich nicht mit der erstbesten Lösung zufriedengeben.

Auch für korrekte und gute Lösungen, erhält man oft Programme mit unnötigen Komplikationen, wie explizit ausprogrammierte Spezialfälle, die aber auch der allgemeine Lösungsteil des Programms gut mit abdecken würde. Auch hier braucht es genaues Hinschauen, um die Programme zu prüfen und zu vereinfachen. Gleiches gilt für das Nicht-Einhalten mancher Richtlinie für gute Strukturen.

Natürlich machen nicht nur KI-System gelegentlich Fehler, sondern auch Menschen. Neurologen mögen argumentieren, dass das menschliche Gehirn genauso statistisch arbeitet, wie ein neuronales Netz in einem LLM. Aus diesem Grund hat das Engineering Hilfsmittel erfunden, um Zusammenhänge und Details unabhängig von rein sprachlichen Formulierungen präzise sichtbar (im Wortsinn!) zu machen. Das sind vor allem Konstruktionszeichnungen und mathematische Formeln. Zeichnet man Dinge auf oder rechnet mit formalen Systemen, fallen Fehlüberlegungen und Ungenauigkeiten viel deutlicher auf.

Diese Werkzeuge und Denkweisen werden wir in unserer Ausbildung stärker betonen müssen. Gefährlich ist, dass wir Programmier-erfahrene Dozierende Programmier-Aufgaben lösen, ohne immer gleich eine Zeichnung zu machen. Reflektiert man aber den Gedankengang, wird klar, dass das nur geht, weil man die einzelnen Überlegungen schon wiederholt gemacht hat und tatsächlich auf Erfahrung zurückgreift, die den Beginnenden fehlt. Als Vorbilder müssen wir also vermehrt die Gedankengänge ausführlich und präzise darlegen und so eine Haltung von Exaktheit und Exzellenz im Dialog vorleben.

Besonders in der Ausbildung gilt eben: Programmieren ist Silber, über Programme zu sprechen ist Gold.

Tech-Talk und Blog Beitrag:
Wolfgang Weck (wolfgang.weck@fhnw.ch), Dozent für Informatik am IMVS