Ein Beispiel: vor kurzem hatte ich mich mit dem Thema Impressum auseinandergesetzt und diese Impressum-Vorlage von eRecht24 gefunden. Interessehalber hab ich das Impressum dann in ChatGPT geworfen, mit der Bitte das 1:1 kopierte Impressum zu bewerten. Das Ergebnis war im Grunde wie zu erwarten:
Die Rückmeldung stört mich. Nicht, weil die Rückmeldung grundsätzlich falsch ist. Ich bin auch nicht in der Lage die Rechtssicherheit eines online angebotenen Impressum zu bewerten. Mich stört, was GPT hier für ein Korinthenkacker ist. Mich stört, dass die KI alles korrigieren muss.
Ich will an dieser Stelle semi-philosophisch über das Thema sprechen. Gehen wir davon aus, dass die Trainingsdaten, die in die KI geflossen sind, wie vermutet wird, großteils aus dem freien Internet stammen. Und alles was die KI nicht in ersten Selbstlern-Prozessen aufgenommen hat über reinforced learning in das finale Modell eingeflossen ist. Dann hat die KI von uns gelernt so zu sein.
Wie ein Kind, das sich von Erwachsenen abschaut wie es sich verhält, hat die KI von uns gelernt, dass die beste Interaktion mit anderen ist, diese zu korrigieren. Die Male, die ich es in der Vergangenheit geschafft habe die KI auf ein “Das ist okay so. Ich hab keine weitere Anmerkungen.” zu treiben geht gegen Null.
Ich finde das interessanter auf der gesellschaftlichen Ebene als auf der technischen. Die technische Ebene verstehe ich. Die gesellschaftliche fasziniert mich. Wie viele Probleme ließen sich lösen, wenn wir einfach dazu übergehen es nicht immer zwanghaft besser zu wissen. Einfach mal einzugestehen, dass wir nicht die klügsten im Raum sind.
Wir versuchen der KI immer mehr von uns aufzudrängen. Sie besser zu gestalten und menschlicher zu machen. Was auch immer das letztere heißt. Vielleicht sollten wir versuchen die KI so zu gestalten, dass sie manche Dinge besser macht als wir. Zum Beispiel Fehler eingestehen und es nicht zwanghaft besser zu wissen. Vielleicht beeinflusst die KI uns dann im Gegenzug auch positiv und wir lernen voneinander.
Aber hey. Was weiß ich schon.
]]>Stattdessen rückt die “Harness”, also die Umgebung in der das dahinterliegende LLM arbeitet, immer mehr in den Vordergrund. Diese Harness kann dabei verschiedene Formen annehmen. Am bekanntesten sind die weit verbreiteten Chat-Oberflächen, mit denen ChatGPT bekannt geworden ist. Es existieren darüber hinaus aber andere Möglichkeiten eine KI anzusteuern, wie beispielsweise in der Seitenansicht eines Webbrowsers, über Low-Code Tools wie z.B. n8n oder sogar als Standalone Assistent auf dem Rechner, der die Maus übernimmt.
Das alles sind verschiedene Entwicklungsstufen der Interaktion mit einer KI. Gleichzeitig sind das inzwischen ebenso wichtige Instrumente im Kampf um die Marktmacht, wie die Modelle selbst.
Wer sich beispielsweise Claude anschaut stellt fest, dass die Oberfläche inzwischen nicht mehr bloß ein reiner Chat ist, sondern, dass inzwischen die Möglichkeit besteht Routine-Aufgaben zu planen, externe Dienste, wie einen Mailservice, zu verbinden oder direkt innerhalb des Chats interaktiv anklickbare Grafiken zu generieren.
Die Anbieter der großen KI-Modelle haben längst erkannt, dass ein “bloßes intelligentes Modell” nicht mehr ausreicht. Die User verlangen immer öfter reibungslos laufende Oberflächen mit Funktionen, die über einfache Chatantworten hinaus gehen.
User reifen mit den Modellen mit. Die, die erkennen welche Möglichkeiten in den KI-Oberflächen stecken, bekommen neue Ideen alte Probleme innovativer zu beheben.
Bessere Oberflächen sind Wettbewerbsvorteile. Gleichzeitig ermöglichen sie Usern einen einfacheren Einstieg und einen besseren Umgang mit den Werkzeugen. Die neusten Modelle hingegen sind kaum noch ausschlaggebendes Argument für die breite Basis ein bestimmtes Modell zu bevorzugen. Trust me.
]]>Dabei sind Berichte nur ein Beispiel für bestehende Prozesse, die nicht sauber definiert sind. In Gesprächen rund um das Thema KI treten oft ähnliche Themen auf.
Die technische Implementierung ist dabei theoretisch nicht schwierig umzusetzen. Berichte sind Produkte aus einer klaren Vorlage, festgelegten Infos aus Normen und Gesetzen und projektbezogenen Informationen. Falls man alle Daten hat, kann die KI einen Bericht erstellen. Oft scheitert es daran die Datenpipeline so sauber aufzubauen, dass projektbezogene Infos in den Kontext der KI gegeben werden. Das sind technische Probleme und zwar solche in der Art, dass umfangreichere Umstrukturierungen in Unternehmen erforderlich werden um diese Art von Datenpipeline in große Unternehmen hochzuskalieren.
Doch noch öfter scheitert es schon an sauberen Vorlagen. Man kann der KI natürlich ebenfalls sagen “erstell den Bericht analog zu diesen dreien”. Aber sauberer ist es klare Vorlagen zu geben wie ein Bericht auf jeden Fall aussehen sollte, statt eine Token-Rate-Maschine raten zu lassen was denn nun wirklich einen guten Bericht ausmacht. Gleiches gilt für neue Mitarbeiter. Für das Onboarding jedes neuen Kollegen sind saubere Vorlagen sinnvoller als aus jeder Berichtserstellung ein reverse engineering Projekt zu machen.
Qualitätsmanagement ist ein Thema das gefühlt niemanden begeistert und dass auch niemandem im ersten Moment gewinnbringend erscheint. Aber mit Blick auf wechselnde Arbeitswelten und den Druck, dass junge neue Kolleginnen sich schnell in Projekte einarbeiten sollen, schwinden die Alternativen.
]]>Wer schon einmal mit einer KI gearbeitet hat versteht das grundsätzliche Vorgehen. Man packt eine PDF in den Chat und lässt die KI die PDF verarbeiten oder interpretieren. Das funktioniert grundsätzlich gut. Doch im Bauwesen geht es leider nicht bloß um PDFs. Es geht leider nicht mal um eine bestimmte Art von Dateiinhalt innerhalb der PDF.
Wer schon einmal mit einem Bauwerk in Berührung gekommen ist, wird das festgestellt haben. Bauen ist weit mehr als bloß Text. Es sind Baupläne, Tabellen, Grafiken und Berichte. All diese Informationen leben in unterschiedlichen Dateiformaten. Textdokumente werden in DOC Formaten gespeichert, Tabellen in XLS. Zeichnungen haben überhaupt keine Einheitlichkeit sondern richten sich nach dem Hersteller: RVT, DWG, DXF, NWD, DGN. Und das sind nur die nativen Formate der Hersteller. On top kommen noch dutzende Formate die zum Austausch zwischen Gewerken und Unternehmen genutzt werden. Auch hier gibt es mehr als genug dreiteilige Kürzel. Zum Beispiel IFC, XML und SHP.
Und dann gibt es noch das Austausch Format schlechthin: PDF. Kann alles sein, kann jeder lesen. Perfekt. Oder auch nicht. PDF ist nicht der König der Formate. PDF ist der König der Unsicherheit.
Nur anhand der Dateiendung lässt sich nicht erkennen was eine PDF beinhaltet. Ein Textdokument? Eine Tabelle? Eine Grafik? Falls es eine Grafik ist, dann eine vektorisierte? Oder ein Raster Foto aus Pixeln? Wenn es ein Pixel Foto ist, was stellt es dann dar? Das Bild eines Gebäudes, aufgenommen von einem Smartphone? Den Scan eines Papierplans? Den Scan einer Tabelle? Sind es mehrere Fotos?
Die Unsicherheit die PDF mit sich bringt ist grundsätzlich schon problematisch. Die Tatsache, dass ein Bauwerk nie über ein einzelnes Dokument beschrieben werden kann macht es schlimmer.
Eine Wand kann in einem Grundriss dargestellt sein. Oder aber in einem Schnitt. Pläne haben unterschiedliche Entwicklungsphasen und Maßstäbe, die jeweils unterschiedliche Informationsgehalte beinhalten. Der Wandaufbau lässt sich manchen Planunterlagen entnehmen, anderen hingegen nicht. Wände sind aber nicht nur in Plänen vorhanden. Wandaufbauten und Wärmeübergangskoeffizienten lassen sich in Tabellen finden. Aussagen zur Bauzeit aus Terminplänen. Statische Informationen aus den Berechnungsergebnissen von Programmen. Darstellungen in Renderings.
Verschiedene Dateien beschreiben verschiedene Aspekte dessen was wir als Menschen als “die Wand” verstehen. Aber verschiedene Disziplinen betrachten eine Wand mit verschiedenen Schwerpunkten. Daraus ergeben sich unterschiedliche Anforderungen und unterschiedliche Facetten derselben Wand, die die Wand schnell zu einem Multidimensionalen Objekt werden lassen.
Nur können diese Beziehungen in einer PDF nicht mehr dargestellt werden. Wenn Grundriss und Tabelle vorliegen, dann ist eine Verknüpfung der Informationen für Projektbeteiligte logisch. Eine inhärente Logik darüber, dass die Dokumente in Bezug stehen, gibt es aber nicht.
Das Bauwesen lebt von verschiedenen Dokument- und Dateitypen. Bauwerke sind komplexe Objekten mit tausenden von Informationen. Die alle auf ein einziges Format runterzubrechen hilft niemandem.
Innerhalb des Bauwesens gibt es Bestrebungen diese Formate anzupassen. BIM Modelle bilden semantische Informationen ab und verknüpfen Daten miteinander. Daten, die dann von einer KI im entsprechenden Kontext und ohne Interpretationsspielraum verarbeitet werden können.
PDFs können alles sein. Das macht sie so attraktiv. Und gleichzeitig so problematisch. Sie sind unglaublich vielseitig, stellen Informationen immer, auf jedem Gerät, gleich dar. Sie sind wahnsinnig dumm, wahnsinnig simpel. Die Attraktivität der PDF liegt in der Stabilität. Aber besser geeignet für eine KI sind sie deswegen nicht.
Eine KI ist in der Lage eine PDF zu analysieren. Aber das stellt einen Versuch dar unsaubere Daten zwanghaft in eine Form zu pressen, statt die Daten im ersten Schritt sauber aufzubereiten. PDFs in einer KI bekämpfen Symptome, nicht die Probleme. Verpasste Digitalisierung. Übertragung von Prozessen in eine neue Welt in die sie nie gehört haben.
KI ist sicherlich kein Allheilmittel. Aber KI deckt Versäumnisse auf, die es jetzt anzugehen gilt. Das Bauwesen hat jetzt die Chance im Rahmen von KI Einführungen an diesen Versäumnissen zu arbeiten. Es braucht klarere Strukturen, besser aufbereitete Modelle und Prozesse die uns ermöglichen den vollen Nutzen aus der KI zu ziehen.
Das PDF-Format wurde 1992 entwickelt. Wir sind 24 Jahren gut damit gefahren. Wir werden auch noch weitere Jahre damit fahren. Aber der Mensch baut seit tausenden Jahren. PDF war ein erster Schritt in Richtung einer digitalen Baubranche. Aber PDF ist zu jung um der finale Schritt zu sein. Es gilt jetzt die nächsten Schritte zu tun.
]]>Immer öfter berühren die Gespräche Punkte, die ich persönlich früher in den Bereich von Softwareentwicklern verortet hätte: Welche Schnittstellen zwischen den Fachanwendungen gibt es? Wie können wir die Datenstrukturen sauber aufbauen? Wie die Projektstrukturen?
Wenn es nicht gerade um technische Umsetzbarkeiten geht ist das andere riesige Thema Transformation: Wie können wir alte Prozesse in neue Bahnen bringen? Wie Mitarbeiterinnen abholen, schulen und Kompetenzen aufbauen? Wie sehen unsere Prozesse in 2 Jahren aus?
Die Digitalisierung ist für viele Büros (und wohl für keine Behörde), abgeschlossen: Mobiles Arbeiten und Zugriff von unterwegs gehört zum Tagesgeschäft. Aber die digitale Transformation hat für die meisten gerade erst begonnen. Dokumente in PDFs einzuscannen war nie gemeint, als man vom digitalen Bauantrag sprach. Es braucht Vereinfachung, wirkliches Umdenken und das Nutzen technischer Möglichkeiten.
Die Baubranche kann von Programmierern lernen. Versionierung und Branching in GitHub kann als Vorlage dienen wie Variantenuntersuchungen ablaufen. Die Nutzung von Variablen und Libraries der Softwareentwicklung zeigen, wie Planung und Entwicklung aus Vorlagekomponenten zusammengesetzt werden kann, ohne das Rad für jedes Projekt neu zu erfinden.
Digitale Transformation ist nicht deswegen so schwierig weil keiner PCs benutzen will. Sie stellt Probleme dar, weil die Prozesse nicht passen und Menschen sich umstellen müssen.
]]>Seit der Veröffentlichung von Fable mehren sich online die Berichte, dass das neue Modell von Anthropic in der Lage ist, Websites und Programme aus einem einzigen Prompt zu generieren. Grund genug für mich die Fähigkeiten nach der Aufhebung des Embargos der US-Regierung zu testen. Das ernüchternde Ergebnis: Wie bei allen vorherigen Modellen von OpenAI und Anthropic ist mir bislang der berühmte Oneshot nicht gelungen. Zufriedenstellende Ergebnisse werden immer erst nach vielzähligen Versionen und mehrfachem Iterieren nutzbar.
Dabei sind die Anfangsergebnisse nicht schlecht, sondern einfach nicht das, was ich mir vorgestellt habe. Fable mag in der Lage sein ein perfekt beschriebenes Programm zu erstellen, aber ich bin nicht in der Lage, ein perfektes Programm zu beschreiben. Claude Fable kann oneshotten. Ich kann es nicht.
Im konkreten Beispiel wollte ich ein Tool zur Erstellung eines Grabenprofils (ein Querschnitt durch einen Graben) erstellen. Ich gehe intuitiv von einer visuellen Seite an das Problem heran. Als gelernter Bauzeichner habe ich diese Arten von Zeichnungen immer geometrisch mit einem CAD-Programm umgesetzt.
Dass ich auf eine bestimmte Art über diese Probleme nachdenke, habe ich überhaupt erst in der Diskussion mit Fable gemerkt. Die softwaretechnische Herangehensweise an diese Probleme ist anders, als ich sie vornehmen würde. Ich denke viel geometrisch: Abstände zwischen Rohren (Kreisen), Bezug von Linien zueinander. Zusammenhänge dieser Objekte sind mir intuitiv teilweise so klar, dass ich gar nicht erst in meiner Beschreibung darauf eingehe. Ich sehe Probleme und Lösungen (“dieser Kreis ist so zu diesem positioniert”), wie ich sie in CAD bearbeiten würde.
Bei einer softwaretechnischen Umsetzung werden diese Fragen stärker aufgebrochen. Nur weil zwei Kreise existieren, kann ich nicht direkt deren Beziehung zueinander beschreiben. Ich brauche Informationen zur Lage des Mittelpunkts, den Radien der Kreise und den Abstand in mehreren Dimensionen (hier mindestens x und y).
Innerhalb meines CAD-Programms haben die Kreise keine logische Verbindung. Ich zeichne einfach einen und dann daneben einen anderen. Dass die Kreise einen Bezug haben, ist in einer bloßen Darstellung von zwei Kreisen nicht gegeben. Die Logik entsteht in meinem Kopf. Wenn ich diesen Bezug jetzt herstellen will, werde ich gezwungen, den zu beschreiben.
Die Probleme entstehen nicht darin die Mathematik aufzusetzen und zu programmieren. Die KI kann die Logik durchaus durchführen. Aber es entstehen Fragen, die diese Themen berühren und z.B. auch das User Interface betreffen. Das beginnt schon bei der Frage, ob ich den Bezug zwischen zwei Kreisen über deren Außenabstände oder Kreismittelpunkte definieren will. Was macht für den User mehr Sinn?
Das ist kein Thema von Programmiersprache oder grundsätzlicher Beschreibung meines Problems. Es geht um Verbalisierung dessen, was man eigentlich will. Und ehrlich gesagt weiß ich das manchmal selbst nicht, bis ich es sehe.
Es gibt Teile innerhalb des Tools, die korrekt umgesetzt wurden, die sich dann aber als zu umständlich herausgestellt haben. Funktionen die ich so beschrieben habe, weil ich meine Lösungen auf andere Schwerpunkte gelegt habe. In der ersten verbalen Beschreibung eines Tools können das aber vermutlich nur Personen erfassen, die regelmäßig solche Tools erstellen. Solche, die ein intuitives Verständnis für diese Probleme entwickelt haben.
Ich bin kein Programmierer. Ich denke anders. Das ist bestimmt manchmal von Vorteil. Die Beschreibung eines einfachen Online-Tools macht es schwieriger. Es mag Personen geben, die über genug Erfahrung verfügen, dass sie aus der Beschreibung eines Tools direkt die Fehler antizipieren und Lösungen finden können. Solchen Personen wird der Oneshot mit Fable glücken. Ich selbst muss fürs erste weiter iterieren.
]]>Mit den Automationstools in der ersten Phase der KI-Welle schien dann die Möglichkeit gekommen, der Flut an Videos Herr zu werden: KI kümmert sich. Dementsprechend war einer meiner ersten Use-Cases unter Einbindung von n8n eine Automation um meine Watchlist aufzuräumen: Einmal die Woche wird die gescannt und jedes Video in 250 Worten zusammengefasst. Dann bekomme ich eine Mail der Zusammenfassung und eine Empfehlung, ob sich das Video lohnt.
Perfekte Lösung, oder? Statt zig Videos in meiner Liste zu haben, die mich jedes Mal kognitiv belasten, wenn ich YouTube öffne, hab ich jetzt jede Woche eine E-Mail mehr in meinem Posteingang, die zu lesen mich mehr als 10 Minuten kostet und mich jedes Mal kognitiv belastet wenn ich mein Mail Programm öffne.
In den ersten Wochen hielt ich das Ganze noch für eine gute Idee. Bis die Mails dann länger wurden. Sich Videos anzuschauen, erzeugt durch die Zeit, die man sich nehmen muss grundsätzlich erstmal Reibung. Videos in eine Liste zu packen dagegen nicht. Das führte rasch dazu, dass die Liste wuchs. Rasant. Aus ein paar Videos pro Woche wurden schnell ein paar Dutzend. Mangels Erfolg wurde das Projekt dann relativ schnell eingestellt.
Das Beispiel zeigt eine generelle Gefahr, wenn man beginnt Prozesse zu automatisieren, ohne sich selbige vorher überhaupt mal anzuschauen. Die technische Umsetzung einer KI, die einem das Schauen von YouTube-Videos abnimmt, ist heute kein Problem mehr. Das macht den ursprünglichen Prozess deswegen aber nicht sinnvoller.
Wie eigentlich immer wäre es besser gewesen, wenn ich erstmal mein Ziel hinterfragt hätte: Will ich einfach nur viele Videos durchschleusen? Oder will ich Videos für später auswählen?
Hier lag auch mein Fehler. Die ganze Automation war darauf ausgelegt, möglichst viele Videos zu verarbeiten. Ergo die wachsende Playlist. Dabei war mein eigentlicher Gedanke ja immer gewesen, Videos auch zum Lernen zu verwenden. Die Entscheidung wurde aber letztlich nur von der Watchlist in den Posteingang verschoben.
Richtig angewandt kann die KI, kann jede Automation helfen, uns das Leben leichter zu machen. Allerdings müssen die Rahmenbedingungen besser benannt sein.
Prozesse vereinheitlichen das Vorgehen größerer Gruppen und Automatisierung hilft dabei aufgesetzte Prozesse im großen Maßstab zu skalieren. Aber ganz am Anfang muss die Frage stehen ob man hier überhaupt das richtige Problem angeht. Will ich dieses Video gucken? Will ich mich hiermit längerfristig auseinandersetzen? Oder verlagere ich die Pain Points nur in einen weiteren Prozess, den ich im Auge halten muss?
]]>