Mintel nutzt die mehrsprachige Suche, um globale Abonnenten anzusprechen

Mintel ist seit fast 50 Jahren eine vertrauenswürdige Quelle für Marktinformationen und hat jeden Monat über 35 Tausend Nutzer. Angesichts der großen Bandbreite an Themen, die in den Berichten von Mintel behandelt werden, und eines weltweiten Kundenstamms, der eine Vielzahl von Sprachen spricht, war es für das Engineering-Team von Mintel eine Herausforderung, jedem Kunden ein intuitives Sucherlebnis zu bieten. Erfahren Sie, wie Mintel Fusion Query Pipelines einsetzt, um jedem Benutzer relevante Suchergebnisse in seiner bevorzugten Sprache zu liefern.

Redner: Adrian Rogers, Mintel, Architekt

Zum Mitnehmen

In dieser Sitzung erfahren die Teilnehmer, wie wir unseren Index und unsere Abfrage-Pipelines strukturiert haben, um die Suche nach Inhalten zu ermöglichen, die in mehreren Sprachen indiziert sind und in der bevorzugten Sprache des Benutzers zurückgegeben werden.

Publikum

Diese Sitzung ist nützlich für Softwareentwickler. Besonders wenn Sie mit Inhalten in mehreren Sprachen arbeiten.

Themen

Suchrelevanz; Handel – Ecommerce Suche und Personalisierung;

Sprecher Bio

Adrian Rogers arbeitet als Architekt im IT-Team von Mintel. Er hat an einer Vielzahl von Projekten innerhalb des Unternehmens mitgewirkt, u.a. am Aufbau der Inhaltssuchfunktionen mit Solr und Fusion.

[Adrian Rogers]

Herzlich willkommen. Mein Name ist Adrian Rogers. Ich bin Architekt und arbeite für Mintel. Und heute werde ich darüber berichten, wie wir das Problem der mehrsprachigen Suche angegangen sind.

Ich beginne mit einem kurzen Überblick über die Herausforderungen, mit denen wir konfrontiert waren, und stelle dann vor, wie Lucidworks Fusion uns in diesem Bereich geholfen hat. Ich werde auch ein wenig mehr auf die technischen Details unserer Lösung eingehen, bevor ich am Ende ein Fazit ziehe.

Als vertrauenswürdige Quelle für Marktinformationen, die es seit fast 50 Jahren gibt, verfügt Mintel über eine ständig wachsende Anzahl von Forschungsinhalten. Ursprünglich waren diese Inhalte nur in englischer Sprache verfasst, aber als wir in jüngster Zeit in neue Märkte vordrangen, wollten wir unsere Inhalte auf diese Märkte zuschneiden und insbesondere die Inhalte in die jeweiligen Landessprachen übersetzen. Derzeit unterstützen wir sechs verschiedene Sprachen für unsere Inhalte, und zwar Englisch, Chinesisch, brasilianisches Portugiesisch, Deutsch, Thailändisch und Japanisch.

Die Herausforderung besteht nun darin, dass unsere Nutzer in der Lage sein sollen, nach diesen Inhalten in der Sprache zu suchen, die sie am besten beherrschen. Und ich sollte vielleicht gleich zu Beginn klarstellen, dass wir nicht versuchen, ihre Suchanfragen zu übersetzen. Wir versuchen nur sicherzustellen, dass sie, wenn sie nach einer von uns unterstützten Sprache suchen, in der Lage sind, nach diesen Inhalten zu suchen und sie korrekt anzuzeigen. Darüber hinaus möchten wir, dass sie ihre Ergebnisse sehen können, insbesondere die Übersetzungen der Inhalte, die ihren Wünschen entsprechen, ohne dass gleichzeitig andere übersetzte Versionen angezeigt werden und die Suchergebnisse mit Duplikaten überladen werden.

Als Benutzer von Lucidworks Fusion verlassen wir uns also auf eine der wichtigsten Funktionen, um dieses Problem zu lösen. Und die Funktion, die wir dafür hauptsächlich verwenden, sind Abfrage-Pipelines. Wir machen also ausgiebig Gebrauch von Pipelines, um sicherzustellen, dass wir unabhängig davon, woher eine Suche kommt, in der Lage sind, Sprache und Übersetzungen angemessen zu behandeln. Wir tun dies, indem wir sowohl die Abfragen, die wir an Solr senden, als auch die Felder, die zurück angefordert und dann an den Endbenutzer zurückgegeben werden, dynamisch ändern.

Ich werde mit einigen Grundlagen beginnen. Bevor wir also über die Pipelines sprechen können, müssen wir uns das Schema ansehen, denn ohne die Möglichkeit, Felder in den verschiedenen Sprachen richtig zu speichern und zu verarbeiten, können wir sie nicht genau durchsuchen und die richtigen Funktionen anbieten. Dies hier ist also nur ein Beispiel für unser Schema. Aber jede Sprache, die wir unterstützen, hat im Wesentlichen ihren eigenen Feldtyp, auf den die entsprechenden Tokenizer und Stemmer angewendet werden können, sowie alle speziellen Stoppwörter oder andere sprachspezifische Elemente, die in die Analysatoren einfließen müssen. Diese Feldtypen werden dann auf alle unsere durchsuchbaren Felder für diese spezifischen Sprachen angewendet.

