Zurück zu Ressourcen
Guides & Templates
KI-Produktmanagement: Von der Modellauswahl bis zur Datenarchitektur
Senior Technical AI Product Manager & Machine Learning Architect
Ziel: Ein umfassender, schrittweiser Leitfaden, der Produktmanager zu technischen Führungskräften für KI-gesteuerte Produkte qualifiziert, mit einem besonderen Fokus auf Branchen mit hohen Anforderungen wie Fintech und Reisen.
Modul 1: Modell-Taxonomie & Auswahl
Das Verständnis der Landschaft der KI-Modelle ist die Grundlage im Werkzeugkasten jedes technischen PM.
Modelltypen
- SLMs (Small Language Models): Leichtgewichtig, schnell, kosteneffizient. Ideal für Klassifizierung, Zusammenfassung und On-Device-Inferenz. Beispiele: Phi-3, Gemma.
- LLMs (Large Language Models): Breites Wissen, starke Generalisierungsfähigkeit. Am besten für komplexe Generierung, mehrstufige Konversationen und kreative Aufgaben. Beispiele: GPT-4, Claude, Gemini.
- Reasoning-Modelle (o1-style): Optimiert für mehrstufiges logisches Denken und Chain-of-Thought-Problemlösung. Am besten für komplexe Analysen, Codegenerierung und mathematisches Schließen.
- Vision-Modelle: Verarbeiten und verstehen Bilder neben Text. Unverzichtbar für Dokumenten-OCR, visuelle Inspektion und multimodale Anwendungen.
Entscheidungsmatrix
| Anwendungsfall | Fintech | Reisebranche | Empfohlener Modelltyp |
|---|---|---|---|
| Betrugserkennung | Analyse von Transaktionsmustern | Erkennung von Buchungsanomalien | SLM / Reasoning-Modell |
| Kundensupport | Kontoanfragen, Compliance-Fragen | Buchungsänderungen, Reisehinweise | LLM |
| Dokumentenverarbeitung | KYC-Dokumentenprüfung | Pass-/Visum-OCR | Vision-Modell |
| Komplexe Analyse | Risikobewertung, Einhaltung von Vorschriften | Dynamische Preisgestaltung, Reiseroutenoptimierung | Reasoning-Modell |
| Content-Generierung | Berichterstellung | Beschreibungen von Reiserouten, Reiseführer | LLM |
Checkliste für PMs
- Definieren Sie die primäre Aufgabe (Klassifizierung, Generierung, Schlussfolgern, Bilderkennung)
- Bewerten Sie die Latenzanforderungen (Echtzeit vs. Batch)
- Evaluieren Sie Kostenbeschränkungen und Volumenerwartungen
- Bestimmen Sie, ob domänenspezifisches Wissen entscheidend ist
- Berücksichtigen Sie regulatorische und Compliance-Anforderungen
Modul 2: Hosting & Infrastruktur
Lokales Hosting
Tools: Ollama, vLLM, llama.cpp
Hardware-Anforderungen:
- Modelle mit 7B Parametern: 8GB+ RAM, Consumer-GPU (RTX 3060+)
- Modelle mit 13B Parametern: 16GB+ RAM, Mid-Range-GPU (RTX 3090+)
- Modelle mit 70B+ Parametern: 64GB+ RAM, Enterprise-GPU (A100, H100)
Wann einsetzen: Prototyping, datensensible Anwendungen, abgeschottete Umgebungen, Kostenoptimierung bei Skalierung.
Cloud-Hosting
Hugging Face Ecosystem:
- Spaces: Schnelle Demos und Prototypen mit Gradio/Streamlit
- Inference Endpoints: Produktivtaugliches, automatisch skalierendes Modell-Serving
- Vorteile: Riesige Modellbibliothek, Community-Support, flexible Preisgestaltung
Managed Providers (OpenAI, Anthropic, Google):
- Vorteile: Kürzeste Zeit bis zur Produktion, verwaltete Infrastruktur, Enterprise-SLAs
- Nachteile: Datenschutzbedenken, Anbieterabhängigkeit, weniger Anpassungsmöglichkeiten
Quantisierung
Quantisierung reduziert die Präzision eines Modells (z. B. von FP16 auf INT8 oder INT4), um den Speicherbedarf zu verringern und die Geschwindigkeit zu erhöhen.
- FP16: Volle Präzision, höchste Qualität, höchste Kosten
- INT8: ~50% Speicherreduktion, minimaler Qualitätsverlust
- INT4: ~75% Speicherreduktion, spürbarer Qualitätskompromiss
Auswirkung: Ein 70B-Modell mit FP16 benötigt ~140 GB VRAM. Mit INT4 passt es in ~35 GB – und ist damit auf einer einzigen A100 lauffähig.
Checkliste für PMs
- Berechnen Sie das erwartete Abfragevolumen und die Latenz-SLAs
- Evaluieren Sie Anforderungen an Datenresidenz und Datenschutz
- Vergleichen Sie die Gesamtbetriebskosten: Cloud-API vs. selbst gehostet
- Planen Sie die Skalierung: automatisch skalierende Endpunkte vs. feste Infrastruktur
- Bewerten Sie die Fähigkeiten des Teams für das Infrastrukturmanagement
Modul 3: Der Entscheidungsbaum zur Optimierung
Framework
Hier starten: Ist das Wissen des Basismodells ausreichend?
|
+-- JA --> Ist das Ausgabeformat/der Stil korrekt?
| |
| +-- JA --> So verwenden (evtl. leichtes Prompt Engineering)
| +-- NEIN --> Prompt Engineering (System-Prompts, Few-Shot-Beispiele)
|
+-- NEIN --> Benötigt das Modell Zugriff auf IHRE Daten?
|
+-- JA, und die Daten ändern sich häufig --> RAG
+-- JA, und es handelt sich um stabiles Fachwissen --> Fine-Tuning
+-- Eine völlig neue Fähigkeit wird benötigt --> Vollständiges Pre-Training (selten, teuer)
Wichtige technische Unterscheidung
Aktualisierung der Modellgewichte (Fine-Tuning):
- Ändert das Verhalten des Modells dauerhaft
- Erfordert Trainingsdaten und Rechenleistung
- Das Wissen wird "eingebrannt"
- Wie jemandem eine neue Fähigkeit beibringen
Aktualisierung einer Wissensdatenbank (RAG):
- Das Modellverhalten bleibt gleich
- Neue Informationen werden zur Abfragezeit abgerufen
- Das Wissen ist extern und leicht aktualisierbar
- Wie jemandem ein Nachschlagewerk geben
Vergleichstabelle
| Ansatz | Kosten | Aufwand | Ideal für |
|---|---|---|---|
| Prompt Engineering | Niedrig | Stunden | Format, Tonalität, einfache Aufgabensteuerung |
| RAG | Mittel | Tage-Wochen | Dynamische Daten, Firmendokumente, FAQs |
| Fine-Tuning | Hoch | Wochen | Domänenexpertise, konsistenter Stil |
| Pre-Training | Sehr hoch | Monate | Völlig neue Sprache oder Domäne |
Checkliste für PMs
- Beginnen Sie mit Prompt Engineering, bevor Sie eskalieren
- Dokumentieren Sie, wann Prompt Engineering an seine Grenzen stößt
- Für RAG: Identifizieren Sie Datenquellen und Aktualisierungshäufigkeit
- Für Fine-Tuning: Bereiten Sie mindestens 1.000+ qualitativ hochwertige Beispiele vor
- Führen Sie immer einen Benchmark-Vergleich mit dem Basismodell durch
Modul 4: Datenarchitektur
Wann ist eine traditionelle Datenbank (SQL/JSON) ausreichend?
- Strukturierte, tabellarische Daten mit bekannten Schemata
- Exakte Suchanfragen (Benutzerprofile, Transaktionen, Buchungen)
- ACID-Konformitätsanforderungen (Finanzunterlagen)
- Einfaches Filtern, Sortieren und Aggregieren
Beispiel: Buchungshistorie von Kunden, Transaktionsjournale, Benutzerpräferenzen.
Wann ist eine Vektordatenbank notwendig?
Vektordatenbanken sind unverzichtbar, wenn Sie semantische Suche benötigen – das Finden von Informationen nach Bedeutung statt nach exakten Schlüsselwörtern.
Schritt-für-Schritt-Prozess:
- Wählen Sie ein Embedding-Modell: Wandeln Sie Text/Bilder in numerische Vektoren um (z. B. OpenAI text-embedding-3, Sentence Transformers)
- Embeddings generieren: Verarbeiten Sie Ihre Dokumente mit dem Embedding-Modell
- Vektoren indizieren: In einer Vektor-DB speichern (Pinecone, Weaviate, Qdrant, pgvector)
- Retrieval konfigurieren: Ähnlichkeitsmetriken (Kosinus, Skalarprodukt) und Top-k-Ergebnisse festlegen
- Mit LLM integrieren: Abgerufenen Kontext an das Modell übergeben (RAG-Muster)
Beispiel: Suche in Reisebewertungen nach "romantischen Strandhotels mit gutem Essen" oder das Finden ähnlicher Betrugsmuster über Transaktionen hinweg.
Wann ist ein Knowledge Graph überlegen?
Knowledge Graphs sind dann hervorragend geeignet, wenn:
- Komplexe Beziehungen wichtig sind
- Multi-Hop-Reasoning erforderlich ist
- Erklärbarkeit entscheidend ist
- Daten eine reiche, vernetzte Struktur haben
Checkliste für PMs
- Analysieren Sie Ihre Datentypen: strukturiert, unstrukturiert oder beides?
- Identifizieren Sie Abfragemuster: exakte Übereinstimmung, semantische Suche oder relational?
- Für Vektor-DBs: Schätzen Sie die Embedding-Dimensionen und den Speicherbedarf
- Für Knowledge Graphs: Bilden Sie Entitätstypen und Beziehungstypen ab
- Ziehen Sie hybride Ansätze in Betracht: SQL + Vektor-DB wird immer häufiger eingesetzt