Erkenntnisse nach der Verarbeitung von 500 Millionen GPT-Tokens

 (kenkantzer.com)
4 Punkte von GN⁺ 2024-04-14 | 1 Kommentare | Auf WhatsApp teilen
  • Truss hat in den letzten 6 Monaten LLM-zentrierte Funktionen betrieben, dabei mit OpenAI-Modellen mehr als 500 Millionen Tokens verarbeitet und die Grenzen zusammengefasst, auf die man bei B2B-Textzusammenfassung, -analyse und -extraktion in der Praxis gestoßen ist
  • Prompts wurden nicht unbedingt stabiler, wenn man viele Detailanweisungen hinzufügte; bei Allgemeinwissen, das GPT bereits kannte, lieferten kürzere und weniger spezifische Anweisungen teils bessere Ergebnisse
  • Auch ohne Langchain, JSON mode, function calling oder assistants wurden mehrere Funktionen nur mit der chat-API und einer JSON-Extraktionsfunktion betrieben; der Kerncode bestand aus einer 40-Zeilen-Funktion plus Fehlerbehandlung und automatischem Abschneiden
  • GPT war schwach bei der Behandlung von Nullhypothesen wie „wenn nichts vorhanden ist, gib einen leeren Wert zurück“ sowie bei langen Ausgaben; unabhängig vom 128k-Eingabefenster von GPT-4 blieb die Ausgabe bei etwa 4k
  • RAG und Vektor-Datenbanken passten für die begrenzten Textextraktionsaufgaben von Truss nicht gut; Analysen, Zusammenfassungen und Extraktionen mit vollem Kontext sind zuverlässig, aber problematisch, wenn die Eingabe leer ist oder keine relevanten Informationen enthält

Einsatzbereich und Annahmen

  • Truss hat in den letzten 6 Monaten einige LLM-zentrierte Funktionen veröffentlicht; der geschätzte Verbrauch lag bei etwas über 500 Millionen Tokens
  • Verwendet wurden Modelle aus dem OpenAI-Umfeld; der Token-Verbrauch lag bei 85 % GPT-4 und 15 % GPT-3.5
  • Die verarbeiteten Daten bestehen ausschließlich aus Text; nicht-textuelle Funktionen wie gpt-4-vision, Sora oder Whisper sind nicht enthalten
  • Der Produktkontext ist B2B, die Hauptaufgaben sind Zusammenfassung, Analyse und Extraktion
  • 500 Millionen Tokens entsprechen ungefähr Text im Umfang von 750.000 Seiten

Weniger spezifische Prompts können besser sein

  • Wenn man bei Allgemeinwissen, das GPT ohnehin kennt, übergenaue Listen und Anweisungen hineingibt, können die Ergebnisse schlechter werden
  • Eine Pipeline musste Textblöcke danach klassifizieren, auf welchen der 50 US-Bundesstaaten oder die Bundesregierung sie sich beziehen
    • Der ursprüngliche Prompt übergab im Feld locality_id eine JSON-Liste mit den IDs der 50 Bundesstaaten und von federal, aus der ausgewählt werden sollte
    • Das funktionierte in etwa zu mehr als 98 %, aber die Fehlerquote war immer noch hoch genug, um weiter nachzuforschen
  • Ein anderes Feld, name, wurde nicht ausdrücklich verlangt, lieferte aber dennoch stabil den vollständigen Namen des richtigen Bundesstaats
    • Danach wurde die Methode so geändert, dass nach der im name ausgegebenen Zeichenfolge gesucht wurde, um den Bundesstaat zu finden, und das funktionierte gut
  • Der bessere Ansatz war ein Prompt im Stil von: „Du kennst die 50 Bundesstaaten, gib daher den vollständigen Namen des betreffenden Bundesstaats oder Federal zurück“ — also ein an den gesunden Menschenverstand delegierter Prompt
  • Es gab noch weitere Beobachtungen
    • Fehler traten häufiger bei mit M beginnenden Staaten wie Maryland, Maine, Massachusetts und Michigan auf
    • Wenn eine ID aus einer Liste gewählt werden sollte, war gut formatiertes JSON mit einem Staat pro Zeile weniger verwirrend als eine kommagetrennte Liste

