Der KI-Stack, den wir in Produktion nutzen: Modelle & Pipelines

Die KI-Tooling-Landschaft Anfang 2026 ist überwältigend. Jede Woche bringt ein neues Framework, ein neues Modell, eine neue Vektordatenbank, die behauptet, die schnellste zu sein, und eine neue Orchestrierungs-Ebene, die verspricht, alles zu vereinfachen. Für Engineering-Leader, die versuchen, Produktions-KI-Systeme zu bauen, war das Noise-to-Signal-Verhältnis nie schlechter. Wir wissen das, weil wir selbst darin navigieren – KI-gestützte Produkte und Agentensysteme für Kunden über Fintech, Energie und Regierung versenden, während der Boden sich jedes Quartal unter uns verschiebt.

Dieser Artikel ist unser Versuch, durch diesen Lärm zu schneiden. Wir teilen die spezifischen Tools, Modelle und architektonischen Entscheidungen, die unseren Produktions-KI-Stack ausmachen – was wir verwenden, warum wir es gewählt haben und was wir bewusst gewählt haben, nicht zu verwenden. Dies ist kein theoretisches Framework oder ein Vendor-Vergleichs-Chart. Es ist der Stack, der heute in Produktion läuft, echte Nutzer bedient, echte Edge-Cases handhabt und echtes Geld kostet. Wir teilen es, weil Transparenz Vertrauen aufbaut und weil wir wünschen, mehr Teams würden dasselbe tun. Wenn Vendors Benchmarks veröffentlichen, optimieren sie für die Demo. Wenn Praktiker ihre Stacks teilen, optimieren sie für Ehrlichkeit.

Die Modell-Ebene: Ihre LLMs wählen

Wir betreiben eine Multi-Modell-Strategie – nicht weil es trendy ist, sondern weil kein einzelnes Modell die richtige Wahl für jede Aufgabe in einem Produktionssystem ist. Die Modellstrategie falsch zu machen, bedeutet entweder Überbezahlen für Capabilities, die Sie nicht benötigen, oder unter-liefern bei Qualität, die Nutzer erwarten.

Claude: Unser primäres Reasoning-Modell

Anthropics Claude ist unser primäres Modell für komplexes Reasoning, Long-Context-Analyse und nuanciertes Instruction-Following. Wir verwenden es für Agenten-Orchestrierungs-Entscheidungen, Dokumentenanalyse über 50-100-seitige Verträge, Code-Generierung und -Review und jede Aufgabe, wo präzises Befolgen detaillierter System-Prompts wichtiger ist als rohe Geschwindigkeit. Claudes Extended-Thinking-Capability ist besonders wertvoll für Agentensysteme – wenn ein Agent einen mehrstufigen Workflow planen muss, ist der Qualitätsunterschied versus andere Modelle messbar. Wir verlassen uns auch auf Claudes Structured-Output-Zuverlässigkeit. Produktionssysteme können kein malformed JSON tolerieren, und für regulierte Branchen ist diese Zuverlässigkeit eine harte Anforderung.

GPT-4o und Open-Source-Modelle

OpenAIs GPT-4o dient als unser Fallback und unsere Wahl für multimodale Aufgaben mit Bildanalyse und komplexen Function-Calling-Mustern. Wir pflegen es nicht als Hedge gegen Vendor-Lock-in – obwohl das ein Vorteil ist – sondern weil bestimmte Aufgaben echt besser darauf performen. Vorzutäuschen, ein Modell gewinnt überall, ist Ideologie, nicht Engineering.

Für kostenempfindliche, hochvolumige Aufgaben deployen wir Open-Source-Modelle – primär Metas Llama 3 und Mistral. Diese handhaben Klassifikation, Entity-Extraction und einfache Zusammenfassung, wo Frontier-Modell-Kosten nicht zu rechtfertigen sind. Eine Klassifikationsaufgabe, die 50.000 Mal pro Tag läuft, kostet ungefähr 100 $ pro Monat auf Llama 3 versus 3.000 $ auf Claude. Der Qualitätsunterschied für binäre Klassifikation ist vernachlässigbar; der Kostenunterschied ist es nicht. Wir self-hosten mit vLLM für Inference-Serving, was uns Kontrolle über Latenz, Verfügbarkeit und Daten-Residency gibt.

