Wie Embedding-Modelle die Antwortzeit von Instant Search unter 10 ms halten

2016 entwickelte unser Team ein Suchwerkzeug für Premium-Domains, das ähnliche Namen auf dem Sekundärmarkt sofort während der Eingabe findet. Mit fastText-Embeddings und Spotifys Annoy-Indexierung ermöglichten wir semantische Suche in unter 10 ms.

Anders als herkömmliche Domainsuchwerkzeuge, die nur Verfügbarkeit prüfen, versuchte unseres, die Absicht der Nutzer zu verstehen. Sucht jemand nach „instantdomainsearch.com“, findet unser Index semantisch ähnliche Domains:

• domaininstant.com
• fastdomainsearch.com
• searchdomain.com

Die Tücken von fastText: domänenspezifischer Kontext

fastText erlernte sein semantisches Verständnis aus Milliarden Wörtern in Common Crawl und Wikipedia. Domains repräsentieren jedoch Unternehmen und Marken, die Wörter oft anders verwenden als allgemeine Webtexte.

Nehmen wir „mint“ als Beispiel. fastText kennt beide Bedeutungen, bewertet die Ähnlichkeit mit Pflanzen- und Kräuterbegriffen aber deutlich höher. In der Domain- und Geschäftswelt wird „mint“ häufiger mit Geld verbunden, etwa bei Mint.com. Dieses Muster zeigte sich bei vielen Begriffen, etwa Cloud und Spark.

Wir erkannten, dass nicht fastText begrenzt war. Domainnamen hatten vielmehr ihre eigene semantische Bedeutung entwickelt.

Daraus entstand die Herausforderung: Wie konnten wir unserem Modell domainspezifischen Kontext geben?

Warum nicht einfach KI einsetzen?

Moderne LLMs verstehen Kontext hervorragend. Als wir GPT-4 für ähnliche Domainvorschläge testeten, erfasste es die von Nutzern erwarteten Bedeutungen klar.

Mit einem kurzen Prompt für den Domainkontext verstand es, dass „cloud“ auch Cloud Computing, „mint“ Finanzen und „spark“ Datenanalyse meint. Es schlug Domains vor, die tatsächlichen Käuferwünschen entsprachen, statt bloßer Textvarianten.

Ein entscheidendes Hindernis blieb: die Latenz. Unser fastText-System liefert Ergebnisse in unter 10 ms. GPT-4 benötigte durchschnittlich 1,7 Sekunden, 85-mal länger. Bei einem Tool, dessen Nutzer Ergebnisse während der Eingabe erwarten, würde mehr als eine Sekunde Wartezeit pro Tastendruck das Nutzererlebnis zerstören.

Embedding-Modelle: von Wörtern zu Konzepten

So kamen wir auf die Idee, LLMs nicht in Echtzeit auszuführen, sondern offline zum Training eines eigenen schnellen Embedding-Modells zu verwenden. Statt allgemeinen Webkontext zu lernen, sollte es auf unseren Anwendungsfall spezialisiert sein: Domains.

Die praktischen Unterschiede:

fastText-Ansatz (allgemeines semantisches Verständnis):

• Verwendet 2 Millionen Wortvektoren, trainiert mit Common Crawl (2017)
• Versteht Wortbeziehungen anhand ihrer Verwendung in Webtexten
• „searchengine“ = semantische Bedeutung aus Millionen Sätzen
• Hervorragend beim allgemeinen Sprachverständnis

Unser erweiterter Ansatz (domainspezifische Semantik):

• Behandelt jedes Wort und jede Wortgruppe als Geschäftskonzept
• „searchengine“ = „Eine Plattform für Websuche und Entdeckung“
• Ergänzt domainspezifischen Kontext, den fastText nie gesehen hat
• Baut mit modernen Verfahren auf fastText auf

Für die Umsetzung verwendeten wir sentence-transformers, eine Python-Bibliothek für modernere Embedding-Modelle zur semantischen Suche, die wir für unseren Anwendungsfall feinabstimmen konnten. Seit 2017 hat sich die KI-Landschaft stark weiterentwickelt. Spezialisierte Modelle lassen sich heute wesentlich leichter erstellen. Mit GPT-4 erzeugten wir Millionen domainspezifischer Trainingsbeispiele in Stapeln. Anschließend stimmten wir neuere Modelle darauf ab, Domains so zu verstehen wie Domainprofis.

Die Umsetzung erforderte fünf Schritte: Trainingsdaten erzeugen, Ähnlichkeiten berechnen, Daten für das Training strukturieren, das Modell feinabstimmen und die Geschwindigkeit für den Produktivbetrieb optimieren.

Schritt 1: Domain-Beschreibungen mit GPT-4 erzeugen

