Bevor Sie ein KI-Produkt bauen: Die Architektur-Fragen, die niemand stellt

Zusammenfassung

Die meisten KI-Produkte scheitern nicht wegen schlechter Modelle, sondern wegen schlechter Architekturentscheidungen, die vor dem ersten Prompt getroffen wurden. Dieser Leitfaden behandelt die Fragen, die Sie vor dem Bauen beantworten müssen: Wie viel Latenz tolerieren Ihre Nutzer? Was kostet eine Anfrage bei Skalierung? Ist KI überhaupt die richtige Lösung? Sie erhalten ein Modellauswahl-Framework, einen RAG-vs-Fine-Tuning-Entscheidungsbaum und einen realistischen Kostenrechner — denn "wir nehmen GPT-4" ist keine Architektur.

Voraussetzungen

• Eine klare Produktvision mit definierten Nutzer-Workflows
• Verständnis Ihrer Daten: was Sie haben, wo sie liegen, wie sensibel sie sind
• Eine Ziel-Nutzerzahl (das treibt die Kostenrechnung)
• Grundlegendes Verständnis von LLM-Konzepten (Tokens, Embeddings, Context Windows)

Schritt 1: Das Latenz-Kosten-Genauigkeits-Dreieck

Jedes KI-Produkt muss explizite Kompromisse zwischen drei konkurrierenden Einschränkungen machen. Sie können nicht alle drei gleichzeitig optimieren.

Das Dreieck

       GENAUIGKEIT
           /\
          /  \
         / Wähle \
        /  Zwei   \
       /____________\
   LATENZ       KOSTEN

Konkrete Kompromisse

Priorität                 | Architektur-Implikation
--------------------------+--------------------------------------------
Genauigkeit + Niedrige    | Teuer. Großes Modell, leistungsstarke GPU,
Latenz                    | Edge-Deployment. Budget: $$$ pro Anfrage.

Genauigkeit + Niedrige    | Langsam. Kleineres Modell mit mehreren
Kosten                    | Durchgängen, Caching, async. Der Nutzer wartet.

Niedrige Latenz + Niedrige| Weniger genau. Kleinere/schnellere Modelle,
Kosten                    | weniger Tokens, einfachere Prompts.

Definieren Sie Ihre Einschränkungen

Bevor Sie eine Technologie wählen, füllen Sie diese Zahlen aus:

Maximal akzeptable Latenz (p95): _____ ms
  - Konversations-Chat: 500-2000ms für erstes Token
  - Suche/Empfehlung: 200-500ms
  - Batch-Verarbeitung: Minuten bis Stunden (egal)
  - Echtzeit-Analyse: 50-200ms

Zielkosten pro Anfrage: $_____ 
  - Consumer-Produkt (hohes Volumen): $0,001-0,01
  - B2B SaaS (mittleres Volumen): $0,01-0,10
  - Enterprise-Tool (niedriges Volumen): $0,10-1,00
  - Internes Tool: was es kostet

Minimale Genauigkeitsschwelle: _____% 
  - Medizin/Recht: 99%+ (KI allein wahrscheinlich ungeeignet)
  - Content-Erstellung: 85-95% (menschliches Review fängt Rest ab)
  - Klassifikation/Routing: 90-98%
  - Suche/Empfehlung: 80-90%

Schritt 2: Modellauswahl-Framework

Ein Modell auszuwählen heißt nicht, das "beste" zu nehmen. Es geht darum, das richtige für Ihre Einschränkungen zu wählen.

Entscheidungsmatrix

Anwendungsfall         | Empfohlene Modellklasse         | Warum
-----------------------+---------------------------------+-------------------
Einfache Klassifikation| Klein (Llama 3 8B, Mistral 7B)  | Schnell, günstig
Named Entity Extraction| Klein/Mittel                    | Strukturierter Output
Zusammenfassung        | Mittel (Llama 3 70B, Claude Haiku)| Balance Qualität/Kosten
Code-Generierung       | Groß (GPT-4o, Claude Sonnet)   | Braucht Reasoning
Komplexes Reasoning    | Groß (GPT-4o, Claude Opus)     | Genauigkeit kritisch
Multi-modal (Bilder)   | Groß (GPT-4o, Claude Sonnet)   | Begrenzte Optionen
Embeddings/Suche       | Embedding-Modell                | Zweckgebaut
Echtzeit-Konversation  | Mittel mit Streaming            | Latenz zählt

Self-Hosted vs API

