Was ich in einem Jahr Bauen mit LLMs gelernt habe

• Die Entwicklung mit Large Language Models (LLMs) ist derzeit eine spannende Phase.
  • Im vergangenen Jahr haben LLMs ein Niveau erreicht, das für reale Anwendungen „gut genug“ ist, und sie werden jedes Jahr besser und günstiger.
  • Zusammen mit Demos in den sozialen Medien wird geschätzt, dass bis 2025 rund 200 Milliarden US-Dollar in AI investiert werden.
  • Durch die APIs der Anbieter sind LLMs leichter zugänglich geworden, sodass nicht nur ML-Ingenieure und Wissenschaftler, sondern praktisch alle Intelligence in Produkte einbauen können.
• Die Einstiegshürde für das Bauen mit AI ist gesunken, aber wirksame Produkte und Systeme zu schaffen, die über eine Demo hinausgehen, bleibt weiterhin schwierig.
• Wir haben im vergangenen Jahr daran gebaut und dabei viele Schwierigkeiten entdeckt.
  • Wir möchten teilen, was wir gelernt haben, damit andere unsere Fehler vermeiden und schneller iterieren können.
• Dieser Artikel besteht aus drei Teilen:
  1. Tactical (taktisch): einige Praktiken für Prompting, RAG, Workflow-Engineering, Evaluierung und Monitoring
     • Geschrieben für Praktiker, die mit LLMs bauen, oder für Leute mit Wochenendprojekten
  2. Operational (operativ): organisatorische und alltägliche Fragen beim Produkt-Launch sowie der Aufbau effektiver Teams
     • Für Produkt- und Tech-Leads, die nachhaltig und stabil ausrollen wollen
  3. Strategic (strategisch): langfristige, übergreifende Perspektiven und Wege zur Iteration mit Thesen wie „keine GPU vor PMF“ und „auf Systeme statt auf Modelle fokussieren“
     • Mit Blick auf Gründer und Führungskräfte geschrieben
• Dieser Leitfaden will ein praxisnaher Wegweiser für den Aufbau erfolgreicher Produkte mit LLMs sein.
  • Er basiert auf unseren eigenen Erfahrungen und zeigt Beispiele aus der gesamten Branche.

[Taktik: Der Kern der LLM-Nutzung]

• In diesem Abschnitt teilen wir Best Practices zu den zentralen Bausteinen des neu entstehenden LLM-Stacks.
  • Dazu gehören Prompting-Tipps zur Verbesserung von Qualität und Zuverlässigkeit, Strategien zur Bewertung von Ausgaben sowie Ideen für Retrieval Augmented Generation zur besseren Grounding-Qualität.
  • Außerdem untersuchen wir, wie man Human-in-the-Loop-Workflows entwirft.

Taktik 1. Prompting

• Bei der Entwicklung neuer Anwendungen empfehlen wir, mit Prompting zu beginnen.
  • Es ist leicht, die Bedeutung von Prompting zu unterschätzen oder zu überschätzen.
  • Es wird tendenziell unterschätzt, weil man mit den richtigen Prompting-Techniken sehr weit kommen kann.
  • Es wird tendenziell überschätzt, weil auch promptbasierte Anwendungen viel Engineering rund um den Prompt benötigen, um wirklich gut zu funktionieren.

Darauf fokussieren, grundlegende Prompting-Techniken maximal auszuschöpfen

• Es gibt einige Prompting-Techniken, die bei verschiedenen Modellen und Aufgaben kontinuierlich zu Leistungsverbesserungen beitragen.
  • Dazu gehören N-shot-Prompts + In-Context Learning, Chain-of-Thought und das Bereitstellen relevanter Ressourcen.
• N-shot-Prompts und In-Context Learning
  • Die Idee hinter In-Context Learning mit N-shot-Prompts ist, dem LLM die Aufgabe anhand einiger Beispiele vorzuführen und die Ausgabe an die Erwartungen anzupassen.
  • Wenn N zu niedrig ist, kann sich das Modell zu stark an diese konkreten Beispiele klammern, was die Generalisierungsfähigkeit verschlechtert.
  • Aus Erfahrung sollte man N ≥ 5 anstreben und sich nicht scheuen, auch einige Dutzend zu verwenden.
  • Die Beispiele sollten repräsentativ für die erwartete Eingabeverteilung sein.
  • Es ist nicht nötig, vollständige Ein-/Ausgabe-Paare bereitzustellen; in vielen Fällen reichen Beispiele der gewünschten Ausgabe.
  • Wenn man ein LLM verwendet, das Tool-Nutzung unterstützt, sollten auch die N-shot-Beispiele die Tools verwenden, die der Agent später nutzen soll.
• Chain-of-Thought-(CoT-)Prompting
  • Beim CoT-Prompting wird das LLM dazu angeregt, seinen Denkprozess zu erläutern, bevor es die endgültige Antwort zurückgibt.
  • Man kann es sich so vorstellen, als gäbe man dem LLM einen Notizblock, damit es nicht alles aus dem Gedächtnis erledigen muss.
  • Der ursprüngliche Ansatz bestand einfach darin, eine Formulierung wie „Lass uns Schritt für Schritt nachdenken“ als Teil der Anweisung hinzuzufügen, aber wir haben festgestellt, dass es hilft, CoT konkreter zu machen.
  • Bereits 1–2 zusätzliche Sätze mit mehr Konkretheit senken die Halluzinationsrate oft deutlich.
  • In letzter Zeit wird allerdings infrage gestellt, ob diese Technik wirklich so wirkungsvoll ist, wie viele glauben.
  • Außerdem gibt es erhebliche Debatten darüber, was bei der Inferenz genau passiert, wenn CoT eingesetzt wird.
  • Dennoch ist es eine Technik, mit der man nach Möglichkeit experimentieren sollte.
• Relevante Ressourcen bereitstellen
  • Das Bereitstellen relevanter Ressourcen ist ein wirkungsvoller Mechanismus, um die Wissensbasis des Modells zu erweitern, Halluzinationen zu verringern und das Vertrauen der Nutzer zu stärken.
  • Häufig geschieht dies über Retrieval Augmented Generation (RAG).
  • Dem Modell Text-Snippets bereitzustellen, die es direkt in der Antwort verwenden kann, ist eine essenzielle Technik.
  • Beim Bereitstellen relevanter Ressourcen reicht bloßes Einfügen jedoch nicht aus.
    • Man sollte dem Modell ausdrücklich vorgeben, die Ressourcen zu priorisieren, direkt darauf Bezug zu nehmen und mitunter zu erwähnen, wenn die Ressourcen nicht ausreichen.
  • All dies hilft dabei, Agent-Antworten im Ressourcenkorpus zu „grounden“.

Eingaben und Ausgaben strukturieren

• Strukturierte Eingaben und Ausgaben helfen dem Modell, Eingaben besser zu verstehen und Ausgaben zurückzugeben, die sich zuverlässig in nachgelagerte Systeme integrieren lassen.
  • Das Hinzufügen eines Serialisierungsformats zu den Eingaben kann helfen, Beziehungen zwischen Tokens im Kontext, zusätzliche Metadaten zu bestimmten Tokens (etwa Typen) oder die Verknüpfung der Anfrage mit ähnlichen Beispielen aus den Trainingsdaten des Modells abzubilden.
  • So beginnen etwa viele Fragen im Internet zum Schreiben von SQL mit der Angabe des SQL-Schemas.
    • Effektives Prompting für Text-to-SQL sollte daher strukturierte Schemadefinitionen enthalten.
• Strukturierte Ausgaben erfüllen einen ähnlichen Zweck, vereinfachen aber die Integration in nachgelagerte Komponenten des Systems.
  • Instructor und Outlines funktionieren gut für strukturierte Ausgaben.
    • (Instructor verwenden, wenn man ein LLM-API-SDK einbindet, und Outlines, wenn man Huggingface für selbst gehostete Modelle einbindet.)
  • Strukturierte Eingaben erhöhen die Wahrscheinlichkeit besserer Ausgaben, weil sie die Aufgabe klar ausdrücken und dem Format der Trainingsdaten ähneln.
• Bei der Verwendung strukturierter Eingaben sollte man beachten, dass jede LLM-Familie ihre bevorzugte Form hat.
  • Claude bevorzugt <xml>, während GPT Markdown und JSON bevorzugt.
  • Mit XML kann man Claudes Antwort auch vorab füllen, indem man ein <response>-Tag bereitstellt.

Kleine Prompts erstellen, die jeweils eine Sache gut machen

• Ein verbreitetes Anti-Pattern bzw. ein typischer Code Smell in der Softwareentwicklung ist das „God Object“, also eine einzelne Klasse oder Funktion, die alles erledigt.
  • Dasselbe gilt für Prompts.
• Prompts beginnen in der Regel einfach.
  • Man startet vielleicht mit ein paar Sätzen an Anweisungen und einigen Beispielen.
  • Doch wenn man die Leistung verbessern und mehr Edge Cases abdecken will, steigt die Komplexität.
    • Es kommen mehr Anweisungen, mehrstufiges Reasoning, Dutzende Beispiele usw. hinzu.
  • Am Ende wird aus dem anfangs einfachen Prompt ein 2.000-Token-Frankenstein.
    • Hinzu kommt, dass die Leistung bei allgemeineren und intuitiveren Eingaben sogar sinkt.
    • GoDaddy nennt dieses Problem als wichtigste Lektion aus dem Bauen mit LLMs.
• So wie man versucht, Systeme und Code einfach zu halten, sollte man es auch mit Prompts handhaben.
  • Statt für einen Zusammenfasser von Meeting-Transkripten einen einzigen universellen Prompt zu verwenden, kann man den Prozess in Schritte aufteilen, etwa:
    • wichtige Entscheidungen, Action Items und Verantwortliche in einem strukturierten Format extrahieren
    • die extrahierten Details mit dem Originaltranskript auf Konsistenz prüfen
    • aus den strukturierten Details eine knappe Zusammenfassung erzeugen
• Das Ergebnis ist, dass man einen einzelnen Prompt in mehrere einfache, fokussierte und leicht verständliche Prompts aufteilt.
  • Durch diese Aufteilung kann man nun jeden Prompt einzeln iterieren und evaluieren.

Kontext-Tokens erstellen

• Annahmen über die Menge an Kontext, die tatsächlich an den Agenten gesendet werden muss, sollten überdacht und hinterfragt werden
  • Man sollte nicht wie Michelangelo eine Kontextskulptur aufbauen, sondern unnötiges Material wegmeißeln, um die Skulptur freizulegen
  • RAG ist eine weit verbreitete Methode, um alle potenziell relevanten Marmorblöcke zusammenzutragen, aber was wird getan, um das tatsächlich Benötigte herauszuziehen?
• Es hat sich gezeigt, dass es hilft, den endgültigen Prompt, der an das Modell gesendet wird, zusammen mit der gesamten Kontextzusammenstellung, Meta-Prompting und den RAG-Ergebnissen auf eine leere Seite zu setzen und zu lesen, um den Kontext neu zu bewerten
  • Mit dieser Methode lassen sich Redundanzen, sich selbst widersprechende Formulierungen und falsch formatierte Stellen finden
• Eine weitere zentrale Optimierung ist die Struktur des Kontexts
  • Eine Bag-of-docs-Darstellung hilft Menschen nicht, daher sollte man nicht annehmen, dass sie für Agenten gut ist
  • Es sollte sorgfältig darüber nachgedacht werden, wie der Kontext so aufgebaut wird, dass die Beziehungen zwischen den einzelnen Teilen hervorgehoben werden und das Extrahieren so einfach wie möglich wird

Taktik 2. Information Retrieval / RAG

• Neben dem Prompting ist eine weitere effektive Methode zur Steuerung von LLMs, Wissen als Teil des Prompts bereitzustellen
  • Dadurch wird das LLM im bereitgestellten Kontext verankert, was für In-Context-Learning genutzt wird
  • Dies wird Retrieval-Augmented Generation (RAG) genannt
  • Praktiker haben festgestellt, dass RAG effektiv Wissen bereitstellt und die Ausgaben verbessert, dabei aber deutlich weniger Aufwand und Kosten verursacht als Fine-Tuning
  • RAG ist nur so gut wie die Relevanz, Dichte und Detailtiefe der abgerufenen Dokumente

Die Qualität der RAG-Ausgabe hängt von der Qualität der abgerufenen Dokumente ab, wobei mehrere Faktoren berücksichtigt werden können

• Die erste und offensichtlichste Kennzahl ist „Relevanz“
  • Diese wird üblicherweise durch Ranking-Metriken wie Mean Reciprocal Rank (MRR) oder Normalized Discounted Cumulative Gain (NDCG) quantifiziert
  • MRR bewertet, wie gut ein System das erste relevante Ergebnis in einer Rangliste platziert, während NDCG die Relevanz und Position aller Ergebnisse berücksichtigt
  • Sie messen die Leistung eines Systems dabei, relevante Dokumente höher und irrelevante Dokumente niedriger zu ranken
  • Wenn zum Beispiel Nutzerzusammenfassungen abgerufen werden, um eine Zusammenfassung von Filmkritiken zu erzeugen, sollten Rezensionen zu einem bestimmten Film höher gerankt und Rezensionen zu anderen Filmen ausgeschlossen werden
  • Wie bei klassischen Empfehlungssystemen hat das Ranking der abgerufenen Elemente erheblichen Einfluss darauf, wie das LLM die nachgelagerte Aufgabe ausführt
  • Um den Einfluss zu messen, sollte man die RAG-basierte Aufgabe einmal mit durchgemischten abgerufenen Elementen ausführen und prüfen, wie sich die RAG-Ausgabe verhält
• Zweitens ist da die „Informationsdichte“
  • Wenn zwei Dokumente gleich relevant sind, sollte das prägnantere Dokument mit weniger irrelevanten Details bevorzugt werden
  • Um auf das Filmbeispiel zurückzukommen: Ein Filmdrehbuch und alle Nutzerrezensionen könnten im weiten Sinne als relevant gelten
  • Dennoch haben hoch bewertete Rezensionen und redaktionelle Besprechungen wahrscheinlich eine höhere Informationsdichte
• Schließlich sollte das „Detailniveau“ der im Dokument bereitgestellten Informationen berücksichtigt werden
  • Stellen wir uns vor, man baut ein RAG-System, das aus natürlicher Sprache SQL-Abfragen erzeugt
    • Es könnte bereits ausreichen, das Tabellenschema mit den Spaltennamen als Kontext bereitzustellen
    • Aber was ist, wenn zusätzlich Spaltenbeschreibungen und einige repräsentative Werte aufgenommen werden?
  • Zusätzliche Details können dem LLM helfen, die Bedeutung der Tabelle besser zu verstehen und präzisere SQL-Abfragen zu erzeugen

