So bereiten Sie Ihre Unternehmensdaten für ein RAG- oder LLM-Deployment vor

In einem RAG-Projekt ist das Sprachmodell selten der schwierigste Teil. Weit mehr Probleme entstehen durch veraltete Dokumente, widersprüchliche Quellen, fehlende Zugriffskontrollen und Daten, die niemand jemals für die automatisierte Nutzung aufbereitet hat.

Sie müssen nicht das gesamte Unternehmen umorganisieren, bevor Sie das erste Deployment starten. Aber Sie müssen genau wissen, welches Problem Sie lösen, welche Daten das System nutzen darf und was es tun soll, wenn es keine verlässliche Antwort findet.

Beginnen Sie mit der Frage, nicht mit den Daten

Gespräche über RAG-Deployments beginnen meist bei den Quellen.

Wir haben SharePoint. Ein paar tausend PDFs. Handbücher auf einem Netzlaufwerk. Daten im ERP. Kontakthistorie im CRM. Können wir das alles in die KI einspeisen?

Technisch gesehen - meistens ja. Das heisst aber nicht, dass wir es tun sollten.

Wenn die gesamte Unternehmensdokumentation ohne definierten Zweck ins System fliesst, bekommt das Modell mehr Informationen - aber nicht unbedingt mehr Wissen. Aktuelle Verfahren vermischen sich mit archivierten. Anweisungen für unterschiedliche Abteilungen konkurrieren miteinander. Mehrere Systeme liefern verschiedene Versionen derselben Information.

Das Ergebnis ist ein Assistent, der viel weiss, bei dem man aber nicht vorhersagen kann, wann er korrekt antwortet.

Deshalb ist der erste Schritt nicht das Anbinden einer Vektordatenbank. Es ist die Definition eines einzelnen Prozesses.

Nicht:

Wir möchten KI für unser Unternehmenswissen einsetzen.

Sondern:

Ein Servicetechniker stellt Fragen zu aktuellen Reparaturhandbüchern. Das System nutzt ausschliesslich freigegebene technische Dokumentation, nennt seine Quelle und verweigert die Antwort, wenn es keine ausreichenden Daten findet.

Dieser Satz enthält den Nutzer, die Aufgabe, den Datenumfang und das erwartete Systemverhalten. Das ist bereits der Anfang einer Architektur.

Praxistipp: Formulieren Sie Ihren Use Case als einen einzigen Satz, der mit "Der Nutzer fragt nach..." beginnt - wenn Sie ihn nicht formulieren können, sind Sie noch nicht bereit für ein Deployment.

Jeder Use Case braucht andere Daten

Ein Assistent, der Fragen zu internen Verfahren beantwortet, arbeitet mit anderen Quellen als ein System, das den Bestellstatus prüft.

Der erste nutzt Dokumente, Handbücher und die Unternehmenswissensbasis. Der zweite sollte Echtzeitdaten aus dem ERP oder dem Auftragsmanagementsystem abrufen. Beide Probleme mit derselben Dokumentendatenbank lösen zu wollen, führt schnell zu Fehlern.

Dasselbe gilt für andere Prozesse:

Ein System zur Analyse von Angebotsanfragen benötigt Nachrichteninhalte, Kundendaten und Regeln zur Lead-Qualifizierung.
Ein Produktassistent braucht den Katalog, Spezifikationen, Preise, Verfügbarkeit und Varianteninformationen.
Ein Marketing-Agent kann Google Ads, GA4, Search Console, Shop-Daten und historische Entscheidungsprotokolle nutzen - genau so funktioniert unser Ads Agent, der mit Live-Kundendaten statt mit statischen Berichten arbeitet.
Ein System zur Unterstützung der Tierzucht sucht nicht nach ähnlichen Textabschnitten. Es braucht genealogische Daten, Berechnungen und Beziehungen zwischen Datensätzen.

Es gibt keine einheitliche "KI-Wissensbasis". Es gibt spezifische Datensätze, die für spezifische Aufgaben benötigt werden.

Unternehmen haben meist mehr Datenquellen, als sie denken

Daten befinden sich selten an einem einzigen Ort.

