Back to top

Wikipedia mit Azure Search durchsuchen

Eine Demonstration von Search Technologies

Azure Search nutzt die Infrastruktur der Microsoft Azure Cloud Infrastruktur, um eine robuste Search-as-a-Service-Lösung zu bieten, ohne dass die Infrastruktur verwaltet werden muss. Mit Azure Search kann man einfach REST API oder .NET SDK verwenden, um die Daten in Azure zu bringen und die Konfiguration der Suchanwendung zu beginnen.

Wir haben bereits cloudbasierte Anwendungen für Suche und Big Data in der Azure Hostingumgebung entwickelt, Azure Search ist aber noch recht neu auf dem Markt der Suchanbieter. Also haben wir beschlossen, ganz nach Vorbild unseres leitenden Architekten Paul Nelson, der eine Demo für eine Wikipedia-Suche über Amazon CloudSearch erstellt hat, diese Wikipedia-Suche in Form einer neuen Demo wiederaufleben zu lassen, diesmal mit Azure Search.

Die Demo kann unter wikipedia.searchtechnologies.com/azure/ eingesehen werden. 

Für all jene, die sich fragen, wie genau diese Azure Search Anwendung entwickelt wurde haben wir hier ein paar Einblicke zusammengetragen, was sich im Hintergrund abspielt.  

 

Überblick über die Architektur

azure search for wikipedia architecture  

Datensammlung 

Man muss sich nur mal die massiven Mengen Content vorstellen, die man auf Wikipedia findet. Wie kann man all diese Daten erfassen? Wir haben dafür einen Aspire-Konnektor entwickelt, der Dump Files direkt von Wikipedia in das Aspire Staging Repository herunterlädt, welches diese Daten dann wiederum direkt per Streaming in Azure Search eingibt. Es handelt sich dabei also um einen nahtlosen Transfer, bei dem zu keinem Zeitpunkt Daten auf Festplatten gespeichert werden müssen. 

Ein bisschen Hintergrund für all jene, die gerne wissen wollen, was Aspire eigentlich ist: Aspire ist ein von Search Technologies entwickeltes proprietäres Framework für die Content-Verarbeitung, das sowohl mit strukturierten als auch unstrukturierten Daten umgehen kann. Das Framework unterstützt komplexe Content-Verarbeitung, bietet ein Staging Repository für effiziente Indexierung und umfasst vordefinierte Daten-Konnektoren zum Erwerb von Daten von verschiedenen Quellen. Mehr über Aspire können Sie hier erfahren. 

Der Konnektor ermöglicht es uns, mehr als 5 Millionen englische Artikel von Wikipedia im XML-Format einzuholen, einschließlich der URLs für Thumbnails. Er unterstützt auch die Verarbeitung von Updates. Das bedeutet, dass neue Daten in das Aspire-Staging Repository heruntergeladen werden, wenn neue Seiten auf Wikipedia hinzugefügt oder bestehende Seiten aktualisiert werden.

 

Datenverarbeitung

Parsen

Das Open-Source-Programm DKPro (DKPro Wikipedia Library) – ein spezieller Parser für Wikipedia Syntax – hat stark dabei geholfen, den Content aus Wikipedia zu parsen und Metadaten zu extrahieren, wie etwa die Aktualisierungszeit der Artikel, ihre Kategorie, Titel, Beschreibungen usw. 

In der alten Demo für CloudSearch auf Wikipedia hat Paul beschrieben, wie kompliziert die Datenverarbeitung bei großen Datenbanken wie Wikipedia sein kann. 

„Seiten auf Wikipedia nutzen Templates in Templates in externen Links in internen Links, und dergleichen mehr. Es ist das reinste Chaos, aber so etwas ist typisch bei großen und stark strukturierten Datensätzen, die von Menschen geschrieben wurden.“

– Paul Nelson, leitender Architekt bei Search Technologies

Dieser speziell für Wikipedia entwickelte Parser bietet schnelleren und effizienteren Zugriff zum Parsen in diesem Labyrinth der Daten. 

 

Entitätenerkennung

wikipedia content typesDie Kategorisierung ist eine natürliche Art, Content effizient zu sortieren. Je besser die Erkennung von Entitäten funktioniert, desto besser werden die Daten kategorisiert. Wenn man das Volumen und die Vielzahl von Content in Wikipedia bedenkt, braucht man fortgeschrittene Entitätenerkennung, die wir deshalb in unseren benutzerdefinierten Aspire-Konnektor für Wikipedia eingebaut haben.

