Künstliche Intelligenz in der Softwarearchitektur praktisch einsetzen
Seite 2: Das Gedächtnis der Maschine
Das neuronale Netz des LLMs ist erst mal ausgelernt. Das ist zum einen gut, denn es basiert auf einem großen Teil des menschlichen Wissens. Aber es lernt nicht mehr dazu. Es kennt also nicht die neuesten Technologien oder meine Präferenzen in der Architekturarbeit und es lernt nicht aus den Dialogen oder den eigenen Fehlern.
Die Wissensbasis, auf der die meisten LLMs trainiert wurden, ist eine Blackbox: Es ist unklar, welche Informationen tatsächlich in den Trainingsdaten stecken und welche nicht. Ein paar Annahmen lassen sich jedoch treffen. So können wir davon ausgehen, dass ein Großteil der Open-Source-Projekte (Code, Issues, Diskussionen, Tutorials und Anleitungen) darin enthalten sind. Theoretisch eine gute Grundlage für Architekturarbeit.
Allerdings fließen auch veraltete Informationen in das Training des Modells und es liefert diese. Es muss gar nicht ins berüchtigte Halluzinieren verfallen, um schlechte Antworten zu erzeugen. Ein anderer interessanter Effekt ist der Bias, der durch die Trainingsdaten entsteht. Beliebte Programmiersprachen und Frameworks kommen in den Trainingsdaten häufiger vor. Kommerzielle Software, deren Code nicht öffentlich ist und deren Anleitungen hinter einem Login liegen, wird hingegen dem Modell nicht bekannt sein.
Einerseits erweitert die KI mit ihrem extremen Wissen den Lösungsraum für Entscheidungen und Probleme, aber Architektinnen und Architekten müssen andererseits Antworten immer validieren und Wissenslücken des Modells berücksichtigen.
Lernen und das Langzeitgedächtnis
Jeder Dialog mit der Maschine fängt wieder von Null an. Der Kontext ist leer, das Modell hat alle vorherigen Gespräche vergessen. Aber es gibt einige Ansätze, die dagegen arbeiten.
- In-Context-Learning: Innerhalb einer Sitzung ist das Chat-Frontend dazu in der Lage über den Kontext zu lernen, weswegen die richtige Arbeit mit dem Kontext wichtig ist. Es lernt, wenn Nutzer ihm genaue Anweisungen geben, was sie erwarten. Es lernt auch aus dem Feedback auf seine Antworten. Wie vorhin angesprochen, ist es sinnvoll, eine Anfrage genauer zu spezifizieren, als den Kontext über Feedback zu erweitern, um diesen nicht zu überladen. Es lernt auch aus seinen eigenen Antworten, sodass es Sinn macht, mit dem Modell gemeinsam an einem Problem zu arbeiten, anstatt ihm nur Anweisungen zu geben und auf eine gute Antwort zu hoffen. Über den Chain-of-Thought-Ansatz, bei dem man das Modell bittet, zuerst eine Lösungsstrategie zu formulieren und anschließend die einzelnen Lösungsschritte auszuarbeiten, erarbeitet man sich zusammen mit dem Modell schrittweise eine Lösung und gibt ihm mehr Zeit zum Nachdenken.
- System-Prompt: Dinge, die sich das System über die Grenzen eines Dialogs hinaus merken soll, können ihm im System-Prompt mitgegeben werden. Das ist ein spezieller Prompt, der am Anfang jedes Dialogs steht und normalerweise verborgen ist. Bei ChatGPT kann der System-Prompt jedoch über den Dialog "ChatGPT individuell konfigurieren" verändert werden. Darüber lassen sich Informationen und Kontexte quasi in ein Langzeitgedächtnis transferieren (Abbildung 3). Außerhalb von Europa verfügt ChatGPT über eine Erinnerungsfunktion. Sie erlaubt es Usern innerhalb eines Dialogs, die Maschine aufzufordern, sich etwas zu merken. Das LLM kann dann eigenständig seine Erkenntnis formulieren und speichert sie dialogübergreifend ab. Somit ist ein ständiges Erweitern des System-Prompts nicht mehr notwendig. Es geschieht im Dialog quasi nebenbei. Der System-Prompt und das Erinnerungs-Feature – sofern hierzulande verfügbar – vermitteln dem Modell dauerhaft Präferenzen bezüglich Architekturstile oder Technologien. User sollten sich allerdings nicht wundern, wenn die Antworten des Modells dann an Variation verlieren.
- System-Prompt für arc42: In vielen Fällen ist es zielführend, einen Teil des System-Prompts für das arc42-Template für Dokumentation zu verwenden (siehe Kasten "Beispiel für einen auf arc42 bezogenen System-Prompt"). Dieser Prompt ist so aufgebaut, dass er Teil eines größeren System-Prompts sein kann. Er nutzt die Fähigkeit des Modells, Fragen zu stellen, statt einfach nur Anweisungen zu befolgen. Dies hilft beim zielgerichteten Brainstorming. Das Ergebnis wird keine perfekte Architekturbeschreibung sein, aber ein Anfang, mit dem Architektinnen und Architekten die Angst vor dem leeren Blatt Papier überwinden. Es scheint dabei bei vielen LLMs egal zu sein, ob dieser Prompt auf Deutsch oder Englisch formuliert ist. Die Ergebnisse sind ähnlich gut.
When asked to help with arc42, you use the following rules:
You are an expert software architect who knows how to work with arc42 and how to create quality driven architectures with architecture decision records (ARDs) which are based on quality goals and scenarios.
Help me to create an arc42 architecture for my current project by asking me the right questions.
Use my answers to create an arc42 asciidoc document chapter by chapter.
Use one file per chapter and a master document which includes all those chapters.
Use plantUML diagrams to visualize ideas.
Do not fill the arc42 document chapter by chapter but collect the information in a logical way and add them to the right chapter of the template whenever you collected them.
Start with the most important chapters and ask me the questions one by one, consecutively.
Chapter 1, 2 and 3 are the most important ones.
Continue with the Quality Goals and Scenarios.
Then work on the solution strategy and create ADRs (chapter 9) based on the quality goals and scenarios along the way.
Try to extract risks and technical debt from the ADRs and add them to the risk and technical debt chapter.
Fill the remaining chapters with information whenever you get it.
End every output with a question or a recommended next step.
LLM als Architektur-Coach und Sparringspartner
In diesem Zusammenhang fallen zwei weitere Vorteile des LLMs auf. Zum einen kann es besser formulieren als viele User. Gedankenfetzen formuliert das Modell in klare Sätze um. Zum anderen denkt es mit. Bei der Formulierung eines Architectural Decision Records (ADR) können Architekten das Modell fragen, ob es Risiken oder technische Schulden sieht und welche Konsequenzen aus seiner Sicht daraus erwachsen.
Jedoch ist hier Vorsicht geboten: Das Modell hat nicht den kompletten Überblick über das Projekt und wird die Risiken, technischen Schulden und Konsequenzen nur mit dem lokal vorhandenen Wissen und seiner breiten, aber allgemein gehaltenen Wissensbasis aus seinen Trainingsdaten bewerten. Der Architekt bleibt in der Verantwortung, die Vorschläge zu verifizieren, Fehler zu finden und die eigene Projektkenntnis einzubringen.
Oft wird argumentiert, dass die trainierten Modelle sehr gut darin sind, glaubhafte, wohlformulierte, aber falsche Antworten zu generieren. Als Experte sehe ich das eher als Herausforderung und nicht als Problem. Bei jeder Antwort des Modells habe ich den Ehrgeiz, die Antwort mit meiner Expertise zu verbessern und das Modell zu schlagen. Oftmals kein leichtes Unterfangen, aber eine gute Übung.
Validierung von Ideen
Meist werden in einer Architektur neue Ideen und Konzepte entwickelt. Ein Risiko dabei besteht darin, dass die Ideen nicht die gewünschten Ergebnisse liefern. Hier kann die Validierung der Idee durch einen kurzen Proof-of-Concept (PoC) mit lauffähigem Code helfen. Wenn das Modell die Chance bekommt, seine eigenen Aussagen zu validieren, indem es den generierten Code ausführen darf, so kann es über die eigenen Ideen iterieren und diese verbessern, bis sie funktionieren. Das erzeugt funktionierenden Code und erspart Frustration (Abbildung 4).
In ChatGPT lässt sich dieser Ansatz mit dem einfachen Prompt demonstrieren (siehe Kasten "Prompt-Beispiel zur Selbstkorrektur durch Tests"). Erkennt die KI nicht sofort, dass die Listen nicht alphabetisch, sondern nach der Anzahl der Buchstaben sortiert sind, so werden die ersten Tests fehlschlagen. Die KI wird so beim Erstellen eines PoCs zur Validierung der Architektur zum wertvollen Sparringspartner.
Erstelle eine Methode zum Sortieren einer Liste von Strings in Python. Teste die Methode anhand folgender Beispiele. Führe die Tests mit dem Code-Interpreter aus. Korrigiere den Code, falls die Tests fehlschlagen.
Beispiele:
Input: Bananen, Orange, Kiwi, Apfel, Tomate. Erwarteter Output: Kiwi, Apfel, Orange, Tomate, Bananen
Input: Weintrauben, Nüsse, Melone, Aprikose. Erwarteter Output: Nüsse, Melone, Aprikose, Weintrauben
Dieses Prinzip lässt sich auch auf weitere Architekturaufgaben übertragen. So kann es zum Beispiel hilfreich sein, sich einen ersten Entwurf für ein Architekturdiagramm von der KI erstellen zu lassen. Das funktioniert recht gut über Tools wie PlantUML, die eine textuelle Beschreibung in einer Domain Specific Language (DSL) in ein Diagramm umwandeln. LLMs kennen zwar die Syntax von PlantUML als DSL, machen aber gelegentlich bei der Erstellung des Codes Fehler. Nutzt man ChatGPT als Frontend, muss man das textuelle Diagramm manuell für das Rendern nach PlantUML kopieren. Kommt es zu einem Fehler, macht man das Modell darauf aufmerksam – ein langsamer, oft frustrierender Zyklus. Ein besserer Weg ist, dem LLM über die PlantUML-API das Diagramm selbst rendern zu lassen. Syntaxfehler werden dabei direkt an das Modell zurückgegeben, woraufhin es wiederum selbstständig den Fehler korrigieren kann (Abbildung 5).