Manches Wissen steckt in PDF- und Word-Dokumenten. Manches in Transaktionssystemen. Manches in E-Mails, Notizen von Mitarbeitern, Tabellenkalkulationen und Anwendungen, die über die Jahre entstanden sind.

Bei der ersten Bestandsaufnahme finden Sie typischerweise:

Dokumente und Präsentationen,
Verfahrensanweisungen und Handbücher,
ERP-System (SAP, Oracle, Microsoft Dynamics),
CRM (Salesforce, HubSpot, Pipedrive),
SQL-Datenbanken und APIs,
Produktkataloge,
Websites und Intranets,
Ticketing-Systeme,
Tabellenkalkulationen,
E-Mails und Besprechungsnotizen,
branchenspezifische oder eigenentwickelte Anwendungen.

In diesem Stadium müssen Sie nichts importieren oder indexieren. Sie müssen feststellen:

wem jede Quelle gehört,
wie auf sie zugegriffen werden kann,
wie oft sich die Daten ändern,
ob die Quelle noch aktiv genutzt wird,
wer berechtigt ist, ihren Inhalt einzusehen,
ob die Daten für die erste Systemversion benötigt werden.

Das Ziel ist eine Datenkarte, keine organisatorische Migration. Bei unseren Audits stellen wir regelmässig fest, dass ein erheblicher Teil der kritischen Dokumentation in SharePoint-Ordnern oder auf Netzlaufwerken liegt, auf die niemand aktiv zugreift.

Eine Information, mehrere Versionen

Das schwierigste Problem taucht auf, wenn man beginnt, Quellen zu vergleichen.

Der Preis eines Produkts steht im ERP, im Online-Shop und im PDF-Katalog. Das Reklamationsverfahren existiert in drei Versionen. Technische Spezifikationen unterscheiden sich zwischen der Produktkarte und der Tabelle des Lieferanten.

Jedes dieser Dokumente sieht glaubwürdig aus. Aber das Sprachmodell weiss nicht, welches Vorrang hat. Wenn es zwei widersprüchliche Informationen abruft, wählt es möglicherweise eine aus, kombiniert beide oder generiert eine Antwort, die keiner der Quellen entspricht. Und das mit voller Überzeugung.

Deshalb müssen Sie für jeden wesentlichen Informationstyp eine einzige verlässliche Quelle (Single Source of Truth) festlegen.

Wenn Lagerbestände aus dem ERP kommen, sucht das System nicht in der Dokumentation oder in einer Katalogkopie vom letzten Monat danach. Wenn die aktuellen AGB im Dokumentenmanagementsystem liegen, konkurrieren archivierte Versionen nicht mit ihnen bei der Suche.

In der Praxis müssen Sie definieren:

das massgebliche System für jeden Datentyp,
den Dateneigentümer,
die Aktualisierungshäufigkeit,
Regeln zur Konfliktlösung,
Richtlinien zur Archivkennzeichnung,
das Systemverhalten, wenn aktuelle Daten nicht verfügbar sind.

Eine Single Source of Truth bedeutet nicht ein System für das gesamte Unternehmen. Das ERP kann massgeblich für Preise und Verfügbarkeit sein, das CRM für die Kontakthistorie und das freigegebene Dokumentenrepository für Verfahrensanweisungen. Entscheidend ist, dass die Hierarchie explizit und dokumentiert ist, bevor Sie die erste Zeile Code schreiben.

Nicht alles, was existiert, gehört ins RAG

Beim Audit taucht schnell eine Versuchung auf: Wenn wir schon Zugriff haben, indexieren wir doch gleich alles.

Das ist meistens eine schlechte Idee.

Eine grosse Anzahl von Dokumenten verbessert nicht automatisch die Antwortqualität. Sie kann jedoch die Zahl der Duplikate, Widersprüche und Ergebnisse erhöhen, die nur scheinbar mit der Frage zusammenhängen.

Bevor Sie eine Quelle ins System aufnehmen, prüfen Sie:

ob das Dokument noch gültig ist,
ob es einen Verantwortlichen hat,
ob Sie wissen, wann es zuletzt aktualisiert wurde,
ob der Inhalt eine Kopie eines anderen Dokuments ist,
ob sein Geltungsbereich klar definiert werden kann,
ob der Nutzer tatsächlich darauf zugreifen darf,
ob das Dokument für den gewählten Use Case relevant ist.