Zusammen mit den Metadaten, die wir durch DK Pro gewonnen haben, konnten diese Algorithmen 40 % des gesamten eingeholten Wikipedia-Contents nach PersonOrt, oderOrganisation erkennen und kategorisieren.

Wie genau funktionieren die Algorithmen für die Kategorisierung?

  • Um eine „Person“ zu erkennen, sucht der Algorithmus nach Geburtsdatum und Todesdatum
  • Für einen „Ort“ nach GPS-Koordinaten
  • Für ein „Unternehmen“ nach Gründern

Wir haben auch mit DBpedia experimentiert, einem Open-Source-Projekt zum Extrahieren von strukturierten Daten aus Wikipedia, um die Daten effizienter zu kategorisieren. Ein Problem bei DBpedia war aber aber, dass die Geschwindigkeit beim Indexieren heruntergezogen wurde, wenn wir große Datenmengen verarbeiteten. Unser Lösungsansatz war also ...

 

Aspire-Staging Repository

Wir haben das Aspire-Staging Repository für schnelles erneutes Indexieren von verarbeitetem Content verwendet. Sobald die Daten bereinigt und normalisiert sind, können sie im Staging Repository gespeichert werden. Hierdurch können die Daten schneller erneut indexiert werden.

Das Staging Repository dient als Brücke zwischen den Datenquellen (in diesem Fall dem Content aus Wikipedia) und der Suchmaschine (Azure Search). Bei Änderungen an der Konfiguration der Suchmaschine mussten wir damit also nur noch die Daten erneut indexieren, die bereits im Staging Repository vorlagen, ohne die ursprünglichen Datenquellen erneut abfragen zu müssen. Dieser Ansatz löste das Problem der langsamen Indexierung, die für die Indexierung benötigte Zeit wurde von Tagen auf Stunden reduziert.

Mehr darüber, wie dieses Staging Repository funktioniert, erfahren Sie in unserem Video-Blog.

 

Indexieren

Wir haben die Microsoft Azure Search API verwendet, um einen benutzerdefinierten Aspire Publisher zu entwickeln, der die Daten mit Metadaten (wie Titel, Beschreibung, Thumbnail usw.) abgleicht und diese Daten dann per Streaming aus dem Aspire Staging Repository in Azure Search anbietet.

Azure Search unterstützt das Einfügen von bis zu 1000 Dokumenten pro Batch über den benutzerdefinierten Aspire Publisher, dadurch wurde die für das Indexieren benötigte Zeit signifikant verkürzt.

Man sollte auch beachten, dass die Menge der Dokumente, die durch Azure indexiert werden können, von dem Datenplan abhängt, den man von Microsoft kauft. In unserem Fall wurden über 5 Millionen Wikipedia-Dokumente heruntergeladen, verarbeitet und indexiert. Nachdem man einen Überblick über die Dokumente gewonnen hat, die für die Suche indexiert werden sollen, kann man den Azure Preisrechner verwenden, um die Gesamtkosten für die beabsichtigten Daten zu berechnen.

Für die linguistischen Funktionen haben wir Lucene Stemmer eingesetzt. So haben diese Stemmer beispielsweise „Olympic“ und „Olympics“ als zwei Varianten desselben Wortes erkannt, statt sie als zwei verschiedene Wörter zu werten.

 

Abfrage und Relevanzbewertung

Wie bei jeder Suchmaschine mussten auch in Azure Search die Algorithmen für die Relevanz definiert und kontinuierlich angepasst werden. Durch die Nutzung eines Caches wird die Geschwindigkeit der Abfrage durch jede weitere Abfrage besser.

Eine der Funktionen von Azure Search ist die Erstellung mehrerer Bewertungsprofile. Hierüber konnten wir mehrere Instanzen einrichten und dynamisch zwischen diesen wechseln, um die Relevanz anzupassen.

Die meisten Aufgaben für die Relevanzeinstellung bei dieser Demo hatten damit zu tun, die Metadaten-Felder korrekt zu verwenden und die richtigen Gewichtungen für die Relevanz bei Titeln und Ausdrücken zu definieren.

So gibt es beispielsweise fünf verschiedene Bewertungsprofile in unserer Demo:

Diese Bewertungsprofile haben bei den fortlaufenden Tests und Feineinstellungen der Relevanz stark geholfen. Potentiell können komplexere Bewertungsprofile eingesetzt werden, um die Bewertungsalgorithmen der Suchmaschine anzupassen und die Relevanz weiter zu verbessern. 

In diesem on-demand Webinar kann man eine Live-Demo für das Suchmaschinen-Scoring sehen.

 

