Enterprise Search

Woher der Begriff kommt und wo er normiert ist

Enterprise Search stammt aus der Softwarebranche und hat sich um die Jahrtausendwende eingebürgert, als die Websuche im Alltag selbstverständlich wurde und der Unterschied zur Suche im eigenen Haus auffiel. Der deutsche Ausdruck Unternehmenssuche wird seltener verwendet. Beide bezeichnen dieselbe Aufgabe.

Fachlich steht die Aufgabe im Information Retrieval, dem Teilgebiet der Informatik, das sich mit dem Auffinden relevanter Dokumente befasst. Von dort stammen auch die beiden Verfahrensfamilien, auf denen praktisch jedes System aufsetzt: die lexikalische Suche mit einem Rankingverfahren wie BM25 und die Suche über gelernte Vektordarstellungen. Für beide gibt es Primärquellen, sie stehen unten im Quellenverzeichnis.

Wie ein Enterprise-Search-System aufgebaut ist

Zwischen der Datei im Laufwerk und dem Treffer auf dem Bildschirm liegen fünf Schritte. Sie laufen in jedem System dieser Art ab, unabhängig vom Hersteller.

• Erschließen: Konnektoren holen Inhalte aus den Quellen, also aus Dateiablagen, Postfächern, Ticketsystemen oder Datenbanken. Jede Quelle braucht ihren eigenen Konnektor, und jeder Konnektor muss auch die Zugriffsrechte der Quelle mitlesen.
• Aufbereiten: Aus PDF, Präsentation oder Tabelle wird Text extrahiert. Gescannte Seiten ohne Textebene brauchen zuvor eine Texterkennung, Tonaufnahmen eine Transkription. Danach wird der Text in Abschnitte zerlegt.
• Indexieren: Die Abschnitte werden in einen Suchindex geschrieben, je nach Verfahren als Wortindex, als Vektoren oder als beides.
• Anfragen und prüfen: Zur Anfrage werden Kandidaten ermittelt und gegen die Rechte der suchenden Person gefiltert. Wo diese Prüfung stattfindet, ist die wichtigste Architekturentscheidung des ganzen Systems.
• Rangfolge und Darstellung: Die verbliebenen Treffer werden sortiert und mit Fundstelle angezeigt, idealerweise mit der Textstelle, die zur Anfrage passt.

Warum der Zeitpunkt der Rechteprüfung entscheidend ist

Für die Rechteprüfung gibt es zwei Bauformen. Bei der einen werden die Berechtigungen bereits in den Index geschrieben, sodass die Suche nur Treffer zurückgibt, die die anfragende Person sehen darf. Bei der anderen sucht das System zunächst ohne Einschränkung und filtert danach. Die zweite Variante ist einfacher zu bauen und in dem Moment gefährlich, in dem ein Sprachmodell die Treffer weiterverarbeitet: Was einmal in den Kontext des Modells gelangt ist, steht potenziell in der Antwort, auch wenn der Treffer selbst später herausgefiltert wird.

Ein zweiter Punkt betrifft die Aktualität. Rechte ändern sich, Dokumente ziehen um, Mitarbeitende wechseln die Abteilung. Ein Index, der diese Änderungen erst beim nächsten vollständigen Durchlauf nachvollzieht, zeigt vorübergehend Berechtigungen von gestern.

Welche Systemarten es gibt

Die am Markt verfügbaren Systeme lassen sich in vier Gruppen einteilen. Die Gruppen unterscheiden sich weniger im Suchverfahren als in der Frage, wem der Bestand und wem das Rechtemodell gehört.

• Suchmaschinenkerne als Baustein: Apache Lucene und die darauf aufbauenden Systeme Elasticsearch, OpenSearch und Apache Solr. Sie liefern Index und Rangfolge, alles Weitere, von Konnektoren bis Rechtemodell, wird ergänzt.
• In eine Plattform eingebaute Suche: Die Suche gehört zum Kollaborationswerkzeug, etwa in einer Dokumentenplattform oder Office-Suite. Rechte und Bestand liegen dort ohnehin, dafür endet die Suche an der Systemgrenze.
• Eigenständige Enterprise-Search-Produkte: Sie setzen über vorhandene Systeme und binden sie über Konnektoren an. Der Bestand zieht nicht um, der Aufwand liegt in Anbindung, Rechteübernahme und Aktualisierung.
• Ablage und Suche in einem System: Der Speicher ist zugleich der Index. Es gibt nur ein Rechtemodell und keine Konnektoren, dafür muss der Bestand dort liegen.

Innerhalb jeder Gruppe stellt sich zusätzlich die Verfahrensfrage: lexikalische Suche, semantische Suche oder beides kombiniert. Was die Verfahren unterscheidet, steht unter semantische Dokumentensuche. Wird aus den Treffern zusätzlich eine formulierte Antwort erzeugt, ist die Bauform dahinter RAG.

Wie Nexoria das umsetzt

Nexoria gehört zur vierten Gruppe: Ablage und Suche sind dasselbe System. Die Dateien liegen in Nexoria Drive, ihre Inhalte werden beim Ablegen indexiert, und die Dokumentensuche arbeitet auf genau diesem Index. Sie steht sowohl im Assistenten Nex als auch in einem eigenen Suchfenster zur Verfügung. Als Verfahren nennt die Faktenschicht semantische Suche über die Inhalte des Workspaces und RAG mit Hybrid-Retrieval, also die Kombination aus lexikalischer und semantischer Suche.

Zur Funktionsweise gilt der freigegebene Wortlaut: Die Dokumentensuche durchsucht die Inhalte eines Workspaces semantisch und nennt zu jedem Ergebnis die Quelle.

Die Rechteebene liegt bei den Workspaces: Ein Workspace bestimmt, welche Personen und welche Chatbots welche Inhalte sehen, und dieselben Rechte gelten für Suche, Chat und Bot. Technisch dahinter steht: Strikte Datenisolierung pro Mandant auf Datenbank- und Vektorspeicher-Ebene, Rollenmodell mit Admin, Mitglied und Betrachter, serverseitige Berechtigungsprüfung auf jedem API-Endpunkt.

Wo die Verarbeitung stattfindet: Dokument-Embeddings, Analyse und semantische Suche laufen vollständig lokal auf deutschen Servern.

Wo die Grenzen liegen

• Durchsucht wird der Bestand in Nexoria Drive, soweit er für den jeweiligen Workspace freigegeben ist. Ein Verbund über beliebige Fremdsysteme mit eigenen Konnektoren ist nicht Teil dieses Ansatzes. Wer seinen Bestand nicht verlagern will, braucht eine andere Systemart.
• Welche Dateiformate im Einzelnen indexiert werden, ist öffentlich nicht dokumentiert.
• Zur Trefferqualität gibt es keine veröffentlichte Messung mit offengelegter Methodik. Prozentangaben zu Trefferquote, Recall oder Genauigkeit stehen deshalb auf keiner Seite dieser Website.
• Semantische Suche ist kein Ersatz für exakte Suche. Bei Aktenzeichen, Belegnummern und Eigennamen ist der wortgenaue Abgleich weiterhin überlegen, deshalb die Kombination beider Verfahren.