In einem Produktivsystem sind wenige gut beschriebene Quellen oft wertvoller als Tausende beliebiger Dateien.

Unaufgeräumte Daten räumen sich nicht von selbst auf, wenn man ein Modell anschliesst

Wenn die Dokumentation veraltet ist, macht RAG sie nicht aktuell. Wenn dasselbe Produkt unter mehreren Kennungen erscheint, erkennt das Modell möglicherweise nicht, dass sie sich auf ein einziges Produkt beziehen. Wenn eine alte Richtlinie nicht als archiviert gekennzeichnet wurde, wird sie genauso abgerufen wie die aktuelle.

Wenn Dokumente keine ordnungsgemässen Metadaten und Statuslabel haben, weiss das LLM nicht, welche Version einer Richtlinie gültig ist. Es kann ein archiviertes Dokument mit derselben Sicherheit abrufen wie das aktuelle. Das ist nicht die Schuld des Modells. Das ist die Schuld der Daten.

Vor dem Deployment müssen Sie zumindest die Daten aufräumen, die Ihr erster Use Case abdeckt:

Duplikate entfernen oder kennzeichnen,
aktive Dokumente von archivierten trennen,
Kennungen standardisieren (gleiches Produkt = gleicher Code, keine Variationen),
Vollständigkeit der Schlüsselfelder prüfen,
Publikations- und Gültigkeitsdaten kennzeichnen,
einen Dokumentverantwortlichen zuweisen,
eine Richtlinie für unvollständige Datensätze definieren - ablehnen, ergänzen oder kennzeichnen?

Das bedeutet nicht, dass Sie ein monatelanges "Data Governance"-Programm starten müssen, bevor das Projekt beginnt. Es bedeutet, einen bestimmten Datenumfang in einen Zustand zu bringen, in dem Sie testen und iterieren können, ohne zu raten.

Metadaten sind Teil der Antwort

Der Dokumenteninhalt ist nur eine Informationsebene. Das System muss oft wissen:

wann das Dokument erstellt wurde und ob es noch gültig ist,
für welchen Markt es gilt,
in welcher Sprache es verfasst wurde,
zu welcher Abteilung es gehört,
wer es freigegeben hat,
welche Vertraulichkeitsstufe es hat,
auf welches Produkt, welchen Kunden oder welches Projekt es sich bezieht.

Diese Informationen werden als Metadaten gespeichert. Sie ermöglichen es dem System, die Suche auf aktuelle technische Dokumentation für einen bestimmten Markt einzugrenzen, statt die gesamte Wissensbasis des Unternehmens zu durchsuchen.

Metadaten helfen auch bei der Konfliktlösung. Wenn zwei Dokumente unterschiedliche Antworten enthalten, kann das System das neuere, freigegebene Dokument bevorzugen, das der richtigen Region zugeordnet ist. Beispiel: Ein Dokument mit dem Status "freigegeben" und einem Aktualisierungsdatum von 2026-07 hat Vorrang vor einem Entwurf von 2025-01, selbst wenn der Entwurf semantisch näher an der Frage liegt. Ohne Metadaten sieht das System nur Textähnlichkeit - und hat keine Grundlage für eine Entscheidung.

Zugriffskontrollen müssen greifen, bevor die Antwort generiert wird

Ein KI-Assistent darf die im Unternehmen geltenden Zugriffsregeln nicht umgehen. Wenn ein Mitarbeiter keine Berechtigung hat, ein Dokument in SharePoint zu öffnen, sollte er auch kein Fragment davon in einer modellgenerierten Antwort erhalten.

Die Zugriffskontrolle muss auf der Abrufebene greifen. Das System ermittelt zunächst, welche Daten der Nutzer einsehen darf, und wählt erst dann den Kontext für das Modell aus.

Je nach Infrastruktur kann dies eine Integration erfordern mit:

dem unternehmensinternen Identitätsmanagementsystem,
Active Directory oder Entra ID,
anwendungsspezifischen Rollen,
projektspezifischen Berechtigungen,
den Dokumenten zugewiesenen Zugriffskontrolllisten.

