Alexander Dávila - Elasticsearch Labs

Training von LTR-Modellen in Elasticsearch mit Urteilslisten basierend auf Benutzerverhaltensdaten

Alexander Dávila — Wed, 15 Oct 2025 00:00:00 GMT

Eine große Herausforderung bei der Verwendung von Learning-to-Rank- Modellen besteht darin, eine qualitativ hochwertige Beurteilungsliste zu erstellen, mit der das Modell trainiert werden kann. Traditionell beinhaltet dieser Prozess eine manuelle Bewertung der Relevanz von Suchanfrage und Dokument, um jedem Dokument eine Note zuzuweisen. Dies ist ein langsamer Prozess, der sich nicht gut skalieren lässt und schwer zu pflegen ist (stellen Sie sich vor, Sie müssten eine Liste mit Hunderten von Einträgen manuell aktualisieren).

Was wäre, wenn wir die Interaktionen realer Nutzer mit unserer Suchanwendung nutzen könnten, um diese Trainingsdaten zu erstellen? Die Nutzung von UBI -Daten ermöglicht uns genau das. Entwicklung eines automatischen Systems, das unsere Suchanfragen, Klicks und sonstige Interaktionen erfassen und nutzen kann, um eine Bewertungsliste zu erstellen. Dieser Prozess lässt sich viel einfacher skalieren und wiederholen als eine manuelle Interaktion und führt tendenziell zu besseren Ergebnissen. In diesem Blogbeitrag werden wir untersuchen, wie wir in Elasticsearch gespeicherte UBI-Daten abfragen können, um aussagekräftige Signale zu berechnen und so einen Trainingsdatensatz für ein LTR- Modell zu generieren.

Das vollständige Experiment finden Sie hier.

Warum UBI-Daten für das Training Ihres LTR-Modells nützlich sein können

UBI-Daten bieten gegenüber einer manuellen Annotation mehrere Vorteile:

Volumen: Da die Daten zum bedingungslosen Grundeinkommen aus realen Interaktionen stammen, können wir viel mehr Daten sammeln, als wir manuell generieren könnten. Dies setzt natürlich voraus, dass wir über genügend Traffic verfügen, um diese Daten zu generieren.
Tatsächliche Nutzerabsicht: Traditionell basiert eine manuelle Beurteilungsliste auf der Auswertung der verfügbaren Daten durch Experten. Andererseits spiegeln UBI-Daten das tatsächliche Nutzerverhalten wider. Das bedeutet, dass wir bessere Trainingsdaten generieren können, die die Genauigkeit unseres Suchsystems verbessern, da sie darauf basieren, wie Benutzer tatsächlich mit Ihren Inhalten interagieren und einen Nutzen darin finden, anstatt auf theoretischen Annahmen darüber, was relevant sein sollte.
Kontinuierliche Aktualisierungen: Beurteilungslisten müssen von Zeit zu Zeit aktualisiert werden. Wenn wir sie aus UBI-Daten erstellen, erhalten wir aktuelle Daten, die zu aktualisierten Urteilslisten führen.
Kosteneffizienz: Da keine manuelle Erstellung einer Beurteilungsliste erforderlich ist, kann der Prozess beliebig oft effizient wiederholt werden.
Natürliche Abfrageverteilung: UBI-Daten repräsentieren reale Benutzerabfragen, die tiefgreifendere Veränderungen bewirken können. Nutzen unsere Nutzer beispielsweise natürliche Sprache, um in unserem System zu suchen? In diesem Fall sollten wir möglicherweise einen semantischen Suchansatz oder einen hybriden Suchansatz implementieren.

Es gibt allerdings auch einige Warnhinweise:

Verzerrungsverstärkung: Beliebte Inhalte erhalten mit größerer Wahrscheinlichkeit Klicks, einfach weil sie mehr Aufmerksamkeit erregen. Dies könnte dazu führen, dass beliebte Artikel verstärkt werden und bessere Alternativen möglicherweise in den Hintergrund treten.
Unvollständige Abdeckung: Neuen Inhalten fehlen jegliche Interaktionen, daher ist es schwierig für sie, in den Suchergebnissen weit oben zu erscheinen. Bei seltenen Anfragen können zudem nicht genügend Datenpunkte vorhanden sein, um aussagekräftige Trainingsdaten zu erzeugen.
Saisonale Schwankungen: Wenn Sie erwarten, dass sich das Nutzerverhalten im Laufe der Zeit drastisch ändert, geben historische Daten möglicherweise nicht viel Aufschluss darüber, was ein gutes Ergebnis ist.
Aufgabenunklarheit: Ein Klick garantiert nicht immer, dass der Nutzer gefunden hat, wonach er gesucht hat.

Notenberechnung

Noten für LTR-Schulung

Um LTR-Modelle zu trainieren, benötigen wir eine numerische Darstellung, die angibt, wie relevant ein Dokument für eine Suchanfrage ist. In unserer Implementierung handelt es sich bei dieser Zahl um einen kontinuierlichen Wert von 0,0 bis 5,0+, wobei höhere Werte eine höhere Relevanz anzeigen.

Um zu veranschaulichen, wie dieses Bewertungssystem funktioniert, betrachten Sie folgendes manuell erstellte Beispiel:

Abfrage

Dokumentinhalt

Grad

Erläuterung

"bestes Pizza-Rezept"

"Authentisches italienisches Pizzateigrezept mit Schritt-für-Schritt-Fotos"

4.0

Äußerst relevant, genau das, wonach der Nutzer sucht.

"bestes Pizza-Rezept"

„Geschichte der Pizza in Italien“

1.0

Es passt zwar thematisch, es geht um Pizza, ist aber kein Rezept.

"bestes Pizza-Rezept"

"Schnelles 15-Minuten-Pizza-Rezept für Anfänger"

3.0

Relevant, ein gutes Ergebnis, aber es verfehlt vielleicht das Ziel, das „beste“ Rezept zu sein.

