Enterprise GenAI Platform isoliert KI Service von .NET Kern

Enterprise GenAI Platform testete, was geschieht, wenn der Python Service, der KI Berechnungen ausführt, nicht verfügbar ist. Während Python nicht erreichbar war, erhielt ein semantischer Vergleichs Request einen HTTP 503 Fehler. Der .NET Core API blieb jedoch aktiv und verarbeitete den Request nach dem Neustart des Python Containers wieder erfolgreich. Dieser Vorgang zeigte, dass ein Ausfall einer KI Abhängigkeit als klare Fehlermeldung einer einzelnen Operation behandelt werden soll, anstatt als unvorhersehbarer Serverausfall. Das Ergebnis wirft die Frage auf, wo die Grenze zwischen Geschäftslogik und maschinellem Lernen zu ziehen ist und wie viel Verteilung tatsächlich für diese Grenze nötig ist. Die Plattform nutzt einen modularen Monolithen in .NET 10, in dem öffentliche Routen, Validierung, Anwendungslogik und PostgreSQL Zugriff zusammengefasst sind. Die Chats und KI Module bleiben innerhalb des Core API logisch getrennt, ohne eigene Prozesse. KI Berechnungen benötigen jedoch andere Lebenszyklen, wie das Laden von Modellgewichten, PyTorch Abhängigkeiten und CPU Last, weshalb sie separat in einem Python Service ausgeführt werden. Obwohl KI Modelle auch in .NET über ONNX Runtime laufen könnten, bietet Python direkten Zugriff auf spezialisierte Tools, die nicht in den Core API integriert werden sollen. Die Trennung ermöglicht unabhängiges Skalieren, erschwert jedoch die Interaktion durch HTTP Aufrufe und erfordert Vertragsabstimmung sowie Fehlerbehandlung. Für Tests wurde eine einfache semantische Vergleichsoperation verwendet, bei der Sätze mit dem sentence-transformers/all-MiniLM-L6-v2 Modell in 384 dimensionalen Embeddings umgewandelt werden. Der Cosinusähnlichkeit wird dann zwischen den Vektoren berechnet, um semantische Nähe zu messen.

Der Service lädt das Modell einmal beim Start und speichert es im Anwendungszustand, um wiederholte Initialisierung zu vermeiden. Die Implementierung nutzt FastAPI mit einer synchronen Funktion, die in einem Threadpool läuft, ohne den asynchronen Event Loop zu blockieren. Die Kommunikation zwischen .NET und Python erfolgt über einen einfachen HTTP POST Request, der in AiOrchestratorClient typisiert ist. Dieser Ansatz vermeidet die Komplexität von Message Queues für kurze interaktive Operationen. Die Wahl von Python als separatem Service basiert auf der Notwendigkeit, spezialisierte Bibliotheken und Workloads zu isolieren, während .NET den stabilen Kern der Plattform bereitstellt. Die Plattform betont, dass klare Fehler für einzelne Operationen wichtig sind, um systemweite Ausfälle zu verhindern. Gleichzeitig wird die Architektur als experimentell betrachtet, da aktuelle Lastdaten fehlen und weitere Tests erforderlich sind, um Skalierungsbedarf zu bestimmen. Die Entscheidung, Python separat zu betreiben, spiegelt einen strategischen Versuch wider, KI Workloads von der Kernanwendung zu trennen, ohne die Stabilität des gesamten Systems zu gefährden. Diese Trennung ermöglicht eine flexiblere Ressourcenverwaltung und Updates der KI Modelle, birgt aber auch zusätzliche Komplexität in der Interaktion zwischen den Komponenten. Die Plattform plant, weitere Tests durchzuführen, um die praktischen Auswirkungen dieser Architektur auf Skalierbarkeit und Zuverlässigkeit zu bewerten. Die Ergebnisse zeigen, dass ein klarer Trennpunkt zwischen Geschäftslogik und KI Berechnungen wichtig ist, um Fehler isoliert zu halten. Gleichzeitig wird betont, dass die aktuelle Implementierung noch nicht für hohe Lasten optimiert ist und weitere Forschung erfordert.