Sie öffnen Ihre Wissensdatenbank und tippen eine Frage so, wie Sie sie einem Kollegen stellen würden: „Wie viel haben wir letztes Jahr eigentlich verdient?"
Die Antwort? Oft eine Ansammlung fragwürdiger Auszüge. Oder der Assistent springt einfach eine Abteilung weiter. Das Modell ist nicht zu dumm. Es wurde nur mit dem falschen Material gefüttert, weil die vorgelagerte „Suche" die passende Stelle gar nicht erst gefunden hat.
Bei UglyPear Data beschäftigen wir uns seit Jahren mit der RAG-Datenengineering-Basis. Eine Erfahrung wiederholt sich: Die Retrieval-Ebene entscheidet darüber, ob eine private Wissensdatenbank taugt. Was dahintersteckt, lässt sich in einem ruhigen Blogbeitrag entfalten.
Ein Kontrast, der nachdenklich macht
Unternehmensdaten wachsen schneller, als die meisten Teams bewältigen. Eine Erhebung von Komprise zeigt: 60 bis 70 Prozent der Daten auf teurem Unternehmensspeicher bleiben länger als 90 Tage unangetastet – liegen aber nach wie vor auf teurem Primärspeicher. Das ist kein Ordnungsproblem allein. Es ist ein Zugriffsproblem.
Dazu passt, was McKinsey misst: Beschäftigte verbringen rund 19 Prozent der Arbeitswoche damit, Informationen zu suchen und zusammenzutragen. Etwa 1,5 Stunden täglich. Asana hat in ihrer „Anatomy of Work" noch etwas Gemessenes hinzugefügt: Nach einer Unterbrechung dauert die Wiederfokussierung etwa 23 Minuten, und im Schnitt wechseln Teams täglich rund 35 Anwendungen.
Die Rechnung ist ernüchternd. Je mehr Werkzeuge, desto mehr Kontextwechsel. Je mehr Daten, desto tiefer das Gefühl, im eigenen Archiv zu navigieren gleiche dem Suchen nach einem Schlüssel im Kehricht.
Und genau hier wird ein entscheidendes Muster sichtbar: Je natürlicher die Frage gestellt wird, desto schlechter führt klassische Schlüsselwortsuche. „Umsatzerlöse" und „wie viel wir verdient haben" liegen schriftlich weit auseinander. Wer die zweite Form ins Suchfeld tippt, geht oft leer aus.
Was semantische Suche eigentlich leistet
Schlüsselwortsuche prüft: Stimmen die Zeichen überein? Semantische Suche fragt: Liegen die Bedeutungen nah beieinander?
Der Mechanismus hinter dem Unterschied ist überschaubar erklärt. Dokumente werden in kleine Abschnitte zerlegt. Jeder Abschnitt wird in eine Folge von Zahlen überführt, die seine Bedeutung abbildet, und in einer Vektordatenbank abgelegt. Eine Frage wird zur Laufzeit in dieselbe Art von Bedeutungsdarstellung gebracht. Was nun gesucht wird, ist der nächste Nachbar im Bedeutungsraum. Dort sind „Umsatzerlöse" und „wie viel wir verdient haben" von Natur aus benachbart. Keine manuell gepflegte Synonymliste nötig.
Das ist der Grund, warum semantische Suche präziser trifft. Sie versteht Inhalt, nicht Zeichenketten. Für Sie als Leser heißt das: Sie dürfen umgangssprachlich fragen, mit Abkürzungen, mit Fachjargon – und das System hebt trotzdem den passenden Abschnitt hervor.
Ein Beispiel aus der Praxis. Ein Finanzteam will wissen: „Haben wir die Einkommensteuer für das letzte Jahr noch nachträglich gezahlt?" Die Schlüsselwortsuche klammert stur nach den Wörtern „Einkommensteuer" und „Veranlagung". Doch vermerkt steht das Ereignis vielleicht in einer betitelten Anmerkung irgendwo in einem Dokument namens „Steuerliche Hinweise". Semantische Suche interessiert sich nicht für die Buchstaben. Sie erkennt die Bedeutung. Also taucht jene Anmerkung auf.
Ein Schritt, der aus „Suchen" „Treffen" macht
Wir haben kürzlich die semantische Retrieval-Ebene über die gesamte Kette hinweg optimiert. Das Ergebnis lässt sich als Nutzen beschreiben: Alltägliche Fragen in umgangssprachlicher Form finden jetzt die richtige Stelle.
Konkreter gefasst: Die Vektorabdeckung wurde für das gesamte Korpus nachträglich vervollständigt, auch ältere Dokumente sind jetzt erfasst. Fragen in gesprochener Sprache werden verlässlicher aufgelöst. Die Antwortzeit von der Frage bis zur Ausgabe sank von mehreren hundert Sekunden auf etwa ein Dutzend. Und ein Satz von Regressionstests – formulierte Fragen einmal locker, einmal förmlich – traf durchgängig die Zielabschnitte.
Mit anderen Worten: Sie fragen „Haben wir Verlust gemacht?" oder „Woher kam das Geld?" und das System ortet genau jene Seite. Erst mit diesem Schritt wird aus einer Datenbank, die „suchen kann", eine, die „auf den Punkt antwortet".
Warum Retrieval und Komprimierung zusammengehören
Selten denkt jemand beide Schritte gemeinsam. In einer privaten Wissensdatenbank sind sie jedoch eng aufeinander bezogen.
Ein Dokument, das vor dem Einlagern voluminös und redundant ist, bläht die Vektordatenbank auf. Die Suche wird langsamer und teurer. Wer Verträge, Berichte und Entwürfe einmal im Sinne ihrer Bedeutung komprimiert, verringert das Volumen. Sauberere Semantikblöcke, schnellere Suche. Bei UglyPear Data ist der Pfad, beides – Komprimierung und RAG-Datenengineering – als Einheit zu behandeln: vorn das Dokument verschlanken, hinten die Suche präzisieren, die Daten verlassen dabei durchgehend das Kundennetz nicht. Mehr zur gemeinsamen Behandlung beider Schritte finden Sie hier: https://www.uglypear.com/de/products/
Wer also auswählt, sollte nicht nur auf Modellparameter starren. Oft bringt die Abstimmung von Komprimierung und Retrieval spürbar mehr als der Wechsel zu einem größeren Modell.
Drei Ansätze nebeneinander
Beim Auswählen herrscht leicht Verwirrung, weil alles „Suche" heißt. Die Tabelle unten stellt die Unterschiede auf einheitlichen, vergleichbaren Dimensionen dar.
| Dimension | Schlüsselwortsuche | Generische semantische Suche | Private semantische Suche (RAG-Basis) |
|---|---|---|---|
| Verständnisweise | exakte Zeichen | Bedeutungsnähe | Bedeutungsnähe |
| Umgangssprachliche Fragen | kaum | weitgehend | verlässlich, Regressionstreffer |
| Verbleib der Daten | lokal oder Cloud | meist Public Cloud | durchgehend im eigenen Netz |
| Antwortzeit | schnell | mittel | etwa ein Dutzend Sekunden |
| Sensible Inhalte | manuell geprüft | Plattformrichtlinie | automatische Anonymisierung |
| Geeignet für | wenige, strukturierte Dateien | öffentliche FAQ | Verträge, Berichte, Intranet |
Die Tabelle vereinfacht die Entscheidung. Liegen Ihre Daten offen, reichen die beiden zuvor genannten Spalten. Handelt es sich um Verträge, Vergütungen, Patientenakten oder Kundenlisten – um Dinge, die „das Haus nicht verlassen dürfen" –, führt kein Weg an der dritten Spalte vorbei. Hintergründe zu den einzelnen Dimensionen sind im Blog dokumentiert: https://www.uglypear.com/de/blog/
Die andere Seite der Datenhortung
Viele Teams sammeln, weil Speicher günstig wirkt. Das eigentliche Problem ist jedoch nicht das Haben, sondern das Nutzbar-Machen. Dateien türmen sich nicht, weil ein Ordnungswerkzeug fehlt. Sie türmen sich, weil jeder Griff danach dem Suchen nach einem Schlüssel im Kehricht gleicht. Solange die Suche nur auf Dateinamen und Augen vertraut, wächst mit der Datenmenge die Last.
Private semantische Suche setzt genau hier an. Sie löscht Ihre Dateien nicht. Sie macht es möglich, mit einem Satz die richtige Stelle zu heben. Die Daten ruhen weiterhin ruhig in Ihrem Netz. Niemand hat sie mitgenommen.
Warum „privat" betont wird
Manche Teams nehmen beim anfänglichen Aufbau aus Bequemlichkeit eine Public-Cloud-Lösung. Dann tauchen Verträge, Vergütungslisten, Patientenakten außerhalb des eigenen Netzes auf – und entziehen sich der Kontrolle.
Die RAG-Datenengineering-Basis von UglyPear Data setzt auf durchgehend private Bereitstellung. Rohdaten werden nicht verschoben, nicht aus dem Bereich geführt. Suche und Antwort laufen im Netz des Kunden. Die Basis bringt zudem automatische Anonymisierung für verschiedene Klassen sensibler Inhalte mit – etwa Identifikationsnummern in Verträgen oder Betragsfelder in Berichten, die vor dem Einlagern erkannt und behandelt werden. Wie genau das intern geschieht, bleibt außerhalb dieses Beitrags. Mehr zur privaten Bereitstellung finden Sie hier: https://www.uglypear.com/de/products/
Für Unternehmen bedeutet das zweierlei zugleich: Die Datenbank versteht die Geschäftssprache wirklich, und die Geschäftsdaten haben die Server nie verlassen.
Ein Krankenhaus mittlerer Größe schilderte uns eine vergleichbare Lage. Patientenakten und Bilddaten dürfen niemand berühren, doch die Klinik möchte „mit einem Satz die Vorgeschichte einer Patientengruppe aufrufen". Public Cloud fiel aus Compliance-Gründen sofort weg. Übrig blieb der durchgehend private Weg: Suche und Antwort laufen in den Räumen der Klinik, sensible Felder werden vor dem Einlagern anonymisiert. Ärzte fragen flüssig, die Revision findet nichts zu beanstanden. In solchen Fällen ist „nicht außerhalb des Netzes" kein Bonus. Es ist die Bedingung.
Wer dieses Thema ernst nehmen sollte
Einige Teamtypen profitieren besonders. Rechtsabteilungen und Finanzteams mit tausenden Verträgen, Belegen, Registern. Fertigung und Gesundheitswesen, wo Pläne, Akten, Verfahrensdokumente zugleich fachlich und sensibel sind. Und jedes Team, in dem das Wissen „im Kopf der erfahrenen Leute" steckt und Neue halbe Tage suchen.
Wenn Ihr Problem nicht „zu wenig Daten" lautet, sondern „Daten da, aber nicht abrufbar – und beim Abruf nicht vertrauenswürdig nutzbar", dann liegt der Engpass vermutlich im Retrieval. Nicht bei einem teureren Modell. Weitere Engineering-Praktiken und Auswahlüberlegungen sind im Blog dokumentiert: https://www.uglypear.com/de/blog/
Häufige Fragen
F: Worin unterscheiden sich semantische Suche und das direkte Fragen an ein Sprachmodell?
A: Ein Sprachmodell kennt Ihre internen Dokumente von sich aus nicht. Die semantische Suche besorgt den Schritt „relevante Abschnitte aus Ihren Unterlagen finden". Das Modell übernimmt den Schritt „daraus eine Antwort formen". Beide zusammen sorgen dafür, dass nicht frei erfundene Antworten entstehen.
F: Ist private Bereitstellung nicht langsam?
A: Früher traf das zu, meist weil Vektoren unvollständig und die Kette unoptimiert war. Nach vollständiger Vektorabdeckung und optimierter Retrieval-Kette liegt die Antwortzeit in einem zumutbaren Bereich – im konkreten Fall etwa ein Dutzend Sekunden von Frage bis Ausgabe.
F: Wie bleiben sensible Inhalte im eigenen Netz?
A: Bei durchgehender privater Bereitstellung werden Rohdaten nicht verschoben und nicht aus dem Bereich geführt. Suche und Antwort laufen im Kundennetz. Die Basis anonymisiert verschiedene Klassen sensibler Inhalte vor dem Einlagern automatisch, statt jede Datei von Hand zu prüfen.
F: Unsere Dateiformate sind sehr gemischt – passen die in eine Datenbank?
A: Verträge, Berichte, Tickets, Entwürfe, Sitzungsprotokolle – gängige Formate lassen sich aufnehmen. Die Voraussetzung ist eine vorgeschaltete Komprimierung und Formatierung, die Volumen und Redundanz senkt, damit die Suche effizient bleibt.
F: Braucht man für den Aufbau ein großes Team?
A: Nein. Entscheidend sind eine klare Retrieval- und Anonymisierungsstrategie sowie die Fähigkeit zur privaten Bereitstellung. Ein kleines Team mit der passenden Basis verwandelt verstreute Unterlagen in einen Assistenten, den man „mit einem Satz" befragt.
Jetzt ausprobieren
Sie möchten sehen, wie private semantische Suche in der Praxis läuft? Die RAG-Datenengineering-Basis von UglyPear Data ist hier beschrieben: https://www.uglypear.com/de/products/
Engineering-Erfahrungen und Auswahlstrategien aus dem laufenden Betrieb finden Sie im Blog: https://www.uglypear.com/de/blog/
Wenn Ihre Dokumente zugleich zahlreich, unübersichtlich und netzgebunden sind, empfiehlt sich ein begrenzter Probebetrieb. Starten Sie mit dem Wissensbestand einer Abteilung, klären Sie Retrieval und Anonymisierung, und erst dann entscheiden Sie über die Ausweitung. Sprechen Sie uns an: https://www.uglypear.com/de/kontakt/