Die fertige Antwort zu filtern kommt zu spät. Das Modell sollte niemals Inhalte erhalten, auf die der Nutzer keinen Zugriff hat.

Für personenbezogene, medizinische, finanzielle oder anderweitig regulierte Daten gelten zusätzliche Anforderungen bezüglich Aufbewahrung, Protokollierung und Verarbeitungsort. Diese Regeln müssen vor der Auswahl eines Modellanbieters und der Infrastruktur festgelegt werden - nicht danach.

RAG bedeutet nicht immer eine Vektordatenbank

Die häufigste RAG-Variante basiert auf semantischer Suche - Dokumente werden in Chunks aufgeteilt, in Vektoren umgewandelt und mit der Frage des Nutzers verglichen. Das funktioniert gut für viele Dokumenttypen und beschreibende Fragen.

Aber nicht für jeden Informationstyp.

Wenn der Nutzer nach der Rechnung INV/2026/001, einer Seriennummer oder einem bestimmten Produktcode fragt - kann eine exakte Übereinstimmung wichtiger sein als semantische Ähnlichkeit.

Wenn er nach dem aktuellen Bestellstatus fragt - ist die richtige Antwort möglicherweise eine SQL-Abfrage oder ein API-Aufruf, keine Dokumentensuche.

Wenn er Beziehungen zwischen Objekten analysieren möchte - braucht man möglicherweise einen Graphen, keine Vektordatenbank.

Deshalb kann die Abrufschicht mehrere Methoden kombinieren:

Semantische Suche (Vektoren),
Volltextsuche (BM25),
Metadatenfilterung,
SQL-Abfragen an Transaktionssysteme,
Echtzeit-API-Aufrufe,
Graphen und Beziehungen,
dedizierte Berechnungsfunktionen.

Eine gute Architektur zwingt nicht alle Daten in einen einzigen Speicher. Sie wählt Quelle und Methode basierend auf der Art der Frage.

Hybride Suche: Bedeutung und Präzision

In grösseren Wissensbasen wird die semantische Suche oft mit traditioneller Volltextsuche kombiniert.

Die semantische Suche erfasst Bedeutung gut. Die Frage "Welche Haftung trägt der Lieferant bei verspäteter Lieferung?" kann zu einem Dokument führen, das die Formulierung "Überschreitung der Lieferfrist" verwendet, obwohl die Wörter nicht identisch sind.

Die Volltextsuche ist besser beim Finden von:

Produktcodes,
Rechnungs- und Bestellnummern,
Eigennamen,
Teilesymbolen,
Branchenabkürzungen,
exaktem Vertragstext.

Die dritte Ebene ist die Metadatenfilterung - die Eingrenzung der Suchmenge, bevor die eigentliche Suche beginnt. "Zeige nur Dokumente der Finanzabteilung aus dem letzten Jahr" - das erhöht die Präzision dramatisch und eliminiert irrelevante Ergebnisse.

Die Kombination dieser drei Methoden findet semantisch ähnliche Inhalte, ohne präzise Kennungen zu verlieren.

Chunking - wo man ein Dokument aufteilt

Das Modell sollte nicht jedes Mal ein mehrhundertseitiges Dokument erhalten, wenn ein Nutzer eine Frage stellt. Dokumente werden daher in kleinere Stücke aufgeteilt - Chunks.

Es klingt wie ein technisches Detail. In der Praxis kann die Aufteilungsstrategie die Antwortqualität komplett verändern.

Wenn ein Chunk zu klein ist, findet das System den konkreten Satz, verliert aber die Bedingungen und Ausnahmen, die einen Absatz vorher beschrieben werden. Ist er zu gross, erhält das Modell eine Masse irrelevanter Inhalte, und die Schlüsselinformation geht in der Mitte unter.

Drei Hauptansätze:

Aufteilung nach Dokumentstruktur - Kapitel, Überschriften, Abschnitte und Absätze als natürliche semantische Grenzen. Funktioniert gut für Handbücher, Richtlinien, technische Dokumentation und juristische Materialien.