Keyword-Suche nicht vergessen und sie für Baselines und hybride Suche nutzen

• Weil Embedding-basierte RAG-Demos weit verbreitet sind, ist es leicht, Jahrzehnte an Forschung und Lösungen im Bereich Information Retrieval zu vergessen oder zu übersehen
  • Dennoch sind Embeddings zweifellos ein mächtiges Werkzeug, aber kein Allheilmittel
• Vorteile keyword-basierter Suche
  • Erstens sind Embeddings hervorragend darin, semantische Ähnlichkeit auf hoher Ebene zu erfassen, können aber bei spezifischeren, keyword-basierten Suchanfragen Schwierigkeiten haben, etwa wenn Nutzer nach Namen (z. B. Ilya), Akronymen (z. B. RAG) oder IDs (z. B. claude-3-sonnet) suchen
    • Keyword-basierte Suche wie BM25 ist genau dafür explizit ausgelegt
    • Nutzer haben keyword-basierte Suche lange verwendet und nehmen sie daher als selbstverständlich hin; wenn das gesuchte Dokument nicht zurückgegeben wird, kann das frustrierend sein
  • Zweitens ist es intuitiver zu verstehen, warum ein Dokument durch Keyword-Suche gefunden wurde
    • Denn man kann die Keywords sehen, die mit der Anfrage übereinstimmen
    • Embedding-basierte Suche ist dagegen weniger gut interpretierbar
  • Drittens ist Keyword-Suche im Allgemeinen recheneffizienter, dank Systemen wie Lucene oder OpenSearch, die über Jahrzehnte optimiert und in der Praxis bewährt wurden
• In den meisten Fällen ist ein hybrider Ansatz am effektivsten
  • Für offensichtliche Treffer Keyword-Matching verwenden und für Synonyme, Oberbegriffe, Tippfehler und Multimodalität (z. B. Bilder und Text) Embeddings einsetzen
  • Shortwave hat geteilt, wie sie ihre RAG-Pipeline aufgebaut haben, einschließlich Query-Rewriting, Keyword- + Embedding-Suche und Ranking

Für neues Wissen RAG gegenüber Fine-Tuning bevorzugen

• Sowohl RAG als auch Fine-Tuning können verwendet werden, um neue Informationen in ein LLM zu integrieren und die Leistung bei bestimmten Aufgaben zu verbessern
  • Was sollte man also zuerst versuchen?
• Vorteile von RAG
  • Jüngere Forschung legt nahe, dass RAG überlegen sein kann
  • Eine Studie verglich RAG und unüberwachtes Fine-Tuning (auch als fortlaufendes Pretraining bezeichnet), indem beide auf einer Teilmenge von MMLU und aktuellen Themen evaluiert wurden
    • RAG zeigte sowohl bei Wissen, dem das Modell während des Trainings begegnet war, als auch bei völlig neuem Wissen durchgängig bessere Leistung als Fine-Tuning
  • Eine weitere Arbeit verglich RAG und überwachtes Fine-Tuning für einen Agrardatensatz
    • Auch hier war der Leistungsgewinn durch RAG größer als durch Fine-Tuning, insbesondere bei GPT-4 (siehe Tabelle 20 der Arbeit)
  • Über die Leistungsverbesserung hinaus hat RAG mehrere praktische Vorteile
    • Erstens ist es einfacher und günstiger, einen Retrieval-Index aktuell zu halten, als fortlaufendes Pretraining oder Fine-Tuning durchzuführen
    • Zweitens lassen sich problematische Dokumente leicht löschen oder korrigieren, wenn der Retrieval-Index schädliche oder verzerrte Inhalte enthält
  • Darüber hinaus bietet das R in RAG eine feinere Kontrolle darüber, wie Dokumente abgerufen werden
    • Wenn man beispielsweise ein RAG-System für mehrere Organisationen hostet, kann der Retrieval-Index partitioniert werden, sodass jede Organisation nur Dokumente aus ihrem eigenen Index abrufen kann
    • So kann verhindert werden, dass Informationen einer Organisation versehentlich einer anderen offengelegt werden

Long-Context-Modelle werden RAG nicht nutzlos machen

• Da Gemini 1.5 ein Kontextfenster von bis zu 10 Millionen Tokens bietet, beginnen einige, die Zukunft von RAG infrage zu stellen
  • Ein Kontextfenster von 10 Millionen Tokens macht die meisten bestehenden RAG-Frameworks überflüssig
    • Man muss die Daten nur in den Kontext packen und wie gewohnt mit dem Modell sprechen
  • Man stelle sich vor, welche Auswirkungen das auf Startups, Agenten und LangChain-Projekte hat, bei denen der Großteil der Engineering-Arbeit in RAG fließt
    • In einem Satz zusammengefasst: 10 Millionen Kontext töten RAG
• Der anhaltende Bedarf an RAG
  • Zwar stimmt es, dass Long-Context für Anwendungsfälle wie die Analyse mehrerer Dokumente oder Chatten mit PDFs ein Game Changer sein wird, doch die Gerüchte über das Ende von RAG sind stark übertrieben
    • Erstens braucht man selbst mit einem Kontextfenster von 10 Millionen Tokens weiterhin eine Methode, um auszuwählen, welche Informationen dem Modell gegeben werden
    • Zweitens habe ich jenseits enger Needle-in-a-Haystack-Benchmarks noch keine überzeugenden Daten gesehen, dass Modelle über derart große Kontexte hinweg effektiv schlussfolgern können
    • Ohne gute Retrieval-Mechanismen (und Ranking) besteht daher das Risiko, das Modell mit ablenkenden Informationen zu überfordern oder das Kontextfenster sogar mit völlig irrelevanten Informationen zu füllen
• Schließlich gibt es noch die Kostenfrage
  • Die Inferenzkosten von Transformern steigen quadratisch mit der Kontextlänge an (oder linear sowohl im Speicher- als auch im Zeitbedarf)
  • Nur weil es ein Modell geben könnte, das den gesamten Inhalt des Google Drive einer Organisation lesen kann, heißt das nicht, dass es sinnvoll ist, dies vor jeder einzelnen Frage zu tun
  • Betrachten wir eine Analogie zur Nutzung von RAM
    • Es gibt Computing-Instanzen mit Dutzenden Terabyte RAM, und trotzdem wird weiterhin auf Festplatte gelesen und geschrieben
• Deshalb sollte man RAG noch nicht in den Mülleimer werfen
  • Dieses Muster wird auch bei weiter wachsenden Kontextfenstern nützlich bleiben

Taktik 3. Workflow-Tuning und -Optimierung

• Ein LLM zu prompten, ist nur der Anfang
  • Um das Maximum aus LLMs herauszuholen, muss man über einen einzelnen Prompt hinausdenken und Workflows einbeziehen
  • Wie lässt sich beispielsweise eine komplexe Einzelaufgabe in mehrere einfachere Aufgaben aufteilen?
  • Wann helfen Fine-Tuning oder Caching dabei, die Performance zu steigern und Latenz/Kosten zu senken?
• In diesem Abschnitt werden bewährte Strategien und reale Beispiele geteilt, um beim Optimieren und Aufbauen von LLM-Workflows zu helfen

Schrittweise, mehrturnige „Flows“ können große Performance-Steigerungen liefern

• Es ist bereits bekannt, dass sich bessere Ergebnisse erzielen lassen, wenn man einen großen Prompt in mehrere kleine Prompts zerlegt
  • AlphaCodium ist ein Beispiel dafür
    • Durch den Wechsel von einem einzelnen Prompt zu einem mehrstufigen Workflow wurde die GPT-4-Genauigkeit (pass@5) bei CodeContests von 19 % auf 44 % erhöht
  • Der Workflow umfasst
    • Nachdenken über das Problem
    • Schlussfolgern über öffentliche Tests
    • Erzeugen möglicher Lösungen
    • Einordnen möglicher Lösungen
    • Erzeugen synthetischer Tests
    • Iterieren der Lösungen anhand öffentlicher und synthetischer Tests
• Kleine Aufgaben mit klaren Zielen ergeben die besten Agent- oder Flow-Prompts
  • Nicht jeder Agent-Prompt muss strukturierte Ausgaben verlangen, aber strukturierte Ausgaben helfen sehr bei der Schnittstelle zu Systemen, die die Interaktion des Agenten mit seiner Umgebung koordinieren
• Dinge, die man ausprobieren sollte
  • Möglichst strikt spezifizierte, explizite Planungsschritte
    • Erwäge, aus vordefinierten Plänen auswählen zu lassen
  • Den ursprünglichen User-Prompt in einen Agent-Prompt umschreiben
    • Dabei kann Informationsverlust entstehen, also Vorsicht
  • Agent-Verhalten als lineare Kette, DAG und Zustandsmaschine
    • Unterschiedliche Abhängigkeiten und logische Beziehungen können für unterschiedliche Skalierungen besser oder schlechter geeignet sein
    • Lässt sich aus unterschiedlichen Task-Architekturen eine Performance-Optimierung herausholen?
  • Planvalidierung
    • Ein Plan kann Anweisungen enthalten, wie die Antworten anderer Agenten bewertet werden sollen, damit das Endergebnis gut funktioniert
  • Prompt Engineering mit festem Upstream-Zustand
    • Stelle sicher, dass Agent-Prompts gegen die verschiedenen möglichen früheren Varianten evaluiert werden

Vorerst deterministischen Workflows Priorität geben

• AI-Agenten können dynamisch auf User-Anfragen und ihre Umgebung reagieren, aber ihre nichtdeterministische Natur erschwert den produktiven Einsatz
  • Jeder Schritt, den ein Agent ausführt, kann fehlschlagen, und die Wahrscheinlichkeit, sich von Fehlern zu erholen, ist gering
  • Daher sinkt die Wahrscheinlichkeit, dass ein Agent eine mehrstufige Aufgabe erfolgreich abschließt, mit zunehmender Schrittzahl exponentiell
  • Infolgedessen tun sich Teams, die Agenten bauen, schwer damit, verlässliche Agenten auszurollen
• Ein vielversprechender Ansatz besteht darin, ein Agentensystem zu haben, das einen deterministischen Plan erzeugt und ihn dann strukturiert und reproduzierbar ausführt
  • Im ersten Schritt erzeugt der Agent einen Plan, wenn ein übergeordnetes Ziel oder ein Prompt vorgegeben wird
  • Anschließend wird der Plan deterministisch ausgeführt
  • Dadurch wird jeder einzelne Schritt besser vorhersagbar und verlässlicher
  • Vorteile
    • Der erzeugte Plan kann als Few-Shot-Beispiel genutzt werden, um Agenten zu prompten oder feinzujustieren
    • Deterministische Ausführung macht das System verlässlicher und erleichtert Tests und Debugging. Außerdem lassen sich Fehler auf einen bestimmten Planschritt zurückführen
    • Der erzeugte Plan kann als gerichteter azyklischer Graph (DAG) dargestellt werden und ist damit leichter zu verstehen und an neue Situationen anzupassen als ein statischer Prompt
• Die erfolgreichsten Agent-Builder könnten am Ende Menschen sein, die viel Erfahrung im Führen von Junior Engineers haben
  • Denn der Prozess der Planerstellung ähnelt der Art, wie man Juniors anleitet und steuert
  • So wie man Juniors statt vager, offener Vorgaben klare Ziele und konkrete Pläne gibt, sollte man es auch bei Agenten machen
• Letztlich liegt der Schlüssel zu verlässlichen, funktionierenden Agenten wahrscheinlich darin,
  • einen stärker strukturierten und deterministischen Ansatz zu verfolgen und
  • Daten zu sammeln, um Prompts zu verbessern und Modelle feinzujustieren
• Ohne das baut man Agenten, die manchmal sehr gut funktionieren, im Durchschnitt aber User enttäuschen und dadurch zu geringer Bindung führen

Vielfältigere Ausgaben als nur über den Temperature-Parameter

• Nehmen wir an, es gibt eine Aufgabe, bei der Vielfalt in den Ausgaben eines LLMs nötig ist
  • Vielleicht schreibt man eine LLM-Pipeline, die unter Berücksichtigung einer Liste zuvor gekaufter Produkte Produkte aus einem Katalog zum Kauf empfiehlt
  • Dann stellt man möglicherweise fest, dass die empfohlenen Ergebnisse bei mehreren Ausführungen des Prompts zu ähnlich sind
  • Daher könnte man den Temperature-Parameter der LLM-Anfrage erhöhen
• Wenn man den Temperature-Parameter erhöht, werden die Antworten des LLM vielfältiger
  • Beim Sampling wird die Wahrscheinlichkeitsverteilung für das nächste Token flacher, sodass Tokens, die normalerweise seltener gewählt würden, häufiger ausgewählt werden
• Beim Erhöhen der Temperatur können jedoch einige Failure Modes im Zusammenhang mit der Ausgabenvielfalt auftreten
  • Zum Beispiel könnten einige Produkte im Katalog geeignet sein, aber vom LLM nicht ausgegeben werden
  • Wenn das LLM den Prompt mit hoher Wahrscheinlichkeit so befolgt, wie es dies im Training gelernt hat, kann es sein, dass dieselben wenigen Produkte in den Ausgaben überrepräsentiert sind
  • Ist die Temperatur zu hoch, können Ausgaben entstehen, die sich auf nicht existierende Produkte beziehen (oder anderweitig unsinnig sind)
• Eine höhere Temperatur garantiert nicht, dass das LLM Ausgaben aus der gewünschten Wahrscheinlichkeitsverteilung sampelt (zum Beispiel gleichverteilt zufällig)
• Dennoch gibt es weitere Tricks, um die Vielfalt der Ausgaben zu erhöhen
  • Der einfachste Weg ist, Elemente innerhalb des Prompts zu verändern
    • Wenn zum Beispiel eine Prompt-Vorlage eine Liste von Einträgen wie frühere Käufe enthält, kann es einen erheblichen Unterschied machen, deren Reihenfolge bei jedem Einfügen in den Prompt zu mischen
  • Es hilft auch, eine kurze Liste der jüngsten Ausgaben zu behalten, um Wiederholungen zu vermeiden
    • Im Beispiel mit Produktempfehlungen kann man das LLM anweisen, Vorschläge aus dieser jüngsten Liste zu vermeiden, oder Antworten zusätzlich variieren, indem man Ausgaben ablehnt und neu sampelt, die jüngsten Vorschlägen zu ähnlich sind
  • Eine weitere wirksame Strategie ist es, die im Prompt verwendeten Formulierungen zu variieren
    • Das Einbauen von Formulierungen wie „Wähle Artikel aus, die der User gern regelmäßig verwenden würde“ oder „Wähle Produkte aus, die der User wahrscheinlich Freunden empfehlen würde“ kann den Fokus verschieben und so die Vielfalt der empfohlenen Produkte beeinflussen

