Enterprise Search: Eine eigene Unternehmenssuche aufsetzen

Eine Kollegin sucht das Angebot, das vor drei Monaten an einen Kunden rausging. Sie tippt „Angebot Wartungsvertrag" ins Suchfeld und bekommt: nichts. Dabei liegt das Dokument im System, nur heißt es dort „Service-Level-Agreement Hosting". Andere Worte, gleiche Sache, kein Treffer.

Dieses Szenario kennt fast jedes Unternehmen. Es zeigt zwei Dinge, an denen eine gute Unternehmenssuche hängt: Sind die relevanten Quellen überhaupt durchsuchbar, und passt die Art der Suche zur Frage?

Eine Enterprise Search durchsucht unternehmensweit verschiedene Datenquellen, von PDFs in der Dokumentenablage über das Wiki bis zum Fachsystem. Dabei gibt es verschiedene Arten der Suche.

Die Volltextsuche ist die klassische Variante. Sie legt einen Index über alle Wörter an und findet Dokumente, die die Suchbegriffe enthalten. Diese Suchart ist schnell und präzise bei exakten Begriffen wie Produktnummern, Fehlercodes oder Eigennamen. Auch Tippfehler und Schreibvarianten lassen sich über Fuzzy Search abfangen, sodass „Wartunsgvertrag“ trotzdem den „Wartungsvertrag“ findet. Ihre Schwäche: Sie vergleicht Zeichenketten und ist blind für alles, was anders formuliert ist.

Bei der semantischen Suche geht es um die Bedeutung hinter den Wörtern. Texte werden über ein KI-Modell und Vektortechnologie in Zahlenreihen übersetzt (Embeddings), die ihren Sinn abbilden. „Angebot Wartungsvertrag“ und „Service-Level-Agreement Hosting“ landen dann nah beieinander, obwohl sie kein Wort teilen. Das löst genau das Problem aus dem Einstieg. Semantisch heißt aber nicht automatisch besser: Wo ein exakter Begriff entscheidend ist, etwa bei einem Aktenzeichen oder einer Fehlernummer, ist die rein semantische Suche oft unterlegen.

Die Hybrid Search führt die Ergebnisse aus Stichwort- und semantischer Suche zu einer Liste zusammen und fängt so sowohl die exakte Produktnummer als auch die sinngemäße Frage ab. Deshalb wählen wir bei den meisten Projekten genau diese Variante. Sie ist der beste Kompromiss. Wie wir die beiden Trefferlisten dabei technisch zusammenführen, beschreiben wir im Detail in unserem Wiki-Eintrag zur hybriden Suche.

Wer noch einen Schritt weiter gehen will, setzt ein Sprachmodell obendrauf. Statt nur Dokumente aufzulisten, formuliert dieses eine Antwort und nennt die Quellen dazu. Dieses Muster heißt RAG (Retrieval Augmented Generation). Technisch ruft das Sprachmodell die Suche dabei oft über einen Function Call auf, nutzt sie also als Werkzeug, um an die richtigen Informationen zu kommen, bevor es antwortet. So bleiben die Antworten des Sprachmodells an die echten Unternehmensdokumente gebunden. Über Natural Language Understanding kann das System außerdem ganze Fragen in Alltagssprache statt einzelner Stichworte verstehen. Conversational Search erlaubt zusätzlich einen Dialog, in dem man nachfragen und präzisieren kann, ähnlich einem Chat. Beides hilft besonders Menschen, die nicht in Suchbegriffen denken.

Eine eigene Enterprise Search aufzubauen wirkt aufwendig, gelingt aber in überschaubaren Schritten. Der typische Ablauf sieht so aus:

Schritt 1: Die Datenbasis schaffen und Quellen vernetzen

Die relevanten Quellen müssen angebunden werden, also Dokumentenablagen, Wikis, Fachsysteme und je nach Bedarf auch Mailprogramme oder CRMs. Die meisten Systeme bieten dafür Schnittstellen oder Konnektoren, sodass sich Inhalte automatisch und regelmäßig einlesen lassen. Dabei ist die Herausforderung, die unterschiedlichen Formate und Datentypen so aufzubereiten, dass die Suche sie findet.
Eine Sache lohnt sich schon hier: aufräumen. Veraltete Dokumente, doppelte Einträge und uneinheitliche Benennungen verringern die Trefferqualität. Eine Suche ist immer nur so gut wie die Inhalte, die sie durchsucht.