API und Abstraktion blieben einfach

  • Langchain war in diesem Fall eher eine vorschnelle Abstraktion, und selbst nach mehreren Millionen Tokens und 3 bis 4 verschiedenen produktiven Funktionen bestand die Datei openai_service weiterhin nur aus einer 40-Zeilen-Funktion
  • Tatsächlich wurde nur die chat-API verwendet
    • Es wurde immer JSON extrahiert
    • JSON mode, function calling und assistants waren nicht nötig
    • Auch ein system prompt wurde nicht verwendet
    • Als gpt-4-turbo erschien, musste im Codebestand nur eine einzige Zeichenkette geändert werden
  • Der Großteil der Funktion übernahm die Fehlerbehandlung für Dinge wie 500er-Fehler der OpenAI-API oder geschlossene Sockets
    • Diese Fehler sind weniger geworden, was angesichts der Last bei OpenAI nicht überrascht
  • Das Limit der Kontextlänge wurde durch eigenes automatisches Abschneiden behandelt
    • Wenn die Stringlänge größer als model_context_size * 3 war, wurde abgeschnitten
    • Bei sehr vielen Punkten oder Zahlen kann das fehlschlagen, weil das Token-Verhältnis dann unter 1 Token pro 3 Zeichen fällt
    • Wenn context_length_exceeded auftrat, wurde anhand von model_context_size * 3 / 1.3 erneut abgeschnitten und der Versuch wiederholt

Streaming-UX ist schwer zu unterschätzen

  • Die Idee, mit der Streaming-API die Latenz zu senken und Nutzern mit variabler Geschwindigkeit eintreffende Zeichen zu zeigen, wirkte anfangs fast wie ein Gimmick
  • Tatsächliche Nutzer reagierten jedoch sehr positiv auf diese Anzeige eines variablen „Tippens“
  • Das fühlte sich an wie der Moment, in dem KI ihr Gegenstück zu Maus- und Cursor-UX bekommt

Leere Ergebnisse und lange Ausgaben sind Schwächen

  • „Wenn nichts gefunden wird, gib eine leere Ausgabe zurück“ war fast die fehleranfälligste Prompt-Formulierung
    • Gemeint war nicht, wirklich gar nichts auszugeben, sondern eine Darstellung eines leeren Werts wie {value: ""} zurückzugeben
    • Das Problem lag weniger an Ausgabegrenzen als an der Schwierigkeit, die Nullhypothese selbst korrekt zu erkennen
  • GPT entschied sich beim Zurückgeben leerer Werte teils für Halluzinationen, und umgekehrt gab es aus mangelnder Sicherheit zu häufig leere Werte zurück
  • Als es einen Bug gab, durch den Textblöcke leer sein konnten, traten starke Halluzinationen auf
    • Als Beispiele tauchten erfundene Bäckereinamen wie Sunshine Bakery, Golden Grain Bakery und Bliss Bakery auf
    • Die Lösung war, bei fehlendem Text den Prompt gar nicht erst zu senden
  • GPT-4 kann für Eingaben zwar ein 128k-Token-Fenster haben, aber das Ausgabefenster liegt weiterhin bei etwa 4k
    • Der Ausdruck „context window“ verwischt die Unterscheidung zwischen Ein- und Ausgabe
  • Wenn eine Liste von JSON-Objekten zurückgegeben werden sollte, war es selbst bei einfachen Objekten schwer, über 10 hinauszukommen
    • Bei einer Anforderung von 15 lag die Erfolgsquote schätzungsweise nur bei etwa 15 %
    • Selbst wenn bei etwa 10 gestoppt wurde, lag die Ausgabe nur bei 700 bis 800 Tokens
  • Man kann das Ausgabelimit umgehen, indem man jeweils nur eins anfordert und frühere Ergebnisse wieder mit hineingibt, aber dann spielt man mit GPT Stille Post und muss Werkzeuge wie Langchain handhaben