Caching wird unterschätzt

• Caching senkt die Kosten, indem es die Notwendigkeit beseitigt, Antworten für dieselbe Eingabe erneut zu berechnen, und eliminiert die Generierungs-Latenz
  • Wenn eine Antwort zuvor bereits durch Guardrailing abgesichert wurde, kann außerdem genau diese validierte Antwort ausgeliefert werden, wodurch sich das Risiko verringert, schädliche oder unangemessene Inhalte bereitzustellen
• Ein einfacher Ansatz für Caching besteht darin, eine eindeutige ID für das verarbeitete Element zu verwenden, etwa beim Zusammenfassen neuer Artikel oder Produktrezensionen
  • Wenn eine Anfrage eingeht, kann geprüft werden, ob die Zusammenfassung bereits im Cache vorhanden ist
    • Falls ja, kann sie sofort zurückgegeben werden; falls nicht, kann sie generiert, per Guardrailing abgesichert und ausgeliefert und anschließend für künftige Anfragen im Cache gespeichert werden
• Bei offeneren Abfragen kann man Techniken aus der Suche übernehmen, um Caching auch für offene Eingaben zu nutzen
  • Funktionen wie Autovervollständigung und Rechtschreibkorrektur helfen dabei, Nutzereingaben zu normalisieren und so die Cache-Trefferquote zu erhöhen

Wann Finetuning erforderlich ist

• Es kann Aufgaben geben, bei denen selbst der intelligenteste Prompt nicht ausreicht
  • So kann ein System selbst nach erheblichem Prompt Engineering noch weit davon entfernt sein, zuverlässig hochwertige Ausgaben zurückzugeben
  • In diesem Fall kann es notwendig sein, das Modell für eine bestimmte Aufgabe feinzujustieren
• Erfolgreiche Finetuning-Beispiele
  • Honeycombs Natural Language Query Assistant
    • Anfangs wurde ein „Programmierhandbuch“ zusammen mit n-shot-Beispielen für In-Context Learning im Prompt bereitgestellt
    • Das funktionierte zwar gut, aber durch Finetuning des Modells konnten bessere Ausgaben in Bezug auf Syntax und Regeln der domänenspezifischen Sprache erzielt werden
  • Luc y von Rechat
    • Das LLM musste Antworten in einem sehr spezifischen Format erzeugen, das strukturierte und unstrukturierte Daten kombiniert, damit das Frontend korrekt rendern kann
    • Finetuning war entscheidend, damit dies konsistent funktioniert
• Finetuning kann zwar wirksam sein, ist aber mit erheblichen Kosten verbunden
  • Man muss Finetuning-Daten annotieren, das Modell feinjustieren und evaluieren und es am Ende selbst hosten
  • Deshalb sollte man abwägen, ob die höheren Anfangskosten es wert sind
• Wenn man mit Prompting bereits 90 % erreichen kann, lohnt sich die Investition in Finetuning möglicherweise nicht
  • Entscheidet man sich dennoch für Finetuning, kann man synthetische Daten erzeugen und darauf feinjustieren oder Open-Source-Daten zum Bootstrap nutzen, um die Kosten für menschlich annotierte Datensätze zu senken

Taktik 4. Evaluierung und Monitoring

• Die Evaluierung von LLMs kann ein Minenfeld sein
  • Ein- und Ausgaben von LLMs sind beliebiger Text, und auch die definierten Aufgaben sind vielfältig
  • Dennoch sind strenge und sorgfältige Evaluierungen wichtig
    • Es ist kein Zufall, dass technische Führungskräfte bei OpenAI an Evaluierungen teilnehmen und Feedback zu einzelnen Evaluierungen geben
• Die Evaluierung von LLM-Anwendungen erfordert verschiedene Definitionen und Reduktionen
  • Sie kann schlicht Unit-Testing sein, eher Observability ähneln oder einfach Data Science sein
  • Wir haben festgestellt, dass all diese Perspektiven nützlich sind
• Dieser Abschnitt liefert Erkenntnisse darüber, was beim Aufbau einer Evaluierungs- und Monitoring-Pipeline wichtig ist

Erzeuge einige assertion-basierte Unit-Tests aus realen Ein-/Ausgabebeispielen

• Erstelle aus Stichproben von Ein- und Ausgaben aus der Produktion Unit-Tests, also Assertions, und definiere Erwartungen an die Ausgabe anhand von mindestens drei Kriterien
  • Drei Kriterien mögen willkürlich erscheinen, sind aber ein praktischer Ausgangspunkt
    • Sind es weniger, ist die Aufgabe womöglich nicht ausreichend definiert oder zu offen, wie bei einem allgemeinen Chatbot
  • Diese Unit-Tests oder Assertions sollten durch Änderungen an der Pipeline ausgelöst werden, etwa durch Prompt-Änderungen, das Hinzufügen neuen Kontexts per RAG oder andere Anpassungen
• Ziehe in Betracht, mit Assertions zu beginnen, die Phrasen oder Ideen festlegen, die in jeder Antwort enthalten oder ausgeschlossen sein sollen
  • Erwäge außerdem Prüfungen, ob die Zahl der Wörter, Elemente oder Sätze innerhalb eines bestimmten Bereichs liegt
  • Bei anderen Arten von Generierung können Assertions anders aussehen
    • Bei der Ausführungsevaluierung, einer robusten Methode zur Bewertung von Codegenerierung, wird etwa der erzeugte Code ausgeführt und geprüft, ob der Laufzeitzustand die Nutzeranfrage ausreichend erfüllt
• Wenn ein Nutzer zum Beispiel eine neue Funktion namens foo anfordert, sollte man nach Ausführung des vom Agenten generierten Codes foo aufrufen können
• Eine Herausforderung der Ausführungsevaluierung besteht darin, dass Agenten-Code die Laufzeitumgebung oft in einer leicht anderen Form hinterlässt als der Zielcode
  • Es kann wirksam sein, Assertions zu „lockern“, sodass sie von der schwächsten Annahme ausgehen, die jede plausible Antwort erfüllen kann
• Das Produkt wie ein Kunde auf die beabsichtigte Weise zu verwenden, also „Dogfooding“, kann Einblicke in Fehlermuster mit echten Daten liefern
  • Dieser Ansatz hilft nicht nur dabei, potenzielle Schwächen zu identifizieren, sondern liefert auch eine nützliche Quelle realer Produktionsbeispiele, die sich in Evaluierungen umwandeln lassen

LLM-as-Judge kann (bis zu einem gewissen Grad) funktionieren, ist aber kein Allheilmittel

• LLM-as-Judge ist ein Ansatz, bei dem ein leistungsfähiges LLM genutzt wird, um die Ausgaben eines anderen LLMs zu bewerten, was von manchen mit Skepsis betrachtet wird
• Dennoch kann LLM-as-Judge, wenn es gut umgesetzt ist, eine deutliche Korrelation mit menschlichen Urteilen erreichen und zumindest dabei helfen, Vorabinformationen darüber aufzubauen, wie neue Prompts oder Techniken abschneiden könnten
  • Besonders bei paarweisen Vergleichen, etwa Kontrollgruppe vs. Testgruppe, liegt LLM-as-Judge bei der Richtung meist richtig, auch wenn das Ausmaß von Sieg oder Niederlage verrauscht sein kann
• Vorschläge, um LLM-as-Judge optimal zu nutzen
  • Paarweise Vergleiche verwenden
    • Statt das LLM zu bitten, eine einzelne Ausgabe auf einer Likert-Skala zu bewerten, präsentiere zwei Optionen und lass es die bessere auswählen
    • Das führt tendenziell zu stabileren Ergebnissen
  • Positionsbias kontrollieren
    • Die Reihenfolge der präsentierten Optionen kann die Entscheidung des LLM verzerren
    • Um das abzumildern, führe jeden paarweisen Vergleich zweimal durch und tausche jedes Mal die Reihenfolge des Paars
    • Nach dem Tausch muss der Sieg der richtigen Option zugeschrieben werden
  • Unentschieden zulassen
    • In manchen Fällen können beide Optionen gleich gut sein
    • Deshalb sollte das LLM ein Unentschieden erklären dürfen, damit es nicht willkürlich einen Sieger wählen muss
  • Chain-of-Thought verwenden
    • Wenn man das LLM bittet, seine Entscheidung zu begründen, bevor es die endgültige Präferenz angibt, kann das die Zuverlässigkeit der Bewertung verbessern
    • Als Bonus kann man dadurch ein schwächeres, aber schnelleres LLM verwenden und dennoch ähnliche Ergebnisse erzielen
    • Da dieser Teil der Pipeline häufig im Batch-Modus läuft, ist die zusätzliche Latenz durch CoT kein Problem
  • Antwortlänge kontrollieren
    • LLMs neigen dazu, längere Antworten zu bevorzugen
    • Um das abzumildern, sollte man sicherstellen, dass die Längen der Antwortpaare ähnlich sind
• Eine besonders starke Anwendung von LLM-as-Judge besteht darin, neue Prompt-Strategien auf Regressionen zu prüfen
  • Wenn man eine Sammlung von Produktionsergebnissen nachverfolgt hat, kann man diese Produktionsbeispiele manchmal mit einer neuen Prompt-Strategie erneut ausführen und mithilfe von LLM-as-Judge schnell bewerten, wo die neue Strategie Schwierigkeiten haben könnte
• Ein Beispiel für einen einfachen, aber wirksamen Ansatz mit LLM-as-Judge
  • Es werden einfach die LLM-Antwort, die Kritik des Richters, also CoT, und das Endergebnis protokolliert
  • Anschließend wird dies mit Stakeholdern überprüft, um Verbesserungsbereiche zu identifizieren
  • Über drei Iterationen hinweg stieg die Übereinstimmung zwischen Mensch und LLM von 68 % auf 94 %
• Dennoch ist LLM-as-Judge kein Allheilmittel
  • Selbst die leistungsfähigsten Modelle können bestimmte feine sprachliche Aspekte nicht zuverlässig bewerten
• Außerdem haben wir festgestellt, dass klassische Klassifikatoren und Reward-Modelle eine höhere Genauigkeit als LLM-as-Judge erreichen können und dabei weniger Kosten und Latenz verursachen
  • Bei Codegenerierung kann LLM-as-Judge schwächer sein als direktere Evaluierungsstrategien wie die Ausführungsevaluierung

„Intern-Test“ zur Bewertung generierter Ergebnisse

• Bei der Bewertung von Generationsergebnissen ist es sinnvoll, den folgenden „Praktikanten-Test“ zu verwenden
  • Wenn man den exakten Input für das Sprachmodell inklusive Kontext nimmt und ihn einer durchschnittlichen Studentin oder einem durchschnittlichen Studenten des relevanten Fachs als Aufgabe gibt: Würde die Person erfolgreich sein?
  • Wie lange würde es dauern?
• Wenn die Antwort nein ist
  • Falls dem LLM das nötige Wissen fehlt, sollte man überlegen, wie sich der Kontext anreichern lässt
  • Wenn sich das Problem auch durch besseren Kontext nicht lösen lässt, könnte die Aufgabe für moderne LLMs zu schwierig sein
• Wenn die Antwort ja ist, es aber Zeit braucht
  • Man kann versuchen, die Komplexität der Aufgabe zu reduzieren
    • Lässt sie sich zerlegen?
    • Welche Aspekte der Aufgabe lassen sich stärker templatisieren?
• Wenn die Antwort ja ist und schnell erledigt werden kann
  • Beim tieferen Blick in die Daten
    • Was macht das Modell falsch?
    • Lassen sich Fehlermuster finden?
  • Das Modell bitten, sich vor oder nach der Antwort selbst zu erklären

Eine zu starke Fokussierung auf einzelne Evaluierungen kann die Gesamtleistung verschlechtern

„Wenn ein Messwert zum Ziel wird, ist er kein guter Messwert mehr.“ – Goodharts Gesetz

• Ein Beispiel dafür ist die Needle-in-a-Haystack(NIAH)-Evaluierung
  • Die ursprüngliche Evaluierung half dabei, den Recall eines Modells mit wachsender Kontextgröße zu quantifizieren und zu prüfen, wie die Position der Nadel den Recall beeinflusst
  • Sie wurde jedoch überbetont und als Figure 1 im Gemini-1.5-Bericht vorgestellt
  • Diese Evaluierung besteht darin, in ein langes Dokument mit wiederholten Essays von Paul Graham eine bestimmte Phrase („The special magic {city} number is: {number}“) einzufügen und das Modell anschließend nach der magischen Zahl zu fragen
• Einige Modelle erreichen nahezu perfekten Recall, aber es ist fraglich, ob NIAH die für reale Anwendungen nötigen Fähigkeiten zu Schlussfolgern und Erinnern wirklich abbildet
• Betrachtet man praktischere Szenarien
  • Wenn ein einstündiges Meeting-Transkript vorliegt: Kann ein LLM die wichtigsten Entscheidungen und die nächsten Schritte zusammenfassen und jeden Punkt korrekt den zuständigen Personen zuordnen?
  • Diese Aufgabe ist realistischer, weil sie über bloßes Auswendiglernen hinaus auch die Fähigkeit berücksichtigt, komplexe Diskussionen zu erfassen, relevante Informationen zu identifizieren und Zusammenfassungen zu synthetisieren
• Beispiel für eine praktischere NIAH-Evaluierung
  • Verwendung des Transkripts eines Videoanrufs zwischen Arzt und Patient, um dem LLM Fragen zu den Medikamenten des Patienten zu stellen
  • Dazu kommt ein anspruchsvolleres NIAH, etwa durch das Einfügen von Phrasen mit zufälligen Zutaten für Pizzabelag wie in Espresso getränkte Datteln, Zitrone und Ziegenkäse
  • Beim Medikamenten-Task lag der Recall bei etwa 80 %, beim Pizza-Task bei 30 %
