Python - Elasticsearch Labs

Multimodale Suche nach Berggipfeln mit Elasticsearch und SigLIP-2

Navneet Kumar — Tue, 04 Nov 2025 00:00:00 GMT

Wollten Sie schon immer einmal Ihr Fotoalbum nach Bedeutung durchsuchen? Versuchen Sie Suchanfragen wie „Zeig mir meine Bilder, auf denen ich eine blaue Jacke trage und auf einer Bank sitze“, „Zeig mir Bilder vom Mount Everest“ oder „Sake und Sushi“. Schnapp dir eine Tasse Kaffee (oder dein Lieblingsgetränk) und lies weiter. In diesem Blog zeigen wir Ihnen, wie Sie eine multimodale hybride Suchanwendung erstellen. Multimodal bedeutet, dass die App verschiedene Arten von Eingaben verstehen und durchsuchen kann – Text, Bilder und Audio – und nicht nur Wörter. Hybrid bedeutet, dass Techniken wie Keyword-Matching, kNN-Vektorsuche und Geofencing kombiniert werden, um präzisere Ergebnisse zu liefern.

Um dies zu erreichen, verwenden wir Googles SigLIP-2, um Vektoreinbettungen sowohl für Bilder als auch für Texte zu generieren und diese in der Elasticsearch-Vektordatenbank zu speichern. Zum Zeitpunkt der Abfrage wandeln wir die Sucheingabe, Text oder Bild, in Einbettungen um und führen schnelle kNN-Vektorsuchen durch, um Ergebnisse abzurufen. Diese Konfiguration ermöglicht eine effiziente Text-zu-Bild- und Bild-zu-Bild-Suche. Eine Streamlit-Benutzeroberfläche erweckt dieses Projekt zum Leben, indem sie uns ein Frontend zur Verfügung stellt, mit dem wir nicht nur textbasiert nach passenden Fotos aus dem Album suchen und diese anzeigen können, sondern auch den Berggipfel auf dem hochgeladenen Bild identifizieren und weitere Fotos dieses Berges im Fotoalbum anzeigen können. Wir beschreiben außerdem die Schritte, die wir zur Verbesserung der Suchgenauigkeit unternommen haben, und geben praktische Tipps und Tricks. Zur weiteren Erkundung stellen wir ein GitHub-Repository und ein Colab-Notebook zur Verfügung.

Wie alles begann

Dieser Blogbeitrag entstand auf Anregung eines 10-Jährigen, der mich bat, ihm alle Bilder des Mount Ama Dablam von meiner Everest-Basislager-Trekkingtour zu zeigen. Während wir das Fotoalbum durchsahen, wurde ich auch gebeten, mehrere andere Berggipfel zu identifizieren, von denen ich einige nicht benennen konnte.

Das brachte mich auf die Idee, dass dies ein unterhaltsames Computer-Vision-Projekt werden könnte. Was wir erreichen wollten:

Finde Bilder eines Berggipfels anhand seines Namens
Errate den Namen des Berggipfels anhand eines Bildes und finde ähnliche Gipfel im Fotoalbum.
Konzeptabfragen zum Laufen bringen (Person, Fluss, Gebetsfahnen usw.)

Zusammenstellung des Dreamteams: SigLIP-2, Elasticsearch & Streamlit

Es wurde schnell klar, dass wir, um dies zu ermöglichen, sowohl den Text („Ama Dablam“) als auch die Bilder (Fotos aus meinem Album) in Vektoren umwandeln müssten, die sinnvoll verglichen werden können, d. h. im selben Vektorraum. Sobald wir das getan haben, besteht die Suche nur noch darin, „die nächstgelegenen Nachbarn zu finden“.

Um Bildeinbettungen zu generieren, verwenden wir einen mehrsprachigen Bild-Sprach-Encoder, sodass ein Foto eines Berges und ein Ausdruck wie „Ama Dablam“ im selben Vektorraum landen.

SigLIP-2, das kürzlich von Google veröffentlicht wurde, passt hier gut hinein. Es kann Einbettungen ohne aufgabenspezifisches Training generieren (eine Zero-Shot -Einstellung) und eignet sich hervorragend für unseren Anwendungsfall: unbeschriftete Fotos und Gipfel mit unterschiedlichen Namen und Sprachen. Da es für die Zuordnung von Text zu Bild trainiert wurde, werden ein Bergbild von der Wanderung und eine kurze Texteingabeaufforderung als Einbettungen sehr ähnlich dargestellt, selbst wenn die Abfragesprache oder die Rechtschreibung variiert.

SigLIP-2 bietet ein gutes Verhältnis von Qualität zu Geschwindigkeit, unterstützt mehrere Eingangsauflösungen und läuft sowohl auf der CPU als auch auf der GPU. Der SigLIP-2 ist im Vergleich zu Vorgängermodellen wie dem ursprünglichen CLIP robuster für Außenaufnahmen. Während unserer Tests lieferte SigLIP-2 durchweg zuverlässige Ergebnisse. Es wird zudem sehr gut unterstützt, was es zur naheliegenden Wahl für dieses Projekt macht.

Als nächstes benötigen wir eine Vektordatenbank zum Speichern der Einbettungen und zur Durchführung der Power-Suche. Es sollte nicht nur die Cosinus-kNN-Suche über Bildeinbettungen unterstützen, sondern auch Geofencing und Textfilter in einer einzigen Abfrage anwenden. Elasticsearch passt hier gut: Es verarbeitet Vektoren (HNSW kNN auf dense_vector-Feldern) sehr gut, unterstützt die hybride Suche, die Text-, Vektor- und Geo-Abfragen kombiniert, und bietet standardmäßig Filter- und Sortierfunktionen. Es ist außerdem horizontal skalierbar, sodass man problemlos von einer Handvoll Fotos auf Tausende wachsen kann. Der offizielle Elasticsearch Python-Client hält die Infrastruktur einfach und lässt sich nahtlos in das Projekt integrieren. Schließlich benötigen wir noch ein schlankes Frontend, in dem wir Suchanfragen eingeben und Ergebnisse anzeigen können. Für eine schnelle, Python-basierte Demo ist Streamlit hervorragend geeignet. Es bietet die grundlegenden Funktionen, die wir benötigen – Datei-Upload, ein responsives Bildraster und Dropdown-Menüs zum Sortieren und Geofencing. Es lässt sich leicht klonen und lokal ausführen und funktioniert auch in einem Colab-Notebook.

Implementierung

Elasticsearch-Indexierungsdesign und Indexierungsstrategie

Für dieses Projekt verwenden wir zwei Indizes: peaks_catalog und photos.

Peaks_Katalogindex

Dieser Index dient als kompakter Katalog markanter Berggipfel, die während der Everest-Basislager-Trekkingtour sichtbar sind. Jedes Dokument in diesem Index entspricht einem einzelnen Berggipfel, wie zum Beispiel dem Mount Everest. Für jedes Berggipfeldokument speichern wir Namen/Aliasse, optionale Breiten- und Längengradkoordinaten sowie einen einzelnen Prototypvektor, der durch die Kombination von SigLIP-2-Texteingabeaufforderungen (+ optionalen Referenzbildern) erstellt wird.

Indexzuordnung:

Feld

Typ

Beispiel

Zweck/Anmerkungen

Vektor-/Indexierung

Ausweis

Stichwort

ama-dablam

Stabiler Slug/ID

—

Namen

Text + Stichwort-Unterfeld

["Ama Dablam","Amadablam"]

Aliase / mehrsprachige Namen; names.raw für genaue Filter

—

Breitengrad

Geopunkt

{"lat":27.8617,"lon":86.8614}

GPS-Koordinaten des Gipfels als Kombination aus Breitengrad und Längengrad (optional)

—

elev_m

ganze Zahl

6812

Höhenangabe (optional)

—

text_embed

dense_vector

768

Kombinierter Prototyp (Aufforderungen und optional 1–3 Referenzbilder) für diesen Peak

index:true, similarity:"cosine", index_options:{type:"hnsw", m:16, ef_construction:128}

Dieser Index wird vor allem für Bild-zu-Bild-Suchen verwendet, beispielsweise zur Identifizierung von Berggipfeln anhand von Bildern. Wir verwenden diesen Index auch, um die Ergebnisse der Text-zu-Bild-Suche zu verbessern.

Zusammenfassend lässt sich sagen, dass die peaks_catalog die Frage „Welcher Berg ist das?“ in ein fokussiertes Nächste-Nachbar-Problem umwandelt und so das konzeptionelle Verständnis effektiv von der Komplexität der Bilddaten trennt.

Indexierungsstrategie für den peaks_catalog-Index: Wir beginnen mit der Erstellung einer Liste der markantesten Gipfel, die während der EBC-Trekkingtour sichtbar sind. Für jeden Gipfel speichern wir seine geografische Position, seinen Namen, Synonyme und seine Höhe in einer YAML-Datei. Im nächsten Schritt wird für jeden Peak die Einbettung generiert und im Feld text_embed gespeichert. Um robuste Einbettungen zu erzeugen, verwenden wir die folgende Technik:

Erstellen Sie einen Textprototyp mit folgendem Werkzeug:
- Namen der Gipfel
- Prompt-Ensemble (Verwendung mehrerer unterschiedlicher Prompts, um dieselbe Frage zu beantworten), zum Beispiel:
  - „Ein Naturfoto des Berggipfels {name} im Himalaya, Nepal“
  - „ {name} markanter Gipfel in der Khumbu-Region, alpine Landschaft“
  - „ {name} Berggipfel, Schnee, felsiger Grat“
- optionales Anti-Konzept (sagt SigLIP-2, wonach nicht gematcht werden soll): einen kleinen Vektor für „Gemälde, Illustration, Poster, Karte, Logo“ abziehen, um eine Bevorzugung von echten Fotos zu erreichen.
Optional kann ein Bildprototyp erstellt werden, falls Referenzbilder des Gipfels vorhanden sind.

Anschließend verschmelzen wir den Text- und Bildprototyp , um die endgültige Einbettung zu erzeugen. Abschließend wird das Dokument mit allen erforderlichen Feldern indexiert :

def l2norm(v: np.ndarray) -> np.ndarray: return v / (np.linalg.norm(v) + 1e-12) def compute_blended_peak_vec( emb: Siglip2, names: List[str], peak_id: str, peaks_images_root: str, alpha_text: float = 0.5, max_images: int = 3, ) -> Tuple[np.ndarray, int, int, List[str]]: """ Build blended vector for a single peak. Returns: vec : np.ndarray (L2-normalized) found_count : number of reference images discovered used_count : number of references used (<= max_images) used_filenames: list of filenames used (for logging) """ # 1) TEXT vector tv = embed_text_blend(emb, names) # 2) IMAGE refs: prefer folder by id; fallback to slug of the primary name root = Path(peaks_images_root) candidates = [root / peak_id] if names: candidates.append(root / slugify(names[0])) all_refs: List[Path] = [] for c in candidates: if c.exists() and c.is_dir(): all_refs = list_ref_images(c) if all_refs: break found = len(all_refs) used_list = all_refs[:max_images] if (max_images and found > max_images) else all_refs used = len(used_list) img_v = embed_image_mean(emb, used_list) if used_list else None # 3) Blend TEXT and IMAGE vectors, clamp alpha to [0,1] a = max(0.0, min(1.0, float(alpha_text))) vec = l2norm(tv if img_v is None else (a * tv + (1.0 - a) * img_v)).astype("float32") return vec, found, used, [p.name for p in used_list]

Beispieldokument aus dem Index peaks_catalog :

Fotoindex

Dieser Hauptindex speichert detaillierte Informationen über alle Fotos im Album. Jedes Dokument stellt ein einzelnes Foto dar und enthält folgende Informationen:

Relativer Pfad zum Foto im Fotoalbum. Dies kann verwendet werden, um das passende Bild anzuzeigen oder das Bild in die Suchoberfläche zu laden.
GPS- und Zeitinformationen des Bildes.
Dichter Vektor für die Bildkodierung, generiert durch SigLIP-2.
predicted_peaks Das ermöglicht es uns, nach Gipfelnamen zu filtern. Indexzuordnung

Feld

Typ

Beispiel

Zweck/Anmerkungen

Vektor-/Indexierung

Weg

Stichwort

data/images/IMG_1234.HEIC

Wie die Benutzeroberfläche das Miniaturbild/Vollbild öffnet

—

Bildausschnitt

dense_vector

768

SigLIP-2 Bildeinbettung

index:true, similarity:"cosine", index_options:{type:"hnsw", m:16, ef_construction:128}

vorhergesagte_Spitzen

Stichwort

["ama-dablam","pumori"]

Top-K-Vorhersagen zur Indexierungszeit (kostengünstiger UX-Filter / Facette)

—

GPS

Geopunkt

{"lat":27.96,"lon":86.83}

Aktiviert Geofilter

—

Schusszeit

date

2023-10-18T09:41:00Z

Aufnahmezeit: Sortieren/Filtern

—

Indexierungsstrategie für den Fotoindex: Für jedes Foto im Album gehen wir wie folgt vor: Extrahieren Sie die Bildinformationen shot_time und gps aus den Bildmetadaten.

SigLIP-2 Bildeinbettung: Das Bild wird durch das Modell geleitet und der Vektor anschließend L2-normalisiert. Speichere die Einbettung im Feld clip_image .
Die Peaks werden vorhergesagt und im Feld predicted_peaks gespeichert. Dazu nehmen wir zunächst den im vorherigen Schritt erzeugten Bildvektor des Fotos und führen dann eine schnelle kNN-Suche im Feld text_embed im Index peaks_catalog durch. Wir behalten die obersten 3-4 Spitzen bei und ignorieren den Rest.
Wir berechnen das Feld _id , indem wir einen Hashwert aus Bildname und Pfad erstellen. Dadurch wird sichergestellt, dass nach mehreren Durchläufen keine Duplikate entstehen.

Sobald alle Felder für das Foto ermittelt wurden, werden die Fotodokumente mithilfe der Massenindizierung stapelweise indexiert:

