Mein Fine-Tuning-Modell übertrifft OpenAI GPT-4

 (mlops.systems)
1 Punkte von GN⁺ 2024-07-02 | 1 Kommentare | Auf WhatsApp teilen
  • In 724 Tests zur Extraktion strukturierter Daten aus ISAF-Pressemitteilungen erzielten mehrere Fine-Tuning-Modelle eine höhere Genauigkeit als die GPT-4-Familie
  • Der Vergleich umfasste GPT-4o, GPT-4 Turbo, GPT-3.5 Turbo sowie Fine-Tuning-Modelle auf Basis von TinyLlama, Mistral, Llama3, Solar und GPT-3.5
  • Die OpenAI-Modelle lieferten stets gültiges JSON, und auch die Fine-Tuning-Modelle Mistral und Llama3 waren stabil; bei TinyLlama schwankten jedoch je nach Template fehlende Werte und JSON-Qualität stark
  • In der Endauswertung lag das mit OpenPipe finegetunte Mistral-7B auf Platz 1, dicht gefolgt von Solar LLM und Llama3-7B
  • Fine-Tuning bietet potenziell Vorteile bei Datenschutz, Kontrolle und Kosten, erhöht aber zugleich die MLOps-Komplexität beim Management von Inferenz, Evaluation und Reproduzierbarkeit über Modelle hinweg, die auf verschiedene Umgebungen verteilt sind

Ziel des Experiments und Datensatz

  • Ziel war es, die Genauigkeit von finegetunten LLMs bei der Extraktion von Event-Informationen aus ISAF-Pressemitteilungen zu bewerten
  • Die Daten liegen in einem öffentlichen Repository auf dem Hugging Face Hub; die Evaluation erfolgte mit einem Test-Split, den die Modelle nicht gesehen hatten
    • Die Testdaten bestehen aus 724 Zeilen
    • Die Felder umfassen unter anderem name, eventrefnumber, text, StartDate, eventtype, province, targetgroup, minkilled, mincaptured, killq, captureq, killcaptureraid, airstrike, noshotsfired, minleaderskilled, minleaderscaptured
  • Jede Zeile wurde in ein Pydantic-Objekt umgewandelt, um Validierung und Verarbeitung zu erleichtern
  • Für die Modellausgabe wurde die folgende JSON-Struktur erwartet
    • name
    • start_date
    • event_type
    • province
    • target_group
    • min_killed
    • min_captured
    • killq
    • captureq
    • killcaptureraid
    • airstrike
    • noshotsfired
    • min_leaders_killed
    • min_leaders_captured

Evaluationsmethode für die OpenAI-Baseline-Modelle

  • Als Baselines für den Vergleich wurden GPT-4o, GPT-4 Turbo und GPT-3.5 Turbo verwendet
  • Die GPT-Modelle konnten nicht exakt denselben Prompt wie die Fine-Tuning-Modelle verwenden und benötigten daher einen längeren Prompt
    • Die zu extrahierenden Felder wurden explizit aufgelistet
    • Zulässige Werte für Event-Typ, Provinz und Zielgruppe wurden angegeben
    • Regeln zur Annotation von Zahlen wurden aufgenommen
    • Eine Beispiel-Pressemitteilung und die erwartete JSON-Ausgabe wurden gemeinsam eingefügt
  • Für die Regeln zur Annotation von Zahlen galten folgende Kriterien
    • a couple wird als 2 interpretiert
    • several wird als mindestens 3 interpretiert
    • a few, some, a group, a small group, multiple werden als mindestens 3 interpretiert
    • numerous, a handful werden als mindestens 4 interpretiert
    • a large number wird als mindestens 5 interpretiert
    • facilitator ist kein leader
  • Die Massen-Vorhersagen liefen asynchron; wegen des Rate Limits von GPT-3.5 Turbo wurde eine Retry-Logik ergänzt
  • Die Vorhersageergebnisse wurden im Feld predictions jedes Events nach Modellname gespeichert