"bestes Pizza-Rezept"

"Autowartungsleitfaden"

0,0

Überhaupt nicht relevant, steht in keinem Zusammenhang mit der Anfrage.

Wie wir hier sehen können, ist die Bewertung eine numerische Darstellung der Relevanz eines Dokuments für unsere Beispielanfrage nach dem „besten Pizza-Rezept“. Anhand dieser Werte kann unser LTR-Modell lernen, welche Dokumente in den Ergebnissen weiter oben angezeigt werden sollten.

Die Berechnung der Noten ist der Kern unseres Trainingsdatensatzes. Hierfür gibt es verschiedene Ansätze , jeder mit seinen eigenen Stärken und Schwächen. Wir könnten beispielsweise eine binäre Bewertung vergeben: 1 für relevant, 0 für nicht relevant. Oder wir könnten einfach die Anzahl der Klicks in einem Ergebnisdokument für jede Suchanfrage zählen.

In diesem Blogbeitrag werden wir einen anderen Ansatz verfolgen, indem wir das Nutzerverhalten als Eingabe betrachten und eine Note als Ausgabe berechnen. Wir werden auch Verzerrungen korrigieren, die dadurch entstehen könnten, dass höhere Ergebnisse tendenziell häufiger angeklickt werden, unabhängig von der Relevanz des Dokuments.

Notenberechnung – COEC-Algorithmus

Der COEC-Algorithmus (Clicks over Expected Clicks) ist eine Methode zur Berechnung von Beurteilungsnoten aus den Klicks der Nutzer. Wie bereits erwähnt, neigen Nutzer dazu, auf weiter oben positionierte Ergebnisse zu klicken, selbst wenn das Dokument nicht das relevanteste für die Suchanfrage ist; dies wird als Positionsbias bezeichnet. Die Grundidee des COEC-Algorithmus besteht darin, dass nicht alle Klicks gleich wichtig sind; ein Klick auf ein Dokument an Position 10 deutet darauf hin, dass das Dokument für die Suchanfrage viel relevanter ist als ein Klick auf ein Dokument an Position 1. Um die Forschungsarbeit zum COEC-Algorithmus (siehe Link oben) zu zitieren:

„Es ist bekannt, dass die Klickrate (CTR) von Suchergebnissen oder Anzeigen je nach Position der Ergebnisse deutlich abnimmt.“

Mehr zum Thema Positionsbias können Sie hier lesen.

Um dies mit dem COEC-Algorithmus zu lösen, gehen wir wie folgt vor:

1. Festlegung von Positionsbaselines: Wir berechnen die Klickrate (CTR) für jede Suchposition von 1 bis 10. Das bedeutet, wir ermitteln, welcher Prozentsatz der Nutzer typischerweise auf Position 1, Position 2 usw. klickt. Dieser Schritt erfasst die natürliche Positionsverzerrung der Nutzer. Wir berechnen die CTR wie folgt:

Wo:

p = Position. Von 1 bis 10 Cp = Gesamtzahl der Klicks (auf beliebige Dokumente) an Position p über alle Abfragen hinweg Ip = Gesamteindrücke: Wie oft ein Dokument an Position p über alle Suchanfragen hinweg erschienen ist.

Hier gehen wir davon aus, dass höhere Positionen mehr Klicks erhalten.

2. Berechnung der erwarteten Klicks (EC):

Diese Kennzahl legt fest, wie viele Klicks ein Dokument basierend auf seinen Platzierungspositionen und der Klickrate (CTR) für diese Positionen hätte erhalten sollen. Wir berechnen EC wie folgt:

Wo:

Qd = Alle Anfragen, bei denen das Dokument d vorkam pos(d,q) = Position des Dokuments d in den Abfrageergebnissen q

3. Tatsächliche Klicks zählen: Wir zählen die tatsächliche Gesamtzahl der Klicks, die ein Dokument über alle Suchanfragen hinweg erhalten hat, bei denen es erschien, im Folgenden A(d) genannt.

4. Berechnen Sie den COEC-Wert: Dies ist das Verhältnis der tatsächlichen Klicks (A(d)) zu den erwarteten Klicks (EC(d)):

Diese Metrik normalisiert Positionsverzerrungen folgendermaßen:

Ein Wert von 1,0 bedeutet, dass das Dokument angesichts seiner Positionen genau wie erwartet funktioniert hat.
Ein Wert über 1,0 bedeutet, dass das Dokument im Vergleich zu den bisherigen Ergebnissen besser abgeschnitten hat. Dieses Dokument ist daher für die Anfrage relevanter.
Ein Wert unter 1,0 bedeutet, dass das Dokument im Vergleich zu den bisherigen Ergebnissen schlechter abgeschnitten hat. Dieses Dokument ist daher für die Anfrage weniger relevant.

Das Endergebnis ist eine Bewertungszahl, die das widerspiegelt, wonach die Nutzer suchen, wobei positionsbezogene Erwartungen berücksichtigt werden, die aus realen Interaktionen mit unserem Suchsystem abgeleitet wurden.

Technische Umsetzung

Wir werden ein Skript erstellen, um eine Beurteilungsliste zu generieren, mit der ein LTR-Modell trainiert werden kann.

Die Eingabe für dieses Skript sind die in Elastic indexierten UBI-Daten (Abfragen und Ereignisse).

Das Ergebnis ist eine Beurteilungsliste in einer CSV-Datei, die aus diesen UBI-Dokumenten mithilfe des COEC-Algorithmus generiert wird. Diese Beurteilungsliste kann mit Eland verwendet werden, um relevante Merkmale zu extrahieren und ein LTR-Modell zu trainieren.

Schnellstart

Um aus den Beispieldaten in diesem Blog eine Bewertungsliste zu erstellen, können Sie folgende Schritte befolgen:

1. Klonen Sie das Repository:

git clone https://github.com/Alex1795/elastic-ltr-judgement_list-blog.git cd elastic-ltr-judgement_list-blog