• Eine Überbetonung der NIAH-Evaluierung kann die Leistung bei Extraktions- und Zusammenfassungsaufgaben verschlechtern
  • Solche LLMs werden so feinabgestimmt, dass sie auf jeden Satz achten, wodurch sie irrelevante Details und Ablenkungen als wichtig behandeln können
  • Diese können dann im Endergebnis auftauchen (auch wenn sie dort nicht auftauchen sollten!)
• Das kann auch für andere Evaluierungen und Anwendungsfälle gelten
  • Zum Beispiel Zusammenfassung
    • Wer faktische Konsistenz zu stark betont, erhält möglicherweise weniger spezifische (und damit seltener faktisch falsche), aber auch weniger relevante Zusammenfassungen
    • Umgekehrt kann eine starke Betonung von Schreibstil und Eloquenz zu stärker ausgeschmückter Marketing-Sprache führen, die faktische Inkonsistenzen verursachen kann

Annotationen auf binäre Aufgaben oder paarweise Vergleiche vereinfachen

• Offenes Feedback zu Modellausgaben oder Bewertungen auf einer Likert-Skala zu geben, ist kognitiv anspruchsvoll
  • Dadurch werden die gesammelten Daten wegen der Unterschiede zwischen menschlichen Bewertenden stärker verrauscht und damit weniger nützlich
• Ein effektiverer Ansatz besteht darin, die Aufgabe zu vereinfachen und die kognitive Belastung der Annotierenden zu reduzieren
  • Zwei gut funktionierende Aufgaben sind binäre Klassifikation und paarweiser Vergleich
• Bei der binären Klassifikation werden Annotierende gebeten, für den Output des Modells ein einfaches Ja/Nein-Urteil abzugeben
  • Man kann etwa fragen, ob eine erzeugte Zusammenfassung faktisch mit dem Quelldokument übereinstimmt, ob eine vorgeschlagene Antwort relevant ist oder ob sie schädliche Inhalte enthält
  • Im Vergleich zu Likert-Skalen sind binäre Entscheidungen präziser, konsistenter zwischen Bewertenden und mit höherem Durchsatz verbunden
  • So hat Doordash eine Labeling-Queue eingerichtet, um Menüpunkte über eine Reihe von Ja/Nein-Fragen zu taggen
• Beim paarweisen Vergleich(Pairwise Comparison) erhalten Annotierende ein Paar von Modellantworten und sollen angeben, welche besser ist
  • Weil es für Menschen leichter ist zu sagen „A ist besser als B“, als A oder B einzeln zu bewerten, führt dies zu schnelleren und zuverlässigeren Annotationen (im Vergleich zu Likert-Skalen)
• Bei einem Llama2-Meetup bestätigte Thomas Scialom, einer der Autoren des Llama2-Papers, dass paarweise Vergleiche schneller und günstiger sind als das Sammeln von Supervised-Fine-Tuning-Daten in Form ausformulierter Antworten
  • Ersteres kostet 3,5 US-Dollar pro Einheit, Letzteres 25 US-Dollar pro Einheit

(Referenzfreie, Reference-free) Evaluierungen und Guardrails können austauschbar verwendet werden

• Guardrails helfen dabei, unangemessene oder schädliche Inhalte abzufangen, während Evaluierungen helfen, Qualität und Genauigkeit von Modellausgaben zu messen
  • Bei referenzfreien Evaluierungen kann man sie als zwei Seiten derselben Medaille betrachten
    • Eine referenzfreie Evaluierung bewertet die Qualität eines Outputs nur anhand des Eingabe-Prompts und der Antwort des Modells, ohne auf eine „goldene“ Referenz wie eine von Menschen verfasste Antwort angewiesen zu sein
• Beispiel für eine referenzfreie Evaluierung: Zusammenfassungsbewertung
  • Um die faktische Konsistenz und Relevanz einer Zusammenfassung zu bewerten, muss nur das Eingabedokument betrachtet werden
  • Wenn die Zusammenfassung bei diesen Metriken schlecht abschneidet, kann man entscheiden, sie dem Nutzer nicht anzuzeigen und die Evaluierung so effektiv als Guardrail zu verwenden
• Referenzfreie „Übersetzungs“-Evaluierung:
  • Auch ohne von Menschen übersetzte Referenz lässt sich die Qualität einer Übersetzung bewerten, was sich wiederum als Guardrail nutzen lässt

LLMs geben auch dann Ausgaben zurück, wenn sie es nicht sollten

• Eine zentrale Herausforderung bei der Arbeit mit LLMs ist, dass sie oft Outputs erzeugen, auch wenn sie es nicht sollten
  • Das kann zu harmlosen, aber sinnlosen Antworten führen oder zu gravierenderen Fehlern wie schädlichen oder riskanten Inhalten
  • Wenn man ein LLM zum Beispiel bittet, bestimmte Eigenschaften oder Metadaten aus einem Dokument zu extrahieren, kann es selbstbewusst einen Wert zurückgeben, obwohl dieser tatsächlich gar nicht vorhanden ist
  • Oder das Modell antwortet in einer anderen Sprache als Englisch, weil im Kontext ein nicht englischsprachiges Dokument enthalten war
• Man kann LLMs per Prompt dazu anhalten, „nicht zutreffend“ oder „unbekannt“ zurückzugeben, aber das ist nicht perfekt
  • Selbst wenn Log-Wahrscheinlichkeiten verfügbar sind, sind sie ein schlechter Indikator für die Output-Qualität
    • Log-Wahrscheinlichkeiten zeigen, wie wahrscheinlich das Auftreten von Tokens im Output ist, spiegeln aber nicht die Korrektheit des erzeugten Textes wider
  • Gerade bei Instruction-Tuned-Modellen, die darauf trainiert sind, auf Anfragen zu antworten und kohärente Antworten zu erzeugen, können Log-Wahrscheinlichkeiten schlecht kalibriert sein
    • Eine hohe Log-Wahrscheinlichkeit kann also bedeuten, dass der Output flüssig und konsistent ist, nicht aber, dass er korrekt oder relevant ist
• Sorgfältiges Prompt Engineering kann bis zu einem gewissen Grad helfen, sollte aber durch robuste Guardrails ergänzt werden, die unerwünschte Ausgaben erkennen und filtern bzw. neu generieren
  • OpenAI bietet zum Beispiel eine Content-Moderation-API an, die unsichere Antworten wie Hassrede, Selbstverletzung oder sexuelle Ausgaben identifizieren kann
  • Ebenso gibt es zahlreiche Pakete zur Erkennung personenbezogener Daten (PII)
• Ein Vorteil von Guardrails ist, dass sie weitgehend unabhängig vom konkreten Use Case sind und sich daher breit auf alle Ausgaben in einer bestimmten Sprache anwenden lassen
  • Auch durch präzise Retrieval-Verfahren kann das System, wenn keine relevanten Dokumente vorhanden sind, eindeutig mit „Ich weiß es nicht“ antworten
• LLMs können auch dann keinen Output erzeugen, wenn einer erwartet wird
  • Das kann viele Ursachen haben, von einfachen Problemen wie hoher Latenz beim API-Anbieter bis hin zu komplexeren Fällen, in denen der Output durch einen Content-Moderation-Filter blockiert wird
• Deshalb ist es wichtig, für Debugging und Monitoring die Eingaben und auch das potenzielle Ausbleiben von Ausgaben konsistent zu protokollieren

Halluzinationen sind ein hartnäckiges Problem

• Mängel bei Content-Sicherheit oder PII treten dank der großen Aufmerksamkeit dafür nur selten auf, während faktische Inkonsistenzen hartnäckig bestehen bleiben und schwerer zu erkennen sind
  • Sie treten häufiger auf; die Basisrate liegt bei 5–10 %, und nach dem, was wir von LLM-Anbietern gelernt haben, kann es selbst bei einfachen Aufgaben wie Zusammenfassungen schwierig sein, sie auf unter 2 % zu senken
• Um dies zu lösen, kann man Prompt Engineering (upstream bei der Generierung) mit Guardrails gegen faktische Inkonsistenzen (downstream nach der Generierung) kombinieren
  • Beim Prompt Engineering helfen Techniken wie CoT dabei, Halluzinationen zu verringern, indem das LLM seine Schlussfolgerung erklärt, bevor es die endgültige Ausgabe zurückgibt
  • Anschließend können Guardrails gegen faktische Inkonsistenzen angewendet werden, um die Faktentreue der Zusammenfassung zu bewerten und Halluzinationen herauszufiltern oder neu generieren zu lassen
• In manchen Fällen können Halluzinationen deterministisch erkannt werden
  • Wenn bei der RAG-Abrufsuche Ressourcen verwendet werden, die Ausgabe strukturiert ist und identifiziert wird, welche Ressourcen es sind, sollte man manuell prüfen können, ob sie aus dem Eingabekontext stammen

[Betrieb: Tagesgeschäft und organisatorische Probleme ]

Betrieb 1. Daten

• So wie die Qualität der Zutaten den Geschmack eines Gerichts bestimmt, begrenzt die Qualität der Eingabedaten die Leistung eines Machine-Learning-Systems
• Außerdem sind die Ausgabedaten die einzige Möglichkeit festzustellen, ob das Produkt funktioniert
• Alle Autorinnen und Autoren schauen sich jede Woche mehrere Stunden lang Eingaben und Ausgaben genau an, um die Datenverteilung (Modi, Edge Cases, Grenzen des Modells) besser zu verstehen

Entwicklungs-Produktions-Drift prüfen

• In traditionellen Machine-Learning-Pipelines ist Training-Serving-Skew eine häufige Fehlerursache
  • Er tritt auf, wenn sich die für das Training verwendeten Daten von den Daten unterscheiden, denen das Modell in der Produktion begegnet
• Da LLMs ohne Training oder Fine-Tuning verwendet werden können, gibt es zwar keinen Trainingssatz, aber ein ähnliches Problem in Form von Entwicklungs-Produktions-Daten-Drift
  • Grundsätzlich sollten die Daten, mit denen das System während der Entwicklung getestet wird, die Daten widerspiegeln, denen das System in der Produktion begegnen wird
    • Andernfalls kann die Genauigkeit in der Produktion sinken
• Entwicklungs-Produktions-Drift bei LLMs lässt sich in zwei Typen einteilen: strukturelle Drift und inhaltsbasierte Drift
  • Zu struktureller Drift gehören Formatabweichungen wie der Unterschied zwischen JSON-Dictionaries mit Listenwerten und JSON-Listen, inkonsistente Groß- und Kleinschreibung sowie Fehler wie Tippfehler oder Satzfragmente
    • Solche Fehler können zu unvorhersehbarer Modellleistung führen, weil verschiedene LLMs auf bestimmte Datenformate trainiert wurden und Prompts sehr empfindlich auf kleine Änderungen reagieren können
  • Inhaltsbasierte oder „semantische“ Drift bezeichnet Unterschiede in Bedeutung oder Kontext der Daten
• Wie bei traditionellem ML ist es nützlich, Drift zwischen LLM-Ein-/Ausgabe-Paaren regelmäßig zu messen
  • Einfache Metriken wie die Länge von Ein- und Ausgaben oder bestimmte Formatanforderungen (z. B. JSON oder XML) sind eine einfache Möglichkeit, Änderungen nachzuverfolgen
• Für fortgeschrittenere Drifterkennung sollte erwogen werden, Embeddings von Ein-/Ausgabe-Paaren zu clustern, um semantische Drift zu erkennen, etwa Themenverschiebungen in dem, worüber Nutzer sprechen, was darauf hindeuten kann, dass Nutzer Bereiche erkunden, denen das Modell bisher nicht ausgesetzt war
• Wenn Änderungen wie Prompt Engineering getestet werden, sollte sichergestellt werden, dass der Holdout-Datensatz aktuell ist und die neuesten Arten von Nutzerinteraktionen widerspiegelt
  • Wenn beispielsweise Tippfehler in Produktionseingaben häufig sind, sollten sie auch im Holdout-Datensatz vorkommen
• Es ist vorteilhaft, über die reine numerische Messung von Drift hinaus qualitative Bewertungen der Ausgaben durchzuführen
  • Die regelmäßige Überprüfung von Modellausgaben — umgangssprachlich als „Vibe Check“ bekannt — stellt sicher, dass die Ergebnisse den Erwartungen entsprechen und für die Bedürfnisse der Nutzer relevant bleiben
• Es ist auch nützlich, Nichtdeterminismus in die Driftprüfung einzubeziehen
  • Wenn die Pipeline für jede Eingabe des Testdatensatzes mehrfach ausgeführt und alle Ausgaben analysiert werden, steigt die Wahrscheinlichkeit, Anomalien zu erfassen, die nur gelegentlich auftreten

Täglich Stichproben von LLM-Ein- und -Ausgaben prüfen

• LLMs sind dynamisch und entwickeln sich ständig weiter
  • Trotz ihrer beeindruckenden Zero-Shot-Fähigkeiten und oft erfreulichen Ausgaben sind die Fehlermodi von LLMs äußerst unvorhersehbar
• Für maßgeschneiderte Aufgaben ist es unerlässlich, Datenstichproben regelmäßig zu überprüfen, um ein intuitives Verständnis der LLM-Leistung zu entwickeln
  • Ein-/Ausgabe-Paare aus der Produktion sind die „realen Dinge an realen Orten“ (genchi genbutsu) von LLM-Anwendungen und nicht ersetzbar
• Jüngste Forschung hebt hervor, dass sich mit zunehmender Interaktion von Entwicklern mit Daten ihre Wahrnehmung von „guten“ und „schlechten“ Ausgaben verändert (d. h. Kriterien-Drift)
  • Entwickler können im Voraus einige Kriterien zur Bewertung von LLM-Ausgaben festlegen, doch diese vordefinierten Kriterien sind oft unvollständig
• Beispielsweise kann man während der Entwicklung Prompts aktualisieren, um die Wahrscheinlichkeit guter Antworten zu erhöhen und die Wahrscheinlichkeit schlechter Antworten zu senken
  • Dieser iterative Prozess aus Bewertung, Neubewertung und Aktualisierung der Kriterien ist notwendig, weil sich weder das Verhalten von LLMs noch menschliche Präferenzen ohne direkte Beobachtung der Ausgaben leicht vorhersagen lassen
• Um dies wirksam zu handhaben, sollten LLM-Eingaben und -Ausgaben protokolliert werden
  • Wenn täglich Stichproben dieser Logs geprüft werden, können neue Muster oder Fehlermodi schnell identifiziert werden, sodass man sich anpassen kann
  • Wenn ein neues Problem entdeckt wird, kann sofort eine passende Assertion oder Eval dafür geschrieben werden