Aufbau der Fine-Tuning-Modelle

  • Nach den Vorhersagen der OpenAI-Baselines wurden Vorhersagen zuvor finegetunter lokaler Modelle und von Modellen aus One-Click-Fine-Tuning-Services demselben Datensatz hinzugefügt
  • Die enthaltenen Fine-Tuning-Modelle waren:
    • tinyllama-templatefree
    • tinyllama-sharegpt
    • mistral-lora-templatefree
    • finetuned-openai-gpt-3.5-turbo-1106
    • finetuned-mistral-7b-optimised-openpipe
    • ft-solar-1-mini-chat-240612-predibase
    • finetuned-llama3-7b-32k-openpipe
  • Das lokal finegetunte Mistral-Modell war lokal schwer auszuführen und wurde daher in einer A100-Umgebung von Modal inferiert
    • In der späteren Evaluation scheiterte es bei nahezu allen Einträgen
    • In den Charts wird es als mistral-lora-templatefree angezeigt
  • Mit OpenAIs One-Click-Fine-Tuning-Service wurde das Modell gpt-3.5-turbo-1106 finegetunt
  • Über OpenPipe wurden Vorhersagen für Mistral 7B, Mistral 8x7B und Llama3 erzeugt
  • Bei Predibase wurde ein Modell auf Basis von Upstages Solar LLM evaluiert
    • Solar LLM wird als Modell vorgestellt, das für Aufgaben stark sein soll, bei denen Fine-Tuning häufig eingesetzt wird, etwa die Extraktion strukturierter Daten
    • Als Basismodell wird upstage/SOLAR-10.7B-v1.0 vom Hugging Face Hub vermutet
  • Die Predibase-Inferenz mit Qwen2 funktionierte nicht und wurde daher aus dieser Evaluation ausgeschlossen
  • Der finale Vorhersage-Datensatz wurde als öffentlicher Datensatz auf dem Hugging Face Hub veröffentlicht

JSON-Gültigkeit und fehlende Werte

  • Die erste Evaluation prüfte, ob die Ausgabe jedes Modells gültiges JSON war
  • Die OpenAI-Modelle erzeugten jedes Mal gültiges JSON
  • Auch die finegetunten Mistral- und Llama3-Modelle lieferten stabil gültiges JSON
  • Bei TinyLlama unterschieden sich die Ergebnisse je nach gewähltem Template stark
    • tinyllama-sharegpt hatte 38 fehlende Werte
    • Ohne fehlende Werte hätte es vermutlich alle 724 Vorhersagen und gültiges JSON vollständig geliefert
  • Die Zählung fehlender Werte sah wie folgt aus
    • gpt-4o: 0
    • gpt-4-turbo: 0
    • gpt-3.5-turbo: 0
    • tinyllama-templatefree: 0
    • tinyllama-sharegpt: 38
    • finetuned-openai-gpt-3.5-turbo-1106: 0
    • finetuned-llama3-7b-32k-openpipe: 0
    • mistral-lora-templatefree: 0
    • finetuned-mistral-7b-optimised-openpipe: 0
    • ft-solar-1-mini-chat-240612-predibase: 0