2. Installieren Sie die erforderlichen Bibliotheken

Für dieses Skript benötigen wir die folgenden Bibliotheken:

pandas: um die Urteilsliste zu speichern
elasticsearch: Um die UBI-Daten aus unserer Elastic-Bereitstellung zu erhalten

Wir benötigen außerdem Python 3.11.

pip install -r requirements.txt

3. Aktualisieren Sie die Umgebungsvariablen für Ihre Elastic-Bereitstellung in einer .env-Datei.

ES_HOST
API-Schlüssel

Um die Umgebungsvariablen hinzuzufügen, verwenden Sie:

source .env

4. Erstellen Sie die Indizes ubi_queries und ubi_events und laden Sie die Beispieldaten hoch. Führen Sie die Datei setup.py aus:

python setup.py

5. Führen Sie das Python-Skript aus:

python judgement_list-generator.py

Wenn Sie diese Schritte befolgen, sollte eine neue Datei namens judgement_list.csv erscheinen, die folgendermaßen aussieht:

Dieses Skript berechnet die Noten unter Anwendung des zuvor erläuterten COEC-Algorithmus mithilfe der unten gezeigten Funktion calculate_relevance_grade() .

Datenarchitektur

Ubi-Anfragen

Unser UBI-Abfrageindex enthält Informationen über die in unserem Suchsystem ausgeführten Abfragen. Dies ist ein Beispieldokument:

{ "client_id": "client_002", "query": "italian pasta recipes", "query_attributes": { "search_type": "recipe", "category": "food", "cuisine": "italian" }, "query_id": "q002", "query_response_id": "qr002", "query_response_object_ids": [ "doc_011", "doc_012", "doc_013", "doc_014", "doc_015", "doc_016", "doc_017", "doc_018", "doc_019", "doc_020" ], "timestamp": "2024-08-14T11:15:00Z", "user_query": "italian pasta recipes" }

Hier sehen wir Daten vom Benutzer (client_id), aus den Ergebnissen der Abfrage (query_response_object_ids) und die Abfrage selbst (timestamp, user_query).

Ubi-Klickereignisse

Unser ubi_events-Index enthält Daten von jedem Klick eines Nutzers auf ein Dokument in den Suchergebnissen. Dies ist ein Beispieldokument:

{ "action_name": "click", "application": "recipe_search", "client_id": "client_001", "event_attributes": { "object": { "description": "Authentic Italian Pizza Dough Recipe with Step-by-Step Photos", "device": "desktop", "object_id": "doc_001", "position": { "ordinal": 1, "page_depth": 1 }, "user": { "city": "New York", "country": "USA", "ip": "192.168.1.100", "location": { "lat": 40.7128, "lon": -74.006 }, "region": "NY" } } }, "message": "User clicked on document doc_001", "message_type": "click", "query_id": "q001", "timestamp": "2024-08-14T10:31:00Z", "user_query": "best pizza recipe" }

Skript zur Generierung der Urteilsliste

Allgemeine Skriptübersicht

Dieses Skript automatisiert die Generierung der Beurteilungsliste mithilfe von UBI-Daten aus Abfragen und Klickereignissen, die in Elasticsearch gespeichert sind. Es führt folgende Aufgaben aus:

Ruft die UBI-Daten in Elasticsearch ab und verarbeitet sie.
Korreliert UBI-Ereignisse mit seinen Abfragen.
Berechnet die Klickrate (CTR) für jede Position.
Berechnet die erwarteten Klicks (EC) für jedes Dokument.
Zählt die tatsächlichen Klicks für jedes Dokument.
Berechnet den COEC-Score für jedes Abfrage-Dokument-Paar.
Erstellt eine Bewertungsliste und speichert diese in einer CSV-Datei.

Lassen Sie uns die einzelnen Funktionen durchgehen:

connect_to_elasticsearch()

def connect_to_elasticsearch(host, api_key): """Create and return Elasticsearch client""" try: es = Elasticsearch( hosts=[host], api_key=api_key, request_timeout=60 ) # Test the connection if es.ping(): print(f"✓ Successfully connected to Elasticsearch at {host}") return es else: print("✗ Failed to connect to Elasticsearch") return None except Exception as e: print(f"✗ Error connecting to Elasticsearch: {e}") return None

Diese Funktion gibt ein Elasticsearch-Clientobjekt unter Verwendung des Hosts und des API-Schlüssels zurück.

fetch_ubi_data()

def fetch_ubi_data(es_client: Elasticsearch, queries_index: str, events_index: str, size: int = 10000) -> Tuple[List[Dict], List[Dict]]: """ Fetch UBI queries and events data from Elasticsearch indices. Args: es_client: Elasticsearch client queries_index: Name of the UBI queries index events_index: Name of the UBI events index size: Maximum number of documents to fetch Returns: Tuple of (queries_data, events_data) """ logger.info(f"Fetching data from {queries_index} and {events_index}") # Fetch queries with error handling try: queries_response = es_client.search( index=queries_index, body={ "query": {"match_all": {}}, "size": size } ) queries_data = [hit['_source'] for hit in queries_response['hits']['hits']] logger.info(f"Fetched {len(queries_data)} queries") except Exception as e: logger.error(f"Error fetching queries from {queries_index}: {e}") raise # Fetch events (only click events for now) with error handling try: events_response = es_client.search( index=events_index, body={ "query": { "term": {"message_type.keyword": "CLICK_THROUGH"} }, "size": size } ) events_data = [hit['_source'] for hit in events_response['hits']['hits']] logger.info(f"Fetched {len(events_data)} click events") except Exception as e: logger.error(f"Error fetching events from {events_index}: {e}") raise logger.info(f"Data fetch completed successfully - Queries: {len(queries_data)}, Events: {len(events_data)}") return queries_data, events_data