Für einen bestimmten Inhalt werden alle Übersetzungen dieses Inhalts in einem einzigen Solr-Dokument indiziert. Das bedeutet, dass ein Solr-Dokument sowohl die englischen Versionen der Felder als auch die lokalisierte Sprache enthält, und wenn es mehr als eine lokalisierte Sprache gibt, wird auch diese mit einbezogen. Dies hilft uns, unser Kriterium zu erfüllen, niemals mehr als eine Übersetzung eines Inhalts anzuzeigen, da immer nur ein einziges Dokument zurückgegeben wird und wir von dort aus nur die entsprechenden Felder aufrufen.

Und da wir gerade von diesen Feldern sprechen: Neben den Feldern für die Suche haben wir auch Felder, die für den Abruf als einfache Zeichenketten gespeichert werden. Es handelt sich also um einfache Zeichenketten, weil wir keine Tokenisierung oder ähnliches vornehmen müssen. Wir wollen nur die Werte. Und auch dies ist mit der gleichen Feld- und Namensstruktur aufgebaut. Alles, was wir haben, endet also mit .lang, einem Punkt und dann dem Sprachcode. Sobald wir das Schema eingerichtet haben, war der nächste Schritt, die Abfrage-Pipeline in Angriff zu nehmen.

In der Pipeline beginnen wir mit zwei Nicht-Standard-Eingabevariablen, mit denen Solr nichts anzufangen wüsste. Für uns müssen wir jedoch zunächst überprüfen, ob beide vorhanden sind, da wir sie in zukünftigen Pipelineschritten verwenden werden, und wir müssen auch überprüfen, ob es sich um gültige Sprachcodes handelt. Wir haben hier also die Eingabesprache, d.h. die Sprache, in der der Benutzer zu suchen versucht. Derzeit leiten wir diese Sprache von der Ausgabesprache ab. Wir bei Mintel haben jedoch Pläne, Tools zur automatischen Erkennung der Eingabesprache zu entwickeln, um die Suche etwas umfassender zu gestalten. Die Ausgabesprache steht für die Sprache, in der der Benutzer versucht, unsere Website zu betrachten, und für die Sprache, in der er die Inhalte bevorzugt liest.

Indem wir also sicherstellen, dass diese Einstellungen vorhanden sind und für eine von uns unterstützte Sprache gelten, sind wir in der Lage, die nächsten Schritte der Pipeline durchzuführen. Der zweite Schritt besteht darin, die Felder zu ändern, nach denen Solr tatsächlich sucht. Dazu fügen wir qf-Argumente für die spezifischen Eingabesprachen hinzu, die angefordert werden.

Wir werden immer Englisch als eines der Suchfelder angeben, da die meisten unserer Inhalte immer noch auf Englisch sind und wir die Ergebnisse für die Nutzer nicht so stark einschränken wollen, wenn es nicht wirklich viele Ergebnisse gibt, und vor allem, weil wir die Eingabesprache noch nicht automatisch erkennen. Was wir jedoch tun werden, ist, die angeforderten Sprachfelder zu verstärken, so dass alle Artikel, die mit dieser Sprache übereinstimmen, hoffentlich etwas weiter oben angezeigt werden und der Nutzer Artikel und Inhalte in der von ihm bevorzugten Sprache sieht.

Schließlich richten wir die Felder für den Rückgabewert ein. Dies ist nun ein Schritt, der benutzerdefiniertes JavaScript enthält. Er durchläuft eine Schleife über alle übergebenen fl-Argumente und überprüft jedes einzelne, ob es mit einer Liste von Feldern übereinstimmt, für die es möglicherweise eine übersetzte Version gibt. Wenn dies der Fall ist, ersetzen wir das fl-Argument durch eine Solr def-Funktion. Diese Funktion besagt im Grunde, dass Sie versuchen sollen, die Version des Feldes in der Ausgabesprache auszuwählen, wenn sie vorhanden ist. Ist sie nicht vorhanden, greifen wir auf die englische Version zurück und holen sie ab. Wenn es also eine Version der Ausgabesprache für den gewünschten Inhalt gibt, sollten wir hoffentlich in der Lage sein, sie zu liefern. Ist dies nicht der Fall, stellen wir den Inhalt trotzdem bereit, wenn auch auf Englisch.

Sobald wir diese Rückgabefelder umgeschrieben haben, wendet die Pipeline den Rest unserer Geschäftslogik an. Es handelt sich also um alles, was im Wesentlichen sprachunabhängig ist, also Dinge wie Relevanzsteigerung, signalbasierte Benutzerpräferenzen und all diese anderen Dinge, die auf strukturierten Metadaten und nicht auf freien Textfeldern basieren. Diese Schritte werden von den Eingabe- und Ausgabesprachen nicht beeinflusst. Sie werden also vor der endgültigen Ausführung der Abfrage ausgeführt und liefern dem Benutzer hoffentlich die Ergebnisse, die er sehen möchte. Um es also kurz zusammenzufassen. Um die mehrsprachige Suche zu ermöglichen, haben wir zunächst unser Schema aktualisiert, damit unser Suchindex die Suche in den gewünschten Sprachen unterstützen kann.

Dann fügten wir einen Schritt hinzu, um festzustellen, in welcher Sprache der Benutzer suchen möchte und in welcher Sprache er seine Ergebnisse erhalten möchte. Wir fügten einen Schritt hinzu, um die Solr-Anfrage so zu aktualisieren, dass die Suche in der bevorzugten Eingabesprache des Benutzers durchgeführt wird. Wir fügten einen Schritt hinzu, um die Solr-Anfrage ebenfalls zu aktualisieren, damit die Felder in der bevorzugten Sprache zurückgegeben werden, die der Benutzer lesen möchte. Und schließlich führen wir wie üblich alle anderen sprachunabhängigen Schritte aus.

Vielen Dank, dass Sie zugehört haben. Ich hoffe, dies war hilfreich.