3 Punkte von GN⁺ 2023-09-24 | 1 Kommentare | Auf WhatsApp teilen
  • Große LLMs können neue Aufgaben allein mit Few-Shot lösen, aber die Serving-Kosten sind hoch. Das Google-Cloud-AI-Team schlägt daher Distilling Step-by-Step vor, bei dem kleine, auf Aufgaben spezialisierte Modelle gemeinsam mit natürlichsprachlichen Begründungen (Rationales) trainiert werden.
  • Dieser Ansatz extrahiert per Few-Shot-Chain-of-Thought (CoT) die Zwischenschritte des LLM und überführt sie in Multitask-Lernen, bei dem ein T5-Modell sowohl Label-Vorhersage als auch Begründungsgenerierung lernt.
  • In den Experimenten wurde PaLM mit 540B als Referenz-LLM und T5 als Downstream-Modell verwendet; bewertet wurden e-SNLI, ANLI, CQA und SVAMP für natürliches Sprachschlussfolgern, Commonsense-QA und arithmetische Textaufgaben.
  • Bei e-SNLI wurde mit nur 12,5 % der Gesamtdaten eine bessere Leistung als mit Standard-Fine-Tuning erreicht; bei ANLI übertraf ein T5 mit 770M unter Nutzung von 80 % der Daten die Few-Shot-Leistung von PaLM 540B und reduzierte die Modellgröße um mehr als das 700-Fache.
  • Der Ansatz verringert den Trade-off zwischen der Bereitstellung kleiner Modelle und den Kosten für die Erhebung von Trainingsdaten und ist in Vertex AI als Private Preview verfügbar.

Die Kosten der LLM-Bereitstellung und die Grenzen des Trainings kleiner Modelle

  • LLMs können mit Zero-Shot- und Few-Shot-Prompting neue, bislang ungesehene Aufgaben bearbeiten, doch in realen Services ist die Modellgröße eine große Einschränkung.
    • Um ein LLM mit 175B Parametern zu serven, werden auf Spezialinfrastruktur mindestens 350 GB GPU-Speicher benötigt.
    • Die damals neuesten LLMs waren mit mehr als 500B Parametern aufgebaut.
  • In der Praxis werden daher oft kleinere, auf einzelne Aufgaben spezialisierte Modelle bereitgestellt; typischerweise kommen zwei Verfahren zum Einsatz.
    • Fine-Tuning: Ein kleines vortrainiertes Modell wie BERT oder T5 wird mit von Menschen gelabelten Downstream-Daten aktualisiert.
    • Distillation: Ein kleines Modell wird mit Labels trainiert, die von einem größeren LLM erzeugt wurden.
  • Beide Verfahren verursachen weiterhin Kosten.
    • Fine-Tuning benötigt von Menschen erzeugte Labels, was teuer und arbeitsintensiv ist.
    • Distillation erfordert große Mengen ungelabelter Daten, die ebenfalls schwer zu beschaffen sein können.

Die Kernidee von Distilling Step-by-Step

  • Distilling Step-by-Step! Outperforming Larger Language Models with Less Training Data and Smaller Model Sizes ist ein Ansatz, der den Trade-off zwischen Modellgröße und den Kosten der Datenerhebung für das Training verringern soll.
  • Distilling Step-by-Step extrahiert natürlichsprachliche Begründungen, also Zwischenschritte der Argumentation, aus einem LLM und nutzt sie als zusätzliches Aufsichtssignal für das Training kleiner Modelle.
  • Natürlichsprachliche Begründungen machen die Verbindung zwischen Eingabefrage und Ausgabenantwort sichtbar.
    • Wenn zum Beispiel Länge und Breite eines Raums sowie die bereits vorhandene Teppichfläche gegeben sind, kann das LLM eine Zwischenbegründung wie „Area = length * width“ erzeugen.
    • Solche Begründungen können Aufgabenwissen enthalten, das ein kleines Modell sonst erst aus vielen Daten lernen müsste.
  • Anstatt nur Labels zu lernen, lernt das kleine Modell Labels und Begründungen gemeinsam und kann so mit weniger Daten die Aufgabe beherrschen.