Genauigkeit nach Feld

  • Die Genauigkeit wurde anhand von insgesamt 13 Attributen bewertet
    • start_date
    • province
    • target_group
    • event_type
    • min_killed
    • min_captured
    • killq
    • captureq
    • killcaptureraid
    • airstrike
    • noshotsfired
    • min_leaders_killed
    • min_leaders_captured
  • Die Gesamtzahl der Aufgaben in allen Charts beträgt 724

  • start_date

    • Bei der Genauigkeit von start_date schnitten Solar und das finegetunte GPT-3.5-Modell am besten ab
    • Die Scores waren:
      • gpt-4o: 527
      • gpt-4-turbo: 522
      • gpt-3.5-turbo: 492
      • tinyllama-templatefree: 231
      • tinyllama-sharegpt: 479
      • finetuned-openai-gpt-3.5-turbo-1106: 646
      • finetuned-llama3-7b-32k-openpipe: 585
      • mistral-lora-templatefree: 0
      • finetuned-mistral-7b-optimised-openpipe: 636
      • ft-solar-1-mini-chat-240612-predibase: 649
    • Selbst das beste Modell lag bei 75 Datumsangaben falsch, sodass die Datumsextraktion weiterhin Verbesserungspotenzial hat

  • province

    • Bei der Vorhersage der Provinz (province) lagen die Fine-Tuning-Modelle vor den OpenAI-Modellen
    • Die Scores waren:
      • gpt-4o: 649
      • gpt-4-turbo: 645
      • gpt-3.5-turbo: 595
      • tinyllama-templatefree: 335
      • tinyllama-sharegpt: 660
      • finetuned-openai-gpt-3.5-turbo-1106: 704
      • finetuned-llama3-7b-32k-openpipe: 707
      • mistral-lora-templatefree: 0
      • finetuned-mistral-7b-optimised-openpipe: 711
      • ft-solar-1-mini-chat-240612-predibase: 704

  • target_group und event_type

    • Da es mehrere target_group-Gruppen geben kann, wurde der Score als Anteil der korrekten Gruppen berechnet, die das Modell erkannt hat
    • Die Fine-Tuning-Modelle schnitten bei der Identifikation von Zielgruppen deutlich besser ab als die OpenAI-Modelle
    • Werden jedoch neue Gruppen hinzugefügt, die nicht in den Trainingsdaten vorkamen, kann die Leistung sinken
    • event_type gilt als auch für menschliche Annotatoren schwieriges Feld, da sich Kategorien semantisch überschneiden
    • Auch bei diesem schwierigen Feld erzielten die Fine-Tuning-Modelle gute Ergebnisse

  • Zahlen- und Boolean-Felder

    • Bei Zahlenschätzungen wie min_killed verringerte sich der Abstand zwischen Fine-Tuning-Modellen und OpenAI-Modellen
    • Mistral lag am höchsten, der Unterschied war aber nicht groß, und auch die OpenAI-Modelle schnitten bei diesem Feld gut ab
    • Wahrscheinlich halfen die im langen Prompt enthaltenen Regeln zur Annotation von Zahlen
    • Bei Boolean-Attributen wie killq erreichten die meisten Modelle eine hohe Genauigkeit
    • Das finegetunte Mistral übertraf auch hier den Bestwert von GPT-4o
    • killcaptureraid erwies sich als Feld, bei dem OpenAI-Modelle im Nachteil waren
      • kill-capture raid war ein Fachbegriff, der im Labeling auf eine bestimmte Weise verwendet wurde
      • Die OpenAI-Modelle kannten die Entscheidungsregeln für dieses Labeling nicht
    • noshotsfired ist ein Feld, das daraus entstand, dass Pressemitteilungen eines bestimmten Zeitraums betonten, dass „keine Schüsse gefallen“ waren
    • Die OpenAI-Modelle schnitten in umgekehrter Reihenfolge der Erwartungen ab; um die Ursache zu verstehen, wären weitere Untersuchungen nötig
    • Bei min_leaders_killed und min_leaders_captured waren die Scores insgesamt hoch
    • Entgegen der verbreiteten Annahme, dass LLMs bei Zahlen schwach sind, zeigte diese Aufgabe eine hohe Leistung; dennoch erzielten die Fine-Tuning-Modelle die besten Ergebnisse