Diese Funktion ist die Datenextraktionsschicht; sie stellt eine Verbindung zu Elasticsearch her, um UBI-Abfragen mittels einer match_all-Abfrage abzurufen und filtert UBI-Ereignisse, um nur 'CLICK_THROUGH'-Ereignisse zu erhalten.

process_ubi_data()

def process_ubi_data(queries_data: List[Dict], events_data: List[Dict]) -> pd.DataFrame: """ Process UBI data and generate judgment list. Args: queries_data: List of query documents from UBI queries index events_data: List of event documents from UBI events index Returns: DataFrame with judgment list (qid, docid, grade, keywords) """ logger.info("Processing UBI data to generate judgment list") # Group events by query_id clicks_by_query = {} for event in events_data: query_id = event['query_id'] if query_id not in clicks_by_query: clicks_by_query[query_id] = {} # Extract clicked document info object_id = event['event_attributes']['object']['object_id'] position = event['event_attributes']['object']['position']['ordinal'] clicks_by_query[query_id][object_id] = { 'position': position, 'timestamp': event['timestamp'] } judgment_list = [] # Process each query for query in queries_data: query_id = query['query_id'] user_query = query['user_query'] document_ids = query['query_response_object_ids'] # Get clicks for this query query_clicks = clicks_by_query.get(query_id, {}) # Generate judgment for each document shown for doc_id in document_ids: grade = calculate_relevance_grade(doc_id, query_clicks, document_ids, queries_data, events_data) judgment_list.append({ 'qid': query_id, 'docid': doc_id, 'grade': grade, 'query': user_query }) df = pd.DataFrame(judgment_list) logger.info(f"Generated {len(df)} judgment entries for {df['qid'].nunique()} unique queries") return df

Diese Funktion ist für die Generierung der Urteilsliste zuständig. Die Verarbeitung der UBI-Daten beginnt mit der Verknüpfung von UBI-Ereignissen und -Abfragen. Anschließend wird für jedes Dokument-Abfrage-Paar die Funktion calculate_relevance_grade() aufgerufen, um die Einträge für die Bewertungsliste zu erhalten. Schließlich gibt es die resultierende Liste als Pandas-DataFrame zurück.

calculate_relevance_grade()

def calculate_relevance_grade(document_id: str, clicks_data: Dict, query_response_ids: List[str], all_queries_data: List[Dict] = None, all_events_data: List[Dict] = None) -> float: """ Calculate COEC (Click Over Expected Clicks) relevance score for a document. Args: document_id: ID of the document clicks_data: Dictionary of clicked documents with their positions for current query query_response_ids: List of document IDs shown in search results (ordered by position) all_queries_data: All queries data for calculating position CTR averages all_events_data: All events data for calculating position CTR averages Returns: COEC relevance score (continuous value, typically 0.0 to 5.0+) """ # If no global data provided, fall back to simple position-based grading if all_queries_data is None or all_events_data is None: logger.warning("No global data provided, falling back to position-based grading") # Simple fallback logic if document_id in clicks_data: position = clicks_data[document_id]['position'] if position > 3: return 4.0 elif position >= 1 and position <= 3: return 3.0 if document_id in query_response_ids: position = query_response_ids.index(document_id) + 1 if position <= 5: return 2.0 elif position >= 6 and position <= 10: return 1.0 return 0.0 # Calculate rank-aggregated click-through rates position_ctr_averages = {} position_impression_counts = {} position_click_counts = {} # Initialize counters for pos in range(1, 11): # Positions 1-10 position_impression_counts[pos] = 0 position_click_counts[pos] = 0 # Count impressions (every document shown contributes) for query in all_queries_data: for i, doc_id in enumerate(query['query_response_object_ids'][:10]): # Top 10 positions position = i + 1 position_impression_counts[position] += 1 # Count clicks by position for event in all_events_data: if event.get('action_name') == 'click': position = event['event_attributes']['object']['position']['ordinal'] if position <= 10: position_click_counts[position] += 1 # Calculate average CTR per position for pos in range(1, 11): if position_impression_counts[pos] > 0: position_ctr_averages[pos] = position_click_counts[pos] / position_impression_counts[pos] else: position_ctr_averages[pos] = 0.0 # Calculate expected clicks for this specific document expected_clicks = 0.0 # Count how many times this document appeared at each position for any query for query in all_queries_data: if document_id in query['query_response_object_ids']: position = query['query_response_object_ids'].index(document_id) + 1 if position <= 10: expected_clicks += position_ctr_averages[position] # Count total actual clicks for this document across all queries actual_clicks = 0 for event in all_events_data: if (event.get('action_name') == 'click' and event['event_attributes']['object']['object_id'] == document_id): actual_clicks += 1 # Calculate COEC score if expected_clicks > 0: coec_score = actual_clicks / expected_clicks else: coec_score = 0.0 logger.debug( f"Document {document_id}: {actual_clicks} clicks / {expected_clicks:.3f} expected = {coec_score:.3f} COEC") return coec_score

Dies ist die Funktion, die den COEC-Algorithmus implementiert. Es berechnet die Klickrate (CTR) für jede Position, vergleicht dann die tatsächlichen Klicks für ein Dokument-Abfrage-Paar und berechnet schließlich den tatsächlichen COEC-Wert für jedes Paar.

generate_judgment_statistics()

def generate_judgment_statistics(df: pd.DataFrame) -> Dict: """Generate statistics about the judgment list.""" stats = { 'total_judgments': len(df), 'unique_queries': df['qid'].nunique(), 'unique_documents': df['docid'].nunique(), 'grade_distribution': df['grade'].value_counts().to_dict(), 'avg_judgments_per_query': len(df) / df['qid'].nunique() if df['qid'].nunique() > 0 else 0, 'queries_with_clicks': len(df[df['grade'] > 1]['qid'].unique()), 'click_through_rate': len(df[df['grade'] > 1]) / len(df) if len(df) > 0 else 0 } return stats

