Open-Source Spryker-Suchtools
Transparente und feineinstellbare Suchrelevanz für Spryker.
Produkt-Rankings in Spryker debuggen und gezielt optimieren — mit nachvollziehbarem Scoring für Elasticsearch und OpenSearch.
finalScore =
Normalisierte Textrelevanz + normalisierte Business-Signale.
Die Query Specificity verschiebt anschließend α →
d = 2 · specificitypspecificityp + kspecp − 1
specificity = β · max(log(KataloggrößeDokumente mit Term)) + (1 − β) · harmonicMean(log(KataloggrößeDokumente mit Term))
1 / 5
Relevanz-Datensatz
Basis jeder Optimierung ist eine repräsentative Stichprobe aus Suchanfragen und manuell bewerteten Suchergebnissen.
Jeder Query werden Produkte sowie deren Soll-Relevanz zugewiesen. Die Qualität der optimierten Formel steht und fällt mit der Güte und Größe dieses Datensatzes — er sollte typische Suchmuster, Spezialfälle und geschäftskritische Anfragen gleichermaßen abdecken.
Der Datensatz ist vom Optimierungsalgorithmus entkoppelt und kann sich bei Katalog- und Sortimentsänderungen kontinuierlich weiterentwickeln.
2 / 5
Rank Evaluation
Rank Eval führt sämtliche Queries des Datensatzes mit der aktuellen Formel aus und gleicht die Trefferreihenfolge mit den Soll-Bewertungen ab.
Die Rank-Eval-Schnittstelle von Elasticsearch bzw. OpenSearch wertet den Relevanz-Datensatz unter der gewählten Scoring-Formel aus. Kennzahlen wie nDCG quantifizieren präzise, wie gut die aktuelle Parameterkonfiguration über alle Testanfragen hinweg abschneidet.
Rank Eval liefert den objektiven Fitness-Wert, auf dessen Basis der Optimizer Parameter anpasst.
3 / 5
CMA-ES-Optimizer
Die Covariance Matrix Adaptation Evolution Strategy ermittelt optimale Parameterkombinationen ganz ohne Ableitungen oder manuelles Nachjustieren.
Pro Generation bewertet der Algorithmus mehrere Parameterkandidaten via Rank Eval. Erfiolgreiche Kandidaten fließen in die nächste Generation ein; dabei verengt und neugewichtet sich der Suchraum schrittweise bis zur Konvergenz im Optimum.
Im Gegensatz zu manuellem Ausprobieren durchsucht CMA-ES den vollständigen Parameterraum systematisch und automatisch.
4 / 5
Optimale Parameter
Nach Abschluss des Optimierungslaufs kann der performanteste Parametersatz als neue Runtime-Konfiguration übernommen werden.
Zu den optimierten Werten gehören unter anderem der Spezifitätsexponent, die Textgewichtung, die Gewichte der Business-Signale sowie die maximale Spezifitätsverschiebung — exakt die Parameter aus der dargestellten Formel.
Die Optimierung erfolgt vollständig offline. Anfragen zur Laufzeit nutzen lediglich den berechneten Parametersatz und bleiben deterministisch sowie performant.
5 / 5
Adaptive Formel
Die optimierten Parameter werden von der Suchmaschine geladen und deterministisch auf jede Suchanfrage angewendet — ohne Optimizer-Overhead zur Laufzeit.
Die Query Specificity gewichtet dynamisch zwischen textueller Relevanz und Business-Signalen, während die Scoring-Logik vollständig nachvollziehbar bleibt. Ändern sich Katalogdaten oder Business-Ziele, erzeugt ein erneuter Optimierungslauf einfach einen aktualisierten Parametersatz.
Runtime-Ranking und Offline-Optimierung sind strikt getrennt: Suchanfragen führen niemals den Optimizer aus.
1 / 5
Query-Terme analysieren
Jeder gematchte Begriff wird über die Term-Statistiken des Index ausgewertet — gemessen an den Dokumenten mit Treffern im Verhältnis zur Gesamtmenge.
Ein Begriff, der in fast jedem Produkt auftaucht (chair), besitzt kaum Aussagekraft über die Kundenabsicht. Ein sehr seltener Begriff (gsr) deutet hingegen stark auf ein gezieltes Suchinteresse hin. Begriffe ohne echte Katalogtreffer werden übersprungen und nicht fälschlicherweise als maximal selten gewertet.
idfterm = log(Kataloggröße / Dokumente mit Term)
2 / 5
Raw Specificity berechnen
Die Term-Scores einer Suchanfrage werden zu einem Gesamtwert kombiniert — mit starker Gewichtung zugunsten des aussagekräftigsten Terms.
Das harmonische Mittel der IDF-Werte fällt deutlich ab, sobald auch nur ein gewöhnlicher Begriff enthalten ist. Das Blend-Gewicht β sorgt jedoch dafür, dass ein einzelner, sehr seltener Term als starkes Signal dominieren kann. Einzelterm-Queries überspringen diesen Schritt — ihr eigener IDF-Wert entspricht direkt der Raw Specificity.
specificity = β · max(idf) + (1 − β) · harmonicMean(idf)
3 / 5
Normalisierung via Sättigungskurve
Die Raw Specificity wird über dieselbe Sättigungsfunktion gestaucht wie die Elasticsearch-Relevanz — x / (x + k) — angepasst über einen eigenen Sättigungspunkt.
Ein Kurvenexponent p steuert bei Bedarf die Steilheit des Übergangs am Sättigungspunkt. Bei p = 1 vereinfacht sich der Ausdruck zum gewöhnlichen Verhältnissortiment — analog zu Schritt 2 im Haupt-Explorer.
normalize(x) = xp / (xp + kspecp)
4 / 5
Gewichtung anpassen
Die normalisierte Specificity wird als vorzeichenbehaftete Abweichung vom Neutralpunkt skaliert und als Korrekturwert auf α angewendet.
d = 2 · normalize(specificity) − 1 zentriert typische Suchanfragen exakt bei null. Der Exponent γ steuert die Sensitivität im Zentrum (gedämpft bei γ > 1, verstärkt bei γ < 1), während m die maximale Verschiebung von α durch die Specificity nach oben und unten deckelt.
αeff = α + m · sign(d) · |d|γ
5 / 5
Parameter kalibrieren
kspec, β, p, γ und m basieren nicht auf Schätzungen, sondern werden wie der Rest der Formel systematisch kalibriert.
Die Sättigungspunkt-Kalibrierung von Search Ranking Optimizer bietet einen eigenen Specificity-Modus: Sie wertet echte Suchanfragen aus und leitet kspec direkt aus deren Verteilung ab. Die verbleibenden Shift-Parameter werden automatisiert vom Optimizer durchsucht (siehe Tab „Optimierung“ oben).
Derselbe Kalibrierungs- und Optimierungsablauf, angewendet auf die Spezifitätsparameter.
01 / 05
Berechnung des Gesamtscores
Jeder Treffer wird als konvexe Kombination aus normalisierter Textrelevanz und gewichteten Business-Signalen berechnet.
Das Modell besteht aus zwei Komponenten: α steuert das Gewicht der Textrelevanz; 1 − α weist den verbleibenden Anteil den Business-Signalen zu.
Da beide Seiten normalisiert vorliegen, bleiben die Einzelbeiträge direkt vergleichbar und der finale Score verständlich.
Berechnet durch Search Ranking · nachvollziehbar via Search Debug
02 / 05
Elasticsearch-Relevanz normalisieren
Der nach oben unbegrenzte _score von Elasticsearch wird in ein Intervall von 0 bis knapp unter 1 transformiert.
Diese Transformation wahrt die ursprüngliche Sortierreihenfolge und verhindert verlässlich, dass extrem hohe Text-Scores sämtliche Business-Signale überlagern.
Dafür kommt dieselbe Sättigungsfunktion zum Einsatz, mit der BM25 Termfrequenzen skaliert — hier angewendet auf den Gesamtdokument-Score.
score / (score + k)
03 / 05
Sättigungspunkt festlegen
Der Parameter k definiert den Schwellenwert, an dem die normalisierte Relevanz exakt 0,5 erreicht.
Gilt score = k, liefert der Relevanzterm genau 0,5. Kleinere Werte führen zu einer früheren Sättigung; größere Werte erhalten die Feinabstimmung bei hohen Elasticsearch-Scores aufrechterhalten.
Statt k manuell zu raten, ermittelt Search Ranking praxisnahe Richtwerte: Auf Basis eines Query-Sets aus CSV-Import oder Admin-Bewertung und einer definierten Auswertungs-Tiefe analysiert das Package die Top-Treffer und schlägt den gemessenen Mittelwert der _score-Werte als Startpunkt für k vor.
Test-Queries + Stichprobentiefe → Gemessene _score-Verteilung → Empfohlenes k
04 / 05
Normalisierte Business-Signale einbinden
Die zweite Komponente bündelt Kennzahlen wie Click-Through-Rate, Conversion-Rate, Lieferfähigkeit oder Marge.
Jede Metrik wird vor der Verrechnung auf Werte zwischen 0 und 1 skaliert, wodurch Kennzahlen unterschiedlicher Einheiten vergleichbar werden.
Search Ranking analysiert die Verteilungssymmetrie der Metrikdaten und schlägt eine passende Normalisierungsfunktion vor. Die integrierte Analyseansicht vergleicht die empirische Verteilung mit der mathematischen Kurve; der finale Ausdruck bleibt frei konfigurierbar.
Zusätzlich empfiehlt sich ein gering gewichtetes random()-Signal. Es löst Treffer-Gleichstände deterministisch auf und verhindert, dass Produkte dauerhaft auf identischen Plätzen feststecken.
Verteilungsanalyse → Empfehlung der Normalisierungsfunktion · gering gewichtetes random() zur Tie-Breaking-Steuerung
05 / 05
Einheitliche Signalgewichtung
Alle eingegebenen Signalgewichte werden automatisch so normiert, dass ihre Summe stets 1 ergibt.
In Zed können Administratoren relative Verhältnisse angeben, ohne manuell eine Gesamtsumme von 100 % ausrechnen zu müssen. Die Eingaben 30 und 10 werden automatisch zu 0,75 und 0,25 umgerechnet.
Diese Umrechnung erfolgt einmalig beim Publizieren der Konfiguration, damit Anfragen zur Laufzeit schlank bleiben.
wi = enteredWeighti / Σ enteredWeightj
Roadmap
Search Relevance v1 basiert auf dem Funktionsumfang von OpenSearch 1.3 — dem langjährigen Standard für Spryker-Projekte.
Mit der Unterstützung von OpenSearch 3.x in Spryker werden fortschrittliche Ranking-Verfahren anwendbar. Search Relevance v2 bringt dafür Unterstüzung für Reranking, Hybrid Retrieval, Learning-to-Rank und weitere Ansätze.
Ursprung
Das Projekt basiert auf Sprykers Data-driven ranking Best-Practice-Leitfaden. Dieser beschreibt ein bewährtes Praxissystem, das ursprünglich von Martin Loetsch und Krešimir Slugan für Contorion konzipiert und implementiert wurde. Spryker selbst liefert hierfür keinen Quellcode, lediglich obige Anleitung.
search-ranking und search-ranking-optimizer setzen dieses Konzept für die Spryker-Architektur um und erweitern es um Funktionen wie Store-/Locale-Scoping, spezifitätsbasierte Relevanzgewichtung und automatisierte Blackbox-Optimierung.