René Kriegler leitet den Bereich E-Commerce bei OpenSource Connections (OSC). Vorrangiges Ziel des Teams von OSC ist es, seine Kunden zu befähigen, ihre Suche zu verstehen und zu optimieren, so dass die Suche zu einem treibenden Faktor bei der Verbesserung der Online-Verkäufe wird. René arbeitet seit mittlerweile 15 Jahren im Bereich Suche, unter anderem für einige der deutschen Top-10 E-Commerce-Seiten. Er ist Mitgründer und -organisator der Veranstaltung MICES (Mix-Camp E-Commerce Search), auf der seit nunmehr fünf Jahren die E-Commerce-Search-Community zusammenkommt. Renés technologischer Schwerpunkt liegt auf Open-Source-Technologien wie Solr und Elasticsearch. Er ist Gründer und Maintainer der Querqy-Bibliothek und Mitinitiator des Chorus-Projekts, das verschiedene Open-Source-Tools zu einem abgestimmten Paket zur Implementierung einer E-Commerce-Suche vereint.
Hallo René! Wir möchten heute mit dir vor allem über das Open-Source-Projekt Querqy sprechen, aber auch über das neuere Projekt Chorus. Querqy gibt es ja schon eine Weile und wir glauben im Bereich Suche im E-Commerce sollte man Querqy unbedingt auf dem Zettel haben. Beschreibe uns doch einmal was Querqy ist und was es mit dem neuen Projekt Chorus auf sich hat.
Querqy ist eine Open-Source-Java-Bibliothek für Solr und Elasticsearch, um Suchabfragen umzuschreiben, also „auf gut Deutsch“ ein Query-Rewriting-Framework. Das klingt erstmal sehr technisch, aber gerade für den Bereich E-Commerce-Suche bekommt man über das Query-Rewriting ein mächtiges Werkzeug, seine Suche für einzelne Suchanfragen ganz gezielt zu optimieren.
Möchte ich zum Beispiel für eine bestimmte Suchabfrage Produkte einer bestimmten Marke ganz oben anzeigen oder – das andere Extrem – Produkte einer Marke für diese Abfrage ausblenden, kann ich das über Query-Rewriting lösen. Ein anderes häufiges Problem, für das Querqy eine Lösung bietet, ist das „Zubehör-Problem“: Ich suche nach „smartphone“ und bekomme lauter Ladekabel auf den ersten Positionen. Das möchte man zwar am liebsten algorithmisch lösen, also mit dem allgemeinen Ranking-Algorithmus der Suchmaschine, und nicht spezifisch, pro Suchabfrage, aber leider schaffen das auch die besten Algorithmen nicht für alle Suchanfragen. Wenn es sich dann noch um eine sehr wichtige, häufige Suchabfrage handelt, kommt man um solch eine spezifische Lösung nicht herum.
Mit Query-Rewriting kann man nicht nur das Ranking optimieren, sondern auch das „Matching“. Das kann zum Beispiel durch das Einfügen von Synonymen in die Suchabfrage erfolgen – also zum Beispiel „Finde auch ‘laptop’, wenn jemand nach ‘notebook’ sucht“.
Das Rewriting kann man mit Querqy aber noch sehr viel weitertreiben. Wenn zum Beispiel jemand nach „notebook 15 zoll“ sucht und man ein Feld für die Bildschirmdiagonale in cm hat, ließe sich diese Abfrage umschreiben zu: „Finde
notebook oder laptop mit Bildschirmdiagonale von ca. 34 bis 42 cm aber bringe solche mit Bildschirmdiagonale nahe 38 cm nach oben“
Diese Funktionalität wird mit Hilfe von sogenannten Rewritern implementiert – also quasi einem kleinen Bausatz von Komponenten, von denen jede die Suchabfrage jeweils auf eine spezifische Weise umbaut. Davon bringt Querqy schon einige mit, man kann aber auch für seine spezifischen Bedürfnisse seine eigenen Rewriter implementieren.
Mit Chorus können sich Teams viel früher den Lösungen für ihre spezifischen Suche-Probleme zuwenden – hier entsteht dann auch erst der eigentliche Nutzen aus der Entscheidung, eine E-Commerce-Suche auf Basis von Open-Source-Software zu implementieren.
Mit Querqy bekommt man schon mal ein sehr mächtiges Werkzeug, um die Qualität einer Suchanwendung zu verbessern. Allerdings ist dieses Werkzeug noch nicht sehr handlich. Will man zum Beispiel neue Synonym-Regeln anlegen, müsste man immer noch auf das Entwicklungsteam zurückgreifen. An dieser Stelle kommt nun Chorus ins Spiel. Dabei handelt es sich um ein abgestimmtes Ensemble von Open-Source-Tools zur Implementierung einer E-Commerce-Suche. Startet man Chorus, bekommt man eine kleine Suchanwendung, welche mehrere Tools integriert: Als Suchmaschine wird Solr mit integriertem Querqy gestartet. Mit SMUI – dem Search Management User Interface – kann man sofort loslegen, und ‘Searchandizing’-Regeln für Querqy pflegen. Also zum Beispiel Regeln für das Ranking und Matching, wie ich sie beschrieben habe. Zudem stehen noch eine Reihe von Tools wie Quepid oder ‘Rated Ranking Evaluator’ parat, mit denen man Suchqualität bewerten und optimieren kann.
Für uns als Chorus-Initiatoren war es wichtig, den Sucheteams mit Chorus einen Weg aufzuzeigen, die Entwicklungszeit, die man in einem Open-Source-Projekt normalerweise aufwendet, um mit kommerziellen Lösungen erstmal gleich zu ziehen, erheblich zu verkürzen. Mit Chorus können sich Teams viel früher den Lösungen für ihre spezifischen Suche-Probleme zuwenden – hier entsteht dann auch erst der eigentliche Nutzen aus der Entscheidung, eine E-Commerce-Suche auf Basis von Open-
Source-Software zu implementieren.
Was war für dich ausschlaggebend, Querqy zu entwickeln? Wie kam das Ganze ins Rollen?
Das war „produktiver Ärger“! Und dabei ging es eigentlich um zwei Dinge: Ich war damals vor allem mit Solr unterwegs, und sobald es bei Synonymen um solche ging, die sich auf mehrere Wörter beziehen, gab es Probleme. Sowohl mit dem Auffinden von Treffern als auch mit dem Ranking. Das war 2014, und selbst heute sind trotz beträchtlicher Fortschritte solche Multi-Wort-Synonyme sowohl in Solr als auch in Elasticsearch nicht 100%ig gelöst. Querqy löst diese Probleme seit seiner ersten Version vor allem dadurch, dass es einen expliziten Ort für das Umschreiben von Suchabfragen einführt, wo sich viele Operationen viel leichter als in Solr oder Elasticsearch anwenden lassen.
Der zweite Grund Querqy zu entwickeln lag darin, dass in einem Migrationsprojekt von einer kommerziellen Suche-Lösung zu Solr lange Zeit offen war, wie wir die ‘Searchandizing’-Features der kommerziellen Suchmaschine in Solr abbilden können. Wahrscheinlich jede kommerzielle Suchmaschine bietet die Möglichkeit, solche
Regeln zu pflegen, also zum Beispiel zu sagen: Wenn die Suchabfrage ‘iPhone’ ist, bringe Apple-Produkte nach vorn. Warum sollten die Open-Source-Suchmaschinen das nicht können?
Heute nutzen einige der deutschen Top-10-E Commerce-Sites Querqy und es ist auch zunehmend international verbreitet. Wir sehen gut 4000 Downloads pro Monat.
Wir konnten damals dann einen Kunden für die Idee gewinnen, in die Entwicklung von Querqy als Open-Source-Bibliothek zu investieren, und so nahm die Sache ihren Lauf. Heute nutzen einige der deutschen Top-10-E-Commerce-Sites Querqy und es ist auch zunehmend international verbreitet. Wir sehen gut 4000 Downloads pro Monat.
Du weist auch immer wieder darauf hin, dass Querqy einem nicht nur ermöglicht, Suchergebnisse manuell oder durch die Rewriter zu verbessern, sondern im Kern schon Vorteile beim Relevanzscoring im Bereich E-Commerce mitbringt. Das heißt, auch ohne die Pflege vieler Regeln und ohne ausgefuchste Rewriter könnte Querqy alleine als Query Handler schon Vorteile bringen?
Ja, das ist in der Tat so, wobei die Größe des Effekts von der konkreten Anwendung abhängt.
Hintergrund ist, dass die Ranking-Modelle in Lucene – also der Suche-Bibliothek im Kern von Solr und Elasticsearch – eigentlich für das Auffinden von Textdokumenten gedacht sind. Dabei geht es vorwiegend um unstrukturierte, oft auch längere Texte, in denen viele verschiedene Themen repräsentiert sind. Für die E-Commerce-Suche brauchen wir jedoch ein Ranking-Modell für strukturierte Daten, mit verschiedenen Feldern, die kurze Texte oder oft nur Namen und Bezeichnungen enthalten und bei denen ein einzelner Datensatz für genau ein Produkt steht. Querqy verbessert zumindest den Umgang mit Feldern etwas, und das tut es auch ohne einen einzigen Rewriter.
Fachlich würde ich immer zu Querqy raten, da es vor allem für den E-Commerce-Bereich wichtige Features bereitstellt, für die es meines Wissens aktuell im Open-Source-Bereich keine andere Lösung gibt.
Gibt es eigentlich irgendeinen Grund, Querqy in einem Solr oder Elasticsearch E-Commerce-Suche-Projekt nicht zu nutzen?
Da fällt mir in der Tat kaum ein Grund ein. Sollte eine Suche die Solr-Suchesyntax an die Endnutzer weitergegeben haben – also zum Beispiel die Möglichkeit Feldnamen einzugeben, oder Operatoren wie AND und OR in die Query einzubauen – könnte es
schwierig werden. Aber das wäre eigentlich im E-Commerce eher ungewöhnlich und wohl auch eine „Bad Practice“. Fachlich würde ich immer zu Querqy raten, da es vor allem für den E-Commerce-Bereich wichtige Features bereitstellt, für die es meines Wissens aktuell im Open-Source-Bereich keine andere Lösung gibt.
Wie hoch schätzt du den Integrationsaufwand von Querqy ein?
Der Aufwand hängt vom konkreten Projektkontext ab. Ist man ohnehin im Rahmen einer Migration beim Neuaufsetzen der Suchmaschine, ist der zusätzliche Aufwand eigentlich zu vernachlässigen – Querqy verwendet grundsätzlich Konzepte, die aus Solr oder Elasticsearch vertraut sind. Zudem kann Chorus noch als zusätzliche Blaupause verwendet werden. Größere Aufwände sehe ich gelegentlich bei bestehenden Elasticsearch-Anwendungen. Das Zusammenbauen von Suchanfragen mit Bordmitteln ist aus meiner Sicht in Elasticsearch für E-Commerce-Anwendungen nicht optimal lösbar.
In der Konsequenz bauen sich Teams oft umfangreiche Komponenten zum Erstellen der Suchabfragen außerhalb von Elasticsearch. Daraus ergibt sich dann natürlich ein gewisser Aufwand bei der Umstellung auf Querqy, was dann diese Funktion ersetzt.
Welche Pläne habt ihr konkret für die nächsten Versionen von Querqy?
Wir denken in Querqy eigentlich nicht so sehr in Versionen, sondern versuchen sehr schnell zu releasen, wenn ein Feature implementiert wurde. Zu einem gewissen Grade werden diese Features auch durch die Pull-Requests – also durch die Zuarbeiten aus der Community – bestimmt. Aus Maintainer-Sicht wollen wir vor allem versuchen, das Erstellen eigener Query-Rewriter einfacher zu machen, so dass jedes Entwicklungsteam unkompliziert Rewriter für seine spezifischen Anwendungsfälle implementieren kann. Zudem gibt es erste Experimente, das Query-Rewriting mit Querqy ganz oder teilweise außerhalb der Suchmaschine zu lösen. Das wäre zum Beispiel in Fällen interessant, in denen das Rewriting zusätzliche, sich häufig aktualisierende Datenquellen benötigt,
oder wenn auf komplexere maschinen-gelernte Modelle zugegriffen werden soll.
Wenn du dir einfach so ein neues Feature für Querqy wünschen könntest, was wäre das?
Manchmal wünsche ich mir, dass Querqy nicht nur ein Query-Rewriting-Framework wäre, sondern auch gleich noch ein Framework, um flexiblere Ranking-Modelle in Solr und Elasticsearch zu implementieren. Vor allem in Hinblick auf ein besseres Ranking im E-Commerce.
Danke René für das Interview, die Einblicke in Querqy und Chorus und auch die Zeit und Energie, die du in die E-Commerce Search Community und Open-Source-Projekte steckst. Ich finde, das hat den deutschsprachigen Bereich Suche im E-Commerce in den letzten Jahren deutlich vorangebracht.
Alle Infos zu Querqy, SMUI, Chorus sind auf https://querqy.org zu finden. Infos zur Teilnahme oder zu den Inhalten der letzten Jahre der MICES Konferenz zum Thema Suche im E-Commerce findet man unter https://mices.co.
Wer Teil der E-Commerce-Suche-Community werden möchte oder Fragen und Anregungen hat, dem empfehlen wir den E-Commerce Search Slack Channel https://ecom-search.slack.com.
Die Webseite von OpenSource Connections https://opensourceconnections.com hält interessante englischsprachige Inhalte und Infos zu den Tools Quepid und Splainer bereit. OpenSource Connections bietet auch Trainings für Solr und Elasticsearch sowie für Learning to Rank in beiden Suchlösungen an.
