Die Anforderungen an eine Enterprise Search sind schnell spezifiziert: Wir wollen eine Suchmaske mit einem Eingabefeld, einer Vorschlagsfunktion während des Tippens und einer Ergebnisliste, in der das wichtigste Dokument zuoberst steht.

Wir sind verwöhnt von Google und Co. Die Messlatte für die Standards liegt hoch. Jahrzehntelange Forschung und Entwicklung stehen hinter diesen Suchsystemen.

Wer eine Enterprise Search aufbauen will, muss sich auf eine längere Entwicklungszeit einstellen.

Der Aufbau einer Unternehmensweiten Suche ist mehr als ein Integrationsprojekt. Dokumente liegen in unterschiedlichen Systemen und sollen mit wenigen Klicks in einer einfachen Suchmaske auffindbar sein. Natürlich steht das beste Dokument ganz oben in der Trefferliste und die Trefferliste ist maßgeschneidert auf den Suchenden.

Ein ehrgeiziges Projekt. Hier die wichtigsten Aspekte, die es zu beachten gilt:

Qualität des Suchsystems

Die Erwartungen sind einfach:

“Ein gutes Suchsystem liefert mir das, was ich suche”.

Im Umkehrschluss: Liefert ein Suchsystem keine brauchbaren Ergebnisse, dann ist das System unbrauchbar. Und das gilt für jeden User und für jede Suchfrage.

Erwartungen der Zielgruppen

Bei der Entwicklung einer Enterprise Search Plattform lohnt es sich, von Anfang an die Erwartungen der Zielgruppen abzuholen.

Gerade in einem größeren Unternehmen gibt es mehr als eine Zielgruppe. Diese richten sich nach dem Aufgabengebiet der Mitarbeitenden und nach deren Informationsbedarf.

• Welche Begriffe werden die Suchenden in das Suchfeld eintippen?
• Ein Wort? Oder ganze Sätze?
• Soll eine Konversation mit dem System entstehen? Falls ja, welches sind die Erwartungen?
• Ist ein Suchfeld zu wenig? Wäre es sinnvoll, die Suche in mehreren Feldern differenzieren zu können?
• Wären Auswahllisten sinnvoll? Würden diese von den Mitarbeitenden verstanden und angewendet?
• Müssen die Suchergebnisse personalisiert sein, so dass dieselbe Suchanfrage nicht für jeden User dieselben Treffer liefert?

Idealerweise werden noch vor Projektstart ausgewählte Vertreterinnen und Vertreter der einzelnen Zielgruppen ihre Erwartungen aufschreiben.

Und idealerweise wird diese Gruppe während des Projekts nach jeder Iteration gezielt Feedback zum Suchsystem geben.

Mit der Cranfield-Methode wurde dieses Vorgehen formalisiert und wird gerne in erfolgreichen Projekten angewendet. Denn ein Suchsystem ist dann gut, wenn es die Fragen der Suchenden beantwortet. Wir müssen also verstehen, was und wie die Suchenden fragen und mit welchen Antworten sie zufrieden sind.

Der Aufbau eines Suchsystems ist keine exakte Wissenschaft.

Vertrauliche Daten in der Enterprise Search

Eine wichtige Frage, die zu Beginn klar sein muss:

Gibt es Dokumente mit eingeschränkten Leserechten? Falls ja, dann ist diesem Merkmal besondere Beachtung zu schenken:

Ein solches Dokument darf nicht in der Trefferliste für alle sichtbar erscheinen.

Auch die Information, dass ein Dokument mit einem bestimmten Titel überhaupt existiert, ist eine Information.

Datenquellen und Mengengerüst

Die Dokumente liegen oft verstreut auf vielen unterschiedlichen Systemen. Sharepoint, Confluent, Filesysteme, CMS-Systeme, Document Management Systeme, Archivsysteme – der Phantasie sind keine Grenzen gesetzt.

Es lohnt sich, zu Projektstart, eine Liste zu erstellen mit

• den einzelnen Datenquellen,
• jeweils der ungefähren Anzahl Dokumente,
• den Fileformaten,
• den Aktualisierungshäufigkeiten und dem geschätzten Wachstum
• und den Authentifizierungsmethoden.

Diese Liste  wird helfen, ein passendes System zu evaluieren.

Im Verlauf des Projekts werden die Dokumente aus allen Systemen ausgelesen . Die Enterprise Search Plattform braucht Zugriff auf alle Systeme und muss mit einer Vielzahl von Authentifizierungsmechanismen zurechtkommen.