Orchestrierung: Agenten zusammen verdrahten

Die Orchestrierungs-Ebene ist das, was individuelle Modell-Aufrufe in kohärente Agenten-Workflows verwandelt. Sie managed State, routet Entscheidungen, handhabt Tool-Aufrufe und erholt sich von Fehlern. Diese Ebene richtig zu machen, ist der Unterschied zwischen einer Demo, die beeindruckt, und einem System, das um 3 Uhr morgens an einem Samstag funktioniert.

LangGraph für Agenten-Workflows

Wir verwenden LangGraph als unsere primäre Orchestrierungs-Ebene. Es modelliert Agenten-Workflows als gerichtete Graphen, wo Nodes Aktionen repräsentieren und Edges bedingte Übergänge. Der Schlüsselvorteil ist Checkpointing – LangGraph persistiert den vollen Agenten-State bei jedem Node, ermöglicht Replay fehlgeschlagener Ausführungen vom exakten Fehlerpunkt, Human-in-the-Loop-Approval bei jedem Schritt und vollständige Audit-Trails für Compliance.

Custom-Orchestrierung für kritische Pfade

Für produktionskritische Pfade – Payment-Processing-Agenten, sicherheitssensitive Workflows – verwenden wir Custom-TypeScript-State-Machines statt eines Frameworks. Frameworks fügen Abstraktions-Ebenen hinzu, und Abstraktions-Ebenen fügen Fehlermodi hinzu. Wenn ein Workflow Finanztransaktionen verarbeitet, sollte jede Zeile Orchestrierungs-Code explizit, testbar und frei von Third-Party-Dependency-Updates sein, die Verhalten ändern könnten. Es ist mehr Code als LangGraph, aber der Trade-off ist es wert, wo Zuverlässigkeit Entwicklungsgeschwindigkeit trumpft.

Vektordatenbanken und Embeddings

Wir verwenden drei Vektordatenbanken für drei Deployment-Kontexte. Pinecone ist unser Default für cloud-native Deployments – managed, skalierbar, mit namespace-basierter Tenant-Isolation. pgvector ist unsere Wahl, wenn die Anwendung bereits auf PostgreSQL läuft, hält Vektoren neben relationalen Daten und eliminiert eine separate Datenbank zum Betreiben. Weaviate wird für on-premise Kunden deployed – Regierungsbehörden und Finanzinstitutionen mit strikter Daten-Residency – läuft containerisiert innerhalb ihrer Infrastruktur mit nativer Hybrid-Suche.

Für Embeddings ist OpenAIs text-embedding-3-large unser Default für englische Anwendungen. Für multilinguale Arbeit – ein bedeutender Teil unserer Projekte über Lateinamerika und Europa – übertrifft Coheres embed-multilingual-v3.0 Alternativen bei Cross-Language-Retrieval. Für on-premise Deployments verwenden wir Open-Source-Modelle wie BGE-large und E5-mistral, laufend auf denselben GPU-Instanzen wie unsere LLMs, um die gesamte Pipeline self-contained zu halten.

RAG-Pipeline: Von Dokumenten zu Antworten

Die Qualität eines RAG-Systems hängt weit mehr von der Retrieval-Pipeline ab als vom Generierungs-Modell – ein Frontier-Modell mit schlechtem Kontext produziert schlechte Antworten genauso zuversichtlich wie es gute produziert.

Dokumenttyp-bewusstes Chunking

Wir haben universelle Chunking-Strategien früh aufgegeben. Fixed-Size-Chunks mit Overlap funktionieren für Artikel und Reports, aber schlachten Verträge, Spezifikationen und Finanzstatements. Unser Ansatz: Rechtsverträge werden nach Klausel gechunked, technische Docs nach Sektion, Finanzberichte nach Tabelle und Narrativ separat. Wir pflegen auch Parent-Child-Beziehungen zwischen Chunks, sodass das System umgebenden Kontext ziehen kann, wenn ein Fragment abgerufen wird – eliminiert den häufigsten RAG-Fehlermodus, ein relevantes Fragment zurückzugeben, dem der Kontext fehlt, um es korrekt zu interpretieren.