Es generiert nützliche Statistiken aus der Bewertungsliste, wie z. B. die Gesamtzahl der Anfragen, die Gesamtzahl der eindeutigen Dokumente oder die Notenverteilung. Dies dient lediglich der Information und hat keinen Einfluss auf die endgültige Urteilsliste.

Ergebnisse und Auswirkungen

Wenn Sie die Anweisungen im Abschnitt „Schnellstart“ befolgen, sollte eine CSV-Datei mit einer Urteilsliste mit 320 Einträgen angezeigt werden (ein Beispiel finden Sie im Repository). Mit diesen Feldern:

qid: eindeutige ID der Abfrage
docid: eindeutige Kennung für ein resultierendes Dokument
Note: die berechnete Note für das Abfrage-Dokument-Paar
Anfrage: Die Benutzeranfrage

Schauen wir uns die Ergebnisse der Suchanfrage „Italienische Rezepte“ an:

qid

docid

Grad

Abfrage

q1-italienische-rezepte

Grundrezept für Pasta

0,0

Italienische Rezepte

q1-italienische-rezepte

Rezept_Pizza_Margherita

3,333333

Italienische Rezepte

q1-italienische-rezepte

Rezept-Risotto-Anleitung

10.0

Italienische Rezepte

q1-italienische-rezepte

Rezept_französisches_Croissant

0,0

Italienische Rezepte

q1-italienische-rezepte

Rezept_spanische_Paella

0,0

Italienische Rezepte

q1-italienische-rezepte

Rezept_griechische_Moussaka

1,875

Italienische Rezepte

Aus den Ergebnissen geht hervor, dass für die Suchanfrage „Italienische Rezepte“ Folgendes gilt:

Das Risotto-Rezept ist definitiv das beste Ergebnis der Suchanfrage und erhielt zehnmal mehr Klicks als erwartet.
Auch die Pizza Margherita ist ein hervorragendes Ergebnis.
Die griechische Moussaka erzielt (überraschenderweise) ebenfalls ein gutes Ergebnis und schneidet besser ab, als ihre Platzierung in der Ergebnisliste vermuten lässt. Das bedeutet, dass einige Nutzer, die nach italienischen Rezepten suchten, stattdessen an diesem Rezept interessiert waren. Vielleicht interessieren sich diese Nutzer generell für mediterrane Gerichte. Letztendlich bedeutet dies, dass es sich um ein gutes Ergebnis handeln könnte, das unter den beiden anderen, oben besprochenen, "besseren" Treffern angezeigt werden könnte.

Fazit

Die Verwendung von UBI-Daten ermöglicht es uns, das Training von LTR-Modellen zu automatisieren und so qualitativ hochwertige Beurteilungslisten aus unseren eigenen Nutzern zu erstellen. Die UBI-Daten liefern einen großen Datensatz, der die Nutzung unseres Suchsystems widerspiegelt. Durch die Verwendung des COEC-Algorithmus zur Generierung der Noten berücksichtigen wir inhärente Verzerrungen und spiegeln gleichzeitig wider, was ein Benutzer als besseres Ergebnis ansieht. Die hier beschriebene Methode kann auf reale Anwendungsfälle angewendet werden, um ein besseres Sucherlebnis zu bieten, das sich mit den tatsächlichen Nutzungstrends weiterentwickelt.

Einzigartige Muster aufdecken: Ein Leitfaden zur Aggregation aussagekräftiger Begriffe in Elasticsearch

Alexander Dávila — Mon, 07 Jul 2025 00:00:00 GMT

In Elasticsearch geht die signifikante Termaggregation über die häufigsten Begriffe hinaus, um statistisch ungewöhnliche Werte in einem Datensatz zu finden. Dies ermöglicht es uns, wertvolle Erkenntnisse und nicht offensichtliche Muster zu entdecken. Eine signifikante Termaggregation liefert eine Antwort mit zwei nützlichen Parametern:

bg_count (Hintergrundzählung): Anzahl der im übergeordneten Datensatz gefundenen Dokumente
doc_count: Anzahl der im Ergebnisdatensatz gefundenen Dokumente

In einem Datensatz zu Handyverkäufen können wir beispielsweise nach relevanten Begriffen im Zusammenhang mit den iPhone 16-Verkäufen suchen, etwa so:

GET phone_sales_analysis/_search { "size": 0, "query": { "term": { "phone_model": { "value": "iPhone 16" } } }, "aggs": { "significant_cities": { "significant_terms": { "field": "city_region", "size": 1 } } } }

Die Antwort lautet dann:

{ "aggregations": { "significant_cities": { "doc_count": 122, "bg_count": 424, "buckets": [ { "key": "Houston", "doc_count": 12, "score": 0.1946481360617346, "bg_count": 14 } ] } } }

Houston gehört weder zu den Top 10 Städten im gesamten Datensatz noch ist Houston die Top-Stadt für das iPhone 16. Die Auswertung der signifikanten Terme ergab jedoch, dass das iPhone 16 in dieser Stadt im Vergleich zu den übrigen Daten überproportional häufig gekauft wird . Lassen Sie uns die Zahlen genauer betrachten:

Auf höchster Ebene:
- Dokumentenanzahl: 122 – Die Abfrage ergab insgesamt 122 Treffer.
- bg_count: 424 — Der Hintergrundsatz (alle Verkaufsbelege) enthält 424 Belege
Im Houston-Eimer:
- Dokumentanzahl: 12 — Houston erscheint in 12 der 122 Suchergebnisse
- bg_count: 14 — Houston erscheint in 14 der insgesamt 424 Dokumente im Hintergrunddatensatz

Dies bedeutet, dass von insgesamt 424 Käufen nur 14 in Houston stattfanden; das sind 3,3 % aller Käufe. Betrachtet man jedoch nur die Verkaufszahlen des iPhone 16, so stellt man fest, dass 12 von 122 Verkäufen in Houston stattfanden, was 9,8 % entspricht – das Dreifache des Wertes im gesamten Datensatz; das ist bemerkenswert!

