Das Problem: Fragmentierte Lieferdaten und langsame Reaktionszeiten
In der österreichischen Logistikbranche ist die First-Response-Time ein kritischer KPI. Kunden erwarten bei Anfragen zu Lieferstatus oder Reklamationen eine Antwort innerhalb weniger Minuten, nicht Stunden. Bei 500 bis 2.000 Mitarbeitern ist die manuelle Bearbeitung durch Back-Office-Teams oft der Flaschenhals. Die Daten liegen verstreut in E-Mails, ERP-Systemen und Tickets. Ein Retrieval-Augmented Generation (RAG) System kann diese Fragmentierung überwinden, indem es eine zentrale Wissensbasis schafft, die auf natürliche Sprache zugreifbar ist. Der Ansatz von Forfis beginnt mit einem Prozess-Audit, um die relevanten Workflows zu identifizieren, bevor eine technische Lösung implementiert wird. Dies stellt sicher, dass die Automatisierung dort ansetzt, wo der größte Hebel liegt.
Technische Architektur: RAG mit pgvector und LLM-APIs
Die Architektur basiert auf drei Schichten. Erstens die Ingest-Pipeline: Dokumente wie Lieferscheine, E-Mails und ERP-Exporte werden in Text umgewandelt, in Chunks von 200-500 Tokens aufgeteilt und in Vektoren konvertiert. Zweitens der Retrieval-Layer: pgvector in PostgreSQL speichert diese Vektoren. Bei einer Anfrage wird die Frage in einen Vektor übersetzt und die ähnlichsten Chunks abgerufen. Drittens der Generative Layer: Ein LLM (z. B. GPT-4 oder Claude) formuliert die Antwort basierend auf dem abgerufenen Kontext. Die Integration in Google Workspace erfolgt über die API, sodass das System E-Mails direkt beantworten kann. Die Architektur ist model-agnostic, was Flexibilität bei der Wahl des LLMs bietet.
Trade-offs: Chunking, Embeddings und Latenz
Die Chunking-Strategie ist entscheidend für die Qualität. Zu kleine Chunks verlieren Kontext, zu große Chunks verwässern die Relevanz. Für Lieferstatus-Updates sind Chunks von 300 Tokens oft optimal, da sie eine vollständige Lieferinformation enthalten. Die Embedding-Modellwahl beeinflusst die Genauigkeit: Modelle wie text-embedding-3-small von OpenAI bieten ein gutes Verhältnis aus Kosten und Qualität. Bei der Datenbankabfrage ist der Index-Typ wichtig: HNSW (Hierarchical Navigable Small World) bietet eine gute Balance zwischen Geschwindigkeit und Genauigkeit. Die Latenz der Vektorsuche liegt bei optimiertem Index unter 50 ms. Die Generierung der Antwort durch das LLM ist der langsamste Teil, mit 1-3 Sekunden je nach Antwortlänge.
Human-in-the-Loop: Eskalationslogik und Qualitätskontrolle
Der Human-in-the-Loop-Ansatz ist bei Forfis Standard. Das System erstellt einen Antwortentwurf, der bei kritischen Fällen (z. B. Reklamationen, Verzögerungen über 48 Stunden) von einem menschlichen Agenten geprüft wird. Dies reduziert das Risiko von Fehlinformationen und hält die Kundenbeziehung aufrecht. Für einfache Statusanfragen kann das System automatisch antworten. Die Eskalationslogik wird über Metriken gesteuert: Wenn die Konfidenz des LLMs unter einem Schwellenwert liegt oder bestimmte Schlüsselwörter (z. B. ‘Beschädigung’, ‘Verlust’) erkannt werden, wird der Fall eskaliert. Dies erfordert eine klare Definition der Eskalationskriterien im Prozess-Audit.
Implementierungszeitplan: 4 Wochen bis zum Pilotbetrieb
Die 4-Wochen-Zeitraum ist realistisch, wenn der Scope klar definiert ist. Woche 1: Prozess-Audit und Datenanalyse. Woche 2: Setup der Infrastruktur (pgvector, API-Verbindungen) und erste Prototypen. Woche 3: Feintuning der Prompts, Test mit realen Daten und Schulung des Teams. Woche 4: Pilotbetrieb mit einem kleinen Nutzerkreis und Auswertung der Metriken. Wichtig ist, dass die Datenbereinigung vorab erfolgt. Wenn die Lieferdaten unvollständig oder inkonsistent sind, verzögert sich das Projekt. Ein fester Scope für den Piloten ist entscheidend für den Erfolg. Die Metriken für den Erfolg sind die First-Response-Time und die Fehlerquote, gemessen vor und nach der Implementierung.
Empfehlung: Start mit einem fokussierten Piloten
Für Unternehmen in der Logistik mit 500-2000 Mitarbeitern in Österreich ist ein RAG-System mit pgvector die wirtschaftlichste Lösung. Es nutzt bestehende Infrastruktur und reduziert die Abhängigkeit von externen Vektor-Datenbanken. Die Integration in Google Workspace stellt sicher, dass das System dort arbeitet, wo die Kommunikation stattfindet. Der Human-in-the-Loop-Ansatz minimiert das Risiko und hält die Qualität hoch. Die 4-Wochen-Zeitraum ist realistisch, wenn der Scope klar definiert ist. Der nächste Schritt ist ein Prozess-Audit, um die relevanten Workflows zu identifizieren und die Datenqualität zu bewerten. Dies ist die Grundlage für eine erfolgreiche Implementierung.
Leave a Reply