Die Vorstellung, dass der schwierige Teil sprachlicher Natur sei, ist irreführend; sobald sowohl die Suchanfrage als auch das Dokument in einem gemeinsamen Format dargestellt sind, würde man erwarten, dass sich die Relevanz von selbst ergibt. Dies ist jedoch nicht der Fall. Cross-Language Information Retrieval (CLIR) definiert die sprachübergreifende Suche formal als eine Abrufaufgabe, bei der das Ziel darin besteht, Dokumentenkandidaten in einer anderen Sprache danach zu ordnen, wie relevant sie für die Suchanfrage sind. In ihrer umfassenden Übersicht über mehrsprachige Retrieval-Systeme definieren Peters, Braschler und Clough CLIR als eine dem Wesen nach retrievalbezogene Aufgabe. Nutzer formulieren ihren Informationsbedarf in einer Sprache und lassen das System anschließend relevante Dokumente in einer anderen Sprache abrufen. Obwohl die Übersetzung eine notwendige Komponente für den Aufbau der sprachlichen Brücke ist, stellt sie nicht das gesamte System dar. Vielmehr bildet die Übersetzung die Grundlage für die sprachliche Brücke, während die Rangfolge bestimmt, was auf Platz 1 erscheint.
Die Lösung des ersten Problems bedeutet nicht zwangsläufig auch die Lösung des zweiten.
Seit Jahren haben Forscher am CLIR gezeigt, dass es nie einen Engpass hinsichtlich der Qualität der Übersetzung selbst gegeben hat. Es gab jedoch schon immer einen Engpass: die Präzision der Suche nach der Transformation. Bei der Übersetzung geht es darum, ein Format zu entwickeln, das alle „guten“ Dokumente findet (d. h. Relevanz), und nicht darum, wie gut diese guten Dokumente in ein für Menschen lesbares Format übersetzt werden. Dies ist ein Problem der Suche. Systeme, die ihre Übersetzungen optimiert, ihr Ranking jedoch nicht optimiert haben, werden im Vergleich zu Systemen, die ihr Ranking optimiert haben, immer schlecht abschneiden. Die Oberflächenform spielt keine Rolle mehr; entscheidend ist die Position.
Die mehrsprachige Suche ist daher für globale E-Commerce-Plattformen, SaaS-Produkte oder inhaltsreiche Anwendungen nicht optimal. Was Entscheidungsträger wirklich interessieren, sind die Kosten für die Indizierung, die Kosten für das Sprachmodell, die Gleichwertigkeit der Relevanz über mehrere Sprachen und Regionen hinweg, die operative Komplexität bei der Verwaltung der Konfigurationsoptionen für jede Spracheinstellung sowie die Zeit bis zur Markteinführung, sobald ein Unternehmen beschließt, in ein neues Sprachökosystem einzusteigen.
Eine Plattform, die auf Englisch zwar korrekt, auf Französisch jedoch falsch gerankt wird, wird in Frankreich Geld verlieren. Und dieser finanzielle Verlust lässt sich messen. Doch das korrekte Ranking der darüber liegenden Übersetzungsebene gleicht das falsche Ranking nicht aus.
Es muss ein wesentlicher Unterschied bestehen zwischen den NLP-Funktionen (Spracheinbettung und/oder optionale Übersetzungen) und den Funktionen, die wir als „sprachliche Echtzeit-Erkennung“ bezeichnen könnten; anschließend sendet das NLP die Länderkennung, den Vektor und die normalisierte Abfrage an die Abrufebene. Die Abrufebene nutzt diese Eingaben, um sprachbewusste Tokenisierung, Filterung usw. durchzuführen und deterministische sowie erklärbare Ergebnisse in großem Maßstab zu liefern. Obwohl Googles BERT-Implementierung das Verständnis der Suchanfrage verbessert hat, bevor diese an die Abrufebene weitergeleitet wird, hat dies dennoch Auswirkungen auf die Art und Weise, wie das Ranking erfolgt, da der Ranking-Mechanismus unverändert bleibt und unabhängig vom Sprachverstehensmechanismus ist.
Es ist außerdem wichtig, die sequenzielle Struktur der Sprachverstehens- und Bewertungsschichten beizubehalten, da eine Kombination beider Schichten negative Auswirkungen auf beide Schichten hat.
Zudem gibt es keine übergreifenden Relevanzebenen, die alle Sprachmärkte abdecken, weshalb jeder Sprachmarkt dieses Problem eigenständig lösen muss. Jede Sprachversion muss in der Lage sein, mehrere Indizes, Ad-hoc-Übersetzungsabläufe und mehrere Synonymlisten zu verarbeiten. Darüber hinaus werden die daraus resultierenden Ranking-Regeln marktbezogen trainiert, was jedoch keine Konsistenz der Ergebnisse zwischen den verschiedenen Märkten gewährleistet.
Schließlich steigt der Komplexitätsaufwand für die Unterstützung mehrerer Sprachen proportional zur Anzahl der unterstützten Sprachen, sofern keine spezielle Designarchitektur für die mehrsprachige Indizierung vorliegt, wie in der Dokumentation zu Microsoft Azure AI Search dargestellt. Daher muss eine Plattform, die zehn Sprachen unterstützt, ohne eine zentrale Instanz zur Steuerung der Relevanz, zehn separate Relevanzprobleme gleichzeitig bewältigen.
Algolia Fit: Die fünf Signale vereint
Die Algolia AI Search nutzt die Ergebnisse der NLP-Verarbeitung als Ebene zur Umwandlung des Textes und liefert so präzise Relevanz im Kontext mehrsprachiger Relevanz. Fünf Arten heterogener Signale werden verwendet, um eine einzigartige Art von Informationen bereitzustellen, die mit einer einzelnen NLP-Primitive nicht erzeugt werden können.
Algolia bietet eine zentrale Plattform für die Verwaltung der fünf Faktoren, die das Sucherlebnis der Nutzer in zahlreichen Sprachen beeinflussen; dabei wird die Muttersprache des Nutzers als Grundlage für die Generierung der morphologischen Regeln zur Tokenisierung der Nutzereingabe herangezogen; außerdem werden Suchanfragen an Konfigurationen weitergeleitet, die der Ländereinstellung des Nutzers entsprechen (fr-CA und fr-FR verfügen über unterschiedliche Synonymlisten, Werberegelsätze und verfügbare Filter), sodass für jede Ländereinstellung die richtige Konfiguration zurückgegeben wird. Algolia passt die Gewichtung der Ranking-Faktoren im Algorithmus auf der Grundlage der semantischen Bedeutung der Suchanfrage an, um besser zu ermitteln, was der Nutzer mit seiner Suche erreichen möchte – Stöbern, Kaufen oder Recherchieren. Algolia berücksichtigt zudem regionale kulturelle Unterschiede innerhalb der einzelnen Regionen, in denen das Unternehmen tätig ist, und zwar durch Produktbenennungskonventionen, saisonale Marketingzeiträume sowie die Art und Weise, wie Markenführung und Treueprogramme in diesen Regionen wahrgenommen werden – allesamt Faktoren, die in anderen Regionen nicht vorhanden wären. Darüber hinaus wird durch die Segmentierung von Klick- und Konversionsdaten aus den aggregierten globalen Daten nach Sprachraum sichergestellt, dass die globalen, verkehrsstarken Marktsegmente keinen Einfluss auf Suchergebnisse außerhalb der Sprachräume haben, in denen sie Traffic generieren. Die Logik zur Erstellung einer einheitlichen Rangberechnung wird einheitlich angewendet, um Suchergebnisse für jeden Markt zu generieren.
Technische Umsetzung: Schema für das Relevanzparitätssignal
Das Datenmodell enthält alle notwendigen Informationen zur Erstellung eines indizierten, mehrsprachigen Produktdatensatzes mit Lokalisierungshinweisen und Sprachmetadaten, um gleichgewichtete Rankings über mehrere Märkte hinweg zu ermöglichen. Da die sprachbezogene Verarbeitung auf Indexebene konfiguriert wird (über Einstellungen wie „indexLanguages“ und „ignorePlurals“), spiegeln Tokenisierung, Stemming und die Eliminierung von Stoppwörtern die sprachlichen Eigenschaften der jeweiligen Sprache wider, ohne dass im Anwendungscode Analysatoren für einzelne Felder zugewiesen werden müssen. Alle Felder der Geschäftslogik (Margengewicht, Verfügbarkeit und Aktionspriorität) sind sprachneutral und liefern daher bei Abfragen nach Ländereinstellung das gleiche Ergebnis, wodurch eine einheitliche Geschäftslogik zur Unterstützung der Rangfolge von Suchergebnissen über alle Märkte hinweg gewährleistet wird.
/**
* Multilingual Product Record Schema
* Indexed in AI Search to support relevance parity across language markets.
* Language-specific fields utilize settings applied via index-level configuration.
* Business logic fields are locale-agnostic and applied consistently across all markets.
*/
{
"objectID": "product_carry_on_luggage_001",
"locale_signals": {
"primary_language": "en",
"supported_locales": ["en-US", "fr-FR", "ja-JP"],
"bcp47_tag": "en-US"
},
"content": {
"title_en": "Carry-on luggage, 22-inch hardshell",
"title_fr": "Bagage cabine, coque rigide 22 pouces",
"title_ja": "機内持ち込みスーツケース、22インチハードシェル",
"description_en": "Lightweight hardshell carry-on approved for major airlines.",
"description_fr": "Bagage cabine léger approuvé par les principales compagnies aériennes.",
"description_ja": "主要航空会社に対応した軽量ハードシェルの機内持ち込み荷物。"
},
"ranking_signals": {
"margin_weight": 0.82,
"availability_score": 1.0,
"promotional_priority": 2,
"market_popularity": {
"en-US": 9800,
"fr-FR": 4200,
"ja-JP": 3100
}
},
// Illustrative: in production, analyzer assignments live in index settings, not the record
"language_analyzer_config": {"en": "english", "fr": "french", "ja": "japanese" }
}
Zum Zeitpunkt der Suche verwendet die Routing-Ebene das BCP-47-Tag, das sie für die Sitzung des Nutzers ermittelt hat (über die Browser-Lokalisierung, Kontoeinstellungen oder Spracherkennung durch einen vorgelagerten Dienst), um die Suchanfrage an die entsprechende Sprachspalte weiterzuleiten. Alle anderen Spalten der Geschäftslogik werden unverändert angewendet. Beispielsweise erhalten Nutzer in allen drei Märkten Ergebnisse mit denselben Margengewichtungen, Verfügbarkeitswerten und Werbeprioritäten, die unter Verwendung der korrekten Morphologie für ihre jeweilige Sprache normalisiert wurden. Daher wird die Relevanzparität auf Schemaebene (d. h. auf Datenbankebene) durchgesetzt und nicht erst zur Laufzeit aus mehreren unabhängigen Lokalisierungs-Pipelines zusammengestellt.
2. NeuralSearch: die Hybrid-Suchmaschine für globale Präzision
Die Optimierung der semantischen Ähnlichkeit zwischen Vektoren und Suchergebnissen innerhalb eines Einbettungsraums bedeutet nicht immer, dass das relevanteste Suchergebnis für einen bestimmten Nutzer mit einem bestimmten Geschäftsziel an einem bestimmten geografischen Standort ermittelt wird. Ein Nutzer, der auf Japanisch nach „wasserdichten Laufschuhen“ sucht, würde die am höchsten rangierenden Ergebnisse erhalten, je nachdem, wie nah sein Suchbegriff dem eigenen im Einbettungsraum liegt (Trail-Schuhe, wasserabweisende Schuhe, Outdoor-Schuhe) – und nicht danach, welche Produkte zum Kauf verfügbar sind, welche die größte Gewinnspanne aufweisen oder derzeit beworben werden. Keyword-Übereinstimmungen liefern präzise Treffer, während Einbettungen semantisch verwandte Ergebnisse liefern; für die Mehrheit der kommerziellen Suchanfragen (z. B. Produktnamen, Modellnummern, Kategoriebegriffe, die exakt übereinstimmen müssen) ist dieser Kompromiss jedoch falsch.
Googles BERT zeigt, wie NLP innerhalb der Rahmenbedingungen von Suchmaschinen eingesetzt werden kann. Wenn man beispielsweise fragt: „Stehen Kosmetikerinnen bei der Arbeit viel?“, wusste BERT, dass sich „stehen“ auf die körperlichen Anforderungen des Berufs bezog und nicht auf „allein stehen“ – was ein keywordbasiertes Suchsystem niemals erkennen könnte. Google hat seine Sucharchitektur für BERT nicht abgeschafft, sondern das Sprachverständnis als Bestandteil des Suchprozesses integriert. Der Ranker, den Google bereits vor der Einführung von BERT nutzte, ist nach wie vor vorhanden und funktioniert genau wie zuvor. Das ist das Modell. NLP ermöglicht viele weitere Funktionen (z. B. Übersetzung, Generierung von Embeddings, Ermittlung der Sprache der Suchanfrage usw.). Die Abrufebene ermöglicht zudem weitere Prozesse wie Indizierung, Rangierung, Filterung und Geschäftslogik. Wenn man die beiden Ebenen auf ein bloßes Maß dafür reduziert, wie ähnlich die Vektordarstellungen sind, wird man wahrscheinlich ein System schaffen, das die Suchanfrage zwar viel besser versteht, aber wahrscheinlich weniger relevante Antworten liefert.
Wie dies in der Praxis umgesetzt wurde, wird im Folgenden dargestellt. Zunächst gibt ein Nutzer eine Suchanfrage auf Spanisch ein, und das NLP identifiziert die Sprache der Eingabe mithilfe von fastText’s lid.176 (mit 176 Sprachen basierend auf einer 917-KB-Binärdatei) und erstellt optional sprachübergreifende Embeddings über LASER oder mehrsprachige Sentence Transformers. Diese Ausgabe wird dann an nachgelagerte Prozesse weitergeleitet. Anschließend führt Algolia eine Suche in mehreren mehrsprachigen Indizes durch, wendet Regeln für ein lokalisierungsbewusstes Ranking an und nutzt Geschäftslogik (d. h. Verfügbarkeit, Gewichtung der Margen, Priorität von Werbeaktionen usw.), um die Reihenfolge der zurückgegebenen Ergebnisse in der entsprechenden Sprache zu bestimmen. NLP lieferte die Komponente zum Sprachverständnis. Algolia lieferte das Endergebnis. NeuralSearch bietet sowohl den semantischen als auch den Keyword-Betriebsmodus gleichzeitig an, wobei diese auf der Ranking-Ebene über einen einzigen API-Aufruf miteinander verschmolzen werden. Keiner der beiden Kanäle beeinträchtigt die Leistung des anderen. Das Hinzufügen sprachübergreifender semantischer Funktionen zu einem derzeit verwendeten mehrsprachigen Index beeinträchtigt nicht die Fähigkeit, exakte Begriffsübereinstimmungen zu liefern, die für kommerzielle Suchanfragen erforderlich sind.
Sprachübergreifende Embeddings trainieren Modelle für typologisch weit voneinander entfernte Sprachen (z. B. Japanisch und Englisch, Arabisch und Englisch, Chinesisch und Englisch) und nicht nur für europäische Sprachen, die eine hohe Wortschatzüberlappung aufweisen, um eine schnellere Suche zu ermöglichen; sie trainieren Modelle auch für Sprachpaare wie Englisch und Chinesisch, bei denen sich Schriftsysteme, Morphologie und Syntax stark voneinander unterscheiden. Mithilfe eines einzigen Encoders in LASER, der anhand von 223 Millionen parallelen Sätzen trainiert wurde, die entweder mit Englisch oder Spanisch gepaart waren, wird ein gemeinsames BPE-Wörterbuch für alle Sprachen verwendet. Daher können Sprachen mit geringeren Ressourcen die Trainingsdaten von Sprachen mit umfangreicheren Ressourcen nutzen. Der semantische Kanal von NeuralSearch funktioniert über diesen gesamten Sprachbereich hinweg. Wenn ein Nutzer auf Französisch nach „chaussures de course imperméables“ sucht, erhält er dieselben Suchergebnisse wie bei der Suche nach „waterproof running shoes“ auf Englisch, und die Suchergebnisse werden nach derselben Logik sortiert, die auch vom Unternehmen verwendet wird. Das bedeutet, dass nicht der Abstand des eingebetteten Objekts zu einem beliebigen Referenzpunkt im Vektorraum diese Reihenfolge bestimmt.
Die von Algolia entwickelte NeuralSearch-Technologie kombiniert vektorbasierte Verarbeitung natürlicher Sprache und Schlüsselwortabgleich in einer einzigen API. Die meisten Vektorsuchmaschinen, einschließlich solcher, die wie Algolia im Unternehmensmaßstab betrieben werden, nutzen hybride Ansätze, um Suchvorgänge mittels schlüsselwortbasierter Suche und/oder Verarbeitung natürlicher Sprache (NLP) durchzuführen, was den bei allen Vektorsuchmaschinen auftretenden Kompromiss zwischen Präzision und Recall ermöglicht. Algolia kann für Betriebs- und Verwaltungszwecke vollständig getrennte Indizes erstellen; da zudem die Latenz im Geschäftsmodell von Algolia ein messbarer Umsatzengpass und keine technische Präferenz ist, führt Algolia beide Abrufmodi ohne zusätzliche Kosten parallel aus.
Die Plattform wird weltweit drei Vorgaben für die KI-Suche als Relevanzplattform anwenden, die durch NLP möglicherweise niemals durchgesetzt werden können: die einheitliche Anwendung der Ranking-Logik über verschiedene Märkte hinweg, die Erklärbarkeit der Ergebnisse durch deterministische, überprüfbare Regeln sowie die Skalierbarkeit auf Unternehmensebene. Übersetzungs- und Sprachmodelle werden im vorgelagerten Bereich eingesetzt, um ihre beste Leistung zu erbringen; im nachgelagerten Bereich setzt Algolia die daraus resultierenden Ergebnisse um. Es ersetzt Übersetzungs- und Sprachmodelle nicht, sondern stellt sicher, dass die von ihnen erzeugten Ergebnisse zu den gewünschten Ergebnissen führen.
Technische Umsetzung: Hybrid-Abfragekonfiguration für mehrsprachige Indizes
Die Hybridkonfiguration wird verwendet, um neuronale Suchfunktionen für einen mehrsprachigen Produktindex zu ermöglichen, wobei sowohl die semantische, vektorbasierte Suche als auch die schlüsselwortbasierte Suche im sprachlichen Kontext (d. h. sprachbewusst) zum Einsatz kommen. Diese Konfiguration aktiviert den Vektorkanal über „semanticSearch“, während „searchableAttributes“ den Schlüsselwortkanal auflistet, da die sprachspezifischen Felder entsprechend der Ländereinstellung der Benutzersitzung sortiert werden. Das „customRanking“-Array ermöglicht die Anwendung einer einheitlichen Geschäftslogik auf alle Ergebnisse, die von einer der beiden Abrufmethoden zurückgegeben werden; dadurch wird sichergestellt, dass die kommerzielle Absicht das endgültige Ranking eines bestimmten Ergebnisses bestimmt, unabhängig davon, über welchen Abrufkanal dieses Ergebnis angezeigt wird.
/**
* NeuralSearch Hybrid Configuration for Multilingual Index
* Combines semantic vector retrieval with language-aware keyword matching.
* Business logic signals apply consistently across both retrieval channels.
* Locale-specific fields are prioritized by query routing at search time.
*/
const indexSettings = {
// Activate hybrid retrieval: semantic + keyword in one relevance stack
semanticSearch: {
eventSources: ["click", "conversion"],
},
// Language-specific fields ordered by retrieval priority
// Active field set overridden at query time by locale-aware routing function
searchableAttributes: [
"title_en, title_fr, title_ja", // Unordered: equivalent priority
"description_en, description_fr, description_ja",
"category_tags" // Language-agnostic taxonomy
],
// Business logic applied consistently across all locale-aware queries
customRanking: [
"desc(promotional_priority)",
"desc(availability_score)",
"desc(margin_weight)",
"desc(market_popularity.value)" // Locale-specific popularity injected at query time
],
// Typo tolerance configured per language morphology
// Japanese and CJK scripts require typo tolerance disabled: no whitespace delimiters
typoTolerance: true,
disableTypoToleranceOnAttributes: ["title_ja", "description_ja"], // CJK: no whitespace delimiters
minWordSizefor1Typo: 5,
minWordSizefor2Typos: 9,
// Distinct product grouping across locale variants
distinct: true,
attributeForDistinct: "product_base_id"
};
/**
* Locale-Aware Query Execution
* Injects BCP 47 tag and market popularity signal at search time.
* Routes semantic and keyword retrieval to locale-appropriate fields.
*/
async function searchMultilingual(query, userLocale) {
const localeFieldMap = {
"en-US": { titleField: "title_en", descField: "description_en" },
"fr-FR": { titleField: "title_fr", descField: "description_fr" },
"ja-JP": { titleField: "title_ja", descField: "description_ja" }
};
const { titleField, descField } = localeFieldMap[userLocale] || localeFieldMap["en-US"];
return await index.search(query, {
restrictSearchableAttributes: [titleField, descField, "category_tags"],
// Popularity ranking applied via customRanking in index settings (locale-agnostic),
ruleContexts: [userLocale], // Activates locale-specific Query Rules
analytics: true,
clickAnalytics: true
});
}
Der Parameter „ruleContexts“ ermöglicht es, dass ein Index je nach der Locale, aus der die Abfrage stammt, mehrere Indizes funktional repräsentieren kann. Wenn also eine japanischsprachige Abfrage mit dem Tag „ja-JP“ bei Algolia eingeht, werden nur die für diesen spezifischen Kontext konfigurierten „QueryRules“ aktiviert (z. B. lokalisierte Kategorie-Boosts, lokalisationsspezifische Synonym-Erweiterungen usw.), während alle anderen „QueryRules“ deaktiviert werden. Ebenso erhält der französische Nutzer die französischen „QueryRules“ und der amerikanische Nutzer die amerikanischen „QueryRules“ – alles aus demselben Index und verarbeitet über dieselbe Abfrageverarbeitungspipeline. Durch die Verwendung des Parameters „ruleContexts“ kann ein und derselbe Index somit je nach Markt unterschiedliche Verhaltensweisen aufweisen – ohne dass für jeden Markt eine zusätzliche Infrastruktur geschaffen werden muss.
3. Sprachliche Grenzen: Unterschiede in der Schrift und die Absicht hinter BCP 47
Jeder Lucene-Sprachanalysator hat seine eigene Art, mit den sprachlichen Besonderheiten seiner Muttersprache umzugehen. Elasticsearch, das auf der Ebene der Feldzuordnung Zugriff auf das Lucene-Analysatormodell bietet, stellt für jede Sprache einen Analysator bereit, der auf unterschiedlichen Filterketten basiert; es gibt keine einheitliche Filterkette und somit auch keinen einheitlichen Filtersatz, der beim Wechsel von einer Sprache zur anderen umgeschaltet oder angepasst wird. Der französische Analysator ist das anschaulichste Beispiel für dieses Konzept; er nutzt zunächst den französischspezifischen Elisionsfilter, um die verkürzten Artikel „l'“, „m'“, „t'“, „d'“, „j'“ und „s'“ zu entfernen; würde er dies nicht vor der Anwendung des Stemmers tun, würde die Token-Stemming-Verarbeitung dieselben Token erzeugen wie jene, die in den nicht flektierten Indexformen von Wörtern ohne Artikel zu finden sind. Die Filterkette des französischen Analysators ist wie folgt festgelegt: french_elision → french_lowercase → french_stop → french_stemmer. Es handelt sich also um vier aufeinanderfolgende Prozesse, von denen jeder notwendig ist und keiner durch den entsprechenden Prozess in Filterketten anderer Sprachen ersetzt werden könnte.
"rebuilt_french": {
"tokenizer": "standard",
"filter": [
"french_elision",
"lowercase",
"french_stop",
"french_stemmer"
]
}
Im Allgemeinen sind die bei Sprachen beobachteten Muster ähnlich, doch variieren die morphologischen Aspekte von Sprache zu Sprache erheblich. So kann beispielsweise der arabische Analysator vor der Wortstammbildung verschiedene Buchstabenformen (z. B. verschiedene Formen von „alef“, „taa marbuta“ und „yaa“) normalisieren, da festgestellt wurde, dass dieselben Wörter in unterschiedlichen orthografischen Formen bei einer identischen Suchanfrage zu falschen Nichtübereinstimmungen führen. Der deutsche Analysator hingegen bietet ein begrenztes, leichtes Stemming unter Berücksichtigung der Flexion, wendet jedoch standardmäßig keine Zerlegung auf zusammengesetzte Substantive an – d. h., „Handgepäckkoffer“ wird nicht mit einer Suchanfrage nach „Koffer“ abgeglichen, es sei denn, es wird ein optionaler Zerlegungsfilter unter Verwendung externer Wörterbuchressourcen angewendet. Ebenso fügen sowohl das Finnische als auch das Türkische den Wortstämmen grammatikalische Informationen hinzu, und zwar auf eine Weise, die kein englischer Stemmer jemals lösen könnte.
Fazit für die technische Leitung: Für alle oben genannten Sprachen stehen in Elasticsearch und Lucene spezifische Analysatoren zur Verfügung. In Lucene-basierten Architekturen besteht die entscheidende Aufgabe darin, jeden sprachspezifischen Analysator gezielt auf Feldebene zuzuweisen. [Hinweis: Dies gilt für Elasticsearch- und Lucene-Bereitstellungen. In Algolia wird das Sprachverhalten auf Indexebene über „indexLanguages“ und „queryLanguages“ konfiguriert; eine Zuweisung von Analysatoren auf Feldebene ist nicht erforderlich. Wie bereits erwähnt, schlagen die Standard-Analysatoren bei allen oben genannten Sprachen stillschweigend fehl – es gibt keine Fehler oder Warnungen, sondern lediglich falsche Ergebnisse.
BCP 47 – Das Rahmenwerk für die Erstellung von Tags (definiert in RFC 5646) und die Festlegung von Abgleichregeln (RFC 4647) stellt Locale-Tags mit maschinenlesbaren Locales bereit und ermöglicht es Entwicklern, Locale-Tags mit Subtags für Sprache, Schrift, Region und Variante zu erstellen. Gemäß den W3C-Richtlinien „sollten Sie das Tag so kurz wie nötig halten und Subtags nur hinzufügen, wenn eine höhere Spezifität erforderlich ist.“ Beispielsweise unterscheidet sich die in Kanada gesprochene französische Sprache (fr-ca) hinsichtlich Wortschatz und Rechtschreibung erheblich von der in Frankreich gesprochenen (fr-fr); und die traditionell in Hongkong gesprochene chinesische Sprache (zh-hant-hk) unterscheidet sich hinsichtlich der Namenskonventionen für Produkte, Werbekalender und Markenbekanntheit erheblich von der in Taiwan gesprochenen (zh-hant-tw).
Die Suchmaschinenübersetzung übersetzt die Länderkennung bis auf die von Ihrer Ranking-Logik unterstützte Detailebene und führt keine zusätzlichen Übersetzungen durch. Wenn Ihr Index auf der Ranking-Ebene nicht zwischen „en-us“ und „en-gb“ unterscheiden kann, hat die Speicherung des Regional-Subtags für Ihren Index keinen Nutzen. Verwendet Ihr Index jedoch unterschiedliche Synonymlisten, gewichtet er bei der Platzierung unterschiedlich oder wendet er unterschiedliche Verfügbarkeitsfilter für Nutzer in den Vereinigten Staaten im Vergleich zu Nutzern im Vereinigten Königreich an, dann wird das Regional-Subtag zu einem primären Routing-Signal.
Aufgrund der extremen Unterschiede hinsichtlich Wortschatz, Schriftzeichen und kultureller Bezugspunkte wurden in den W3C-BCP-47-Standards die beiden Tags „zh-hans“ (vereinfachtes Chinesisch) und „zh-hant“ (traditionelles Chinesisch) definiert, obwohl die Sprachen dasselbe Schriftsystem verwenden. Jede Sprache wird ganz anders verwendet als die andere, insbesondere hinsichtlich der Schreibweise und der Bedeutung der jeweiligen Wörter. Aus diesem Grund wurden in den W3C-BCP-47-Standards die beiden Tags (zh-hans, vereinfachtes Chinesisch, und zh-hant, traditionelles Chinesisch) definiert. Leider lässt sich dieser Unterschied nicht allein durch das Sprach-Subtag ausdrücken.
Bei Suchanfragen in traditionellem Chinesisch in Hongkong kann es zu „False Negatives“ kommen, da Zeichenvarianten nicht unterstützt werden; außerdem können „False Positives“ durch Wörter mit unterschiedlichen Bedeutungen entstehen sowie durch Beliebtheitssignale, die fälschlicherweise auf das falsche geografische Gebiet kalibriert sind, wenn Suchanfragen anhand eines Indexes durchgeführt werden, der für vereinfachtes Chinesisch erstellt wurde.
In einigen Teilen Aserbaidschans kann Aserbaidschanisch sowohl in arabischer als auch in lateinischer Schrift geschrieben werden. Bei der Entwicklung einer Indexierungsstrategie müssten diese Alternativen berücksichtigt werden; daher gibt es bei der Entwicklung einer Indexierungsstrategie verschiedene Möglichkeiten, die bei der Festlegung des richtigen Vorgehens zur Datenverarbeitung vor der eigentlichen Verarbeitung zu prüfen sind, anstatt Fehler erst nach der Verarbeitung der Suchanfrage zu korrigieren.
FastText’s Lid .176 – 176 Sprachen werden aus einem komprimierten Binärmodell extrahiert (Wikipedia, Tatoeba und SETimes), um die übergeordnete Sprache zu ermitteln und somit die Sprache in den BCP-47-Tags zu identifizieren, die in die Routing-Ebene der Algolia-Index-Engine gelangen, wenn die Sitzungslokalisierung der Suchmaschine nicht zur Verfügung steht. Dabei wird der Rohtext der Suchanfrage verwendet, und die Extraktion von Sprache und Lokalisierung aus der NLP-Ebene sowie deren Weiterleitung in die Such- und Abrufebene ist sowohl ein operativer Bestandteil der Infrastruktur als auch dient nicht als Metadaten für die Anzeige.
Algolia-Fit: Sprachgrenzen
Algolia betrachtet die Sprachumgebung als ein Schlüsselelement seines „Locale View Model“ und betrachtet sie daher nicht als sekundäre Metadaten, die zusätzlich zu einem Suchmodell auf Basis künstlicher Intelligenz hinzukommen.
Algolia betrachtet das BCP-47-Tag als primäres Routing-Signal für die Weiterleitung der Abfrage über eine Regel im Parameter „Contexts“. Dies ermöglicht lokalspezifische Einstellungen wie die Erweiterung von Synonymen, die Gewichtung im Rahmen der Ranking-Logik sowie die Geschäftslogik zur Segmentierung von Marketingkampagnen auf Basis der lokalen Gegebenheiten und kultureller Werberegeln für verschiedene Märkte.
Die sprachbezogene Tokenisierung in Algolia erfolgt über die Konfiguration auf Indexebene (d. h. nicht durch die Zuweisung von Analysatoren zu einzelnen Feldern), sodass die morphologische Korrektheit ein Konstruktionsmerkmal des Indexes ist und nicht erst zur Laufzeit im Anwendungscode festgelegt wird.
Algolia ermöglicht die Integration der fünf Elemente, von denen die mehrsprachige Relevanz abhängt – nämlich: die Sprache (morphologische Tokenisierung) der Suchbegriffe, die Ländereinstellung (um die Suchanfrage an die richtige Konfiguration für den Marktplatz weiterzuleiten), die Nutzerabsicht (die Ranking-Logik kann auf der Grundlage der Semantik der Suchanfrage konfiguriert werden), kulturelle Erwartungen (Werberegeln können auf der Grundlage regionaler Kalender und Markensignale konfiguriert werden) sowie marktspezifische Beliebtheit (Klick- und Konversionssignale werden nach Ländereinstellung segmentiert und nicht über alle Ländereinstellungen hinweg aggregiert).
Technische Umsetzung: Schema für das Relevanzparitätssignal
Die folgende Konfiguration veranschaulicht, wie sprachbezogene Einstellungen über die Indexkonfiguration (indexLanguages, queryLanguages) und BCP 47-gebundene Abfrageregeln für die lokalisierungsbezogene Synonymausweitung auf mehrsprachige Felder angewendet werden können. Die Konfiguration der Abfrageregeln veranschaulicht, wie eine für britisches Englisch geeignete Synonymausweitung auf den en-GB-Lokalisierungskontext beschränkt wird, ohne andere Märkte zu beeinträchtigen.
/**
* Language-Aware Index Field Configuration
* Demonstrates language-aware processing configured at the index level. .
* Ensures correct tokenization, stemming, and normalization per language.
* Aligned with Lucene language analyzer architecture and Microsoft Azure AI Search
* blended-index pattern for multilingual field design.
*/
const multilingualIndexSettings = {
searchableAttributes: [
"title_en",
"title_fr",
"title_ja",
"title_de",
"description_en",
"description_fr",
"description_ja",
"description_de",
"category_tags" // Language-agnostic taxonomy, no language analyzer required
],
// Index-level language configuration
// Each language field processes queries through morphologically correct rules
indexLanguages: ["en", "fr", "ja", "de"],
queryLanguages: ["en", "fr", "ja", "de"],
customRanking: [
"desc(promotional_priority)",
"desc(availability_score)",
"desc(margin_weight)"
],
// Ignore plurals and apply language-aware stemming per field
ignorePlurals: ["en", "fr", "de"], // Japanese morphology handled by segmentation
// Remove stop words per language
removeStopWords: ["en", "fr", "de"], // CJK languages do not use stop-word lists
// Disable typo tolerance for CJK: character substitution carries semantic weight
typoTolerance: true,
disableTypoToleranceOnAttributes: ["title_ja"]
};
/**
* BCP 47-Scoped Query Rule: locale-aware synonym expansion
* Applies British English synonym mapping only when query context is en-GB.
* Does not affect en-US, fr-FR, or any other locale context.
* Configured via Algolia Query Rules API.
*/
const enGBSynonymRule = {
objectID: "synonym-rule-en-gb-footwear",
conditions: [ {
context: "en-GB" // BCP 47 region subtag as Query Rule scope
}
],
consequence: {
filterPromotes: [
{
objectID: "category_footwear_uk",
position: 0
}
]
}
};
/**
* Language detection integration: fastText lid.176
* Resolves BCP 47 tag from raw query text when session locale is unavailable.
* Maps ISO 639 language code to BCP 47 tag for Query Rule context injection.
*/
async function resolveLocale(queryText, sessionLocale) {
if (sessionLocale) return sessionLocale;
// fastText lid.176 returns ISO 639 codes (e.g., "fr", "ja", "de")
// Map to BCP 47 region-qualified tag for market-level routing
const detectedLang = await fastTextModel.identify(queryText);
const langToLocaleMap = {
"en": "en-US",
"fr": "fr-FR",
"ja": "ja-JP",
"de": "de-DE",
"zh": "zh-Hans" // Defaults to Simplified; override with script detection if required
};
return langToLocaleMap[detectedLang] || "en-US"; }
4. Indexierungskonzept: Code-First-Architektur
Die Gestaltung des Indexes ist die architektonische Entscheidung, die alles, was danach folgt, bestimmt.
- Modell 1: Segmentierte Indizes – Jeder Markt verfügt über einen eigenen Index. Jeder Index kann unabhängig konfiguriert werden (z. B. Analyzer-Einstellungen, Synonymlisten, Ranking-Regeln, Merchandising-Logik). Bei der Abfrageverarbeitung kommt es zu keinen sprachübergreifenden Überschneidungen. Der größte Vorteil der segmentierten Indizierung ist die Präzision: Es gibt keine sprachübergreifenden Überschneidungen bei der Tokenisierung, keine Kollisionen von Synonymen zwischen den Märkten und keine Anpassung von Gewichtungen, die zur Rangfolge von Produkten in einem Markt kalibriert wurden und die Rangfolge dieser Produkte in einem anderen Markt beeinflussen würden. Die Kosten für die Replikation variieren je nach Anzahl der Segmente. Da für jede Sprache mehrere Indizes erstellt werden, müssen zudem alle Änderungen am Relevanzmodell auf jeden anderen Index angewendet werden, der für jede andere Sprache erstellt wurde. Während dies bei vier Sprachen noch zu bewältigen wäre, kommt es bei vierzehn Sprachen wahrscheinlich zu einer Konfigurationsabweichung, die zu einem Verlust der Relevanzparität führt – dem eigentlichen Ziel des segmentierten Indizierungsmodells. Die richtige Wahl, wenn Ihre Märkte unterschiedliche Ranking-Logiken erfordern (unterschiedliche Produktkataloge, unterschiedliche Preisstrukturen, unterschiedliche regulatorische Anforderungen).
- Muster 2: Gemischte Indizes – Ein Index, dessen Felder jedoch sprachspezifisch sind. Produktdatensätze enthalten Felder wie „title_en“, „title_fr“, „title_ja“ und „title_de“ als separate Suchfelder und nutzen eine auf Indexebene konfigurierte sprachbezogene Verarbeitung. Wenn eine Anwendung nach etwas sucht, ruft die Routing-Ebene das Länderkennzeichen des Benutzers aus BCP 47 ab und sendet die Suchanfrage anschließend an das bzw. die Felder für diese Ländereinstellung. Wie von Microsoft Azure AI Search beschrieben: „Verwenden Sie den Parameter ‚searchFields‘, um die Suchanfrage an das Feld zu senden, das Zeichenfolgen in der richtigen Sprache enthält, und den Parameter ‚select‘, um nur Ergebnisse aus den länderspezifischen Feldern zurückzugeben und Felder in anderen Sprachen auszuschließen.“ Die betriebliche Effizienz der gemischten Indizierung ist hoch, da Sie nur einen Index, eine Relevanzkonfiguration und eine Telemetrieoberfläche benötigen. Die richtige Wahl, wenn die sprachübergreifende Suche ein Merkmal Ihrer Produkte ist oder wenn betriebliche Effizienz über viele Märkte hinweg Priorität hat.“
Zusätzlich zu einem Katalog mit fünf Sprachen verfügt jede Sprache über zehn durchsuchbare Attribute. Bevor also sprachunabhängige Attribute (Preis, Verfügbarkeit, Kategorietaxonomien) zum Katalog hinzugefügt werden, gibt es bereits fünfzig durchsuchbare Felder im Katalog. Bei diesem Komplexitätsgrad ist das Schema schwer zu analysieren, und die Routing-Logik für jedes Feld lässt sich bei der Suche im Rahmen einer Abfrage nur äußerst schwer aufrechterhalten. Wenn Sie beispielsweise eine japanischsprachige Abfrage eingeben würden, würden alle fünfzig Felder durchsucht, anstatt nur die fünf japanischsprachigen Felder. Dieses Problem lässt sich mit einer Zuordnungstabelle von Sprachumgebung zu Feld lösen, die als Anwendungskonfiguration verwaltet wird. Die Zuordnungstabelle von Sprachumgebung zu Feld bietet eine zentrale Kontrollstelle für das Routing-Verhalten, ist über die gesamte Codebasis hinweg nachvollziehbar und erfordert keine Änderungen an der Logik der Abfrage.
Die beiden oben genannten Architekturvarianten hängen davon ab, ob sowohl die Dokumente als auch die Suchanfragen mehrsprachig sein müssen (gemischt) oder ob jeder Markt ein eigenständiges Produkterlebnis mit einer eigenen Katalogisierungsmethodik darstellen kann und keine sprachübergreifende Suche erforderlich ist (segmentiert). Der Vorgesetzte des Entwicklers begeht keinen Fehler bei der Entscheidung für eine der beiden Architekturen; er/sie begeht lediglich standardmäßig einen Fehler – d. h., er/sie wird sich zunächst für den segmentierten Ansatz entscheiden, da dieser weniger kompliziert erscheint als der gemischte Ansatz, und er/sie wird die Kosten für die Indizierung und die Replikation von Arbeitsabläufen über alle zehn Märkte hinweg nicht berücksichtigen, oder er/sie wird sich für den gemischten Ansatz entscheiden und keinen Plan haben, wie die Felder benannt, die Daten weitergeleitet werden sollen usw.
Die technische Leitung hat vier Anliegen hinsichtlich der technischen Führung: Indexkosten/-größe, Relevanzäquivalenz über Märkte hinweg, Komplexität der Abläufe und Markteinführungszeit für neue Sprachen. Diese Anliegen ergeben sich aus dem Indexdesign. Die Entwicklung einer Architektur aus segmentierten Indizes für zehn verschiedene Sprachmärkte würde zu zehn Indexkonfigurationen, zehn Synonym-Workflows, zehn Relevanzoptimierungszyklen und zehn Bereitstellungs-Pipelines führen. Ein einziger kombinierter Index kann genutzt werden, um jeweils eines der oben aufgeführten Elemente bereitzustellen. Je mehr Sprachmärkte Sie Ihrer Plattform hinzufügen, desto größer wird der betriebliche Vorteil. Die Zeit für die Bereitstellung eines neuen Sprachmarktes verkürzt sich von Monaten auf Tage. Unternehmen, deren Geschäft auf saisonalen Zyklen basiert (z. B. Golden Week, Singles’ Day), werden direkte positive Auswirkungen auf ihren Umsatz verzeichnen.
Algolia Fit: Indexierungsdesign
Die KI-Suche von Algolia unterstützt beide Architekturen, indem sie alle erforderlichen Konfigurationselemente bereitstellt, um beide Architekturen zu unterstützen. Die Konfigurationselemente (ignorePlurals, queryLanguages, indexLanguages, removeStopWords) können auf Segmentebene konfiguriert werden, sodass für jede in das Suchfeld eingegebene Suchanfrage eine korrekte morphologische Analyse durchgeführt wird. Darüber hinaus entsteht kein zusätzlicher Aufwand, da für jede Suchanfrage dieselben Konfigurationselemente bereitgestellt werden.
Um die Erstellung einer lokalisierungsspezifischen Merchandising-Ebene in gemischten Bereitstellungen zu unterstützen, nutzt Algolia eine Sprachkonfiguration auf Indexebene sowie ein Suchfeld-Routing, das auf einem regelbasierten Kontext zum Zeitpunkt der Abfrage basiert.
Wenn Nutzer also einen Index von Algolia verwenden, erhalten sie eine marktspezifische Relevanzoberfläche, die aus einem einzigen Index abgeleitet wird. Dies führt dazu, dass es nur ein Modell für alle Märkte und somit nur ein Relevanzmodell gibt. Da es zudem keine unterschiedliche Ranking-Logik für jeden Markt gibt, gibt es weder einen Index pro Markt noch eine Ad-hoc-Weiterleitung von Übersetzungen an mehrere Indizes. Schließlich werden dadurch unvereinbare Relevanzwerte zwischen den Regionen vermieden.
Eine Plattform für globale Erfahrungen, die Konsistenz, Nachvollziehbarkeit und Leistung gewährleistet – nicht als Eigenschaften, die die Architektur aufrechtzuerhalten versucht, sondern als Eigenschaften, die sie hervorbringt.
Implementierungen von segmentierten Indizes und gemischten Indizes
In diesem Abschnitt werden Einzelheiten zur Implementierung dieser beiden Konfigurationen erläutert. Das erste Beispiel zeigt die Implementierung einer segmentierten Indexkonfiguration, die für einen einsprachigen Marktplatz verwendet werden kann. Alle Einstellungen in diesem Beispiel beziehen sich auf die französische Morphologie. Das zweite Beispiel zeigt eine Abfrage mit gemischtem Index, die mithilfe einer lokalisierungsbewussten Feldweiterleitung implementiert wurde und dem Muster von Microsoft Azure AI Search sowie der in Abschnitt 3 festgelegten BCP 47-Lokalisierungsauflösung folgt.
/**
* Segmented Index Configuration: French Market
* All settings tuned for French morphological rules.
* Maintains full locale specificity at the cost of per-index operational overhead.
* Recommended when French market requires distinct ranking logic,
* catalog structure, or merchandising rules from other language markets.
*/
const frenchMarketIndexSettings = {
// Language settings: French morphology throughout
indexLanguages: ["fr"],
queryLanguages: ["fr"],
ignorePlurals: ["fr"],
removeStopWords: ["fr"],
searchableAttributes: [
"title_fr",
"description_fr",
"category_tags",
"brand_name" // Brand names are language-agnostic
],
customRanking: [
"desc(promotional_priority)",
"desc(availability_fr)", // France-specific warehouse availability
"desc(margin_weight_eur)", // EUR-denominated margin signal
"desc(popularity_fr)" // French market popularity score
],
// French-specific synonym configuration
// Scoped entirely to this index: no cross-locale contamination
synonyms: [
{
objectID: "syn-fr-baggage",
type: "synonym",
synonyms: ["bagage cabine", "bagage à main", "valise cabine"]
},
{
objectID: "syn-fr-livraison",
type: "oneWaySynonym",
input: "livraison gratuite",
synonyms: ["expédition offerte", "frais de port offerts"]
}
],
typoTolerance: true,
minWordSizefor1Typo: 5,
minWordSizefor2Typos: 9
};
/**
* Blended Index Query Implementation
* Single index serves multiple language markets via locale-aware field routing.
* Implements Microsoft Azure AI Search searchFields routing pattern.
* BCP 47 locale tag drives field selection, ruleContexts, and filter injection.
* Recommended when cross-lingual discovery is a product requirement
* or when operational efficiency across many language markets is the priority.
*/
// Locale-to-field routing table: single point of control for field selection
// Extend this map to add new language markets without modifying query logic
const localeFieldConfig = {
"en-US": {
searchFields: ["title_en", "description_en", "category_tags"],
selectFields: ["title_en", "description_en", "price_usd", "availability"],
popularityAttr: "popularity_en_us"
},
"fr-FR": {
searchFields: ["title_fr", "description_fr", "category_tags"],
selectFields: ["title_fr", "description_fr", "price_eur", "availability"],
popularityAttr: "popularity_fr_fr"
},
"ja-JP": {
searchFields: ["title_ja", "description_ja", "category_tags"],
selectFields: ["title_ja", "description_ja", "price_jpy", "availability"],
popularityAttr: "popularity_ja_jp"
},
"de-DE": {
searchFields: ["title_de", "description_de", "category_tags"],
selectFields: ["title_de", "description_de", "price_eur", "availability"],
popularityAttr: "popularity_de_de"
}
};
async function searchBlendedIndex(query, userLocale) {
const config = localeFieldConfig[userLocale] || localeFieldConfig["en-US"];
return await index.search(query, {
// Route query to locale-appropriate language fields only
restrictSearchableAttributes: config.searchFields,
// Return only locale-appropriate fields in response payload
attributesToRetrieve: config.selectFields,
// Inject locale-specific popularity as optional ranking signal
// Popularity ranking applied via customRanking in index settings (locale-agnostic),
// Activate locale-scoped Query Rules: synonyms, boosts, filters
// French rules inactive for ja-JP context; Japanese rules inactive for fr-FR
ruleContexts: [userLocale],
// Pass locale to analytics for per-market relevance measurement
analyticsTags: [`locale:${userLocale}`],
analytics: true,
clickAnalytics: true
});
}
Analytics-Tags werden in BlendedQueries verwendet, um die Relevanzparität zu quantifizieren, anstatt sich auf die Annahme der Relevanzparität zu verlassen, indem die aufgelöste Ländereinstellung jeder Abfrage als Tag an die Analytics-Ebene übermittelt wird. Durch die Erfassung von Klickraten, Konversionsraten und „Keine-Ergebnisse“-Raten pro Markt lassen sich diese Kennzahlen marktübergreifend direkt miteinander vergleichen. Wenn im obigen Beispiel die „No-Result“-Rate für ja-JP um 300 % höher ist als die für en-US, würde dies in den Telemetriedaten sofort erkennbar sein und könnte auf der Ebene der Indexkonfiguration behoben werden (z. B. fehlende Synonyme oder fehlerhafte Feldzuordnung). Zudem ließe sich feststellen, dass das aktuelle Suchmuster spezifisch für Japan ist und die aktuelle Tokenisierungskonfiguration diesen Suchtyp nicht ordnungsgemäß verarbeitet. Die Relevanzparität ist eine fortlaufende Kennzahl, die ständig gemessen werden muss; man kann sich nicht allein auf eine gute Anfangskonfiguration verlassen.
5. Der TCO-Vorteil: Interaktive Latenz als technische Einschränkung
Die Geschwindigkeit ist eine variable Einschränkung mit finanziellen Auswirkungen: Eine Verkürzung der Suchzeit des Nutzers um 0,1 Sekunden führt zu 10 Prozent höheren Kosten. Daher sind Entscheidungen, die den Suchpfad verzögern, wirtschaftlich motiviert und nicht von den Präferenzen der Entwickler bestimmt. Die Geschwindigkeitsvorgabe ist bei mehrsprachigen Suchen im Vergleich zu einsprachigen Suchen deutlich strenger, da ein naiver mehrsprachiger Suchprozess mehrere Verzögerungen im Suchprozess verursacht: (a) Vor der Verarbeitung der Suchanfrage erfolgt ein Aufruf zur Spracherkennung; (b) es findet eine eingebettete Generierung von Semantik für die Ergebnisausgabe statt; (c) wenn das Dokument in einer Sprache verfasst wurde und die Suchanfrage in einer anderen Sprache erfolgt, ist möglicherweise ein Übersetzungsschritt erforderlich; und (d) es findet eine Ranglistenberechnung statt, die zusätzlich zur grundlegenden Relevanzberechnung lokalspezifische Geschäftsregeln berücksichtigt. All dies kann zusammen zu einem Sucherlebnis führen, das als „langsam“ (im Gegensatz zu einem „interaktiven“) empfunden wird, und die entgangenen Einnahmen lassen sich nicht einfach dadurch ausgleichen, dass die richtige Sprache zurückgegeben wurde.
Teams, die sich mit der Entscheidung zwischen „Erstellen“ und „Zentralisieren“ befassen, berücksichtigen zwar alle technischen Aufwendungen, die direkt mit der Erstellung eines zentralen Indexes im Vergleich zur Erstellung mehrerer Indizes verbunden sind, versäumen es jedoch, die laufenden Betriebskosten für deren Verwaltung angemessen zu berücksichtigen und zu beziffern. Eine selbstverwaltete mehrsprachige Architektur für den Einsatz in acht verschiedenen Sprachmärkten bedeutet, dass acht verschiedene Indexkonfigurationen synchronisiert, acht Synonymlisten erstellt und gepflegt sowie acht verschiedene Regelsätze angepasst werden müssten, während sich Katalogdaten und Marktbedingungen ständig weiterentwickeln; außerdem müssten acht separate Bereitstellungsprozesse überwacht werden, da jede Änderung am zentralisierten Relevanzmodell zunächst in jeder der acht Sprachen getestet werden müsste, bevor sie in die Produktion übernommen wird. In diesem Fall schloss das ursprüngliche Team, das die Anwendung entwickelt hatte, das Projekt zwar innerhalb von sechs Monaten ab, verbrachte jedoch die folgenden vierundzwanzig Monate mit der Wartung der Anwendung; darüber hinaus steigen die für die Wartung aufgewendeten Kosten mit jedem neuen Sprachmarkt, der dem Unternehmen hinzukommt, um einen zusätzlichen Betrag. Der Anstieg der Wartungskosten kann durch die „Index-Ausbreitung“ noch weiter verschärft werden – wenn ein Produktkatalog mit zehn Millionen Produkten über acht Indizes für verschiedene Sprachen dupliziert wird, benötigt er das Achtfache des Speicherplatzes, den derselbe Katalog in Form eines einzigen kombinierten Indexes beanspruchen würde; selbst wenn der kombinierte Index jedoch angemessen konfiguriert ist, ergibt sich kein Leistungsgewinn hinsichtlich der Fähigkeit, Daten aus dem Index abzurufen.
Was den Entwicklungsprozess betrifft, so erhöht der Einsatz einer internen Übersetzungs-Engine als Teil einer maßgeschneiderten Lösung die Kosten für den Besitz und den Betrieb der Engine. Sowohl die Sprachidentifizierung als auch sprachübergreifende Embeddings lassen sich durch den Einsatz kostengünstiger und wartungsarmer NLP-Ressourcen realisieren. „lid.176“ von fastText ist ein sehr kleines Modell, das komprimiert nur 917 kB benötigt, um 176 Sprachen zu identifizieren. Mehrsprachige Modelle wie „Sentence-Transformers“ liefern sprachübergreifende Embeddings und erfordern keine maßgeschneiderte Lösung zu deren Erzeugung. Keines der beiden Modelle benötigt eine maßgeschneiderte Übersetzungspipeline.
Eine verwaltete Relevanzplattform, die native Unterstützung für sprachbezogene Tokenisierung bietet, macht eine Übersetzungspipeline sowohl für die Tokenisierungs- als auch für die Morphologieebene überflüssig. Dadurch reduziert sich die Anzahl der NLP-Abhängigkeiten, die für die Bereitstellung einer mehrsprachigen Suchfunktion erforderlich sind, auf lediglich zwei. Die Zeitspanne zwischen der geschäftlichen Entscheidung, eine Suchfunktion in einem neuen Sprachmarkt anzubieten, und der Verfügbarkeit einer Suchfunktion in Produktionsqualität für Kunden in diesem Markt bedeutet einen direkten Verlust an potenziellen Einnahmen.
Bei einer selbstverwalteten, segmentierten Architektur umfasst dieses Intervall alle Schritte, die erforderlich sind, um die notwendige Hardware bereitzustellen, Indexkonfigurationen in der gesamten Umgebung zu replizieren, Synonymlisten neu zu erstellen, Ranking-Regeln neu abzustimmen und einen vollständigen Testzyklus für die neue Ländereinstellung durchzuführen, bevor diese in die Produktion übernommen wird. Bei einem verwalteten gemischten Index beschränkt sich das Intervall lediglich auf die Konfiguration des Systems: Erweiterung der Feldzuordnung, Auswahl des Analysators und Konfiguration der länderspezifischen Abfrageregeln. Für Unternehmen, die in saisonalen Märkten tätig sind (Golden Week, Singles’ Day usw.), misst sich der Unterschied zwischen der Einführung eines neuen Sprachmarktes innerhalb von Tagen oder Monaten nicht daran, wie lange es dauert, bis Ingenieure das Produkt bereitstellen, sondern daran, ob man in der Lage ist, die Umsatzchancen zu nutzen, die sich während dieser saisonalen Zeitfenster bieten.
Algolia bedient derzeit über 17.000 Unternehmen in mehr als 150 Ländern, die wöchentlich über 30 Milliarden Suchanfragen durchführen – das entspricht 1,75 Billionen Suchanfragen pro Jahr. Dieses enorme Suchvolumen liefert die Daten, die zur Ermittlung der Leistungskennzahlen für die Dienste von Algolia benötigt werden. Wie bereits erwähnt, hat Algolia zwei Abrufmethoden entwickelt (sprachspezifisch und hybrid), die parallel laufen und die Latenz für den Endnutzer nicht beeinträchtigen. Zudem werden alle Dienste, einschließlich der sprachbezogenen Tokenisierung, des lokalisierungsbasierten Rankings und der hybriden Suche, innerhalb genau desselben Zeitrahmens ausgeführt wie eine standardmäßige sprachspezifische Suche. Daher ist die Entscheidung hinsichtlich der technischen Aspekte, ob eine mehrsprachige Suche mit interaktiver Latenz möglich ist, bereits getroffen – sie ist bereits Realität. Nun müssen Sie nur noch entscheiden, wie Sie dieses Ziel erreichen möchten: entweder durch den Aufbau und die Wartung der erforderlichen Infrastruktur oder durch deren Konfiguration.
6. Strategische Relevanz der Unternehmensführung: die institutionelle Steuerungsebene
Um festzustellen, ob im Hinblick auf institutionelle Kontrollebenen ein Problem der strategischen Relevanz in der Unternehmensführung vorliegt: Das „Relevanzproblem“ (das Auffinden von Produkten auf einem mehrsprachigen Marktplatz) wandelt sich in ein „Problem der Aufrechterhaltung der Relevanz“ (die Gewährleistung, dass Produkte für Verbraucher über einen längeren Zeitraum hinweg relevant bleiben), sobald ein Produkt bzw. Produkte erfolgreich auf einem mehrsprachigen Marktplatz (in diesem Fall in zwölf Sprachen) eingeführt wurde(n). Ein „Problem der Aufrechterhaltung der Relevanz“ ist definiert als ein kontinuierlicher Zyklus, in dem versucht wird, sicherzustellen, dass Verbraucher die Produkte finden, die sie kaufen möchten, während der Marktplatz an Größe und Komplexität zunimmt und sich weiterentwickelt. Mit anderen Worten: Ein Problem der Relevanzaufrechterhaltung tritt jedes Mal auf, wenn beispielsweise in der englischen Sprachversion eines Marktplatzes eine Änderung am Produktnamen vorgenommen wird; dabei ist es sehr wahrscheinlich, dass die Produktnamen in allen anderen Sprachen nicht gleichzeitig aktualisiert werden. Wenn für einen Feiertag wie den Black Friday in den Vereinigten Staaten ein Gewicht für Werbeaktivitäten hinzugefügt wird, ist es sehr wahrscheinlich, dass diese Gewichte auch auf die übrigen acht Standorte angewendet werden, die dieselben Werbewichte verwenden.
Darüber hinaus ist nicht garantiert, dass eine Funktion, die zur Verbesserung der Qualität der Suchergebnisse in einem Marktplatz hinzugefügt wird, auch im Schema eines anderen Marktplatzes vorhanden ist. Tritt also während einer Anpassung ein „stiller Fehler“ auf, kann dies dazu führen, dass das neue Attribut bei der Berechnung des Rankings entweder vollständig ignoriert wird oder dass der Endnutzer darauf hingewiesen wird, dass im Marktplatz ein Fehler aufgetreten ist. Obwohl die kumulativen Auswirkungen jeder einzelnen „Abweichung“ gering sind, führt die Gesamtzahl der Konfigurationsänderungen an einem Marktplatz im Laufe von zwölf Monaten, in denen Produkte in mehreren Sprachen veröffentlicht werden, zu einer Marktplatzumgebung, in der die Relevanzqualität von Marktplatz Fünf und Marktplatz Neun deutlich geringer ist als die von Marktplatz Eins – und zwar ausschließlich aufgrund der erfolgreichen Übertragung von Konfigurationsänderungen vom ersteren zum letzteren sowie des Versäumnisses des letzteren, die übertragenen Konfigurationsänderungen zu erkennen und zu übernehmen.
Das Governance-Rahmenwerk umfasst drei Komponenten, die drei verschiedene Arten von Ausfällen abdecken:
- Indexvertrag – Der Indexvertrag beschreibt, pflegt und hält die für jeden Index und jede Sprache erforderlichen Schemata, Analysatoren und Rangattribute formal fest. Das bedeutet, dass es einen einzigen Ort gibt, an dem Sie stets die richtige Konfiguration für einen mehrsprachigen Index finden können. Sollte daher ein Konfigurationsproblem vorliegen, wird es bereits zum Zeitpunkt der Bereitstellung als solches erkannt und nicht erst Wochen später als Relevanzverlust oder unbekanntes Ereignis.
- Steuerung der Abfrageweiterleitung – Die Steuerung der Abfrageweiterleitung legt fest, wie BCP 47-Lokalisierungssignale von der Sitzung eines Benutzers an eine Suchabfrage weitergeleitet werden und welche Felder und/oder Abfrageregeln auf das Lokalisierungssignal angewendet werden. Durch die Verwendung des Lokalisierungs-Tags lassen sich die für dieses Tag geltenden Regeln und Rangsignale identifizieren, ohne dass der Anwendungscode analysiert werden muss.
- Parität bei der Relevanzmessung – Parität bei der Relevanzmessung ist die Zusage, die Relevanz in allen Sprachmärkten auf dieselbe Weise (Klickraten, Konversionen, keine Ergebnisse) und unter Verwendung desselben Überprüfungszyklus zu messen. Wird keine Parität bei der Relevanzmessung hergestellt, nimmt die Relevanz in Märkten mit geringerer Sichtbarkeit ab und wird nicht erfasst. Eine höhere „Keine Ergebnisse“-Rate für die japanische Sprache über einen Zeitraum von drei Monaten ist kein sprachbezogenes Problem, sondern ein Problem der Unternehmensführung.
{
"conditions": [{
"context": "ja-JP"
}],
"consequence": {
"params": {
"optionalFilters": ["market_popularity.ja_JP:>100"],
"ruleContexts": ["ja-JP"]
},
"promote": [{
"objectID": "seasonal_jp_featured",
"position": 0
}]
}
}
Beginnend mit der ersten Phase dieses Prozesses (der unausgesprochenen/impliziten Phase) erfordert die unausgesprochene/implizite Phase in der Regel keine konkreten Maßnahmen und ist typischerweise unausgesprochen oder implizit. Aufgrund der Natur unserer typischen Entwicklungsprozesse existiert zwar eine Konfiguration, diese wurde jedoch nie formell dokumentiert oder validiert, und ihre Relevanz wird ausschließlich auf dem Hauptsprachenmarkt gemessen.
Die nächste Phase (Managed) wird sich in mehrfacher Hinsicht von der ersten Phase dieses Prozesses unterscheiden. Es wird eine Versionskontrolle für die Verträge geben, für jede bereitgestellte Konfiguration wird eine automatisierte Validierung der Verträge stattfinden, und die Kennzahlen pro Sprachversion werden so ausgewertet, dass einzelne Mitarbeiter diese nachverfolgen können.
Die letzte Phase („Optimiert“) findet statt, wenn der Zyklus abgeschlossen ist und die Klick- und Konversionsdaten aus allen Märkten dazu verwendet werden, die Synonyme neu zu ordnen und zu erweitern – und zwar unter Anwendung derselben Überprüfungsprozesse wie bei allen anderen Konfigurationsänderungen. Es handelt sich dabei NICHT um einen separaten Prozess für mehrsprachige Konfigurationen, sondern lediglich um den Prozess selbst.
Ob dieser Zustand erreicht wird, hängt weitgehend davon ab, ob innerhalb der Ingenieurorganisationen institutionelle Normen geschaffen werden. Die dafür erforderlichen technischen Grundlagen sind bereits vorhanden.
In der Regel sind es die institutionellen Normen, die die Bedeutung der Mehrsprachigkeit als ein allen Teams gemeinsames technisches Anliegen anerkennen – und nicht die Tatsache, dass jedes Lokalisierungsteam dies individuell als sein eigenes technisches Anliegen betrachtet, das es noch zu lösen gilt.
Ohne eine einheitliche Konfigurationsoberfläche können sich diese Normen nicht durchsetzen. Die Implementierung der einzelnen Sprachen wird von unterschiedlichen Teams zu unterschiedlichen Zeitpunkten und ohne ein einheitliches Schema verwaltet; daher werden sie niemals zusammenlaufen. Governance ist in dieser Hinsicht kein konzeptionelles Problem; der Grund liegt vielmehr im Fehlen einer zentralen Stelle, die eine solche Konvergenz durchsetzen könnte.
Algolia-Fit: Steuerung der strategischen Relevanz
Der wohl beste Aspekt des Designs von Algolia ist der Ort, an dem all dies untergebracht ist. Die Indexeinstellungen befinden sich in der API, was bedeutet, dass sie jederzeit überprüft werden können. Abfrage-Regeln werden nach genau 6 Monaten deterministisch ausgelöst, genau wie beim Start; die Regel „ja-JP“ wird für „ja-JP“ ausgelöst, Punkt. Es ist keine manuelle Überprüfung erforderlich, um festzustellen, ob sie ausgelöst wurde oder nicht. Die Analyseebene fügt jeder Abfrage ein Tag mit der entsprechenden Ländereinstellung hinzu, sodass Sie die Relevanzparität zwischen den Ländereinstellungen messen können, anstatt einfach davon auszugehen, dass sie besteht. Dies ist eine Plattform für globale Nutzererlebnisse, die Konsistenz, Nachvollziehbarkeit und Leistung gewährleistet.
7. Fazit: Die globale Suche ist ein Relevanzproblem
Die proprietäre NeuralSearch-Technologie von Algolia vereint sowohl vektorbasierte Verarbeitung natürlicher Sprache als auch den Abgleich von Schlüsselwörtern in einer einzigen API. Sie ersetzt weder Übersetzungs- noch Sprachmodelle – sie nutzt lediglich deren Ergebnisse und wandelt diese in etwas um, das für Nutzer unabhängig von ihrem Standort nutzbar ist. Algolia übernimmt die Rangfolge und den Abruf der Ergebnisse auf der Grundlage konfigurierter Signale, doch die Absicht hinter der Suche eines Nutzers wird weiterhin von der NLP-Ebene ermittelt. Algolia gewährleistet Konsistenz, Erklärbarkeit und Leistung. Die globale Suche ist ein Relevanzproblem. Die sprachliche Ebene ist bereits gelöst. In der Abrufebene wird die eigentliche Arbeit geleistet und werden die Ergebnisse ermittelt.
Fordern Sie unteralgolia.com/demorequesteine Demo der KI-Suchlösung von Algolia an oder erfahren Sie mehr unteralgolia.com/blog/ai/
.webp)
.jpg)
%20(2).svg)