• Ebenso sollten alle Aktualisierungen bei der Definition von Fehlermodi in den Bewertungskriterien berücksichtigt werden
  • Diese „Vibe Checks“ sind Signale für fehlerhafte Ausgaben, und Code sowie Assertions operationalisieren sie
• Schließlich sollte diese Haltung sozialisiert werden
  • Etwa indem in die On-Call-Rotation die Prüfung oder Kommentierung von Ein- und Ausgaben aufgenommen wird

Betrieb 2. Mit Modellen arbeiten

• Durch die Nutzung von LLM-APIs kann man sich auf die Intelligenz einiger weniger Anbieter stützen
  • Das ist zwar gut, aber diese Abhängigkeit bringt Trade-offs bei Leistung, Latenz, Durchsatz und Kosten mit sich
• Da im vergangenen Jahr zudem fast monatlich neuere und bessere Modelle erschienen sind, sollte man darauf vorbereitet sein, das Produkt zu aktualisieren, wenn ältere Modelle ausgemustert und durch neue ersetzt werden
  • Dieser Abschnitt teilt Erkenntnisse aus der Arbeit mit Technologien, die man nicht vollständig kontrolliert, also Technologien, deren Modelle man nicht selbst hosten und verwalten kann
• In den meisten realen Anwendungsfällen werden LLM-Ausgaben von Downstream-Anwendungen in irgendeiner maschinenlesbaren Form weiterverarbeitet
  • Zum Beispiel benötigt ReChat, ein Immobilien-CRM, strukturierte Antworten, um Widgets im Frontend zu rendern
  • Ähnlich benötigt Boba, ein Tool zur Generierung von Ideen für Produktstrategien, strukturierte Ausgaben mit Feldern für Titel, Zusammenfassung, Machbarkeits-Score und Zeitraum
  • Schließlich hat LinkedIn gezeigt, wie LLMs darauf beschränkt werden können, YAML zu erzeugen, das genutzt wird, um zu entscheiden, welche Technik eingesetzt werden soll, und die Parameter für deren Aufruf bereitzustellen
• Dieses Anwendungsmuster ist eine extreme Version von Postels Gesetz
  • Sei großzügig bei dem, was du akzeptierst (beliebige natürliche Sprache), und konservativ bei dem, was du sendest (typisierte, maschinenlesbare Objekte)
  • Deshalb ist zu erwarten, dass dies sehr langlebig sein wird
• Gegenwärtig sind Instructor und Outlines de-facto-Standards, um strukturierte Ausgaben aus LLMs zu erhalten
  • Wenn LLM-APIs verwendet werden (z. B. Anthropic, OpenAI), sollte Instructor verwendet werden; bei selbst gehosteten Modellen (z. B. Huggingface) Outlines

Prompt-Migration zwischen Modellen ist schmerzhaft

• Manchmal funktioniert ein sorgfältig ausgearbeiteter Prompt mit einem Modell hervorragend, mit einem anderen jedoch nicht richtig
  • Das kann nicht nur beim Wechsel zwischen verschiedenen Modellanbietern passieren, sondern auch beim Upgrade zwischen Versionen desselben Modells
• Voiceflow stellte zum Beispiel fest, dass bei einer Migration von gpt-3.5-turbo-0301 zu gpt-3.5-turbo-1106 die Leistung bei der Intent-Klassifizierung um 10 % sank
  • (Zum Glück hatten sie Evaluierungen!)
• Ähnlich beobachtete GoDaddy beim Upgrade auf Version 1106 einen positiven Trend, bei dem sich die Leistungslücke zwischen gpt-3.5-turbo und gpt-4 verringerte
  • (Oder, wenn Sie eher der Typ mit dem halb vollen Glas sind, könnten Sie enttäuscht sein, dass das neue Upgrade den Vorsprung von gpt-4 verkleinert hat)
• Wenn Sie Prompts also zwischen Modellen migrieren müssen, sollten Sie damit rechnen, dass dies mehr Zeit in Anspruch nimmt, als einfach nur den API-Endpunkt auszutauschen
  • Gehen Sie nicht davon aus, dass das Anschließen desselben Prompts zu ähnlichen oder besseren Ergebnissen führt
• Außerdem helfen zuverlässige, automatisierte Evaluierungen dabei, die Aufgabenleistung vor und nach der Migration zu messen, und verringern den Aufwand für manuelle Validierung

Modellversionsverwaltung und Pinning

• In jeder Machine-Learning-Pipeline gilt: „Wenn man irgendetwas ändert, ändert sich alles“
  • Das ist besonders relevant, wenn wir von Komponenten wie großen Sprachmodellen (LLMs) abhängen, die wir nicht selbst trainiert haben und die ohne unser Wissen geändert werden können
• Glücklicherweise bieten viele Modellanbieter die Möglichkeit, eine bestimmte Modellversion zu „pinnen“ (z. B. gpt-4-turbo-1106)
  • Dadurch können Sie eine bestimmte Version der Modellgewichte verwenden, sodass sie sich nicht ändert
• Wenn Sie Modellversionen in der Produktion pinnen, können Sie unerwartete Änderungen im Modellverhalten verhindern
  • Das kann helfen, Kundenbeschwerden über Probleme wie übermäßig wortreiche Ausgaben oder andere unerwartete Fehlermodi zu vermeiden, die auftreten können, wenn ein Modell ersetzt wird
• Ziehen Sie außerdem in Betracht, eine „Shadow-Pipeline“ zu betreiben, die die Produktionseinstellungen spiegelt, aber die neueste Modellversion verwendet
  • So können Sie sicher mit neuen Releases experimentieren und sie testen
• Nachdem Sie Stabilität und Qualität der Ausgaben dieser neuen Modelle validiert haben, können Sie die Modellversion in der Produktionsumgebung mit gutem Gewissen aktualisieren

Das kleinste Modell wählen, das die Aufgabe erledigen kann

• Bei der Arbeit an einer neuen Anwendung ist die Versuchung groß, das größte und leistungsfähigste verfügbare Modell zu verwenden
  • Sobald jedoch bestätigt ist, dass die Aufgabe technisch machbar ist, lohnt es sich zu experimentieren, ob sich mit einem kleineren Modell ähnliche Ergebnisse erzielen lassen
• Die Vorteile kleiner Modelle sind geringere Latenz und niedrigere Kosten
  • Sie mögen schwächer sein, aber Techniken wie Chain-of-Thought, n-shot-Prompts und In-Context-Learning können kleineren Modellen helfen, über ihre eigentlichen Fähigkeiten hinauszuwachsen
• Über LLM-APIs hinaus kann auch Fine-Tuning für spezifische Aufgaben zur Leistungssteigerung beitragen
• Zusammengenommen kann ein sorgfältig entworfener Workflow mit kleineren Modellen schneller und günstiger sein und dabei die Ausgabequalität eines einzelnen großen Modells erreichen oder sogar übertreffen
  • Zum Beispiel teilt dieser Tweet eine Anekdote darüber, wie Haiku + ein 10-shot-Prompt Zero-Shot Opus und GPT-4 übertrifft
• Langfristig ist zu erwarten, dass mehr Beispiele für Flow-Engineering mit kleineren Modellen auftauchen werden, das die beste Balance aus Ausgabequalität, Latenz und Kosten bietet
• Ein weiteres Beispiel ist die bescheidene Klassifizierungsaufgabe
  • Leichtgewichtige Modelle wie DistilBERT (67 Millionen Parameter) sind überraschend starke Baselines
  • DistilBART mit 400 Millionen Parametern ist eine weitere hervorragende Option
    • Wird es auf Open-Source-Daten feinabgestimmt, kann es Halluzinationen mit einer ROC-AUC von 0,84 identifizieren und dabei die meisten LLMs bei weniger als 5 % von Latenz und Kosten übertreffen
• Der Punkt ist, dass kleine Modelle nicht übersehen werden sollten
  • Es ist leicht, riesige Modelle auf jedes Problem anzusetzen, aber mit etwas Kreativität und Experimentierfreude finden wir oft effizientere Lösungen

Betrieb 3. Produkt

• Neue Technologien eröffnen neue Möglichkeiten, aber die Prinzipien für den Bau großartiger Produkte sind zeitlos
  • Selbst wenn wir also zum ersten Mal ein neues Problem lösen, müssen wir bei der Produktgestaltung das Rad nicht neu erfinden
• Es gibt viel zu gewinnen, wenn man die Entwicklung von LLM-Anwendungen auf solide Produktgrundlagen stützt
  • Dadurch können wir den Menschen, die wir bedienen, echten Mehrwert bieten

Design von Anfang an einbeziehen

• Wenn Designer eingebunden sind, hilft das dabei zu verstehen und gründlich zu durchdenken, wie ein Produkt gebaut und den Nutzern präsentiert werden kann
  • Manchmal werden Designer stereotyp als diejenigen gesehen, die Dinge hübsch machen
  • Doch sie denken nicht nur über Benutzeroberflächen nach, sondern auch darüber, wie sich die User Experience verbessern lässt, selbst wenn dafür bestehende Regeln und Paradigmen aufgebrochen werden müssen
• Designer sind besonders talentiert darin, Nutzeranforderungen in verschiedene Formen zu überführen
  • Einige dieser Formen sind leichter lösbar als andere und bieten daher mehr oder weniger Spielraum für AI-Lösungen
• Wie bei vielen anderen Produkten sollte auch der Bau von AI-Produkten sich um die zu erledigende Aufgabe drehen und nicht um die Technologie, die das Produkt antreibt
• Konzentrieren Sie sich darauf, sich selbst Fragen wie die folgenden zu stellen
  • „Welche Aufgabe bitten Nutzer dieses Produkt zu erledigen? Ist das eine Aufgabe, in der ein Chatbot gut wäre? Wie wäre es mit Autovervollständigung? Oder vielleicht etwas ganz anderes!“
• Berücksichtigen Sie bestehende Designmuster und wie sie mit der zu erledigenden Aufgabe zusammenhängen
  • Das sind wertvolle Beiträge, mit denen Designer die Fähigkeiten eines Teams erweitern

UX für Human-in-the-Loop gestalten

• Eine Möglichkeit, hochwertige Annotationen zu erhalten, besteht darin, Human-in-the-Loop (HITL) in die User Experience (UX) zu integrieren
  • Wenn Nutzer einfach Feedback und Korrekturen geben können, verbessert das die unmittelbare Ausgabe und sammelt nützliche Daten für die Modellverbesserung
• Stellen wir uns eine E-Commerce-Plattform vor, auf der Nutzer Produkte hochladen und kategorisieren
  • Es gibt mehrere Möglichkeiten, die UX zu gestalten
    1. Der Nutzer wählt manuell die richtige Produktkategorie aus, und das LLM prüft regelmäßig neue Produkte und korrigiert Fehlklassifizierungen im Backend
    2. Der Nutzer wählt überhaupt keine Kategorie aus, und das LLM kategorisiert Produkte regelmäßig im Backend (einschließlich potenzieller Fehler)
    3. Das LLM schlägt in Echtzeit eine Produktkategorie vor, und der Nutzer kann sie bei Bedarf prüfen und aktualisieren
• Alle drei Ansätze beinhalten ein LLM, bieten aber eine sehr unterschiedliche UX
  • Der erste Ansatz verlagert die anfängliche Last auf den Nutzer, während das LLM als nachgelagerte Prüfung dient
  • Der zweite Ansatz erfordert keinerlei Aufwand vom Nutzer, bietet aber weder Transparenz noch Kontrolle
  • Der dritte Ansatz hält die richtige Balance
    • Indem das LLM Kategorien im Voraus vorschlägt, reduziert es die kognitive Last für den Nutzer, der unsere Taxonomie nicht erst lernen muss, um Produkte zu kategorisieren
    • Gleichzeitig bleibt die endgültige Entscheidung über die Produktklassifizierung fest in der Hand des Nutzers, da er Vorschläge prüfen und bearbeiten kann
  • Als Bonus schafft der dritte Ansatz eine natürliche Feedback-Schleife zur Modellverbesserung
    • Gute Vorschläge werden akzeptiert (positives Label), schlechte Vorschläge werden aktualisiert (negatives, dann positives Label)
• Dieses Muster aus Vorschlag, Nutzerverifikation und Datensammlung ist in vielen Anwendungen üblich
  • Coding-Assistenten: Nutzer können Vorschläge akzeptieren (stark positiv), akzeptieren und anpassen (positiv) oder ignorieren (negativ)
  • Midjourney: Nutzer können ein Bild hochskalieren und herunterladen (stark positiv), ein Bild verändern (positiv) oder einen neuen Bildsatz erzeugen (negativ)
  • Chatbots: Nutzer können auf Antworten mit „Gefällt mir“ (positiv) oder „Gefällt mir nicht“ (negativ) reagieren oder bei wirklich schlechten Antworten eine Neugenerierung anfordern (stark negativ)
• Feedback kann explizit oder implizit sein
  • Explizites Feedback sind Informationen, die Nutzer als Reaktion auf eine Aufforderung des Produkts geben
  • Implizites Feedback sind Informationen, die aus Nutzerinteraktionen gelernt werden, ohne dass Nutzer absichtlich Feedback geben müssen
• Coding-Assistenten und Midjourney sind Beispiele für implizites Feedback, während Likes und Dislikes explizites Feedback sind
  • Wenn man die UX gut gestaltet, wie bei Coding-Assistenten und Midjourney, kann man viel implizites Feedback sammeln, um Produkt und Modell zu verbessern

Anforderungen in der Hierarchie rücksichtslos priorisieren

• Wenn man darüber nachdenkt, eine Demo in Produktion zu bringen, muss man Anforderungen in den folgenden Bereichen berücksichtigen
  • Zuverlässigkeit: 99,9 % Uptime, Einhaltung strukturierter Outputs
  • Unschädlichkeit: keine beleidigenden, NSFW- oder sonstigen schädlichen Inhalte erzeugen
  • Faktische Konsistenz: dem bereitgestellten Kontext treu bleiben und Fakten nicht verzerren
  • Nützlichkeit: relevant für die Bedürfnisse und Anfragen der Nutzer
  • Skalierbarkeit: Latenz-SLAs, unterstützter Durchsatz
  • Kosten: weil das Budget nicht unbegrenzt ist
  • Sonstiges: Sicherheit, Datenschutz, Fairness, DSGVO, DMA usw.
• Wenn man versucht, all diese Anforderungen gleichzeitig zu lösen, bringt man am Ende gar nichts auf den Markt
  • Deshalb muss man priorisieren. Rücksichtslos.