Wir entdeckten, dass GPT-4 einzelne Wörter hervorragend zu kontextreichen Beschreibungen erweitern kann. Allein aus einem Domainnamen konnte es mögliche Anwendungen, verwandte Branchen und semantische Verbindungen ableiten.

Beschreibungen für einen Teil unseres Bestands lieferten beschriftete Trainingsdaten, die Domainsemantik erfassten.

Schritt 2: Beschreibungen in Ähnlichkeitswerte überführen

Mit Beschreibungen für jede Domain konnten wir semantische Ähnlichkeit anhand bestehender Embedding-Modelle messen. So erhielten wir Referenzdaten dazu, welche Domains als verwandt gelten sollten:

Diese Ähnlichkeitswerte wurden unsere Trainingsziele. Sie zeigten dem Modell, welche Domains im Embedding-Raum nah beieinander oder weit voneinander entfernt liegen sollten.

Schritt 3: Trainings-Triplets für das Fine-Tuning erstellen

Training mit Triplet Loss benötigt Dreiergruppen: eine Ankerdomain, einen positiven (ähnlichen) und einen negativen (unähnlichen) Treffer. Aus unseren Ähnlichkeitsberechnungen erzeugten wir Tausende solcher Tripel:

Diese Struktur zwingt das Modell, relative Ähnlichkeiten statt absoluter Klassifikationen zu lernen.

Schritt 4: unser domänenspezifisches Embedding-Modell trainieren

Wir wählten all-MiniLM-L6-v2 als Basismodell und all-mpnet-base-v2 als anfänglichen Embedding-Anbieter. Das bietet ein gutes Verhältnis von Leistung und Größe. Mit Triplet Loss trainierten wir es darauf, GPT-4s semantisches Verständnis nachzubilden:

Die Korrelation von 0,87 zeigte, dass unser leichtgewichtiges Modell den größten Teil von GPT-4s semantischem Verständnis erfasste und dabei um Größenordnungen schneller lief.

Schritt 5: von rund 500 ms auf 10 ms optimieren

Die erste Version dieses neuen Systems implementierten wir in Python, um einige Hypothesen zu prüfen. Wir nutzten verbreitete Bibliotheken wie usearch für HNSW und SQLite für die Rückzuordnung zur Domain. Vielversprechende Ergebnisse in meist etwa 500 ms bestätigten die Richtung. Ein gutes Modell zu trainieren löste aber erst die Hälfte des Problems. Wir brauchten weiterhin weniger als 50 ms Latenz!

Der größte Teil unseres Systems ist bereits in Rust geschrieben. Deshalb beschlossen wir, auch diese neuen Modelle nach Rust zu übertragen. Um große Abhängigkeiten zu vermeiden und weil Torch nicht die schnellste Inferenz bietet, entschieden wir uns für ONNX Runtime.

• Modellformat: ONNX (3-mal schneller als PyTorch)
• Laufzeit: Rust + ort (minimaler Overhead, hervorragende CPU-Leistung)
• Index: HNSW für eine begrenzte Menge von etwa 25 Millionen Sekundärmarkt-Domains
• Hardware: ausschließlich CPU (kein Overhead für GPU-Koordination)
• Optimierungen: quantisierte optimierte Ausgabe (optimum)

Das Ergebnis: 10 ms Latenz im 95. Perzentil und damit innerhalb unseres 25-ms-Ziels. Diese Geschwindigkeit ist entscheidend für das sofortige Sucherlebnis, das wir durch unsere CDN-Infrastruktur optimiert haben.

KI in der Entwicklung und im Produktivbetrieb

„KI-gestützt“ wird oft mit einem LLM in jedem Anfragepfad gleichgesetzt. Der Einsatzort ist jedoch eine Designentscheidung mit unterschiedlichen Vor- und Nachteilen.

• In der Entwicklung: weniger Kontext, höhere Geschwindigkeit
• Im Produktivbetrieb: mehr Kontext, geringere Geschwindigkeit

Unsere Sofortsuche zeigt, wie weit der erste Ansatz reicht: Wir destillierten GPT-4s Wissen mit Billionen Parametern in ein Embedding-Modell mit 22,7 Millionen Parametern. Es liefert semantische Ergebnisse in unter 10 ms, ohne die Entfernung zwischen Nutzer und unseren Servern einzurechnen.

Unser Firmennamengenerator zeigt dagegen, wo ein live ausgeführtes LLM Vorteile hat: Markenideen benötigen frisches, umfassendes Denken. Deshalb tauschen wir Geschwindigkeit gegen Tiefe und liefern Vorschläge, die tatsächlich den Kontext von mehr als einer Billion Parametern brauchen.

Das bedeutet nicht, dass LLMs in der Entwicklung besser sind als im Produktivbetrieb. Es geht darum, Kontexttiefe und Latenzkosten aufeinander abzustimmen.

Wir planen, unser neues Modell im Laufe des nächsten Monats einzuführen.