Faktor               | Self-Hosted (Ollama, vLLM)     | API (OpenAI, Anthropic)
---------------------+--------------------------------+------------------------
Latenz-Kontrolle     | Volle Kontrolle                | Provider-abhängig
Kosten bei niedrigem | Hoch (GPU-Kosten)              | Niedrig (Pay per Token)
Volumen              |                                |
Kosten bei hohem     | Niedriger pro Anfrage          | Lineare Skalierung
Volumen              |                                |
Datenschutz          | Daten bleiben on-premise       | Verlassen Ihre Infra
Modell-Updates       | Manuell                        | Automatisch
Operativer Aufwand   | Hoch (GPU, VRAM, Skalierung)   | Keiner
Max. Modellqualität  | Begrenzt durch Ihre GPU        | State of the Art

Break-even: ~100.000 Anfragen/Tag ist wo Self-Hosting
günstiger wird als API-Calls (Schätzung, modellabhängig).

Das "Start mit API, wechsle zu Self-Hosted"-Muster

Das ist fast immer der richtige Ansatz für neue Produkte:

1. Bauen Sie Ihr Produkt mit einem API-Anbieter (OpenAI, Anthropic)
2. Abstrahieren Sie den LLM-Call hinter einem Interface (Provider nie hardcoden)
3. Messen Sie tatsächliche Nutzungsmuster: Tokens/Anfrage, Anfragen/Tag, Latenz
4. Wenn Kosten oder Datenschutz es erfordern, wechseln Sie für bestimmte Workloads zu Self-Hosted
5. Behalten Sie die API für komplexe Reasoning-Tasks, wo Modellqualität am wichtigsten ist

# Gut: Abstrahiertes LLM-Interface
class LLMProvider:
    def complete(self, prompt: str, **kwargs) -> str:
        raise NotImplementedError

class OpenAIProvider(LLMProvider):
    def complete(self, prompt, **kwargs):
        # OpenAI API-Aufruf
        ...

class OllamaProvider(LLMProvider):
    def complete(self, prompt, **kwargs):
        # Lokaler Ollama-Aufruf
        ...

# Provider wechseln ohne Geschäftslogik zu ändern
llm = OpenAIProvider()  # oder OllamaProvider()
result = llm.complete("Klassifiziere dieses Ticket: ...")

Schritt 3: RAG vs Fine-Tuning Entscheidungsbaum

Das ist die am meisten missverstandene Entscheidung in der KI-Produktarchitektur. Die meisten Teams wählen RAG standardmäßig, ohne zu verstehen, wann Fine-Tuning besser ist — und umgekehrt.

Entscheidungsbaum

Muss das Modell domänenspezifische Fakten kennen?
├── NEIN → Basismodell mit gutem Prompting verwenden. Fertig.
└── JA → Ändert sich das Wissen häufig (wöchentlich oder öfter)?
    ├── JA → RAG (Retrieval-Augmented Generation)
    │   Grund: Fine-Tuning auf sich ändernden Daten ist unpraktisch.
    └── NEIN → Geht es um WISSEN (Fakten) oder VERHALTEN (Stil/Format)?
        ├── WISSEN → RAG
        │   Grund: RAG ist besser darin, spezifische Fakten einzufügen.
        └── VERHALTEN → Fine-Tuning
            Grund: Fine-Tuning ändert, WIE das Modell antwortet.

Kann man beides kombinieren?
└── JA, und das ist oft die beste Antwort.
    Fine-Tuning für Verhalten + RAG für Wissen.

RAG-Architekturentscheidungen

Komponente         | Optionen                          | Empfehlung
-------------------+-----------------------------------+------------------
Vektor-Datenbank   | Pinecone, Weaviate, Qdrant,       | pgvector wenn Sie
                   | pgvector, Chroma                  | bereits Postgres nutzen.
Embedding-Modell   | text-embedding-3-small/large,     | text-embedding-3-small
                   | Cohere embed, BGE                 | für die meisten Fälle.
Chunk-Größe        | 256-2048 Tokens                   | Start bei 512, messen.
Chunk-Overlap      | 10-20% der Chunk-Größe            | 50-100 Tokens.
Retrieval-Strategie| Semantisch, Keyword, Hybrid       | Hybrid (semantisch +
                   |                                   | BM25 Keyword) ist am besten.
Reranking          | Cohere rerank, Cross-Encoder      | Ja, immer reranken.
                   |                                   | Verbessert Relevanz 20-40%.

RAG-Pipeline-Beispiel

# Vereinfachte RAG-Pipeline

# 1. Ingestion (offline)
documents = load_documents("./knowledge_base/")
chunks = split_into_chunks(documents, size=512, overlap=50)
embeddings = embed_model.encode(chunks)
vector_db.upsert(chunks, embeddings)

# 2. Abfrage (online, pro Anfrage)
query = "Was ist unsere Rückgaberichtlinie?"
query_embedding = embed_model.encode(query)

# Top-k relevante Chunks abrufen
candidates = vector_db.search(query_embedding, top_k=20)

# Relevanz-Reranking
reranked = reranker.rank(query, candidates, top_k=5)