Endergebnis der Aggregation

  • Die 13 einzelnen Genauigkeitsscores wurden summiert und anschließend gemittelt, um eine finale aggregierte Genauigkeit auf einer Skala von 0 bis 100 zu berechnen
  • Im Endergebnis übertrafen die Fine-Tuning-Modelle die OpenAI-GPT-Modellfamilie
  • Auch TinyLlama zeigte eine höhere aggregierte Genauigkeit als GPT-3.5 Turbo
  • Das leistungsstärkste Modell war das mit OpenPipe finegetunte Mistral-7B
  • Solar LLM und Llama3-7B folgten Mistral-7B mit sehr geringem Abstand
  • Für Fine-Tuning zur Extraktion strukturierter Daten erscheint ein Ansatz sinnvoll, mit Mistral-7B, Solar 7B und Llama3-7B zu beginnen und zu vergleichen, welches Modell am besten passt
  • Betrachtet man nur die Genauigkeit, können die drei Modelle nahezu gleichauf liegen
  • Bei Model Serving, Effizienz und Latenz kann es separate Trade-offs geben

Vorteile und Kosten von Fine-Tuning

  • Auch OpenAI-Modelle könnten bessere Ergebnisse erzielen, wenn man mehr Beispiele und Regeln in den Prompt einfügt
  • Längere Prompts erhöhen jedoch die Kosten pro Anfrage
  • Eigene Fine-Tuning-Modelle bieten folgende Vorteile
    • Datenschutz, da vertrauliche Informationen nicht an OpenAI gesendet werden müssen
    • Potenzielle Leistungsverbesserungen durch kleinere Modelle
    • Mehr Kontrolle
    • Potenzielle Kostenvorteile
  • Der Kostenvergleich lässt sich derzeit schwer eindeutig entscheiden
    • Große Cloud-Anbieter können Skaleneffekte nutzen
    • Für reale Anwendungsfälle mit langfristig wiederholter Inferenz kann die Kostenlogik eigener Modelle überzeugender werden
    • Um OpenAI-Aufrufe zu verbessern, müssen viele Beispiele und Erklärungen ergänzt werden, was die Kosten pro Query erhöhen kann

Evaluationsbetrieb und MLOps-Komplexität

  • Fine-Tuning erzielte mit relativ wenigen Anpassungen eine bessere Leistung als GPT-4
    • Die verwendeten Modelle waren die ersten Fine-Tuning-Modelle, die aus den importierten Daten erstellt wurden
    • Meist wurden Standardwerte verwendet
  • Künftig soll der Fokus auf Solar-, Llama3- und Mistral-7B-Modellen liegen
  • Die Evaluation wurde hauptsächlich in Jupyter Notebooks implementiert, und der Betrieb war umständlich
    • Einige Modelle liefen lokal
    • Einige Modelle wurden in unterschiedlichen Services und Umgebungen bereitgestellt
    • Das Iterieren über 724 Zeilen war langsam
  • In der nächsten Iteration sollte die Evaluation lokal ausführbar sein; außerdem sollte zunächst nur ein Datenslice bewertet und anschließend auf den gesamten Datensatz skaliert werden
  • Wenn mehrere Modelle im selben Projekt verwendet werden, braucht es eine standardisierte Inferenzschnittstelle
  • Wenn Modelle über mehrere Orte verteilt sind, Fine-Tuning und Updates wiederholt stattfinden und sich Daten laufend ändern, braucht es ein System, das all das verwaltet
  • Der wichtigste Trade-off finegetunter LLMs besteht darin, dass für einen stabilen und wiederholbaren Betrieb viele Komponenten gemanagt werden müssen