Zweistufiges Trainingsverfahren

  • Im ersten Schritt werden mit Few-Shot-CoT-Prompting Begründungen aus dem LLM extrahiert.
    • Für jede Aufgabe werden Beispiele aus drei Elementen — Eingabe, Begründung und Ausgabe — in den LLM-Prompt aufgenommen.
    • Das LLM folgt diesen Beispielen und erzeugt Begründungen für neue Eingaben.
  • Im Beispiel für Commonsense-QA wird die Frage „Sammy wanted to go to where the people are“ zusammen mit Antwortoptionen gegeben.
    • Die richtige Antwort ist „(a) populated areas“.
    • Die Begründung stellt die Verbindung her: Es muss ein Ort sein, an dem viele Menschen sind, und unter den Optionen trifft das nur auf populated areas zu.
  • Im zweiten Schritt werden die extrahierten Begründungen in das Training des kleinen Modells eingebracht.
    • Zusätzlich zur Standardaufgabe der Label-Vorhersage wird eine neue Aufgabe der Begründungsgenerierung trainiert.
    • Vor den Modelleingaben stehen Aufgabenpräfixe wie [label] oder [rationale], um beide Aufgaben zu unterscheiden.
    • Die Aufgabe der Begründungsgenerierung trainiert das Modell darauf, Zwischenschritte der Argumentation zu erzeugen, und führt dadurch letztlich zu besserer Label-Vorhersage.

Versuchsaufbau und Vergleichsmaßstäbe

  • Das Referenz-LLM ist PaLM 540B.
  • Als aufgaben­spezifisches Downstream-Modell werden T5-Modelle verwendet.
  • Für CoT-Prompting werden nach Möglichkeit bestehende CoT-Prompts genutzt; für neue Datensätze werden Beispiele direkt erstellt.
  • Die Evaluation erfolgt auf 4 Benchmarks aus 3 NLP-Aufgaben.
    • e-SNLI, ANLI: natürliches Sprachschlussfolgern
    • CQA: Commonsense-QA
    • SVAMP: arithmetische Textaufgaben
  • Es gibt zwei Vergleichslinien.
    • Für den Vergleich mit per Few-Shot geprompteten LLMs wird Few-Shot-CoT-Prompting mit PaLM 540B verwendet.
    • Auch Standard-Fine-Tuning und Standard-Distillation sind Teil des Vergleichs; der Blogbeitrag konzentriert sich jedoch vor allem auf den Vergleich mit Standard-Fine-Tuning.

Besser als Standard-Fine-Tuning mit weniger Trainingsdaten

  • Distilling Step-by-Step erzielt mit deutlich weniger Trainingsdaten bessere Ergebnisse als Standard-Fine-Tuning.
  • Bei e-SNLI wird mit nur 12,5 % des vollständigen Datensatzes eine bessere Leistung erreicht als mit Standard-Fine-Tuning, das auf dem gesamten Datensatz trainiert wurde.
  • Auch bei den anderen Datensätzen sinkt die benötigte Datenmenge.
    • ANLI: Reduktion der Datensatzgröße um 75 %
    • CQA: Reduktion der Datensatzgröße um 25 %
    • SVAMP: Reduktion der Datensatzgröße um 20 %
  • Dieser Vergleich wurde mit T5-Modellen mit 220M Parametern auf von Menschen gelabelten Datensätzen unterschiedlicher Größe durchgeführt.

Mit kleineren Bereitstellungsmodellen besser als PaLM

  • Distilling Step-by-Step erzielt mit viel kleineren Modellen bessere Ergebnisse als ein LLM mit Few-Shot-CoT-Prompting.
  • Bei e-SNLI erzielt ein T5-Modell mit 220M Parametern bessere Ergebnisse als PaLM 540B.
  • Bei ANLI erzielt ein T5-Modell mit 770M Parametern bessere Ergebnisse als PaLM 540B.
    • Dieses Modell ist mehr als 700-mal kleiner als PaLM.
    • Dasselbe T5-Modell mit 770M erreicht mit reinem Standard-Fine-Tuning die Leistung von PaLM nur schwer.
  • Das Ergebnis zeigt zugleich kleine Modellgrößen und eine Leistung oberhalb des LLM-Referenzwerts.

Ergebnisse bei gleichzeitig weniger Daten und kleineren Modellen

  • Bei ANLI übertrifft Distilling Step-by-Step mit T5 770M und nur 80 % der Gesamtdaten die Few-Shot-Leistung von PaLM 540B.
  • Unter denselben Bedingungen kann Standard-Fine-Tuning die Leistung von PaLM selbst mit 100 % der Gesamtdaten nicht erreichen.
  • Durch eine grobe Suche wurden die minimale T5-Modellgröße und die minimale Zahl menschlich gelabelter Beispiele bestimmt, die nötig sind, um die Few-Shot-CoT-Leistung des LLM zu übertreffen.
  • Damit reduziert der Ansatz zugleich die nötige Größe des Bereitstellungsmodells und die Menge der Trainingsdaten, die erforderlich sind, um die LLM-Leistung zu übertreffen.

Bereitstellung

  • Distilling Step-by-Step ist in Vertex AI als Private Preview verfügbar.
  • Wer es nutzen möchte, soll sich mit Google-Cloud-Projektnummer und einer Zusammenfassung des Anwendungsfalls an vertex-llm-tuning-preview@google.com wenden.