def bulk_index_photos( es: Elasticsearch, images_root: str, photos_index: str = "photos", peaks_index: str = "peaks_catalog", topk_predicted: int = 5, batch_size: int = 200, refresh: str = "false", ) -> None: """Walk a folder of images, embed + enrich, and bulk index to Elasticsearch.""" root = Path(images_root) if not root.exists(): raise SystemExit(f"Images root not found: {images_root}") emb = Siglip2() batch: List[Dict[str, Any]] = [] n_indexed = 0 for p in iter_images(root): rel = relpath_within(root, p) _id = id_for_path(rel) # 1) Image embedding (and reuse it for predicted_peaks) try: with Image.open(p) as im: ivec = emb.image_vec(im.convert("RGB")).astype("float32") except (UnidentifiedImageError, OSError) as e: print(f"[skip] {rel} — cannot embed: {e}") continue # 2) Predict top-k peak names try: top_names = predict_peaks(es, ivec.tolist(), peaks_index=peaks_index, k=topk_predicted) except Exception as e: print(f"[warn] predict_peaks failed for {rel}: {e}") top_names = [] # 3) EXIF enrichment (safe) gps = get_gps_decimal(str(p)) shot = get_shot_time(str(p)) # 4) Build doc and stage for bulk doc = {"path": rel, "clip_image": ivec.tolist(), "predicted_peaks": top_names} if gps: doc["gps"] = gps if shot: doc["shot_time"] = shot batch.append( {"_op_type": "index", "_index": photos_index, "_id": _id, "_source": doc} ) # 5) Periodic flush if len(batch) >= batch_size: helpers.bulk(es, batch, refresh=refresh) n_indexed += len(batch) print(f"[photos] indexed {n_indexed} (last: {rel})") batch.clear() # Final flush if batch: helpers.bulk(es, batch, refresh=refresh) n_indexed += len(batch) print(f"[photos] indexed {n_indexed} total.") print("[done] photos indexing")

Beispieldokument aus dem Fotoindex:

Zusammenfassend lässt sich sagen, dass der Fotoindex ein schneller, filterbarer und kNN-fähiger Speicher aller Fotos im Album ist. Die Kartierung ist bewusst minimalistisch gehalten – gerade so strukturiert, dass die Ergebnisse schnell abgerufen, übersichtlich dargestellt und nach Raum und Zeit unterteilt werden können. Dieser Index dient beiden Suchanwendungsfällen. Das Python-Skript zur Erstellung beider Indizes finden Sie hier.

Die untenstehende Visualisierung der Kibana-Karten zeigt Dokumente aus dem Fotoalbum als grüne Punkte und Berggipfel ab dem Index peaks_catalog als rote Dreiecke an, wobei die grünen Punkte gut mit dem Wanderweg zum Everest-Basislager übereinstimmen.

Suchanwendungsfälle

Namenssuche (Text-zu-Bild): Mit dieser Funktion können Benutzer mithilfe von Textanfragen Fotos von Berggipfeln (und sogar abstrakten Konzepten wie „Gebetsfahnen“) finden. Um dies zu erreichen, wird die Texteingabe mithilfe von SigLIP-2 in einen Textvektor umgewandelt . Für eine robuste Textvektorgenerierung verwenden wir die gleiche Strategie wie für die Erstellung von Text-Embeddings im peaks_catalog -Index: Kombination der Texteingabe mit einem kleinen Prompt-Ensemble, Subtraktion eines minor Anti-Concept-Vektors und Anwendung der L2-Normalisierung zur Erzeugung des endgültigen Abfragevektors. Anschließend wird eine kNN- Abfrage auf dem Feld photos.clip_image ausgeführt, um die am besten übereinstimmenden Peaks auf Basis der Kosinusähnlichkeit zu ermitteln und so die ähnlichsten Bilder zu finden. Optional können die Suchergebnisse relevanter gestaltet werden, indem Geo- und Datumsfilter und/oder ein photos.predicted_peaks -Termfilter als Teil der Abfrage angewendet werden (siehe Abfragebeispiele unten). Dadurch werden ähnlich aussehende Gipfel ausgeschlossen, die auf der Wanderung gar nicht sichtbar sind.

Elasticsearch-Abfrage mit Geofilter:

POST photos/_search { "knn": { "field": "clip_image", "query_vector": [ ... ], "k": 60, "num_candidates": 2000 }, "query": { "bool": { "filter": [ { "geo_bounding_box": { "gps": { "top_left": "...", "bottom_right": "..." } } } ] } }, "_source": ["path","predicted_peaks","gps","shot_time"] } Response (first two documents): { "hits": { "total": { "value": 56, "relation": "eq" }, "max_score": 0.5779596, "hits": [ { "_index": "photos", "_id": "d01da3a1141981486c3493f6053c79e92a788463", "_score": 0.5779596, "_source": { "path": "IMG_2738.HEIC", "predicted_peaks": [ "Pumori", "Kyajo Ri", "Khumbila", "Nangkartshang", "Kongde Ri" ], "gps": { "lat": 27.97116388888889, "lon": 86.82331111111111 }, "shot_time": "2023-11-03T08:07:13" } }, { "_index": "photos", "_id": "c79d251f07adc5efaedc53561110a7fd78e23914", "_score": 0.5766071, "_source": { "path": "IMG_2761.HEIC", "predicted_peaks": [ "Kyajo Ri", "Makalu", "Baruntse", "Cho Oyu", "Khumbila" ], "gps": { "lat": 27.975558333333332, "lon": 86.82515 }, "shot_time": "2023-11-03T08:51:08" } } }

Bildsuche (Bild-zu-Bild): Mit dieser Funktion können wir einen Berg auf einem Bild identifizieren und weitere Bilder desselben Berges innerhalb des Fotoalbums finden. Beim Hochladen eines Bildes wird dieses vom SigLIP-2-Bildcodierer verarbeitet, um einen Bildvektor zu erzeugen. Anschließend wird eine kNN-Suche im Feld peaks_catalog.text_embed durchgeführt, um die am besten passenden Peaknamen zu identifizieren. Anschließend wird aus diesen übereinstimmenden Peaknamen ein Textvektor generiert und eine weitere kNN-Suche im Fotoindex durchgeführt, um entsprechende Bilder zu finden.

Elasticsearch-Abfrage:

Schritt 1: Finde die passenden Peaknamen

GET peaks_catalog/_search { "knn": { "field": "text_embed", "query_vector": [...image-vector... ], "k": 3, "num_candidates": 500 }, "_source": [ "id", "names", "latlon", "text_embed" ] } Response (first two documents): { "took": 2, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 3, "relation": "eq" }, "max_score": 0.58039916, "hits": [ { "_index": "peaks_catalog", "_id": "pumori", "_score": 0.58039916, "_source": { "id": "pumori", "names": [ "Pumori", "Pumo Ri" ], "latlon": { "lat": 28.01472, "lon": 86.82806 }, "text_embed": [ ... embeddings... ] } }, { "_index": "peaks_catalog", "_id": "kyajo-ri", "_score": 0.57942784, "_source": { "id": "kyajo-ri", "names": [ "Kyajo Ri", "Kyazo Ri" ], "latlon": { "lat": 27.909167, "lon": 86.673611 }, "text_embed": [ ... embeddings... ] } } ] } }

Schritt 2: Führen Sie eine Suche im Index photos durch, um die passenden Bilder zu finden (dieselbe Abfrage wie im Anwendungsfall der Text-zu-Bild-Suche):