Wert der Evaluation und nächste Schritte

  • Die Umsetzung der Evaluation war umständlich, bot aber einen aufgabenspezifischen Benchmark, mit dem sich prüfen lässt, ob Verbesserungen an Trainingsdaten oder Modellen tatsächlich Fortschritte bringen
  • Ohne Evaluation ist schwer zu beurteilen, ob etwas besser geworden ist
  • Die Idee, mehrere hyperspezialisierte Modelle separat zu erstellen, ist nicht der unmittelbar klare nächste Schritt
    • Beispiel: ein separates Modell, das nur die Zahl gefangener Personen gut schätzt
    • Ausgehend von der aktuellen Modellleistung ist unklar, ob dieser Ansatz die Genauigkeit stark erhöhen würde
  • Der nächste Schritt mit hoher Priorität ist, Evaluationen jenseits der Genauigkeit durchzuführen
    • Ein Beispiel ist die im früheren Beitrag erwähnte Evaluation mit Out-of-Domain-Daten
    • Es soll geprüft werden, wie sich die Modelle bei Fake-Daten zu völlig anderen Themen verhalten
  • Ein weiterer nächster Schritt ist, das LLM Serving der Top-3-Modelle genauer zu untersuchen
    • LLM Serving hat andere Werkzeuge, Trade-offs und Techniken als Serving von Nicht-LLM-Modellen
  • Wenn man tiefer in das Problem einsteigt, kann es nützlich sein, Fehlfälle in eine Weboberfläche wie Lilac oder Argilla zu laden und Fehlermuster zu analysieren
  • Das Verstehen von Fehlerszenarien dürfte für Genauigkeitsverbesserungen hilfreicher sein als das Anpassen von Fine-Tuning-Parametern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-02