1 Kommentare

 
GN⁺ 2023-09-24
Meinungen auf Hacker News
  • Ich vermute, dass kleinere Expertenmodelle die meisten Anwendungen dominieren werden. Zwischen Größe und Nutzbarkeit gibt es einen Sweet Spot und eine feine Balance; verschiedene Mechanismen wie die im Artikel gezeigten dürften helfen, diesen Sweet Spot zu finden und umzusetzen.

    • Große universelle Modelle könnten aus mehreren kleinen Expertenmodellen bestehen, plus einem Vermittlungsmodell, das entscheidet, welches domänenspezifische Modell gefragt werden soll.
  • Interessant, dass für das destillierte Modell T5 verwendet wurde. Ich dachte, Encoder-Decoder-Architekturen seien auf dem Rückzug, aber offenbar sind sie weiterhin relevant.
    Interessant ist auch, dass diese Idee nicht unvorstellbar genial oder völlig unkonventionell ist. Das zeigt, dass es noch viel low-hanging fruit zu erkunden gibt und dass die Zukunft großer Sprachmodelle noch nicht feststeht. Die eigentliche Lösung könnte eine auf diese Weise trainierte Mischung aus Experten sein. Es ist spannend, dass ein dem heiligen Gral nahekommendes Ziel erreichbar wirkt, wenn man nur die richtige Kombination von Ideen findet.

    • Die T5-Familie ist hervorragend. FastChat-T5 liefert eine erstaunliche Qualität bei der Textgenerierung, eignet sich zum Beispiel gut für Chatbots mit Retrieval-Augmented Generation und lässt sich sogar auf CPUs schnell genug für Echtzeitdialoge betreiben.
    • Das erwähnte Paper wurde im Mai eingereicht. Encoder-Decoder-Architekturen wirken bei multimodalen Modellen weiterhin ziemlich plausibel.
      Es gibt noch viel low-hanging fruit. Ich habe gefühlt Dutzende Varianten gesehen: Chain of Thought, Tree of Thoughts, Graph of Thoughts, self-ask, self-critique, self-plan, self-reflect und so weiter.
    • Mich würde interessieren, warum du dachtest, dass Encoder-Decoder-Architekturen auf dem Rückzug seien.
  • Das Ausmaß an Aktivität und Fortschritt im Bereich großer Sprachmodelle/Machine Learning/Künstliche Intelligenz ist wirklich beeindruckend. Gerade wenn Hardware wie die von Nvidia sehr teuer ist, sind solche Optimierungen besonders wertvoll.

  • Ist das nicht dasselbe wie https://arxiv.org/abs/2212.08410, nur ein Jahr später?

    • Die Verbesserungen sind beeindruckend, aber GSM8K 22 % zieht als Endergebnis nicht gerade die Blicke auf sich.
  • Ich bin kein Forscher, hatte aber immer die Intuition, dass die effektivsten Modelle multimodal sein und mit einem sorgfältig gestalteten Kerncurriculum trainiert werden dürften.
    Man möchte sicherstellen, dass das System die Grundstrukturen und Fähigkeiten erwirbt und beibehält, die es braucht, um effektiv und korrekt zu generalisieren. Man erhält diese Dinge und füttert es gleichzeitig mit vielen unterschiedlichen Daten, damit es Ausnahmen und Kombinationen von Fähigkeiten lernt. Allerdings braucht man eine Möglichkeit, die Kernfähigkeiten und das Kernwissen bis zum Ende sicherzustellen. Vielleicht geht das, wenn man es nicht nur die endgültige Antwort ausgeben lässt, sondern auch den Prozess des Verstehens oder der Manipulation, so wie es im Paper gemacht wird.
    Bei einem Modell zur Codegenerierung könnte man zum Beispiel verlangen, dass es eine Zustandsmaschinen-Simulation des angeforderten Programms ausgibt.

    • Ich stimme zu, dass Multimodalität der richtige Weg ist, aber es ist keineswegs intuitiv, warum man erwarten sollte, dass das Curriculum unbedingt sorgfältig gestaltet werden muss. Ein Vergleich mit https://gwern.net/scaling-hypothesis lohnt sich.
    • Wenn man an die Idee eines schulischen Curriculums denkt, frage ich mich, ob die Reihenfolge der Trainingsdaten einen Unterschied macht. Es könnte davon abhängen, ob man von Einfach zu Komplex füttert oder umgekehrt. Gradientenabstieg könnte doch sicher in anderen lokalen Minima landen, die besser oder schlechter sind.
  • Beim ersten Bild frage ich mich, warum die Menge an Trainingsdaten für das große Sprachmodell geringer ist als für das destillierte Modell und das aufgabenspezifische Modell.
    Oder rechnen die Autoren die Trainingsdaten, die für das große Sprachmodell nötig sind, in die für das destillierte/aufgabenspezifische Modell nötigen Trainingsdaten mit ein?
    https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj...

    • Genau. Es wird die Datenmenge gezählt, die man selbst sammeln muss, um das Problem zu lösen.
      Man kann ein vortrainiertes großes Sprachmodell nehmen; in diesem Fall sind die Daten, die ich sammeln muss, die Daten, die für das Fine-Tuning dieses Modells nötig sind.
  • Steckt in diesen riesigen großen Sprachmodellen viel ungenutzte Kapazität, oder imitiert das kleine Sprachmodell die Inferenzaufgabe einfach nur? Also eine Imitation der Imitation?

    • Zwischen Realität und Imitation gibt es keinen wesentlichen Unterschied.
      In den Datensätzen, mit denen riesige große Sprachmodelle trainiert werden, steckt viel Rauschen, das den Fortschritt bremst. Außerdem ist viel irrelevantes Wissen enthalten, das das Modell ebenfalls lernen oder memorisieren muss, weshalb absurd viele Parameter nötig werden.
      Wenn man einem Sprachmodell nicht die Gesamtheit des menschlichen Wissens beibringen will, sondern ihm einen hochwertig kuratierten Datensatz gibt, liegt die Skalierungsbarriere deutlich niedriger.
      https://arxiv.org/abs/2305.07759
    • Die Frage klingt fast gleichbedeutend mit „Sind die heutigen riesigen großen Sprachmodelle nahe am Optimum?“, und es scheint offensichtlich, dass sie es nicht sind.
      Ich frage mich, welche Ideen es geben könnte, um die optimale Größe abzuschätzen.
    • Große Modelle generalisieren besser. Kleine Modelle lassen sich leichter auf bestimmte Aufgaben trainieren.
  • Interessant. Ist RLHF zwingend nötig, damit ein kleines Modell eine ähnliche Leistung wie aktuelle große Sprachmodelle erreicht? Probleme rund um Ausgabestruktur, Tonfall und Domänenverständnis dürften sich mit Instruction Tuning lösen lassen, aber ich weiß nicht, ob das auch ausreicht, um die Schlussfolgerungsfähigkeit kleiner Modelle zu verbessern.

  • Angeblich braucht man mindestens 350 GB GPU-Speicher in spezieller Infrastruktur, um ein großes Sprachmodell mit 175 Milliarden Parametern zu betreiben.
    Apple verkauft den Mac Studio mit bis zu 144 GB nutzbarem GPU-Speicher.
    Wenn Apple einen Mac Pro mit über 300 GB herausbrächte und den Markt für das Serving großer Sprachmodelle dominieren würde, wäre das ziemlich interessant.

    • Gibt es ein Framework, das große Sprachmodelle unter Metal im Batch verarbeiten kann? Bei GGML oder MLC scheint es das noch nicht zu geben.
      Falls nicht, ist das derzeit nur ein weiterer Grund, warum es sich nicht gut für das Hosting großer Sprachmodelle eignet.
      Wirklich den Markt aufmischen könnte ohnehin Intel. Theoretisch könnten sie mit 2x48-GB-Arc-Karten einsteigen und einen Markt günstiger angreifen, in den AMD/Nvidia wegen ihrer Kunden für Profikarten nicht einsteigen.
    • Ich hoffe, dass Apples Hardware-Vorteile in der M3-Generation richtig zur Geltung kommen. Dass der A17 Pro Raytracing-Unterstützung bekommen hat, gibt Hoffnung, dass Apple schnell zu den etablierten Marktführern aufschließen kann.
      Ehrlich gesagt ist das der einzige Grund, der mich von aktueller Apple-Hardware abhält. Ich nutze den Computer hauptsächlich am Schreibtisch, und PC-Hardware, insbesondere GPUs, ist dem, was Apples Spitzenprodukte leisten können, weit voraus. Linux passt sehr gut zu meiner Arbeit, und nach Feierabend kann ich auch spielen; da lassen sich fast 4.000 Dollar schwer rechtfertigen.
    • Ich frage mich, wer als Erster die RAM-Kapazität seiner Hardwareprodukte drastisch erhöht, um die Nutzerbasis großer Sprachmodelle zu gewinnen. Das wirkt wie ein Weg zu mehr Marktanteil.
    • Diese Zahl gilt sogar ohne Quantisierung. Wenn man 175 Milliarden Parameter auf 4 Bit quantisiert, sollte es in etwa 120 GB VRAM passen. Ein Modell mit 34 Milliarden Parametern passt mit 4-Bit-Quantisierung sogar auf eine einzelne RTX 3090 mit 24 GB VRAM.
  • Ich frage mich, ob Facebook große Sprachmodelle mit dem gesamten Chatverlauf aller Nutzer trainieren kann.