SHI GmbH Augsburg - Ihr Starker Partner für Search & Big Data, Apache Solr, IT Commerce Lösungen

SHI - Support und Service
SHI - Support und Service
Wir sind Dienstleister aus Leidenschaft und verstehen unsere Kunden.
Nach dem Projekt ist vor dem Projekt und individuelle, persönliche
Betreuung stehen bei uns ganz weit oben.
SHI - Fast Forward to Success
SHI - Fast Forward to Success
Geschwindigkeit zählt. Bei den Kosten und bei den Erfolgsaussichten.
Bei uns sorgen professionelles Projektmanagement und modulare Entwicklung
für Ihren raschen und effizienten Software-Projekterfolg.
SHI - Individuelle Anwendungen aus Software-Bausteinen
SHI - Individuelle Anwendungen aus Software-Bausteinen
Bei uns bekommen Sie weder Software von der Stange, noch unerprobte Eigenentwicklungen. Wir setzen auf bewährte Open-Source-Technologien und setzen Ihre individuelle Anwendung
aus passenden
Bausteinen zusammen.
SHI - Beratung  Entwicklung  Consulting
SHI - Beratung Entwicklung Consulting
Wir beraten und unterstützen Sie mit Schulungen, Trainings und Consulting. Von der Strategieberatung bis zur Anwendungsentwicklung helfen wir Ihnen bei der Optimierung Ihrer
Geschäftsprozesse.

Universal AJAX Live Search

Veröffentlicht am 08.02.2017 von Daniel Wrigley

Teil III


Nachdem die beiden vorhergehenden Blogs eine Einführung in die Thematik und vorbereitende Maßnahmen behandelt haben, geht es im abschließenden Teil der Blog-Serie um das große Ziel: Mit Hilfe von Streaming Expressions ein Modell zur Erkennung von Spam-Mails zu trainieren und zu validieren und zu Klassifikationszwecken einzusetzen.

Klassifikation mit Solr mit Hilfe von Streaming Expressions

Wie im einführenden Beitrag beschrieben, durchläuft man bei Klassifikationsthemen drei Phasen:


1.    Trainieren eines Modells
2.    Testen und Validierung des Modells
3.    Klassifikation von neuen Dokumenten mit Hilfe des validierten Modells


Alle Phasen werden von Solr und den enthaltenen Streaming Expressions ab Version 6.3.0, die für diesen Beitrag verwendet wird, unterstützt. Das heißt konkret: Auf Basis indexierter Dokumente kann Solr ein Modell errechnen, welches in einer Collection gespeichert werden kann. Die in der Trainingsphase extrahierten Features können in mehreren Iterationen verfeinert werden, um ein besseres Klassifikationsmodell zu erhalten, welches eine bessere Klassifikationsgüte aufweist. Dieses gespeicherte Modell kann dann wiederum verwendet werden, um weitere, indexierte Dokumente zu klassifizieren.

Exkurs – Streaming Expressions

Streaming Expressions wurden in Solr 6.0 eingeführt und seitdem stetig erweitert und verbessert. Sie bieten eine einfache, aber sehr mächtige Sprache für die Verarbeitung von Datenströmen mit Solr. Durch die hohe Skalierbarkeit, die die SolrCloud bietet, ist ein hoher Grad an Parallelisierung bei der Verarbeitung möglich. Der bereitgestellte Funktionsumfang weist ein Höchstmaß an Flexibilität auf, was durch die Kombinationsmöglichkeiten der Expressions unterstrichen wird. Das Spektrum reicht von einfachen Operationen wie Suchen bis hin zu komplexen Tätigkeiten wie Klassifikation mittels Machine Learning Algorithmen. Letzteres wird in diesem Beispiel gezeigt.


Klassifikationsmodell trainieren und speichern

Das Trainieren des Modells übernimmt Solr, ebenso wie das Speichern in einer Collection:


update(modelCollection,
 batchSize=1,
 train(mails,
 features(mails, q="*:*", featureSet="first", field="_text_",
 outcome="out_i", numTerms=250),
 q="*:*",
 name="model1",
 field="_text_",
 outcome="out_i",
 maxIterations=100))

Bereits bei diesem Aufruf werden drei Streaming Expressions miteinander verknüpft. Die innerste Funktion (features) extrahiert Features aus den Ergebnissen einer Suchanfrage. Hierfür werden 250 Terme aus dem Feld _text_ extrahiert. Es wird ein Algorithmus namens Information Gain verwendet, um die wichtigsten Terme aus diesem Feld zu extrahieren. Die Query (q) gibt an, welche Dokumente zum Trainingsset dazugezählt werden. In diesem Fall sind es alle („Match All Query“). Die Angabe der Query ermöglicht es, in einer SolrCloud Collection mehrere Trainingssets zu halten, um die besten Trainingsdaten für einen bestimmten Use Case herauszufinden.


Die extrahierten Features bilden den Input für die train-Funktion. Unter Angabe von maxIterations wird spezifiziert, wie viele Iterationen zur Modellerstellung durchgeführt werden sollen. In diesem Beispiel sind es 100 Iterationen. Demnach werden auch der Reihe nach 100 Modelle berechnet, die dann an die update-Funktion zur Indexierung weitergereicht werden.