# Prompt mit Kontext aufbauen
context = "\n\n".join([chunk.text for chunk in reranked])
prompt = f"""Beantworte die Frage basierend auf dem Kontext unten.
Wenn die Antwort nicht im Kontext steht, sage "Ich weiß es nicht."

Kontext:
{context}

Frage: {query}
Antwort:"""

# Antwort generieren
answer = llm.complete(prompt)

Schritt 4: Kostenberechnung — Die Mathematik, die niemand macht

Bevor Sie bauen, berechnen Sie Ihre projizierten Kosten bei Skalierung. Überraschungen hier töten Produkte.

Token-Kostenrechner

# Kosten pro Anfrage schätzen

# Inputs (aus Ihrem Prototyp messen)
avg_input_tokens = 2000    # System-Prompt + RAG-Kontext + Nutzereingabe
avg_output_tokens = 500    # Modellantwort

# Preise (GPT-4o, Stand März 2026)
input_price_per_1k = 0.0025   # $2,50 pro 1M Input-Tokens
output_price_per_1k = 0.01    # $10,00 pro 1M Output-Tokens

# Kosten pro Anfrage
cost_per_request = (avg_input_tokens / 1000 * input_price_per_1k) + \
                   (avg_output_tokens / 1000 * output_price_per_1k)
# = (2 * 0,0025) + (0,5 * 0,01) = $0,005 + $0,005 = $0,01

# Monatliche Kostenprojektion
requests_per_user_per_day = 20
active_users = 1000
monthly_requests = requests_per_user_per_day * active_users * 30
# = 600.000 Anfragen

monthly_llm_cost = monthly_requests * cost_per_request
# = 600.000 * $0,01 = $6.000/Monat

# Nicht vergessen:
# + Embedding-Kosten für RAG (~$0,00002 pro Abfrage)
# + Vektor-DB-Hosting ($50-500/Monat)
# + Compute für Self-Hosted Modelle ($500-5000/Monat pro GPU)
# + Reranking-Kosten bei API-Reranker

Kostenoptimierungsstrategien

Strategie                    | Einsparung | Kompromiss
-----------------------------+------------+---------------------------
Häufige Abfragen cachen      | 30-60%     | Veraltete Antworten möglich
Kleineres Modell für einfache| 50-80%     | Geringere Genauigkeit bei
Aufgaben                     |            | Grenzfällen
Kürzere System-Prompts       | 10-30%     | Weniger Anweisung
Batch-Verarbeitung           | 50%        | Höhere Latenz
Prompt-Komprimierung         | 20-40%     | Etwas schlechteres Verständnis
Self-Hosted bei hohem Volumen| 60-80%     | Operativer Aufwand

Der Unit-Economics-Test

Umsatz pro Nutzer pro Monat:     $___
KI-Kosten pro Nutzer pro Monat:  $___
Andere Kosten pro Nutzer/Monat:  $___

Wenn KI-Kosten > 30% des Umsatzes pro Nutzer, sind Ihre
Unit Economics kaputt. Entweder:
  1. Preis erhöhen
  2. KI-Kosten senken (kleineres Modell, Caching, weniger Calls)
  3. Überdenken, ob KI der richtige Ansatz ist

Schritt 5: Wann KEINE KI verwenden

Die schwierigste Architekturfrage: Sollten Sie überhaupt KI einsetzen?

Verwenden Sie keine KI, wenn:

• Ein regelbasiertes System funktioniert. Wenn Sie die Logik als if/else-Anweisungen schreiben können, tun Sie das. Es ist schneller, günstiger, deterministisch und debuggbar. KI sollte Probleme lösen, die regelbasierte Systeme nicht können.
• Genauigkeit 100% sein muss. LLMs halluzinieren. Wenn eine falsche Antwort echten Schaden anrichtet (Medikamentendosierung, Finanztransaktionen, rechtliche Compliance), kann KI einen Menschen unterstützen, aber nicht allein entscheiden.
• Die Daten strukturiert und die Abfrage exakt sind. "Wie war unser Umsatz in Q3?" ist eine Datenbankabfrage, kein LLM-Prompt. SQL ist schneller, günstiger und garantiert korrekt.
• Latenzanforderungen unter 50ms liegen. Selbst die schnellsten LLMs brauchen 100-500ms. Wenn Ihr Use Case Echtzeitverarbeitung braucht, ist KI zu langsam.
• Sie nicht genug Daten haben, um Qualität zu bewerten. Wenn Sie nicht messen können, ob der KI-Output gut ist, können Sie ihn nicht verbessern. Bauen Sie erst das Evaluierungs-Framework.
• Die Kosten den Wert nicht rechtfertigen. Wenn KI $5/Nutzer/Monat kostet aber nur $2/Nutzer/Monat an Wert liefert, ist es eine schlechte Investition.

