Order Intelligence: LLM-Klassifizierung für 40k+ B2B-Aufträge/Tag
Automatische Kategorisierung eingehender B2B-Aufträge mit 94% Genauigkeit, von 11h manueller Arbeit auf 8 Minuten reduziert.
Das Problem
Cipher AI wickelte täglich über 40.000 B2B-Aufträge ab — eingehend über E-Mail, EDI und unstrukturierte PDFs. Drei Vollzeit-Operations-Mitarbeiter verbrachten zusammen 11 Stunden am Tag damit, jeden Auftrag in eines von 47 internen Klassifizierungs-Buckets einzusortieren.
Die Fehlerquote: 4–6%. Ein falsch einsortierter Auftrag verursachte im Durchschnitt €800 Folgekosten — durch Routing-Fehler, verspätete Lieferungen, Reklamationen. Hochgerechnet waren das fünfstellige Kosten pro Monat, nur weil das manuelle System an Komplexität scheiterte.
Der Geschäftsführer wollte ML-basierte Klassifikation. Die ersten Angebote aus der Beraterwelt: sechs Monate Discovery, zwölf Monate Training-Pipeline, ein Daten-Science-Team von außen. Zu viel Zeit, zu viel Geld, zu wenig Gewissheit.
Discovery: Warum klassisches ML hier falsch war
In der ersten Woche haben wir ~500 historische Aufträge pro Bucket analysiert. Ergebnis:
- Die Klassifikationsmuster waren oft schon im Text erkennbar — kein hochspezialisiertes Feature-Engineering nötig
- Viele Edge-Cases hatten zu wenig Beispiele für saubere Supervised-Learning-Modelle
- Die Kategorien änderten sich alle paar Wochen — ein trainiertes Modell wäre schnell veraltet
Entscheidung: Retrieval-Augmented Classification statt klassischer ML-Pipeline. Kein Fine-Tuning, keine Labeled-Data-Kampagne, kein Modell-Redeployment-Theater.
Architektur
Email / EDI / PDF Input
↓
FastAPI Queue (async)
↓
Embedding (pgvector in Postgres)
↓
Top-5 Similar Orders → Few-Shot Context
↓
Claude Sonnet (structured JSON output)
↓
Confidence Router:
• > 85% → auto-assign
• 70–85% → human review queue
• < 70% → flag + retrain-signal
↓
Next.js Ops Dashboard + Metrics
Alles läuft in einer einzigen Postgres-Instance — keine separate Vector-DB, keine zusätzliche Service-Ebene. pgvector als Extension reicht für Retrieval bei dieser Größenordnung völlig.
"Das System macht was die Berater uns für das Zehnfache versprochen hatten. Ohne Team von außen, ohne sechs Monate Discovery. In sieben Wochen." — Operations-Leitung, Cipher AI
Build: Sieben Wochen, drei Sprints
Woche 1–2 — Discovery & MVP Pipeline Wir haben die ersten 500 Orders embedden und in pgvector geladen. Manuelle Tests: wie gut findet der Nearest-Neighbor-Ansatz die richtige Kategorie? Ergebnis: 87% Accuracy mit Pure-Retrieval, ohne LLM. Das war der Beweis dass der Ansatz funktioniert.
Woche 3–5 — Production-Pipeline & Dashboard FastAPI-Queue mit asynchronem Worker-Pool. Claude Sonnet als Classifier mit strukturiertem JSON-Output (Tool Use, kein Text-Parsing). Next.js Ops-Dashboard mit Live-Metriken, Confidence-Verteilung, Override-Historie. Die Operations-Mitarbeiter konnten ab Tag 20 mitklicken.
Woche 6–7 — Confidence Routing & Go-Live Der Confidence-Router war der kritische Teil: nicht jede Klassifikation durfte automatisch. Die letzten beiden Wochen: Schwellwert-Tuning mit echten Daten, Human-in-the-Loop UI für den Review-Bucket, Monitoring mit Alerts bei Drift.
Ergebnis nach 3 Monaten Produktion
- 94% Genauigkeit — vergleichbar mit dem manuellen Benchmark (94–96%)
- 98% Reduktion der manuellen Arbeit — 11 h/Tag auf 8 Min
- 40k Aufträge/Tag stabil — keine Queue-Backlogs
- ROI nach 4 Monaten — die drei Operations-Mitarbeiter übernahmen hochwertigere Arbeit
Was wir gelernt haben
Retrieval-first schlägt Fine-Tuning fast immer bei domänenspezifischen Klassifikationsaufgaben. Weniger Infrastruktur, schnellere Iteration, jede neue Kategorie funktioniert ohne Retraining. Fine-Tuning wäre nur dann sinnvoll gewesen, wenn Latenz ein harter Constraint wäre — ist hier nicht der Fall (Batch-Processing, Sekunden-Toleranz).
Confidence-Routing ist wichtiger als das Modell selbst. Ein 94%-genaues Modell ohne Routing wäre unbrauchbar — die 6% Fehler bei 40k/Tag = 2.400 falsche Entscheidungen am Tag. Mit Routing: nur die unsicheren 10% landen beim Menschen, die anderen 90% laufen automatisch.
Ops-Dashboard war kein Nice-to-have. Die Akzeptanz im Team hing komplett davon ab, dass sie die KI-Entscheidungen nachvollziehen konnten. Ohne Dashboard hätten sie dem System nicht vertraut.
Andere Projekte