POST photos/_search { "knn": { "field": "clip_image", "query_vector": [ ...image-vector... ], "k": 30, "num_candidates": 2000 }, "_source": [ "path", "gps", "shot_time", "predicted_peaks", "clip_image" ], "query": { "bool": { "filter": [ { "term": { "predicted_peaks": "Pumori" } } ] } } } Response (first two documents): { "hits": { "total": { "value": 56, "relation": "eq" }, "max_score": 0.5779596, "hits": [ { "_index": "photos", "_id": "d01da3a1141981486c3493f6053c79e92a788463", "_score": 0.5779596, "_source": { "path": "IMG_2738.HEIC", "predicted_peaks": [ "Pumori", "Kyajo Ri", "Khumbila", "Nangkartshang", "Kongde Ri" ], "gps": { "lat": 27.97116388888889, "lon": 86.82331111111111 }, "shot_time": "2023-11-03T08:07:13" } }, { "_index": "photos", "_id": "c79d251f07adc5efaedc53561110a7fd78e23914", "_score": 0.5766071, "_source": { "path": "IMG_2761.HEIC", "predicted_peaks": [ "Kyajo Ri", "Makalu", "Baruntse", "Cho Oyu", "Khumbila" ], "gps": { "lat": 27.975558333333332, "lon": 86.82515 }, "shot_time": "2023-11-03T08:51:08" } } }

Streamlit-Benutzeroberfläche

Um alles zusammenzuführen, haben wir eine einfache Streamlit-Benutzeroberfläche entwickelt, die es uns ermöglicht, beide Suchanwendungsfälle durchzuführen. In der linken Spalte wird eine scrollbare Liste von Gipfeln (aggregiert aus photos.predicted_peaks) mit Kontrollkästchen und einem Mini-Karten-/Geofilter angezeigt. Ganz oben befinden sich ein Suchfeld für den Namen und eine Schaltfläche zum Hochladen eines Fotos zur Identifizierung . Im mittleren Bereich befindet sich ein responsives Miniaturraster mit kNN-Werten, vorhergesagten Spitzenwerten und Erfassungszeiten. Jedes Bild enthält eine Schaltfläche „Bild anzeigen“ für Vorschauen in voller Auflösung.

Suche durch Hochladen eines Bildes: Wir prognostizieren den Peak und finden übereinstimmende Peaks aus dem Fotoalbum.

Suche nach Text: Finde die passenden Höhepunkte im Album anhand des Textes

Fazit

Was mit der Frage begann: Können wir bitte die Bildervon Ama Dablamsehen? entwickelte sich zu einem kleinen, funktionierenden multimodalen Suchsystem . Wir haben Rohdaten von Trekkingfotos aufgenommen, diese in SigLIP-2-Einbettungen umgewandelt und Elasticsearch verwendet, um ein schnelles kNN über Vektoren durchzuführen, sowie einfache Geo-/Zeitfilter, um die richtigen Bilder anhand ihrer Bedeutung anzuzeigen. Dabei haben wir die Belange mithilfe zweier Indizes getrennt: einem winzigen peaks_catalog Index von kombinierten Prototypen (zur Identifizierung) und einem skalierbaren photos Index von Bildvektoren und EXIF-Daten (zum Abruf). Es ist praktisch, reproduzierbar und leicht erweiterbar.

Falls Sie es feinabstimmen möchten, gibt es einige Einstellungen, mit denen Sie experimentieren können:

Einstellungen für die Abfragezeit: k (wie viele Nachbarn Sie zurückbekommen möchten) und num_candidates (wie breit die Suche vor der endgültigen Bewertung sein soll). Diese Einstellungen werden hier im Blog besprochen.
Indexzeiteinstellungen: m (Graphkonnektivität) und ef_construction (Genauigkeit der Build-Zeit vs. Speicher). Experimentieren Sie bei Abfragen auch mit ef_search – ein höherer Wert bedeutet in der Regel eine bessere Trefferquote, allerdings mit einem gewissen Nachteil bei der Latenz. Weitere Einzelheiten zu diesen Einstellungen finden Sie in diesem Blog .

Zukünftig werden native Modelle/Reranker für multimodale und mehrsprachige Suche in Kürze im Elastic-Ökosystem verfügbar sein. Dies dürfte die Bild-/Textsuche und das hybride Ranking von Haus aus noch weiter verbessern. ir.elastic.co+1

Wenn Sie das selbst ausprobieren möchten:

GitHub-Repository: https://github.com/navneet83/multimodal-mountain-peak-search
Colab-Schnellstartanleitung: https://github.com/navneet83/multimodal-mountain-peak-search/blob/main/notebooks/multimodal_mountain_peak_search.ipynb

Damit ist unsere Reise zu Ende, und es ist Zeit, zurückzufliegen. Ich hoffe, das war hilfreich, und falls etwas kaputtgeht (oder verbessert wird), würde ich gerne erfahren, was Sie geändert haben.

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.

Geodaten-Suche mit Elasticsearch und ES|QL

Craig Taverner — Mon, 12 Aug 2024 00:00:00 GMT

Elasticsearch verfügt seit vielen Jahren über leistungsstarke Funktionen für die Geodaten-Suche und -Analyse , aber die API unterschied sich deutlich von dem, was typische GIS-Anwender gewohnt waren. Im vergangenen Jahr haben wir die Abfragesprache ES|QL hinzugefügt, eine Pipe-Abfragesprache, die genauso einfach oder sogar noch einfacher als SQL ist. Es eignet sich besonders für die Anwendungsfälle Suche, Sicherheit und Beobachtbarkeit, in denen Elastic hervorragende Leistungen erbringt. Wir fügen außerdem Unterstützung für die Geodaten-Suche und -Analyse innerhalb von ES|QL hinzu, was die Nutzung deutlich vereinfacht, insbesondere für Anwender aus SQL- oder GIS- Bereichen.

Elasticsearch 8.12 und 8.13 führten die grundlegende Unterstützung für Geodaten-Typen in ES|QL ein. Dies wurde durch die Hinzufügung von Geodaten-Suchfunktionen in Version 8.14 deutlich verbessert. Wichtiger noch: Diese Unterstützung wurde so konzipiert, dass sie sich eng an den Simple Feature Access- Standard des Open Geospatial Consortium (OGC) anlehnt, der auch von anderen räumlichen Datenbanken wie PostGIS verwendet wird. Dadurch wird die Nutzung für GIS-Experten, die mit diesen Standards vertraut sind, deutlich vereinfacht.

In diesem Blog zeigen wir Ihnen, wie Sie mit ES|QL Geodatenabfragen durchführen und wie sich dies im Vergleich zu den entsprechenden SQL- und Query-DSL-Funktionen verhält. Wir zeigen Ihnen außerdem, wie Sie mit ES|QL räumliche Verknüpfungen durchführen und wie Sie die Ergebnisse in Kibana Maps visualisieren. Bitte beachten Sie, dass sich alle hier beschriebenen Funktionen in der „technischen Vorschau“ befinden. Wir freuen uns über Ihr Feedback, wie wir diese verbessern können.

Suche nach Geodaten

Beginnen wir mit einer Beispielabfrage:

FROM airport_city_boundaries | WHERE ST_INTERSECTS( city_boundary, "POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))"::geo_shape ) | KEEP abbrev, airport, region, city, city_location

Hierbei wird nach Stadtgrenzenpolygonen gesucht, die sich mit einem rechteckigen Suchpolygon um den internationalen Flughafen Sanya Phoenix (SYX) schneiden.

In einem Beispieldatensatz mit Flughäfen, Städten und Stadtgrenzen findet diese Suche das sich überschneidende Polygon und gibt die gewünschten Felder aus dem übereinstimmenden Dokument zurück:

Abkürzung

Flughafen

Region

Stadt

Stadtstandort

SYX

Sanya Phoenix Int'l

天涯区

Sanya

Punkt(109.5036 18.2533)

Das war einfach! Vergleichen Sie dies nun mit der klassischen Elasticsearch Query DSL für dieselbe Abfrage:

GET /airport_city_boundaries/_search { "_source": ["abbrev", "airport", "region", "city", "city_location"], "query": { "geo_shape": { "city_boundary": { "shape": { "type": "polygon", "coordinates" : [[ [109.4, 18.1], [109.6, 18.1], [109.6, 18.3], [109.4, 18.3], [109.4, 18.1] ]] } } } } }

Beide Abfragen sind in ihrer Absicht einigermaßen klar, aber die ES|QL-Abfrage ähnelt stark SQL. Die gleiche Abfrage in PostGIS sieht folgendermaßen aus:

SELECT abbrev, airport, region, city, city_location FROM airport_city_boundaries WHERE ST_INTERSECTS( city_boundary, 'SRID=4326;POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'::geometry );

Schauen Sie sich das ES|QL-Beispiel noch einmal an. So ähnlich, nicht wahr?

Wir haben festgestellt, dass bestehende Benutzer der Elasticsearch API ES|QL als wesentlich einfacher zu bedienen empfinden. Wir gehen davon aus, dass bestehende SQL-Anwender, insbesondere Spatial SQL-Anwender, feststellen werden, dass sich ES|QL sehr vertraut anfühlt und ihnen sehr ähnlich ist.

Warum nicht SQL?

Und wie sieht es mit Elasticsearch SQL aus? Es existiert schon eine Weile und verfügt über einige Geodatenfunktionen. Elasticsearch SQL wurde jedoch als Wrapper für die ursprüngliche Query-API geschrieben, was bedeutete, dass nur Abfragen unterstützt wurden, die in die ursprüngliche API transpiliert werden konnten. ES|QL hat diese Einschränkung nicht. Da es sich um einen völlig neuen Stack handelt, sind viele Optimierungen möglich, die in SQL nicht möglich waren. Unsere Benchmarks zeigen, dass ES|QL sehr oft schneller ist als die Query API, insbesondere bei Aggregationen!

Unterschiede zu SQL

Wie das vorherige Beispiel zeigt, ist ES|QL SQL zwar in gewisser Weise ähnlich, es gibt aber auch einige wichtige Unterschiede. ES|QL ist beispielsweise eine Pipe-Abfragesprache, die mit einem Quellbefehl wie FROM beginnt und dann alle nachfolgenden Befehle mit dem Pipe-Zeichen | miteinander verkettet. Dadurch wird es sehr einfach verständlich, wie jeder Befehl eine Datentabelle empfängt und eine bestimmte Aktion an dieser Tabelle durchführt, z. B. Filtern mit WHERE, Hinzufügen von Spalten mit EVAL oder Durchführen von Aggregationen mit STATS. Anstatt mit SELECT zu beginnen, um die endgültigen Ausgabespalten zu definieren, können ein oder mehrere KEEP -Befehle verwendet werden, wobei der letzte Befehl die endgültigen Ausgaberesultate angibt. Diese Struktur vereinfacht die Argumentation bezüglich der Anfrage.

Wenn wir uns den Befehl WHERE im obigen Beispiel genauer ansehen, erkennen wir, dass er dem PostGIS-Beispiel sehr ähnlich sieht:

ES|QL

WHERE ST_INTERSECTS( city_boundary, "POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))"::geo_shape )

PostGIS

WHERE ST_INTERSECTS( city_boundary, 'SRID=4326;POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'::geometry )

Abgesehen von den Unterschieden bei den Anführungszeichen für Zeichenketten besteht der größte Unterschied darin, wie wir die Zeichenkette in einen räumlichen Datentyp umwandeln. In PostGIS verwenden wir das Suffix ::geometry , während wir in ES|QL das Suffix ::geo_shape verwenden. Dies liegt daran, dass ES|QL innerhalb von Elasticsearch ausgeführt wird und der Typumwandlungsoperator :: verwendet werden kann, um eine Zeichenkette in einen der unterstützten ES|QL-Typen umzuwandeln, in diesem Fall in einen geo_shape. Darüber hinaus implizieren die Typen geo_shape und geo_point in Elasticsearch das räumliche Koordinatensystem WGS84, das häufiger unter der SRID-Nummer 4326 bezeichnet wird. In PostGIS muss dies explizit angegeben werden, daher die Verwendung des Präfixes SRID=4326; für die WKT-Zeichenkette. Wird dieses Präfix entfernt, wird die SRID auf 0 gesetzt, was eher den Elasticsearch-Typen cartesian_point und cartesian_shape entspricht, die nicht an ein bestimmtes Koordinatensystem gebunden sind.

Sowohl ES|QL als auch PostGIS bieten eine Syntax für Typkonvertierungsfunktionen:

ES|QL

WHERE ST_INTERSECTS( city_boundary, TO_GEOSHAPE("POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))") )

PostGIS

WHERE ST_INTERSECTS( city_boundary, ST_SetSRID( ST_GeomFromText('POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'), 4326 ) )

OGC-Funktionen

Elasticsearch 8.14 führt die folgenden vier OGC-Funktionen für die räumliche Suche ein:

ES|QL

PostGIS

Beschreibung

ST_INTERSECTS

ST_Schnittpunkte

Gibt true zurück, wenn sich zwei Geometrien schneiden, und andernfalls false.

ST_DISJOINT

ST_Disjoint

Gibt true zurück, wenn sich zwei Geometrien nicht schneiden, und andernfalls false. Die Umkehrfunktion von ST_INTERSECTS.

ST_CONTAINS

ST_Contains

Gibt true zurück, wenn eine Geometrie eine andere enthält, andernfalls false.

ST_WITHIN

ST_Within

Gibt true zurück, wenn sich eine Geometrie innerhalb einer anderen befindet, und andernfalls false. Das Inverse von ST_CONTAINS.

Diese Funktionen verhalten sich ähnlich wie ihre PostGIS-Pendants und werden auf die gleiche Weise verwendet. Beispielsweise gibt ST_INTERSECTS true zurück, wenn sich zwei Geometrien schneiden, und andernfalls false. Wenn Sie den Dokumentationslinks in der obigen Tabelle folgen, werden Sie feststellen, dass sich alle ES|QL-Beispiele innerhalb einer WHERE -Klausel nach einer FROM -Klausel befinden, während alle PostGIS-Beispiele literale Geometrien verwenden. Tatsächlich unterstützen beide Plattformen die Verwendung der Funktionen in jedem Teil der Abfrage, in dem sie sinnvoll sind.

Das erste Beispiel in der PostGIS-Dokumentation für ST_INTERSECTS lautet:

SELECT ST_Intersects( 'POINT(0 0)'::geometry, 'LINESTRING ( 2 0, 0 2 )'::geometry );

Das ES|QL-Äquivalent dazu wäre:

ROW ST_INTERSECTS( "POINT(0 0)"::geo_point, "LINESTRING ( 2 0, 0 2 )"::geo_shape )

Beachten Sie, dass wir im PostGIS-Beispiel die SRID nicht angegeben haben. Dies liegt daran, dass in PostGIS bei Verwendung des Typs geometry alle Berechnungen auf einem planaren Koordinatensystem durchgeführt werden. Wenn also beide Geometrien die gleiche SRID haben, spielt es keine Rolle, welche SRID es ist. In Elasticsearch gilt dies auch für die meisten Funktionen. Es gibt jedoch Ausnahmen, bei denen geo_shape und geo_point sphärische Berechnungen verwenden, wie wir im nächsten Blogbeitrag über die Suche nach räumlichen Distanzen sehen werden.

ES|QL Vielseitigkeit

Wir haben oben also Beispiele für die Verwendung von räumlichen Funktionen in WHERE -Klauseln und in ROW -Befehlen gesehen. Wo sonst würden sie Sinn machen? Eine sehr nützliche Stelle dafür ist der Befehl EVAL . Mit diesem Befehl können Sie einen Ausdruck auswerten und das Ergebnis zurückgeben. Nehmen wir beispielsweise an, wir wollen feststellen, ob die Schwerpunkte aller Flughäfen, gruppiert nach ihren Ländernamen, innerhalb einer Grenze liegen, die das jeweilige Land umschließt:

FROM airports | EVAL in_uk = ST_INTERSECTS(location, TO_GEOSHAPE("POLYGON((1.2305 60.8449, -1.582 61.6899, -10.7227 58.4017, -7.1191 55.3291, -7.9102 54.2139, -5.4492 54.0078, -5.2734 52.3756, -7.8223 49.6676, -5.0977 49.2678, 0.9668 50.5134, 2.5488 52.1065, 2.6367 54.0078, -0.9668 56.4625, 1.2305 60.8449))")) | EVAL in_iceland = ST_INTERSECTS(location, TO_GEOSHAPE("POLYGON ((-25.4883 65.5312, -23.4668 66.7746, -18.4131 67.4749, -13.0957 66.2669, -12.3926 64.4159, -20.1270 62.7346, -24.7852 63.3718, -25.4883 65.5312))")) | EVAL within_uk = ST_WITHIN(location, TO_GEOSHAPE("POLYGON((1.2305 60.8449, -1.582 61.6899, -10.7227 58.4017, -7.1191 55.3291, -7.9102 54.2139, -5.4492 54.0078, -5.2734 52.3756, -7.8223 49.6676, -5.0977 49.2678, 0.9668 50.5134, 2.5488 52.1065, 2.6367 54.0078, -0.9668 56.4625, 1.2305 60.8449))")) | EVAL within_iceland = ST_WITHIN(location, TO_GEOSHAPE("POLYGON ((-25.4883 65.5312, -23.4668 66.7746, -18.4131 67.4749, -13.0957 66.2669, -12.3926 64.4159, -20.1270 62.7346, -24.7852 63.3718, -25.4883 65.5312))")) | STATS centroid = ST_CENTROID_AGG(location), count=COUNT() BY in_uk, in_iceland, within_uk, within_iceland | SORT count ASC

Die Ergebnisse sind erwartungsgemäß: Die Schwerpunkte der britischen Flughäfen liegen innerhalb der Grenzen Großbritanniens und nicht innerhalb der Grenzen Islands, und umgekehrt.

Schwerpunkt

Anzahl

in_uk

in Island

innerhalb Großbritanniens

innerhalb Islands

PUNKT (-21,946634463965893 64.13187285885215)

FALSCH

wahr

FALSCH

wahr

PUNKT (-2,597342072712148 54,33551226578214)

wahr

FALSCH

wahr

FALSCH

PUNKT (0,04453958108176276 23,74658354606057)

873

FALSCH

Tatsächlich können diese Funktionen in jedem Teil der Abfrage verwendet werden, in dem ihre Signatur sinnvoll ist. Sie alle nehmen zwei Argumente entgegen, die entweder ein Literal eines räumlichen Objekts oder ein Feld eines räumlichen Typs sind, und sie alle geben einen booleschen Wert zurück. Eine wichtige Überlegung ist, dass das Koordinatenreferenzsystem (CRS) der Geometrien übereinstimmen muss, andernfalls wird ein Fehler zurückgegeben. Das bedeutet, dass Sie die Typen geo_shape und cartesian_shape nicht im selben Funktionsaufruf mischen können. Allerdings können Sie die Typen geo_point und geo_shape mischen, da der Typ geo_point ein Sonderfall des Typs geo_shape ist und beide das gleiche Koordinatenreferenzsystem verwenden. Die Dokumentation zu jeder der oben definierten Funktionen listet die unterstützten Typkombinationen auf.

Darüber hinaus kann jedes Argument ein räumliches Literal oder ein Feld sein, in beliebiger Reihenfolge. Sie können sogar zwei Felder, zwei Literale, ein Feld und ein Literal oder ein Literal und ein Feld angeben. Die einzige Voraussetzung ist, dass die Datentypen kompatibel sind. Diese Abfrage vergleicht beispielsweise zwei Felder im selben Index:

Die Anfrage zielt im Grunde darauf ab, ob sich der Ort innerhalb der Stadtgrenzen befindet, was im Allgemeinen zutreffen sollte, aber es gibt immer Ausnahmen:

Kardinalität

Anzahl

in_city

wenige

FALSCH

viele

740

wahr

Eine weitaus interessantere Frage wäre, ob sich der Flughafenstandort innerhalb der Grenzen der Stadt befindet, die der Flughafen bedient. Der Standort des Flughafens befindet sich jedoch in einem anderen Index als derjenige, der die Stadtgrenzen enthält. Dies erfordert eine Methode, um Daten aus diesen beiden separaten Indizes effektiv abzufragen und zu korrelieren.

Räumliche Verknüpfungen

ES|QL unterstützt keine JOIN -Befehle, aber Sie können einen Sonderfall eines Joins mit dem ENRICH -Befehl erreichen, der sich ähnlich wie ein 'left join' in SQL verhält. Dieser Befehl funktioniert ähnlich wie ein „Left Join“ in SQL und ermöglicht es Ihnen, Ergebnisse aus einem Index mit Daten aus einem anderen Index anzureichern, basierend auf einer räumlichen Beziehung zwischen den beiden Datensätzen.

Nehmen wir beispielsweise an, wir reichern die Ergebnisse einer Tabelle mit Flughäfen um zusätzliche Informationen über die jeweilige Stadt an, indem wir die Stadtgrenze ermitteln, die den Flughafenstandort enthält, und führen dann einige statistische Auswertungen der Ergebnisse durch:

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary | MV_EXPAND city_boundary | EVAL boundary_wkt_length = LENGTH(TO_STRING(city_boundary)) | STATS centroid = ST_CENTROID_AGG(location), count = COUNT(city_location), min_wkt = MIN(boundary_wkt_length), max_wkt = MAX(boundary_wkt_length) BY region | SORT count DESC | LIMIT 5

Dies liefert die Top 5 Regionen mit den meisten Flughäfen, zusammen mit dem Schwerpunkt aller Flughäfen, die übereinstimmenden Regionen zugeordnet sind, und der Längenspanne der WKT-Darstellung der Stadtgrenzen innerhalb dieser Regionen:

Schwerpunkt

Anzahl

min_wkt

max_wkt

Region

PUNKT (-32.56093470960719 32.598117914802714)

207

null

PUNKT (-73.94515332765877 40.70366442203522)

438

Stadt New York

PUNKT (-83.10398317873478 42.300230911932886)

473

Detroit

PUNKT (-156.3020245861262 20.176383580081165)

307

803

Hawaii

PUNKT (-73.88902732171118 45.57078813901171)

837

Montréal

Was ist hier also wirklich geschehen? Wo trat das vermeintliche JOIN auf? Der Kern der Anfrage liegt im Befehl ENRICH :

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary

Dieser Befehl weist Elasticsearch an, die aus dem Index airports abgerufenen Ergebnisse anzureichern und einen Join intersects zwischen dem Feld city_location des ursprünglichen Index und dem Feld city_boundary des Index airport_city_boundaries durchzuführen, den wir bereits in einigen Beispielen verwendet haben. Einige dieser Informationen sind in dieser Abfrage jedoch nicht klar ersichtlich. Was wir sehen, ist der Name einer Anreicherungsrichtlinie city_boundaries, und die fehlenden Informationen sind in dieser Richtliniendefinition enthalten.

{ "geo_match": { "indices": "airport_city_boundaries", "match_field": "city_boundary", "enrich_fields": ["city", "airport", "region", "city_boundary"] } }

Hier sehen wir, dass eine geo_match -Abfrage durchgeführt wird (intersects ist der Standardwert), das Feld, mit dem abgeglichen werden soll, ist city_boundary, und die enrich_fields sind die Felder, die wir dem Originaldokument hinzufügen möchten. Eines dieser Felder, nämlich region wurde tatsächlich als Gruppierungsschlüssel für den Befehl STATS verwendet, was ohne diese 'left join'-Funktion nicht möglich gewesen wäre. Weitere Informationen zu Anreicherungsrichtlinien finden Sie in der Anreicherungsdokumentation. Beim Lesen dieser Dokumente werden Sie feststellen, dass darin die Verwendung von Anreicherungsindizes zur Anreicherung von Daten während der Indexierung durch die Konfiguration von Aufnahmepipelines beschrieben wird. Dies ist für ES|QL nicht erforderlich, da der Befehl ENRICH zur Abfragezeit funktioniert. Es genügt, den Anreicherungsindex mit den erforderlichen Daten und der Anreicherungsrichtlinie vorzubereiten und dann den Befehl ENRICH in Ihren ES|QL-Abfragen zu verwenden.

Möglicherweise stellen Sie auch fest, dass die am häufigsten vorkommende Region null war. Was könnte das bedeuten? Zur Erinnerung: Ich habe diesen Befehl mit einem 'Left Join' in SQL verglichen. Das bedeutet, dass, wenn keine übereinstimmende Stadtgrenze für einen Flughafen gefunden wird, der Flughafen trotzdem zurückgegeben wird, jedoch mit null Werten für die Felder ab dem airport_city_boundaries Index. Es stellte sich heraus, dass es 89 Flughäfen gab, bei denen kein passender Eintrag city_boundary gefunden wurde, und einen Flughafen mit einer Übereinstimmung, bei dem das Feld region den null hatte. Dies führte zu einer Zählung von 90 Flughäfen, bei denen keine region in den Ergebnissen vorkam. Ein weiteres interessantes Detail ist die Notwendigkeit des Befehls MV_EXPAND . Dies ist notwendig, da der Befehl ENRICH für jede Eingabezeile mehrere Ergebnisse zurückgeben kann, und MV_EXPAND hilft dabei, diese Ergebnisse in mehrere Zeilen aufzuteilen, eine für jedes Ergebnis. Dies erklärt auch, warum für "Hawaii" unterschiedliche min_wkt und max_wkt Ergebnisse angezeigt werden: Es gab mehrere Regionen mit dem gleichen Namen, aber unterschiedlichen Grenzen.

Kibana-Karten

Kibana hat die Unterstützung für Spatial ES|QL in der Kartenanwendung hinzugefügt. Das bedeutet, dass Sie nun ES|QL verwenden können, um in Elasticsearch nach Geodaten zu suchen und die Ergebnisse auf einer Karte zu visualisieren.

Im Menü „Ebenen hinzufügen“ gibt es eine neue Ebenenoption mit der Bezeichnung „ES|QL“. Wie alle bisher beschriebenen Geodatenfunktionen befindet sich auch diese in der „technischen Vorschauphase“. Durch Auswahl dieser Option können Sie der Karte eine Ebene hinzufügen, die auf den Ergebnissen einer ES|QL-Abfrage basiert. Man könnte beispielsweise eine Ebene zur Karte hinzufügen, die alle Flughäfen der Welt anzeigt.

Oder Sie könnten eine Ebene hinzufügen, die die Polygone ab dem Index airport_city_boundaries anzeigt, oder noch besser, wie wäre es mit der komplexen ENRICH -Abfrage oben, die Statistiken darüber generiert, wie viele Flughäfen sich in jeder Region befinden?

Was kommt als Nächstes?

Vielleicht ist Ihnen aufgefallen, dass wir in zwei der obigen Beispiele noch eine weitere räumliche Funktion ST_CENTROID_AGG eingefügt haben. Dies ist eine Aggregationsfunktion, die im Befehl STATS verwendet wird, und die erste von vielen räumlichen Analysefunktionen, die wir ES|QL hinzufügen wollen. Wir werden darüber bloggen, sobald wir mehr zu zeigen haben!

Zuvor möchten wir Ihnen jedoch ein besonders spannendes Feature vorstellen, an dem wir gearbeitet haben: die Möglichkeit, räumliche Distanzsuchen durchzuführen – eine der am häufigsten genutzten räumlichen Suchfunktionen von Elasticsearch. Können Sie sich vorstellen, wie die Syntax für Distanzsuchen aussehen könnte? Vielleicht ähnlich einer OGC-Funktion? Bleiben Sie dran für den nächsten Blogbeitrag dieser Reihe, um es herauszufinden!

Spoiler-Alarm: Elasticsearch 8.15 wurde soeben veröffentlicht und beinhaltet die räumliche Distanzsuche mit ES|QL!

Bewertung der Suchrelevanz Teil 1 – Der BEIR-Benchmark

Thanos Papaoikonomou,Thomas Veasey — Tue, 16 Jul 2024 00:00:00 GMT

Dies ist der erste Beitrag einer Reihe von Blogbeiträgen, in denen wir uns damit befassen, wie Sie Ihre eigenen Suchsysteme im Zusammenhang mit einem besseren Verständnis des BEIR-Benchmarks bewerten können. Wir stellen Ihnen spezielle Tipps und Techniken vor, mit denen Sie Ihre Suchbewertungsprozesse im Zusammenhang mit dem besseren Verständnis von BEIR verbessern können. Wir stellen Ihnen auch die häufigsten Fallstricke vor, die eine Bewertung weniger zuverlässig machen. Abschließend möchten wir darauf hinweisen, dass LLMs ein leistungsstarkes neues Tool für Suchingenieure darstellen. Anhand eines Beispiels zeigen wir, wie Sie diese zur Bewertung der Suche einsetzen können.

Den BEIR-Benchmark bei der Bewertung der Suchrelevanz verstehen

Für die Verbesserung eines Systems müssen Sie messen können, wie gut es funktioniert. Im Zusammenhang mit der Suche BEIR (oder gleichwertig der Abschnitt „Retrieval” der Bestenliste MTEB) gilt als der „heilige Gral” für die Informationsabruf-Community, was nicht weiter verwunderlich ist. Es handelt sich um einen sehr gut strukturierten Benchmark mit vielfältigen Datensätzen für unterschiedliche Aufgaben. Genauer gesagt werden folgende Bereiche abgedeckt:

Abrufen von Argumenten (ArguAna, Touche2020)
Open-Domain-QA (HotpotQA, Natural Questions, FiQA)
Passagenabruf (MSMARCO)
Abrufen doppelter Fragen (Quora, CQADupstack)
Faktenprüfung (FEVER, Climate-FEVER, Scifact)
Biomedizinische Informationsabfrage (TREC-COVID, NFCorpus, BioASQ)
Abrufen von Entitäten (DBPedia)
Zitationsvorhersage (SCIDOCS)

Es liefert eine einzige Statistik, nDCG@10, die angibt, wie gut ein System die relevantesten Dokumente für jedes Aufgabenbeispiel in den von ihm zurückgegebenen besten Ergebnissen abgleicht. Für ein Suchsystem, mit dem ein Mensch interagiert, ist die Relevanz der betsen Ergebnisse entscheidend. Allerdings gibt es bei der Bewertung von Suchvorgängen viele Nuancen, die durch eine einzelne zusammenfassende Statistik nicht erfasst werden.

Struktur eines BEIR-Datensatzes

Jeder Benchmark hat drei Artefakte:

der Korpus oder die Dokumente, die abgerufen werden sollen
Die Abfragen
die Relevanzbewertungen für die Abfragen (auch bekannt als qrels).

Relevanzbewertungen werden als Wert zwischen null und größer angegeben. Werte ungleich Null zeigen an, dass das Dokument in gewisser Weise mit der Abfrage in Zusammenhang steht.

Datensatz

Korpusgröße

#Abfragen im Testset

#qrels positiv gekennzeichnet

#qrels gleich Null

#duplicates im Korpus

Arguana

8.674

1.406

Climate-FEVER

5.416.593

1.535

4.681

DBPedia

4.635.922

400

15.286

28.229

FEVER

5.416.568

6.666

7.937

FiQA-2018

57.638

648

1.706

HotpotQA

5.233.329

7.405

14.810

Natürliche Fragen

2.681.468

3.452

4.021

16.781

NFCorpus

3.633

323

12.334

Quora

522.931

10.000

15.675

1.092

SCIDOCS

25.657

1.000

4.928

25.000

Scifact

5.183

300

339

Touche2020

382.545

932

1.982

5.357

TREC-COVID

171.332

24.763

41.663

MSMARCO

8.841.823

6.980

7.437

324

CQADupstack (Summe)

457.199

13.145

23.703

Tabelle 1: Datensatzstatistiken. Die Zahlen wurden auf dem Testabschnitt der Datensätze berechnet (dev für MSMARCO).

Tabelle 1 enthält einige Statistiken zu den Datensätzen, aus denen der BEIR-Benchmark besteht, wie zum Beispiel die Anzahl der Dokumente im Korpus, die Anzahl der Abfragen im Testdatensatz und die Anzahl der positiven/negativen Paare (Abfrage, Dokument) in der qrels-Datei. Ein kurzer Blick auf die Daten lässt uns sofort Folgendes ableiten:

Die meisten Datensätze enthalten keine negativen Beziehungen in der qrels-Datei, d. h. null Werte, was Dokumente ausdrücklich als irrelevant für die jeweilige Abfrage kennzeichnen würde.
Die durchschnittliche Anzahl von Dokumentbeziehungen pro Abfrage (#qrels / #queries) variiert von 1,0 im Ticket von ArguAna bis 493,5 (TREC-COVID), jedoch mit einem Wert von <5 für die Mehrheit der Tickets.
Bei einigen Datensätzen gibt es doppelte Dokumente im Korpus, was in einigen Fällen zu einer falschen Auswertung führen kann, z. B. wenn ein Dokument als relevant für eine Abfrage angesehen wird, sein Duplikat jedoch nicht. Zum Beispiel haben wir in ArguAna 96 Tickets von doppelten Dokumentpaaren identifiziert, wobei pro Paar nur ein Dokument als relevant für eine Abfrage markiert wurde. Durch die „Erweiterung“ der ursprünglichen Qrels-Liste um die Duplikate haben wir einen relativen Anstieg des nDCG@10-Wertes um durchschnittlich ~1 % festgestellt.

{ "_id": "test-economy-epiasghbf-pro02b", "title": "economic policy international africa society gender house believes feminisation", "text": "Again employment needs to be contextualised with …", "metadata": {} } { "_id": "test-society-epiasghbf-pro02b", "title": "economic policy international africa society gender house believes feminisation", "text": "Again employment needs to be contextualised with …", "metadata": {} }

Beispiel für duplizierte Paare in ArguAna. In der qrels-Datei scheint nur der erste Eintrag (als Gegenargument) für die Abfrage („test-economy-epiasghbf-pro02a“) relevant zu sein.

Beim Vergleich von Modellen in der MTEB-Rangliste ist es naheliegend, sich auf die durchschnittliche Retrieval-Qualität zu konzentrieren. Dies ist ein guter Indikator für die Gesamtqualität des Modells, sagt jedoch nicht unbedingt etwas darüber aus, wie es für Sie funktionieren wird. Da die Ergebnisse pro Datensatz gemeldet werden, ist es sinnvoll zu verstehen, wie eng die verschiedenen Datensätze mit Ihrer Suchaufgabe zusammenhängen, und die Modelle nur anhand der relevantesten Datensätze neu zu bewerten. Wenn Sie noch tiefer eintauchen möchten, können Sie zusätzlich überprüfen, ob es Überschneidungen zwischen den Themen der verschiedenen Datensätze gibt. Die Stratifizierung von Qualitätsmaßen nach Themen ermöglicht eine viel differenziertere Bewertung ihrer spezifischen Stärken und Schwächen.

Wichtig ist hierbei, dass ein Dokument, das nicht in der qrels-Datei markiert ist, standardmäßig als für die Abfrage irrelevant angesehen wird. Wir befassen uns etwas eingehender mit diesem Bereich und sammeln einige Nachweise, um mehr Licht in die folgende Frage zu bringen: „Wie oft werden einem Evaluator Paare (Abfrage, Dokument) vorgelegt, für die es keine Ground-Truth-Informationen gibt?“. Der Grund dafür ist, dass bei nur verfügbaren oberflächlichen Markups (sodass nicht jedes relevante Dokument als solches gekennzeichnet ist) ein Informationsabrufsystem schlechter bewertet werden kann als ein anderes, nur weil es sich dafür „entscheidet“, andere relevante (aber nicht markierte) Dokumente anzuzeigen. Das ist ein häufiger Fehler bei der Erstellung qualitativ hochwertiger Evaluierungsdatensätze, insbesondere bei großen Datensätzen. Aus praktischen Gründen konzentriert sich die manuelle Kennzeichnung in der Regel auf die besten Ergebnisse, die vom aktuellen System zurückgegeben werden, sodass relevante Dokumente in den blinden Flecken möglicherweise übersehen werden. Daher ist es in der Regel vorzuziehen, mehr Ressourcen auf ein umfassenderes Markup weniger Abfragen als auf ein breites, oberflächliches Markup zu konzentrieren.

Nutzung des BEIR-Benchmarks zur Bewertung der Suchrelevanz

Um unsere Analyse zu beginnen, implementieren wir das folgende Szenario (siehe Notizbuch):

Zuerst laden wir den Korpus jedes Datensatzes in einen Elasticsearch-Index.
Für jede Abfrage im Testsatz rufen wir die 100 besten Dokumente mit BM25 ab.
Wir ordnen die abgerufenen Dokumente mithilfe verschiedener SOTA-Reranking-Modelle neu an.
Abschließend geben wir die „Bewertungsrate“ für die 10 besten Dokumente aus Schritt 2 (nach dem Abrufen) und Schritt 3 (nach dem Reranking) an. Mit anderen Worten: Wir berechnen den durchschnittlichen Prozentsatz der 10 besten Dokumente mit einer Bewertung in der qrels-Datei.

Die Liste der von uns verwendeten Reranking-Modelle lautet wie folgt:

Coheres rerank-english-v2.0 und rerank-english-v3.0
BGE-base
mxbai-rerank-xsmall-v1
MiniLM-L-6-v2

Abruf

Reranking

Datensatz

BM25 (%)

Cohere Rerank v2 (%)

Cohere Rerank v3 (%)

BGE-base (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

Arguana

7,54

4,87

7,87

4,52

4,53

6,84

Climate-FEVER

5,75

6,24

8,15

9,36

7,79

7,58

DBPedia

61,18

60,78

64,15

63,9

63,5

67,62

FEVER

8,89

9,97

10,08

10,19

9,88

FiQa-2018

7,02

11,02

10,77

8,43

9,1

9,44

HotpotQA

12,59

14,5

14,76

15,1

14,02

14,42

Natürliche Fragen

5,94

8.84

8,71

8,37

8,14

8,34

NFCorpus

31,67

32,9

33,91

30,63

32,77

32,45

Quora

12,2

10,46

13,04

11,26

12,58

12,78

SCIDOCS

8,62

9,41

9,71

8,04

8,79

8,52

Scifact

9,07

9,57

9,77

9,3

9,1

9,17

Touche2020

38,78

30,41

32,24

33,06

37,96

33,67

TREC-COVID

92,4

98,4

98,2

93,8

99,6

97,4

MSMARCO

3,97

6,00

6,03

6,07

5,47

6,11

CQADupstack (Durchschnitt)

5,47

6,32

6,87

5.89

6,22

6,16

Tabelle 2: Bewertungsrate pro Paare (Datensatz, Reranker), berechnet anhand der 10 am häufigsten abgerufenen/neu geordneten Dokumente

Aus Tabelle 2 sehen wir, mit Ausnahme von TREC-COVID (>90 % Abdeckung), DBPedia (~65 %), Touche2020 und nfcorpus (~35 %), dass die Mehrheit der Datensätze eine Labeling-Rate zwischen 5 % und etwas mehr als 10 % nach dem Abrufen oder Reranking aufweist. Das heißt nicht, dass alle diese unmarkierten Dokumente relevant sind, aber es könnte ein Teilbereich davon geben, insbesondere diejenigen, die an oberster Stelle stehen, die positiv sein könnten.

Mit dem Aufkommen von auf allgemeine Anweisungen abgestimmten Sprachmodellen haben wir ein neues leistungsfähiges Tool, das die Beurteilung der Relevanz potenziell automatisieren kann. Diese Methoden sind in der Regel viel zu rechenaufwändig, um online für die Suche verwendet zu werden, aber hier geht es uns um die Offline-Auswertung. Im Folgenden verwenden wir sie, um die Hinweise darauf zu untersuchen, dass einige der BEIR-Datensätze unter oberflächlichen Markups leiden.

Zur weiteren Untersuchung dieser Hypothese haben wir uns entschlossen, uns auf MSMARCO zu konzentrieren und einen Teilbereich von 100 Abfragen zusammen mit den fünf (mit Cohere v2) höchsten Reranking-Dokumenten auszuwählen, die derzeit nicht als relevant markiert sind. Wir haben zwei verschiedene Bewertungsansätze verfolgt: Zunächst haben wir einen sorgfältig abgestimmten Prompt (mehr dazu in einem späteren Beitrag) verwendet, um das kürzlich veröffentlichte Phi-3-mini-4k-Modell darauf vorzubereiten, die Relevanz (oder Nicht-Relevanz) eines Dokuments für die Abfrage vorherzusagen. Parallel dazu wurden diese Tickets auch manuell gekennzeichnet, um auch die Übereinstimmungsrate zwischen dem LLM-Ausgang und der menschlichen Bewertung zu ermitteln. Insgesamt können wir die folgenden beiden Schlüsse ziehen:

Die Übereinstimmungsrate zwischen den LLM-Reaktionen und den menschlichen Beurteilungen lag bei knapp 80 %, was als Ausgangspunkt in diese Richtung durchaus gut erscheint.
In 57,6 % der Fälle (nach menschlicher Beurteilung) erwiesen sich die zurückgegebenen Dokumente tatsächlich als relevant für die Abfrage. Anders ausgedrückt: Bei 100 Abfragen werden 107 Dokumente als relevant eingestuft, aber es gibt mindestens 0,576 x 5 x 100 = 288 zusätzliche Dokumente, die tatsächlich relevant sind!

Hier einige Beispiele aus dem Datensatz MSMARCO/dev, die die Abfrage, das annotierte positive Dokument (aus qrels) und ein falsch negatives Dokument aufgrund unvollständiger Auszeichnung enthalten:

Beispiel 1:

{ "query": { "_id": 155234, "text": "do bigger tires affect gas mileage" }, "positive_doc": { "_id": 502713, "text": "Tire Width versus Gas Mileage. Tire width is one of the only tire size factors that can influence gas mileage in a positive way. For example, a narrow tire will have less wind resistance, rolling resistance, and weight; thus increasing gas mileage.", }, "negative_doc": { "_id": 7073658, "text": "Tire Size and Width Influences Gas Mileage. There are two things to consider when thinking about tires and their effect on gas mileage; one is wind resistance, and the other is rolling resistance. When a car is driving at higher speeds, it experiences higher wind resistance; this means lower fuel economy." } }

Beispiel 2:

{ "query": { "_id": 300674, "text": "how many years did william bradford serve as governor of plymouth colony?" }, "positive_doc": { "_id": 7067032, "text": "http://en.wikipedia.org/wiki/William_Bradford_(Plymouth_Colony_governor) William Bradford (c.1590 \u00e2\u0080\u0093 1657) was an English Separatist leader in Leiden, Holland and in Plymouth Colony was a signatory to the Mayflower Compact. He served as Plymouth Colony Governor five times covering about thirty years between 1621 and 1657." }, "negative_doc": { "_id": 2495763, "text": "William Bradford was the governor of Plymouth Colony for 30 years. The colony was founded by people called Puritans. They were some of the first people from England to settle in what is now the United States. Bradford helped make Plymouth the first lasting colony in New England." } }

Die manuelle Auswertung solcher spezifischer Abfragen ist eine allgemein nützliche Methode, um die Suchqualität zu verstehen und quantitative Messgrößen wie nDCG@10 zu ergänzen. Bei einem repräsentativen Abfrageset, das Sie immer ausführen, wenn Sie Änderungen an der Suche vornehmen, erhalten Sie wichtige qualitative Informationen darüber, wie sich die Leistung verändert, die in den Statistiken nicht sichtbar sind. Beispielsweise erhalten Sie viel mehr Einblick in die falschen Ergebnisse Ihrer Suche: Sie erkennen offensichtliche Fehler in den Suchergebnissen, Kategorien verwandter Fehler, wie z. B. die Fehlinterpretation fachspezifischer Terminologie und so weiter.

Unser Ergebnis stimmt mit einschlägigen Studien zur MSMARCO Bewertung der Suchrelevanz überein. Zum Beispiel folgen Arabzadeh et al. einem ähnlichen Verfahren, bei dem sie Crowdsourcing-Mitarbeiter für Präferenzurteile einsetzen: Sie zeigen unter anderem, dass in vielen Fällen die von den Reranking-Modulen zurückgegebenen Dokumente im Vergleich zu den Dokumenten in der MSMARCO- qrels-Datei bevorzugt werden. Ein weiterer Nachweis stammt von den Autoren des RocketQA-Rerankers, die berichten, dass mehr als 70 % der Reranking-Dokumente nach einer manuellen Überprüfung als relevant eingestuft wurden.

Aktualisierung – 9. September: Nach einer genauen Neubewertung des Datensatzes haben wir 15 weitere Fälle relevanter Dokumente identifiziert, wodurch sich die Gesamtzahl von 273 auf 288 erhöht hat

Wichtigste Erkenntnisse und nächste Schritte

Das Streben nach besseren Referenzwerten ist ein nie endender Prozess, da diese für Benchmarking und Modellvergleiche von entscheidender Bedeutung sind. LLMs können in einigen Bewertungsbereichen helfen, wenn sie mit Vorsicht angewendet und mit den richtigen Anweisungen abgestimmt werden.
Allgemeiner gesagt: Da Benchmarks niemals perfekt sein werden, könnte es vorteilhaft sein, von einem reinen Wertevergleich zu robusteren Methoden überzugehen, die statistisch signifikante Unterschiede erfassen. Die Arbeit von Arabzadeh et al. liefert hierfür ein gutes Beispiel, da auf Grundlage der Ergebnisse 95-prozentige Konfidenzintervalle erstellt wurden, die signifikante (oder nicht signifikante) Unterschiede zwischen den verschiedenen Durchläufen aufzeigen Im beigefügten Notizbuch stellen wir eine Implementierung von Konfidenzintervallen unter Verwendung von Bootstrapping zur Verfügung.
Aus der Perspektive des Endnutzers ist es sinnvoll, bei der Betrachtung von Benchmark-Ergebnissen über die Aufgabenausrichtung nachzudenken. Für einen KI-Ingenieur, der beispielsweise eine RAG-Pipeline entwickelt und weiß, dass der typische Anwendungsfall das Zusammenführen mehrerer Informationen aus verschiedenen Quellen beinhaltet, wäre es sinnvoller, die Leistung seines Retrieval-Modells anhand von Multi-Hop-QA-Datensätzen wie HotpotQA zu bewerten, anstatt den globalen Durchschnitt des gesamten BEIR-Benchmarks zu verwenden.

Im nächsten Blogbeitrag werden wir uns eingehender mit der Verwendung von Phi-3 als LLM-as-a-Judge und der Optimierung zur Vorhersage der Relevanz befassen.

KI-Plagiat: Plagiatserkennung mit Elasticsearch

Priscilla Parodi — Tue, 19 Dec 2023 00:00:00 GMT

Plagiat kann direkt sein, indem Teile oder der gesamte Inhalt kopiert werden, oder paraphrasiert, wobei das Werk des Autors durch die Änderung einiger Wörter oder Formulierungen umformuliert wird.

Es besteht ein Unterschied zwischen Inspiration und Paraphrasierung. Es ist möglich, einen Inhalt zu lesen, sich davon inspirieren zu lassen und die Idee dann mit eigenen Worten weiterzuentwickeln, selbst wenn man zu einem ähnlichen Schluss kommt.

Obwohl Plagiat schon seit langer Zeit ein Diskussionsthema ist, hat die beschleunigte Produktion und Veröffentlichung von Inhalten dazu geführt, dass es weiterhin relevant ist und eine ständige Herausforderung darstellt.

Diese Herausforderung beschränkt sich nicht auf Bücher, wissenschaftliche Forschung oder Gerichtsdokumente, wo häufig Plagiatsprüfungen durchgeführt werden. Dies kann sich auch auf Zeitungen und sogar soziale Medien erstrecken.

Wie kann Plagiat angesichts der Informationsfülle und des einfachen Zugangs zu Veröffentlichungen effektiv und in großem Umfang bekämpft werden?

Universitäten, Regierungsstellen und Unternehmen nutzen verschiedene Instrumente, aber während eine einfache lexikalische Suche direkte Plagiate effektiv aufdecken kann, liegt die größte Herausforderung in der Identifizierung paraphrasierter Inhalte.

Plagiatserkennung mit generativer KI

Mit generativer KI entsteht eine neue Herausforderung. Gilt von KI generierter Inhalt als Plagiat, wenn er kopiert wird?

In den Nutzungsbedingungen von OpenAI ist beispielsweise festgelegt, dass OpenAI keine Urheberrechte an Inhalten beansprucht, die von der API für Benutzer generiert werden. In diesem Fall können die Nutzer ihrer generativen KI die generierten Inhalte nach Belieben ohne Quellenangabe verwenden.

Die Akzeptanz des Einsatzes von generativer KI zur Effizienzsteigerung ist jedoch weiterhin Gegenstand von Diskussionen.

In dem Bestreben, einen Beitrag zur Plagiatserkennung zu leisten, entwickelte OpenAI ein Erkennungsmodell , räumte aber später ein, dass dessen Genauigkeit nicht ausreichend hoch sei.

„Wir glauben, dass diese Genauigkeit für eine eigenständige Erkennung nicht ausreicht und mit metadatenbasierten Ansätzen, menschlichem Urteilsvermögen und Aufklärung der Öffentlichkeit kombiniert werden muss, um effektiver zu sein.“

Die Herausforderung besteht weiterhin; allerdings stehen mit der Verfügbarkeit von mehr Werkzeugen nun auch mehr Möglichkeiten zur Erkennung von Plagiaten zur Verfügung, selbst bei paraphrasierten und KI-generierten Inhalten.

Plagiatserkennung mit Elasticsearch

In Anbetracht dessen untersuchen wir in diesem Blog einen weiteren Anwendungsfall von Natural Language Processing (NLP)-Modellen und Vector Search, nämlich die Plagiatserkennung, die über die Metadatensuche hinausgeht.

Dies wird anhand von Python-Beispielen demonstriert, wobei wir einen Datensatz von SentenceTransformers verwenden, der Artikel zum Thema NLP enthält. Wir prüfen die Abstracts auf Plagiat, indem wir eine „semantische Textähnlichkeit“ durchführen und dabei „Abstract“-Einbettungen berücksichtigen, die mit einem zuvor in Elasticsearch importierten Text-Einbettungsmodell generiert wurden. Um zudem KI-generierte Inhalte – also KI-Plagiate – zu identifizieren, wurde ein von OpenAI entwickeltes NLP-Modell in Elasticsearch importiert.

Die folgende Abbildung veranschaulicht den Datenfluss:

Während der Ingest-Pipeline mit einem Inferenzprozessor wird der Absatz „abstract“ einem 768-dimensionalen Vektor, dem „abstract_vector.predicted_value“, zugeordnet.

Abbildung:

"abstract_vector.predicted_value": { # Inference results field "type": "dense_vector", "dims": 768, # model embedding_size "index": "true", "similarity": "dot_product" # When indexing vectors for approximate kNN search, you need to specify the similarity function for comparing the vectors.

Die Ähnlichkeit zwischen Vektordarstellungen wird mithilfe einer Vektorähnlichkeitsmetrik gemessen, die über den Parameter „Ähnlichkeit“ definiert ist.

Der Kosinus ist das Standardähnlichkeitsmaß und wird wie folgt berechnet: '(1 + cosine(query, vector)) / 2'. Sofern Sie die ursprünglichen Vektoren nicht erhalten müssen und sie nicht im Voraus normalisieren können, ist die effizienteste Methode zur Durchführung der Kosinusähnlichkeit die Normalisierung aller Vektoren auf Einheitslänge. Dadurch wird vermieden, dass während der Suche zusätzliche Vektorlängenberechnungen durchgeführt werden, stattdessen wird 'dot_product' verwendet.

In derselben Pipeline erkennt ein weiterer Inferenzprozessor, der das Textklassifizierungsmodell enthält, ob der Inhalt „Real“ (wahrscheinlich von Menschen geschrieben) oder „Fake“ (wahrscheinlich von einer KI geschrieben) ist, und fügt jedem Dokument den Wert „openai-detector.predicted_value“ hinzu.

Ingest-Pipeline:

client.ingest.put_pipeline( id="plagiarism-checker-pipeline", processors = [ { "inference": { #for ml models - to infer against the data that is being ingested in the pipeline "model_id": "roberta-base-openai-detector", #text classification model id "target_field": "openai-detector", # Target field for the inference results "field_map": { #Maps the document field names to the known field names of the model. "abstract": "text_field" # Field matching our configured trained model input. } } }, { "inference": { "model_id": "sentence-transformers__all-mpnet-base-v2", #text embedding model id "target_field": "abstract_vector", # Target field for the inference results "field_map": { "abstract": "text_field" # Field matching our configured trained model input. Typically for NLP models, the field name is text_field. } } } ] )

Zum Zeitpunkt der Abfrage wird dasselbe Text-Embedding-Modell auch verwendet, um die Vektordarstellung der Abfrage 'model_text' in einem 'query_vector_builder'-Objekt zu generieren.

Bei einer k-Nächste-Nachbarn-Suche (kNN) werden die k nächsten Vektoren zum Anfragevektor anhand der Ähnlichkeitsmetrik ermittelt.

Der _Score jedes Dokuments wird aus der Ähnlichkeit abgeleitet, wobei ein höherer Score einer höheren Platzierung entspricht. Das bedeutet, dass das Dokument semantisch ähnlicher ist. Als Ergebnis geben wir drei Möglichkeiten aus: Bei einem Wert > 0,9 gehen wir von „hoher Ähnlichkeit“ aus; bei einem Wert < 0,7 von „geringer Ähnlichkeit“; andernfalls von „mittlerer Ähnlichkeit“. Je nach Anwendungsfall haben Sie die Möglichkeit, unterschiedliche Schwellenwerte festzulegen, um zu bestimmen, ab welchem _score-Wert ein Plagiat vorliegt oder nicht.

Zusätzlich wird eine Textklassifizierung durchgeführt, um auch KI-generierte Elemente in der Textanfrage zu erkennen.

Abfrage:

from elasticsearch import Elasticsearch from elasticsearch.client import MlClient #duplicated text - direct plagiarism test model_text = 'Understanding and reasoning about cooking recipes is a fruitful research direction towards enabling machines to interpret procedural text. In this work, we introduce RecipeQA, a dataset for multimodal comprehension of cooking recipes. It comprises of approximately 20K instructional recipes with multiple modalities such as titles, descriptions and aligned set of images. With over 36K automatically generated question-answer pairs, we design a set of comprehension and reasoning tasks that require joint understanding of images and text, capturing the temporal flow of events and making sense of procedural knowledge. Our preliminary results indicate that RecipeQA will serve as a challenging test bed and an ideal benchmark for evaluating machine comprehension systems. The data and leaderboard are available at http://hucvl.github.io/recipeqa.' response = client.search(index='plagiarism-checker', size=1, knn={ "field": "abstract_vector.predicted_value", "k": 9, "num_candidates": 974, "query_vector_builder": { #The 'all-mpnet-base-v2' model is also employed to generate the vector representation of the query in a 'query_vector_builder' object. "text_embedding": { "model_id": "sentence-transformers__all-mpnet-base-v2", "model_text": model_text } } } ) for hit in response['hits']['hits']: score = hit['_score'] title = hit['_source']['title'] abstract = hit['_source']['abstract'] openai = hit['_source']['openai-detector']['predicted_value'] url = hit['_source']['url'] if score > 0.9: print(f"\nHigh similarity detected! This might be plagiarism.") print(f"\nMost similar document: '{title}'\n\nAbstract: {abstract}\n\nurl: {url}\n\nScore:{score}\n\n") if openai == 'Fake': print("This document may have been created by AI.\n") elif score < 0.7: print(f"\nLow similarity detected. This might not be plagiarism.") if openai == 'Fake': print("This document may have been created by AI.\n") else: print(f"\nModerate similarity detected.") print(f"\nMost similar document: '{title}'\n\nAbstract: {abstract}\n\nurl: {url}\n\nScore:{score}\n\n") if openai == 'Fake': print("This document may have been created by AI.\n") ml_client = MlClient(client) model_id = 'roberta-base-openai-detector' #open ai text classification model document = [ { "text_field": model_text } ] ml_response = ml_client.infer_trained_model(model_id=model_id, docs=document) predicted_value = ml_response['inference_results'][0]['predicted_value'] if predicted_value == 'Fake': print("\nNote: The text query you entered may have been generated by AI.\n")

Ausgabe:

High similarity detected! This might be plagiarism. Most similar document: 'RecipeQA: A Challenge Dataset for Multimodal Comprehension of Cooking Recipes' Abstract: Understanding and reasoning about cooking recipes is a fruitful research direction towards enabling machines to interpret procedural text. In this work, we introduce RecipeQA, a dataset for multimodal comprehension of cooking recipes. It comprises of approximately 20K instructional recipes with multiple modalities such as titles, descriptions and aligned set of images. With over 36K automatically generated question-answer pairs, we design a set of comprehension and reasoning tasks that require joint understanding of images and text, capturing the temporal flow of events and making sense of procedural knowledge. Our preliminary results indicate that RecipeQA will serve as a challenging test bed and an ideal benchmark for evaluating machine comprehension systems. The data and leaderboard are available at[ http://hucvl.github.io/recipeqa](http://hucvl.github.io/recipeqa). url:[http://aclweb.org/anthology/D18-1166](http://aclweb.org/anthology/D18-1166) Score:1.0

In diesem Beispiel wurde ein Plagiat festgestellt, nachdem einer der „abstract“-Werte aus unserem Datensatz als Textabfrage „model_text“ verwendet wurde. Der Ähnlichkeitswert beträgt 1,0, was auf eine hohe Ähnlichkeit hinweist – direktes Plagiat. Die vektorisierte Anfrage und das Dokument wurden erwartungsgemäß nicht als KI-generierter Inhalt erkannt.

Abfrage:

#similar text - paraphrase plagiarism test model_text = 'Comprehending and deducing information from culinary instructions represents a promising avenue for research aimed at empowering artificial intelligence to decipher step-by-step text. In this study, we present CuisineInquiry, a database for the multifaceted understanding of cooking guidelines. It encompasses a substantial number of informative recipes featuring various elements such as headings, explanations, and a matched assortment of visuals. Utilizing an extensive set of automatically crafted question-answer pairings, we formulate a series of tasks focusing on understanding and logic that necessitate a combined interpretation of visuals and written content. This involves capturing the sequential progression of events and extracting meaning from procedural expertise. Our initial findings suggest that CuisineInquiry is poised to function as a demanding experimental platform.'

Ausgabe:

Durch die Aktualisierung der Textabfrage 'model_text' mit einem KI-generierten Text, der die gleiche Botschaft vermittelt und gleichzeitig die Wiederholung ähnlicher Wörter minimiert, war die festgestellte Ähnlichkeit immer noch hoch, aber der Wert betrug 0,9302529 statt 1,0 — Paraphrasierungsplagiat. Es wurde auch erwartet, dass diese von einer KI generierte Anfrage erkannt werden würde.

Schließlich ergab die Betrachtung der Textanfrage 'model_text' als Text über Elasticsearch, der kein Abstract eines dieser Dokumente ist, eine festgestellte Ähnlichkeit von 0,68991005, was gemäß den betrachteten Schwellenwerten auf eine geringe Ähnlichkeit hinweist.

Abfrage:

#different text - not a plagiarism model_text = 'Elasticsearch provides near real-time search and analytics for all types of data.'

Ausgabe:

Low similarity detected. This might not be plagiarism.

Obwohl Plagiate in der von der KI generierten Textanfrage sowie in Fällen von Paraphrasierung und direkt kopierten Inhalten korrekt identifiziert wurden, erfordert die Navigation durch das Feld der Plagiatserkennung die Berücksichtigung verschiedener Aspekte.

Im Kontext der Erkennung von KI-generierten Inhalten haben wir ein Modell untersucht, das einen wertvollen Beitrag leistet. Es ist jedoch entscheidend, die systembedingten Einschränkungen der eigenständigen Erkennung zu erkennen, weshalb andere Methoden zur Steigerung der Genauigkeit einbezogen werden müssen.

Die durch die Wahl der Text-Embedding-Modelle bedingte Variabilität ist ein weiterer zu berücksichtigender Aspekt. Unterschiedliche Modelle, die mit verschiedenen Datensätzen trainiert wurden, führen zu unterschiedlichen Ähnlichkeitsgraden, was die Bedeutung der generierten Text-Embeddings unterstreicht.

Schließlich haben wir in diesen Beispielen die Zusammenfassung des Dokuments verwendet. Die Plagiatserkennung betrifft jedoch häufig große Dokumente, weshalb es unerlässlich ist, die Herausforderung der Textlänge anzugehen. Häufig überschreitet der Text das Token-Limit eines Modells, sodass er vor dem Erstellen der Einbettungen in Abschnitte unterteilt werden muss. Ein praktischer Ansatz zur Bewältigung dieses Problems besteht in der Verwendung verschachtelter Strukturen mit dense_vector.

Fazit

In diesem Blog haben wir die Herausforderungen bei der Erkennung von Plagiaten, insbesondere bei paraphrasierten und KI-generierten Inhalten, erörtert und gezeigt, wie semantische Textähnlichkeit und Textklassifizierung zu diesem Zweck eingesetzt werden können.

Durch die Kombination dieser Methoden haben wir ein Beispiel für die Plagiatserkennung geliefert, bei dem wir erfolgreich KI-generierte Inhalte, direkte und paraphrasierte Plagiate identifiziert haben.

Das Hauptziel war die Einrichtung eines Filtersystems, das die Erkennung vereinfacht, die menschliche Beurteilung bleibt jedoch für die Validierung unerlässlich.

Wenn Sie mehr über semantische Textähnlichkeit und NLP erfahren möchten, empfehlen wir Ihnen, auch diese Links zu besuchen:

Lexikalische und semantische Suche mit Elasticsearch

Priscilla Parodi — Tue, 03 Oct 2023 00:00:00 GMT

Die Suche ist der Prozess, bei dem die relevantesten Informationen auf der Grundlage Ihrer Suchanfrage oder kombinierter Suchanfragen gefunden werden; relevante Suchergebnisse sind Dokumente, die am besten zu diesen Suchanfragen passen. Obwohl die Suche mit verschiedenen Herausforderungen und Methoden verbunden ist, bleibt das letztendliche Ziel dasselbe: die bestmögliche Antwort auf Ihre Frage zu finden.

Mit Blick auf dieses Ziel werden wir in diesem Blogbeitrag verschiedene Ansätze zur Informationsbeschaffung mit Elasticsearch untersuchen, wobei der Schwerpunkt auf der Textsuche liegt: lexikalische und semantische Suche.

Voraussetzungen

Um dies zu erreichen, werden wir Python-Beispiele bereitstellen, die verschiedene Suchszenarien auf einem Datensatz demonstrieren, der zur Simulation von E-Commerce-Produktinformationen generiert wurde.

Dieser Datensatz enthält über 2.500 Produkte, jedes mit einer Beschreibung. Diese Produkte sind in 76 verschiedene Produktkategorien unterteilt, wobei jede Kategorie eine unterschiedliche Anzahl von Produkten enthält, wie unten dargestellt:

Treemap-Visualisierung – die 22 wichtigsten Werte von category.keyword (Produktkategorien)

Für die Einrichtung benötigen Sie:

Python 3.6 oder höher
Der Elastic Python-Client
Elastic 8.8-Bereitstellung oder höher, mit 8 GB Arbeitsspeicher-Knoten für maschinelles Lernen
Das Elastic Learned Sparse EncodeR- Modell, das in Elastic vorinstalliert und auf Ihrem Bereitstellungsserver gestartet ist, ist bereits vorhanden.

Wir werden Elastic Cloud verwenden, eine kostenlose Testversion ist verfügbar.

Neben den in diesem Blogbeitrag bereitgestellten Suchanfragen führt Sie ein Python-Notebook durch die folgenden Prozesse:

Stellen Sie mithilfe des Python-Clients eine Verbindung zu unserer Elastic-Bereitstellung her.
Laden Sie ein Text-Embedding-Modell in den Elasticsearch-Cluster.
Erstellen Sie einen Index mit Zuordnungen zum Indizieren von Merkmalsvektoren und dichten Vektoren.
Erstellen Sie eine Ingest-Pipeline mit Inferenzprozessoren für Text-Embedding und Text-Expansion.

Lexikalische Suche – spärliche Suche

Die klassische Methode, mit der Elasticsearch Dokumente anhand einer Textabfrage nach Relevanz ordnet, verwendet die Lucene-Implementierung des BM25- Modells, eines Sparse-Modells für die lexikalische Suche. Diese Methode folgt dem traditionellen Ansatz der Textsuche und sucht nach exakten Übereinstimmungen der Begriffe.

Um diese Suche zu ermöglichen, wandelt Elasticsearch die Daten der Textfelder durch eine Textanalyse in ein durchsuchbares Format um.

Die Textanalyse wird von einem Analysator durchgeführt, einem Regelsatz, der den Prozess der Extraktion relevanter Token für die Suche steuert. Ein Analysator muss genau einen Tokenizer haben. Der Tokenizer empfängt einen Zeichenstrom und zerlegt ihn in einzelne Tokens (in der Regel einzelne Wörter), wie im folgenden Beispiel:

String-Tokenisierung für die lexikalische Suche

#Performs text analysis on a string and returns the resulting tokens. # Define the text to be analyzed text = "Comfortable furniture for a large balcony" # Define the analyze request request_body = { "analyzer": "standard", "text": text } # Perform the analyze request response = client.indices.analyze(analyzer=request_body["analyzer"], text=request_body["text"]) # Extract and display the analyzed tokens tokens = [token["token"] for token in response["tokens"]] print("Analyzed Tokens:", tokens)

Ausgabe

Analyzed Tokens: ['comfortable', 'furniture', 'for', 'a', 'large', 'balcony']

In diesem Beispiel verwenden wir den Standardanalysator , der für die meisten Anwendungsfälle gut geeignet ist, da er eine auf englischer Grammatik basierende Tokenisierung bietet. Die Tokenisierung ermöglicht den Abgleich einzelner Begriffe, wobei jedes Token weiterhin wörtlich abgeglichen wird.

Wenn Sie Ihr Sucherlebnis personalisieren möchten, können Sie einen anderen integrierten Analysator auswählen. Beispielsweise wird durch die Aktualisierung des Codes zur Verwendung des Stoppwortanalysators der Text an jedem Nicht-Buchstaben-Zeichen in Tokens zerlegt, wobei die Entfernung von Stoppwörtern unterstützt wird.

... # Define the analyze request request_body = { "analyzer": "stop", "text": text } ...

Ausgabe

Analyzed Tokens: ['comfortable', 'furniture', 'large', 'balcony']

Wenn die integrierten Analysatoren Ihre Anforderungen nicht erfüllen, können Sie einen benutzerdefinierten Analysator erstellen, der die entsprechende Kombination aus null oder mehr Zeichenfiltern, einem Tokenizer und null oder mehr Tokenfiltern verwendet.

"analyzer": { "my_analyzer": { "type": "custom", #For custom analyzers, use a type of custom or omit the type parameter. "tokenizer": "standard", #Built-in or customized tokenizer "filter": ["lowercase", "synonym"] #Built-in or customized token filters } }

Im obigen Beispiel, das einen Tokenizer und Tokenfilter kombiniert, wird der Text vom Kleinbuchstabenfilter in Kleinbuchstaben umgewandelt, bevor er vom Synonym-Tokenfilter verarbeitet wird.

Lexikalische Übereinstimmung

BM25 wird die Relevanz von Dokumenten für eine bestimmte Suchanfrage anhand der Häufigkeit der Begriffe und ihrer Wichtigkeit messen.

Der unten stehende Code führt eine Match -Abfrage durch, bei der bis zu zwei Dokumente unter Berücksichtigung der Werte des Feldes "description" aus dem Index "ecommerce-search" und der Suchanfrage "Comfortable furniture for a large Balcony" gesucht werden.

Durch eine Verfeinerung der Kriterien, nach denen ein Dokument als Treffer für diese Abfrage in Betracht gezogen werden soll, kann die Genauigkeit verbessert werden. Genauere Ergebnisse gehen jedoch mit einer geringeren Toleranz gegenüber Abweichungen einher.

# BM25 response = client.search(size=2, index="ecommerce-search", query= { "match": { "description" : { "query": "Comfortable furniture for a large balcony", "analyzer": "stop" } } } ) hits = response['hits']['hits'] if not hits: print("No matches found") else: for hit in hits: score = hit['_score'] product = hit['_source']['product'] category = hit['_source']['category'] description = hit['_source']['description'] print(f"\nScore: {score}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

Ausgabe

Score: 15.607948 Product: Barbie Dreamhouse Category: Toys Description: is a classic Barbie playset with multiple rooms, furniture, a large balcony, a pool, and accessories. It allows kids to create their dream Barbie world. Score: 9.137739 Product: Comfortable Rocking Chair Category: Indoor Furniture Description: enjoy relaxing moments with this comfortable rocking chair. Its smooth motion and cushioned seat make it an ideal piece of furniture for unwinding.

Die Analyse der Ergebnisse zeigt, dass das relevanteste Produkt das „ Barbie Dreamhouse “ in der Kategorie „ Spielzeug “ ist. Dessen Beschreibung ist besonders relevant, da sie die Begriffe „ Möbel “, „ groß“ und „Balkon “ enthält. Es ist das einzige Produkt, dessen Beschreibung drei Begriffe enthält, die mit der Suchanfrage übereinstimmen, und es ist außerdem das einzige, dessen Beschreibung den Begriff „Balkon“ enthält.

Das zweitwichtigste Produkt ist ein „ Komfortabler Schaukelstuhl “, der unter „ Innenmöbel “ kategorisiert ist und dessen Beschreibung die Begriffe „ bequem “ und „ Möbel “ enthält. Nur 3 Produkte im Datensatz entsprechen mindestens 2 Begriffen dieser Suchanfrage, dieses Produkt ist eines davon.

Der Begriff „Komfortabel“ taucht in der Beschreibung von 105 Produkten auf, der Begriff „Möbel“ in der Beschreibung von 4 Produkten aus 4 verschiedenen Kategorien: Spielzeug, Möbel für den Innenbereich, Möbel für den Außenbereich und „Zubehör und Spielzeug für Hunde und Katzen“.

Wie Sie sehen konnten, ist das relevanteste Produkt im Hinblick auf die Suchanfrage ein Spielzeug und das zweitrelevanteste Produkt sind Möbel für den Innenbereich. Wenn Sie detaillierte Informationen über die Berechnung der Punktzahl wünschen, um zu verstehen, warum diese Dokumente übereinstimmen, können Sie den Parameter explain __query auf true setzen.

Obwohl beide Ergebnisse die relevantesten sind, sowohl hinsichtlich der Anzahl der Dokumente als auch des Vorkommens der Begriffe in diesem Datensatz, besteht die Absicht hinter der Anfrage "Bequeme Möbel für einen großen Balkon" darin, Möbel für einen tatsächlich großen Balkon zu finden, wobei unter anderem Spielzeug und Möbel für den Innenbereich ausgeschlossen werden.

Die lexikalische Suche ist relativ einfach und schnell, hat aber ihre Grenzen, da es nicht immer möglich ist, alle möglichen Begriffe und Synonyme zu kennen, ohne unbedingt die Absicht und die Suchanfragen des Benutzers zu kennen. Ein häufiges Phänomen beim Gebrauch natürlicher Sprache ist die Diskrepanz im Wortschatz. Untersuchungen zeigen, dass verschiedene Personen (Experten auf demselben Gebiet) im Durchschnitt in 80 % der Fälle ein und dasselbe Objekt unterschiedlich benennen.

Diese Einschränkungen veranlassen uns, nach anderen Bewertungsmodellen zu suchen, die semantisches Wissen einbeziehen. Transformerbasierte Modelle, die sich durch ihre Fähigkeit auszeichnen, sequentielle Eingabe-Tokens wie natürliche Sprache zu verarbeiten, erfassen die zugrundeliegende Bedeutung Ihrer Suche, indem sie mathematische Darstellungen sowohl von Dokumenten als auch von Suchanfragen berücksichtigen. Dies ermöglicht eine dichte, kontextsensitive Vektordarstellung von Texten und ist somit die Grundlage für die semantische Suche, eine verfeinerte Methode zum Auffinden relevanter Inhalte.

Semantische Suche – dichte Suche

In diesem Zusammenhang wird nach der Umwandlung Ihrer Daten in aussagekräftige Vektorwerte der k-nächste-Nachbarn-Suchalgorithmus (kNN) verwendet, um Vektordarstellungen in einem Datensatz zu finden, die einem Anfragevektor am ähnlichsten sind. Elasticsearch unterstützt zwei Methoden für die kNN-Suche: die exakte Brute-Force-kNN-Suche und die approximative kNN-Suche, auch bekannt als ANN.

Brute-Force-kNN garantiert zwar genaue Ergebnisse, skaliert aber nicht gut mit großen Datensätzen. Approximatives kNN findet effizient annähernd nächste Nachbarn, indem es etwas Genauigkeit für eine verbesserte Leistung opfert.

Durch die Unterstützung von kNN-Suche und dichten Vektorindizes durch Lucene nutzt Elasticsearch den Hierarchical Navigable Small World (HNSW)-Algorithmus, der eine starke Suchleistung über eine Vielzahl von ann-Benchmark-Datensätzen hinweg demonstriert. Eine approximative kNN-Suche kann in Python mithilfe des unten stehenden Beispielcodes durchgeführt werden.

Semantische Suche mit approximativem kNN

# KNN - approximate kNN response = client.search(index='ecommerce-search', size=2, knn={ "field": "description_vector.predicted_value", "k": 50, # Number of nearest neighbors to return as top hits. #The optimal value of k is dependent on the data. It can vary in different scenarios. "num_candidates": 500, # Number of nearest neighbor candidates to consider per shard. #Increasing num_candidates tends to improve the accuracy of the final k results. "query_vector_builder": { # Object indicating how to build a query_vector. kNN search enables you to perform semantic search by using a previously deployed text embedding model, the steps for this process are demonstrated in the Python notebook. "text_embedding": { "model_id": "sentence-transformers__all-mpnet-base-v2", # Text embedding model id "model_text": "Comfortable furniture for a large balcony" # Query } } } ) for hit in response['hits']['hits']: score = hit['_score'] product = hit['_source']['product'] category = hit['_source']['category'] description = hit['_source']['description'] print(f"\nScore: {score}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

Dieser Codeblock verwendet Elasticsearchs kNN, um bis zu zwei Produkte mit einer Beschreibung zurückzugeben, die der vektorisierten Anfrage (query_vector_build) von "Komfortable Möbel für einen großen Balkon" ähnlich ist, wobei die Einbettungen des Feldes "description " im Produktdatensatz berücksichtigt werden.

Die Produkt-Embeddings wurden zuvor in einer Ingest-Pipeline mit einem Inferenzprozessor generiert, der das Text-Embedding-Modell "all-mpnet-base-v2" enthielt, um aus den in die Pipeline aufgenommenen Daten Inferenz zu ziehen.

Dieses Modell wurde auf Grundlage der Auswertung vortrainierter Modelle mithilfe von "sentence_transformers.evaluation" ausgewählt. wobei verschiedene Klassen verwendet werden, um ein Modell während des Trainings zu beurteilen. Das Modell „all-mpnet-base-v2“ erzielte die beste durchschnittliche Leistung gemäß dem Sentence-Transformers-Ranking und sicherte sich auch eine günstige Position im Massive Text Embedding Benchmark (MTEB) Leaderboard. Das Modell basiert auf dem vortrainierten microsoft/mpnet-base- Modell und wurde anhand eines Datensatzes mit 1 Milliarde Satzpaaren feinabgestimmt. Es bildet Sätze auf einen 768-dimensionalen dichten Vektorraum ab.

Alternativ stehen viele andere Modelle zur Verfügung, die verwendet werden können, insbesondere solche, die speziell auf Ihre domänenspezifischen Daten abgestimmt sind.

Ausgabe

Score: 0.79207325 Product: Patio Sofa Set with Ottoman Category: Outdoor Furniture Description: is a versatile and comfortable patio sofa set, including a sofa, ottoman, and coffee table, great for outdoor lounging. Score: 0.7836937 Product: Patio Sofa Set with Canopy Category: Outdoor Furniture Description: is a luxurious and comfortable patio sofa set with a canopy, providing shade and style for outdoor lounging.

Das Ergebnis kann je nach gewähltem Modell, Filtern und ungefährem kNN-Tuningvariieren.

Die kNN-Suchergebnisse befinden sich beide in der Kategorie „ Gartenmöbel “, obwohl das Wort „ Garten “ nicht explizit in der Suchanfrage erwähnt wurde. Dies unterstreicht die Bedeutung des semantischen Verständnisses im Kontext.

Die dichte Vektorsuche bietet mehrere Vorteile:

Aktivierung der semantischen Suche
Skalierbarkeit zur Verarbeitung sehr großer Datensätze
Flexibilität im Umgang mit einer breiten Palette von Datentypen

Die Suche in dichten Vektoren birgt jedoch auch ihre eigenen Herausforderungen:

Auswahl des richtigen Einbettungsmodells für Ihren Anwendungsfall
Sobald ein Modell ausgewählt ist, kann es notwendig sein, das Modell feinabzustimmen, um die Leistung auf einem domänenspezifischen Datensatz zu optimieren. Dieser Prozess erfordert die Einbeziehung von Domänenexperten.
Darüber hinaus kann die Indizierung hochdimensionaler Vektoren rechenaufwändig sein.

Semantische Suche – gelernter spärlicher Abruf

Lassen Sie uns einen alternativen Ansatz erkunden: das gelernte spärliche Retrieval, eine andere Möglichkeit, semantische Suchen durchzuführen.

Als Sparse-Modell nutzt es den Lucene-basierten invertierten Index von Elasticsearch, der von jahrzehntelangen Optimierungen profitiert. Dieser Ansatz geht jedoch über das einfache Hinzufügen von Synonymen mit lexikalischen Bewertungsfunktionen wie BM25 hinaus. Stattdessen werden gelernte Assoziationen mithilfe eines tiefergehenden sprachlichen Wissens einbezogen, um die Relevanz zu optimieren.

Durch die Erweiterung der Suchanfragen um relevante Begriffe, die in der ursprünglichen Anfrage nicht enthalten sind,verbessert der Elastic Learned Sparse Encoder die Sparse Vector Embeddings, wie Sie im folgenden Beispiel sehen können.

Suche nach dünnbesetzten Vektoren mit elastischem, gelerntem, dünnbesetztem Encoder

# Elastic Learned Sparse Encoder response = client.search(index='ecommerce-search', size=2, query={ "text_expansion": { "ml.tokens": { "model_id":"elser_model", "model_text":"Comfortable furniture for a large balcony" } } } ) for hit in response['hits']['hits']: score = hit['_score'] product = hit['_source']['product'] category = hit['_source']['category'] description = hit['_source']['description'] print(f"\nScore: {score}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

Ausgabe

Score: 14.405318 Product: Garden Lounge Set with Side Table Category: Garden Furniture Description: is a comfortable and stylish garden lounge set, including a sofa, chairs, and a side table for outdoor relaxation. Score: 14.281318 Product: Rattan Patio Conversation Set Category: Outdoor Furniture Description: is a stylish and comfortable outdoor furniture set, including a sofa, two chairs, and a coffee table, all made of durable rattan material.

Zu den Ergebnissen gehört in diesem Fall die Kategorie „ Gartenmöbel “, die Produkte anbietet, die den „ Outdoor-Möbeln “ sehr ähnlich sind.

Durch die Analyse von "ml.tokens", Aus dem Feld "rank_features", das die von Learned Sparse Retrieval generierten Token enthält, wird deutlich, dass sich unter den verschiedenen generierten Token Begriffe befinden, die zwar nicht Teil der Suchanfrage sind, aber dennoch eine relevante Bedeutung haben, wie zum Beispiel "relax" (bequem), "sofa" (Möbel) und "outdoor" (Balkon).

Das Bild unten hebt einige dieser Begriffe zusammen mit der Suchanfrage hervor, sowohl mit als auch ohne Begriffserweiterung.

Wie bereits erwähnt, ermöglicht dieses Modell eine kontextsensitive Suche und trägt dazu bei, das Problem der Diskrepanz zwischen Vokabular und Definition zu mindern, während es gleichzeitig besser interpretierbare Ergebnisse liefert. Es kann sogar dichte Vektormodelle übertreffen, wenn kein domänenspezifisches Nachtraining angewendet wird.

Hybridsuche: Relevante Ergebnisse durch die Kombination von lexikalischer und semantischer Suche

Wenn es um die Suche geht, gibt es keine Universallösung. Jede dieser Abrufmethoden hat ihre Stärken, aber auch ihre Herausforderungen. Je nach Anwendungsfall kann sich die beste Option ändern. Oftmals ergänzen sich die besten Ergebnisse verschiedener Abrufmethoden. Um die Relevanz zu erhöhen, werden wir daher versuchen, die Stärken der einzelnen Methoden zu kombinieren.

Es gibt verschiedene Möglichkeiten, eine hybride Suche zu implementieren, darunter die lineare Kombination, die Gewichtung jedes Ergebnisses und die reziproke Rangfusion (RRF), bei der die Angabe eines Gewichts nicht erforderlich ist.

Elasticsearch: Das Beste aus beiden Welten mit lexikalischer und semantischer Suche

# BM25 + Elastic Learned Sparse Encoder (Linear Combination) response = client.search(index='ecommerce-search', size=2, query= { "bool": { "should": [ { "match": { "description" : { "query": "A dining table and comfortable chairs for a large balcony", "boost": 1 } } }, { "text_expansion": { "ml.tokens": { "model_id": "elser_model", "model_text": "A dining table and comfortable chairs for a large balcony", "boost": 1 } } } ] } } ) # The boost value is 1 for the text expansion and match query. This means that the relevance score of the results of these queries are not boosted. You can specify a boost value to give a weight to each score in the sum. The scores will be calculated as: score = boost value * match_score + boost value * text_expansion_score for hit in response['hits']['hits']: score = hit['_score'] product = hit['_source']['product'] category = hit['_source']['category'] description = hit['_source']['description'] print(f"\nScore: {score}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

In diesem Code haben wir eine hybride Suche mit zwei Abfragen durchgeführt, die den Wert "Ein Esstisch und bequeme Stühle für einen großen Balkon" hatten. Anstatt "Möbel" als Suchbegriff zu verwenden, geben wir an, wonach wir suchen, und beide Suchanfragen berücksichtigen die gleichen Feldwerte, "Beschreibung". Die Rangfolge wird durch eine lineare Kombination der BM25- und ELSER-Werte bei gleicher Gewichtung ermittelt.

Ausgabe

Score: 31.628141 Product: Garden Dining Set with Swivel Rockers Category: Garden Furniture Description: is a functional and comfortable garden dining set, including a table and chairs with swivel rockers for easy movement. Score: 31.334227 Product: Garden Dining Set with Swivel Chairs Category: Garden Furniture Description: is a functional and comfortable garden dining set, including a table and chairs with swivel seats for convenience.

Im folgenden Code verwenden wir denselben Wert für die Abfrage, kombinieren aber die Ergebnisse von BM25 (Abfrageparameter) und kNN (KNN-Parameter) mithilfe der Methode der reziproken Rangfusion, um die Dokumente zu kombinieren und zu ordnen.

# BM25 + KNN (RRF) response = client.search(index='ecommerce-search', size=2, query={ "bool": { "should": [ { "match": { "description": { "query": "A dining table and comfortable chairs for a large balcony" } } } ] } }, knn={ "field": "description_vector.predicted_value", "k": 50, "num_candidates": 500, "query_vector_builder": { "text_embedding": { "model_id": "sentence-transformers__all-mpnet-base-v2", "model_text": "A dining table and comfortable chairs for a large balcony" } } }, rank={ "rrf": { # Reciprocal rank fusion "window_size": 50, # This value determines the size of the individual result sets per query. "rank_constant": 20 # This value determines how much influence documents in individual result sets per query have over the final ranked result set. } } ) for hit in response['hits']['hits']: rank = hit['_rank'] category = hit['_source']['category'] product = hit['_source']['product'] description = hit['_source']['description'] print(f"\nRank: {rank}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

Die RRF-Funktionalität befindet sich in der technischen Vorschauphase. Die Syntax wird sich voraussichtlich vor der allgemeinen Verfügbarkeit ändern.

Ausgabe

Rank: 1 Product: Patio Dining Set with Bench Category: Outdoor Furniture Description: is a spacious and functional patio dining set, including a dining table, chairs, and a bench for additional seating. Rank: 2 Product: Garden Dining Set with Swivel Chairs Category: Garden Furniture Description: is a functional and comfortable garden dining set, including a table and chairs with swivel seats for convenience.

Hier könnten wir auch andere Felder und Werte verwenden; einige Beispiele hierfür finden Sie im Python-Notebook.

Wie Sie sehen, bietet Elasticsearch das Beste aus beiden Welten: die traditionelle lexikalische Suche und die Vektorsuche, egal ob spärlich oder dicht, um Ihr Ziel zu erreichen und die bestmögliche Antwort auf Ihre Frage zu finden.

Wenn Sie mehr über die hier erwähnten Ansätze erfahren möchten, können Ihnen diese Blogs hilfreich sein:

Elasticsearch bietet eine Vektordatenbank sowie alle Werkzeuge, die Sie zum Erstellen von Vektorsuchen benötigen:

Elasticsearch -Vektordatenbank
Anwendungsfälle für die Vektorsuche mit Elastic

Fazit

In diesem Blogbeitrag haben wir verschiedene Ansätze zur Informationsbeschaffung mit Elasticsearch untersucht, wobei wir uns insbesondere auf die Text-, lexikalische und semantische Suche konzentriert haben. Um dies zu veranschaulichen, haben wir Python-Beispiele bereitgestellt, die verschiedene Suchszenarien anhand eines Datensatzes mit E-Commerce-Produktinformationen aufzeigen.

Wir haben die klassische lexikalische Suche mit BM25 überprüft und ihre Vorteile und Herausforderungen, wie z. B. Vokabeldiskrepanz, diskutiert. Wir haben die Bedeutung der Einbeziehung semantischen Wissens zur Überwindung dieses Problems hervorgehoben. Darüber hinaus haben wir die dichte Vektorsuche erörtert, die eine semantische Suche ermöglicht, und die mit dieser Abrufmethode verbundenen Herausforderungen behandelt, einschließlich des Rechenaufwands bei der Indizierung hochdimensionaler Vektoren.

Andererseits haben wir erwähnt, dass sich dünnbesetzte Vektoren außergewöhnlich gut komprimieren lassen. Daher haben wir den Learned Sparse Encoder von Elastic besprochen, der Suchanfragen erweitert, um relevante Begriffe einzubeziehen, die in der ursprünglichen Anfrage nicht enthalten sind.

Bei der Suche gibt es keine Universallösung. Jede Abrufmethode hat ihre Stärken und Schwächen. Deshalb haben wir auch das Konzept der hybriden Suche erörtert.

Wie Sie sehen konnten, bietet Elasticsearch die Vorteile beider Welten: die traditionelle lexikalische Suche und die Vektorsuche!

Bereit loszulegen? Sehen Sie sich das verfügbare Python-Notebook an und starten Sie eine kostenlose Testphase von Elastic Cloud.

Python - Elasticsearch Labs

Multimodale Suche nach Berggipfeln mit Elasticsearch und SigLIP-2

Wie alles begann

Zusammenstellung des Dreamteams: SigLIP-2, Elasticsearch & Streamlit

Implementierung

Elasticsearch-Indexierungsdesign und Indexierungsstrategie

Peaks_Katalogindex

Fotoindex

Suchanwendungsfälle

Streamlit-Benutzeroberfläche

Fazit

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

Geodaten-Suche mit Elasticsearch und ES|QL

Suche nach Geodaten

Warum nicht SQL?

Unterschiede zu SQL

OGC-Funktionen

ES|QL Vielseitigkeit

Räumliche Verknüpfungen

Kibana-Karten

Was kommt als Nächstes?

Bewertung der Suchrelevanz Teil 1 – Der BEIR-Benchmark

Den BEIR-Benchmark bei der Bewertung der Suchrelevanz verstehen

Struktur eines BEIR-Datensatzes

Nutzung des BEIR-Benchmarks zur Bewertung der Suchrelevanz

Wichtigste Erkenntnisse und nächste Schritte

KI-Plagiat: Plagiatserkennung mit Elasticsearch

Plagiatserkennung mit generativer KI

Plagiatserkennung mit Elasticsearch

Fazit

Lexikalische und semantische Suche mit Elasticsearch

Voraussetzungen

Lexikalische Suche – spärliche Suche

String-Tokenisierung für die lexikalische Suche

Lexikalische Übereinstimmung

Semantische Suche – dichte Suche

Semantische Suche mit approximativem kNN

Semantische Suche – gelernter spärlicher Abruf

Suche nach dünnbesetzten Vektoren mit elastischem, gelerntem, dünnbesetztem Encoder

Hybridsuche: Relevante Ergebnisse durch die Kombination von lexikalischer und semantischer Suche

Elasticsearch: Das Beste aus beiden Welten mit lexikalischer und semantischer Suche

Fazit

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