Ein Mitarbeiter fragt Ihre Wissensdatenbank nach einer Klausel aus dem Liefervertrag von 2023. Zurück kommt brav das falsche Dokument, zwei Projekte werden verwechselt, und obendrein wird eine Frist erfunden, die so nie existiert hat. Die naheliegende Reaktion ist schnell getroffen: das Modell ist zu klein, wir brauchen etwas Größeres, Teureres. Also wird das Modell getauscht, der Prompt verlängert, das Budget erhöht – und die Antworten laufen weiter schief.
Genau hier rennen die meisten Teams in die falsche Richtung. Eine Wissensdatenbank antwortet nicht deshalb falsch, weil das Sprachmodell zu schwach wäre. Sie antwortet falsch, weil die Dokumente, die vor dem Modell liegen, ein völliges Durcheinander sind. Was das Modell am Ende zu sehen bekommt, ist nur so gut wie die Schicht unmittelbar davor.
Stellen Sie sich den Alltag vor: fünf Jahre Verträge, Tickets, Produkthandbücher und Scan-Vorlagen liegen wild verteilt in einem Ordner. Alles zusammen wird dem Modell übergeben mit dem Auftrag, es "einfach zu verstehen". Was das Modell lesen kann, sind zig Gigabyte unaufbereiteter Rohtexte. Was es zurücksuchen kann, sind nach Dateinamen und Stichworten hart gematchte Seiten. Was es ausspuckt, greift folgerichtig oft daneben. Nicht das Modell ist dumm. Das Gefütterte ist schlicht chaotisch.
Ein größeres Modell heilt die Decke, nicht den Boden
Es lohnt sich, das eigentliche Kostenmodell genauer anzusehen. Bevor ein Dokument in die Datenbank wandert, bestimmen dessen Zustand – Volumen, Format, sensible Felder, Doppelungen – das obere Limit der Suchqualität. Ein noch so starkes Modell rettet keine verschmutzte Eingabe. In der Branche spricht man von Data Hygiene: ein "unordentliches, überdimensioniertes, schmutziges" Dokument erst sauber zu machen ist deutlich günstiger, als später Rechenleistung zu häufen.
Oberflächlich wirkt es wie ein Modellproblem. Bei genauerem Hinsehen liegt die Wurzel weiter vorn. Das eigentliche Problem des Retrievals war nie, ob ein Modell "schlau genug" ist. Es war immer, ob die Information, die ein Nutzer wirklich braucht, präzise gefunden werden kann. Dieses Prinzip steht über jeder Modelltechnik. Das Modell ist nur die letzte von mehreren Stationen. Waren die vorherigen Stationen falsch, rettet auch höchster Einsatz am Ende nichts.
Was eine Datenengineering-Basis leistet
Teams, die Wissensdatenbanken ernsthaft betreiben, geben Rohdateien nicht direkt an ein Modell weiter. Sie schalten davor eine Engineering-Basis: Dokumente werden verschlankt, Formate vereinheitlicht, sensible Inhalte nach Regeln geschwärzt, Texte in gut durchsuchbare Abschnitte zerlegt – und erst dann mit Herkunftsangabe eingespielt. Diese Kette aus Erfassung, Bereinigung, Segmentierung, Vektorisierung, Retrieval und Generierung prägt die Qualität der späteren Antwort in jeder einzelnen Stufe.
Wer es wirklich versteht, erledigt noch ein paar Dinge, die der Auftraggeber gar nicht gefordert hat. Etwa eine realistische Frage-Antwort-Sammlung als Abnahmekorpus anzulegen, statt sich auf das Gefühl zu verlassen, es sei "wohl präziser" geworden. Oder die Suchqualität als messbare Kennzahl zu behandeln und regelmäßig Regressionen laufen zu lassen, sodass auffällt, welche Fragenklasse schwächer geworden ist. Hybrides Retrieval, Re-Ranking, Query-Rewriting, semantische Segmentierung und Offline-Evaluation mit etablierten Frameworks gehören zum offenen Handwerkszeug der Disziplin. Nicht als Geheimrezept eines Anbieters, sondern als gemeinsamer Standard. Das, was jede Stufe tatsächlich reproduzierbar macht, verlangt, die Basis wie ein Produkt zu pflegen.
Was "reproduzierbar" wirklich bedeutet, gerät leicht zu einem Slogan. Woran erkennt man unabhängig, ob eine Wissensdatenbank tauge? Nicht am Selbstlob einer Demo. Sondern an einer unabhängig annotierten Golden-Question-Sammlung, an Offline-Kennzahlen, die sich wiederholen lassen, an stabilen Blind-A/B-Ergebnissen, an einer Regression, die dauerhaft in der kontinuierlichen Integration hängt, und an echten Nutzungssignalen, die zurückfließen. Fehlt das, bleibt "präziser" nur ein Gefühl.
Der Schritt nach vorn: Vorverarbeitung, die nicht mehr im Dunkeln läuft
Dass die Vorverarbeitung zu einer beobachtbaren Station wird, ist ein Fortschritt, der bisher zu wenig beachtet wird. Tausende Dokumente komprimieren, konvertieren, einspielen – das läuft über Stunden. Wo es hakt, welche Datei still ausfällt, sieht der klassische Prozess nicht. UglyPear Daten hat in der jüngsten Datenengineering-Basis einen Schritt nach vorn gemacht: die Dokumentvorverarbeitung (Kompression, Formatkonvertierung und andere langlaufende Stapelaufgaben) wurde zu einer beobachtbaren Pipeline ausgebaut. Der Fortschritt ist sichtbar. Sie können erkennen, welcher Schritt langsamer wurde oder welche Datei fehlgeschlagen ist, und bei Bedarf zurückrollen sowie erneut versuchen.
Der Nutzen für Sie: kein schwarzes Warten mehr vor einer Konsole, und kein böses Erwachen am Ende, wenn die letzten 30 % der Dokumente gar nicht in die Datenbank gelangt sind. Dieser eine Fortschritt trennt "es läuft irgendwie" von "wir trauen uns, es in Produktion zu nehmen".
Warum diese Stationen wirklich greifen
Nützlicher als eine Funktionsliste ist die Erklärung, warum das Verfahren trägt.
Beginnen wir mit der Kompression. Die Situation ist vertraut: ein Vertrag der Rechtsabteilung wiegt schnell mehrere hundert Megabyte, und eine vollständige Aufnahme in die Datenbank zieht Speicher und Suche gleichermaßen in den Keller. Im Kern stecken in Dokumenten enorme Mengen an Wiederholungen, redundanten Objekten und neu kodierbaren Medien. Wer sie nach Verwendungszweck neu codiert, drückt das Volumen typischerweise um 60 % bis 80 %, während Texte und Stempel als Schlüsselinformation erhalten bleiben. Ihr Gewinn: dieselbe Suchdatenbank reagiert nach der Verschlankung schneller und kostengünstiger, und große Dateien bleiben nicht mehr an der Schwelle "lädt sich nicht ins Modell" hängen.
Dann das Retrieval. Wer nach dem Dateinamen "Lieferantenvereinbarung 2024" sucht, findet nichts, wenn genau dieser Name fehlt. Wer semantisch nach Inhalt sucht, versteht das Modell: "mit wem wurde geschlossen, worum ging es, wo steht die Klausel". Das ist der qualitative Sprung der semantischen Suche gegenüber dem Namensabgleich – sie liest Bedeutung, nicht Zeichen. Freilich rettet auch eine noch so starke Semantik keine schmutzige Eingabe. Die vorgelagerte Bereinigung und Segmentierung entscheidet, wie viel der semantischen Suche überhaupt gelingt.
Nun zur Bereitstellungsform. Bei sensiblen Dokumenten ist nicht die falsche Modellantwort die Hauptgefahr, sondern dass Daten das eigene Netz verlassen. Eine private Bereitstellung lässt die gesamte Vorverarbeitung und Suche auf Ihren eigenen Maschinen laufen, das Dokument verlässt das Firmennetz nicht, und der Compliance-Rahmen bleibt von Natur aus sauberer. Das verläuft auf einer anderen Linie als "wir kaufen ein größeres Cloud-Modell": einmal wird Daten herausgegeben für mehr Intelligenz, einmal bleibt die Intelligenz zu Hause.
Dass jeder Satz seine Herkunft trägt, verdient einen eigenen Satz, weil es oft als Beiwerk abgetan wird, tatsächlich aber Pflicht ist. In regulierten Branchen lässt sich eine Antwort, die nicht benennen kann, aus welcher Datei auf welcher Seite sie schöpft, weder prüfen noch zurechnen. Die Engineering-Basis setzt beim Zerlegen und Einspielen jedem Abschnitt eine Rückverfolgbarkeitsmarke auf und führt die Quelle beim Generieren mit – ein Punkt, den der Auftraggeber für "egal" halten mag, den der Fachmann aber als Abnahmegrenze betrachtet. Compliance nach vorn zu ziehen heißt genau das: die Regeln schon vor dem Einlagern des Dokuments festzulegen, statt sie nach einem Vorfall zu reparieren.
Es gibt noch eine Kostenrechnung, die gern verrechnet wird. Die Strafe für unterlassene Vorverarbeitung fällt nicht einmalig an, sie rollt weiter: die Suche wird zusehends unpräziser, das Vertrauen der Nutzer schwindet, am Ende wird die Datenbank schlicht nicht mehr genutzt, und die zuvor hineingesteckte Rechenleistung ist verbrannt. Umgekehrt steht die Qualität jeder einzelnen späteren Frage auf einem höheren Boden, wenn die Vorverarbeitung vorab solide steht – und der Grenzaufwand sinkt eher. Es geht nicht um eine gesparte Summe, es geht darum, ob dieser Weg überhaupt tragfähig ist.
Direkt werfen gegen vorher aufbereiten: eine Tabelle
Die folgende Übersicht stellt "Rohdatei direkt ins Modell" und "über die Engineering-Basis vorverarbeitet" auf einigen messbaren Dimensionen gegenüber:
| Dimension | Rohdatei direkt ins Modell | Über Datenengineering-Basis vorverarbeitet |
|---|---|---|
| Dokumentenvolumen | Original, oft mehrere hundert MB | nach Kompression typischerweise −60 % bis −80 % |
| Sensible Informationen | rohe PII / Geschäftsgeheimnisse offengelegt | 13 Kategorien sensibler Infos automatisch geschwärzt |
| Rückverfolgbarkeit | schwer zu sagen, welche Passage zitiert wurde | jeder Satz trägt seine Quelle, prüfbar |
| Steuerung langlaufender Aufgaben | Warten im Dunkeln, Fehler schwer zu lokalisieren | Fortschritt sichtbar, Fehler lokalisierbar, Rücksetzbar |
| Freundlichkeit für mehrere Modelle | große Dateien lassen sich oft in manche Modelle nicht laden | dieselbe verschlankte Datei lädt stabil über Modelle hinweg |
Drei Zahlen, die zeigen, warum man hier nicht sparen darf
Warum die Schwärzung nicht wegzulassen ist, beantwortet ein bemerkenswerter Wert aus dem IBM-Bericht "Cost of a Data Breach" von 2025: among den gestohlenen Daten entfielen 53 % auf Kundendaten (PII), 37 % auf Mitarbeiterdaten (PII) und 33 % auf geistiges Eigentum. Und geistiges Eigentum ist mit 178 USD pro Datensatz die teuerste Kategorie. Sobald eine Wissensdatenbank genau diese Felder unverändert herausgibt, ist das Risiko nicht "möglich", es ist eingetreten.
Hinzu kommt die verlorene Arbeitszeit. McKinsey beziffert, dass Wissensarbeiter rund 19 % ihrer Arbeitswoche damit verbringen, Informationen zu suchen und zusammenzutragen. Eine Datenbank, die wegen schlechter Vorverarbeitung die falschen Passagen liefert, vergrößert genau diesen verschwendeten Block weiter, statt ihn zu schrumpfen.
Auch die Speicherseite drückt. Laut einer Kundenbefragung von Komprise liegen 60 % bis 70 % der Unternehmensdaten auf dem primären NAS-Speicher seit über 90 Tagen ungenutzt herum – und belegen ausgerechnet die teuerste Storage-Ebene. Eine Wissensdatenbank, die nicht verschlankt und nicht schichtet, lässt diesen kalten Datenberg nur weiter anwachsen.
Zurück zum Anfang
Eine Wissensdatenbank, die falsch antwortet, scheitert in den meisten Fällen nicht am Modell, sondern an der Dokumentebene davor. Machen Sie die Vorverarbeitung zu einer beobachtbaren, rücksetzbaren Station, bei der Daten das Netz nicht verlassen – und erst danach reden wir über das Modell. Die Reihenfolge entscheidet. Wer sie vertauscht, drückt noch so viel Rechenleistung in ein undichtes Gefäß.
Jetzt ausprobieren
Möchten Sie die Dokumente Ihres Unternehmens tatsächlich nutzbar machen? UglyPear Daten bietet hier Ansätze:
- Produktübersicht und Datenengineering-Basis: https://www.uglypear.com/de/products/
- Private Bereitstellung und Dokumentvorverarbeitung: https://www.uglypear.com/de/products/
- Mehr Engineering-Praxis und Auswahlhilfen im Blog: https://www.uglypear.com/de/blog/
Häufige Fragen
Die Datenbank antwortet falsch – lieber ein größeres Modell oder die Daten ändern?
In den meisten Fällen sind es die Daten. Ein Modell, so stark es ist, bleibt durch die Qualität seiner Eingabe nach oben begrenzt. Erst wenn Kompression, Bereinigung, Segmentierung und Schwärzung der Dokumente stimmen, steigt das obere Limit der Suchqualität. Ein Modellwechsel hebt meist nur die "Decke", die Engineering-Basis festigt den "Boden".
Zerstört die Dokumentenkompression Stempel oder wesentliche Klauseln?
Nein. Die Kompression unterscheidet nach Verwendungszweck zwischen verlustfreier und verlustbehafteter Stufe: Texte, Stempel und Diagramme als Schlüsselinformation bleiben originalgetreu, redundante Objekte und Medien werden neu codiert. In einem öffentlichen Test wurde ein 443-seitiges OFD-Dokument in rund 124 Sekunden komprimiert, wobei Klarheit und Stempel erhalten blieben.
Wie funktioniert die Schwärzung sensibler Informationen, und werden Texte dabei beschädigt?
Es werden nach Regeln Kategorien wie Namen, Ausweise, Beträge und Geschäftsgeheimnisse erkannt und verdeckt – insgesamt 13 Kategorien. Es wird nur an den Stellen eingegriffen, die es betrifft; die Semantik des übrigen Textes bleibt weitgehend erhalten. Welche Felder konkret geschwärzt werden, sollte mit Ihrer eigenen Compliance-Liste abgestimmt werden.
Wo liegt der Unterschied zwischen privater Bereitstellung und einem Cloud-Modell?
Er liegt im Ort der Daten. Bei der privaten Bereitstellung laufen Vorverarbeitung und Suche vollständig in Ihrer eigenen Umgebung, das Dokument verlässt das Firmennetz nicht. Ein Cloud-Modell verlangt, den Inhalt nach außen zu senden, bevor es nutzbar wird. Bei Verträgen, Krankenakten oder Finanzdaten ist ein Verbleib vor Ort der sauberere Compliance-Rahmen – auch im Hinblick auf Datensouveränität und abgeschlossene Netze.
Braucht ein kleines Team mit wenigen Dokumenten überhaupt eine Datenengineering-Basis?
Entscheidend ist "unordentlich" statt "viel". Schon wenige tausend Dokumente lohnen, sobald Formate gemischt sind, sensible Felder enthalten oder langfristig archiviert werden sollen – eine beobachtbare Vorverarbeitung spart dann viel Nacharbeit. Bei geringer Menge lässt sich die Station obendrein leichter sauber einrichten und später mit dem Geschäft mitwachsen.