Architecture and Design Flashcards
Benefits of proper AI Experimentation
- Decide when goals are reached
- Test for bias and assumption in data and hardware
- reproduce models, version experiment
- apply root-cause for false predicitons
Was sind Requirements für Experimentation?
3
Logging und Tracking von:
- all relevant data
- Code
- Decisions in the run
Runs must be reproducible or often repeated for averaging
Must be independent of environment
Was sind Guidelines für das Definieren einer Architektur?
2
- Verstehe die Anforderungen
- Verstehe die Domain-Grenzen (Fachliche Abgrenzung wie Sales / Support)
Für was steht das C4 Modell (Definition, Nennung der 4 C’s und deren Beschreibung)
- Context of Software System
- Container
- Component
- Code
In SW Entwicklung gibt es verschiedene Audiences (Nutzer, Management, Kunden, Tester, …) -> Benötigen verschiedene Stories
Context
Wie passt die Software in die Welt? Für Non-Technical Persons
Container
High Level Überblick über Container
Component
Komponenten / Modelle eines Containers
Code (Optional)
Zoomt in ein Komponent und zeigt ein UML Diagramm oder ähnliche Darstellungsform (nur für sehr komplexe Anwendungen)
Abstraktionen, warum sind sie wichtig in der SW Architektur und aus welchen essenziellen Bestandteile besteht sie?
Syntax und Notationen variieren von Architektur zur Architektur, aber die Bestandteile der Abstraktionen bleiben gleich:
- Interagierende Personen
- **Software System **
zB andere Systeme, welche eine Abhängigkeit darstellen - wie OpenAI -
Container
Application or Data Store as Deployable / runnable Unit -
Component
Gruppe von relevanten Funktionalitäten hinter einen gutdefinierten Interface
5 Gründe, warum gute Architektur ein Team Effort ist
- Mehrere Perspektiven
- Keine insulare Kenntnisse
- Es gibt keinen Experten für alles
- Domain Experten können Umgebung und Use Cases besser einschätzen
- Managers kennen Einschränkungen besser
Nenne die SOLID Prinzipien der traditionellen SE
Die SOLID-Prinzipien sind wichtige Software-Design-Prinzipien, die Entwicklern helfen, klare Konzepte für die ordnungsgemäße Entwicklung von Software zu haben. Die SOLID-Prinzipien umfassen folgende Prinzipien:
SRP: Single Responsibility Principle (Prinzip der eindeutigen Verantwortlichkeit)
OCP: Open Closed Principle (Prinzip der Offen- und Verschlossenheit)
LSP: Liskovsches Substitutionsprinzip (Ersetzbarkeitsprinzip)
ISP: Interface Segregation Principle (Schnittstellenaufteilungsprinzip)
DIP: Dependency Inversion Principle (Abhängigkeits-Umkehr-Prinzip)
SOLID
Benenne und beschreibe SRP
Single Responsibility Principle (SRP):
Definition: Eine Klasse sollte nur eine einzige Verantwortlichkeit haben, d.h., sie sollte nur einen Grund zur Änderung haben.
Beispiel: Eine Klasse, die sowohl für die Datenbankverbindung als auch für die Datenverarbeitung zuständig ist, verstößt gegen SRP. Besser wäre es, diese Verantwortlichkeiten auf zwei separate Klassen aufzuteilen.
SOLID
Benenne und beschreibe OCP
Open Closed Principle (OCP):
Definition: Softwaremodule sollten offen für Erweiterungen, aber geschlossen für Änderungen sein.
Beispiel: Anstatt eine bestehende Klasse zu ändern, um neue Funktionalitäten hinzuzufügen, sollte man die Klasse erweitern oder eine neue Klasse erstellen, die die bestehende Klasse nutzt.
SOLID
Benenne und beschreibe LSP
Liskov Substitution Principle (LSP):
Definition: Objekte einer Basisklasse sollten durch Objekte ihrer abgeleiteten Klassen ersetzt werden können, ohne dass das Verhalten des Programms verändert wird.
Beispiel: Wenn eine Klasse Vogel eine Methode fliegen() hat, sollte jede Unterklasse wie Spatz oder Adler diese Methode sinnvoll implementieren können, ohne das Programm zu stören.
SOLID
Benenne und beschreibe ISP
Interface Segregation Principle (ISP):
Definition: Viele spezifische Schnittstellen sind besser als eine allgemeine Schnittstelle.
Beispiel: Anstatt eine große Schnittstelle Fahrzeug mit Methoden wie fahren(), fliegen(), und schwimmen() zu haben, sollte man mehrere spezifische Schnittstellen wie Auto, Flugzeug, und Boot definieren.
SOLID
Benenne und beschreibe DIP
Dependency Inversion Principle (DIP):
Definition: Hochrangige Module sollten nicht von niederrangigen Modulen abhängen. Beide sollten von Abstraktionen abhängen. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.
Beispiel: Anstatt dass eine Klasse direkt eine konkrete Implementierung einer Datenbankverbindung verwendet, sollte sie eine Schnittstelle verwenden, die von einer konkreten Implementierung implementiert wird.
Was sind Unterschiede zwischen traditioneller SE und SE4AI?
- Es gibt spezifische ML Design-Patterns
- DevOps -> MLOps
- Testing Unit, Integration, Acceptance + Ethics, Model, Data
- Align ML Heartbeat to SW Heartbeat
Was ist ein Heartbeat?
In der Computertechnik ist ein Heartbeat ein Programm, das bei jeder Initialisierung oder jedem Neustart eines Systems automatisch spezielle Skripte ausführt. In Systemen, die ein Heartbeat-Programm ausführen, kommunizieren zwei oder mehr Knoten miteinander, indem sie Pakete, sogenannte „Heartbeats“, mit einer Rate von ungefähr 2 Hertz (Hz) (zweimal pro Sekunde) austauschen.
Nenne die drei “Systematic Architectural Decisions” Regionen
- System Landscape
- Intelligence Location
- System Architecture
Idee und Definition von System Landscape innerhalb der “Systematic Architectural Decisions”
System Landscape: bezieht sich auf die Gesamtheit der Systeme und deren Interaktionen innerhalb einer Organisation. Es umfasst alle relevanten Systeme, deren Schnittstellen und die Art und Weise, wie sie miteinander kommunizieren. Die Systemlandschaft hilft dabei, ein umfassendes Bild der IT-Infrastruktur zu bekommen und die Abhängigkeiten zwischen den Systemen zu verstehen
Wo wird was deployt (SW? Model?)
Welche Frameworks werden benutzt?
Ist es in einer All-in-one Cloud Solution (AWS, Azure, …) oder integrierter lokalen Services?
Idee und Definition von Intelligece Location innerhalb der “Systematic Architectural Decisions”
Intelligece Location beschreibt, wo die “Intelligenz” oder die Entscheidungslogik innerhalb eines Systems platziert ist. In AI-gestützten Systemen kann dies bedeuten, dass die Entscheidungsfindung entweder zentralisiert (z.B. in einem Hauptserver) oder dezentralisiert (z.B. in Edge-Geräten) erfolgt.
Die Platzierung der Intelligenz beeinflusst die Leistung, Skalierbarkeit und Zuverlässigkeit des Systems
Idee und Definition von System Architecture innerhalb der “Systematic Architectural Decisions”
System Architecture ist die strukturelle Gestaltung eines Systems, einschließlich der Komponenten, deren Beziehungen und der Prinzipien und Richtlinien, die das Design und die Evolution des Systems leiten. Die Systemarchitektur legt fest, wie die verschiedenen Teile eines Systems zusammenarbeiten, um die gewünschten Funktionen und Leistungen zu erbringen
Nenne 3 Vor- und 4 Nachteile von Cloud / ML Plattform Providern
und die potenzielle Alternative
Vorteile
+ Standardized, “plug&play” pipelines for data preparation, training, and deployment
+ Easy to close a feedback loop
+ Easy to scale for massive amounts of data
Nachteile
- Limited to few algorithms
- Vendor lock
- Can be expensive
- Specialist knowledge is lost if working for another provider
Alternative:
OS Solutions: MLflow, Kubeflow, fastai, docker, …
Erwägungen bei Model Update (Intelligence Location)
- Frequency of model updates
- The need for an update (risk of costly mistakes)
- The availability of the runtime for an update
- The disruptiveness in experience of an update
- The complexity of the architecture to maintain different versions of a model
3 Erwägungen bezüglich der Latenz: Inferenz
- Synchrones oder Asynchrone Verarbeitung des ML Prozesses
- Anzahl der Prozessschritte
- Potenzielle Parallelisierung
Erwägungen im Kosten-Aspekt
Nenne Faktoren Distribution Cost und Execution Cost
Distribution Cost
Kosten für Model Updates, API-Calls, DB Accesses …
Execution Cost
Kosten für Chats, wie das Senden von Context Informationen, CPU, GPU, RAM, TPU, Energie-Kosten, Cloud Kosten, Single vs Batch Erwägung
Nenne drei verschiedene Location Möglichkeiten den intelligenten Part der Anwendung dem Kunden zur Verfügung zu stellen. Gehe auf Vor- und Nachteile ein.
Der KI-Part wird mit der SW mitgesendet
- Ähnlich zum SW Heartbeat
- Nicht gut für Data-Shifting / Time-Shifting Problems
- Für die meisten Probleme nicht gut genug
Der KI-Part kann in der SW geupdated werden
- sehr flexibel hinsichtlich verändernder Probleme / Daten
- schwierig umzusetzen (neue features, Rückgabewerte, …)
- schwierig einzuschätzen, wann ein Update notwendig ist
Der KI-Part ist getrennt von der SW als Serverzentrierte API
- Einfach umzusetzen
- Flexibel hinsichtlich Änderungen
- Kosten sind nur vom Cloud-Provider abhängig
- Performance unabhängig vom Gerät
Backend-Intelligence nutzt offline cached results (good for finite results)
Hybrid Versions
Nenne die 8 ML Stack Elemente und nenne für jedes ein Beispiel
- Data Analysis (Python, IH)
- Source Control (Git)
- Experimentation (Deepeval, Phoenix, Python)
- Feature Store (Feast, DataBricks FeatureStore)
- ML Pipeline (Mlflow, Data Version Control)
- Model Registry (DVC)
- Meta Data Store (DVC)
- Model Monitoring (DVC)
Beschreibe einen Parameter Server. Was ist die Idee dahinter?
Ein Parameter Server löst das folgende Problem:
Große LLM Modelle haben Milliarden von Parameter -> Parameter liegen also auf verschiedenen Servern und benötigen Distributed Learning and Inference
Definiere Model Serving
Das Problem des Model Serving (Bereitstellung eines ML-Modells für die Inferenz in Produktionsumgebungen) bezieht sich auf die Herausforderung, ein trainiertes Modell so einzusetzen, dass es zuverlässig und effizient auf eingehende Datenanfragen reagiert. Ein zentraler Aspekt dabei ist die Zugänglichkeit von Features während des Model Serving.
Nenne 3 von 4 Problemen, die es bei der Architektur von KI-Komponenten geben kann.
Googles Reported Issues
Issues reported by Google
- No principled way for accessing features during model serving
- Features cannot easily be reused among multiple MLOps pipelines
- Lack of collaboration, sharability, and reuse among ML projects
- Incosistency between features used in training and inference (serving time)
- Unclear how to know which features need to be recomputed when new data arrives (so entire pipelines needs to run for updating all features)
Note:
Data is the hardest part of ML and the most important piece to get right.
Idea and Definition of a Feature Store
Idea: Multiple Teams can generate and consume the same features from one single store.
Nenne 5 Feature Store Benefits
11
- **Re-use and discover features across team and project boundaries **
- Access control and versioning support for features
- Precomputation and automatic filling of features for entities of interest
- Centralized place for data quality and integrity checks
- Insurance of consistency of features in training and inference
- Compute once, consume multiple times
- Share expertise across teams
- Easier to maintain quality of features
- Easier to test
- Better incorporation into MLOps pipeline
- Better testability of ML models
Was ist ein Model-Server and was sind Benefits?
Ein Model-Server stellt eine Vielzahl von Models zur Verfügung.
+ Viele Models auf zentralen Platz
+ Ensemble Learning realisierbar
+ Neue Deployment Szenarien (shadow Modes)
+ A/B Testing mit Models
Nenne 3 von 6 Überlegungen beim Design von ML-UX
- Mach Nutzer bewusst, dass es nicht deterministisch ist
- (sometimes) Provide multiple outputs
- Audience Angepasst (IT People, Laien)
- Mach das Intelligente einfach zu nutzen
- Design for Forgiveness (Funny AI, Humanize it)
- Feedback (Implizit / Explizit)
UX Design for ML Errors, nenne 3 Überlegungen
- Update ML Features kontinuierlich
- Nutze Implizites Feedback
- Mach es einfach Fehler zu korrigieren
Nenne die großen ML-UX Design Punkte für gute Prinzipien
- Mistakes Wie geht man mit KI Fehler um?
- Mehrere Outputs Welche zeigt man an (Accuracy vs Diversity)
- Confidence Überführe die Confidence Score ins User UX
- Attribution Zeige warum, die Ergebnisse so sind (Explainability) -> + Transparency
- Limitations Communicate with User, Demonstrate App Usage, Explain inferior results
