AI Engineering Academy · Lektion

Die Produktionsarchitektur entwerfen

Lektion 1 von 413 Schritte

Die Produktionsarchitektur entwerfen ist eine kostenlose AI Engineering Academy-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des AI Engineering Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der AI Engineering Academy-Kurs umfasst insgesamt 4 Lektionen.

Ein Abschlussprojekt auswählen

Das Abschlussprojekt führt alles aus dem Lernpfad zusammen: RAG, Agenten, Streaming, Caching, Observability und Sicherheit. Ein gutes Abschlussprojekt ist inhaltlich komplex — es erfordert mindestens drei unterschiedliche KI-Komponenten — und zugleich so begrenzt, dass es innerhalb weniger Tage statt Monaten ausgeliefert werden kann. Klassische Beispiele sind ein produktionsreifer Dokumente-Frage-und-Antwort-Assistent, ein autonomer Rechercheagent mit menschlicher Aufsicht oder eine Pipeline zur Extraktion von Unternehmensdaten.

Systemkomponenten identifizieren

Beginnen Sie damit, die einzelnen Komponenten aufzulisten, die Ihr System benötigt. Ein typisches KI-Engineering-Projekt für den Produktionseinsatz umfasst: eine Ingestion-Schicht (Dokumente laden, in Chunks aufteilen, Embeddings erzeugen, im Vektorspeicher indizieren), eine Retrieval-Schicht (hybride Suche, Re-Ranking), eine Agentenschicht (Function Calling, Tool-Ausführung), eine API-Schicht (FastAPI-Backend, Streaming-Endpunkte) und eine Observability-Schicht (Tracing, Metriken, Alarme). Skizzieren Sie den Datenfluss zwischen den Komponenten, bevor Sie Code schreiben.

# Component inventory for a Document QA Assistant:
COMPONENTS = [
    'document_ingestion',   # PDF/Word -> chunks -> embeddings -> pgvector
    'hybrid_retriever',     # BM25 + dense + RRF
    'reranker',             # Cohere rerank
    'qa_agent',             # GPT-4o with RAG + function calling
    'semantic_cache',       # Redis + embedding similarity
    'streaming_api',        # FastAPI StreamingResponse
    'tracing',              # LangSmith or Langfuse
    'prompt_injection_filter', # Input sanitization
    'eval_pipeline',        # Automated quality scoring
]

Den passenden Stack auswählen

Wählen Sie Technologien anhand der Vertrautheit Ihres Teams und der tatsächlichen Anforderungen des Systems aus, nicht aufgrund ihrer Neuartigkeit. Ein sinnvoller Standard-Stack ist: FastAPI für die API-Schicht, pgvector für die Vektorspeicherung (nutzt die vorhandene PostgreSQL-Infrastruktur weiter), LangChain LCEL für die Zusammensetzung von Pipelines, Redis für semantisches Caching und den Zustand der Rate-Limits, LangSmith für Tracing und PostgreSQL für Benutzerdaten und Evaluationsergebnisse. Fügen Sie Komponenten nur hinzu, wenn einfachere Optionen die Anforderungen nicht erfüllen.

# Technology decisions and their rationale
STACK = {
    'api':           ('FastAPI',    'Async support, OpenAPI docs, streaming easy'),
    'vector_store':  ('pgvector',   'Already on PostgreSQL, no extra infra'),
    'llm_primary':   ('gpt-4o',     'Best quality for the use case'),
    'llm_fallback':  ('claude-3.5', 'Different provider for resilience'),
    'cache':         ('Redis',      'Sub-ms lookup, TTL support built-in'),
    'tracing':       ('LangSmith',  'Native LangChain integration'),
    'embedding':     ('text-embedding-3-small', 'Good quality, low cost'),
    'reranker':      ('Cohere',     'Best-in-class rerank API'),
}

Das Architekturdiagramm erstellen