Benutzeroberfläche 

Die Konfiguration der Benutzerschnittstelle ist ebenso wichtig wie die Konfiguration im Back-End. Unser Ziel war es, eine grafisch ansprechende, moderne Schnittstelle zu bieten, die dem Benutzer intuitiv weiterhilft.

 

mobile azure search for wikipediaMobile Zugänglichkeit

Die Benutzeroberfläche für den mobilen Zugang haben wir über Bootstrap entwickelt, ein Framework für die Web-Entwicklung, speziell für Web-Initiativen, die sich zuerst auf mobile Anwendungen konzentrieren.

Gemäß den Best Practices für zugängliches Design bei Benutzeroberflächen haben wir:

  • Gitter für Betrachtung über Desktop und mobile Geräte erstellt
  • Ein modernes, schlichtes Design entwickelt – in diesem Fall wurde das Design für die Demo von Windows 10 inspiriert. Man kann Bootstrap oder andere Plattformen nutzen, um eine Benutzeroberfläche zu erstellen, die den Anforderungen der eigenen Marke entspricht
  • Bilder in HTML-Templates konvertiert
  • Mit Apache Velocity verbunden – eine Open-Source-Templateengine, über die sauberer Code für grafische Templates erstellt und konsistent auf alle Seiten der Demo angewendet werden kann

 

Facetten für Kategorien

Zusätzlich zu den Kategorien PersonOrt, und Organisation, die oben besprochen wurden, haben wir auch die vordefinierten Kategorien jedes Wikipedia-Artikels genutzt, um leichteres Browsen durch verwandten Content zu ermöglichen.

Artikel können über das Kategorie-Widget auf der linken Seite der Ergebnisseite oder den Kategorie-Button rechts unten an jedem Suchergebnis sortiert werden (bzw. verwandte Artikel aufgefunden werden).

category facets in azure search

 

Mehr als eine einfache Suche – eine Plattform für maschinelle Lernverfahren und fortgeschrittene Analyse in der Cloud

Die Cloud hat die Entwicklung von Anwendungen für Suche und Big Data leichter und effizienter gemacht. Microsoft bietet die zentrale Infrastruktur und API für die Suche. Daher konnten wir mit dem neuen Azure Search experimentieren, große Mengen Cloudspeicher on-demand erhalten und konfigurieren, so, wie wir es uns vorgestellt hatten.

Während jede Suchmaschine ihre Vor- und Nachteile hat, scheint uns Azure Search fähig, einer der wichtigeren Akteure im sich ausweitenden Feld von Search-as-a-Service zu werden. Unter anderem fanden wir vor allem die Möglichkeit hilfreich, das Staging Repository für effizientes Indexieren und die verschiedenen Bewertungsprofile für Verbesserung der Suchrelevanz zu nutzen. 

Maschinelle Lernverfahren und Predictive Analytics können auch eingebunden werden, um die Algorithmen für Suchgenauigkeit zu verbessern (einen tieferen Einblick findet man in unserem Webinar zu Suchmaschinen-Scoring). Eine Auswahl von Big Data-Technologien aus dem Open-Source-Bereich, wie das Hadoop-Ökosystem, liefert eine solide Auswahl an Hilfsmitteln für solche Aufgaben. Hierzu kann man unsere Demo als Beispiel sehen. Wir haben nicht nur eine Suchanwendung erstellt, sondern auch die verwaltete Cloud-Umgebung von Azure genutzt, um maschinelle Lernverfahren und fortgeschrittene Analyseverfahren über die Cortana Intelligence Suite einzubinden. Die Flexibilität der Unternehmen steigert sich durch die Möglichkeit, umfassende IT-Anwendungen zu erstellen, die Suche und Big Data-Analyse umfassen, auf Grundlage einer sicheren und on-demand verfügbaren Cloud-Unternehmensinfrastruktur. 

Big Data öffnet der fortgeschrittenen Suche neue Türen, aber wie immer beginnt die Verbesserung der Suchanwendungen mit Einblicken, die aus der Benutzererfahrung und den Absichten der Abfragen gewonnen werden. Also, wer sich unsere Demo bisher noch nicht angesehen hat, sollte das jetzt nachholen: Wikipedia mit Azure Search. Senden Sie uns danach doch einfach Ihr Feedback an info@searchtechnologies.com.  


Diese Demo ist ein Projekt von Search Technologies, geleitet durch:

  • Paul Nelson, leitender Architekt
  • Tomas Dockal, Ingenieur
  • Pavel Stastny, Ingenieur
  • Petr Kudela, Ingenieur
0