Aufteilung in kleinere Textfragmente - kürzere Chunks verbessern die Präzision bei einfachen Fragen, erfordern aber die Beibehaltung von Informationen über das übergeordnete Dokument und benachbarte Abschnitte.

Überlappende Chunks - ein Teil des Inhalts wird zwischen benachbarten Chunks wiederholt, damit Sätze oder Bedingungen nicht an der falschen Stelle getrennt werden. Aber Überlappung ist kein Universalmittel - sie vergrössert den Index und kann dazu führen, dass nahezu identische Ergebnisse zurückgegeben werden.

Die wichtigste Regel:

Wählen Sie Ihre Chunking-Strategie nicht anhand eines Artikels im Internet. Vergleichen Sie mehrere Varianten anhand der Fragen, die Ihre Nutzer tatsächlich stellen werden.

Technische Dokumentation erfordert eine andere Strategie als Kunden-E-Mails, und Produktkataloge wieder eine andere. Dies ist einer der Bereiche, in denen die Erfahrung des Implementierungsteams den grössten Unterschied macht.

Wahl des Embedding-Modells

Ein Embedding wandelt Text in eine numerische Darstellung um, die es dem System ermöglicht, die Bedeutung einer Frage und eines Dokuments zu vergleichen. Dank Embeddings wird eine Frage zur "Lieferverzögerung" mit einem Dokument über "Auftragsdurchlaufzeiten" verknüpft.

Die Wahl des Embedding-Modells ist wichtig, aber ein allgemeines Ranking sagt Ihnen nicht, wie das Modell mit Ihrer technischen Dokumentation in Ihrer Sprache, Medikamentennamen, juristischen Formulierungen oder Branchenabkürzungen umgeht.

Kriterien, die die Wahl leiten sollten:

Sprache und Domäne - ein Modell, das primär für allgemeine englische Texte optimiert ist, kann bei technischer, juristischer oder medizinischer Terminologie in anderen Sprachen schlechter abschneiden. Sie müssen dies mit Ihren eigenen Daten testen - gehen Sie nicht davon aus, dass das Modell Ihre Domäne "versteht", nur weil es bei einem englischen Benchmark gut abschneidet.

Qualität auf Ihren Daten - vertrauen Sie keinen allgemeinen Benchmarks. Bereiten Sie einen repräsentativen Satz von Fragen vor, die Ihre Nutzer tatsächlich stellen würden, und prüfen Sie manuell, welches Modell die relevantesten Fragmente abruft. In einem kleinen Pilotprojekt können das einige Dutzend Fälle sein; in einem System mit höherem Risiko erheblich mehr. Tests mit Ihren eigenen Daten sind wichtiger als die Bestenliste eines Anbieters.

Kosten und Leistung - Embedding-Modelle unterscheiden sich in Qualität, Kosten und Geschwindigkeit. Ein grösseres Modell mag in einem Benchmark höher punkten, garantiert aber nicht bessere Ergebnisse mit Ihren Unternehmensdaten. Wenn das System Hunderte von Abfragen pro Minute verarbeiten muss, müssen Sie Qualität gegen Durchsatz abwägen.

Datenschutz und Hosting - dürfen Ihre Unternehmensdaten in eine öffentliche Cloud? Erfordern DSGVO-Anforderungen oder Branchenvorschriften ein On-Premise-Hosting des Modells? Diese Frage muss zu Beginn des Projekts gestellt werden, nicht am Ende.

Stabilität und Versionierung - wenn der Anbieter das Modell ohne Vorankündigung ändert, werden Ihre bestehenden Embeddings inkonsistent mit neu generierten. Den Wechsel eines Embedding-Modells bedeutet die Neuindexierung der gesamten Datenbank - kein triviales Unterfangen.

Ein grösseres Modell ist nicht automatisch besser. Die Qualität wird durch das gesamte System bestimmt: Daten, Chunking, Metadaten, Suchstrategie, Reranking und die Art der gestellten Fragen.

Das "Lost in the Middle"-Problem

Neue Modelle akzeptieren immer grössere Textmengen in ihren Kontextfenstern. Es ist verlockend anzunehmen, man könne ihnen alle abgerufenen Dokumente übergeben und sie selbst die richtige Antwort finden lassen.

