Stellen Sie sich vor, Sie kippen sämtliche Dokumente Ihres Unternehmens – Verträge, Research-Notizen, Transkripte, hunderte Seiten an Scans – ungefiltert in ein "intelligentes System". Was glauben Sie, macht es damit? Wer das je erlebt hat, gibt gewöhnlich dieselbe ehrliche Antwort: Entweder es weigert sich, die Dinge überhaupt anzunehmen. Oder es nimmt sie und beantwortet dann die falsche Frage. Oder die Rechnung steigt leise.
Komprise stößt in Unternehmensspeichern immer wieder auf dasselbe Bild: zwischen 60 und 70 Prozent der Daten auf den teuren Primärspeichern werden seit über 90 Tagen nicht mehr angerührt. McKinsey rechnet den menschlichen Preis vor: Wissensarbeiter verbringen fast 19 Prozent der Arbeitswoche, etwa anderthalb Stunden am Tag, allein damit, Informationen zu suchen und zusammenzutragen. Asana legt noch den Unterbrechungs-Zoll oben drauf: nach einer Störung braucht es rund 23 Minuten, um den Fokus zurückzugewinnen, und Menschen springen täglich zwischen etwa 35 Anwendungen hin und her. Schlecht behandelte Dokumente fressen nicht nur Festplattenplatz. Sie vervielfachen leise die Kosten jeder einzelnen Unterbrechung.
Ein Neuling, der vor diesem "Problem" steht, greift gewöhnlich zu zwei Dingen: einem Werkzeug, das die Dateien verkleinert, oder einer Vektor-Datenbank, damit sich der Haufen durchsuchen lässt. Menschen, die solche Systeme produktiv betrieben haben, fangen dort nicht an.
Sie stellen eine andere Frage an den Anfang. Nicht "welches Werkzeug", sondern "warum muss diese Daten überhaupt verändert werden". Um Speicher zu sparen? Damit Anhänge per E-Mail versendbar bleiben? Um beim Beantworten von Fragen durch ein Modell weniger Token zu verbrauchen? Oder um ein revisionssicheres Archiv zu führen, das ein Jahrzehnt unverändert überstehen muss? Derselbe Haufen, auf verschiedene Ziele gerichtet, verlangt völlig unterschiedliche Behandlung. Wer das Terrain kennt, nagelt die Randbedingungen fest, bevor er etwas anrührt – statt "komprimieren" oder "Vektorindex drauf" zum Standardreflex zu machen.
Sind die Randbedingungen festgenagelt, folgt als nächstes, den Haufen nach dem zu sortieren, was er wirklich ist. Ein unterzeichneter Vertrags-PDF mit rotem Stempel, ein 4K-Ingenieur-Scan und ein 200-seitiger Regulierungsbericht sind drei verschiedene Wesen. Der Vertrag braucht Struktur und Stempel bis aufs Zeichen erhalten. Der Scan ist voller redundanter Pixel. Der Bericht schleppt wiederholte Layout-Muster mit. Ein "Default-Compression" über alle drei hinweg zu jagen, liefert in der Regel Ergebnisse, bei denen beides schiefgeht: was scharf bleiben sollte, wird weich; was schrumpfen sollte, rührt sich nicht. Genau hier gehen Amateur und Profi auseinander – der Amateur schaut auf "wie viel es geschrumpft ist", der Profi schaut auf "was darf sich niemals bewegen".
Eine Ebene tiefer kehrt der Profi zur Information selbst zurück. Warum ist eine Datei groß? Ein Scan ist groß, weil er ein dichtes Raster ist, voll mit Redundanz, die das Auge nicht unterscheiden kann, die Bytes aber sehr wohl. Ein Textdokument ist groß wegen wiederholter Struktur und eingebetteter Objekte. Ob und wie komprimiert wird, folgt also nicht einer Voreinstellung – es folgt dem Verwendungszweck. Was ein Jahrzehnt als rechtliches Artefakt überdauern soll, geht verlustfrei und reversibel. Was auf dem Bildschirm kurz angesehen oder in eine Mail gequetscht wird, geht verlustbehaftet, behält aber, was zählt. Den Schalter zwischen verlustfrei und verlustbehaftet dem Default wieder abzunehmen, ist die Grenze zwischen Profi und Werkzeug-Standardverhalten.
Klassifiziert man falsch, bricht alles danach. Einen Vertrag versehentlich als verlustbehaftet markieren und der Stempel verschwimmt – das ist ein Vorfall. Einen Scan, der verlustbehaftet gehört, gewaltsam verlustfrei halten, und die Größe rührt sich nicht, während die ganze Pipeline langsamer wird. Darum verbringt der Profi lieber zehn Minuten am Anfang damit, zu fragen "in welchen Eimer gehört das, und wer nutzt es danach", statt später eine Katastrophe aufzuwischen. Klassifikation ist keine Formalie im Workflow. Sie ist das Fundament, auf dem alles andere ruht.
Ein kleines Beispiel. Ein gescannter Vertrag lebt und stirbt mit seinem Stempel und Unterzeichnungsdatum – verschwimmt das, haben Sie das Dokument rechtlich verändert. Ein medizinisches Bild, komprimieren Sie die falsche Kante weg, verstecken Sie genau den Befund, der zählt. Der Amateur sieht "sechzig Prozent kleiner" und freut sich. Der Profi fragt "ist in diesen sechzig Prozent etwas, das sich nicht bewegen darf". Vor dem Komprimieren fragt der Profi, wer dadurch Schaden nimmt, dass sich "etwas ändert". Die Antwort entscheidet, ob und wie überhaupt komprimiert wird.
Es gibt noch eine Schicht, die Neulinge übersehen: dasselbe Dokument liegt oft in mehreren Systemen mit widersprüchlichen Versionen. Der Profi gleicht Duplikate und Versionen aus, bevor er von Komprimierung oder Suche redet – denn auf schmutzigen Daten zu indexieren garantiert schlechte Retrieval-Qualität, egal was danach kommt. Und die Kosten muss man als Ganzes rechnen: Embeddings einmal berechnet, Reranking einmal gelaufen, das Modell liest es einmal – wo Token wirklich etwas bringen, zieht man extra Passagen und lässt das Modell wählen, oder pre-rankt man und zieht weniger? Bis diese Rechnung klar ist, ist "sparen" nur ein Slogan. Gerade in retrieval-augmentierten Setups wird jede gezogene Passage vom Modell noch einmal gelesen, also zahlen schmutzige Dokumente und achtlose Chunks monatlich auf der Token-Rechnung Zinsen. Vorher komprimieren, vorher aufräumen – oft günstiger, als später ein größeres Modell zu kaufen.
Menschen, die so etwas ausgeliefert haben, behandeln eine Wissensdatenbank als laufendes System, nicht als Upload. Die Dokumente ändern sich, das Geschäft ändert sich, was heute richtig beantwortet wird, kann nächsten Monat beim neuen Release straucheln. Darum lassen sie von Tag eins Platz für ein Evaluation-Set und Rollback, und behandeln "bauen" und "pflegen" als denselben Job. Das erklärt, warum so viele Demos blenden und dann in Produktion einbrechen: eine Demo beweist, dass das System irgendwas zurückgibt; Produktion verlangt, dass es auf echten, chaotischen, sich verschiebenden Dokumenten dauerhaft richtig antwortet. Wer "gibt was zurück" als Ziel sieht und wer es als Startpunkt sieht, baut völlig verschiedene Systeme.
Viele nehmen an, Komprimierung und Retrieval seien zwei getrennte Jobs. Der Profi nicht. Er sieht "aufräumen, schrumpfen, chunken, embedden, retrieven, antworten" als eine Linie, und vertraut nur dem Ergebnis der ganzen Linie, keiner isolierten hübschen Zahl. Und vor Komprimierung und Retrieval steht gewöhnlich ein Aufräumschritt – dieselbe Materie verstreut über ein Dutzend Ordner mit chaotischen Namen. Der Profi klärt vorab, wohin es gehört und nach welcher Achse zu klassifizieren ist, denn selbst ein durchdachtes Retrieval rettet kein Dokument, das am falschen Ort abgelegt ist. Ein sauber komprimierteres Dokument trägt weniger Rauschen ins Retrieval, verbraucht weniger Token, ruft verlässlicher ab – Komprimierung ist hier kein Speicher-Gratisbonus, sie ist Vorbereitungsschritt für Retrieval-Qualität. Und wenn Retrieval dauernd am Thema vorbeiantwortet, schiebt der Profi nicht gleich dem Modell die Schuld zu; er geht zurück und fragt, ob ein Chunk einen Satz in der Mitte zersägt hat, ob eine umgangssprachliche Frage schlicht per wörtlicher Suche nicht zu fassen ist, ob die relevante Passage abgeschnitten wurde.
Beim Retrieval-Schritt sieht die Werkzeugkiste des Profis anders aus, als Amateure sich das vorstellen. Er wirft die rohe Frage nicht einfach rein. Echte Nutzer fragen im Slang, in Abkürzungen, in Synonymen, packen oft drei Intentionen in einen Satz – das saubere "nennen Sie die Rückerstattungsrichtlinie" aus Evaluation-Sets taucht in der Realität fast nie auf. Also macht er Hybrid-Retrieval: ein Keyword-Pfad für exakte Treffer, ein semantischer Pfad für Bedeutung, zusammengeführt, und die Fehlerrate sinkt sofort. Nach dem ersten Durchlauf schiebt ein Reranker das wirklich Relevante nach oben. Bei harten Fragen schreibt er einen umgangssprachlichen Satz in mehrere retrieval-freundliche Sub-Queries um, sucht jede einzeln, setzt dann zusammen. Berechtigungen und Quellen filtert er vorab, damit nichts Vertrauliches nach außen gelangt.
Nichts davon dient der Show. Es zeigt alles auf ein Ziel: "antwortet richtig" von Glück zu einer messbaren Metrik zu machen. Genau das ist der Satz Dinge, den niemand verlangt, den der Profi aber immer tut – eine Charge gelabelter Frage-Antwort-Paare mit zitierter Ground Truth noch bevor überhaupt Code geschrieben wird, denn ohne das hat "richtig" keine Definition; die Miss-Rate und Off-Topic-Rate nach Fragetyp zu bucketn, damit man auf einen Blick sieht, welche Kategorie dauernd einbricht; das alte Evaluation-Set nach jedem KB-Update neu zu werfen, um den stillen Verfall "heute richtig, nächsten Monat falsch" zu erwischen. Wer tiefer in diese Arbeitsweise einsteigen will, findet Praxisbeispiele im technischen Blog von UglyPear Data: https://www.uglypear.com/de/blog/
Also, warum irgendwas davon glauben? Nicht, weil ein Anbieter sagt "wir sind akkurat", und nicht, weil ein Käufer hofft "wird schon reichen". Was hält, ist, was eine dritte Partei ebenfalls reproduzieren kann: ein unabhängig gelabeltes goldenes Frage-Set, bei dem jeder, der Ihr System auf denselben Labels neu wirft, Ihr recall@k und Ihre Faithfulness auf dem Tisch sieht; Blindtests, bei denen neue und alte Pipelines echte Fragen anonym von unabhängigen Evaluatoren prüfen lassen, mit einer Lücke, die nicht auf "wir haben es intern getestet" lehnt; und eine Regression-Suite, in der die Fälle, von denen bekannt ist, dass sie korrekt sind, korrekt bleiben müssen, mit rot-grün-Status zur Einsicht. Dasselbe gilt für die Komprimierung selbst – lässt sich das komprimierte Dokument exakt wie vorher öffnen, ist der Stempel da, hat sich das Layout verschoben? Aufmachen und mit dem Original vergleichen. Nach dem Schrumpfen: wie viele Token sind wirklich weggefallen, hält das Retrieval noch? Die Downstream-Aufgabe durchlaufen, und Sie haben die Antwort. Korrektheit kommt nicht aus dem Versprechen irgendwem. Sie kommt aus Handlungen, die jeder verifizieren kann.
Am Ende ist der ganze Ansatz oben keine Produkt-Feature-Liste. Es ist eine Gewohnheit: erst fragen warum, dann wie; "richtig" definieren, bevor man über "schnell" und "günstig" redet; und beweisen, dass es wirklich richtig ist, mit Handlungen, die jeder reproduzieren kann, nicht mit Slogans.
Wir haben kürzlich einen kleinen Schritt an der Naht zwischen Komprimierung und Retrieval gemacht: wir haben die vorgeschaltete Dokumenten-Komprimierung so adaptiert, dass sie stabil über mehrere gängige große Modelle hinweg läuft, sodass dasselbe verschlankte Dokument von unterschiedlichen Modellen zuverlässig gelesen und genutzt werden kann. Genau das ist die oben beschriebene Hürde – schrumpf es, und es darf dem Modell nicht unlesbar werden. Es ist weit entfernt von der vollen Engineering-Tiefe, aber die Richtung stimmt: "klein" und "lesbar" als eine Sache zu behandeln und daraufhin Evaluation, Reranking und Observability aufzusetzen. Die zugrunde liegende Produktlogik skizzieren wir hier: https://www.uglypear.com/de/products/
Wer die Linie "klein und lesbar" zusammen mit semantischem Retrieval in der Praxis sehen will, findet weitere Einblicke und Hinweise zur Umsetzung ebenfalls im Blog: https://www.uglypear.com/de/blog/
Die Tabelle unten stellt das Default-Verhalten von Werkzeugen dem Vorgehen eines Profis an einigen entscheidenden Punkten gegenüber.
| Entscheidender Punkt | Default-Verhalten des Werkzeugs | Vorgehen eines Profis |
|---|---|---|
| Ausgangspunkt | Direkt komprimieren / direkt Vektorindex | Randbedingungen festnageln, warum Daten sich ändern muss |
| Dokumentenbehandlung | Eine Default-Compression für alles | Nach Vertrag / Scan / Bericht klassifizieren, dann wählen |
| Verlustfrei oder verlustbehaftet | Der Voreinstellung folgen | Nach Zweck entscheiden: verlustfrei fürs Archiv, verlustbehaftet für Vorschau |
| Komprimierung vs. Retrieval | Als zwei Jobs behandelt | Eine Linie, nur das Ergebnis der Gesamtlinie zählt |
| Abfrage | Roher Satz durchsuchen | Hybrid-Retrieval + Reranking + Umschreiben/Zerlegen |
| Qualitätsnachweis | Eigenbehauptung des Anbieters | Gelabeltes Golden-Set + Blind-A/B + Regression-Suite |
Jetzt ausprobieren
Um einen Ansatz zu sehen, der "Private Deployment, Datenhoheit, Daten verlassen nie das eigene Netz, Komprimierung und semantisches Retrieval" – ob air-gapped oder local-first – zu einer Produktionslinie verschweißt:
Häufige Fragen
F: Mein kleines Unternehmen hat gar nicht viele Dokumente. Reicht Default-Komprimierung nicht?
A: Es kommt darauf an, was die Dokumente leisten sollen. Einen Datei intern weiterzureichen, geht mit Default-Komprimierung in der Regel in Ordnung. Sobald Dokumente aber ins Retrieval wandern, ein Modell füttern oder als Beweis bestehen müssen, macht der Unterschied zwischen Klassifikation und Strategie durchaus etwas aus.
F: Kann ein komprimiertes Dokument noch als rechtlicher Beleg dienen?
A: Das hängt von der Methode ab. Archiv-Klasse läuft verlustfrei und reversibel, Inhalt und Stempel bleiben unverändert, also taugt es als Beleg. Vorschau-Klasse verlustbehaftet dient nur dem schnellen Hinsehen. Entscheidend ist nicht "wurde es komprimiert", sondern "welchen Pfad nahm dieser Typ".
F: Hybrid-Retrieval klingt aufwendig. Kann sich ein kleines Team das leisten?
A: Im Kern ist es "Keyword plus semantisch" zusammengeführt, dann ein Reranker – beides gibt es in offenen Implementierungen. Die Hürde ist nicht Geld, sondern die Bereitschaft, "antwortet richtig" als etwas zu begreifen, das man laufend misst.
F: Woran erkenne ich, ob eine Wissensdatenbank wirklich richtig antwortet?
A: Trauen Sie der Demo nicht. Sie brauchen ein gelabeltes Standard-Frage-Antwort-Set, eine neu ausführbare Evaluation, dazu Blindtest und Regression. Kann eine dritte Partei Ihr System auf denselben Standard neu werfen, hält die Schlussfolgerung.
F: Müssen Komprimierung und RAG zwingend zusammen gemacht werden?
A: Nicht vom selben Anbieter, aber sie müssen als eine Linie gedacht werden. Ein sauber komprimiertes Dokument trägt weniger Rauschen ins Retrieval, verbraucht weniger Token, ruft verlässlicher ab – wer beides trennt, blutet gewöhnlich an beiden Enden.