Meinungen auf Hacker News

  • Aus Sicht des OpenPipe-Gründers ist es nicht überraschend, dass dabei gute Ergebnisse herauskommen, denn Datenextraktion ist ein Anwendungsfall, in dem Fine-Tuning-Modelle besonders gut sind.
    Wenn man starke Trainingsdaten erstellen kann, war es bei mehreren Aufgabentypen ziemlich einfach, GPT-4 zu schlagen; auch in einer vor einer Woche veröffentlichten Studie lag ein feinabgestimmtes Llama 3 8B bei 3 von 4 Beispielaufgaben – kreative Zusammenfassung, Fragebeantwortung, Datenextraktion und Klassifizierung – vor GPT-4.
    Der Kern bestand darin, eine Methode zur iterativen Erzeugung hochwertiger Trainingsdaten zu entwickeln; darauf geht auch der Artikel ein: https://openpipe.ai/blog/mixture-of-agents

    • Ich frage mich, ob auch technisch interessierte Nicht-Experten das leicht feinabstimmen und ausführen können.
      Der Anwendungsfall wäre, technische Dokumentation, bestimmte Nachrichten, zwei Jahre Blogbeiträge, Primärquellen und erklärende Twitter-Threads zu trainieren, um ein Themenexperten-LLM zu bauen, das Nischeninformationen zu einem Thema aus den letzten zwei Jahren sammelt.
    • Ich frage mich, ob man mit einem LLM ein Metamodell bauen könnte, das je nach Frage eines von mehreren feinabgestimmten Modellen auswählt, und damit insgesamt bessere Ergebnisse als GPT-4 erzielt.
    • Ich frage mich, ob es gegen die Nutzungsbedingungen verstößt, neue Modelle mit den Antworten von Modellen großer LLM-Anbieter wie OpenAI, Anthropic usw. zu trainieren.

  • Dieses Ergebnis ist überhaupt nicht überraschend und passt zu früheren Resultaten, wonach bei Information Extraction und Textklassifizierung auch kleine spezialisierte Modelle besser abschneiden.
    In meiner Promotion habe ich feingranulare Ereignis- und Stimmungsextraktion im Stil von ACE gemacht, und „kleine“, spezialisierte feinabgestimmte Transformer waren besser als LLM-Prompting mit Modellen wie BERT oder Roberta-large.
    Es wäre gut, wenn neben modernen Pipelines auch Scores kleiner Modelle enthalten wären; selbst wenn hier ein bekanntes Ergebnis reproduziert wurde, ist es gute Arbeit.

  • Der einzige ernsthafte LLM-Einsatz, der sich in meiner echten Arbeit als nützlich erwiesen hat, war Datenextraktion/Strukturierung.
    Aus Experience-Sampling-Berichten, die ich nicht online teilen konnte, musste ich Beginn, Ende und Beschreibung von Ereignissen extrahieren; mit llama.cpp ließ ich ein Modell laufen und wandelte sie in eine CSV mit vier Spalten um: onset, offset, description und ob bestimmte Bedingungen erfüllt waren.
    Schon ein paar Beispiele der gewünschten Struktur im Prompt reichten aus, damit mehrere Modelle das gut erledigten; Mixtral 8x7b gefiel mir, weil es auf dem Notebook bei vergleichbarer Qualität am schnellsten war.
    Für diese Aufgabe wäre ein feinabgestimmtes kleineres Modell wahrscheinlich besser und schneller, und wenn man die Daten nicht an Anbieter wie OpenAI schicken kann, braucht man Offline-Verarbeitung – hier können kleine, lokal ausführbare und feinabstimmbare Modelle glänzen.

    • Beim Experimentieren mit Web-Datenextraktion mit GPT-3 habe ich das früh erkannt; nachdem ich den ersten Prototyp auf Reddit und HN gepostet hatte, zeigte sich eine große Nachfrage nach Automatisierung für regelbasierte Web-Scraping-Stacks.
      Daraus entstand das Startup https://kadoa.com, das dieses „langweilige und schwierige“ Problem automatisiert, das viel Wartung erfordert und schwer zu skalieren ist.
      Den größten Mehrwert liefert KI bei solchen vergleichsweise weniger glamourösen Anwendungen; sie wird eher repetitive Arbeit wie Web Scraping, Ausfüllen von Formularen und Dateneingabe automatisieren, als Jobs zu vernichten.
    • Als nächsten Schritt würde ich bei Deployment/Inference gern sehen, wie klein man das Modell machen kann.
      Spacy treibt diesen Ansatz mit Modellen im Bereich von einigen Dutzend MB schon lange voran, und es ist erfreulich, dass nun mehr Interesse daran entsteht.
      Idealerweise hätte man viele winzige Modelle, die jeweils stark spezialisiert, klein und schnell in der Inference sind; wenn man sie aber nicht richtig organisiert, wird es irgendwann nicht mehr beherrschbar, sie alle aktuell zu halten.

  • Genau darum geht es beim Fine-Tuning von Modellen.
    Gut ist, dass der Beitrag den Fine-Tuning-Prozess mit einer Mischung aus gehosteten und lokalen Optionen nachvollziehbar zeigt.

    • Ich frage mich, ob es einen guten Service nach dem Muster „Hier ist ein Datensatz; fine-tune diese 9 Modelle und gib mir Bewertungsstatistiken“ gibt.
    • Der Kern ist nicht einfach, dass ein Modell durch Fine-Tuning besser wurde, sondern dass ein viel einfacheres Modell feinabgestimmt wurde und ein deutlich fortgeschritteneres Modell geschlagen hat.

  • Der Artikel ist gut geschrieben und hilfreich.
    Mir ist aufgefallen, dass im GPT-Test des Beispiels temperature=1 verwendet wurde; ich frage mich, ob das bei Aufgaben, die strukturierte Ausgaben erfordern, Best Practice ist.
    Nach meinem groben Verständnis ist temperature 0 für solche Workloads am besten, während eine höhere temperature eher zu kreativeren Aufgaben passt.

    • Die Einstellungen wurden an die Guides der jeweiligen Modelle angepasst.
      Einige LLM-Fine-Tuning-Anbieter gaben tatsächlich temperature 0 vor, und das wurde entsprechend übernommen; andere empfahlen 1.
      Man könnte iterativ experimentieren, um den besten Wert für jedes Modell zu finden, und bei Modellen, auf die man sich in späteren Iterationen oder beim Fine-Tuning konzentriert, wäre das einen Versuch wert.

  • Ich würde gern ein Beispiel sehen, bei dem GPT-4o falsch lag, das leistungsstärkste Modell aber richtig.
    Außerdem wäre es aus meiner Erfahrung mit viel strukturierter Datenextraktion sinnvoll, es noch einmal mit temperature 0 zu versuchen; meiner Erfahrung nach sollte man immer 0 verwenden, und der Unterschied kann sehr groß sein.
    Temperature 1 bedeutet im Grunde, dass auch Tokens ausgewählt werden, die mit geringerer Wahrscheinlichkeit korrekt sind.

    • Für diesen Anwendungsfall mit klaren Richtig/Falsch-Antworten auf Basis historischer Daten wäre ein Vergleich mit temperature 0 interessant.
      Als ich in einem AI-SQL-Editor mit der temperature experimentierte, war 0.3 ideal: Je näher an 0, desto stärker ist es auf Genauigkeit optimiert, aber wenn ein Fehler auftritt, wird Selbstkorrektur schwieriger.

  • Ich habe zu einem ähnlichen Thema ein Paper geschrieben: https://www.nature.com/articles/s41467-024-45563-x

  • Ich frage mich, ob potenziell kontroverse Inhalte der betreffenden Nachrichtenartikel die Zusammenfassungsfähigkeit von ChatGPT beeinflussen können.

    • Wir nutzen LLM-Informationsextraktion über OpenAI Azure für Finanznachrichten, und das ist ein großes Problem.
      Schon allein bei Texten aus Finanznachrichten erhalten wir bei 4 % der Artikel 404-Antworten der Content Moderation, was ein Hauptgrund ist, offene Modelle zu prüfen.
    • Das glaube ich eher nicht.
      Normalerweise kommt bei solchen Fehlern gar keine Ausgabe zurück, während der Artikel zeigt, dass für alle 724 Testfälle eine gültige JSON-Ausgabe auf die Queries erhalten wurde.
      Solche Themen dürften in den Trainingsdaten gut vertreten sein, und Open-Source-Modelle werden ähnliche Daten verwendet haben; daher dürfte die Lücke zwischen proprietären und Open-Source-Modellen nicht groß sein.

  • Auf die Gefahr hin, wie ein alter Mensch zu klingen: Oberste Priorität sollte sein, alle Modelle so frei und Open Source wie möglich zu veröffentlichen, damit alle sie fine-tunen können.
    Das ist ein Spezialfall der Ansicht, dass Free/Open Source meist sowohl bei Freiheit als auch bei Qualität besser ist.

    • Das klingt, als würde am Ende derjenige das beste Produkt bauen, der die meisten persönlichen Daten gesammelt hat und Eigentumsrechte daran beansprucht.
      Es ist ähnlich wie früher, als man personalisierte Werbung gut fand, weil sie „relevanter“ war; jetzt gilt das nicht nur für Werbung, sondern auch für nützliche Produkte.
      Plattformbesitzer wie Apple oder Microsoft können Daten aus Apps und Produkten abgreifen, sogar lokal, und bekommen dadurch einen viel größeren Vorteil, als bei der Modellqualität 3–6 Monate vorn zu liegen.
      Ich mag die Zentralisierung dieser Technologie nicht, aber auch wenn es hoffnungsvoll stimmt, dass kleine feinabgestimmte Modelle besser sind, werden Offenheit und Privatsphäre allein damit schwer oder fast gar keine Chance haben.
      Das Beste wäre eine Verbreitung, bei der offene Modelle im Servicebereich kleiner und mittlerer Unternehmen zur Standardware werden und effektiv genug sind, sodass OpenAI-Tokenkosten nicht nötig sind.
      Das war vermutlich Zucks Plan und könnte die Absicht gewesen sein, bei einer Technologie, die vor allem Wettbewerbern zugutekommt, zentrale Gatekeeper zu verhindern.
      Trotzdem: Der Feind meines Feindes ist mein Freund, und vielleicht ist sein Vorgehen das Beste, was er je für das Gemeinwohl getan hat.

  • Bei Predibase haben wir kürzlich über 700 Fine-Tuning-Experimente durchgeführt, um die Leistung beliebter Open-Source-LLMs bei 30 Aufgaben zu benchmarken und mit GPT-4 zu vergleichen.
    In 85 % der Fälle haben sie GPT-4 geschlagen; die Ergebnisse gibt es hier: https://predibase.com/fine-tuning-index
    Die Website enthält interaktive Diagramme und einen Link zum Arxiv-Paper.