Verwenden Sie KI, wenn:

• Die Aufgabe inhärent unscharf ist (natürliche Sprachverarbeitung, Content-Generierung, Klassifikation mehrdeutiger Eingaben)
• Die Alternative teure menschliche Arbeit in großem Maßstab ist
• "Gut genug" akzeptabel ist (Empfehlungen, Zusammenfassungen, Entwürfe)
• Die Domäne zu komplex für erschöpfende Regeln ist
• Nutzer Personalisierung erwarten, die nicht hardcodiert werden kann

Problembehandlung & Hinweise

"Unsere RAG-Pipeline liefert irrelevante Ergebnisse"

Prüfen Sie in dieser Reihenfolge: (1) Sind Ihre Chunks die richtige Größe? Zu groß = Rauschen, zu klein = fehlender Kontext. (2) Nutzen Sie einen Reranker? Das macht einen massiven Unterschied. (3) Ist Ihr Embedding-Modell für Ihre Domäne geeignet? (4) Nutzen Sie hybride Suche (semantisch + Keyword)? Reine semantische Suche verpasst exakte Treffer.

"Die KI ist zu langsam für unsere Nutzer"

Messen Sie zuerst, wo die Zeit vergeht. Typische Aufteilung: (1) Query-Embedding: 50-200ms. (2) Vektorsuche: 20-100ms. (3) Reranking: 100-300ms. (4) LLM-Generierung: 500-5000ms. Nutzen Sie Streaming für die LLM-Antwort — First-Token-Latenz zählt mehr als Gesamtzeit. Cachen Sie Embeddings. Nutzen Sie eine schnellere Vektor-DB wenn die Suche der Engpass ist.

"Kosten sind höher als projiziert"

Messen Sie den tatsächlichen Token-Verbrauch — er ist fast immer höher als geschätzt, weil System-Prompts, Kontext und Konversationshistorie wachsen. Implementieren Sie Token-Zählung. Fügen Sie Caching für wiederkehrende Abfragen hinzu. Routen Sie einfache Abfragen zu günstigeren Modellen.

"Das Modell halluziniert zu viel"

Reduzieren Sie Rauschen im Context Window (senden Sie nur die relevantesten Chunks). Fügen Sie explizite Anweisungen hinzu: "Wenn die Antwort nicht im bereitgestellten Kontext steht, sage Ich weiß es nicht." Nutzen Sie strukturierten Output (JSON-Modus) für extraktive Aufgaben. Senken Sie die Temperature. Erwägen Sie Zitierungen: Bitten Sie das Modell, den Quell-Chunk zu zitieren.

Prävention & Best Practices

Evaluation zuerst bauen

Bevor Sie das Produkt bauen, bauen Sie die Evaluierungs-Pipeline. Erstellen Sie einen Testdatensatz von 50-100 Frage-Antwort-Paaren. Führen Sie jede Architekturänderung gegen diesen Testdatensatz aus. Wenn Sie Qualität nicht messen können, können Sie sie nicht verbessern.

Alles loggen

Loggen Sie jeden LLM-Call: Input, Output, Latenz, Token-Anzahl, Kosten, Modellversion. Diese Daten sind unschätzbar für Debugging, Kostenoptimierung und späteres Fine-Tuning. Nutzen Sie ein Tool wie LangSmith, Weights & Biases oder ein einfaches strukturiertes Logging.

Für Modelländerungen planen

Modelle verbessern sich und ändern sich. Preise ändern sich. Anbieter deprecaten Versionen. Abstrahieren Sie Ihre LLM-Calls hinter einem Interface, damit Sie Modelle wechseln können, ohne Geschäftslogik umzuschreiben. Testen Sie neue Modelle gegen Ihren Evaluierungsdatensatz vor dem Wechsel.

Einfach starten, Komplexität hinzufügen

Bauen Sie die einfachste mögliche Version zuerst: ein einfacher Prompt mit dem Basismodell, kein RAG, kein Fine-Tuning. Messen Sie die Qualität. Dann fügen Sie RAG hinzu, wenn dem Modell Domänenwissen fehlt. Dann Reranking, wenn die Relevanz schlecht ist. Dann Fine-Tuning, wenn das Verhalten angepasst werden muss. Jede Schicht sollte Ihre Evaluierungsmetriken nachweislich verbessern.

Sicherheit und Datenschutz

Definieren Sie Datenklassifikation vor dem Bauen. Personenbezogene Daten in Prompts? Fordern Sie einen Auftragsverarbeitungsvertrag vom API-Anbieter oder hosten Sie selbst. Nutzereingaben als Trainingsdaten? Die meisten Anbieter bieten Opt-out, aber verifizieren Sie es. Prompt Injection? Implementieren Sie Input-Sanitisierung und Output-Validierung. Das ist nicht optional — das ist Architektur.