Ich schreibe ein Buch. Es heißt „Architekturmuster für Enterprise-KI“, im Untertitel „Multi-LLM-Systeme in regulierten Branchen einsetzen“, und erscheint 2027 im Carl Hanser Verlag.
Worum es geht
Sobald mehr als ein Sprachmodell an einem Ablauf beteiligt ist, hängt das Ergebnis weniger am einzelnen Modell als an der Schicht um die Modelle herum. Welcher Schritt bekommt welches Modell? Wann bricht ein Ablauf ab? Welche Daten verlassen das eigene Netz, und was davon wird aufgezeichnet? Um diese Schicht geht es.
Liefert ein solches System unerwartete Ergebnisse, liegt das an einer von drei Achsen: am Modell, am Kontext oder an der Formulierung. Die Gegenmaßnahmen sind je nach Achse verschieden. Wer die Achsen verwechselt, arbeitet wochenlang an der falschen Stelle.
Das Buch gibt dabei zwei Arten von Antworten und hält sie auseinander. Ein Architekturmuster ist eine Struktur: Bausteine, ihre Beziehungen und der Preis, den man dafür zahlt. Eine Best Practice ist eine Handlungsregel ohne eigene Bausteine. Die Muster stehen als Katalog mit Problem, Struktur, Preis und Reifegrad, die Best Practices daneben, und beide bekommen dasselbe Gewicht.
Die These dahinter
Eine regulatorische Anforderung ist eine Entwurfsfrage, keine Nachrüstung.
Bei der Recherche bin ich auf einen Befund gestoßen, den ich so nicht erwartet hatte: Aufsichtstexte aus der Arzneimittelentwicklung, der Finanzwirtschaft und der Luftfahrt zeigen unabhängig voneinander in dieselbe Richtung: Die Qualität der Ergebnisse soll auch nach der Abnahme überwacht werden. Sie fordern das unterschiedlich streng, und einer der drei Texte ist noch ein Entwurf. Dass an einer Stelle ein Mensch die Verantwortung trägt, verlangt in allen drei Branchen ohnehin schon das ältere Recht.
Eine Architektur, die beides trägt – die Überwachung und die verantwortliche Person –, bedient damit mehrere Aufsichtsregime zugleich. Dann kostet die nächste Verordnung eine Anpassung und kein neues Projekt.
Für wen es ist
Für alle, die Systeme mit mehreren Sprachmodellen in regulierten Branchen planen, bauen oder verantworten, also Architektinnen und Architekten, technische Leitungen und die Menschen, die am Ende für ein solches System geradestehen. Wer wissen will, wie man ein bestimmtes Werkzeug bedient, ist hier falsch. Es geht um die Entscheidungen, die beim Bau solcher Systeme unvermeidlich anstehen, und darum, woran man erkennt, dass man sie falsch getroffen hat.
Ein echtes System als Beispiel
Die Muster werden an einem echten System konkret: an Cohereny, das seit heute veröffentlicht ist. Im Buch ist es ein durchgehendes Beispiel, keine Produktwerbung.
Warum ein echtes System und kein ausgedachtes? Ausgedachte Beispiele gehen immer auf. Sie haben keine Altlasten, keine Fehlentscheidung von vor sechs Wochen, keine Stelle, an der zwei Annahmen einander widersprechen, ohne dass es jemand gemerkt hat. Genau solche Stellen sind aber der Gegenstand des Buchs.
Dazu gehört auch Ehrlichkeit darüber, was ich selbst messen kann. Meine eigene Hardware ist klein. Wo eine Aussage größere Hardware braucht, stammt die Zahl aus fremden Erhebungen, gegen die Primärquelle geprüft. Wo eine eigene Messung im Buch steht, steht der Befehl daneben, damit man sie auf der eigenen Maschine wiederholen kann.
Wann es erscheint
Das Buch erscheint 2027 im Carl Hanser Verlag. Sobald es einen Termin und eine Verlagsseite gibt, steht beides hier.