RAG und Vektor-Datenbanken passen nicht gut zu diesem Anwendungsfall

  • Vektor-Datenbanken sowie RAG/Embeddings waren im Fall von Truss größtenteils nutzlos
  • Vektor-Datenbanken und RAG passen nach dieser Sicht eher zu Suche, und zwar zu echter Suche wie bei Google oder Bing
  • Das Kernproblem ist das Relevanzkriterium
    • Es gibt keinen klaren Cutoff für Relevanz
    • Lösungen wie rerank von Cohere oder eigene Heuristiken sind möglich, aber nicht stabil
    • Es besteht das Risiko, dass Suchergebnisse durch irrelevante Treffer verunreinigt werden oder dass man zu konservativ filtert und wichtige Ergebnisse verpasst
  • Es ist auch verlustbehaftet, Vektoren in einer spezialisierten, proprietären Datenbank getrennt von den normalen Daten zu speichern
    • Sofern man nicht auf Google- oder Bing-Niveau operiert, rechtfertigt der Kontextverlust den Trade-off aus dieser Sicht nicht
  • Bei Suche innerhalb von Business-Anwendungen sind Nutzer oft Domänenexperten
    • Es wird angenommen, dass sie semantische Suche, die mehr Bedeutung hineininterpretiert als der Nutzer tatsächlich eingegeben hat, nicht mögen
  • In den meisten Suchfällen könnte es besser sein, das LLM als normalen Completion-Prompt zu nutzen, um die Suchanfrage des Nutzers in Faceted Search, komplexe Queries oder SQL zu übersetzen
    • Das ist kein RAG

Halluzinationen nehmen stark ab, wenn genügend Kontext vorhanden ist

  • Die meisten Anwendungsfälle von Truss folgen dem Muster: „Gib einen Textblock hinein und extrahiere etwas daraus“
  • Wenn man nach im Text erwähnten Firmennamen fragt, gibt GPT normalerweise keine beliebigen Unternehmen zurück
    • Wenn im Text allerdings keine Firma vorkommt, taucht das Nullhypothesen-Problem wieder auf
  • Auch bei Code halluziniert GPT beim Umschreiben eines übergebenen Codeblocks in der Regel nicht in dem Sinne, dass es Variablen erfindet oder mitten im Code zufällig Tippfehler einfügt
    • Wenn man es jedoch bittet, etwas zu erzeugen, kann es die Existenz von Standardbibliotheksfunktionen erfinden
    • Auch das wirkt eher wie ein Problem, nicht „ich weiß es nicht“ sagen zu können
  • Bei Aufgaben, bei denen der volle Kontext bereitgestellt wird und Analyse, Zusammenfassung und Extraktion verlangt werden, war es sehr zuverlässig
  • Es ähnelt einer Struktur, bei der gute Daten zu guten GPT-Token-Antworten führen

Einschätzung zum weiteren Ausblick

  • Mit den aktuellen Transformern, Internetdaten und Infrastruktur im Wert von zig Milliarden Dollar allein wird aus dieser Sicht kein AGI erreicht
  • GPT-4 ist kein Marketing, sondern zu 100 % nützliche Technologie, befindet sich aber noch in einer Phase ähnlich dem frühen Internet
    • Es ist keine Technologie, die alle entlässt
    • Sie senkt jedoch die Eintrittsbarrieren für ML/AI, die früher praktisch nur Google überwinden konnte
  • Claude, Gemini und andere wurden nicht in strengen A/B-Tests verglichen
    • Beim alltäglichen Programmieren wirkte GPT-4 in den feinen Nuancen des intuitiven Erfassen von Absichten deutlich näher als diese Alternativen
  • Es ist nicht nötig, jedem LLM-/AI-Trend vollständig zu folgen
    • Im Licht von The Bitter Lesson gilt: Wenn die Verbesserung allgemeiner Modellleistung wichtiger ist als spezialisierte Optimierungen, dann muss man im Grunde nur darauf achten, ob GPT-5 erscheint
    • Abgesehen von getrennten Feldern wie Sora wirken die meisten Zwischenveröffentlichungen von OpenAI eher wie Rauschen
  • GPT-5 wird wahrscheinlich eher schrittweise Verbesserungen bringen als alles verändern
    • Beim Übergang von GPT-3 zu GPT-3.5 bestand die Erwartung, dass eine Verdopplung der Trainingsintensität zu einer überproportionalen Leistungssteigerung von 2,2x führen könnte
    • Tatsächlich wirkt die Entwicklung eher logarithmisch, während für inkrementelle Verbesserungen die Token-Geschwindigkeit und die Kosten pro Token exponentiell steigen
  • GPT-4 könnte für das aktuelle Aufgabenset bereits der optimale Punkt sein
    • Im Vergleich zu GPT-3.5 wäre man bereit gewesen, für GPT-4 den 20-fachen Preis zu zahlen, aber vermutlich nicht noch einmal das 20-Fache pro Token für den Schritt von GPT-4 zu GPT-5
    • GPT-5 könnte das widerlegen, oder der Sprung könnte eher dem vom iPhone 4 zum iPhone 5 entsprechen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-14