Welche Art der Suche sich für den jeweiligen Anwendungsfall eignet, ist davon abhängig, was und wie Sie suchen wollen; zur Orientierung können Sie sich die oben im Artikel erklärten Sucharten noch einmal ansehen. Weil Volltextsuche und semantische Suche beide gegenläufige Stärken haben, kombiniert man sie meist zur hybriden Suche. Diese Art der Suche nutzen wir bei den meisten Projekten. 

Welche Technologie man wählt, hängt von Datenmenge, Team und gewünschtem Betriebsaufwand ab. Es gibt spezialisierte Suchtechnologien wie Elasticsearch, OpenSearch oder Meilisearch, oft lässt sich die Suche aber auch auf einer Datenbank aufbauen, die ohnehin schon läuft, etwa PostgreSQL. Das spart Kosten und Infrastruktur und passt zum Grundsatz, klein anzufangen.

Wenn die Suche fertig implementiert ist, folgt immer noch eine Optimierungsphase mit vielen Stellschrauben: Wie viele Treffer zeigt man an, welche Arten von Treffern, wie wird sortiert, und wie stark gewichtet man in der Hybrid-Suche die Volltext- gegenüber der semantischen Trefferliste? Diese Justierung entscheidet darüber, ob die Suche im Alltag als gut empfunden wird.

Damit man nicht nach Gefühl schraubt, gibt es zwei zentrale Messgrößen.

• Precision misst die Genauigkeit: Wie viele der angezeigten Treffer sind tatsächlich relevant?
• Recall misst die Vollständigkeit: Wie viele der relevanten Dokumente hat die Suche überhaupt gefunden?

Die beiden stehen oft in einem Zielkonflikt. Zeigt man mehr Treffer, steigt der Recall, aber die Precision sinkt, weil mehr Unpassendes dabei ist. Welche Balance richtig ist, hängt vom Anwendungsfall ab. Praktisch baut man dafür ein Testset auf, also eine Sammlung typischer Suchanfragen mit den jeweils erwarteten Treffern. Daran lässt sich nach jeder Änderung messen, ob die Suche besser oder schlechter geworden ist. Testen, messen, nachjustieren, und das nicht einmalig, sondern als fester Teil des Betriebs. Denn neue Datenquellen, geänderte Inhalte und wachsende Anforderungen wollen laufend berücksichtigt werden.

Eine Unternehmenssuche durchsucht potenziell sensible Daten, deshalb gehört Sicherheit von Anfang an mitgedacht, nicht erst am Ende.

Zentral ist ein sauberes Berechtigungskonzept. Die Suche darf einer Person nur Treffer zu Dokumenten zeigen, auf die sie auch zugreifen darf. Die bestehenden Zugriffsrechte müssen also in die Suche integriert werden, sonst wird das Suchfeld zum Datenleck.

Eine zweite Grundsatzentscheidung ist On-Premises gegenüber Cloud. Wer Daten im eigenen Rechenzentrum oder bei einem Hostinganbieter in Deutschland behält, hat die volle Datenhoheit und erhöht die Datensicherheit erheblich. Besonders relevant wird das, sobald ein Sprachmodell ins Spiel kommt: Hier sollte klar sein, wohin die Daten zur Verarbeitung fließen. Inzwischen lassen sich auch Sprachmodelle vollständig lokal betreiben, sodass keine Daten das Unternehmen verlassen. Eine eine DSGVO-konforme und datensichere Lösung, die KI-Verarbeitung auf europäischer Infrastruktur oder direkt im eigenen Haus hält, ist für viele Unternehmen das entscheidende Kriterium.

Einen Pauschalsieger gibt es nicht, wichtig ist, dass die Lösung zu den eigenen Daten, zum Team und zu den Sicherheitsanforderungen passt, und nicht, dass sie die meisten Funktionen mitbringt. Wer mit den wichtigsten Datenquellen klein anfängt, sauber integriert und konsequent misst, hat schnell eine Suche, die endlich findet, was im Unternehmen längst vorhanden ist.