So sieht das in einer Visualisierung aus: Gesamtumsatz pro Stadtregion.

Wir sehen, dass es in Houston 14 Verkäufe gibt, womit Houston gemessen an den Verkäufen die 14. höchste Stadt im Datensatz ist.

Wenn wir nun einen Filter anwenden, der nur die Verkaufszahlen des iPhone 16 berücksichtigt, verzeichnen wir 12 Verkäufe in Houston. Damit ist Houston die zweitmeisten Städte mit den Verkaufszahlen für dieses spezielle Modell:

Die wichtigsten Begriffe der Aggregation verstehen

Laut Elastic-Dokumentation sind die wichtigsten Begriffe Aggregation:

„(Findet) Begriffe, deren Popularität sich im Vergleich zwischen einem Vordergrund- und einem Hintergrunddatensatz signifikant verändert hat.“

Das bedeutet, dass statistische Kennzahlen verwendet werden, um die Häufigkeit eines Begriffs in einer Teilmenge der Daten (der Vordergrundmenge) mit der Häufigkeit desselben Begriffs in der übergeordneten Datenmenge (der Hintergrundmenge) zu vergleichen. Auf diese Weise spiegelt die Bewertung die statistische Signifikanz wider und nicht, wie häufig ein Begriff in den Daten vorkommt.

Die Hauptunterschiede zwischen einer Aggregation signifikanter Terme und einer normalen Termaggregation sind:

Signifikante Terme vergleichen eine Teilmenge der Daten, während eine Termaggregation nur mit dem aus der Abfrage resultierenden Datensatz arbeitet.
Die Ergebnisse einer Termaggregation sind die häufigsten Terme im Datensatz, während die Ergebnisse einer signifikanten Termaggregation die häufigen Terme ignorieren, um herauszufinden, was den Datensatz einzigartig macht.
Signifikante Terme können einen größeren Einfluss auf die Leistung haben, da sie Daten von der Festplatte und nicht aus dem Arbeitsspeicher abrufen müssen, wie es bei der Termaggregation der Fall ist.

Praktische Anwendung (Verbraucherverhaltensanalyse)

Datenaufbereitung für die Analyse

Für diese Analyse haben wir einen synthetischen Datensatz über Handyverkäufe erstellt, der Preis, technische Daten des Telefons, demografische Daten des Käufers und Kundenfeedback enthält. Wir haben außerdem Einbettungen aus dem Feedback der Nutzer generiert, um später eine semantische Abfrage durchführen zu können. Wir verwendeten das mehrsprachige e5 small model, das auf Elasticsearch standardmäßig verfügbar ist.

So verwenden Sie diesen Datensatz in Elasticsearch:

Laden Sie die CSV-Datei ( hier herunterladbar) mit der Kibana-Funktion „Datendateien hochladen“ hoch.
Richten Sie ein semantisches Feld namens „Einbettung“ ein, wie in diesem Blog beschrieben. multilingual-e5-small model
Schließen Sie den Import mit den Feldtyp-Standardwerten ab (Schlüsselwort für jedes Feld außer purchase_date und user_feedback). Um die hier präsentierten Abfragen ausführen zu können, müssen Sie unbedingt den Indexnamen phone_sales_analysis hinzufügen.

Der Schwerpunkt dieser Analyse liegt auf der Frage : „Was unterscheidet die Käufer des iPhone 16 von anderen Bevölkerungsgruppen?“ und darauf, eine Segmentierung der Käufer für Marketingzwecke zu erstellen.

Dies ist ein Beispieldokument aus dem Datensatz:

{ "customer_type": "Returning", "user_feedback": "I have to say, quality is great for the price. The battery life is really good.", "upgrade_frequency": "2 years", "storage_capacity": "256GB", "occupation": "Technology & Data", "color": "Phantom Black", "gender": "Male", "price_paid": 899, "previous_brand_loyalty": "Mixed", "location_type": "Urban", "phone_model": "Samsung Galaxy S24", "city_region": "San Francisco Bay Area", "@timestamp": "2024-03-15T00:00:00.000-05:00", "income_bracket": "75000-100000", "purchase_channel": "Online", "feedback_sentiment": "positive", "education_level": "Bachelor", "embedding": "I have to say, quality is great for the price. The battery life is really good.", "customer_id": "C001", "purchase_date": "2024-03-15", "age": 34, "trade_in_model": "iPhone 13" }

demografische Muster verstehen

Hier werden wir eine Analyse der Gesamtbevölkerung durchführen und sie mit interessanten Erkenntnissen aus den signifikanten Begriffsaggregationen für iPhone 16-Nutzer vergleichen.

Normale Muster

Um normale Kaufmuster zu verstehen, können wir Daten aus allen Dokumenten und verschiedenen Bereichen aggregieren. Der Einfachheit halber konzentrieren wir uns auf die Berufe der Personen, die ein Telefon gekauft haben. Das können wir mit einer Anfrage an Elasticsearch erreichen.

GET phone_sales_analysis/_search { "aggs": { "occupation_distribution": { "terms": { "size": 5, "field": "occupation" } } }, "size": 0 }

Dies zeigt uns, dass die häufigsten Berufe im Datensatz (nach Anzahl der Datensätze) folgende sind:

Verhaltensmuster von iPhone 16-Nutzern

Um zu verstehen, was die Käufer eines iPhone 16 auszeichnet, führen wir eine Termaggregation auf demselben Feld mit einem Filter durch, um diese Personen in der Abfrage zu finden, etwa so:

GET phone_sales_analysis/_search { "query": { "term": { "phone_model": "iPhone 16" } }, "aggs": { "occupation_distribution": { "terms": { "size": 5, "field": "occupation" } } }, "size": 0 }

Die häufigsten Berufe für iPhone 16-Nutzer sind also:

