in der amerikanischen Kultur ist Folgendes:
„Du kannst nicht deinen Kuchen haben und ihn auch essen.“
Ich finde diesen Satz äußerst poetisch, aber auch sehr praktisch und nützlich. Die Botschaft dieses Sprichworts ist klar: Alles, was Sie erreichen, wird durch einen Kompromiss erreicht, denn alles hat seinen Preis.
Die philosophische Diskussion würde den Rahmen dieses Artikels sprengen, aber die praktischen Konsequenzen dieser Überlegungen stimmen weitgehend mit der Datenwissenschaft und Softwareentwicklung im Allgemeinen überein. Lass es mich erklären.
In der Softwareentwicklung und Datenwissenschaft gibt es kein „perfektes Design“ an sich. Derselbe Algorithmus, der für eine bestimmte Anwendung fantastisch ist, versagt bei anderen kläglich.
Denken Sie an die Kompromisse zwischen Berechnung und Speicher in den folgenden Fällen:
Es macht sehr viel Sinn, die Entfernung zwischen zwei Städten vorab zu berechnen und in einem Datensatz zu speichern, aber es macht keinen Sinn, sie während des Fluges zu berechnen. Dies liegt daran, dass Sie davon ausgehen, dass der Datensatz einigermaßen wartungsarm ist (Städte bewegen sich nicht einfach so oft) und es dumm wäre, die Entfernung zwischen New York und San Francisco jeden Bruchteil einer Sekunde zu berechnen. (Fall A)
Allerdings wäre es für einen Chatbot ebenso dumm (und wahrscheinlich unmöglich), sich alle möglichen Fragen zu merken, die ein Mensch stellen kann, und die Antwort auf diese Frage zu finden, wann immer sie gestellt wird. Dies liegt daran, dass das Drawback viel dynamischer ist und eine Berechnung „im laufenden Betrieb“ erfordert. (Fall B)
Im Fall A opfern wir Speicher und erhalten extrem schnelle Berechnungen. In Fall B verbringen wir mehr Rechenzeit, verwenden aber keinen „Abfrage“-Speicher.
Können Sie keine Rechenzeit und kein Gedächtnis bekommen? Nicht wirklich, denn du kannst deinen Kuchen nicht haben und ihn auch essen 🙂
Aber nehmen wir ein weniger offensichtliches und „trendigeres“ Beispiel. Lassen Sie uns über Massive Language Fashions (LLMs) sprechen.
LLMs sind die leistungsstärksten KI-Modelle, die wir haben, und sie basieren auf dem gesamten weltweit verfügbaren Wissen. Das sind sie auch massiv. Sie sind tatsächlich so groß, dass wir sie selten intern haben und sie normalerweise über APIs aufrufen. Allerdings gilt: API-Aufruf = Token = Kosten.
Stellen Sie sich nun vor, Sie möchten mithilfe eines intelligenten Methods das beste Restaurant für heute Abend auswählen. Sie würden ChatGPT etwa fragen: „Können Sie mir ein gutes italienisches Restaurant anbieten, das nicht superteuer, aber romantisch und in einer guten Lage ist?“
Stellen Sie sich nun vor, das GPT-Modell müsste alle Eating places im Universum erkunden und entscheiden, ob sie italienisch, nicht teuer, an einem guten Standort und in der Nähe Ihres Zuhauses sind. Im besten Fall würden Sie Millionen in Token ausgeben und wären zum Zeitpunkt der Berechnung bereits im Bett.
Allerdings wollen wir auch nicht ganz auf die ganze saftige, natürlichsprachliche Interpretations- und Informationsbeschaffungsfähigkeit der LLMs verzichten. Der Schlüssel liegt darin, dass wir, um das LLM zu nutzen und intelligente Informationen zu erhalten, nicht ständig den intelligentesten Teil der Pipeline nutzen können (das wäre so, als ob wir Ihren Kuchen hätten und ihn auch essen würden).
In diesem Artikel werde ich Ihnen ein Rezept für diese intelligenten, durch LLM verbesserten Empfehlungssysteme geben, wobei ich das Beispiel einer Restaurantempfehlung als Anwendungsfall verwende.
Die Eingabe dieses Methods ist die Beschreibung des Benutzers seines idealen Eating places in einer bestimmten Stadt und die Ausgabe ist eine Reihe empfohlener Eating places.
Fangen wir an!
1. Systemdesign
Der Kuchenspruch, den wir besprochen haben, ist in der Technik auch als Genauigkeit-Skalen-Zeit-Dreieck bekannt:
- Sie können anhand eines riesigen Datensatzes etwas Genaues machen, aber es wird langsam sein
- Sie können etwas Genaues und Schnelles erstellen, aber es lässt sich nicht intestine auf einen großen Datensatz skalieren
- Man kann etwas schnell machen und intestine skalieren, aber es wird nicht so genau sein.
Natürlich möchten wir, dass unsere Ergebnisse letztendlich genau sind, daher reicht Choice 3 allein nicht aus. Allerdings können wir Choice 3 mit einem genaueren Modell zusätzlich zum ersten verfeinern. Mit anderen Worten: Choice 3 kann uns mit wenig Rechenzeit eine gute Kandidatenliste liefern und wir können mithilfe eines großen Sprachmodells die genaueste Empfehlungsliste auswählen.
Mit anderen Worten, das Design sieht so aus:
- Eine schnelle und einfache Suche findet die High-Okay-Eating places in der Nähe (regelbasiert, hohe Erinnerung, niedrige Präzision)
- Ein langsames, sehr intelligentes Massive-Language-Modell wird uns dabei helfen, basierend auf der Abfrage unter den besten Okay die besten auszuwählen. (KI-basiert, hohe Präzision)
Auf diese Weise verschwenden wir keine Zeit und kein Geld mit dem langsamen LLM, profitieren aber dennoch von deren Intelligenz, indem wir sie auf einer ausgewählten Kandidatenliste einsetzen.
Genug gejault. Beginnen wir mit dem Codieren!
2. Das Drehbuch
2.1 Das Setup
Ich habe die Drecksarbeit hinter den Kulissen für Sie erledigt 🙂
Alles ist in objektorientierter Programmierung (OOP) geschrieben, mit Skripten und einer Pipeline, die den gesamten Prozess übernimmt. Der GitHub-Ordner ist Dieses hierund um den Relaxation des Codes zu generieren, können Sie ihn klonen und diesen Importblock hier verwenden:
2.2 Datengenerierung
Bevor wir etwas empfehlen können, brauchen wir etwas, das wir empfehlen können. In einem realen System würden wir eine Restaurantdatenbank an einem S3-Standort verwenden. Für diesen Artikel generieren wir eine synthetische Model, damit das Ganze vollständig reproduzierbar und frei lauffähig ist.
Dies ist die Aufgabe des RestaurantDataGenerator Klasse drinnen datagenerator.py. Es erstellt eine reproduzierbare Tabelle von ~10.000 Eating places verteilt auf acht Städte (New York, San Francisco, Chicago, Austin, Seattle, Boston, Miami und Denver). Jedes Restaurant erhält:
– ein zufällig zusammengestelltes Title
– A Stadt und a Breiten-/Längengrad rund um das Stadtzentrum dieser Stadt beprobt (innerhalb von ca. 13 km),
– A Küchenstil (Italienisch, Japanisch, Mexikanisch, Thailändisch, Französisch, …),
– A diätetisch Profil (Allesfresser/Vegetarier/Veganer)
– ein durchschnittliche Punktzahl
– A Anzahl der Stimmen
– A Preisklasse (10 / 100 / 1000, ein durchschnittliches Ticket professional Individual in der Größenordnung).
Dieser Generator soll laufen einmal. Das Generieren der Daten ist so einfach wie:
Dieser einzelne Aufruf schreibt in die Tabelle knowledge/eating places.csvdas sieht so aus:
Perfekt, da wir nun unsere Eating places haben, wollen wir mal sehen, wie wir sie empfehlen können.
2.3 Generierung der Kandidaten
Das ist Stufe 1 des Trichters: die günstige, schnelle, regelbasierte Kandidatenliste. Der Benutzer teilt uns mit, in welcher Stadt er sich befindet, und wir behalten nur die geografisch nächstgelegenen Eating places. Der Code filtert die Tabelle nach der Stadt, berechnet die Großkreisentfernung vom Benutzer zu jedem Restaurant und identifiziert die N_DISTANCE_CANDIDATES (Standardmäßig 50).
Diese Section ist bewusst hoher Rückruf, geringe Präzision. Mit diesem Ansatz können wir den gesamten Tisch (10.000 Eating places) ohne einen einzigen API-Aufruf und ohne Token-Kosten abdecken. Natürlich machen wir hier nichts besonders Schlaues oder Ausgefallenes, aber wir filtern tatsächlich alle Daten, die für den Benutzer nicht in Frage kommen. Das allein ist eine große Sache.
Versuchen wir zum Beispiel eine echte Anfrage an die Suche:
„günstige vegane Tacos mit lebhafter Atmosphäre“ in mehreren Städten
Dies ist die Ausgabe:
Beachten Sie, dass die Auswahlliste unten keine Ahnung von „vegan“, „billig“ oder „Tacos“ hat: Sie kennt nur die Entfernung. Dies ist jedoch in Ordnung, da das Ziel dieser Section darin besteht, einen Ausgangspunkt in der richtigen Stadt zu schaffen, den der LLM in Section 2 neu einstufen wird.
Machen wir uns bereit für das LLM!
2.4 Auswahl der Kandidaten
Das ist Stufe 2das langsame, intelligente, LLM-gesteuerte, hochpräzise Ende des Trichters. Dies baut direkt auf der 50-Restaurant-Shortlist von 2.3 auf. Der LLM sieht nie die vollständige Tabelle mit 10.000 Zeilen. Es sieht immer nur den kleinen, bereits relevanten Ausschnitt, den ihm der Distanzfilter übergeben hat.
Wir kommunizieren mit dem Modell über einen kleinen OpenAI-Consumer. Der Schlüssel wird ausgelesen OPENAI_API_KEY (in der Umgebung gespeichert). Der Empfehlungsgeber, definiert als RestaurantRecommenderläuft auf der Abfrage und auf der Stadt durch RestaurantRecommender.recommender(question,metropolis):
Ein paar Dinge sind erwähnenswert:
- Die Präzision steigt. Stufe 1 struggle ein hoher Rückruf, eine geringe Präzision: Es wurden unabhängig von der Anfrage die 50 nächstgelegenen Eating places zurückgegeben. Stufe 2 liest tatsächlich die Abfrage (günstige vegane Tacos mit lebhafter Atmosphäre), verwirft alles, was nicht passt, und gibt nur die besten 5 bis 10 mit einem ehrlichen Wert zurück
fit_score.
- Strukturierte Ausgabe mit Pydantic. Wir analysieren niemals Freiformtext. Das Modell wird gezwungen, in Kind eines Pydantic-Modells zu antworten (über strukturierte OpenAI-Ausgaben), sodass garantiert ist, dass jede Antwort mit dem Schema übereinstimmt.
Das Ausgabeschema trägt die restaurant_id Und title (von den Kandidaten), a fit_scoreWert zwischen 0 und 100 und ein Kurzschluss cause. Die Antwort wird ebenfalls mit einem freundlichen Abschluss versehen abstract. Die Durchführung des Aufrufs für unsere drei Städte ergibt zum Beispiel:
Wie Sie bemerken, ist dies viel besser als die reinen Distanz-Shortlists von 2.3. Dort struggle das nächstgelegene Restaurant in jeder Stadt eine im Wesentlichen zufällige Übereinstimmung (koreanisch, libanesisch, mexikanisch, aber vegetarisch). Hier hat das Modell das nachbestellt Dasselbe 50 Kandidaten rund um das, wonach wir eigentlich gefragt haben: vegane und mexikanische Lokale schweben mit Hoch an der Spitzefit_scoresund das Modell ist ehrlich, wenn nichts perfekt passt, indem es Teilübereinstimmungen notiert und erklärt, warum cause. Das ist die Präzision, die uns das LLM bietet, angewendet auf eine Auswahlliste, die klein genug ist, um im großen Maßstab günstig zu bleiben.
3. Ergebnisse
Gehen wir einen Schritt zurück und schauen wir uns an, was uns der zweistufige Trichter tatsächlich gebracht hat, indem wir dieselbe Anfrage in drei Städten verwenden: „günstige vegane Tacos mit lebhafter Atmosphäre“.
- Stufe 1 liefert uns die Liste der Kandidaten. Die Distanz-Shortlists von 2.3 waren konstruktionsbedingt mit hoher Erinnerung und geringer Präzision ausgestattet.
- Stufe 2 identifiziert die tatsächlichen Empfehlungen. Indem wir die 50 Kandidaten von Stufe 1 bis zum LLM weiterleiten, werden sie entsprechend den tatsächlich gestellten Fragen neu angeordnet.
Hier sind die endgültigen Empfehlungen, die das Modell für jede Stadt abgegeben hat:
- New York: Goldener Löffel (vegan, 4,9) und Maison Fork (Mexikaner, im Funds) steigen mit Fitnesswerten von 90 und 85 an die Spitze auf.
- Miami: Royal Tavern & Co. (vegan, mexikanisch, erschwinglich) führt mit 85.
- Boston: Urbaner Löffel Und Kleines Hausbeide preisgünstige mexikanische Plätze, belegen mit 90 und 85 die ersten beiden Plätze.
In jeder Stadt bewarb das Modell die Kandidaten, die zu den veganen, billigen und mexikanisch/tacostypischen Vorstellungen passten, und struggle ehrlich, wenn es um unvollkommene Übereinstimmungen ging: Orte, die der Ernährung, aber nicht der Küche (oder umgekehrt) entsprachen, wurden als Backup mit sichtbar niedrigeren Werten behalten fit_scores.
4. Schlussfolgerungen
Danke, dass du Zeit mit mir verbringst, das bedeutet mir sehr viel. ❤️ Das haben wir gemeinsam gemacht:
– Einen zweistufigen Empfehlungstrichter entwickelt, der sowohl skalierbar als auch clever ist.
– Verwendet einen günstigen, regelbasierten Distanzfilter (Stufe 1), um 10.000 Eating places auf die nächsten 50 zu reduzieren.
– Durch eine LLM-Neueinstufung (Stufe 2) wurden diese 50 Kandidaten zu den besten 5 bis 10 gemacht, mit einer ehrlichen Bewertung und Begründung für jeden.
In vielen realen Projekten erfreut sich ein Trichter wie der hier gebaute meist großer Beliebtheit. Solche Systeme sind sehr skalierbar, da das LLM sinnvoll eingesetzt wird, und clever, da wir Modelle verwenden, die den Kontext sehr effizient verstehen können.
7. Bevor Sie losfahren!
Nochmals vielen Dank für Ihre Zeit. Es bedeutet viel. Mein Title ist Piero Paialunga und ich bin dieser Typ hier:
Ich komme ursprünglich aus Italien und habe einen Doktortitel. aus dem Universität von Cincinnatiund arbeite als Datenwissenschaftler bei The Commerce Desk in New York Metropolis. Ich schreibe darüber KI, maschinelles Lernen und die sich entwickelnde Rolle von Datenwissenschaftlern sowohl hier auf TDS als auch auf LinkedIn. Wenn Ihnen der Artikel gefallen hat und Sie mehr über maschinelles Lernen erfahren und meine Studien verfolgen möchten, können Sie:
A. Folge mir weiter Linkedinwo ich alle meine Geschichten veröffentliche
B. Folge mir weiter GitHubwo Sie meinen gesamten Code sehen können
C. Bei Fragen können Sie mir eine E-Mail senden an piero.paialunga@hotmail