Auch erwarten wir, dass die Suchmaschine mit den Änderungen der Dokumente synchron ist.

Je nach Quellsystem wird diese Herausforderung anders zu lösen sein.

Suchsystem Lizenzierung

Make or Buy – diese Entscheidung muss gefällt werden.

Jeder Hersteller von Enterprise-Search Plattformen wird mit einem anderen Zauberkasten antreten und jeder Hersteller muss mit unserer Systemlandschaft zurechtkommen.

Entschließt man sich, die Suchplattform weitgehend selbst zu bauen, dann wird man dennoch  nicht bei Null anfangen.

Man wird ein Suchsystem lizenzieren und in die eigene Systemlandschaft integrieren. Je nach Lizenzmodell wird die Datenmenge eine Rolle spielen.

Oder man basiert auf einem Open Source System – wie Apache Solr.

Dieses System wird seit 2006 von einer regen Community ständig weiterentwickelt. Es basiert auf der Open Source Library Apache Lucene.

Diese ist sehr bewährt und beliebt und wird gerne als Herzstück einer Suchmaschine verwendet.

Architektur der Enterprise Search Plattform

Bleiben wir bei Apache Solr als Beispiel einer Suchmaschine, die wir als Herzstück unserer Enterprise Search Plattform einsetzen können.

Solr kommt mit einer Indexierungskomponente und mit einer Suchkomponente. Beide sind unglaublich flexibel konfigurierbar.

Es gibt Features für nahezu alle Anforderungen.

Reicht das nicht aus, dann können wir eigene Features dazu programmieren.

Die Lucene/Solr Community ist sehr aktiv und erweitert den Umfang laufend um die neuen Features, die dank KI möglich werden.

Die Indexierungskomponente baut den Invertierten Index und die Suchkomponente fragt diesen ab.

Je mehr Features wir konfigurieren und je mehr Dokumente wir Indexieren, umso größer wird der invertierte Index.

Früher als uns lieb ist, werden wir in die Big Data Welt, also in die Welt des verteilten Rechnens katapultiert, und war auch dann, wenn die Quelldokumente im Quellsystem bleiben und die User der Enterprise Search Plattform bei Klick auf einen Treffer das Dokument aus dem Quellsystem lesen.

Das folgende Diagramm zeigt die Architektur einer Enterprise Search.

Die Dokumente werden aus den einzelnen Quellsystemen abgeholt.

Sie werden in dasjenige Format transformiert, das Solr als Input verwendet. Das ist ein einfaches XML- oder JSON-Format. Pro Dokument definieren wir einzelne Suchfelder. Hier fängt das Index-Design schon an.

Je zielgenauer die Suchmaschine sein soll, desto raffinierter werden wir dieses Format strukturieren und desto aufwändiger wird diese Datenkonvertierung.

Die konvertierten Daten werden von Sorl zur Indexierung eingelesen. Wir konfigurieren, mit welchen Features indexiert und später gesucht wird.

Im Produktivbetrieb werden wir dafür sorgen, dass Änderungen an den Dokumenten in den Quellsystemen zeitnah indexiert werden.

Die Suchoberfläche sieht nur auf den ersten Blick einfach aus. Unter der Haube werden die User-Eingaben in Suchanfragen umgewandelt, die zum Index passen und die Features ausreizen.

Ranking

Viel Aufmerksamkeit schenken wir dem Ranking: Wir sorgen also dafür, dass das relevanteste Dokument zuerst in der Trefferliste erscheint.

Heute gängig und erwartet: personalisierte Suchen – also ein Ranking, das sich nach dem Suchenden richtet.

Das ist viel Arbeit. Und mit jeder Datenquelle, die wir dazu nehmen, werden wir neue Erkenntnisse gewinnen.

Aufbau der Enterprise Search Plattform und Tuning

Das Suchsystem wird schrittweise aufgebaut.

Jedes Quellsystem muss analysiert werden.

Die Struktur des Suchmaschinen Indexes wird ebenfalls schrittweise entwickelt. Zu Beginn wird man kaum die perfekten Entscheidungen treffen und muss das Design immer wieder überdenken.

Daten abholen und konvertieren

Daten werden in den Quellsystemen abgeholt und konvertiert in ein Format, das von der Suchmaschine indexiert wird.

Vielleicht gibt es einen Konnektor, der das Suchsystem direkt mit dem Quellsystem verbindet und vielleicht funktioniert dieser sogar out-of-the-box und lässt sich nach unseren Anforderungen konfigurieren.

Falls nein, dann erstellt man diesen Prozess selbst. Python ist eine mächtige Sprache mit vielen guten Libraries, die uns die Arbeit erleichtern.