Wir können sehen, dass iPhone 16-Nutzer im Vergleich zu Nutzern anderer Telefonmodelle unterschiedliche Beschäftigungsmuster aufweisen. Nutzen wir Kibana, um die Ergebnisse einfach zu visualisieren:

In dieser Grafik können wir sehen, dass der Trend beim iPhone 16 vom Trend der Gesamtbevölkerung abweicht.

Wir können diese gesamte Analyse überspringen und direkt zu den Unterschieden zwischen iPhone 16-Nutzern und der Gesamtbevölkerung gelangen, indem wir eine Aggregation eines einzigen signifikanten Begriffs durchführen:

GET phone_sales_analysis/_search { "query": { "term": { "phone_model": "iPhone 16" } }, "aggs": { "occupation_distribution": { "significant_terms": { "size": 5, "field": "occupation" } } }, "size": 0 }

Kurz gesagt, erhalten wir folgende Antwort:

Werte der Berufe für das iPhone 16

doc_count

bg_count

Berufsverteilung (oberste Ebene)

122

424

Medizin- und Gesundheitsbereich

Die Reaktion lässt eindeutig darauf schließen, dass iPhone 16-Nutzer ein ungewöhnliches (sprich: signifikantes!) Problem haben. Anzahl der Beschäftigten im medizinischen und Gesundheitsbereich im Vergleich zur Gesamtbevölkerung. Mal sehen, was die Zahlen in der Antwort bedeuten:

Auf höchster Ebene:
- Dokumentenanzahl: 122 – Die Abfrage ergab insgesamt 122 Treffer.
- bg_count: 424 — Der Hintergrundsatz (alle Verkaufsbelege) enthält 424 Belege
Im Bereich Medizin & Gesundheitswesen:
- Dokumentanzahl: 45 — „Medizin & Gesundheitswesen“ erscheint in 45 der 122 Suchergebnisse
- bg_count: 57 — "Medizin & Gesundheitswesen" erscheint in 57 der insgesamt 424 Dokumente im Hintergrunddatensatz

Von 424 Käufern arbeiten 57 im medizinischen und Gesundheitsbereich – das entspricht 13,44 %. Betrachtet man jedoch die Käufer des iPhone 16, so arbeiten 45 von 122 im medizinischen und Gesundheitsbereich – das entspricht 36,88 %. Das bedeutet, dass die Wahrscheinlichkeit, jemanden aus dem medizinischen oder Gesundheitssektor unter den iPhone 16-Nutzern zu finden, doppelt so hoch ist!

Wir können diese Analyse auch auf andere Bereiche (Alter, Standort, Einkommensklasse usw.) anwenden, um mehr Informationen darüber zu erhalten, was die Nutzer des iPhone 16 auszeichnet.

Kundensegmentierung

Mithilfe der Aggregation signifikanter Begriffe können wir Erkenntnisse über die Beziehungen zwischen Produkten, Kategorien und Kundensegmenten gewinnen. Hierfür erstellen wir eine übergeordnete Aggregation für die Kategorie, die wir genauer untersuchen möchten. Wir verwenden außerdem eine Unteraggregation von signifikanten Begriffen und normalen Begriffen, um interessante Erkenntnisse über diese Kategorie zu gewinnen und sie mit dem zu vergleichen, was die meisten Menschen in diesem Beruf verwenden.

Schauen wir uns beispielsweise an, was Menschen in verschiedenen Berufsfeldern bevorzugen:

Um die Analyse übersichtlicher zu gestalten, beschränken wir unsere Suche auf drei Arbeitsbereiche: ["Verwaltung & Support", "Technologie & Daten", "Medizin & Gesundheitswesen"]
Auf der Seite der Aggregationen beginnen wir mit einer Termaggregation nach Berufsbezeichnung.
Fügen Sie eine Unteraggregation hinzu: Begriffe nach Telefonmodell – um herauszufinden, welche Modelle Nutzer kaufen, die in den jeweiligen Bereichen arbeiten.
Fügen Sie eine zweite Unteraggregation hinzu: signifikante Begriffe nach Telefonmodellen – um herauszufinden, welche Modelle in den einzelnen Arbeitsbereichen besonders sind.

GET phone_sales_analysis/_search { "query": { "terms": { "occupation": [ "Administrative & Support", "Technology & Data", "Medical & Healthcare" ] } }, "aggs": { "occupations": { "terms": { "size": 15, "field": "occupation" }, "aggs": { "general_models": { "terms": { "field": "phone_model" } }, "significant_models": { "significant_terms": { "field": "phone_model" } } } } }, "size": 0 }

Lassen Sie uns die Aggregationsergebnisse im Detail betrachten:

Beruf: Verwaltung & Unterstützung

Termaggregation

Aggregation signifikanter Terme

Aus dieser Tabelle lässt sich schließen, dass es keine signifikanten Unterschiede zwischen dem Trend für diesen Beruf und dem Trend für die Gesamtbevölkerung gibt.

Beruf: Technologie & Daten

Termaggregation

Aggregation signifikanter Terme

Gesamtzahl der Dokumente: 424

Dokumente in diesem Beruf: 71

Telefonmodell

doc_count (dieses Modell in diesem Beruf)

bg_count (Dieses Modell ist in allen Dokumenten enthalten)

% in allen Dokumenten

% in diesem Beruf

Google Pixel 8

5,19 %

16,90 %

OnePlus 11

3,30 %

12,68 %

OnePlus 12 Pro

0,71 %

4,23 %

Google Pixel 8 Pro

4,95 %

12,68 %

Nichts Telefon 2

1,89 %

7,04 %

Samsung Galaxy Z Fold5

1,42 %

5,63 %

OnePlus 12

4,72 %

11,27 %

Beruf: Medizin & Gesundheitswesen

Termaggregation

Aggregation signifikanter Terme

Gesamtzahl der Dokumente: 424

Dokumente in diesem Beruf: 57

Telefonmodell

doc_count (dieses Modell in diesem Beruf)