Dokumentieren Sie die Systemarchitektur als Datenflussdiagramm, das jede Komponente, die zwischen ihnen fließenden Daten und die Flussrichtung zeigt. Nehmen Sie sowohl den Ingestion-Pfad (offline: Dokumente → Chunks → Embeddings → Vektorspeicher) als auch den Abfragepfad auf (online: Benutzerabfrage → Cache-Prüfung → Retrieval → Reranking → LLM → Streaming-Antwort). Dieses Diagramm dient Ihnen bei der Implementierung als Orientierung und hilft neuen Teammitgliedern, das System sofort zu verstehen.

# Data flow (ASCII art):
#
# INGESTION PATH (offline):
# Documents --> Loader --> Chunker --> Embedder --> pgvector
#                                             |
#                                         BM25 index
#
# QUERY PATH (online):
# User Query
#    |-> Semantic Cache (hit: return) -> miss:
#    |-> Hybrid Retriever (BM25 + dense)
#    |-> Cohere Reranker
#    |-> LangChain LCEL Chain
#    |-> GPT-4o (streaming) --> FastAPI StreamingResponse
#    |-> LangSmith (trace every step)

API-Verträge frühzeitig definieren

Definieren Sie Ihre API-Endpunkte sowie deren Request- und Response-Schemas in FastAPI, bevor Sie die Backend-Logik implementieren. Dadurch entsteht ein Vertrag zwischen der API und allen Frontend-Clients, und eine parallele Entwicklung wird möglich. Dokumentieren Sie jeden Endpunkt mit OpenAPI-Beschreibungen. Definieren Sie mindestens Endpunkte für: Dokumenten-Ingestion, Chat/Abfragen, Gesprächsverlauf, Evaluationsergebnisse und Systemstatus.

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(title='Document QA Assistant', version='1.0')

class QueryRequest(BaseModel):
    question: str
    conversation_id: str | None = None
    max_chunks: int = 5
    stream: bool = True

class QueryResponse(BaseModel):
    answer: str
    sources: list
    cached: bool
    latency_ms: int
    trace_id: str

@app.post('/query', response_model=QueryResponse)
async def query_endpoint(request: QueryRequest):
    pass  # implementation next lesson

Kosten schätzen und budgetieren

Schätzen Sie die monatlichen API-Kosten Ihres Systems, bevor Sie auch nur eine Zeile Backend-Code schreiben. Berechnen Sie: erwartete täglich aktive Benutzer × Abfragen pro Benutzer × durchschnittliche Tokenanzahl pro Abfrage. Bei einem System mit 100 DAU, 10 Abfragen pro Tag und 3.000 Token pro Abfrage zu GPT-4o-Preisen sind das 3 Millionen Token pro Tag — ungefähr 45 $ pro Tag oder 1.350 $ pro Monat. Diese Schätzung zeigt Ihnen, ob das System wirtschaftlich tragfähig ist und welche Optimierungen (Caching, Model Routing) sich lohnen.

# Cost estimation model
DAU = 100           # daily active users
QPD = 10            # queries per user per day
TOKENS_PER_QUERY = {
    'prompt_tokens': 2000,  # system + context + question
    'completion_tokens': 500
}

PRICE_GPT4O_INPUT = 2.50 / 1_000_000   # per token
PRICE_GPT4O_OUTPUT = 10.00 / 1_000_000  # per token

daily_cost = DAU * QPD * (
    TOKENS_PER_QUERY['prompt_tokens'] * PRICE_GPT4O_INPUT +
    TOKENS_PER_QUERY['completion_tokens'] * PRICE_GPT4O_OUTPUT
)
print(f'Daily: ${daily_cost:.2f}, Monthly: ${daily_cost * 30:.2f}')

Die Ingestion-Pipeline planen

Entwerfen Sie die Ingestion-Pipeline als Offline-Batch-Prozess, der bei Bedarf oder nach einem Zeitplan ausgeführt wird. Legen Sie fest, welche Dokumenttypen Sie unterstützen (PDF, DOCX, HTML, Nur-Text), welche Chunking-Strategie und welches Embedding-Modell Sie verwenden und welche Metadatenfelder zusammen mit jedem Vektor gespeichert werden. Metadaten sind für gefiltertes Retrieval entscheidend — ohne sie können Sie die Suche nicht auf Dokumente aus einem bestimmten Zeitraum, von einem bestimmten Autor oder aus einer bestimmten Kategorie beschränken.

