Veröffentlicht am 2 November 2026
Dispositionsteams in Logistik- und Frachtunternehmen sitzen auf einer enormen Menge schriftlichen Wissens, das fast nie genau dann konsultiert wird, wenn es wirklich gebraucht wird: Spediteurverträge mit spezifischen Bedingungen zu Nebenleistungen, Compliance-Handbücher zu Gefahrgut- und grenzüberschreitenden Anforderungen, Wartezeit- und Standgeldrichtlinien sowie Versicherungszertifikate mit Deckungssummen und Ausschlüssen, die auf Seite zwölf versteckt sind. Wenn ein Disponent eine Antwort braucht — darf dieser Carrier diese Fracht rechtlich über diese Grenze transportieren, wie groß ist unser Risiko, wenn sich diese Sendung um vier Stunden verspätet — lautet die ehrliche Antwort heute meist: „Frag jemanden, der schon länger hier ist“ oder „wühl dich durch ein gemeinsames Laufwerk.“ Retrieval-Augmented Generation (RAG) ist für dieses Problem ein sinnvoller Ansatz, aber es lohnt sich, genau zu sagen, was es hier gut kann und wo echte Engineering-Arbeit nötig ist, nicht bloß ein Chatbot-Overlay.
Warum dies ein RAG-Problem und kein Suchproblem ist
Logistikteams haben bereits Suchwerkzeuge — ein Dokumentenmanagementsystem, ein gemeinsames Laufwerk mit passabler Ordnerstruktur, vielleicht sogar Volltextsuche in Verträgen. Was Suche liefert, ist eine Liste von Dokumenten, in denen deine Stichwörter vorkommen. Was ein Disponent tatsächlich braucht, ist eine Antwort: „Erlaubt der aktuelle Vertrag dieses Carriers temperaturgeführte Transporte“, nicht „hier sind vierzehn PDFs, in denen Kühlung erwähnt wird.“
RAG schließt diese Lücke, indem es die konkret relevanten Passagen aus Spediteurverträgen, Compliance-Handbüchern und Richtliniendokumenten abruft und ein Sprachmodell diese Passagen dann mit Quellenangabe zu einer direkten Antwort verdichten lässt. Gut umgesetzt bekommt ein Disponent in Sekunden eine präzise Antwort mit einem Link zur exakten Klausel, aus der sie stammt, statt zu raten oder jemand anderen aus dem Tagesgeschäft zu reißen, nur um es herauszufinden.
Was Spediteur- und Compliance-Dokumente schwer auffindbar macht
Hier liefern die meisten RAG-Implementierungen in der Logistik zu wenig, und fast immer liegt das an der Dokumentenstruktur und nicht am Modell.
- Verträge verweisen auf andere Verträge. Der Gebührenkatalog für Nebenleistungen in einem Spediteurvertrag steht oft in einem nachträglichen Anhang und nicht im Basisdokument, und eine naive Chunking-Strategie, die Dokumente in feste Blöcke aufteilt, trennt eine Klausel von der Nachtragsvereinbarung, die sie tatsächlich regelt.
- Versionierung ist enorm wichtig. Tarife und Bedingungen von Carriern werden regelmäßig neu verhandelt. Ein RAG-System, das Gültigkeitsdaten und Ablösung nicht mitverfolgt, beantwortet Fragen mit den Konditionen aus einem Vertrag, der vor acht Monaten abgelaufen ist — und das ist schlimmer als gar keine Antwort.
- Compliance-Handbücher mischen Jurisdiktionen. Ein einziges Gefahrgut- oder grenzüberschreitendes Compliance-Dokument behandelt oft mehrere Staaten, Provinzen oder Länder in einer Datei, und die Suche muss präzise genug sein, um den Texas-Abschnitt zu finden, wenn es um Texas geht, statt einen Ausschnitt zu liefern, in dem Texas nur zufällig einmal erwähnt wird.
- Tabellen überstehen naive Textextraktion nicht. Tarife, Gewichtsgrenzen und Tabellen zu Nebenleistungen sind oft genau dort enthalten, wo die wirklich nützlichen Informationen stehen, und die übliche PDF-zu-Text-Extraktion zerstört Tabellenstrukturen häufig zu unbrauchbarem Text.
Das sind keine Gründe, RAG zu vermeiden. Es sind Gründe, vor der Frage nach dem einzusetzenden Sprachmodell echte Engineering-Zeit für Dokumentenaufbereitung, Chunking-Strategie und Metadaten-Tags (Carrier-Name, Gültigkeitsdatum, Jurisdiktion, Dokumenttyp) einzuplanen. Die Retrieval-Schicht entscheidet darüber, ob das Projekt funktioniert oder scheitert; der Generierungsschritt ist zu diesem Zeitpunkt im Vergleich weitgehend Standard.
Wie ein funktionierendes System für ein Dispositionsteam aussieht
Eine produktive Implementierung für die Disposition hat typischerweise vier Bausteine, die zusammenarbeiten. Eine Dokumenten-Ingest-Pipeline, die Verträge und Handbücher verarbeitet, Text und Tabellen extrahiert und jeden Chunk mit strukturierten Metadaten versieht — Carrier, Dokumenttyp, Jurisdiktion, Gültigkeitszeitraum — damit die Suche schon vorab filtern kann und nicht erst im Nachhinein nur nach Ähnlichkeit bewertet. Eine Retrieval-Schicht, die diese Metadaten-Filterung mit semantischer Suche kombiniert, sodass eine Frage zu „Carrier X’ aktueller Wartezeitregelung“ nur den aktuellen Vertrag von Carrier X durchsucht und nicht alle historischen Verträge aller Carrier. Eine Generierungsschicht, die in klarer Sprache antwortet und immer das konkrete Dokument und den Abschnitt zitiert, aus dem die Antwort stammt, damit ein Disponent vor jeder finanziell oder rechtlich relevanten Entscheidung prüfen kann. Und eine Feedback-Schleife — Disponenten melden falsche oder unklare Antworten — die zurück in die Korrektur von Dokumententags und Chunking fließt, statt nur am Prompt des Modells zu schrauben.
Die Oberfläche ist wichtiger, als man vielleicht denkt. Disponenten arbeiten schnell, oft am Telefon oder auf einem Tablet in der Fahrerkabine, und ein RAG-System, das an ein separates Chatfenster angeflanscht ist, das niemand öffnet, wird nicht genutzt. Die Q&A in die Tools zu integrieren, in denen die Dispositionsteams ohnehin schon arbeiten — das TMS, das Disposition-Board, einen Slack- oder Teams-Kanal — entscheidet meist stärker über die Akzeptanz als die Retrieval-Genauigkeit.
Worauf man skeptisch sein sollte
RAG-Systeme halluzinieren seltener als Modelle, die nur aus dem Gedächtnis antworten, aber „seltener“ heißt nicht „nie“. Ein System, das seine Quellenangabe nicht deutlich sichtbar ausspielt oder das bei einem Dokument selbstbewusst antwortet, obwohl es dazu keine relevante Passage finden konnte, ist in einem Bereich ein Risiko, in dem eine falsche Antwort zu Gefahrgut-Compliance oder vertraglicher Abdeckung echte finanzielle und sicherheitsrelevante Folgen hat. Jede Einführung für Fragen mit Compliance-Bezug braucht ein klares Fallback wie „Dafür habe ich nicht genug Informationen, um verlässlich zu antworten“, und die Quellenangabe muss mit einem Klick prüfbar sein, nicht in einer Fußnote versteckt, die niemand liest.
Es ist außerdem wichtig, ehrlich zu sagen, dass RAG die Geschwindigkeit und Konsistenz beim Zugriff auf vorhandenes Wissen verbessert — die Arbeit, von Anfang an gute und aktuelle Verträge sowie Compliance-Dokumente zu haben, ersetzt es nicht. Ein RAG-System, das mit sechs Monate alten Spediteurverträgen gefüttert wird, ruft diese veralteten Klauseln flüssig und selbstsicher ab, was im Grunde noch schlechter sein kann als der Ist-Zustand, in dem jemand manuell ein Laufwerk prüft und das Datum der Datei bemerkt.
Build vs Buy für diesen konkreten Anwendungsfall
Es gibt sofort einsetzbare Dokumenten-Q&A-Tools, die technisch auf eine kleine Menge von Spediteurverträgen funktionieren, und für eine sehr kleine Flotte oder ein Maklerhaus mit nur wenigen Carrier-Beziehungen kann eines davon tatsächlich ausreichen. Die Rechnung ändert sich, sobald jurisdiktionsbezogenes Filtern, Vertragsversionierung und TMS-Integration gleichzeitig erforderlich sind — was bei jeder Logistikorganisation ab einer gewissen Größe der Normalfall ist. Ab diesem Punkt bewältigen generische Dokumenten-Q&A-Tools die einfachen 80% der Fragen meist problemlos und scheitern genau bei den Fragen, die am wichtigsten sind — also bei einer geänderten Anlage, einem abgelaufenen Vertrag oder einer gebietsspezifischen Compliance-Regel —, weil genau diese Fälle generisches Chunking und Retrieval falsch behandeln. Dasselbe Muster sehen wir bei den meisten Enterprise-RAG-Implementierungen: Die Standardversion deckt die einfachen Fragen ab, und die maßgeschneiderte Engineering-Arbeit dreht sich ausschließlich darum, die schwierigen 20% richtig zu lösen, und genau dort liegt meist das eigentliche Geschäftsrisiko.
Ohne Überbau starten
Teams, die das richtig umsetzen, beginnen meist mit einem einzelnen, klar abgegrenzten Dokumentensatz — etwa aktuellen Spediteurverträgen — statt am ersten Tag gleich jedes Compliance-Handbuch und jedes Richtliniendokument zu ingestieren. Bringen Sie für genau diesen einen Satz Metadaten-Tagging, Versionierung und Zitierweise sauber auf den Punkt, messen Sie, wie oft Disponenten das System tatsächlich nutzen und ob die Antworten belastbar sind, und erweitern Sie dann den Umfang. Den gesamten Dokumentenbestand RAG-fähig zu machen, bevor die Retrieval-Qualität an einem gut verstandenen Satz bewiesen ist, ist der häufigste Grund, warum solche Projekte mitten in der Umsetzung ins Stocken geraten.
Wenn Sie abwägen, ob sich das für Ihre Disposition lohnt oder ob angesichts Ihres Dokumentenmixes eine kleinere erste Version sinnvoller ist, starten Sie ein Gespräch mit uns darüber, wie ein Pilot rund um Ihre wichtigsten Reibungspunkte bei Carrier- und Compliance-Fragen aussehen könnte.
Verwandt