Reranking und hybride Suche

Reranking ist konsistent die einzelne größte Qualitätsverbesserung in unseren RAG-Pipelines. Wir verwenden Cohere Rerank für managed Deployments und Cross-Encoder-Modelle für on-premise Setups. Reranking zu einer Baseline-Vector-Search-Pipeline hinzuzufügen, verbessert Answer-Accuracy um 15-25% über Dokumenttypen. Es fügt 100-200ms Latenz hinzu, aber die Qualitätsverbesserung macht es non-negotiable.

Wir paaren dies mit hybrider Suche – kombinieren Vector-Similarity mit BM25-Keyword-Matching – für jedes Produktionssystem. Pure Vector Search verpasst Exact-Match-Abfragen für Vertragsnummern, Produkt-SKUs und Regulations-Identifiers. Die Implementation fügt Komplexität hinzu, aber ein offensichtlich relevantes Dokument zu verpassen, weil es nicht semantisch nah an der Abfrage ist, ist zu schädlich zu akzeptieren.

Evaluation und Monitoring

Ein KI-System ohne Evaluation ist eine Haftung. Jedes Produktionssystem bekommt eine Custom-Evaluations-Suite: Extraktions-Accuracy, Vollständigkeit und Hallucination-Rate für Dokumentenverarbeitung; Task-Completion-Rate, Relevanz und Ton-Adherence für conversational Agenten. Off-the-Shelf-Tools geben Ihnen generische Metriken. Custom-Frameworks geben Ihnen die Metriken, die tatsächlich mit User-Satisfaction korrelieren.

Für subjektive Qualitätsdimensionen verwenden wir ein LLM-as-Judge-Muster – Claude als Judge-Modell, bewertet Outputs auf einer 1-5-Skala mit obligatorischem Reasoning für jeden Score. Es ist kein Ersatz für menschliche Evaluation, aber ein skalierbarer Filter, der Regressionen fängt und Borderline-Fälle markiert. Für kritische Anwendungen in Legal- und Financial-Domänen reviewen Domain-Experten wöchentlich eine statistische Stichprobe von Outputs und liefern die Ground Truth für Kalibrierung automatisierter Evaluation.

Für Observability betreiben wir LangSmith, das jeden LLM-Aufruf, Tool-Invocation und Agenten-Entscheidung als Trace erfasst. Custom-Grafana-Dashboards tracken, was Leadership interessiert: Kosten pro Tag nach Modell und Klient, Latenz-Perzentile, Task-Completion-Raten und Qualitäts-Scores. Jeder Dollar KI-Inferenz ist einem spezifischen Klienten, Projekt und Use Case zugeordnet – nicht als finanzielle Hygiene, sondern um Optimierungs-Entscheidungen zu treiben.

Infrastruktur und das API-Gateway-Muster

Agenten-Services sind mit Docker auf Kubernetes containerisiert, Auto-Scaling basierend auf Queue-Depth statt CPU-Utilization – weil KI-Workloads I/O-bound sind und auf Modell-APIs warten, nicht CPU-bound. Für self-hosted Inference läuft vLLM auf GPU-Instanzen mit dynamischem Batching, skaliert zu null während Off-Hours. Ein einzelnes API-Gateway handhabt Authentifizierung, Rate-Limiting, Retry-Logik, Modell-Routing und Cost-Tracking für jeden ausgehenden LLM-Request. Dieses Gateway ist der Chokepoint, durch den alle KI-Ausgaben fließen, was es zum natürlichen Ort macht, um Budgets durchzusetzen und Telemetrie zu sammeln.

Was wir gewählt haben, nicht zu verwenden (und warum)

Die Tools, die Sie ablehnen, offenbaren genauso viel über Ihre Engineering-Philosophie wie die Tools, die Sie adoptieren. Hier sind die bemerkenswerten Technologien, die wir evaluiert und bewusst abgelehnt haben.