from dataclasses import dataclass
from typing import Optional

@dataclass
class ChunkMetadata:
    doc_id: str
    source_file: str
    page_number: Optional[int]
    section_title: Optional[str]
    created_at: str
    author: Optional[str]
    doc_type: str  # 'pdf', 'docx', 'html'

# Ingestion config
INGESTION_CONFIG = {
    'chunk_size': 800,
    'chunk_overlap': 100,
    'embedding_model': 'text-embedding-3-small',
    'embedding_dimensions': 1536,
    'batch_size': 100,  # chunks per embedding API call
}

Entscheidungen zur Sicherheitsarchitektur

Treffen Sie Sicherheitsentscheidungen frühzeitig, statt sie später nachträglich einzubauen. Legen Sie fest: wie sich Benutzer authentifizieren (JWT, API-Schlüssel), welche Daten pro Benutzer abgerufen werden dürfen (Row-Level Security in pgvector-Abfragen), wie Prompt Injection erkannt wird, welche Ausgabescans angewendet werden und für welche Aktionen eine Bestätigung mit mehreren Faktoren erforderlich ist. Jede Entscheidung hat Auswirkungen auf die Performance, die sich auf die Architekturentscheidungen im gesamten System auswirken.

SECURITY_DECISIONS = {
    'auth': 'JWT with 24h expiry',
    'data_isolation': 'tenant_id column in all vector metadata, filter on every query',
    'injection_detection': 'rule-based pre-filter + LLM secondary check for complex inputs',
    'output_scanning': 'check for PII, system prompt leakage patterns',
    'destructive_actions': 'require confirmation token for delete operations',
    'rate_limiting': '20 queries/minute per user, 429 with Retry-After header',
    'key_storage': 'AWS Secrets Manager, rotated every 90 days'
}

Erfolgsmetriken definieren

Definieren Sie, woran Sie den Erfolg Ihres Systems messen, bevor Sie es entwickeln. Konkrete, messbare Erfolgskriterien halten die Entwicklung fokussiert und liefern klare Kriterien für eine Bereitstellungsentscheidung. Nehmen Sie Metriken für Folgendes auf: Qualität (Evaluationswert auf dem Testdatensatz), Latenz (p95-TTFT und Gesamtlatenz), Kosten (Zielkosten pro Abfrage) und Zuverlässigkeit (Uptime-SLA). Veröffentlichen Sie diese im README des Projekts, damit alle Mitwirkenden dasselbe Ziel verfolgen.

SUCCESS_METRICS = {
    # Quality
    'min_correctness_score': 4.0,       # out of 5, LLM-as-judge
    'min_retrieval_hit_rate': 0.85,     # top-5 chunk contains answer
    # Latency
    'p95_ttft_ms': 800,                 # time to first token
    'p95_total_latency_ms': 8000,       # full response
    # Cost
    'max_cost_per_query_usd': 0.05,     # $0.05 per Q&A
    # Reliability
    'target_uptime': 0.999,             # 99.9%
    'cache_hit_rate_target': 0.25,      # 25% queries served from cache
}

Architekturkompromisse dokumentieren

Jede Architekturentscheidung bringt Kompromisse mit sich. Dokumentieren Sie diese ausdrücklich in einem Architecture Decision Record (ADR): welche Entscheidung getroffen wurde, welche Alternativen geprüft wurden und warum diese Option gewählt wurde. Zum Beispiel: „Wir haben pgvector statt Pinecone gewählt, weil wir PostgreSQL bereits betreiben und dadurch den Betriebsaufwand reduzieren. Kompromiss: Die maximale Skalierung ist ohne Sharding auf etwa 10 Mio. Vektoren begrenzt.“ Künftige Teammitglieder werden Ihnen für diese Transparenz dankbar sein.

