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 typische Aufgaben. Ihre konkrete Umsetzung und die Anbindung der Quellen unterscheiden sich je System.

• Erschließen: Inhalte kommen über passende Konnektoren, Schnittstellen oder einen vereinbarten Import aus den Quellen. Je Anbindung muss geklärt werden, welche Inhalte und Rechte übernommen werden und wie Änderungen nachgeführt werden.
• 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 einer Dokumentenplattform oder Office-Suite. Weitere Quellen und deren Rechte hängen von den konkret vorhandenen Anbindungen ab.
• 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 einer Plattform: Dateien und Suchindex werden gemeinsam verwaltet. Welche Inhalte indexiert werden und ob weitere Quellen hinzukommen, hängt vom Produkt und seinen Anbindungen ab.

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 unterscheiden sich Enterprise-Search-Systeme bei der Integration?

Entscheidend ist nicht nur die Liste der Quellen. Prüfen Sie je Anbindung, welche Inhalte übernommen werden, wie Personen und Gruppen zugeordnet sind und wie Änderungen, Löschungen und Rechteentzug im Suchbestand ankommen. Ein Konnektor allein belegt weder vollständige Rechteübernahme noch eine bestimmte Aktualisierungsfrist. Dieselben Fragen gelten bei einem vereinbarten Import; eine Kopie bleibt nicht ohne passenden Pflegeweg aktuell.

Beispiele liefern die Elastic-Dokumentation zu Konnektoren und dokumentbezogenen Rechten sowie Microsofts Beschreibung externer Gruppen (Abruf jeweils 10.09.2026). Sie beziehen sich auf die Systeme dieser Anbieter. Die Auswahlhilfe für Enterprise-Search-Lösungen führt von diesen Kriterien zu einem abgegrenzten Pilot; die Prüfaufgaben zeigen die Kontrolle mit eigenen Dokumenten und Testkonten.

Wie Nexoria das umsetzt

Nexoria gehört zur vierten Gruppe: Ablage und Suche gehören zur selben Plattform. Unterstützte, freigegebene Inhalte aus Nexoria Drive bilden den Suchbestand, und die Dokumentensuche arbeitet auf genau diesem Index. Sie steht sowohl im Assistenten Nex als auch in einem eigenen Suchfenster zur Verfügung. Nexoria nutzt semantische Suche über die Inhalte des Workspaces und RAG mit Hybrid-Retrieval, also die Kombination aus lexikalischer und semantischer Suche.

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 und semantische Suche laufen auf Servern in Deutschland, mit Modellen, die Nexoria dort selbst betreibt.

Was durchsucht wird

• Durchsucht wird der unterstützte, freigegebene Bestand in Nexoria Drive. Unterlagen aus SharePoint, Postfächern oder Netzlaufwerken legen Sie dort ab, damit die Suche sie einbezieht. Anbindungen an SharePoint, OneDrive, Google Drive und weitere Systeme sind auf Anfrage möglich, Umfang und Indexierung werden dabei abgestimmt.
• Nexoria kombiniert semantische und wortgenaue Suche. So finden Sie Aktenzeichen, Belegnummern und Eigennamen auch über den wortgenauen Abgleich.