• Das bedeutet, klar zu definieren, welche nicht verhandelbaren Punkte existieren, bei denen das Produkt sonst nicht funktioniert oder nicht tragfähig ist (z. B. Zuverlässigkeit, Unschädlichkeit)
  • Es ist wichtig, das MVP (Minimum Lovable Product) zu identifizieren
• Man muss akzeptieren, dass die erste Version nicht perfekt sein wird, und sie trotzdem veröffentlichen und iterieren

Das Risikoniveau je nach Use Case anpassen

• Wenn man das Prüfungsniveau für Sprachmodelle und Anwendungen festlegt, sollte man den Use Case und die Zielgruppe berücksichtigen
  • Bei einem kundenorientierten Chatbot, der medizinische oder finanzielle Beratung bietet, braucht man sehr hohe Maßstäbe bei Sicherheit und Genauigkeit
    • Fehler oder falsche Ausgaben können realen Schaden anrichten und Vertrauen zerstören
  • Bei weniger kritischen Anwendungen wie Empfehlungssystemen oder intern genutzten Anwendungen wie Inhaltsklassifizierung oder Zusammenfassung verlangsamen übermäßig strenge Anforderungen oft nur den Fortschritt, ohne viel zusätzlichen Wert zu schaffen
• Das deckt sich mit einem aktuellen Bericht von a16z, wonach viele Unternehmen sich bei internen LLM-Anwendungen schneller bewegen als bei externen Anwendungen
  • Indem Organisationen KI zunächst für interne Produktivität erproben, können sie anfangen, Wert zu schöpfen und gleichzeitig in einem kontrollierteren Umfeld zu lernen, wie Risiken gemanagt werden
  • Wenn dann ausreichend Vertrauen vorhanden ist, kann auf kundenorientierte Use Cases ausgeweitet werden

Betrieb 4. Teams und Rollen

• Keine Jobfunktion ist leicht zu definieren, aber in diesem neuen Bereich Stellenbeschreibungen für die Arbeit zu verfassen, ist noch schwieriger als sonst
  • Ich werde Venn-Diagramme zu sich überschneidenden Rollen oder Vorschläge für Stellenbeschreibungen auslassen
  • Ich werde jedoch die Existenz einer neuen Rolle anerkennen, des AI Engineers, und über diese Rolle sprechen
• Wichtig ist, zu besprechen, wie der Rest des Teams und die Verantwortlichkeiten verteilt werden sollten

Auf Prozesse statt auf Tools fokussieren

• Wenn Software Engineers mit einem neuen Paradigma wie LLMs konfrontiert werden, neigen sie dazu, Tools zu bevorzugen
  • Das führt dazu, dass sie die Probleme und Prozesse übersehen, die diese Tools eigentlich lösen sollten
  • Dadurch nehmen viele Engineers akzidentelle Komplexität in Kauf, was langfristig negative Folgen für die Produktivität des Teams hat
• Zum Beispiel beschreibt dieser Artikel, wie bestimmte Tools Prompts für große Sprachmodelle automatisch erzeugen können
  • Er argumentiert (meiner Meinung nach zu Recht), dass Engineers, die solche Tools nutzen, ohne zuerst die Problemlösungsmethodik oder den Prozess zu verstehen, am Ende unnötige technische Schulden anhäufen
• Neben akzidenteller Komplexität sind Tools oft auch unzureichend spezifiziert
  • So wächst etwa eine Branche von LLM-Evaluierungstools, die eine „LLM-Evaluierungs-Toolbox“ mit allgemeinen Evaluatoren für Schädlichkeit, Prägnanz, Tonfall usw. anbietet
  • Man sieht viele Teams, die solche Tools übernehmen, ohne kritisch über die spezifischen Fehlermodi ihrer eigenen Domäne nachzudenken
• Im Gegensatz dazu konzentriert sich EvalGen darauf, dem Nutzer den Prozess zur Erstellung domänenspezifischer Evaluierungen beizubringen, indem er tief in jeden Schritt eingebunden wird, etwa bei der Kriterienspezifikation, dem Daten-Labeling und der Überprüfung von Evaluierungen
  • Die Software führt den Nutzer durch einen Workflow wie den folgenden
• Von EvalGen angeleitete Best Practices für die Erstellung von LLM-Evaluierungen
  1. Domänenspezifische Tests definieren (automatisch aus Prompts gebootstrapped)
     • Definiert als Assertions in Code oder mit LLM-as-a-Judge
  2. Die Bedeutung, Tests mit menschlichem Urteil abzugleichen, damit Nutzer überprüfen können, ob die Tests die spezifizierten Kriterien erfassen
  3. Tests iterieren, wenn sich das System (Prompts usw.) verändert
• EvalGen vermittelt Entwicklern ein mentales Modell für den Prozess des Evaluierungsaufbaus, bindet sie aber nicht an ein bestimmtes Tool
  • Es zeigt sich, dass AI Engineers nach diesem Kontext oft einfachere Tools wählen oder beschließen, eigene Tools zu bauen
• Abgesehen von Prompting und Evaluierung gibt es so viele Komponenten von LLMs, dass sie hier nicht alle aufgelistet werden können
  • Dennoch ist es wichtig, dass AI Engineers versuchen, den Prozess zu verstehen, bevor sie Tools übernehmen

Immer experimentieren

• ML-Produkte sind eng mit Experimenten verknüpft
  • Gemeint sind nicht nur A/B-Tests und randomisierte kontrollierte Studien, sondern auch häufige Versuche, die kleinstmöglichen Bestandteile des Systems zu verändern und Offline-Evaluierungen durchzuführen
  • Der Grund, warum alle so begeistert von Evaluierung sind, ist, dass es in Wirklichkeit nicht um Zuverlässigkeit und Vertrauen geht, sondern darum, Experimente zu ermöglichen!
    • Je besser die Evaluierung, desto schneller lassen sich Experimente iterieren und desto schneller kann man sich somit der besten Version des Systems annähern
• Da Experimente sehr viel günstiger geworden sind, ist es üblich, verschiedene Ansätze auszuprobieren, um dasselbe Problem zu lösen
  • Die hohen Kosten für Datenerhebung und Modelltraining wurden minimiert
    • Prompt Engineering kostet kaum mehr als menschliche Zeit
  • Man sollte das Team so aufstellen, dass alle die Grundlagen des Prompt Engineering lernen können
    • Das ermutigt alle zum Experimentieren und führt im gesamten Unternehmen zu vielfältigen Ideen
• Nicht nur zur Exploration experimentieren, sondern Experimente auch zur Ausnutzung verwenden!
  • Gibt es eine funktionierende Version für eine neue Aufgabe?
    • Dann sollte man in Betracht ziehen, dass jemand anderes im Team einen anderen Ansatz ausprobiert
  • Einen anderen Weg testen, der schneller sein könnte
  • Prompt-Techniken wie Chain-of-Thought oder Few-Shot untersuchen, um die Qualität zu verbessern
  • Sicherstellen, dass die Tools Experimente nicht behindern
    • Wenn doch, etwas kaufen, das man neu aufbauen oder verbessern kann
• Während der Produkt-/Projektplanung gezielt Zeit für den Aufbau von Evaluierungen und die Durchführung mehrerer Experimente einplanen
  • Über Produktspezifikationen für das technische Produkt nachdenken und dabei klare Kriterien für die Evaluierung ergänzen
• Bei der Roadmap-Erstellung die für Experimente benötigte Zeit nicht unterschätzen
  • Mit mehreren Entwicklungs- und Evaluierungsiterationen rechnen, bevor man die Freigabe für die Produktion erhält

Alle befähigen, neue AI-Technologien zu nutzen

• Mit der zunehmenden Einführung von generativer AI möchte man, dass nicht nur Spezialisten, sondern das gesamte Team das Gefühl hat, diese neue Technologie zu verstehen und nutzen zu können
  • Es gibt kaum einen besseren Weg, ein Gespür dafür zu entwickeln, wie LLMs funktionieren (z. B. Latenz, Fehlermodi, UX)
  • LLMs sind vergleichsweise zugänglich
    • Man muss nicht programmieren können, um die Leistung einer Pipeline zu verbessern; jeder kann durch Prompt Engineering und Evaluierung beitragen
• Ein großer Teil davon ist Schulung
  • Man kann mit den Grundlagen des Prompt Engineering beginnen, also mit Techniken wie n-shot Prompting und CoT, die helfen, das Modell in Richtung der gewünschten Ausgabe zu konditionieren
• Personen mit entsprechendem Wissen können auch technischere Aspekte vermitteln, etwa dass LLMs ihrem Wesen nach autoregressiv sind
  • Das heißt, Eingabetokens werden parallel verarbeitet, Ausgabetokens jedoch sequenziell erzeugt
  • Daher ist die Latenz eher eine Funktion der Ausgabelänge als der Eingabelänge
    • Das ist ein zentraler Aspekt beim UX-Design und beim Setzen von Performance-Erwartungen
• Man kann auch praktische Gelegenheiten für Experimente und Exploration schaffen
  • Wie wäre es mit einem Hackathon?
    • Es mag teuer erscheinen, wenn das gesamte Team einige Tage damit verbringt, an spekulativen Projekten zu hacken, aber die Ergebnisse könnten überraschen
  • Es gibt Teams, die über Hackathons ihre 3-Jahres-Roadmap in fast einem Jahr weitgehend abgeschlossen haben
    • Ein anderes Team kam durch einen Hackathon zu einer UX, die ein durch LLMs nun möglicher Paradigmenwechsel war und inzwischen zur Priorität für dieses Jahr und darüber hinaus geworden ist

Nicht in die Falle tappen, dass "AI Engineering alles ist"

• Wenn neue Berufsbezeichnungen entstehen, besteht anfangs die Tendenz, die mit diesen Rollen verbundenen Fähigkeiten zu überschätzen
  • Das führt oft zu schmerzhaften Korrekturen, sobald der tatsächliche Umfang dieser Jobs klarer wird
  • Neueinsteiger in diesem Bereich und Hiring Manager neigen zu überzogenen Behauptungen oder unrealistischen Erwartungen
• Bemerkenswerte Beispiele aus den vergangenen 10 Jahren sind:
  • Data Scientist: "jemand, der Statistik besser beherrscht als jeder Software Engineer und Software Engineering besser als jeder Statistiker"
  • Machine Learning Engineer (MLE): eine stärker auf Software Engineering ausgerichtete Perspektive auf Machine Learning
• Anfangs nahmen viele an, dass für datengetriebene Projekte allein Data Scientists ausreichen würden
  • Mit der Zeit wurde jedoch klar, dass Data Scientists mit Software- und Data Engineers zusammenarbeiten müssen, um Datenprodukte effektiv zu entwickeln und auszurollen
• Dieses Missverständnis tauchte mit der neuen Rolle des AI Engineer erneut auf, und manche Teams glauben, AI Engineers seien alles, was sie brauchen
  • In Wirklichkeit braucht der Aufbau von Machine-Learning- oder AI-Produkten eine breite Palette spezialisierter Rollen
• Wir haben mehr als 12 Unternehmen zu AI-Produkten beraten und dabei immer wieder beobachtet, dass sie in die Falle der Annahme tappen, "AI Engineering sei alles, was man braucht"
  • Das Ergebnis ist oft, dass Produkte Schwierigkeiten haben, über den Demo-Status hinaus zu skalieren, weil wichtige Aspekte des Produktaufbaus übersehen werden
• Zum Beispiel sind Evaluierung und Messung entscheidend, um ein Produkt über bloße Vibe-Checks hinaus zu skalieren
  • Die Fähigkeiten für effektive Evaluierung decken sich traditionell mit einigen der Stärken von Machine Learning Engineers
    • Ein Team, das nur aus AI Engineers besteht, verfügt wahrscheinlich nicht über diese Fähigkeiten
• Mitautor Hamel Husain erläutert die Bedeutung dieser Fähigkeiten in jüngerer Arbeit zu Bias-Erkennung in Daten und zum Design domänenspezifischer Evaluierungen
• Welche Arten von Rollen auf dem Weg zum Aufbau von AI-Produkten wann benötigt werden
  1. Zunächst auf den Produktaufbau konzentrieren
  • Das kann AI Engineers einschließen, ist aber nicht zwingend erforderlich
  • AI Engineers sind nützlich, um das Produkt (UX, Plumbing usw.) zu prototypisieren und schnell zu iterieren
  2. Als Nächstes das System instrumentieren und Daten sammeln, um die richtige Grundlage zu schaffen
  • Je nach Art und Umfang der Daten können Platform- und/oder Data Engineers erforderlich sein
  • Außerdem sollte es Systeme geben, um diese Daten abzufragen und zu analysieren, damit sich Probleme debuggen lassen
  3. Danach das AI-System optimieren
  • Das muss nicht zwingend Modelltraining einschließen
  • Zu den Grundlagen gehören Schritte wie Metrikdesign, Aufbau eines Evaluierungssystems, Durchführung von Experimenten, Optimierung des RAG-Retrievals und Debugging probabilistischer Systeme
  • MLEs sind in diesem Bereich sehr stark (auch wenn AI Engineers das selbstverständlich ebenfalls lernen können)
  • Wenn die vorherigen Schritte nicht abgeschlossen sind, ist es in der Regel nicht sinnvoll, einen MLE einzustellen
• Darüber hinaus braucht man immer Domänenexperten
  • In kleinen Unternehmen sollte idealerweise das Gründungsteam diese Rolle übernehmen, in größeren Unternehmen kann das Produktmanagement sie ausfüllen
• Es ist wichtig, die Abfolge und den richtigen Zeitpunkt der Rollen zu verstehen
  • Die falschen Leute zum falschen Zeitpunkt einzustellen (z. B. MLEs zu früh) oder in der falschen Reihenfolge zu bauen, verschwendet Zeit und Geld und führt zu Fluktuation
• Außerdem hilft es dem Unternehmen, in Phase 1–2 regelmäßig mit MLEs abzustimmen (ohne sie jedoch fest anzustellen), um die richtige Grundlage aufzubauen

[Strategie: Wie man beim Bauen mit LLMs nicht zurückfällt]

• Für eine erfolgreiche Produktentwicklung braucht es sorgfältige Planung und Priorisierung, statt einfach blind Prototypen zu bauen oder den neuesten Modellen und Trends hinterherzulaufen
• Bei der Entwicklung von AI-Produkten sollten zentrale Trade-offs geprüft werden, etwa ob man selbst entwickelt oder zukauft
• Es wird ein "Playbook" für die frühe Entwicklung von LLM-Anwendungen vorgestellt

Strategie 1: Keine GPUs vor PMF