Das funktioniert nicht so gut, wie die Theorie vermuten lässt.

Forschungen zur Nutzung langer Kontexte zeigten, dass Modelle Inhalte am Anfang und Ende des Kontexts besser nutzen und Schwierigkeiten mit Informationen haben, die in der Mitte vergraben sind. Wenn Sie 10 Chunks übergeben und die korrekte Antwort im fünften steckt, tendiert das Modell dazu, sie zu übersehen.

In der Praxis ist es besser, dem Modell wenige gut ausgewählte Fragmente zu übergeben als Dutzende "auf Vorrat".

Was hilft:

präzise Metadatenfilterung,
besseres Retrieval (hybrid),
Begrenzung der Ergebnisanzahl,
Deduplizierung der Ausgabe,
Reranking - erneute Bewertung abgerufener Chunks und Hervorhebung derjenigen, die für die konkrete Frage am relevantesten sind,
Aufteilung komplexer Fragen in mehrere Schritte.

Reranking behebt keine schlechten Daten oder schlecht konzipierte Suche. Aber es kann die Kontextauswahl erheblich verbessern, bevor sie an das Modell übergeben wird. Weniger Chunks, besser ausgewählt - das ist der Schlüssel zu präzisen Antworten.

Daten müssen aktuell bleiben

Ein einmaliger Dokumentenimport reicht für eine Demo. Ein Produktivsystem braucht Synchronisation.

Wenn sich Richtlinien, Preise, Dokumentation oder Produktdaten ändern, muss die Aktualisierung die KI-Schicht erreichen. Wenn eine Quelle gelöscht wird, dürfen ihre Chunks nicht auf ewig im Index verbleiben.

Sie müssen definieren:

wie oft die Daten aktualisiert werden,
ob das System den vollständigen Datensatz oder nur Änderungen abruft (Delta-Sync),
was passiert, wenn ein Dokument aus der Quelle gelöscht wird,
wie Synchronisationsfehler behandelt werden,
welche Version eines Dokuments zu jedem Zeitpunkt aktiv ist.

Die Häufigkeit hängt vom Prozess ab. Dokumentation, die einige Male pro Jahr aktualisiert wird, braucht keine minutengenaue Synchronisation. Produktverfügbarkeitsdaten müssen möglicherweise bei jeder Abfrage direkt aus dem Quellsystem gelesen werden.

Versionierung ist nicht optional

Wenn das System eine falsche Antwort gibt, müssen Sie feststellen können:

welche Frage es erhalten hat,
welche Quellen es verwendet hat,
welche Chunks es abgerufen hat,
welche Version des Dokuments aktiv war,
welches Modell es verwendet hat,
welche Regeln und Prompts zu diesem Zeitpunkt galten.

Ohne dies sieht das Team nur die Ausgabe, kann aber die Ursache nicht rekonstruieren.

Die Versionierung von Daten, Prompts, Modellen und Retrieval-Konfiguration ermöglicht es, einen zufälligen Fehler von einer Regression zu unterscheiden, die durch eine Systemänderung verursacht wurde. Das ist einer der Unterschiede zwischen einer RAG-Demo und einem System, das Sie in Produktion warten können.

Erstellen Sie Testfragen, bevor Sie mit dem Bauen beginnen

Warten Sie nicht, bis das System fertig ist, um mit dem Testen zu beginnen. Schon zu Beginn des Projekts können Sie Fragen sammeln, die Nutzer tatsächlich stellen.

Diese sollten umfassen:

typische Fragen - das tägliche Brot des Systems,
ungenaue Fragen - so, wie Menschen tatsächlich fragen,
Fragen, die Informationen aus mehreren Quellen erfordern,
Fragen ohne Antwort in den Quellen - das System muss wissen, wie es ablehnt,
Fragen zu archivierten Daten,
Fälle mit eingeschränktem Zugriff,
Fragen mit exakten Symbolen, Nummern und Kennungen.

Für jede Frage lohnt es sich zu definieren:

wo die korrekte Antwort zu finden ist,
welche Information in der Antwort enthalten sein muss,
was das System nicht erfinden darf,
wann es die Antwort verweigern sollte,
welche Quelle es zitieren sollte.

