Semantische Suche mit RAG (symbolische KI und generative KI)
Wir sind ein Unternehmen aus Düsseldorf, das seit 17 Jahren erfolgreich ein Kernprodukt entwickelt und vermarktet: semantische Suche mit symbolischer KI. Dabei bilden KMU mit dem Einsatzfeld Enterprise-Search (d.h. möglichst vollständige Einbindung aller Dokumentquellen eines Unternehmens) eines unser Hauptkundensegmente. Dort würden wir auch die für JEN ideale Lösung sehen. Als Sprachen stehen bei uns im Vordergrund Deutsch und Englisch (für das automatische Sprachverstehen mit Bedeutungsrepräsentation). In den letzten Jahren haben wir auch generative KI eingebunden. Dies ist optional und funktioniert als lokales RAG mit Ansteuerung über die semantische Suche.
Das konzeptionelle Fundament der Lösung ist die automatische Erzeugung von Bedeutungsrepräsentationen zu Texten und Suchanfragen. Auf dieser Basis können Umformulierungen gefunden werden, was wichtig ist, da oft die Formulierung in der Suchanfrage von den relevanten Formulierungen in den Dokumenten abweicht. Der Zusammenhang kann - auf Wunsch - immer automatisch belegt werden durch Anzeige der verwendeten Fakten und Regeln.
Aussagekräftige Textsnippets enthalten wortgetreue Zitate aus den Dokumenten des Kunden mit gezielter Verlinkung, bei PDFs z.B. auch zur betreffenden Seite. Wenn keine Treffer gefunden werden, wird dies klar kommuniziert. Durch verschiedene Feedback-Komponenten (Rechtschreibprüfung, interaktive Suchvorschläge und Anfrage-Kritiker) wird hilfreiches Feedback gegeben.
Als Rückfall-Strategie werden auch Treffer aus der klassischen Stichwort-orientierten Suche angeboten. Diese Treffer kommen mit einer schlechteren Bewertung als die semantischen Treffer und daher weiter hinten in der Trefferliste. Die Lösung ist seit Jahren im Markt, wird aber fortwährend weiterentwickelt. Synergien zwischen allen Suchmaschinen-Installationen befeuern die Entwicklung.
Unsere Lösung ist besonders gut geeignet, da die meisten der genannten Anforderungen schon erfolgreich gelöst wurden, was auch bei zahlenden Kunden belegt ist. Dubletten-Erkennung ist bei vielen unserer Kunden zentral. Wir haben mittlerweile 5 unabhängige Algorithmen, die dafür sorgen, dass die meisten Duplikate erkannt werden und nur eines für die Suche indexiert wird. Die anderen Duplikate können aber mit Ihrer URL oder Dateipfad auf Wunsch angezeigt werden. Die Größe der Dokumente ist unproblematisch, da wir erfolgreich mit PDFs mit vielen Hundert Seiten arbeiten. (Es kommen sogenannte Kontextfenster von bspw. 10 bis 16 Sätzen zum Einsatz.) OCR wird bei denjenigen PDFs eingesetzt, bei denen keine Texte oder nur schlechte Texte aus einer veralteten OCR hinterlegt sind.
Sicherheit und Administrierbarkeit. Es wird minimal, lokal und nur anonymisiert geloggt. Alleiniges Ziel des Logging ist die Verbesserung der Suchinstallation. Die Software kommuniziert nicht mit dem Internet. Ein Monitoring informiert die Administrator:innen (standardmäßig beim Anbieter, auf Wunsch auch beim Kunden), falls Komponenten ausfallen sollten. Durch die redundante Auslegung sind Nutzer:innen sehr selten betroffen. Backups des Software-Standes und der Such-Indices werden automatisch lokal vorgenommen und können bei Bedarf zurückgespielt werden (durch Anbieter oder Kunde).
In 3 wurden die erfüllten Anforderungen angesprochen. Da es im Enterprise-Umfeld eine Unmenge an Systemen (CMS, DMS, Wiki etc.) gibt, ist es wahrscheinlich, dass für das eine oder andere Systeme eine Anbindung (Konnektor) entwickelt werden muss. Für uns wären die DMS-Systeme nscale und windream mit neuen Konnektoren zu versehen. Die Entwicklungskosten würden wir - je nach Verbreitung des anzubindenden Systems - ganz oder teilweise übernehmen. Im Gegenzug würden wir die Beistellung von Information und Expertise zu diesen Systemen erwarten. Weitere Punkte, die wir noch nicht abdecken, folgen. 1. Zusammenfassungen. Diese könnten z.B. durch das LLM im RAG-System (s.u.) realisiert werden. 2. Versionserkennung. Diese kann anhand von Zeitstempeln im System und/oder Dateinamen und inhaltlicher Analyse passieren.
Unsere Suchmaschine läuft unter gängigen Linux-Distributionen wie Debian, Ubuntu, Fedora u.a. Die Anbindung von Microsoft-Dateisystemen zur Indexierung ist schon häufig eingesetzt worden, auch im Zusammenspiel mit Active Directory. Für den SharePoint, den unser Crawler indexieren wird, müsste ein Rechteexport von JEN beigestellt werden. Auch dies haben wir mehrfach umgesetzt. Die Suchmaschine bildet das Rechtesystem nach und berücksichtigt es in allen Komponenten, auch im RAG, so dass niemand unberechtigt Dokumente (wörtlich oder generiert) zu sehen bekommt, für die er keine Leserechte hat.
Ein erster Pilotbetrieb ist aus unserer Erfahrung sinnvoll, auch wenn die eine oder andere Informationsquelle noch nicht indexiert ist. Wir würden nach 4 bis 6 Monaten ein Pilotsystem anstreben. Als Betriebsmodell unterstützen wir SaaS (mit Rechnern in einem renommierten deutschem Rechenzentrum), On-Premise oder Server bei uns in Düsseldorf. Wir würden vor unserem jetzigen Kenntnisstand einen On-Premise-Betrieb empfehlen mit einem sicheren Fernzugriff per SSH (o.ä.). Als Kosten schätzen wir grob 15 bis 20 TEUR (alle Angaben ohne Mwst.).
Die Nutzung der Suchsoftware (inkl. Wartung als Fernwartung) wird mit einer Monatsgebühr angeboten, die sich nach den unten genannten Hauptparametern richtet (größenordnungsmäßig 600 bis 1200 EUR). Die Ersteinrichtung berechnet sich zu 2 bis 6 Monatsgebühren plus einen Eigenanteil bei neuen Konnektoren, den wir oben schon einkalkuliert haben. Im Regelbetrieb fallen dann nur diese Monatsgebühren und Hardware-Kosten (Hardware-Miete oder regelmäßiger Hardware-Neukauf z.B. nach 4 bis 6 Jahren, s. 6.) an.
Als weitere Beistellung des Kunden ist eine Kopplung des Nutzerpasswort-Systems mit dem Account-System der Suchmaschine zu unterstützen. In einfachster Form reicht eine Beistellung von Account-Namen mit Mail-Adresse. Ein Login ist bei der Suchmaschine nötig, um ein komfortables Such-Cockpit mit zurückliegenden Suchanfragen und Ergebnissen, Alerting (bei neuen Treffern zu hinterlegten Suchanfragen) etc. umsetzen zu können.
Unsere Suchlösungen kalkulieren wir technisch und kaufmännisch nach folgenden Hauptparametern: Größe der Dokumenten-Sammlung (in Sätzen oder Wörtern), Volumen der monatlichen Änderungen (neue und geänderte Dokument), durchschnittliche Anzahl der Suchanfragen pro Tag, maximale Anzahl gleichzeitiger Suchanfragen, gewünschte Häufigkeit der Index-Aktualisierung. Unsere Lösung ist frei von Clouds und jeglicher Drittsoftware und kann komplett On-Premise und ohne Internet betrieben werden.
Wir gehen momentan von folgenden Größen-Annahmen aus (s. Hauptparameter oben): 1 Millionen Dokumente (laut JEN) à 200 Sätze (im Schnitt), Änderungsvolumen von 1 % pro Monat, 500 Suchanfragen pro Tag, maximal 8 gleichzeitige Anfragen (die in der Challenge genannte Zahl 30 wäre empirisch zu prüfen und würde zu höheren Hardwarekosten führen), 1-3 Indexupdates pro Woche. Verschiebungen nach unten oder oben sind meist unproblematisch und klären sich während der Pilot-Vorbereitung.
Wir würden von 8 Suchinstanzen verteilt auf 2 Linux-Servern ausgehen. Jeder Linux-Server mit jeweils mindestens 16 physischen CPU-Kernen, 96 GB RAM, 2 NVME-SSDs mit 4 TB - je nach Analyse der in der Challenge genannten 50 TB könnte der SSD-Bedarf etwas wachsen. Unsere Kunden wählen zwischen Server-Hardware und Consumer-Hardware, wobei oft letztere ein deutlich besseres Preis-Leistungs-Verhältnis bietet. Die Hardware kann vom Kunden anhand unserer Spezifikation beschafft oder bereitgestellt werden, oder wir liefern vollständig konfigurierte Rechner zur Miete oder Kauf aus.
Die RAG-Option ist angesichts der aktuellen Hardware-Knappheiten schwierig zu kalkulieren. Man könnte mit einem soliden offenen Sprachmodell (z.B. von Mistral AI) starten, das pro Server z.B. mit einer GPU mit 32 GB VRAM auskommt.
Denkbar wäre auch, die RAG-Option erst nach einem Pilotbetrieb von z.B. 6 bis 12 Monaten anzuschalten, um ggf. die Entwicklung bei Hardware und LLMs etwas abzuwarten. Bei unserer RAG-Komponente kann das verwendete LLM relativ einfach getauscht werden (durch Anpassung der automatischen Prompt-Anteile).
Bei uns sticht ein Kunde unter den Kunden, die eine Referenznennung erlaubt haben, heraus. (Aus strategischen, wettbewerblichen oder rechtlichen Gründen haben uns die meisten Kunden die Referenznennung leider nicht erlaubt!) Dessen Installationsbericht und Anforderungen stimmen weitgehend mit denen von JEN überein. Das reduziert das Risiko auf beiden Seiten (Dienstleister und Kunde) ganz massiv. Es handelt sich um ein deutsches KMU mit über 100 Mitarbeiter:innen und ähnlichen Dokumentenvolumina wie bei JEN. Weitere Details finden Sie im letzten Abschnitt 9 (Geschützte Angaben).
Zunächst möchten wir darauf verweisen, dass wir schon 17 Jahre mit unserem Kernprodukt semantische Suche unterwegs sind. Insbesondere haben wir Erfahrung, in welchen Abständen und in welcher Abfolge Komponenten Versionssprünge machen oder komplett durch neue Technologien ersetzt werden sollten. Dort kann auch viel Erfahrung zwischen ganz verschiedenen Kundengruppen einfließen. Kurz gesagt, es geht ständig weiter, aber solide und für den Kunden mit möglichst wenig finanzieller oder technischer Belastung.
Die Weiterentwicklung der symbolischen KI bietet viele Synenergien zwischen den verschiedensten Instanzen unserer Suchmaschine. Durch maschinelles Lernen und kontrollierte semiautomatische Anpassungsprozesse (für Domänen und Fachsprachen), umfangreiche Regressionstests und Evaluation von Suchlogs und Suchergebnissen können wir einen kontinuierlichen Fortschritt garantieren. Die Kopplung der symbolischen KI mit generativer KI ist bei uns besonders, da wir dies mit einer großen Expertise im ersteren Bereich angehen können. Auch die Art der Kopplung wird fortwährend hinterfragt und - wo sinnvoll - justiert.