• Um ein großartiges Produkt zu werden, muss es mehr sein als nur ein dünner Wrapper um die API eines anderen
• Doch der Fehler in die entgegengesetzte Richtung kann noch größere Kosten verursachen
  • Im vergangenen Jahr wurde enormes Venture Capital in das Training und die Anpassung von Modellen gesteckt, oft ohne klare Produktvision oder definierten Zielmarkt
  • Ein Unternehmen erhielt sogar eine Series-A-Finanzierung von satten 6 Milliarden US-Dollar
• In diesem Abschnitt wird erklärt, warum es ein Fehler ist, sofort mit dem Training eigener Modelle zu beginnen, und welche Rolle Self-Hosting spielen kann

Es ergibt keinen Sinn, von Anfang an (fast) neu zu trainieren

• Für die meisten Organisationen ist es unrealistisch und vom eigentlichen Produktaufbau losgelöst, ein LLM von Grund auf vorzutrainieren
  • Die Entwicklung und Wartung von Machine-Learning-Infrastruktur verschlingt viele Ressourcen
    • Dazu gehören Datensammlung, Modelltraining und -bewertung sowie Deployment
  • Wenn man sich noch in der Phase befindet, den Product-Market-Fit zu validieren, lenkt dieser Aufwand Ressourcen von der Entwicklung des Kernprodukts ab
  • Selbst wenn Rechenressourcen, Daten und technisches Know-how vorhanden sind, kann ein vortrainiertes LLM innerhalb weniger Monate veraltet sein
• Das Beispiel BloombergGPT
  • BloombergGPT, ein auf Finanzaufgaben spezialisiertes LLM, wurde mit 363B Token vortrainiert
  • Es erforderte den enormen Einsatz von neun Vollzeitkräften, darunter vier AI Engineers sowie fünf Personen aus ML-Produkt und Forschung
  • Trotzdem lag es innerhalb eines Jahres bei dieser Aufgabe hinter gpt-3.5-turbo und gpt-4 zurück
• Diese Beispiele deuten darauf hin, dass das Vortrainieren eines LLM von Grund auf für die meisten realen Anwendungen nicht die beste Nutzung von Ressourcen ist
  • Stattdessen ist es für Teams besser, das stärkste verfügbare Open-Source-Modell auf ihre spezifischen Anforderungen feinzujustieren
• Natürlich gibt es Ausnahmen
  • Das Code-Modell von Replit ist ein gutes Beispiel für eine Vortrainierung, die auf Codegenerierung und -verständnis spezialisiert ist
  • Durch Vortraining zeigte es eine bessere Leistung als größere Modelle wie CodeLlama7b
  • Mit dem Erscheinen leistungsfähigerer Modelle waren jedoch kontinuierliche Investitionen nötig, um den Nutzen aufrechtzuerhalten

Kein Fine-Tuning, bis klar ist, dass es nötig ist

• In den meisten Organisationen wird Fine-Tuning eher von FOMO (Fear Of Missing Out) als von strategischem Denken getrieben
  • Organisationen investieren zu früh in Fine-Tuning, um dem Vorwurf zu entgehen, nur ein „einfacher Wrapper“ zu sein
  • Tatsächlich ist Fine-Tuning eher schweres Gerät, das erst dann eingesetzt werden sollte, wenn genügend Beispiele gesammelt wurden, die belegen, dass andere Ansätze nicht ausreichen
• Vor einem Jahr äußerten viele Teams große Erwartungen an Fine-Tuning, aber nur wenige fanden Product-Market-Fit, und die meisten bereuten ihre Entscheidung
  • Wer Fine-Tuning betreiben will, muss bereit sein, es immer wieder zu wiederholen, wenn sich das Basismodell verbessert
    • Siehe unten „Das Modell ist nicht das Produkt“ und „LLMOps aufbauen“
• Wann Fine-Tuning tatsächlich die richtige Wahl sein kann
  • Wenn Daten benötigt werden, die in den meisten offenen Web-Scale-Datensätzen, die zum Training bestehender Modelle verwendet wurden, nicht verfügbar sind
  • Wenn bereits ein MVP gebaut wurde, das zeigt, dass bestehende Modelle nicht ausreichen
  • Aber Vorsicht: Wenn selbst Model Builder nicht ohne Weiteres an hervorragende Trainingsdaten kommen, woher sollen sie dann kommen?
• LLM-basierte Anwendungen sind keine Projekte für die Wissenschaftsmesse
  • Es sollte nur in einem Maß investiert werden, das dem Beitrag zu strategischen Zielen und zur Differenzierung im Wettbewerb entspricht

Mit einer Inference-API starten, aber Self-Hosting nicht fürchten

• Mit LLM-APIs können Startups Sprachmodellierungsfunktionen leicht übernehmen und integrieren, ohne von Grund auf eigene Modelle trainieren zu müssen
  • Anbieter wie Anthropic und OpenAI stellen allgemeine APIs bereit, mit denen sich Produkten mit nur wenigen Zeilen Code Intelligenz verleihen lässt
  • Wer solche Dienste nutzt, kann den Aufwand verringern und sich auf die Wertschöpfung für Kundinnen und Kunden konzentrieren, Ideen schneller validieren und den Product-Market-Fit schneller iterieren
• Doch wie bei Datenbanken gilt auch hier: Managed Services passen mit zunehmender Größe und steigenden Anforderungen nicht zu jedem Use Case
  • Tatsächlich kann Self-Hosting die einzige Möglichkeit sein, Modelle zu verwenden, ohne vertrauliche oder personenbezogene Daten aus dem eigenen Netzwerk herauszusenden, wie es in regulierten Branchen wie dem Gesundheitswesen und dem Finanzsektor oder durch vertragliche Pflichten und Vertraulichkeitsanforderungen nötig sein kann
• Außerdem umgeht Self-Hosting Beschränkungen wie Rate Limits, das Einstellen von Modellen und Nutzungsgrenzen, die Inference-Anbieter auferlegen
  • Self-Hosting gibt die vollständige Kontrolle über das Modell und erleichtert so den Aufbau differenzierter Systeme mit hoher Qualität
• Schließlich kann Self-Hosting, insbesondere Fine-Tuning, im großen Maßstab Kosten senken
  • Buzzfeed teilte zum Beispiel einen Fall, in dem durch Fine-Tuning eines Open-Source-LLM die Kosten um 80 % gesenkt wurden

Strategie 2: In Richtung eines Besseren iterieren

• Um langfristig einen Wettbewerbsvorteil zu halten, muss man über das Modell hinaus an Faktoren denken, mit denen sich das Produkt differenzieren lässt
• Ausführungsgeschwindigkeit ist wichtig, sollte aber nicht der einzige Vorteil sein

Das Modell ist nicht das Produkt, sondern das System darum herum

• Für Teams, die kein eigenes Modell bauen, ist das schnelle Innovationstempo ein Segen
  • Denn sie können auf neuere Modelle migrieren und dadurch bessere Produkte bauen, indem sie Verbesserungen bei Kontextgröße, Schlussfolgerungsfähigkeit und Preis-Leistungs-Verhältnis nutzen
  • Diese Fortschritte sind auf vorhersehbare Weise spannend
  • Insgesamt ist das Modell wahrscheinlich die am wenigsten dauerhafte Komponente im System
• Stattdessen sollte der Aufwand auf Bereiche konzentriert werden, die dauerhaft Wert liefern können
  • Evals: um die Task-Performance zuverlässig modellübergreifend zu messen
  • Guardrails: um unerwünschte Ausgaben unabhängig vom Modell zu verhindern
  • Caching: um Latenz und Kosten zu senken, indem das Modell ganz umgangen wird
  • Data flywheel: um iterative Verbesserungen von all dem oben Genannten voranzutreiben
  • Diese Komponenten schaffen einen stärkeren Produktqualitäts-Graben als rohe Modellfähigkeiten
• Das bedeutet jedoch nicht, dass der Aufbau auf der Application Layer risikofrei ist
  • Wenn OpenAI oder ein anderer Modellanbieter brauchbare Enterprise-Software liefert, sollte man nicht an Bereichen herumschneiden, die später einfach herausgeschnitten werden können
• Manche Teams haben zum Beispiel in den Aufbau maßgeschneiderter Tools investiert, um strukturierte Ausgaben proprietärer Modelle zu validieren
  • Eine minimale Investition hier ist wichtig, aber tief einzusteigen ist keine gute Nutzung der Zeit
  • OpenAI sollte bei einer Anfrage für Function Calling auch gültige Function Calls liefern, weil alle Kundinnen und Kunden das wollen
  • Hier sollte „strategisches Aufschieben“ gelten: nur bauen, was absolut nötig ist, und auf den Ausbau der Anbieterfunktionen warten

Klein anfangen und Vertrauen gewinnen

• Ein Produkt bauen zu wollen, das für alle alles ist, ist ein Rezept für Mittelmaß
• Um ein überzeugendes Produkt zu schaffen, müssen Unternehmen sich darauf spezialisieren, eine klebrige Erfahrung aufzubauen, zu der Nutzerinnen und Nutzer immer wieder zurückkehren
• Betrachten wir ein generisches RAG-System, das alle Fragen der Nutzer beantworten will
  • Fehlende Spezialisierung bedeutet, dass das System aktuelle Informationen nicht priorisieren, domänenspezifische Formate nicht parsen und die Nuancen bestimmter Aufgaben nicht verstehen kann
  • Das Ergebnis ist eine oberflächliche und unzuverlässige Erfahrung, die Anforderungen nicht erfüllt und zur Abwanderung führt
• Um das zu lösen, muss man sich auf eine bestimmte Domäne und konkrete Use Cases konzentrieren
  • Der Umfang sollte zugunsten von Tiefe verengt werden statt auf Breite zu setzen
  • So lassen sich domänenspezifische Tools schaffen, die bei Nutzerinnen und Nutzern Resonanz erzeugen
• Durch Spezialisierung lassen sich Fähigkeiten und Grenzen des Systems ehrlich vermitteln
  • Transparent offenzulegen, was das System kann und was nicht, zeigt Selbstbewusstsein, hilft Nutzerinnen und Nutzern zu verstehen, wo sie den größten Mehrwert erzielen können, und schafft dadurch Vertrauen und Zuversicht in die Ausgaben

LLMOps aufbauen, aber aus den richtigen Gründen: schnelle Iteration

• DevOps bedeutet im Kern nicht reproduzierbare Workflows oder Shift-left oder die Befähigung von Zwei-Pizza-Teams. Und schon gar nicht das Schreiben von YAML-Dateien
• Bei DevOps geht es darum, den Feedback-Zyklus zwischen Arbeit und ihren Ergebnissen zu verkürzen, sodass sich Verbesserungen statt Fehlern ansammeln
  • Seine Wurzeln reichen über die Lean-Startup-Bewegung zurück zur Lean-Fertigung und zum Toyota-Produktionssystem, mit einem Fokus auf Single-Minute Exchange of Die und Kaizen
• MLOps hat die Form von DevOps auf ML angewandt
  • Es gibt All-in-One-Tool-Suiten für reproduzierbare Experimente und dafür, Modellentwickler zum Deployen zu befähigen. Mit vielen YAML-Dateien
• Als Branche hat MLOps die Funktion von DevOps jedoch nicht übernommen. Die Feedback-Lücke zwischen dem Modell und Inferenz sowie Interaktionen in der Produktion wurde nicht verkleinert
• Glücklicherweise hat sich der Bereich LLMOps von trivialen Problemen wie Prompt-Management abgewandt und hin zu kontinuierlicher Verbesserung orientiert, die zu den schwierigen Problemen führt, welche Iteration behindern: Monitoring und Evaluation in der Produktion
• Es gibt bereits interaktive Arenen für neutrale, crowdsourcte Evaluationen von Chat- und Coding-Modellen. Das ist die äußere Schleife kollektiver, iterativer Verbesserung
  • Tools wie LangSmith, Log10, LangFuse, W&B Weave und HoneyHive versprechen nicht nur, Daten zu Systemergebnissen in der Produktion zu erfassen und aufzubereiten, sondern sich auch tief in die Entwicklung zu integrieren, um zur Verbesserung dieser Systeme genutzt zu werden. Nutzt diese Tools oder baut selbst welche

Baut keine LLM-Funktionalität, die man kaufen kann

• Die meisten erfolgreichen Unternehmen sind keine LLM-Unternehmen. Gleichzeitig gibt es in den meisten Unternehmen Chancen, mit LLMs Verbesserungen zu erzielen
• Diese beiden Beobachtungen führen Führungskräfte oft in die Irre: Sie bauen hastig Systeme mit LLMs um und veröffentlichen künstliche, eitle „AI“-Features, die die Kosten erhöhen und die Qualität senken. Der gefürchtete Glitzer-Icon-Moment ist damit vollendet
• Es gibt einen besseren Weg: Konzentriert euch auf LLM-Anwendungen, die wirklich zu den Produktzielen passen und den Kern des operativen Geschäfts stärken
• Betrachten wir einige Fehlversuche, die nur die Zeit des Teams verschwenden
  • Eine maßgeschneiderte Text-to-SQL-Funktion für das Unternehmen bauen
  • Einen Chatbot bauen, mit dem man mit Dokumenten sprechen kann
  • Die Wissensdatenbank des Unternehmens in einen Customer-Support-Chatbot integrieren
• All das sind zwar Hello-World-Beispiele für LLM-Anwendungen, aber für Produktunternehmen ergibt es keinen Sinn, sie selbst zu bauen
  • Es sind allgemeine Probleme, die in vielen Unternehmen auftreten, bei denen die Lücke zwischen einer vielversprechenden Demo und einer verlässlichen Komponente groß ist, und sie gehören in den angestammten Bereich von Softwarefirmen
  • Es ist Verschwendung, wertvolle R&D-Ressourcen in allgemeine Probleme zu investieren, die gerade von einer ganzen Welle von Y Combinator-Startups in großem Maßstab angegangen werden
• Falls das wie ein abgedroschener Business-Ratschlag klingt: In der aufgeheizten Euphorie der aktuellen Hype-Welle ist es leicht, alles mit dem Etikett „LLM“ für hochmodern und differenzierend zu halten und Anwendungen zu übersehen, die bereits zur Commodity geworden sind

Setzt AI in den Loop, aber den Menschen ins Zentrum