Nur mit einem solchen Test-Set können Sie Chunking, Embeddings, Suchmethoden und Reranking sinnvoll vergleichen. Ein allgemeiner Benchmark eines Anbieters ersetzt nicht das Testen mit Ihren Daten, Ihren Fragen und Ihrem Use Case.

Minimales Datenaudit vor dem Deployment

Bevor Sie mit dem Bau beginnen, beantworten Sie einige Fragen:

Nicht jede Antwort muss sofort "ja" lauten. Das Audit soll zeigen, wo die Lücken sind und ob Sie eine erste Version in begrenztem Umfang sicher starten können.

Case Study: BLUP-FLOCK - wenn Standard-RAG nicht ausreicht

BLUP-FLOCK ist eine ERP-Plattform für die Verwaltung von Geflügelzuchtbeständen, gebaut auf Laravel 11, Vue.js 3, MS SQL und Redis, betrieben auf Kubernetes. Das System arbeitet nicht nur mit Dokumenten. Es muss Stammbäume über fünf Generationen rekonstruieren, Inzuchtkoeffizienten berechnen und die Rangfolge von Zuchtakandidaten mit dem BLUP-Algorithmus unterstützen.

Standard-Textähnlichkeitssuche reicht hier nicht aus.

Das Datenproblem beginnt bei der Erfassung

In der Geflügelstammzucht wird jedes Tier mit einer individuellen Flügelmarke identifiziert. Daten werden mit Handscannern erfasst - aber der Prozess selbst hängt vom Farmtyp ab.

In einem Käfigbetrieb ist es relativ einfach: Eine Waage fährt auf einer leichten Plattform mit Computer zwischen den Käfigen. Das Tier ist im Käfig, das Ei lässt sich leicht wiegen und zuordnen.

In einem Bodenhaltungsbetrieb laufen die Hennen frei und legen Eier in spezielle Fallnester. Die Person, die eine Henne aus dem Nest holt, muss auch das Ei greifen - am Nest ist kein Platz zum Wiegen. Wir haben eine Handwaage entworfen, aber die Schwerkraft hat uns besiegt. Die Lösung stellte sich als einfacher heraus: Ein Arbeiter geht mit einem Scanner, und etwa alle 20 Meter sind elektronische Waagen an der Wand montiert.

Das Ergebnis: doppelt so viele gewogene Eier im Vergleich zur alten Datenerfassungsmethode. Teils dank der neuen Werkzeuge und teils dank der konsequenteren Durchsetzung des neuen Prozesses - Technologie allein reicht nicht ohne eine Veränderung der Arbeitsweise. Wir wiegen immer noch nicht alle Eier - aber wie der Professor der Landwirtschaftsuniversität, der das Projekt berät, erklärte: In der Stammzucht wiegt man nicht jedes Ei. Was man braucht, ist eine korrekt ausgewählte, repräsentative Stichprobe.

Warum das für RAG wichtig ist

Dieses Beispiel zeigt etwas, das in Artikeln über KI-Deployments selten diskutiert wird: Die Datenqualität im System wird durch die Art der physischen Datenerfassung begrenzt. Kein Embedding-Modell wird die Tatsache beheben, dass manche Eier nicht gewogen wurden, weil die Henne auf Einstreu lief statt im Käfig zu sitzen.

Was benötigt wurde, war eine Architektur, die strukturierte Daten, genealogische Beziehungen, einen benutzerdefinierten Abrufmechanismus, deterministische Berechnungen, eine Erklärbarkeitsschicht und Ergebnisnachprüfbarkeit kombiniert. Das Sprachmodell ist eine Komponente in einem solchen System - es ersetzt nicht Datenbankabfragen, den BLUP-Algorithmus oder die für die Berechnungsgenauigkeit verantwortlichen Regeln.

Nach der Optimierung des Datenerfassungsprozesses und der Art, wie Daten bereitgestellt wurden, verbesserte sich die Ergebnisqualität, ohne das Modell zu ändern. Das Problem war nicht das LLM - es war die Art, wie die Daten aufbereitet und geliefert wurden.