# Architecture Decision Records (ADRs):
#
# ADR-001: Use pgvector for vector storage
# Decision: pgvector in existing PostgreSQL
# Alternatives: Pinecone, Weaviate, Qdrant
# Reason: No new infra, row-level security native, familiar operations
# Trade-offs: Limited to ~5M vectors before performance degrades
#
# ADR-002: GPT-4o as primary model
# Decision: gpt-4o for all user-facing queries
# Alternatives: gpt-4o-mini (cheaper), Claude (alternative)
# Reason: Highest quality for use case, Claude as fallback
# Trade-offs: $0.04/query vs $0.002 for gpt-4o-mini

Die Deployment-Topologie skizzieren

Legen Sie fest, wie Ihr System bereitgestellt werden soll, bevor Sie Infrastrukturcode schreiben. Ordnen Sie jede Komponente einer Deployment-Einheit zu: das FastAPI-Backend als Docker-Container, die Ingestion-Pipeline als separaten Worker-Service, pgvector als verwaltete PostgreSQL-Instanz und Redis als verwalteten Cache. Geben Sie an, welche Komponenten zustandslos sind (horizontal skaliert werden können) und welche zustandsbehaftet sind (sorgfältige Skalierungsstrategien erfordern). Ein Deployment-Diagramm erspart Ihnen später viele Stunden Nacharbeit.

# Deployment topology:
#
# Internet -> Load Balancer (AWS ALB)
#                |
#            FastAPI API  (stateless, 2-4 containers, auto-scale)
#                |
#         +------+------+
#         |             |
#    pgvector        Redis Cache
#  (AWS RDS Postgres) (Elasticache)
#         |
#    Ingestion Worker  (separate container, manual trigger)
#         |
#    LangSmith (external SaaS, traces only)
#
# All containers in same VPC, no public access to DB/cache

Kurze Überprüfung

Testen Sie Ihr Verständnis des Entwurfs von Produktionsarchitekturen für KI-Systeme.

Beantworte es in der interaktiven Lektion

Zusammenfassung der Lektion

In dieser Lektion haben Sie gelernt: Komponentenübersichten und Datenflussdiagramme schaffen eine gemeinsame architektonische Vorstellung, bevor die Programmierung beginnt; frühzeitig definierte API-Verträge ermöglichen parallele Entwicklung und machen Anforderungen explizit; und im Voraus definierte Erfolgsmetriken sorgen dafür, dass das Team bei den Zielen für Qualität, Latenz, Kosten und Zuverlässigkeit ausgerichtet bleibt. Als Nächstes implementieren wir die zentralen RAG- und Agentenfunktionen.

Kostenlos starten

Lerne Python mit einem KI-Tutor — kostenlos

Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.

Kurse: 30
Lektionen: 120

Kostenlos lernen Den vollständigen Kurs ansehen

Häufig gestellte Fragen

Ist die Lektion „Die Produktionsarchitektur entwerfen“ kostenlos?

Ja — der vollständige Text von „Die Produktionsarchitektur entwerfen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des AI Engineering Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der AI Engineering Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Die Produktionsarchitektur entwerfen“?

Wählen Sie ein Abschlussprojekt, skizzieren Sie die vollständige Architektur einschließlich RAG-Pipeline, Agentenebene, Caching, Observability und API und dokumentieren Sie anschließend die Designent… Du übst AI Engineering Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um AI Engineering Academy zu starten?

Keine Vorkenntnisse erforderlich. AI Engineering Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.

Wie lange dauert die Lektion „Die Produktionsarchitektur entwerfen“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser AI Engineering Academy-Lektion Code schreiben und ausführen?

Ja. Jede AI Engineering Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

Die Produktionsarchitektur entwerfen
Zentrale RAG- und Agentenfunktionen implementieren
Härtung: Sicherheit, Caching und Zuverlässigkeit
Evaluation, Deployment und Retrospektive

← Zurück zu AI Engineering Academy