• Heutige LLM-basierte Anwendungen sind fragil. Sie brauchen enorme Mengen an Sicherheitsmaßnahmen und defensive Engineering, bleiben aber dennoch schwer vorhersehbar. Zugleich können solche Anwendungen, wenn ihr Umfang eng begrenzt ist, enorm nützlich sein. Das bedeutet, dass LLMs hervorragende Werkzeuge zur Beschleunigung von Nutzer-Workflows sind
• Man möchte sich vielleicht vorstellen, dass LLM-basierte Anwendungen Workflows vollständig ersetzen oder ganze Jobfunktionen übernehmen, aber das wirksamste Paradigma heute ist der Mensch-Computer-Kentaur (Centaur Chess)
  • Wenn fähige Menschen mit LLM-Funktionalität kombiniert werden, die auf ihre schnelle Nutzung abgestimmt ist, kann das Produktivität und Zufriedenheit bei der Erledigung von Arbeit deutlich steigern
  • Eine der Paradeanwendungen von LLMs, GitHub CoPilot, hat die Stärke dieses Workflows bewiesen
    • „Insgesamt sagten Entwickler, dass das Programmieren mit GitHub Copilot und GitHub Copilot Chat einfacher sei und zu weniger Fehlern, besserer Lesbarkeit, höherer Wiederverwendbarkeit, prägnanterem Code, besserer Wartbarkeit und mehr Robustheit führe.“ – Mario Rodriguez, GitHub
• Wer lange im ML-Bereich gearbeitet hat, kommt schnell auf die Idee von „human-in-the-loop“, aber geht nicht zu hastig dorthin
  • HITL-Machine-Learning ist ein Paradigma, das auf menschlichen Experten basiert, die sicherstellen, dass ML-Modelle wie vorhergesagt funktionieren
  • Was hier vorgeschlagen wird, ist verwandt, aber feiner nuanciert. LLM-basierte Systeme sollten heute nicht die Hauptantriebskraft der meisten Workflows sein, sondern schlicht eine Ressource
• Den Menschen ins Zentrum zu stellen und zu fragen, wie LLMs Workflows unterstützen können, hat deutlich andere Auswirkungen auf Produkt- und Designentscheidungen
  • Am Ende baut ihr dadurch ein anderes Produkt als Wettbewerber, die alle Verantwortung schnell an LLMs auslagern wollen: ein besseres Produkt, nützlicher und weniger riskant

Strategie 3. Mit Prompting, Evals und Datensammlung beginnen

• Im vorherigen Abschnitt wurde eine Menge Technik und Ratschläge abgefeuert. Das ist viel auf einmal. Betrachten wir die minimale Menge an nützlichem Rat
  • Wo sollte ein Team anfangen, wenn es ein LLM-Produkt bauen will?
• Im vergangenen Jahr haben wir genug erfolgreiche LLM-Anwendungen gesehen, um überzeugt zu sein, dass sie einem konsistenten Verlauf folgen. In diesem Abschnitt sehen wir uns dieses grundlegende „Getting Started“-Playbook an
• Die Kernidee ist, einfach anzufangen und Komplexität erst bei Bedarf hinzuzufügen
  • Rule of Thumb: Jede zusätzliche Stufe an Raffinesse erfordert in der Regel mindestens eine Größenordnung mehr Aufwand als die vorherige. Vor diesem Hintergrund ...

Prompt Engineering hat Priorität 1

• Beginnt mit Prompt Engineering
  • Nutzt alle Techniken, die zuvor im Abschnitt zu Taktiken besprochen wurden
  • Chain-of-thought, n-shot-Beispiele sowie strukturierte Ein- und Ausgaben sind fast immer eine gute Idee
  • Erstellt Prototypen mit dem leistungsstärksten Modell, bevor ihr versucht, aus einem schwächeren Modell noch Leistung herauszuquetschen
• Fine-Tuning sollte erst dann in Betracht gezogen werden, wenn sich das gewünschte Leistungsniveau mit Prompt Engineering nicht erreichen lässt
  • Das wird häufiger vorkommen, wenn nichtfunktionale Anforderungen den Einsatz proprietärer Modelle ausschließen und Self-Hosting verlangen, etwa wegen Datenschutz, vollständiger Kontrolle oder Kosten
  • Achtet darauf, dass dieselben Datenschutzanforderungen nicht auch die Nutzung von Nutzerdaten für Fine-Tuning blockieren

Evals bauen und das Daten-Flywheel in Gang setzen

• Auch Teams, die gerade erst anfangen, brauchen Evals. Sonst wissen sie nicht, ob Prompt Engineering ausreicht oder ob ein feinabgestimmtes Modell bereit ist, ein Basismodell zu ersetzen
• Effektive Evals sind auf die Aufgabe zugeschnitten und spiegeln den vorgesehenen Use Case wider
  • Die erste empfohlene Stufe von Evals sind Unit-Tests
  • Solche einfachen Assertions helfen dabei, bekannte oder vermutete Fehlermodi zu erkennen und frühe Designentscheidungen zu treffen
  • Siehe auch weitere aufgabenspezifische Evals für Klassifikation, Zusammenfassung und mehr
• Unit-Tests und modellbasierte Evals sind nützlich, ersetzen aber nicht die Notwendigkeit menschlicher Evaluation
  • Lasst Menschen das Modell/Produkt nutzen und Feedback geben
  • Das erfüllt einen doppelten Zweck: reale Leistung und Fehlerraten messen und zugleich hochwertige annotierte Daten sammeln, die später zum Fine-Tuning des Modells verwendet werden können
  • Dadurch entsteht eine positive Feedback-Schleife oder ein Daten-Flywheel, das mit der Zeit Zinseszinseffekte erzeugt
    • Menschliche Evaluation, um Modellleistung zu bewerten oder Fehler zu finden
    • Annotierte Daten nutzen, um das Modell feinabzustimmen oder Prompts zu aktualisieren
    • Wiederholen
• Wenn man zum Beispiel Defekte in LLM-generierten Zusammenfassungen auditiert, kann man granulare Feedback-Labels vergeben, die bei jedem Satz sachliche Inkonsistenz, Irrelevanz oder schlechten Stil markieren
  • Diese Annotationen zu sachlichen Inkonsistenzen können dann verwendet werden, um einen Halluzinationsklassifikator zu trainieren, oder Relevanz-Annotationen, um ein Relevanz-Reward-Modell zu trainieren
• LinkedIn hat Erfolgsbeispiele für den Einsatz modellbasierter Evaluatoren geteilt, um Halluzinationen, Verstöße gegen Responsible AI, Kohärenz und mehr zu schätzen
• Indem Evals Assets schaffen, deren Wert mit der Zeit steigt, wird ihr Aufbau von reinen Betriebskosten zu einer strategischen Investition – und dabei entsteht ein Daten-Flywheel

Strategie 4. Der übergeordnete Trend hin zu kostengünstiger Kognition (The high-level trend of low-cost cognition)

• 1971 sagten Forscher bei Xerox PARC die Welt der vernetzten Personal Computer voraus, in der wir heute leben
  • Sie trugen auch dazu bei, diese Zukunft hervorzubringen, indem sie eine zentrale Rolle bei der Erfindung der Technologien spielten, die sie ermöglichten (Ethernet, Grafik-Rendering, Maus, Fenster usw.)
• Sie machten außerdem eine einfache Übung
  • Sie betrachteten Anwendungen, die sehr nützlich, aber noch nicht wirtschaftlich waren (z. B. Video-Displays, bei denen RAM in ausreichender Menge zum Ansteuern Tausende von Dollar kostete)
  • Anschließend betrachteten sie historische Preisentwicklungen dieser Technologien (ähnlich dem Moore’schen Gesetz) und sagten voraus, wann diese Technologien wirtschaftlich werden würden
• Dasselbe kann man auch für LLM-Technologie tun, auch wenn es nicht so sauber ist wie Transistoren pro Dollar
  • Man wählt einen lange verwendeten populären Benchmark (z. B. den Datensatz Massively-Multitask Language Understanding) und einen konsistenten Eingabeansatz (5-shot Prompting)
  • Dann vergleicht man im Zeitverlauf die Kosten, Sprachmodelle mit verschiedenen Leistungsniveaus auf diesem Benchmark auszuführen
• Bei festen Kosten steigen die Fähigkeiten schnell. Bei festem Fähigkeitsniveau sinken die Kosten schnell
  • In den vier Jahren seit der Veröffentlichung von OpenAIs davinci-Modell als API sind die Kosten, ein Modell mit vergleichbarer Leistung für diese Aufgabe im Umfang von 1 Million Tokens (etwa 100 Kopien dieses Dokuments) auszuführen, von 20 $ auf unter 10 Cent gefallen. Die Halbwertszeit beträgt nur 6 Monate
  • Ebenso kosten Ausführungen von Metas LLaMA 3 8B über API-Anbieter oder selbst betrieben seit Mai 2024 nur noch 20 Cent pro 1 Million Tokens und zeigen eine ähnliche Leistung wie OpenAIs text-davinci-003, das Modell, das ChatGPT ermöglichte
  • Dieses Modell kostete bei seiner Veröffentlichung Ende November 2023 noch etwa 20 $ pro 1 Million Tokens. In nur 18 Monaten ergibt das einen Unterschied um eine Größenordnung. Das ist derselbe Zeitraum, in dem das Moore’sche Gesetz nur eine einfache Verdopplung vorhersagt
• Betrachten wir nun LLM-Anwendungen, die sehr nützlich, aber noch nicht wirtschaftlich sind (etwa das Antreiben generativer Videospielcharaktere wie bei Park et al.), deren Kosten auf 625 $ pro Stunde geschätzt werden
  • Seit der Veröffentlichung dieser Arbeit im August 2023 sind die Kosten bereits um etwa eine Größenordnung auf rund 62,50 $ pro Stunde gefallen
  • 9 Monate später könnte man erwarten, dass sie auf 6,25 $ pro Stunde fallen
• Als Pac-Man 1980 erschien, konnte man für den Gegenwert von 1 heutigen Dollar Credits kaufen, mit denen man einige Minuten oder einige Dutzend Minuten spielen konnte. Nennen wir das 6 Spiele pro Stunde oder 6 $ pro Stunde
  • Diese Überschlagsrechnung deutet darauf hin, dass überzeugende LLM-verstärkte Spielerlebnisse um 2025 wirtschaftlich werden könnten
• Diese Trends sind neu und erst wenige Jahre alt. Es gibt jedoch kaum Gründe anzunehmen, dass sich dieser Prozess in den kommenden Jahren verlangsamen wird
  • Selbst wenn man niedrig hängende Früchte bei Algorithmen und Datensätzen ausschöpft, wie etwa die Skalierung über das „Chinchilla-Verhältnis“ von ~20 Tokens pro Parameter hinaus, werden tiefere Innovationen und Investitionen innerhalb von Rechenzentren und in den Siliziumschichten diese Lücke schließen
• Und das ist wahrscheinlich die wichtigste strategische Tatsache
  • Floor-Demos oder Forschungsarbeiten, die heute völlig unrealisierbar sind, werden in ein paar Jahren Premium-Features und kurz darauf Commodity sein
  • Systeme und Organisationen sollten mit diesem Gedanken im Hinterkopf aufgebaut werden

[Eine Demo von 0 auf 1 reicht jetzt aus. Jetzt geht es darum, Produkte von 1 auf N zu bauen]

• Es macht wirklich Spaß, LLM-Demos zu bauen. Mit ein paar Zeilen Code, einer Vektordatenbank und sorgfältig geschriebenen Prompts entsteht „Magie“
• Im vergangenen Jahr wurde diese Magie mit dem Internet, dem Smartphone und sogar dem Buchdruck verglichen
• Leider weiß jeder, der schon einmal echte Software ausgeliefert hat, dass zwischen einer Demo, die in einer kontrollierten Umgebung funktioniert, und einem Produkt, das im großen Maßstab zuverlässig läuft, ein gewaltiger Unterschied besteht
• Es gibt viele Probleme, die sich leicht vorstellen und als Demo umsetzen lassen, aber sehr schwer in Produkte verwandeln lassen
  • Zum Beispiel autonomes Fahren: Ein Auto einen Block lang autonom fahren zu lassen, lässt sich leicht demonstrieren, aber daraus ein Produkt zu machen, dauert 10 Jahre – Andrej Karpathy
• Nehmen wir autonome Fahrzeuge als Beispiel
  • 1988 erschien das erste Auto, das von einem neuronalen Netz gesteuert wurde
  • 25 Jahre später machte Andrej Karpathy seine erste Demo-Fahrt bei Waymo
  • 10 Jahre danach erhielt das Unternehmen die Genehmigung für fahrerlosen Betrieb
  • Der Weg vom Prototyp zum kommerziellen Produkt umfasste 35 Jahre rigoroser Ingenieursarbeit, Tests, Verbesserungen und regulatorischer Navigation
• In Industrie und Wissenschaft hinweg habe ich im vergangenen Jahr die Höhen und Tiefen beobachtet: Jahr 1 von N für LLM-Anwendungen
  • Ich hoffe, dass die Lektionen, die wir gelernt haben – von Taktiken wie Evaluation, Prompt Engineering und Guardrails bis hin zu strategischen Perspektiven wie operativer Exzellenz, Teamaufbau und der Entscheidung, was intern aufgebaut werden sollte – für Jahr 2 und darüber hinaus hilfreich sein werden
  • Ich freue mich darauf, diese spannende neue Technologie gemeinsam weiterzuentwickeln

[inthelife]

Der Inhalt ist so gut, dass ich daraus eine Mindmap gemacht habe, um ihn mir immer wieder anzusehen ^^;

https://drive.google.com/file/d/…

[hheungsu]

Ein wirklich großartiger Artikel!! Von Anfang bis Ende gibt es viele nützliche Gedanken, über die man immer wieder nachdenken kann. Vielen Dank, dass ihr so einen perlenreichen Text übersetzt und veröffentlicht habt!!

[nutella]

Das ist im Moment wirklich sehr hilfreich.

[komanabi]

Megastudy ist vorbei, jetzt kommt Omega-3!!!

[ssifood]

Skynet ist jetzt vorbei, MegaStudy kommt.

[my0075425]

Jetzt ist die Menschheit am Ende, Skynet kommt!!

[zihado]

Auch der Karriereweg des Autors des Originalbeitrags war interessant.
https://de.news.hada.io/topic?id=1626

[eungook]

Wow … das ist unglaublich inspirierend … danke für die Vorstellung.

[humblebee]

Ein großartiger Text, in dem Einsichten und Erfahrungen lebendig spürbar werden! Ich denke, er wird für mein Team und mich eine große Hilfe sein. Ich habe ihn mit großem Interesse gelesen. Vielen Dank ☺️