Das ist eine wichtige Lektion: Manchmal bedeutet Datenaufbereitung das Bereinigen von Dokumenten und Metadaten. Manchmal bedeutet es, einen physischen Datenerfassungsprozess in einem Bodenhaltungsbetrieb zu gestalten.

Zur vollständigen BLUP-FLOCK-Fallstudie →

CommercePilot: Produktdaten als Sonderfall

Wenn Ihr Use Case ein Shopping-Assistent, ein Produkt-Chatbot oder ein KI-Agent ist, der auf einem E-Commerce-Katalog arbeitet, müssen Produktdaten genauso sauber sein wie technische Dokumentation in der Fertigung.

Das sind sie selten.

CommercePilot scannt einen Online-Shop und prüft die Vollständigkeit und Konsistenz der Produktdaten - und automatisiert damit einen Teil dieses Audits für öffentlich zugängliche E-Commerce-Katalogdaten.

Häufige Probleme, die es erkennt:

Fehlende Produktkennungen (EAN/GTIN) - fehlende EAN-Codes erschweren die eindeutige Identifikation von Produkten, den Abgleich von Angeboten und die Nutzung der Daten über Shopping-Plattformen und agentische Systeme hinweg. Das ist nicht nur ein SEO-Thema - es ist eine Frage der Bereitschaft für agentischen Commerce.

Unvollständige Beschreibungen und fehlende Attribute - wenn auf einer Produktkarte Masse, Materialien oder Gewicht fehlen, kann das Modell keine sinnvolle Antwort auf eine Kundenfrage generieren. Garbage in, garbage out.

Inkonsistente Kategorisierung - dasselbe Produkt in drei Kategorien signalisiert, dass die Daten keine einheitliche Wahrheitsquelle haben.

Fehlende strukturierte Daten - fehlende ordnungsgemässe strukturierte Schema.org-Daten, am häufigsten als JSON-LD implementiert, erschweren es Maschinen, das Produkt, den Preis, die Verfügbarkeit und die Spezifikationen eindeutig zu identifizieren. Das blockiert die Katalognutzung nicht vollständig, erhöht aber die Abhängigkeit von weniger zuverlässigem Seiten-Parsing.

Wenn Sie ein KI-Deployment im E-Commerce planen, ist ein Produktdatenaudit einer der ersten Schritte. CommercePilot automatisiert es für die Storefront-Ebene und gibt Ihnen ein klares Bild davon, was auf der Katalogseite behoben werden muss.

Prüfen Sie Ihren Shop mit CommercePilot →

Man kann das Modell austauschen. Datenprobleme bleiben

Modelle werden sich weiter verändern. Ein Unternehmen kann von einem Anbieter zum anderen wechseln, ein günstigeres Modell für einfache Aufgaben nutzen oder ein leistungsfähigeres für Analysen, die tieferes Reasoning erfordern.

Das Modell ist eines der austauschbareren Elemente der Architektur. Es zu ändern erfordert zwar Tests, Prompt-Anpassungen und Qualitätsprüfungen - aber es ist in der Regel einfacher als die Reparatur von Datenquellen, Zugriffskontrollen und Integrationen, die sich über Jahre entwickelt haben.

Was viel schwerer zu beheben ist:

keine Single Source of Truth,
unklare Zugriffskontrollen,
widersprüchliche Dokumente,
keine Versionierung,
Integration mit einem System, das niemand pflegt,
ein Prozess, der nie klar definiert wurde.

Deshalb ist Datenaufbereitung keine Arbeit, die man "vor der eigentlichen KI" erledigt. Sie ist Teil des eigentlichen Deployments.

Sie planen ein RAG- oder LLM-Deployment?

Wir beginnen mit dem Prozess, den Daten und den Quellen der Wahrheit. Erst dann wählen wir Retrieval-Strategien, Modelle und den Rest der Architektur.

Wir entwickeln RAG-Systeme, Datenpipelines und KI-Agenten, die mit echten Dokumenten, Datenbanken, ERP, CRM und operativen Geschäftstools integriert sind.

Erfahren Sie, wie wir produktionsreife KI-Systeme und LLM-Integrationen bauen →