KĂĽnstliche Intelligenz in der Softwarearchitektur praktisch einsetzen
Künstliche Intelligenz macht Softwarearchitektur und kann Architektinnen und Architekten auf vielfältige Weise bei Entwurf, Prüfung oder Diagramm unterstützen.
- Ralf D. MĂĽller
- Künstliche Intelligenz kann die Architekturarbeit bei Entwurf, Konzepten und Diagrammen vielfältig unterstützen – auch ohne die Preisgabe interner Daten in die Cloud.
- Verschiedene Einstellungen und Funktionen im Frontend helfen, den Kontext von Dialogen besser zu steuern, zu variieren und das Ergebnis zu optimieren.
- Das LLM verfügt über kein Gedächtnis, aber mit speziellen System-Prompts können Anwenderinnen und Anwender immer wiederkehrende Präferenzen voreinstellen. Einen speziellen System-Prompt gibt es beispielsweise für die Dokumentationsvorlagen von arc42.
- Die Modelle können ihre Ergebnisse auch selbst validieren und einen Proof of Concept mit lauffähigem Code ausführen.
Die Büchse der Pandora ist geöffnet: Generative AI in Form von Large Language Models (LLMs) wie ChatGPT, Gemini, Claude etc. hat sich rasant entwickelt und erobert immer mehr Bereiche in der Arbeit von Softwareentwicklerinnen und -entwicklern. Sie kann auch die Tätigkeiten von Softwarearchitekten unterstützen, wie einige Beispiele im Folgenden zeigen sollen.
Eine der wichtigsten Eigenschaften der heutigen LLMs ist, dass die Größe des zugrunde liegenden neuronalen Netzes gemessen in Parametern (Gewichtungen der Neuronen) auch die Leistungsfähigkeit bestimmt. Für die flexible Unterstützung der Architekturarbeit ist ein großes Modell von Vorteil, das oft nicht lokal betrieben werden kann, weshalb Cloud-Dienste unverzichtbar sind. Daraus ergeben sich Fragen zum Vertrauen in die Datenverarbeitung in der Cloud, wobei jeder Anbieter hier eigene Richtlinien hat. Im weiteren Verlauf zeigt der Artikel jedoch, dass LLMs auch ohne die Preisgabe interner Daten Nutzen stiften.
Frontend und Kontext
Hinter einer Technologie wie ChatGPT stehen verschiedene Komponenten: Die LLMs sind nur ein Aspekt, denn auch das Frontend, das das LLM steuert, hat eine große Bedeutung. Ein Blick auf die API (Dokumentation und Referenz) zeigt den stateless-Charakter aller Anfragen an das LLM. Es bekommt mit jedem Request eine Anfrage und liefert eine Antwort. Damit daraus ein Dialog entsteht, baut das Frontend aus den Fragen und Antworten einen Kontext auf, der mit der Zeit anwächst und immer wieder an das Modell übergeben wird.
Anwenderinnen und Anwender können sich bestimmte Eigenschaften des Frontends zunutze machen. Abbildung 1 zeigt beispielsweise einen Teil der smarten Kontrollen, die sich unter jedem Teil des Dialogs im ChatGPT-Frontend finden. Eigene Prompts können hier jederzeit editiert werden (Edit-Icon), um Anforderung genauer zu spezifizieren. Eine Antwort des Bots kann jederzeit neu generiert werden (Reload-Icon), um ein besseres Ergebnis zu erhalten. Damit ersetzen User den eigentlich linearen Chatverlauf durch einen Dialogbaum, durch den sie sich mit den <>-Icons navigieren (siehe Abbildung 2).
Auch wenn die Größe des Kontexts, mit dem die neueren Modelle umgehen können, immer weiter wächst, so spielen mehrere Faktoren für die Qualität der Antworten eine wichtige Rolle. Genauso, wie Menschen im Gespräch nur mit einem begrenzten Kurzzeitgedächtnis arbeiten, ist es auch bei LLMs. Überladen User das Modell mit Informationen im Kontext, so laufen Antworten irgendwann aus diesem Kontext und das Modell weiß plötzlich nicht mehr, was die eigentliche Aufgabe des Dialogs war. Ein Dialogbaum verkleinert den Kontext, da immer nur ein Ast des Baums dafür verwendet wird und nicht der komplette Dialog mit allen Korrekturen.
Das Neugenerieren einer Antwort funktioniert in der Regel nur, wenn das Modell Variationen in der Antwort zulässt. Dies wird über den Parameter temperature
in der API gesteuert. Ist er größer Null, so wird das Modell kreativer, indem es nicht immer die wahrscheinlichste Antwort generiert. Für die Architekturarbeit kann es sinnvoll sein, diesen Parameter je nach Aufgabe zu variieren.
Auch die Kosten der API spielen in diesem Zusammenhang eine Rolle: Anfragen werden in Ein- und Ausgabe-Token abgerechnet. Ein Token entspricht dabei circa einem bis vier Zeichen, sodass die Anfragen mit jedem Dialogschritt teurer werden, denn der Kontext wächst. Diese Kosten summieren sich recht schnell. Ein optimierter, kürzerer Kontext, der durch das Editieren eines Prompts anstelle des Neuformulierens entsteht, kann sich schnell auszahlen. Das macht sich vor allem dann bemerkbar, wenn das Modell auf eine Anfrage eine lange Antwort generiert. Formuliert der Nutzer den Prompt neu, anstatt ihn zu editieren, landet die lange Antwort mehrfach im Kontext und erzeugt Kosten.
Im Blick behalten sollten Anwenderinnen und Anwender auch den Aspekt des Session-Poisoning, also das Vergiften des Dialogs. Ist er in eine falsche Richtung gelaufen, weil Nutzer falsche Bedingungen genannt haben oder das Modell sich in der Antwort geirrt hat, so bleibt diese Fehlinformation bei einem linearen Chatverlauf bestehen. Im menschlichen Dialog würden die Gesprächspartner darüber hinwegsehen – nicht so die Maschine. Der Dialog ist mit den falschen Informationen vergiftet, was die Qualität der Antworten in der Folge beeinflusst. Deshalb ist die Navigation innerhalb des Dialogs so wichtig, denn der Nutzer geht, sobald er einen Fehler erkennt, im Dialogbaum nach oben zurück und zweigt vor dem Fehler ab.
Dieser Artikel wird auch im iX/Developer-Sonderheft zu finden sein, das im Herbst erscheint und sich an Softwarearchitektinnen und Softwarearchitekten richtet. Neben den klassischen Architekturinhalten zu Methoden und Pattern, gibt es Artikel zu Soziotechnischen Systemen, Qualitätssicherung oder zu Architektur und Gesellschaft. Domain Driven Design ist ebenso ein Thema wie Team Topologies und Green Scrum.
Als Autoren konnten wir bekannte Experten gewinnen, die ihr Wissen in vielen spannenden Artikeln – wie dem hier vorliegenden – sowohl für Architektureinsteiger also auch Spezialistinnen weitergeben.