Das Tuning der Suche ist aufwändig und spannend. Immerhin soll die Suchmaschine nicht einfach ein Ergebnis liefern, sondern zielgenau den besten Treffer an erster Stelle zeigen.

Index Design und Optimierung

Nicht nur das Index-Design selbst, sondern auch die Erschließung der Daten im Index wollen entwickelt werden.

Die grundlegendsten Schritte kommen in jedem Suchsystem standardmäßig mit:

• Zeichensätze und Umlaute normieren
• Text in Wörter zerlegen
• Stopp-Worter entfernen
• Synonyme anreichern
• Wörter standardisieren, z.B. auf die Grundform umwandeln.
• Index erstellen.

Das ist der erste Schritt. Jetzt vergleichen wir die Erwartungen der Testuser mit den Ergebnissen.

Das Vorgehen können wir so standardisieren, dass wir nach jedem Optimierungsschritt aufgrund der von den User erwarteten Dokumente und vom Suchsystem gefundenen Treffer den F1-Score berechnen.

Dieser wird mit der out-of-the-box Konfiguration eher im niedrigen Bereich sein. Vielleicht bei 0,2 von 1,0.

Wobei wir 1,0 nicht erzielen wollen, weil wir damit das Suchsystem “overfitten”, also auf die Testuser und deren Fragen trimmen und alles andere außer Acht lassen.

Das erste Tuning wird sich mit der Frage befassen, ob jeder dieser Schritte verbessert werden kann. Beispiele:

• Ist die Stoppwortliste nötig – falls ja, stehen dort die richtigen Begriffe – immerhin werden diese im Suchindex nicht berücksichtigt? Es gibt Standard-Stoppwortlisten für jede Sprache. Doch diese entsprechen vielleicht gar nicht unserem Business.
• Dasselbe gilt für Synonyme: Jedes Unternehmen pflegt eine Art ‘Slang’,  interne Begrifflichkeiten, die auf der Synonymliste wertvolle Dienste leisten könnten.

Nach dem Tuning bauen wir den Index neu und errechnen den F1-Score neu.

Dieser wird stetig wachsen. Sinkt er, dann haben wir einen guten Hinweis, dass der letzte Optimierungsschritt nicht die erwarteten Ergebnisse brachte.

Vielfältige Features für die Enterprise Search

Nach und nach werden wir weitere Features einbauen. Hier eine Liste gängiger Möglichkeiten:

• Spellchecker
• Duplikate erkennen und entfernen
• Vorschlagsliste während des Tippens
• Ähnliche Dokumente vorschlagen
• Disambiguieren – also gleichlautende Begriffe auseinander halten
• Einen Knowledge Graph bauen, um verwandte Begriffe und Zusammenhänge richtig in die Suchergebnisse einzubeziehen.

Infrastruktur und Aktualisierungen

Es ist geschafft – wir vertrauen unserem Suchsystem und wollen eine erste Version ausrollen und einem ausgewählten Benutzerkreis zur Verfügung stellen.

Suchmaschinen Indexe werden sehr groß. Wir werden sehr viel Platz benötigen, sowohl Festplatte als auch RAM.

Und sehr wahrscheinlich werden wir mit einem verteilten System arbeiten, weil die schiere Menge der Daten nicht auf einem Rechner Platz hat.

Wir sollten uns schon lange bei Projektstart mit dem Aspekt der Infrastruktur befassen und in einer sehr frühen Projektphase berechnen, ob die Größe des Suchmaschinenindexes ein verteiltes System benötigt.

Ob wir damit in die Cloud gehen wollen? Auch diese Frage muss abgewogen werden.

Vielleicht kommt gar ein Real-Time-Aspekt dazu – und wir wollen Änderungen an Dokumenten sofort im Index nachführen.

Fazit

Unternehmensweite Suche – die Anforderungen sind schnell formuliert. Der Aufbau eines Suchsystems jedoch ist sehr anspruchsvoll und aufwändig und benötigt vielfältige Skills.

Laufender Betrieb und Unterhalt

Jedes System muss gepflegt werden. Verteilte Systeme sind aufwendiger.

Die Daten müssen aktuell gehalten werden – vielleicht sogar in Echtzeit.

Die Texte und Dokumente werden von Menschenhand erstellt und der Kreativität sind keine Grenzen gesetzt.

Wir brauchen Qualitätssichrungsmechanismen die bemerken, wenn neue Formate erfunden wurden, die in der Datenkonvertierung noch nicht erkannt werden.