Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.
Dieses Mal zum Thema Analyse großer Software-Systeme mit LLMs mit Michael Stal.
Michael, erst mal vielen Dank, dass du dir die Zeit genommen hast und dass du da bist.
Michael, möchtest du kurz zwei Worte über dich sagen?
Zwei Worte ist zu wenig, aber ich mache es trotzdem.
Ich bin seit 1991 bei Siemens, forsche da an Themen wie Software-Architekturen, verteilte Embedded-Systeme und seit einigen Jahren auch Richtung AI oder Künstlicher Intelligenz, KI.
Ich habe eine Professur in Groningen, da geht es eher um Architekturen und Architektenausbildung.
Mehr gibt es eigentlich nicht zu sagen über mich, außer vielleicht, dass wir die Pattern-Oriented Software Architecture Buchserie geschrieben haben, deren erster Band vor genau 30 Jahren veröffentlicht worden ist.
Das fühlt sich an wie gestern.
Mir fiel auch gerade auf, dass ich deinen Professor-Doktor-Titel unterschlagen habe.
Es geht ja heute um dieses Siemens Architecture Review Agent, heißt das Ding, glaube ich, Sarah.
Und auf der Agenda steht halt irgendwie die Frage, was ist das eigentlich, wie funktioniert das?
Das Ganze basiert auf dem Vortrag bei der OOP, den du ja darüber gehalten hast, bzw. das war der Anlass.
Darauf basiert es halt gar nicht so sehr, sondern das war der Anlass, weswegen ich dachte, es wäre spannend, darüber zu reden.
Da ist für mich insbesondere interessant, was sind eure Praxiserfahrungen?
Gerade in dem AI-Bereich gibt es ja eine Menge an Hypes und nachdem ihr nicht selber ein Produkthersteller seid, sondern es euch überlegt und umgesetzt habt, fand ich es ganz spannend, mit jemandem zu reden, der jetzt nicht jemandem versucht, irgendwas zu verkaufen, führt dann zu der ersten Frage, warum habt ihr das gebaut?
Also eigentlich ist das ja ein Werkzeug zur Architekturanalyse, so habe ich das verstanden.
Das ist halt ein etablierter Markt, da gibt es irgendwie verschiedene Werkzeuge.
Jetzt könnte man ja sagen, ich erwarte, dass ich sowas halt einfach irgendwo kaufen kann oder ich kaufe es vielleicht auch irgendwo und stattdessen habt ihr angefangen, es irgendwie selber zu bauen.
Warum?
Der Grund bei uns ist, wir machen ja relativ häufig Software-Architektur-Reviews für unsere Business-Units, also zum Beispiel Fahrkartensysteme oder Ladestationen für elektrische Autos und solche Geschichten und da sind wir oft gefragt, in relativ kurzer Zeit einen Eindruck von den Software-Architekturen, die die halt haben, zu bekommen und das Problem ist halt, wenn du dich als zwei- oder drei-Mann-Team da hinstellst und versuchst, den Code innerhalb von kurzer Zeit zu verstehen, dass du da klar an die Grenzen kommst, weil da waren meinetwegen 60 Leute für mehrere Jahre dran gesessen und das ist halt chancenlos, da zu versuchen, durch jede Code-Seile zu gehen und das ist halt immer uns schwergefallen oder wir haben es dann doch hingekriegt, weil wir auch Interviews geführt haben mit den Leuten, aber es war die Idee, wieso bauen wir nicht ein Werkzeug auf Basis von KI, das quasi uns zumindest ein wenig Aufgaben abnimmt, also das quasi selber sucht, versteht, was die Architektur denn macht und wo vielleicht noch irgendwelche Defizite drin sind, die man verbessern könnte und das sind ja nicht nur die Architekturen selber, sondern auch, wie ist die Organisation, was sind die Geschäftsziele, kann diese Architektur überhaupt die Geschäftsziele sozusagen unterstützen und derlei Fragen tauchen ja auch auf, weil du gesagt hast, es gibt auch Grenzen, vielleicht nur ein Punkt schon mal vorab, eine Grenze ist, dass viel Wissen ja natürlich nicht in einem Code steckt oder in irgendwelchen Dokumenten, sondern in den Köpfen der Entwickler oder Architekten und da ist natürlich für ein KI-basiertes Review-System eine Grenze erreicht, weil da muss ich quasi Human in the Loop einbauen, ich muss also Menschen dazu nehmen, die mir dann erzählen oder in dem Fall dem System erzählen, warum jetzt welche Architekturentscheidung getroffen wurde zum Beispiel oder wie diese, sag ich mal, schlampiges Design zustande kam und dann bekommst du dann Antworten und kannst sie entsprechend eingeben und entsprechend dann verarbeiten.
Das war so unser Grund und ich meine, vielleicht, Entschuldigung, dass ich unterbreche, noch ein zweiter Punkt, wir hatten einen Kunden oder wir haben einen Kunden, das ist die Siemens Mobility und zwar ist es die Bahninfrastruktur und die haben auch Systeme, die teilweise mehrere Jahrzehnte alt sind und wo die Architekten, Entwickler teilweise nicht mehr in Haus sind und wo die auch Interesse haben, so ein System zu verwenden, um eben ihre eigenen Architekturen wieder zu verstehen und zu untersuchen.
Also was bedeutet, ihr habt einen hohen Bedarf, eben selber Reviews zu machen, das heißt, ein Werkzeug im Allgemeinen ist erstmal sinnvoll.
Das ist, glaube ich, also das ist für mich sofort nachvollziehbar.
Jetzt wäre ja für mich die Frage, warum LLMs?
Da habe ich jetzt irgendwie so das Gefühl mitgenommen, naja, also ich kann damit eben zumindest so Architekturdokumentationen und sowas erschließen und deswegen ist es halt eine LLM.
Ist das so die Richtung oder gibt es da irgendwie was?
Das ist die Richtung, weil das Problem ist, also natürlich, du hast jetzt Standards, Review oder Architektur Assessment Werkzeuge, SonarCube und Understand und wie die auch immer heißen mögen.
Die gehen aber an ihre Grenze, weil sie ja nur Syntax verstehen im Endeffekt.
LLMs ist die Hoffnung, die verstehen ja auch Semantik, können sich auch ein Bild machen, worum es da in dieser Applikation geht, auch von der semantischen Seite aus und deswegen reichen bloße Architektur Assessment Tools nicht aus.
Aber wir können auch in unserem Werkzeug solche Tools integrieren, um deren Ergebnisse halt auch zu bekommen.
Führt ja dazu, dass du im Prinzip sagst, wenn ich halt so etwas machen will wie ein Architektur-Review, ist eben ein LLM-Ansatz sinnvoll?
Das ist ja jetzt nicht eine Aussage, die spezifisch ist nur für Siemens, sondern die geht ja, würde ich sagen, für Software-Architektur im Allgemeinen.
Führt für mich zu der Frage, gibt es da nicht einen Tool-Hersteller, der sowas anbietet?
Habt ihr euch das angeschaut?
Also wir haben es angeschaut und nichts gefunden.
Es gibt natürlich die normalen, sag ich mal, Cloud-Code und Copilot und Cursor und Windsurf und wie die alle heißen.
Das Problem von diesen Werkzeugen ist, die sind zwar recht gut zur Softwareentwicklung, aber sie verstehen nur einen relativ kleinen lokalen Kontext.
Und wenn du jetzt zum Beispiel ein größeres Git-Repository hast, wo teilweise Millionen Zeilen Code drinstecken, daran scheitern diese Tools.
Aber so ein richtiges Architekturanalyse-Tool auf Basis von KI habe ich zumindest nicht gefunden.
Also wäre mir auch neu, dass da eines existiert.
Ich kann mir aber vorstellen, dass wahrscheinlich welche an sowas bauen.
Wäre also nicht überraschend.
Genau und das ist ja auch das, was, glaube ich, dein Talk-Titel bei der OOP auch gesagt hat und auch der Titel dieses Streams sagt, dass es eben um große Software-Systeme geht.
Und vielleicht sozusagen zum Hintergrund.
Du kümmerst dich um das Thema KI ja schon an verschiedenen Stellen und auch schon deutlich länger.
Das heißt, das ist jetzt irgendwie nicht so eine Aussage von – also du hattest das bei deiner Vorstellung nicht so explizit gesagt.
Aber ich kriege halt von dir immer wieder auf Social Media und auf LinkedIn Hinweise, dass du da ganz viele Sachen machst.
Du hast nicht nur einen Software-Architektur-Hintergrund, sondern eben auch, glaube ich, einen Hintergrund in dem AI-Bereich, sodass das, glaube ich, gut belastbare Aussagen sind.
Gut, wollen wir kurz darüber sprechen, wie dieses System aufgebaut ist?
Da gibt es ja einige Sachen, die über Rack angeschlossen sind.
Was ist Rack, was habt ihr da angeschlossen und wie funktioniert der Teil?
Also wir haben im Prinzip zwei Komponenten.
Das eine ist eben Rack.
Das steht ja für Retrieval Augmented Generation.
Das ist im Prinzip ein LLM-Modell, kann ja nur Wissen in sich tragen, das quasi bis zu einem Trainingszeitpunkt eben vorhanden war.
Weiß aber jetzt weder, wie es bei einem Siemens-Projekt lokal ausschaut, noch kennt es neuere Technologien.
Und das Rack ist im Prinzip, ich nehme irgendwelche Dokumente, die werden dann in sogenannte Chunks zerlegt.
Die Chunks werden in sogenannte Embeddings umgewandelt.
Das sind also Vektoren im höherdimensionalen Vektorraum und werden in eine Vektordatenbank eingespeist.
Und wenn ich dann eine Frage habe, dann kann ich eben erst in dieser Vektordatenbank nachschauen mit Similarity Search.
Also welche Inhalte in dieser Datenbank passen am besten zu der Benutzeranfrage?
Und diese Ergebnisse schicke ich zusammen mit einem Kontextinformation zum LLM.
Und die kann also quasi diese Ergebnisse nutzen, um die Anfrage zu beantworten.
Also sie kann dann quasi auf echten faktischen Daten entsprechend arbeiten.
Und das zweite, was wir machen, ist Knowledge Graphen.
Knowledge Graphen sind im Prinzip so Graf-Datenbanken, beziehungsweise unterstützen Graf-Datenbanken.
Und da geht es darum, welche Abhängigkeiten bestehen zwischen Komponenten.
Also das kann jetzt quasi eine Enthält, ruft auf, ist abgeleitet oder vererbt von Klasse X und solche Geschichten sein, sodass man auch die, sage ich mal, semantische Struktur ein bisschen besser erkennt.
Und was wir jetzt festgestellt haben in Versuchen ist, dass man, wenn man nur Rack nimmt, wesentlich schlechter dasteht, als wenn man primär erstmal Knowledge Graphen verwendet und dann zusätzlich Retrieval Augmented Generation Embeddings.
Weil scheinbar eben diese ganze, sage ich mal, Entity Relationships, die da drin sind, aus dieser Knowledge Datenbank besser hervorgehen.
Also da bekommt die KI eine bessere Übersicht.
Was sind jetzt Module, Klassen und so weiter?
Wie hängen die voneinander ab und dergleichen?
Welche Art von Daten füttert ihr darüber in dieses System rein?
Oder welche Art von Informationen?
Wir füttern zum einen natürlich das System rein, also den Code, inklusive Konfigurationsdateien, Readmes und was immer.
Und vielleicht, wenn man Glück hat, sind auch noch ADRs drin, also Architecture Decision Records, Bildfiles und dergleichen.
Das ist quasi alles, was so auf der Software Ebene stattfindet.
Wir füttern allerdings auch ein Meeting Notes oder Folien, Präsentationen, die von dem, sage ich mal, Architekturdreiber oder dem Business Unit erstellt worden sind.
Auch irgendwelche Minutes, Protokolle, die da eben sagen, irgendwelche Entscheidungen zum Beispiel enthalten.
Und alles zusammen führt eben dazu, dass man die Architektur nicht nur hinsichtlich des Codes, sondern auch hinsichtlich, zum Beispiel erfüllt diese Architektur die Ziele, die wir uns gegeben haben.
Welche Entscheidungen wurden wann getroffen und warum?
Also da bekomme ich wesentlich mehr Informationen in das System rein, als ich normal hätte, wenn ich nur ein Repository verwenden würde.
Und ich glaube, an der Stelle ist ja nochmal klar, dass es eben etwas ist, wo LLMs mit dem textbasierten Ansatz vielleicht tatsächlich hilfreich sind.
Ich meine, eine Grenze gibt es da natürlich.
Da haben wir vorher drüber gesprochen.
LLMs wissen natürlich nicht, was in den Köpfen von Projektbeteiligten steckt.
Sprich, dieses System, das quasi auf Basis von AI analysiert, muss irgendwie einen jungen in den Loop-Ansatz fahren.
Sodass quasi, wenn jetzt irgendwelche Fragen seitens des LLMs entstehen, Menschen beantworten können, warum wurde diese Architekturentscheidung getroffen.
Oder wieso wurden zum Beispiel andere Optionen abgelehnt, die vielleicht am Anfang besser erscheinen würden.
Also da kriegt man dann mehr Informationen raus, wie Zeitdruck, Technical Depth und dergleichen.
Okay, interessant.
Also meine Erfahrung mit LLMs und wenn ich es richtig verstehe, auch sozusagen die Art und Weise, wie LLMs aufgebaut werden, ist ja so, dass die halt mit Nachdruck sagen, so und so ist übrigens die Welt.
Und wir kennen ja das Thema mit den Halluzinationen, wo man dann irgendwie das System mit Nachdruck sagt, hey, die Welt ist übrigens folgendermaßen.
Und dann stellt man halt irgendwie gemeinsam fest, nee, das stimmt halt irgendwie nicht, sondern das ist halt irgendwie einfach erfunden.
Was du jetzt gerade sagst, ist, es gibt eben sozusagen Lücken in den Informationen, das ist nachvollziehbar.
Und dass dann das LLM Fragen stellt, das ist, wie soll ich sagen, mich überrascht das ein bisschen, weil das für mich nahezu ein Widerspruch ist zu dem, wie LLMs typischerweise funktionieren.
Kannst du den Widerspruch auflösen?
Also, wie gesagt, bei uns war speziell die Tatsache, dass nicht alle Informationen in den Köpfen sind, warum zum Beispiel eine Architekturentscheidung A gefallen ist.
Das kann zum Beispiel jetzt der Mensch, der daran beteiligt war, beantworten.
Und das steht meistens oder oft nicht drin in der Code-Basis, weil die Leute meistens keine ADRs pflegen, was ich immer kritisiere, weil es eigentlich sinnvoll ist.
Und deswegen ist es notwendig.
Und dieses Human-in-the-Loop passt ja auch beim Training von LLMs, weil da werden auch die Nutzer gefragt, ist das eine Antwort, mit der du zufrieden wärst?
Kennst vielleicht selber von Chat-GPT.
Auf einmal erzeugt es dir zwei Lösungen und fragt, welche findest du besser?
Das ist ja auch Human-in-the-Loop mit Reinforcement-Learning, das Modell verbessern.
Aber wie habe ich mir das jetzt vorzustellen?
Das heißt also, ich fange jetzt irgendwie an und sage dem LLM, ich möchte halt etwas… Ist es so, dass das System dann proaktiv tatsächlich nachfragt?
Und in welchen Situationen passiert das?
Ja, es wird auch angewiesen mit Prompt, dass es proaktiv nachfragt, wenn es auf irgendwelche Lücken stößt, wo es mehr Informationen braucht.
Und zum Beispiel eine typische Anfrage, also zum Beispiel gerade bei den Zügen.
Der Zug fährt auf unserer Infrastruktur und hat gebremst.
Warum?
Das ist so eine typische Anfrage, die unsere Mobility-Leute zum Beispiel haben bezüglich der Architektur.
Also warum ist genau das passiert?
Und da wird es dann eben noch komplexer, weil man dann auch dynamische Informationen einlesen muss.
Das haben wir noch nicht drin, aber daran arbeiten unsere Mobility-Kollegen momentan.
Auch nur, dass man sich mal vorstellt, wie das läuft, weil selbst die Architekten oder die Entwickler das nicht beantworten können.
Und ein LLM kann sich anschauen, was waren die Zustände, was war die Basis von dem Ganzen und kann es auch rückwärts verfolgen.
Kann ich als Mensch schon?
Ein LLM ist wesentlich schneller, sowas zu analysieren.
Musst du aber, wie du vorher richtig gesagt hast, dann auch verifizieren, dass da nicht irgendeine Halluzination eine Rolle spielt, sondern es muss immer, wir fordern von dem LLM oder von dem Agenten immer, er muss uns faktische Referenzen geben, die uns genau sozusagen helfen, diese Beweiskette nachzuvollziehen.
Das heißt also, ich frage jetzt das System, warum ist der Zug in dieser spezifischen Situation, warum hat er gehalten?
Und dann stellt das System mir potenziell Rückfragen.
Also kannst du eine konkrete Rückfrage nennen?
Zum Beispiel, eine Rückfrage wäre zum Beispiel, in welchen Situationen ein Zug überhaupt bremst.
Das ist nicht immer, da steckt eine Implementierung drin, aber das ist nicht immer ganz klar, weil teilweise das eben auch schlecht dokumentiert ist.
Leider und wir deswegen aus diesen Informationen vielleicht dann diese Antwort nicht kriegen, die wir uns erwarten.
Und sie wird auch vielleicht fragen, was waren die Situationen, in denen der Zug gebremst hat, was ging da speziell vor?
Wer hat gebremst?
Hat der Zug automatisch gebremst?
War es der Lokführer und dergleichen?
Was dann bedeutet, dass die Benutzung eher so ein Dialogding ist?
Also das hört sich ja an, wie dass man eben in einen Dialog eintritt und da Fragen und Rückfragen und Feststellungen hat, irgendwie trifft und dann irgendwie darüber weiterkommt.
Zum Beispiel, ist aber normal bei LLMs, wenn du zum Beispiel sagst, erzeuge mir einen LLM-Chatbot, dann kriegst du auch Fragen zurück.
Was willst du konkret?
Also das ist mir zu vage.
Und genau diese Dinge, die zu vage sind, da soll das LLM auch aktiv Rückfragen stellen, weil man bevor es dann irgendwelche Findings hat, weil es versucht ja immer irgendwas zu produzieren, egal ob es jetzt stimmt oder nicht.
Und das hilft dabei, das auch zu verifizieren.
Okay, super.
Dann habe ich verstanden, also das ist, glaube ich, dieses Thema rund um Rack und sozusagen Informationen in dieses System reinbekommen.
Dann ist es so, dass das Multiagentensystem ist, wenn ich es richtig verstehe.
Was bedeutet das und was sind da die Agenten, die da arbeiten?
Da sind zum Beispiel Agenten drin, die sind auf Architektur spezialisiert.
Andere Agenten sind zum Beispiel mehr darauf spezialisiert, gewisse Programmiersprachen zu kennen und die entsprechend zu verarbeiten, weil wir haben es ja meistens auch mit Polyglotten-Systemen zu tun.
Da ist ja nicht nur Python drin oder C++, sondern etliche andere Sprachen, TypeScript, JavaScript und der gleichen.
Und deswegen braucht man spezialisierte Agenten, die sich eben konkret um diese Thematik kümmern.
Wir haben auch einen Kritikagenten.
Also für jeden Agenten kannst du, wenn du willst, einen Kritikagenten nehmen, der immer versucht zu beweisen, dass der eigentliche Agent sich geirrt hat und dass da irgendwas nicht in Ordnung ist, sodass quasi das System darüber reflektieren muss und das dann entsprechend hoffentlich terminierend zu einer guten Lösung führt.
Okay, also ich weiß, ihr hättet mir jetzt aus den OP-Folien, die du mir freundlicherweise gegeben hast, aufgeschrieben.
Sowas wie ein Main-User-Input-Agent habt ihr.
Ja, du brauchst ja einen Agenten, der sozusagen die Interaktion zwischen den Menschen, die daran arbeiten und dem System verantwortet.
Und der ist quasi da, kriegt Aufgaben, weiß dann, an welche Agenten er mit welchen Aufgaben geht, kann vielleicht auch Aufgaben in Sub-Teile zerlegen und jeden Agenten, der eben auf diesen Teil spezialisiert ist, damit beauftragen, das zu untersuchen.
Genau, dann haben wir sowas wie, genau, Planning.
Wobei, das hast du, glaube ich, gerade schon erläutert.
Wir haben auch einen Agenten, der quasi, sobald sich irgendwas an der Code-Basis ändert, ist ja nicht so, dass das GitHub-Repository zum Beispiel oder das Git-Repository unverändert bleibt, sondern es könnte sich was ändern.
Und um eben überhaupt einen initialen Zustand in das System zu bringen, das wir gebaut haben, das kann auch mal einen Tag dauern oder sogar mehrere Tage oder mehrere Stunden.
Und wenn ich das jetzt jedes Mal von Null aus wiederholen würde, wenn da jetzt ein neuer Code hinzukommt, dann hätte ich ein Problem.
Also deswegen gibt es einen Agenten, der merkt, da hat es eine Änderung gegeben, baut sich dann quasi eine Impact-Analyse und stellt fest, welche Teile konkret davon betroffen waren und was er eben neu einlesen muss als Delta.
Genau, dann hast du schon genannt die sprachspezifischen Agenten über die verschiedenen Sprachen.
Bei Architektur hatte ich mir aufgeschrieben, Patterns, Modulabhängigkeiten, ADR-Compliance, also Compliance to these architectural decision records und Solid-Prinzipien.
Aber im Prinzip, die Agenten selber haben versucht, möglichst sauber architektonisch aufzusetzen und deswegen haben wir denen auch diese Prinzipien sozusagen mitgegeben, also Single Responsibility Principle, also ein Agent macht eine Sache, die er gut kann und versucht nicht quasi auf fünf Sachen gleichzeitig zu arbeiten.
Genau, und dann geht die Analyse, hattest du auch schon genannt.
Ich glaube, wir haben es dann auch im Wesentlichen sozusagen.
Darf ich fragen, ich weiß nicht, ob du darüber sprechen darfst, wie viel Aufwand da reingeflossen ist, das Ding zu bauen?
Also erst mal nicht so viel, weil wir haben jetzt Stand OP, da hat man Prototypen und da haben mitgearbeitet die Kollegen von Mobility, wir und ein, sage ich mal, Masterstudent, sozusagen Master Thesis auch war, sowas zu bauen, das war unser Glück, da sind wir gut zusammengekommen und also den ersten Stand gibt es, der kann aber wesentlich, ist Multiagenten, nun nicht Multiagenten fähig, kann also große Git-Repositories einlesen und kann auch zum Beispiel, wenn man dann Fragen stellt, zum Beispiel, wo ist meinetwegen diese Funktionalität konkret implementiert, kann er das auch herausfinden und wie vorher schon erwähnt, wird dann gedacht, wir nehmen jetzt Rack her und was sich herausgestellt hat, wir nehmen lieber Knowledge Graphen, weil damit kann die KI wesentlich besser arbeiten und LLMs oder Rack ist dann quasi ein Zusatz an der Information, aber sie braucht auch die Struktur des Systems, was ja eben im Knowledge Graphen hinterlegt ist.
Okay, super.
Was mache ich jetzt typischerweise damit, also in welchen Situationen nutze ich dieses System oder in welchen Situationen habt ihr es genutzt?
Also zum einen, wie schon gesagt, Architektur Refuse, also gerade wenn man eben relativ wenig Zeit hat, es gibt ja zum Beispiel die Utiligence, wir wollen eine Firma kaufen und wollen aber erst mal sehen, was deren Systeme taugen, also Software Architekturen zum Beispiel und das ist in relativ kurzer Zeit zu machen, also zum Beispiel eine Woche und das heißt, in dieser Woche kannst du nicht Millionen Zeilen Code entsprechend durchackern, sondern du kannst da zumindest eine initiale Perspektive auf das System quasi mit diesem Multiagentensystem erarbeiten.
Also beziehungsweise ist es ja noch kein Multiagentensystem, sondern auch in diesem einfachen System, das wir bisher haben, diesen Prototypen, kann man das relativ einfach dann bewerkstelligen.
Habt ihr es in dem Kontext schon genutzt, wenn ich fragen darf?
Ja, haben wir schon.
Also wie schon gesagt, konkret für Architektur Refuse, von denen haben wir relativ viele, also im Jahr schätze ich mal 20, 30 Architektur Refuse.
In der Abteilung sind 200 Leute und nur ein Teil davon beschäftigt sich mit Architektur Refuse und für die ist es halt nützlich.
Bloß ich warne halt immer, trotz aller Maßnahmen, schaut immer nach, ob die Aussagen der KI auch richtig sind.
Genau, also die Abteilung, von der du sprichst, ist, ich weiß nicht, Software and System Processes.
Also ich bin konkret in der SSP.
Wir machen Automation-Themen, also für Mobility, für die Industrieautomatisierung oder für Energieautomatisierung und Gebäude- automatisierung.
Und in diesem Bereich sind wir halt bevorzugt tätig, machen aber auch was für Healthy Nears oder Siemens Energy.
Also das kommt auch vor.
Und auch zum Beispiel letzten Fall, wo wir das benutzt haben, da ging es um eine Ladesäulen-Infrastruktur und die dazugehörige Software.
Und die hatten eine neue Firma aufgekauft, eine kleinere Company mit wenigen Entwicklern.
Und unsere Aufgabe war da einfach mal durchzublicken, wie weit passt das mit dem Siemens-System zusammen?
Also wie leicht kann ich das integrieren?
Und da hat uns das halt schon geholfen, zu sehen, wo gibt es vielleicht Probleme in der Integration, wo läuft es vielleicht ganz easy.
Und ich bekomme dann Aussagen, die ich teilweise zum Beispiel selber übersehen hätte, muss ich ehrlich zugeben.
Also ich mache das ja relativ häufig, aber auch mir passiert, dass ich mal irgendwelche Dinge übersehe, die nicht so offensichtlich sind, weil ich eben nicht den kompletten Überblick über ein System haben kann.
Das heißt also, ich gehe jetzt irgendwie hin und sage jetzt zu diesen Menschen, die diese Software gebaut haben, so nehme ich jetzt jeden Fall erst mal an, ich brauche halt von euch Zugriff auf ADRs, Git-Repositories und was auch immer da rumfliegt.
Und dann installiere ich das erst, also gebe ich erst mal dem, diesem SARA-System da sozusagen Zugriff.
Genau.
Oder mache eine lokale Kopie und lasse es dann lokal laufen.
Also das passiert auf jeden Fall.
Und ja, also das Ganze nennt sich auch Siemens Architecture Review Assistant.
Assistant heißt eben, er assistiert mir.
Also ich nehme ihn jetzt nicht als hauptverantwortlich, sondern ich bin da noch vorsichtig, weil wir müssen erst mal noch mehr Erfahrungen sammeln, wo es dann vielleicht Halluzinationen gibt, die vielleicht sozusagen wir übersehen haben oder wo das System reingefallen ist.
Genau, das wäre jetzt meine nächste Frage.
Ich wollte jetzt irgendwie bewusst naiv die Frage stellen und dann sage ich dem System nicht, wo sind Probleme mit der Integration, mit der Siemens-Infrastruktur.
Und das ist offensichtlich nicht die Art und Weise, wie ich mit dem System umgehe.
Aber was mache ich jetzt mit dem System?
Also das hat er gesagt, dass das System dir tatsächlich geholfen hat und bestimmte Sachen herausgefunden hat oder dich darauf hingewiesen hat, die du sonst nicht gesehen hättest.
Wie stelle ich mir das jetzt vor?
Also wie gehe ich jetzt daran, diese Software von diesem Unternehmen beispielsweise anzugucken?
Also ich erkläre dem LLM oder dem System, wie unsere Siemens-Systeme aussehen.
Also speziell, was die Integrationsschnittstellen betrifft.
Also alles, was von außen kommt oder nach außen geliefert wird.
Und lasse das System auch dieses, sage ich mal, von der kleineren Firma die Infrastruktur untersuchen.
Und frage konkret, sag mal, ob es irgendwelche Probleme geben würde, wenn zum Beispiel hier dieses Teil Funktionalität in das Siemens-System integriert würde.
Also gibt es da Schwierigkeiten oder lässt sich das Ganze recht einfach bewerkstelligen?
Und wie immer gibt es natürlich Schwierigkeiten, weil natürlich die beiden oder die mehreren Systeme sind ja unabhängig voneinander entstanden.
Also wird das meistens nicht so einfach sein.
Also ich bekomme dann zumindest einen Eindruck.
Heißt aber nicht, dass ich nicht die Leute von der Firma unterinterviewe und mir auch dann sozusagen einen Einblick gewähren lasse und auch denen mal sage, bitte macht mir so End-to-End-Use-Cases und zeigt mir die im System.
Das ist aber jetzt ja tatsächlich eine sehr High-Level-Frage.
Also damit sagst du ja im Prinzip, wo überall können jetzt in diesem spezifischen Fall Integrationsprobleme auftauchen und das ist ja schon, wie gesagt, eben sehr High-Level.
Das heißt, ich erwarte jetzt, dass da eigentlich etwas rauskommt, was so ähnlich ist wie das Architektur-Review-Dokument, was du sonst irgendwie sozusagen manuell erzeugen würdest.
Also ich erwarte hier ein Problem, ich erwarte hier ein Problem aus folgenden Gründen, was weiß ich, Skaldierbarkeit.
Ich meine, das ist nicht so einfach.
Wir übergeben natürlich auch die Schnittstellen.
Also wir übergeben die Schnittstellen des Siemens-Systems und versuchen dann rauszufinden, erst mal als Mensch, aber auch mithilfe der KI, wo da eventuell Probleme wirklich entstehen können.
Es ist dann natürlich sehr konkret, was wir dann fragen.
Also ich frage da nicht allgemein, gibt es da Integrationsprobleme, sondern auch gezielt nach gewissen Punkten, Daten zum Beispiel Integration und dergleichen.
Aber das wäre jetzt für mich genau die Frage, also auf welcher Ebene benutzt du das LLM?
Sagst du dem jetzt irgendwie, wo erwartest du Integrationsprobleme, also irgendwie High-Level?
Oder ist es so, dass du halt sagst, okay, ich sehe hier jetzt, dass in dieser Schnittstelle, die wirkt halt, weiß ich nicht, das ist eine Messaging-Schnittstelle, wir benutzen ja, wir bauen es under und rest.
Da ist halt offensichtlich ein Problem.
Wie siehst du das, also welche Ebene ist das halt?
Also gut, ich kann am Anfang, stelle ich jetzt erst mal eine allgemeine Frage.
Dann bekomme ich Ergebnisse raus und dann kann ich sehr konkret fragen, auf gewisse Aspekte eben konkret das System ansprechen, dass mir das einfach erklärt, welche Komponenten innerhalb des Systems sind jetzt von diesem Thema zum Beispiel betroffen und müssten bei einer Integration entsprechend berücksichtigt werden.
Also das geht quasi von eher allgemein, weil du das System ja selber noch nicht kennst, zu immer mehr speziell auf gewisse Themen und Aspekte.
Okay, das heißt also beide Ebenen.
Du hattest es vorhin schon angesprochen, es gibt halt Halluzinationen in diesem System.
Wie sehr ist das dabei störend?
Also es wäre ja jetzt theoretisch denkbar, dass er irgendwie zurückkommt, nicht?
Diese Integration ist halt problemlos möglich oder es gibt halt super krasse Probleme aus irgendwelchen Gründen und dann bohrt man halt irgendwie nach und stellt, also nicht, guckt sich halt die reale Realität an und stellt fest, das ist totaler Quatsch.
Also mir passiert das halt öfter mit LLMs.
Wie ist da deine Erfahrung?
Also wir versuchen es ein bisschen auszugleichen durch diesen Kritikagenten, der dann das Ergebnis des anderen Agenten eben versucht, auf Fehler entsprechend zu lokalisieren und zum Zweiten eben durch REC und GraphREC.
Also wir versuchen wirklich faktisch, dass das System immer begründet, aufgrund von Code innerhalb des Repositories, warum es meint, dass hier an der Stelle das problemlos wäre.
Also wie würden die Integrationen zum Beispiel aussehen?
Zeig mir das mal.
Und wo siehst du da eine problemlose Integration und warum?
Und wie ist dein Gefühl?
Also sind diese Halluzinationen ein Problem im realen Leben oder ist das halt eher so, dass du sagst, naja, ab und zu passiert einmal was, aber eigentlich ist das kein ernsthaftes Thema, so wie es jetzt bei euch funktioniert?
Das ist ein Problem.
Wir haben ja auch bei Siemens die Voraussetzung oder die Vorgabe, dass man auf keinen Fall irgendwelche KI generierten Systeme nutzt, ohne dass sie vorher überprüft werden und auch deren Ergebnisse überprüft werden.
Also drum sehe ich das eher als Assistenten.
Du kannst natürlich nicht alle Halluzinationen abschalten, weil irgendwo geht da halt was sozusagen verloren und dann wird eine Halluzination entsprechend aufgebaut.
Da kann man nur versuchen, das immer auch manuell noch zu verifizieren, wie weit das stimmt.
Zu 90, 95 Prozent ist das ja alles richtig.
Also die Halluzinationen in den LLMs gehen so von 5 bis 20 Prozent, je nach Modell.
Also wenn du ein Frontiermodell hast, dann kommst du eben auf 5 Prozent.
Aber diese 5 Prozent kannst du eben durch diese Maßnahmen in der Architektur wie im Rack und untergleichen abfedern, weil dann muss das System immer beweisen, warum es auf diesen Schluss kommt mit harten Fakten.
Das heißt aber trotzdem, sagen wir mal in 2 bis 3 Prozent wirst du immer noch Halluzinationen bekommen und da hilft wirklich nur die manuelle Inspektion.
Ist das wirklich so?
Schaue ich mir mal an.
Wird wahrscheinlich auch jemand den Outdoor-Motor untersucht und dann seine Software verwendet, auch mal nachgucken, was ist da wirklich am echten Motor?
Wo ist das Problem eigentlich?
Also es ist kein naiver Ansatz.
Wie ist denn, also ich will bei dem Punkt sozusagen noch mal bleiben, dieser sagen wir mal subjektiven Nützlichkeit.
Würdest du dir die Welt vor diesem System zurückwünschen?
Oder ist das etwas, was jetzt ein integraler Bestandteil ist?
Oder wie sehr beeinflusst das deine Arbeit bei so einem Review?
Das wäre eigentlich die Frage.
Ist das jetzt ein zentrales Tool, mit dem du das Review machst?
Oder ist das halt ein Tool von vielen, das dir halt irgendwie an einigen Stellen punktuell hilft, aber es ist eben nicht das zentrale Tool?
Also wir bauen eben, wie schon gesagt, eine Integration mit anderen Architekturtools schon mit ein.
Würde ich mir die Welt von früher zurückwünschen?
Ja und nein.
Also im Prinzip sind wir auch früher mit Architektur-Reviews zurechtgekommen.
Das hat dann immer alles länger gedauert.
Also du gewinnst halt an Produktivität und viele Kunden haben einen relativ kleinen oder geringen Zeitrahmen.
Das heißt, für diese Fälle nützt es ja wirklich.
Wenn ich aber jetzt einen sechs-Wochen-Auftrag habe, ein Review zu machen, dann benutze ich zwar die KI, um zu helfen.
Aber da habe ich wesentlich mehr Zeit, um mit Leuten zu sprechen oder mit Kunden von den Systemen, die die bauen, um zu sehen, was sind jetzt so typische Problemstellungen.
Und tauchen die dann auch auf, wenn ich dann die KI danach frage?
Also sind das Dinge, die die KI erkennen würde oder nicht?
Und damit kannst du auch das System laufend verbessern.
Du kannst zum Beispiel jetzt LLMs speziell feintunen für gewisse Themen.
Meinetwegen für eine Fachdomäne.
Also dass du quasi einen Agenten hast, der die Domäne kennt und dir dann auch sagt, wie die Domäne aufgebaut ist, ob sie DDD-Prinzipien folgt und, und, und.
Das ist halt alles sehr hilfreich an der Stelle.
Aber die meisten haben eben keine DDD-Ergebnis-Dokumentation in ihrem Gitter-Repository.
Aber man erkennt es halt aufgrund der Patterns, die verwendet werden, dass da DDD verwendet worden ist zum Beispiel.
Gut, was also, wenn ich das richtig verstehe, sagst du insbesondere, wenn es darum geht, schnell ein Ergebnis zu haben, dann ist das halt ein Werkzeug, das ganz ehrlich ist.
Genau.
Oder wenn ich halt wirklich tiefer bohren will.
Weil wenn du jetzt ein Review hast mit Menschen, dann kannst du nicht so tief bohren, wie du gern möchtest.
Und es kann auch sein, dass dir Leute vom Auftraggeber gezielt Informationen vorenthalten.
Und dadurch kann ich zumindest auf diese Punkte stoßen und dann eben nachfragen.
Das konnte ich vorher eben nicht.
Da müsste ich mich auf die Leute verlassen.
Genau.
Das ist, glaube ich, noch ein wichtiger Aspekt, den ich, glaube ich, auch noch mal kurz hervorheben wollen würde.
Ein Review bei einer Firma, die man halt potenziell kaufen will, ist halt ein anderes Setting, als das, was ich halt häufig habe, wo man irgendwie sagt, hey, hilf uns doch bitte.
Weil nicht in der Umgebung, wo man eine Firma kaufen möchte, will die natürlich besonders gut dastehen.
Und das Optimum ist keine Probleme.
Während, wenn man jemanden um Hilfe bittet, dann ist das Optimum halt irgendwie Hilfe, was ja impliziert, dass es halt Herausforderungen gibt.
Und das sind andere Sachen.
Und bei den Herausforderungen, wenn es um eine Hilfestellung geht, wird man auch Unterstützung, glaube ich, auf die auch hingewiesen.
Und da ist, glaube ich, noch ein Punkt.
Wir haben zum Beispiel auch ein Review mit einem Ticket.
Das war so ein Ticketsystem, wo du halt quasi für Nahverkehr Tickets kaufen konntest.
Und die hatten halt Probleme mit der Effizienz und wollten auch wissen, ob ihre Architektur gut genug ist oder Fehler enthält.
Da war das natürlich auch sehr nützlich, da mal kurz sozusagen so ein Architektur-Review zu machen und dann ein bisschen Eindrücke zu bekommen.
Also das Tool selber gibt dir aber auch zurück so eine Art Wortanalyse.
Das heißt, es versucht wirklich herauszufinden, was sind Stärken, Schwächen, Gelegenheiten und Risiken des Systems.
Es versucht auch, das zu bewerten, wie kritisch das ist.
Das heißt also, hier hast du auch noch mehr Information, als nur in dem Interface A ist die Methode X nicht funktionstüchtig oder hat Fehler.
Sondern bekommst du noch mehr Information, wie kritisch das eigentlich ist.
Wo siehst du die Hauptnachteile dieses Tools?
Also die Hauptnachteile, wie wir schon gesagt haben, sind erstens die LLMs, die ja auch halluzinieren können.
Ich muss auch die Agenten, die ich habe, die müssen natürlich auch die Programmiersprachen verstehen, die in diesem Repository drin sind.
Das heißt, du musst die speziell trainieren.
Ein reines Training von Agenten, die nur über den Code schauen, funktioniert aber nicht.
Was wir machen, ist, dass wir eben zumindest den abstrakten Zündungsbaum mit Semantik angefüllt quasi zur Verfügung stellen.
Also wir lesen jetzt nicht naiv.
Eine LLM liest nicht naiv sozusagen den Code, sondern es bekommt eben einen Parser an die Seite gestellt, der auch wirklich die Struktur des Programms und so weiter vorgibt.
Also wo man auch dann mehr sieht, als nur LLM hier mit 2000 Zeilen Code und sagen wir mal was über welche Herausforderungen es noch gibt in diesem System.
Jetzt ist ja tatsächlich, wir hatten es vorhin kurz gesagt, es geht halt um die Analyse großer Software-Systeme.
Das ist ja auch offensichtlich die Herausforderung.
Kannst du nochmal, und wir wissen ja alle, dass LLMs dieses begrenzte Kontextfenster haben, also eine bestimmte Menge an Informationsbedauern aufnehmen können.
Kannst du nochmal konkret sagen, was dazu führt, dass diese Systeme tatsächlich mit großen Software-Systemen umgehen können und auch die analysieren können?
Es gibt mehrere Ansätze, die wir dazu haben.
Erstens haben wir spezialisierte Agenten.
Die haben jeweils ihr eigenes Context-Memory.
Also wenn ich einen einzigen Agenten hätte, der alles macht, dann würde er natürlich überschwemmt werden.
Wir machen auch sozusagen Context-Window, Sliding-Context-Windows zum Beispiel, wo wir einfach sagen, ab einem gewissen Punkt vergisst es, was du vorher da gewusst hast.
Wir machen Summarization.
Das heißt, wenn ich jetzt ein größeres System habe, dann muss ich nicht jetzt alle Details erstmal haben, sondern ich kann zum Beispiel angeben, so paar Sätze, was macht jetzt diese Komponente.
Das ist so eine Summary.
Und wenn ich dann tiefer reingehen will, dann kann das System tiefer reingehen.
Es muss es aber nicht unbedingt gleich am Anfang machen.
Das heißt, ich versuche eben, die Zahl der Informationsdichte geringer zu halten, um eben nicht an diese Grenzen zu stoßen.
Weil trotz 100.000 oder Millionen Context-Memory ist ja auch erfahrungsgemäß so, die kannst du nicht verwenden.
Das heißt, selbst wenn ein Modell 100.000 Tokens Context-Memory hat und du gehst an die Grenze, dann wird es relativ viel Halluzination zeigen.
Also du musst rechnen mit der Hälfte zum Beispiel oder ein Teil davon.
Also deswegen hast du das Problem, gerade bei großen Code-Repositories natürlich schon.
Und das Nächste, was du machen kannst, ist Multi-Prompting.
Das ist ein Agent, macht nicht einen riesen Prompt, um alles abzufragen, sondern zerlegt es in mehrere kleinere Prompts.
Und jeder Prompt oder jede Session hat ja wiederum ihr eigenes Context-Memory zur Verfügung.
Das heißt, du hast dann diese Möglichkeit und du kannst auch mehrere LLMs benutzen.
Also spezialisierte LLMs, je nachdem, wo du bist.
Meinetwegen ein GWEN-Coder mit relativ wenig Billionen Parametern für Code-Analyse und ein meinetwegen Cloud Opus oder Sunet 4.6, für komplexere Zusammenhänge.
Es gibt eine Frage von Raj Kumar auf YouTube, die ist englisch, ich werde sie gleich nochmal übersetzen.
Und zwar ist die Frage auf Englisch, does the review happen against the architecture diagrams etc. or against the code base.
Also die Frage ist, ist das Review anhand von Architektur-Diagrammen oder basiert das auf dem Code selber?
Ich glaube, du hast es schon gesagt, aber wir können es ja glaube ich nochmal kurz diskutieren.
Wir benutzen ja nicht nur LLMs, sondern auch VLMs, die Diagramme und dergleichen wissen und die auch Feintuning erfahren, damit sie halt meinetwegen mit UML-Diagrammen besser umgehen können.
Also das schaut sich das System auch an.
Haben wir aber jetzt noch nicht so wirklich genutzt.
Also bisher hat man eben mehr mit den Code-Basen zu tun.
Klar, mit Architektur- Spezifikationen.
Aber wir haben die Möglichkeit von VLMs vorgesehen, aber nun nicht wirklich integriert.
Das heißt, das funktioniert im Augenblick nicht.
Aber das ist natürlich der Wunsch, dass in Zukunft halt VLMs sich auch die Diagramme anzeigen lassen können und dann vielleicht noch mehr Informationen kriegen, ob die Architektur wirklich implementiert ist in dem System oder ob das eine Fantasie-Architektur ist, die aber nie jemand mehr wirklich implementiert hat.
Genau, was also eigentlich bedeutet, es ist sogar eher die Code-Basis.
Du hast ja auch gerade eben gesagt, dass DMB reduziert wird und es da Abstract Syntax-Trees, die daraus generiert werden und eher die Lücke ist eher auf der Ebene der Diagramme.
Es ist momentan eine Einschränkung, weil du kannst natürlich nicht alles bauen.
Du startest ja auch klein, also inkrementell, schaust erst mal an, ob deine Arbeitshypothesen wirklich stimmen und baust das System dann Schritt für Schritt aus.
Und wie schon gesagt, wir haben noch keine VLMs drin, die Diagramme analysieren können.
Aber die Idee wäre, die entsprechenden LLMs zu nehmen oder VLMs und sie halt auch noch fein zu tunen mit den Diagrammtypen, die normalerweise so auftauchen.
Noch eine Frage aus einer persönlichen Perspektive und das ist auch etwas, worüber wir ja auch per E-Mail vorher schon mal kommuniziert hatten.
Ich hatte mir die Folien angesehen von der OP, die du mir ja, wie gesagt, netterweise zur Verfügung gestellt hast.
Für mich ist jetzt die Frage und das steht ja auch im Mittelpunkt, die Frage nach der Praxisrelevanz, sozusagen.
Wie ist das bei uns?
Das hast du, glaube ich, sehr schön beantwortet und vielen Dank erst mal dafür.
Was mir bei den Folien aufgefallen ist, ist, du hattest im Hintergrund einmal so ein Informationshappen, wo drin stand, ich habe hier oder hier ist eine SQL-Injection und in meiner Erinnerung war das so, dass das glaube ich tatsächlich Java-Code war, wo eben ein String zusammengebaut wird für eine SQL-Anfrage und dann eben eine Variable einfach konkateniert wird in den String hinein, was eben bedeutet, dass da irgendwas reinkommen kann und dann haben wir genau dieses SQL-Injection-Problem.
Das heißt, ich mache eben nicht Anfangsstriche oben, Semikolon ist es, glaube ich, oder Bindestrich, Bindestrich, um das Kommando zu wenden und dann sage ich, hier ist das nächste Kommando, das nächste Kommando, das hat eine Datenmarkttabelle oder gibt mir eine Information aus oder so.
Das sind ja diese klassischen SQL-Injection-Sachen, wo ich halt durch einen String dann eben ein SQL-Statement ändere.
Und die Frage, die sich da bei mir halt irgendwie ergeben hat, ist, diese Erkenntnis, ich habe an dieser Stelle eine SQL-Injection in Java, ich unterstelle, dass ich die halt irgendwie durch SonarQube einfach rausfinden würde und ich habe da an der Stelle sozusagen nicht den Sinn verstanden von einem, von dem Ansatz, den ihr da fahrt.
Also sprich, das kann ich halt auch ohne LLM rausfinden.
Kannst du das auflösen, diesen Widerspruch oder diesen mindestens scheinbaren Widerspruch?
Für solche Sachen, wie schon gesagt, wir können auch normale Architekturtools verwenden, wie SonarQube und deren Ergebnisse integrieren.
Also zum Beispiel, wo sind Abhängigkeitszyklen oder wo ist zum Beispiel so eine Fan-out-Problematik drin oder Coupling und Cohesion-Geschichte?
Das heißt also, da können wir auch diese Architekturtools integrieren und deren Ergebnisse nutzen.
Das heißt, die LLMs sind jetzt nicht für alles verantwortlich, sondern wo du bereits praxisnahe Tools hast, die man gut verwenden kann, dann kannst du die auch sozusagen in diese Landschaft integrieren.
Und das ist der Vorteil halt, dass wir nicht nur – also ich will nicht, dass die LLM schaut mal über das System drüber und dann bekomme ich dann einen SWOT-Report und ich bin glücklich und gebe das weiter, sondern das ist für mich ein Assistent.
Also ich nehme das erstmal als Hypothesen hin, was er mir liefert, schaue da aber nochmal kritisch drüber.
Ich glaube, im Augenblick würde ich mich nicht auf ein System alleine verlassen in der Art, weil du eben mangelst Erfahrungen.
Da müssen wir erst noch länger damit arbeiten.
Weißt du halt nicht, wo dann vielleicht Falschaussagen entstehen und so weiter.
Also da wäre ich vorsichtig und darum eben immer, schau auch nochmal selber drüber.
Kannst du das nachvollziehen im Code?
Ist da was dran oder ist es vielleicht völlig daneben, was zum Beispiel jetzt das System liefert?
Und vielleicht noch zu der Frage SQL-Injection.
Also wir haben auch Optionalagenten, die für gewisse Quality-Attributes verantwortlich sind.
Zum Beispiel ein Performance-Agent, der sich das anschaut oder ein Security-Agent.
Und wir haben auch in diese ganze Software natürlich auch Maßnahmen eingebaut, weil du kannst dir auch dieses SARA-System mit Prompt-Injection und so weiter angreifen.
Also das ist natürlich dann auch im System selber drin und das System selber untersucht auch noch andere Systeme auf solche Geschichten, sei es mit Hilfe von SonarQube oder Understand oder was auch immer da existiert.
Also wir versuchen, alle Informationen, die man bisher schon kriegen konnte von anderen Werkzeugen, dann Lint da untergleichen, eben auch mit so einzubauen, um eben die Halluzination zu reduzieren.
Weil wenn man in SonarQube sagt, da ist ein Dependency-Cycle drin, dann macht es das ja nicht zum Spaß, um mich zu ärgern.
Und es ist in Wirklichkeit nichts vorhanden, sondern da kann ich mich darauf verlassen, das stimmt.
Und das ist eine weitere Ebene, um eben auf faktenbasierte Analysen durchzuführen.
Hört sich für mich so ein bisschen an, als wäre das eher ein Input, den man halt dem LLM geben würde.
Also dieses konkrete Fundament in SQL-Injections, was halt vielleicht von SonarQube tatsächlich kommt.
Genau.
Und vielleicht noch der andere Punkt, ich glaube, an dem Punkt sind wir jetzt ein paar Mal vorbeigekommen und ich wollte das halt auch nochmal unterstreichen.
Ich finde es halt sehr schön, dass du sagst, das ist halt ein Assistent.
Und mir fehlt halt bei diesen LLM-Sachen andersrum.
Ich glaube, die Nutzung von LLMs kann gutes Exercise sein in kritischen Nachfragen.
Genau.
Und das ist etwas, wo man sich bewusst sein muss, dass LLMs eigentlich dazu gebaut sind, um irgendwie zu beeindrucken und halt zu sagen, so ist übrigens die Wahrheit und so ist es halt.
Und wir kennen das alle, wie schnell man das System dazu bekommt, irgendwie dann zu sagen, ist es halt irgendwie nicht, weil das ist halt auch in der Textgenerator eingebaut, dass es einen halt irgendwie nicht pleasen soll.
Ich weiß gar nicht, wie man das auf Deutsch sagt, also wohlgefällig sein soll.
Und das führt irgendwie dazu, dass halt dieses kritische Hinterfragen eigentlich eine Kernskill ist.
Und ich habe dieses Exercise gehört, was, glaube ich, eine Lehrerin tatsächlich an der Schule gemacht hat oder so, wo irgendwie die Aufgabe war, ich löse diese Aufgabe mit einem LLM und finde mindestens fünf Sachen, die halt einfach falsch sind.
Das ist tatsächlich eine Aufgabe, die ich halt sehr spannend fand und, glaube ich, an der Stelle hilfreich ist, um die kritische Distanz hinzubekommen.
Was ich vielleicht noch sagen soll, also meiner Meinung nach oder meine Erfahrungen aus den LLMs, zwar gut im Code analysieren, weil du findest natürlich massenhaft Code in GitHub und sonstigen Repositories, aber noch relativ mittelmäßig in Architekturbewertungen.
Das heißt, auch da musst du aufpassen.
Dafür brauchst du eben so Tools wie SonarCube und dergleichen, um das quasi auch auszugleichen.
Und du musst auch den LLMs gewisse Trainingsdaten an die Hand legen, um das so ein bisschen zu leiten.
Also wenn ein LLM eine Architektur baut, dann sind es meistens immer dieselben Patterns wie Observer oder Strategy und Factory.
Die Architektur-Patterns kennst du fast gar nicht, außer vielleicht Leas.
Also du landest im Endeffekt, wenn du nicht aufpasst, immer bei einer Leas-Architektur, wo ganz bestimmte Patterns dann auftauchen.
Und das muss ja nicht immer die richtige Geschichte sein.
Da könnte man ja auch mal über hexagonale Architecture nachdenken zum Beispiel.
Oder ich habe ja auch einen Architekturansatz jetzt entwickelt mit Capability-Centric-Architecture.
Das ist auch eine quasi Architekturstile.
Und sowas kennt natürlich eine LLM von Haus aus nicht.
Das muss ich ihm speziell beibringen.
Und wie schon gesagt, wenn ich ein LLM naiv auf ein System loslasse, ohne was zu tun, dann wird es mir nicht unbedingt die Qualitätslücken in der Architektur aufzeigen.
Also dafür musst du extra Aufwand betreiben, damit es funktioniert.
Und wenn ich es einfach in eine LLM-Reihe schmeiße, dann werde ich auch nicht unbedingt das bekommen, was ich mir erhoffe.
Genau.
Ich habe noch so ein Thema, also sozusagen analog zu dieser SQL-Injection.
Und das kommt von einer von deinen Folien von der OOP.
Da geht es halt um eine Spot-Analyse.
Da ist ein Beispiel.
Da steht halt als Beispiel, Finding ist in der Microsoft-Architektur eingeführt worden.
Und da steht dann als Stärken Skalierbarkeit, Teamautonomie und Tech-Diversität.
Nachteile sind erhöhte Komplexität, verteiltes Tracing und Konsistenzprobleme.
Was dann irgendwie zu Opportunities und Threats führt.
Opportunities sind Cloud-Native, A-B-Testing, unabhängiges Deployment.
Threats, so steht hier Monitoring Gaps, Netzwerk-Latenz, Debugging schwierig.
Und also ich habe ja nun buchstäblich Bücher über das Thema geschrieben.
Und das ist halt irgendwie unterkomplex.
Also man kann darüber sehr viel sagen.
Ich glaube, das ist halt auch irgendwie profan, darüber weiter zu diskutieren.
Und was denn da weiter stand, war als Empfehlung Service Mesh einzuführen.
Service Mesh ist, wer es nicht kennt, ist halt so ein Infrastruktur-Ding, womit ich gerade so im verteilten System ein paar Sachen einfach auf die Reihe bekomme, indem ich in den Netzwerk Kommunikation einschalte.
Also ich kann zum Beispiel verschlüsseln, ich kann über Metriken ableiten, weil ich ja mitbekomme, wie diese Systeme miteinander reden.
Also Request pro Sekunde oder sowas kriege ich halt irgendwie raus.
Also wir nehmen das vielleicht deswegen das Thema wichtig bei uns zumindest, weil wir halt relativ mit Kubernetes machen.
Und Kubernetes und Docker sind ja so Plattformen, um Microservices zu integrieren.
Und da gibt es ja auch ein Service Mesh, das nennt sich Istio.
Und sowas verwenden wir halt dann auch konkret zum Beispiel, um in einem Kubernetes-System nicht ein Standardprotokoll, also TCP IP zu verwenden, sondern wenn man ein zusätzliches schnelle Netzwerkkarte mit einem anderen Protokoll hat, TSN oder untergleichen, dann kann man auch diese Systeme so bauen, dass sie halt immer, wenn es geht, über das schnelle Netzwerk kommunizieren und nicht über das normale Internet oder Ethernet-Netzwerk.
Ja, also meine Fragen sind eigentlich, oder wie gesagt, ich war halt durch die Präsentation durchgegangen, eben in Bezug auf diese Praxisgeschichte.
Und deswegen ist es jetzt irgendwie so, dass ich mir sozusagen nicht so viele Punkte raushole.
Das war halt der zweite und auch tatsächlich der letzte Punkt, der mir halt aufgefallen ist.
Ich habe dazu also die eine Bemerkung und da würde ich gerne wissen, wie deine Antwort dazu sozusagen ist, ist eben genau diese Aussage, das erscheint mir unter komplex.
Denn ich würde behaupten, Microservices haben verschiedene Vorteile.
Ich kann zum Beispiel, was jetzt hier nicht drin steht, ist, ich kann die Sachen unabhängig voneinander deployen, was halt zum Beispiel mit Bezug auf Testing einen Vorteil hat.
Ich muss eben nur ein Teil isoliert testen.
Ja, genau.
Und das hat irgendwie Vorteile, weil wir wissen, durch schnelleres Deployment haben wir Produktivitätsvorteile, schnelleres Feedback, nicht nur von Kunden, sondern auch technisches Feedback.
Das heißt also, es könnte jetzt sein, dass ich eine Situation habe, wo ich sage, ich möchte öfter deployen, weil das irgendwie gut ist.
Und deswegen mache ich jetzt irgendwie Microservices.
Wenn das hier so ein Fall wäre, dann würde das in der SWOT-Analyse noch nicht mal auftauchen.
Und deswegen wirkt das auf mich unterkomplex.
Wie ist dein Gefühl dazu?
Also ist das jetzt dem speziellen Beispiel geschuldet oder ist es eben tatsächlich so?
Da würde ich gerne nochmal deinen Eindruck haben.
Ich würde sagen, da hast du vollkommen recht.
Das sind halt so Ergebnisse, die man am Anfang rausbekommt, wo man sagt, okay, wie du richtig sagst, das ist unterkomplex.
Da müsste man eigentlich viel mehr nachhaken, auch Datenpersistenz untergleichen in Punkten von Microservices oder eben, Bau- oder Evolvierbarkeit nach Cloud-Ansätzen untergleichen.
Und es können im Projekt Gründe bestehen, ganz andere Gründe als die genannten, um eben eine Microservice-Architektur einzuführen.
Und wenn du an solche Punkte kommst, dann ist es eben wiederum so, dass dieser Architektur-Agent neu trainiert werden muss oder zusätzlich trainiert werden muss oder feingetunt werden muss.
Du wirst aber wahrscheinlich zum Anfang, wenn du so ein System gebaut hast, immer wieder solche Ergebnisse kriegen.
Du meintest vorher, die sind relativ schwach in der Architektur.
Und das ist ja wieder so ein konkreter Fall, wo man das sieht.
Und deswegen heißt es da aufpassen und danach schärfen.
Und ich vermute, so etwas wird dann auch mehr öfters vorkommen, gerade am Anfang.
Und da musst du entsprechend das System darauf einstellen.
Und da gibt es sicher noch hunderttausend andere Probleme, die man da hat.
Okay.
Was also bedeutet, dass wir jetzt wieder bei diesem Thema sind mit kritisch nachfragen, Dialog, solche Geschichten.
Und das wäre jetzt, wenn ich jetzt das Review machen würde mit diesem Werkzeug und ich hätte das Ergebnis, dann wäre es irgendwie fein, dass ich sagen würde, ein komisches Ergebnis.
Gucke ich mir nochmal genauer an.
Ich würde bei allen LLM anfragen, auf die Ergebnisse gucken und einfach mal davon ausgehen, dass da Fehler drin sind.
Und eben dann nachprüfen und auch mir von einem LLM praktisch zeigen lassen, wie es darauf kommt.
Also konkret am Code oder an dem Architektur, wie es zu diesem Ergebnis kommt.
Das kann ich dann nachvollziehen, warum eben das berichtet wird.
Wobei man allerdings sagen muss, Cloud und Graphic hat man ja mal untersucht.
Also das Entrophic Team, das sagt dann die irgendwelche Schlussfolgerungen.
Aber in Wirklichkeit ist ganz anders vorgegangen.
Also auch das Problem hast du.
Weil das sind eben Textgeneratoren und eben nicht Systeme, die wirklich denken.
In dem Kontext, wenn ich sozusagen auf dem Punkt nochmal kurz stehen bleiben darf.
Also die Empfehlung ist ja jetzt, dieses Service Mesh einzuführen.
Und ich muss gestehen, ich fand das in gewisser Weise, sagen wir mal, bemerkenswert.
Weil ich würde argumentieren, ein Service Mesh ist eben ein durchaus komplexes Ding.
Und das steht halt als eine Schwäche von dem jetzigen Ansatz, dass der Ansatz eine erhöhte Komplexität hat, der Microservices-Ansatz.
Was halt für mich zu so einer Situation führt, wo ich das Gefühl habe, Komplexität wird bekämpft durch noch mehr Komplexität und mehr Fragezeichen entstehen.
Aber das wäre dann auch wieder etwas, wo das sozusagen meine Fähre wäre.
Was da untersucht worden ist, ist wirklich so ein Kubernetes-System.
Und da war es tatsächlich der Fall, dass man mit Mesh halt entsprechend weiterkommt oder besser vorankommt, als mit, sage ich mal, einfach Microservices zu verwenden, mit Standardprotokollen.
Also in dem Fall hat es sogar gestimmt.
Aber das kann ja auch passieren beim System, wo es eben nicht stimmt.
Also da musst du immer aufpassen, ob das System die richtigen Schlussfolgerungen gemacht hat und eben auch für den konkreten Projektkontext das stimmt.
Und vielleicht irgendwelche Fakten eben überhaupt nicht berücksichtigt worden sind.
Dann gibt es eine Frage von Teppich626 auf YouTube.
Und zwar fragt er oder sie, Michael hatte vorhin gesagt, dass er auch Modelle, Models wechselt, je nach Frage.
Ich habe gerade angefangen Anything LLM zu nutzen, um eine Stelle für meine Rack Vector Datenbank zu haben, auf die ich dann mit unterschiedlichen Modellen zugreifen kann.
Welches Interface nutzt ihr da konkret?
Habt ihr unterschiedliche ausprobiert?
Also wir haben selber ein Interface implementiert.
Das nennt sich LLM Client.
Der LLM Client definiert quasi als absagte Basisklasse, wie der konkrete Zugriff auf Modelle ausschaut.
Also du kriegst dann quasi ein Objekt von dem Typ und kannst mit diesem Objekt auf dein Modell zugreifen.
Und wenn jetzt zum Beispiel das System entscheidet, dafür brauche ich aber einen Python Agenten, der darauf entsprechend programmiert ist und eine spezielle LLM.
Dann kann ich die dynamisch sozusagen zur Laufzeit dann auch ändern.
Also da kann ich mir dann quasi per Dependency Injection eine andere LLM Client Schnittstelle geben lassen, die sich eben auf ein ganz anderes Modell bezieht.
Und wir haben also quasi mit anderen Worten eine Abstraktionsschicht, die von den konkreten Modellen abstrahiert und die ich dann entsprechend aus dem Grund auch austauschen kann.
Und dann gibt es noch eine Frage von Kevin Rhee bei Twitch.
Also ich hatte es schon echt oft, dass Claude bei Analysen komplexer Systeme falsche Ergebnisse geliefert hat.
Das ist halt bei unbekannten Code Basen ein Problem.
Da kann man sich aus meiner Sicht nur bedingt darauf verlassen.
Also wie gesagt, es depends.
Weil wenn du wirklich jetzt hergehst und sagst, Claude schaut sich nicht den Code an, sondern verwendet einen Parser, verwendet dann eben Ergebnisse von anderen Architektur-Introspektions-Werkzeugen und sozusagen hat einen spezialisierten Agenten, der da drauf schaut, der vielleicht auch noch Feintuned ist.
Dann kann man das Problem zumindest abmildern.
Aber wie schon gesagt, man kann sich auf LLMs wirklich nur bedingt verlassen.
Man kann Sicherheitsstufen einbauen, die das quasi möglichst reduzieren, was an Halluzinationen zustande kommt.
Aber man muss eben als Mensch auch noch mal nachgucken.
Also da bleibt nichts übrig, als dann wirklich, das ist ein Assistent, der gibt mir irgendwelche Informationen.
Kann auch sein, dass die ab und zu falsch sind.
Also menschliche Informationen können ja auch falsch sein.
Also deswegen kann man es ja noch mal nachprüfen und so einfach ein Ergebnis von einem Claude zu nehmen oder vom GPT5, das wird nicht funktionieren, weil das quasi nicht spezialisiert ist.
Das ist ein allgemeines LLM, das quasi alles macht, speziell gut coden kann, aber auch wieder bei Architekturanalysen eben Schwächen hat, wie eben alle LLMs, weil die nie auf richtig vielen Architekturen trainiert worden sind, mangels eben vorhandenen Trainingsdaten.
Letzte Frage, kann man auf euch oder dich zukommen, wenn da noch weiteres Interesse besteht oder weitere Themen sind?
Ja, selbstverständlich.
Einfach auf mich zukommen.
Also vielleicht lieber über meine Privatmail michael.stal at gmail.com
Also ich bin jederzeit ansprechbar oder über LinkedIn.
Sich mit mir vernetzen ist auch kein Thema und dann kann man sich direkt austauschen.
Achso, der marianzays87 hat noch bei YouTube geschrieben, deswegen heißt es ja Context is King.
Das ist fast eine gute Endbemerkung.
Das ist ein gutes Schlusswort, ja.
Dann würde ich sagen, vielen Dank nochmal für die Zeit und die Einblicke.
Das ist ja durchaus nicht selbstverständlich und insbesondere eben wertvoll, weil im Gegensatz zu Tourherstellern seid ihr eben keiner, sondern Tournutzer.
Deswegen vielen Dank und ich wünsche dir und auch allen anderen ein schönes Osterfest.
Bis dahin.
Vielen Dank dir auch.
Merci.
Bis dann.
Achso, weil ich es gerade noch sehe, der marwan hat geschrieben, das ist ja glaube ich auch ein Kollege von dir.
Vielen Dank an euch beide.
Folgende Frage.
Gibt es einen Rat, wie ich bei meinen aktuellen Architekturanalysen vorgehen soll?
Mir ist klar, dass ich prinzipiell AI verwenden kann, aber ich kann kein Analysesystem bauen.
Gibt es einen niedrigschwelligen Einstieg?
Gibt es Tools zu der Vorgehensweise, die du empfiehlst?
Da kann ich mit mir persönlich reden.
Klar gibt es Tools, aber eben nicht viele.
Und wie schon gesagt, die meisten Tools haben eben gerade mit Architekturfragen Probleme.
Ich werde ihm antworten, er kann ja auf die Mobility-Kollegen auch zugehen, weil wir haben das gemeinsam gebaut.
Das heißt, ich kann zum Beispiel nicht entscheiden, auch innerhalb von Siemens, welcher Code rausgehen darf und welcher nicht.
Aber ich werde ihm mal den Tipp geben, dass er einfach mal den Adam Schmidt, das ist der Mobility-Verantwortliche, einfach mal anfragt, ob er auf unsere gemeinsamen Code-Agenten Ansatz zugreifen kann.
Was wäre der Tipp für Nicht-Siemens-Mitarbeiter, außer einen Siemens-Mitarbeiter zu werden?
Das wäre dann schon Last Resort sozusagen.
Da kann ich da eigentlich keinen richtigen Tipp geben.
Also ich würde schauen, entweder du musst es selber bauen, aber das kannst du als kleine Firma vergessen.
Bei Siemens ist das natürlich möglich, weil wir mehrere Stakeholder und auch finanziell das Problem nicht haben.
Bei einer kleineren Firma würde ich mich wirklich schwer tun.
Also du kannst mit meinen Patterns, die ich ja teilweise auch verwendet habe, die aber nicht die gesamte Tiefe zeigen natürlich, kannst du schon sozusagen starten.
Du kannst ein kleineres System bauen, aber da wirst du wahrscheinlich auch nicht die Detailinformationen rausbekommen, die du normal rauskriegen würdest.
Bei unserem Ansatz ist halt schon einige Zeit reingeflossen.
Aber ich veröffentliche auch immer so die Architekturen und dergleichen in LinkedIn.
Das heißt, ich gebe den Leuten durchaus die Chance, dass ich dann quasi dort auch bedienen können und auch mal selber so einen Ansatz wählen können.
Aber ich kann jetzt nicht jedem sagen, ich frage mal den Adam Schmidt, ob er den Code da auch rausgibt.
Das wird nicht funktionieren.
Und ich weiß eben nicht, ob es noch weitere Werkzeuge gibt, die auf das aufbauen.
Ich würde mal davon ausgehen, ich weiß nicht, ob das dann Pilot oder Entropic oder OpenAI sind, die sowas machen werden.
Aber ich gehe davon aus, dass es vielleicht kleinere Firmen gibt, die auf LMM-Basis sowas auch bauen.
Genau.
Und dann aber tatsächlich als Schlusswort von Afrination ist das, glaube ich, bei YouTube.
Vielen lieben Dank für den super informativen Talk.
Das ist, glaube ich, ein tolles Schlusswort.
Bis dahin und schöne Ostern und schönes Wochenende.