bg_count (Dieses Modell ist in allen Dokumenten enthalten)

% in allen Dokumenten

% in diesem Beruf

iPhone 16

122

28,77 %

78,95 %

iPhone 15 Pro Max

3,07 %

5,26 %

iPhone 15

9,43 %

12,28 %

Mal sehen, welche Geschichte uns diese Daten erzählen:

Medizinisches Fachpersonal und Angehörige von Gesundheitsberufen bevorzugen das iPhone 16 und neigen generell sehr dazu, Apple-Handys zu benutzen.
Technologie- und Datenexperten bevorzugen High-End-Android-Smartphones, greifen aber nicht unbedingt auf die Marke Samsung zurück. Auch in dieser Kategorie ist ein deutlicher Trend zu iPhones zu beobachten.
Bei Verwaltungs- und Supportmitarbeitern sind Samsung- und Google-Handys beliebt, es gibt jedoch keinen ausgeprägten und eindeutigen Trend.

Aggregation signifikanter Begriffe und Hybridsuche

Die Hybridsuche kombiniert Textsuche und semantische Ergebnisse, um ein verbessertes Sucherlebnis zu bieten. In diesem Kontext kann eine aussagekräftige Termaggregation Aufschluss über die Ergebnisse einer kontextbezogenen Suche geben, indem sie die Frage beantwortet: Was ist das Besondere an diesem Datensatz im Vergleich zu allen Dokumenten?Um diese Funktion zu veranschaulichen, sehen wir uns an, welche Modelle überrepräsentiert sind, wenn Nutzer von guter Leistung sprechen:

Wir erstellen eine semantische Abfrage, bei der wir das beste Nutzerfeedback finden, das dem Eingabetext „gute Leistung“ im Feld „Einbettung“ am nächsten kommt.
Wir werden außerdem eine Textsuche mit denselben Begriffen im Textfeld user_feedback durchführen.
Wir werden außerdem eine Abfrage mit aussagekräftigen Begriffen hinzufügen, um Telefonmodelle zu finden, die in diesen Ergebnissen häufiger vorkommen als im gesamten Datensatz.

GET phone_sales_analysis/_search { "retriever": { "rrf": { "retrievers": [ { "standard": { "query": { "bool": { "must": [ { "match": { "user_feedback": { "query": "good performance", "operator": "and" } } } ] } } } }, { "standard": { "query": { "semantic": { "field": "embedding", "query": "good performance" } } } } ], "rank_window_size": 20 } }, "aggs": { "Models": { "significant_terms": { "field": "phone_model" } } } }

Betrachten wir ein Beispiel für die übereinstimmenden Dokumente:

Das ist die Antwort, die wir erhalten:

{ "took": 388, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 20, "relation": "eq" }, "max_score": 0.016393442, "hits": [...] }, "aggregations": { "Models": { "doc_count": 20, "bg_count": 424, "buckets": [ { "key": "iPhone 15", "doc_count": 5, "score": 0.4125, "bg_count": 40 } ] } } }

Dies bedeutet, dass ein iPhone 15 zwar 40 Mal in insgesamt 424 Dokumenten vorkommt (9,4 % der Dokumente), es aber 5 Mal in den 20 Dokumenten zu finden ist, die der semantischen Suche „gute Leistung“ entsprechen (25 % der Dokumente). Daraus lässt sich schließen: Die Wahrscheinlichkeit, ein iPhone 15 zu finden, ist 2,7-mal höher, wenn es um gute Leistung geht, als durch Zufall.

Fazit

Durch die Aggregation signifikanter Terme lassen sich einzigartige Details eines Datensatzes aufdecken, indem man ihn mit der Gesamtheit aller Dokumente vergleicht. Dadurch können unerwartete Zusammenhänge in unseren Daten aufgedeckt werden, die über die reine Anzahl der Vorkommen hinausgehen. Wir können in verschiedenen Anwendungsfällen aussagekräftige Begriffe einsetzen, die sehr interessante Funktionen ermöglichen, zum Beispiel:

Bei der Betrugserkennung sollten Sie Muster erkennen – identifizieren Sie typische Transaktionen gestohlener Kreditkarten.
Markenqualitätseinblicke aus Nutzerbewertungen – Marken mit einer unverhältnismäßig hohen Anzahl schlechter Bewertungen erkennen.
Aufspüren falsch klassifizierter Dokumente – Aufspüren von Dokumenten, die zu einer Kategorie gehören (Termfilter), die in einer Beschreibung ungewöhnliche Wörter für die Kategorie verwenden (Aggregation signifikanter Begriffe).

Alexander Dávila - Elasticsearch Labs

Training von LTR-Modellen in Elasticsearch mit Urteilslisten basierend auf Be­nut­zer­ver­hal­tens­dat­en

Warum UBI-Daten für das Training Ihres LTR-Modells nützlich sein können

Notenberechnung

Noten für LTR-Schulung

Notenberechnung – COEC-Algorithmus

Technische Umsetzung

Schnellstart

Datenarchitektur

Ubi-Anfragen

Ubi-Klickereignisse

Skript zur Generierung der Urteilsliste

Allgemeine Skriptübersicht

connect_to_elasticsearch()

fetch_ubi_data()

process_ubi_data()

calculate_relevance_grade()

generate_judgment_statistics()

Ergebnisse und Auswirkungen

Fazit

Einzigartige Muster aufdecken: Ein Leitfaden zur Aggregation aussagekräftiger Begriffe in Elasticsearch

Die wichtigsten Begriffe der Aggregation verstehen

Praktische Anwendung (Verbraucherverhaltensanalyse)

Datenaufbereitung für die Analyse

demografische Muster verstehen

Normale Muster

Verhaltensmuster von iPhone 16-Nutzern

Kundensegmentierung

Aggregation signifikanter Begriffe und Hybridsuche

Fazit

Training von LTR-Modellen in Elasticsearch mit Urteilslisten basierend auf Benutzerverhaltensdaten