Die Iterationen übernehmen in diesem Fall günstiger Weise bereits eine Art Validierung des Modells, d.h. nach jeder Iteration werden die für eine Wahrheitsmatrix notwendigen Zahlen mit ausgegeben. Die beste Klassifikationsgüte ist erreicht, wenn alle 1500 Spam-Nachrichten mit dem errechneten Modell als Spam erkannt werden, alle 3672 restlichen Nachrichten als „Kein Spam“ erkannt werden und die Fehlerrate möglichst niedrig ist. Der Output hierzu sähe folgendermaßen aus:


"trueNegative_i": 3672,
"falseNegative_i": 0,
"falsePositive_i": 0,
"error_d": 0.01928354545373971,
"truePositive_i": 1500


Den zugrunde liegenden Algorithmus hier en détail zu beschreiben, würde den Rahmen sprengen. Mehrere Iterationen bedeutet im Wesentlichen, dass pro Iteration versucht wird, die Fehlerquote (error_d) zu minimieren, indem das Featureset angepasst wird. Auch wenn nach 100 Iterationen ein sehr niedriger Fehlerwert berechnet wird und keine falsch negativen und keine falsch positiven Klassifikationen ermittelt werden, ist diese Validierung mit Vorsicht zu genießen, da derjenige Datensatz zum Testen und Validieren verwendet wird, der bereits zur Erstellung des Modells herangezogen worden ist. Eine bessere Variante wäre die Verwendung von Daten, die nicht zur Modellerstellung verwendet wurden.


Nichtsdestotrotz wird es für diese Einführung dabei belassen. Das Ergebnis dieses Schritts sieht also wie folgt aus: Es ist auf dem Inhalt der Collection mails pro Iteration der train-Funktion ein Modell in der Collection modelCollection indexiert worden. Diese Modelle stehen nun für die Klassifikation weiterer Dokumente zur Verfügung.


Dokumente mit dem trainierten Modell klassifizieren

Nachdem ein Modell trainiert ist, können nun Dokumente klassifiziert werden. Natürlich können für einen schnellen Test diejenigen verwendet werden, die bereits für das Training des Modells Verwendung fanden. Nachfolgende Streaming Expression sucht in der Collection mails nach allen Dokumenten (q=*:*, „Match-All Query“), liefert zwei Dokumente zurück (rows=2) und klassifiziert diese mit dem berechneten Modell. Aber es wird wenig überraschend sein, dass dies funktioniert und eine richtige Klassifikation erfolgt, da bereits bei der Modellerstellung von Solr zurückgemeldet wurde, dass alle für das Training verwendeten Datensätze erfolgreich klassifiziert werden konnten.

classify(model(modelCollection, id="model1", cacheMillis=5000),
   search(mails,
    q="*:*",
    fl="_text_, id",
    sort="id asc",
    rows="2"),
   field="_text_")

Ein richtiger Test wären also neue Dokumente. Nachdem der Enron Datensatz einige Mails mehr hat als nur diejenigen, die für das Erstellen des Klassifikationsmodells verwendet wurden, ist dies auch kein Problem. Die einfachste Möglichkeit wäre das Anlegen einer neuen Collection, die Indexierung neuer Mails und eine Anpassung obiger Streaming Expression.


Zusammenfassung

Obwohl der Rahmen dieser Einführung in Solrs Machine Learning Fähigkeiten sehr eng abgesteckt war, hat der durch Solr Streaming Expressions zur Verfügung stehende Ansatz zur Klassifikation sehr gute Ergebnisse bei dieser Binärklassifikation gezeigt. Streaming Expressions sind bereits jetzt, trotz ihres noch recht jungen Alters, mächtige Werkzeuge, deren Kraft sich eigentlich erst richtig entfaltet, wenn sie in großen SolrCloud-Installationen kombiniert bzw. verknüpft werden. Selbst dieses Fallbeispiel ließe sich noch problemlos ausbauen, indem neue, nicht klassifizierte Dokumente von dem Modell klassifiziert werden und das Klassifikationsergebnis mittels der update Streaming Expression wieder in Solr eingespielt wird. Es ist auf jeden Fall sehr beeindruckend und spannend zu sehen, wie sich Solr aktuell nach nun mehr als zehn Jahren weiterentwickelt.


Ein Wort der Vorsicht zum Schluss: Streaming Expressions werden zum jetzigen Zeitpunkt (Solr 6.3.0) noch als experimentell angesehen, d.h. oben beschriebenes Beispiel kann in aktuelleren Versionen zu Fehlern führen bzw. sogar nicht mehr im Funktionsumfang enthalten sein.

Mehr als nur eine Suchmaschine – Solr goes Machine Learning! Teil I

Mehr als nur eine Suchmaschine – Solr goes Machine Learning! Teil II

SEARCH & BIG DATA, BERATUNG, SCHULUNG, ENTWICKLUNG, SUPPORT, PUBLISHER SOLUTIONS
MIT APACHE SOLR, LUCENE, ELASTICSEARCH, SMARTLOGIC SEMAPHORE, SHI INFOPILOT