• CrewAI – Zu opinionated über Agenten-Interaktions-Muster für Produktion. LangGraph bietet dieselben Multi-Agenten-Capabilities mit expliziter Kontrolle über jeden Übergang.
• Chroma – Solid für Prototyping, aber operative Reife für Produktions-Workloads (Connection Pooling, HA, Backups) erfüllte unsere Standards nicht. Wir revisiten periodisch.
• Haystack – Saubere Pipeline-Abstraktion, aber signifikant kleineres Ökosystem und Community-Support als LangChain/LangGraph.
• Fine-tuned Reasoning-Modelle – Ergebnisse konsistent schlechter als gut-promptete Frontier-Modelle, mit hoher Maintenance-Bürde. Wir fine-tunen Embedding-Modelle für domänenspezifisches Retrieval, wo der ROI klar ist.
• AutoGen – Unzureichende Produktions-Härtung. Konversations-basierte Agenten-Interaktion machte Debugging schwierig, und kein persistentes Checkpointing war ein Dealbreaker für Enterprise-Workflows.

Wie unser Stack sich über 18 Monate entwickelte

Mitte 2024 liefen wir GPT-4 als unser einziges Modell, rohe LangChain-Chains für Orchestrierung, Chroma für Vektor-Storage und basic Logging. Das System funktionierte für Demos, aber kollabierte unter Produktionslast. Bis Ende 2024 hatte Claude 3.5 Sonnet GPT-4 als unser primäres Modell ersetzt, Pinecone und pgvector hatten Chroma ersetzt, und LangGraph hatte LangChain-Chains ersetzt – verbesserte sofort Debugging und Testing.

Durch 2025 fügten wir Cohere Rerank hinzu (unsere größte einzelne Qualitätsverbesserung), bauten Custom-Evaluations-Frameworks, deployten LangSmith und führten das API-Gateway-Muster ein. In 2026 verlagerte sich der Fokus auf Reife: Custom-Orchestrierung für kritische Pfade, Human-Evaluations-Loops, self-hosted Modelle für datensensitive Klienten und LLM-as-Judge-Pipelines. Der Stack ist komplexer als vor 18 Monaten, aber jede Komponente verdient ihren Platz durch Lösen eines Problems, das wir tatsächlich hatten – nicht eines, das wir uns vorstellten.

Prinzipien hinter unseren Wahlen

• Verwenden Sie das richtige Modell für jede Aufgabe, nicht das beste Modell für jede Aufgabe. Modell-Cascading ist nicht nur Kostenoptimierung – es ist ein architektonisches Prinzip.
• Besitzen Sie Ihren kritischen Pfad. Frameworks sind exzellent für nicht-kritische Workflows, aber produktionskritischer Code sollte explizit und frei von Upstream-Dependency-Änderungen sein.
• Messen Sie, bevor Sie optimieren. Jede Optimierung, die wir gemacht haben, wurde durch gemessene Qualitätslücken in Produktion getrieben, nicht theoretische Bedenken.
• Operative Einfachheit potenziert sich. Ein etwas weniger fähiges Tool, das Ihr Team zuversichtlich betreiben kann, schlägt ein überlegenes Tool, das spezialisierte Expertise erfordert.
• Transparenz ist ein Feature. Wenn Klienten fragen, welche Modelle wir verwenden und wie wir Qualität evaluieren, antworten wir mit Spezifika.

Unser Stack wird sich weiter entwickeln – die KI-Tooling-Landschaft bewegt sich zu schnell, als dass jede Architektur permanent sein könnte. Aber die Prinzipien sind stabil: Messen Sie alles, besitzen Sie Ihre kritischen Pfade, verwenden Sie das richtige Tool für jeden Job und seien Sie ehrlich über das, was funktioniert. Wenn Sie Produktions-KI-Systeme bauen und Notizen vergleichen möchten, oder wenn Sie ein Team benötigen, das diese Wahlen bereits navigiert hat, würden wir das Gespräch begrüßen. Erkunden Sie unsere KI- und Machine-Learning-Services unter /services/ai-development.