Hacker-News-Kommentare

  • Das Team, für das ich verantwortlich bin, verarbeitet jeden Monat mehr als 5 Milliarden Token, und die Zahl steigt weiter; dabei haben wir ein paar Dinge gelernt.
    Erstens gibt es viel zu viel zu frühe Abstraktion. Tools wie Langchain können irgendwann nützlich sein, aber letztlich sind Prompts auch nur API-Aufrufe, und statt LLM-Aufrufe als etwas Besonderes zu behandeln, ist es einfacher, sie im Standardcode wie instabile API-Aufrufe zu behandeln.
    Zweitens sind Halluzinationen eindeutig ein großes Problem. Zusammenfassungen sind in Tests recht robust, aber Schlussfolgern ist wirklich schwierig, und Handlungsmodelle, bei denen das LLM Benutzereingaben entgegennimmt und die nächste Aktion entscheidet, sind besonders schwierig, was Kontextverständnis und das Ausgeben von „Ich bin mir nicht sicher“ angeht. Trotzdem verändert schon allein die Tatsache, dass das überhaupt möglich ist, die Spielregeln.
    Drittens bin ich etwas stärker als der Autor auf der Seite von „verändert die Spielregeln“, glaube aber nicht an das Ende der Welt. Manche Berufe werden stark betroffen sein, und es könnten ein paar harte Jahre kommen, in denen Bots auf Plattformen die öffentliche Meinung manipulieren. Insgesamt wirkt es eher wie ein Fähigkeitsverstärker als wie ein Durchbruch vom Kaliber des Internets.
    Persönlich erinnert mich das an die DevOps-Veränderungen der 2000er. Man braucht heute kein riesiges dediziertes Team mehr, das Deployments unterstützt; man stellt ein paar Experten ein und kauft für den Rest fertige Lösungen. Genauso kann ich als Webentwickler wie ich inzwischen manche Machine-Learning-Aufgaben leicht umsetzen.

    • Diese Analogie ist nützlich, wenn man erklären will, was man von LLMs im modernen Entwicklungsablauf erwarten sollte. Sie zeigt nämlich, dass es sich nicht um eine Universallösung handelt, sondern um einen Kompromiss.
      Auch die Entwicklung von DevOps hatte ihre Kompromisse. Die direkte Folge von „Nimm einfach AWS RDS“ war zum Beispiel der Verlust von Kernkompetenzen wie Datenbankadministration, und die Cloud-Rechnungen sind explodiert. Selbst die Betriebskosten von Startups ohne besonders große Datenmengen oder regionale Komplexität sind gestiegen, und ich denke, solche Entwicklungen haben auch zu Vorfällen wie dem großen GitLab-Ausfall und ähnlichen Störungen geführt.
    • Jemanden dazu zu bringen, „Ich bin mir nicht sicher“ zu sagen, liegt eher in der Funktion des Sprachmodells selbst. Bis zur Ausgabe verschwindet die der Berechnung innewohnende Unsicherheit innerhalb der Vorhersage.
      Das ist ähnlich wie bei der Aufforderung, Kopf oder Zahl bei einem Münzwurf zu raten, und dann „Kopf“ zu antworten: Vor der Antwort kann man eine Unsicherheit wie Pr[Kopf] = .5 angeben, aber in der tatsächlichen Vorhersage und im Ergebnis des Münzwurfs verschwindet diese Unsicherheit. Auch bei LLMs verschwindet die Unsicherheit während der Berechnung in der finalen Token-Vorhersage, daher wird eine Ausgabe wie „Ich habe das nicht verstanden“ kaum erscheinen, außer wenn die Vorhersage selbst ein Ausdruck von Unsicherheit ist. Der Grund dafür ist allerdings, dass sie von vornherein nicht verstehen, sondern vorhersagen.
    • Über die DevOps-Analogie hatte ich vorher nie nachgedacht, aber sie passt irgendwie so gut, dass ich gerade auf Basis dieser Idee einen Text geschrieben habe: https://kenkantzer.com/gpt-is-the-heroku-of-ai
      Im Grunde verwenden wir GPT im AI-Betrieb als ein Äquivalent zu PaaS/Heroku/Render.
    • Ich stimme der Aussage zu, dass es „eher ein Fähigkeitsverstärker als ein Durchbruch wie das Internet“ ist. Auch Kunden erleben angesichts der Kosten großer Modelle im Verhältnis zum Output einen Preisschock. Mit der Zeit werden die Kosten sinken.
    • Ich kann die Aussage nachvollziehen, dass Zusammenfassung robust ist, Schlussfolgern aber schwierig. Nach Analogien zu fragen war interessant und überraschend nützlich.

  • Der Teil „Wir extrahieren immer JSON. JSON-Modus ist nicht nötig“ macht mich neugierig. Bei mir hat das ziemlich gut funktioniert.
    Mit „Lesson 4: GPT ist wirklich schlecht darin, die Nullhypothese zu bilden“ gehe ich total mit. Erst gestern habe ich beim Testen eines Prompts mit Regeln zur Textbearbeitung am Ende geschrieben: „Wenn keine der Regeln auf den Text zutrifft, gib den Originaltext unverändert zurück.“
    Wisst ihr, was ChatGPT bei einem Text geantwortet hat, auf den keine einzige Regel zutraf? Buchstäblich die Zeichenkette „The original text without any changes“.

    • Es gibt Geschichten über launische Genies, die den Wortlaut eines Wunsches wörtlich auslegen und dadurch einen verfluchten Wunsch erfüllen; genau das haben wir gerade. Leute, die lange mit Prompts für Bildgenerierungsmodelle gearbeitet haben, haben dafür schon ein gewisses Gefühl, aber für Menschen, die wegen LLMs dazugestoßen sind, kann das ziemlich überraschend sein.
      Ich habe einmal für Tarotkarten ein Bild von drei Frauen erstellt, die in einem wunderschönen Garten Wein trinken, und am Ende des Prompts „lush vegetation“ hinzugefügt; wegen der Mehrdeutigkeit von lush kippte die elegante Stimmung plötzlich in Richtung rotznasiger College-Party-Girls.
    • Ich habe das so verstanden: „Unsere Methode funktioniert gut genug, daher brauchen wir keinen JSON-Modus.“ Bei unserer Firma ist es genauso. Das läuft seit einem Jahr in Produktion, und wir mussten es nicht ändern. Unsere Prompts sorgen ziemlich zuverlässig dafür, dass GPT-3.5 immer JSON ausgibt.
    • Wenn man sich Websites über misslungene Tortendekorationen ansieht, merkt man, dass Menschen diese Art von Fehlern auch ständig machen.

  • Mit besseren Prompts kann man günstigere Modelle verwenden.
    „Wenn du nichts findest, gib nichts zurück“ ist ein Level-0-Ansatz, der dem LLM einen einfachen Ausweg gibt. Es ist besser, einen weicheren Fluchtweg zu bieten. Zum Beispiel so: „Wenn nicht genügend Informationen für eine abschließende Aussage vorliegen, erkläre das ausdrücklich; du darfst aber eine Hypothese aufstellen, solange du ihre Begründung und logische Grundlage angibst.“ Danach lässt man es am Ende seine eigene Antwort bewerten.

    • Prompts sollte man nicht abstrakt entwickeln. Das Ziel eines Prompts ist es, die internen Repräsentationen des Modells so zu aktivieren, dass es die Aufgabe bestmöglich ausführt.
      Wenn es keine automatisierte Methode gibt, muss man wiederholt testen, wie das Modell auf verschiedene Eingaben reagiert, um zu verstehen, wie es die Anfrage interpretiert, wo es scheitert, und diese Lücken zu schließen. Man muss sogar überprüfen, ob das Modell überhaupt weiß, was nothing bedeutet.

  • Ich habe Abos für alle drei führenden Services im LLM-Bereich und werfe ihnen häufig denselben Prompt zu; dabei ist es sehr einseitig zugunsten von GPT-4. Selbst wenn man bedenkt, dass GPT-4 seit einem Jahr draußen ist und es in der Zeit mehrere Updates gab, ist das überraschend
    Zumindest in meinem Nutzungsmuster halluziniert es auch eher selten. Claude hingegen erfindet beim Schreiben von Code ziemlich leicht plausibel klingende APIs, die es gar nicht gibt. GPT-4 ist hartnäckiger und stimmt weniger einfach zu, wenn es weiß, dass es richtigliegt. Solche Unterschiede tauchen in Metriken fast nicht auf; man merkt sie erst, wenn man es selbst benutzt

    • Bei mir war Claude 3 Opus besser als GPT-4. Es erklärt vor allem besser und, noch wichtiger, gründlicher
      Auch bei Coding-Aufgaben bitte ich eher um Erklärungen zu Themen oder Code, statt direkt Code schreiben zu lassen, und dabei liefert es deutlich nuanciertere Antworten. Wenn man lange Texte gibt und sich darüber unterhält, hat man bei Claude Opus das Gefühl, dass es den Inhalt tiefer versteht, während GPT-4 eher beim Zusammenfassen des gegebenen Textes bleibt; Claude erweitert das besser und schlussfolgert weiter
    • Ich frage mich, ob der Vergleich mit Claude Opus war oder mit einer kleineren Variante. Opus gefällt mir für englisches Copywriting wirklich sehr
    • GPT-4 kommt besser mit Prompts zurecht, die schlecht geformt, informationsarm oder chaotisch strukturiert sind. Wenn man einen großen Prompt nicht intelligent strukturiert, kann Claude durcheinanderkommen und nicht genau verstehen, worum man bittet
      Bei gut aufgebauten Prompts neigt Claude Opus allerdings dazu, bessere Ausgaben als GPT-4 zu liefern. Claude ist flexibler und liefert längere Antworten, während ChatGPT/GPT-4 immer etwas nach seinen typischen kurzen und „standardisierten“ Antworten klingt
    • Bei mir war die Erfahrung genau umgekehrt. Ich habe mehrere Services abonniert und kopiere dieselben Fragen hinein; bei Fragen zur Softwareentwicklung liegt Claude Opus so deutlich vorn, dass ich denke, ich könnte GPT-4 vielleicht gar nicht mehr brauchen
      Der von GPT-4 erzeugte Code aus angeforderten Beispielen ließ sich oft nicht einmal kompilieren, bei Claude ist mir das fast nie passiert
    • Ich abonniere ebenfalls alle drei Services und vergleiche sie genauso, besonders wenn eine neue Version erscheint
      Mein aktueller Lackmustest ist: „Nenne mir 10 ungewöhnliche Bars im Umkreis von 200 Meilen um Austin.“ Das ist für alle extrem schwer; GPT-4 lag halbwegs nah dran, Claude hat einfach Dinge erfunden und Gemini ist komplett zusammengebrochen

  • GPT ist sehr cool, aber der Interpretation der zwei Absätze im Artikel stimme ich überhaupt nicht zu
    Man kann zusammenfassen, dass ein besserer Ansatz etwa gewesen wäre: „GPT, du kennst die 50 Bundesstaaten eindeutig; gib den vollständigen Namen des zutreffenden Staates an oder antworte mit Federal, falls es die US-Bundesregierung betrifft“
    Aber die Deutung, dass die Qualität und Generalisierung von GPT besser würden, wenn man es vager formuliert, und dass das ein typisches Zeichen hochstufiger Delegation bzw. hochstufigen Denkens sei, halte ich für überzogen. Natürliche Sprache ist für GPT einfach die wahrscheinlichste Ausgabe, weil sie den Texten ähnelt, auf denen es trainiert wurde. In diesem Fall hat sich der Entwickler nur stärker in die Richtung gelehnt, in der GPT gut ist, statt ihm mehr Arbeit zu geben
    Es gibt viele einfache Aufgaben, an denen GPT scheitert. Zeichenersetzung oder absichtliche Tippfehler sind für GPT sehr schwer. Dasselbe gilt für ID-Mappings, besonders wenn sie stark von den Mappings abweichen, die es im Training gesehen hat. Ein Beispiel wären dreibuchstabige Codes, die Ländern zugeordnet sind, aber nicht ISO entsprechen
    Interessant ist vielmehr, dass GPT das Mapping überhaupt „versteht“. Das ist für mich eher der eigentliche Hinweis auf hochdimensionales Pattern Matching

    • Oder es könnte das Mapping einfach auswendig gelernt haben. Nicht im Sinn einer exakten Reproduktion, sondern dass es Vektoren hat, die früher gesehenen Mappings ähneln

  • Ein Tipp zum „null“-Problem: LLMs sind dafür gebaut, Tokens auszugeben, nicht dafür, keine Tokens auszugeben
    Daher sollte man statt „gib nichts zurück“ eher sagen: „gib den Default-Wert von XYZ zurück, wenn es kein Ergebnis gibt“, und dann im Ergebnis per Textsuche nach diesem Default-Wert, also z. B. XYZ, suchen, ähnlich wie bei einer Suche nach Zustandsnamen
    Außerdem können System-Prompts sehr nützlich sein. Im Grunde bekommt man damit die Gelegenheit, das LLM X spielen zu lassen. Es wäre schön, wenn man den System-Prompt direkt durchreichen könnte, aber selbst so ist es besser als nichts

  • Dass GPT keine Liste mit mehr als 10 JSON-Objekten korrekt zurückgeben kann, ist ein Prompt-Problem. Ich habe es schon dazu gebracht, bis zu 200 korrekt und in der richtigen Reihenfolge stabil zurückzugeben
    Der Trick ist, überhaupt keine Liste zu verwenden, sondern im Output JSON-Schlüssel wie "item1": {...} zu benutzen. Wenn es für irgendeinen Input 0 bis n Outputs gibt, kann man für die Werte eine Liste verwenden

    • Es sagt dir, dass der Nutzer aus einer Kultur stammt, in der es als unhöflich und beleidigend gilt, mit einer unvollständigen Liste zu antworten
    • Es wäre gut, wenn du das genauer erklären könntest. Ich zerbreche mir daran gerade den Kopf
      Wenn ich GPT-4 eine bestehende Liste von Einträgen mit definierter Struktur gebe und es diese per Schema-Transformation in JSON umwandeln soll, funktioniert das den ganzen Tag lang problemlos. Aber sobald irgendeine Form von Schlussfolgern nötig ist und es im Grunde seine eigene Liste erstellen muss, liefert es nur eine sehr begrenzte Teilmenge
      Ähnliche Probleme sehe ich auch bei anderen LLMs. Mich interessiert sehr, wie du das angehst

  • Aufgaben wie „Extrahiere den Firmennamen aus einem Textblock“ sollte man in zwei Schritte aufteilen
    Zuerst fragt man: „Wird in diesem Textblock ein Unternehmen erwähnt?“ Falls nicht, hat man ein null-Ergebnis. Falls ja, fragt man: „Liste die Firmennamen in diesem Textblock auf“

  • Ich nutze OpenAI-Modelle in einer persönlichen Schreib-App, und dieser Artikel trifft es wirklich gut. Im Zusammenhang mit Lesson 1, „Je weniger Prompt, desto besser“, habe ich etwas gelernt
    Ich wollte eine intelligente Suchfunktion für Notizen bauen und ChatGPT dazu bringen, strukturierte JSON-Daten zurückzugeben. Zum Beispiel wollte ich fragen: „Gib mir alle meine Notizen, die Haskell erwähnen, als Entwurf markiert sind und innerhalb der letzten zwei Jahre erstellt wurden“, und ChatGPT selbst entscheiden lassen, was es zurückgeben soll. Das funktionierte nur gelegentlich
    Stattdessen habe ich die Daten in eine SQLite-Datenbank gelegt, ChatGPT das Schema geschickt und es die Abfrage schreiben lassen, die die gewünschten Ergebnisse liefert. Das funktionierte deutlich besser

    • Dafür scheinen eine Datenbank und gute Suchfilter besser geeignet zu sein als ein LLM
    • Ich frage mich, ob du response_format=json_object ausprobiert hast
      Für strukturierte Antworten haben Function Calls besser gepasst, aber sie sind stärker eingeschränkt, als einfach nur einen JSON-Body zu bekommen

  • Dass die Genauigkeit sinkt, wenn man zu präzise anweist, ergibt für mein grobes Verständnis davon, wie solche Systeme funktionieren, Sinn
    Wenn man die vollständige Liste der Bundesstaaten hineinkippt, aktiviert man gewissermaßen bis zu einem gewissen Grad Vektoren für alle Staaten. Wenn man einfach „state“ sagt und im übergebenen Text ein expliziter Staat vorkommt, werden weniger Vektoren aktiviert, die mit dem Gesuchten zusammenhängen. Dadurch ist es bei der Softmax-Berechnung wahrscheinlicher, dass der richtige Staat ausgewählt wird
    Im selben Zusammenhang liegt der Vergleich zwischen /n und Kommas wahrscheinlich ebenfalls an Unterschieden bei der Tokenisierung