Muse Spark 1.1 vorgestellt

 (ai.meta.com)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Muse Spark 1.1, vorgestellt von Meta Superintelligence Labs, ist ein multimodales Reasoning-Modell für Agentenaufgaben und verbessert Tool- und Computernutzung, Coding sowie multimodales Verständnis gegenüber dem Vorgänger
  • Ein Kernelement ist die Planung und Orchestrierung über externe Apps und Services hinweg sowie die Zero-Shot-Generalisierung auf native tools, MCP servers und custom skills
  • Das Modell verwaltet ein Kontextfenster von 1 Million Token aktiv, ruft Informationen aus früheren Aufgaben ab und komprimiert den entscheidenden Kontext für spätere Schritte
  • Entwickler können über die öffentliche Preview der Meta Model API auf das Modell zugreifen; in der Meta-AI-App und auf meta.ai ist es im Modus „Thinking“ nutzbar
  • Meta führte vor der Bereitstellung Sicherheitsbewertungen nach dem Advanced AI Scaling Framework durch und stuft das Modell in den Kategorien Chemical & Biological, Cybersecurity und Loss of Control als innerhalb der Sicherheitsmargen ein

Einordnung und Bereitstellung von Muse Spark 1.1

  • Muse Spark 1.1 ist das neueste Modell von Meta Superintelligence Labs und wird als zentrales Upgrade gegenüber dem bisherigen Muse Spark vorgestellt
  • Es ist ein multimodales Reasoning-Modell für Agentenaufgaben und hebt Verbesserungen in den folgenden Bereichen hervor
    • Tool-Nutzung
    • Computernutzung
    • Coding
    • multimodales Verständnis
  • Die Veröffentlichung wird zusammen mit der Vorstellung von Muse Image als weiterer Schritt in Richtung von Metas Vision einer „personal superintelligence“ eingeordnet
  • Entwickler können über die öffentliche Preview der Meta Model API auf Muse Spark 1.1 zugreifen
  • In der Meta-AI-App und auf meta.ai wird es im Modus „Thinking“ angeboten

Agentenaufgaben und Verarbeitung langer Kontexte

  • Das Modell plant und orchestriert Ausführungsabläufe für persönliche Agentenaufgaben über mehrere externe Apps und Services hinweg
  • Es generalisiert Zero-Shot auf native tools, MCP servers und custom skills
  • Es wurde darauf trainiert, komplexe Projekte deutlich schneller als Muse Spark zu bearbeiten
    • Der Hauptagent sammelt Kontext und erstellt einen Plan, bevor er die Ausführung an parallele Subagenten delegiert
    • Die Subagenten folgen ihren Aufgaben, verstehen die verfügbaren Tools und eskalieren bei Bedarf an den Hauptagenten
  • Es verwaltet ein Kontextfenster von 1 Million Token aktiv
    • Es merkt sich ausgeführte Aktionen
    • Es ruft Informationen aus deutlich früheren Aufgaben ab
    • Es komprimiert Inhalte so, dass die entscheidenden Schritte für spätere Aufgaben erhalten bleiben

Automatisierung der Computernutzung

  • Muse Spark 1.1 zeigt besondere Stärken bei Computer-Use-Workflows, die zwischen mehreren Anwendungen wechseln und in denen sich Informationen in Echtzeit verändern
  • Es hält den Kontext auch in langen Sitzungen aufrecht, passt sich veränderten Anforderungen an und navigiert mit minimalem menschlichem Eingriff durch unbekannte Interfaces
  • Desktop-Aufgaben werden nicht immer nur auf Klick-Ebene ausgeführt; je nach Situation wählt das Modell zwischen Automatisierung und direkter Bedienung
    • Wenn Automatisierung schneller ist, schreibt es Skripte
    • Wenn direkte Interaktion einfacher ist, nutzt es Klicks
    • Es erzeugt in jedem Schritt gebündelte Aktionen
  • Im Beispiel zur Vorbereitung einer Dinnerparty erkennt das Modell neuen Kontext während des Bestellprozesses und führt die nötigen Updates ohne Eingriff des Nutzers aus

Coding-Leistung und Entwickler-Workflows

  • Die Leistung von Muse Spark 1.1 verbessert sich deutlich bei praxisnahen Coding-Aufgaben mit großen und komplexen Codebases
  • Es kann komplexe Bugs diagnostizieren und beheben, neue Funktionen in Enterprise-Systemen implementieren und groß angelegte Code-Migrationen durchführen
  • Bei Anwendungsfällen wie der Erstellung von Webanwendungen und End-to-End-Fragebeantwortung zeigt es große Fortschritte gegenüber dem ersten Modell
  • Es wurde darauf trainiert, sich nahtlos an verschiedene Harnesses anzupassen und komplexe Multi-Turn-Abläufe stabil zu verarbeiten
    • planning mode
    • goal conditioning
    • subagent delegation
    • allgemeine Agenten-Coding-Funktionen wie context compaction werden unterstützt
  • In der OpenCode-Debugging-Demo erstellt es eine Chat-Web-App, findet über automatische Screenshots für Nutzer sichtbare Fehler, verfolgt diese bis zum relevanten Code zurück, behebt sie und verifiziert anschließend die Änderungen
  • Meta-interne Entwickler und Forscher nutzen Muse Spark 1.1 bereits täglich; im Meta Internal Coding Bench zeigt es deutliche Verbesserungen gegenüber Muse Spark und wettbewerbsfähige Ergebnisse im Vergleich zu wichtigen Alternativen
  • Forscher setzen Muse Spark 1.1 auch in ihren Workflows ein, um Modellentwicklungs- und Evaluationsaufgaben zu automatisieren
  • Im DeepSWE-Evaluationsbeispiel bewertet das Modell innerhalb von OpenCode eigenständig Teile von DeepSWE bei unterschiedlichen Reasoning-Intensitäten und erstellt ein Analyse-Dashboard auf Basis der Ergebnisse

Multimodales Verständnis und Ausführung

  • Muse Spark 1.1 zeigt auch Stärken bei Aufgaben, die Wahrnehmung, multimodales Reasoning und Tool-Nutzung kombinieren
  • Es kann bei Interaktionen mit realen Umgebungen fundierte Ergebnisse erzeugen
    • Code-Artefakte aus visuellen Materialien erzeugen
    • sehr detaillierte Bild- und Video-Captions erstellen
    • Agenten-Workflows für multimodale Use Cases ausführen
  • Die multimodalen Fähigkeiten sind besonders nützlich in Situationen, in denen Wahrnehmung und Handlung zusammenkommen
    • Es prüft visuelle und akustische Informationen
    • Es bewahrt Details über lange Workflows hinweg
    • Es nutzt diese Details, wenn es Computer im Auftrag des Nutzers bedient
  • Im Beispiel eines Facebook-Marketplace-Agenten extrahiert es nützliche Fotos aus einem mit dem Smartphone aufgenommenen Video, erkennt das Produkt und erstellt anschließend durch Bedienung des Browsers des Nutzers ein Marketplace-Inserat

Sicherheitsbewertung

  • Meta führte vor der Bereitstellung umfangreiche Sicherheitsbewertungen nach dem Advanced AI Scaling Framework durch
  • Dieses Framework definiert Evaluierungen, Bedrohungsmodelle und Bereitstellungskriterien für Metas fortschrittlichste Modelle
  • Zu den Bewertungsbereichen gehören die folgenden frontier risks
    • Chemical & Biological
    • Cybersecurity
    • Loss of Control
  • Laut Metas Bewertung arbeitet Muse Spark 1.1 in allen frontier-risk-Kategorien innerhalb der Sicherheitsmargen
  • Es zeigt starke Widerstandsfähigkeit gegen direkte Jailbreaks, indirekte Angriffe aus nicht vertrauenswürdigen Daten, Prompt Injection und Angriffe auf Developer Prompts
  • Dadurch verbessern sich die adversarial robustness, während die Raten von Halluzinationen und Sycophancy sinken
  • Die vollständigen sicherheitsbezogenen Inhalte sind im Muse Spark 1.1 Evaluation Report dokumentiert

Reaktionen früher Partner und weitere Pläne

  • Über die öffentliche Preview der Meta Model API können Entwickler erstmals mit Builds auf Basis von Muse Spark 1.1 starten
  • Frühe Partner bewerten es als Foundation Model, das lange Kontexte, Coding und Reasoning kombiniert, um Agenten-Workloads im großen Maßstab zu verarbeiten
  • Replit-CEO Amjad Masad betont, dass ein Modell hier ein Kontextfenster von 1 Million Token, multimodale Unterstützung für Bilder, Videos und PDFs, integrierte Suche mit Zitaten, strukturierte Ausgaben, parallele Tool-Aufrufe und ein OpenAI-kompatibles Paket zusammenbringt
  • Cline-CEO Saoud Rizwan sagt, man habe Cline-Entwicklern frühzeitigen Zugang geben wollen, weil das Modell starke Tool-Nutzung mit einem Preisniveau kombiniert, das echte Coding-Workloads in großem Umfang ermöglicht
  • Yashodha Bhavnani von Box bewertet Muse Spark im Enterprise-Task-Evaluationssatz von Box als Modell mit wettbewerbsfähigen Enterprise-Fähigkeiten im Vergleich zu führenden frontier models
  • Dave Morin von der OpenClaw Foundation beschreibt Muse Spark 1.1 als schnelles und leistungsstarkes Modell für Agenten-Ausführung
  • Meta trainiert nach eigenen Angaben bereits leistungsfähigere Modelle und will diese künftig vorstellen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • Im verlinkten Bericht stehen deutlich mehr Details: https://ai.meta.com/static-resource/muse-spark-1-1-evaluatio...
    In den Details zu Terminal-Bench-2.1 heißt es: „Wir haben 89 Aufgaben aus dem offiziellen Terminal-Bench-2.1-Repository mit einem Agent-Harness bewertet, der ausschließlich das bash-Tool nutzt; die Ressourcen waren auf 6 CPU-Kerne und 8 GB RAM begrenzt.“ Damit ist das Ergebnis disqualifiziert.
    Jede Terminal-Bench-Aufgabe hat eigene Obergrenzen für CPU und RAM, und wenn eine davon überschritten wird, ist sie disqualifiziert. Nach tbench-2.1 erlauben von den 89 Aufgaben 0 Aufgaben 6 CPU-Kerne, und nur 8 Aufgaben erlauben 8 GB RAM.
    Solch fragwürdiges Benchmarking nimmt einem völlig den Spaß daran, Harnesses zu bauen, um die Benchmark-Performance eines Modells zu verbessern. Denn egal, was man tut, man kann die ungenauen Zahlen in der Headline nicht schlagen. Vermutlich ist dieses Modell deshalb auch nicht im offiziellen Leaderboard https://www.tbench.ai/leaderboard/terminal-bench/2.1 zu finden.
    Als ehemaliger Meta-Mitarbeiter finde ich das etwas bitter, aber nicht besonders überraschend. Bis die PSC vorbei war und man zum Nächsten überging, war Zahlen hochtreiben die zentrale Kennzahl für die Leistungsbewertung.

    • Abgesehen von Fällen, in denen ein Modell versehentlich eine Fork-Bombe auslöst, verstehe ich nicht, warum man Ressourcenlimits berücksichtigen sollte. Ich dachte, dieser Benchmark misst Terminal-Nutzung, insbesondere die Fähigkeit, viele bash-Tool-Aufrufe aneinanderzureihen. In welchen Testfällen wird das wichtig?
    • Genau das ist das Problem bei geschlossenen Modellen. Wir wissen nicht genau, ob wir für ein besseres Basismodell bezahlen oder für ein gut designtes Harness, das Benchmark-Scores maximiert.
    • Aus reiner Neugier: Wie oft werden Ressourcenlimits zum Flaschenhals? Wobei hilft das Harness hier? Begrenzt es Parallelität oder nutzt es effizientere Tools?
    • Ich verstehe den Punkt, bin aber nicht sicher, ob er wirklich so wichtig ist.
      Haben harbor / tb2.1 den Swap begrenzt, den Docker-Ausführungen nutzen können? Früher gab es einen Bug, bei dem Docker-Instanzen mehr Speicher nutzen konnten als in der Spezifikation angegeben. Einige der ursprünglichen Aufgaben waren praktisch nicht abschließbar, wenn man keinen Swap nutzte; wenn man Docker den Zugriff auf Swap verwehrte, bestanden nicht einmal die Oracle-Lösungen.
      Soweit ich mich erinnere, hatten crack-7z-hash und filter-js-from-html dieses Problem, aber ich habe seit Monaten nicht mehr nachgesehen, bin also nicht sicher.
    • Das wirkt nicht wie ein so großes Problem. Wenn ich irgendein Produkt bewerte, nehme ich auch nicht einfach die Aussagen des Herstellers für bare Münze. Natürlich gibt es da Bias. Genau deshalb gibt es unabhängige Tests wie https://artificialanalysis.ai.

  • Ich konnte es ein paar Tage vorab ausprobieren und in der Zeit ein Plugin für LLM bauen. Im Terminal kann man das Modell so testen:
    uv tool install llm
    llm install llm-meta-ai
    llm keys set meta-ai
    # paste API key here
    llm -m meta-ai/muse-spark-1.1 "Generate an SVG of a pelican riding a bicycle"
    Das Ergebnis ist hier: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...
    Zum Vergleich: Der Pelikan aus Muse Spark 1 ist hier: https://simonwillison.net/2026/Apr/8/muse-spark/

    • Ich frage mich, wie du die Zeit findest, so viele Modelle vorab auszuprobieren. In letzter Zeit gab es wirklich einen wilden Strom an Modell-Releases; fühlt sich das manchmal nicht wie Arbeit an?

  • Vielleicht sollte Zuck sich stärker darauf konzentrieren, im Modellmarkt die Rolle des Spoilers zu spielen, statt frontal zu konkurrieren.
    Er muss die Modellumsätze von Anthropic oder OpenAI nicht einholen; es reicht, wenn er diese Umsätze um 99 % drücken kann. Er kann weiter Milliarden von Dollar in die Entwicklung von Frontier-Modellen stecken und sie mit offenen Gewichten veröffentlichen, sodass Coding-Modelle zur Commodity werden. Dazu braucht es auch ein gut gemachtes Open-Source-Benchmark-Harness.
    Es gibt kaum jemanden, der in der Position ist, das zu tun, und für den es auch geschäftlich Sinn ergibt. Der Trend dürfte ohnehin in diese Richtung gehen, und er könnte ihn stark beschleunigen. Wie Compiler sollten auch Modelle hoffentlich von proprietären Produkten zu Commodities werden.
    Das könnte eines der besten Dinge sein, die Zuck für die Welt tun kann.

    • Wenn sie Umsätze verlieren, wer wird dann Metas Rechenressourcen mieten?
    • Um wirklich der König der Spoiler zu werden, müsste man den Trainingsdatensatz als Open Source veröffentlichen. Ich bezweifle, dass sie so weit gehen.
    • Coding-Modelle sind nicht das Ziel. Coding-Modelle sind nur Teil des Bootstrapping-Prozesses hin zu allgemeiner Intelligenz.
    • Haben sie das mit llama nicht schon versucht?
    • Alles, was er tun muss, ist zu beweisen, dass es nicht mehr so schwierig ist, solche Modelle zu bauen. Denn der Burggraben dieser Unternehmen ist die Wahrnehmung, dass der Aufbau von Frontier-Modellen wirklich schwierig ist.

  • Der Preis ist absurd gut: $1,25 Input und $4,50 Output pro 1 Mio. Tokens, und gecachter Input kostet $0,15.
    https://dev.meta.ai/docs/getting-started/pricing-rate-limits

    • Am direktesten lässt sich das mit xAI Grok 4.5 vergleichen. Beide gehen grob in Richtung „Intelligenz auf Opus-Niveau zum Haiku-Preis“, und für Anwendungsentwickler, die so ein Modell in Apps einbauen wollen, ist das eine große Sache.
      Ich war gerade dabei, Tests zu machen, bei denen Haiku und Sonnet durch Grok 4.5 ersetzt werden; das hier will ich ebenfalls ausprobieren. Vor allem der Cache-Preis ist deutlich günstiger.
    • Das Preisverhältnis für gecachten Input ist gut.
      Grok 4.5 kam mit $2/$6 heraus, verlangt aber still und leise $0,50 pro 1 Mio. gecachter Input-Tokens. Das ist so teuer wie Opus 4.8.
    • Meta ist derzeit bei den meisten Leuten, die Modelle auswählen, nicht auf dem Radar. Wenn man ein wirklich gutes Modell hat, ergibt es Sinn, Nutzer mit Subventionen zu gewinnen, bevor man die Preise an die Konkurrenz anpasst.
    • Günstiger als Qwen 3.7 Max. Nach den $2 Input / $6 Output von Grok 4.5 ist das das zweite Signal, dass die großen Labs den Druck durch GLM 5.2 spüren.
    • Trotzdem immer noch lächerlich teuer. Wenn man sich vorstellt, $10 für 100 Google-Suchergebnisse zu zahlen, ist es im Grunde genau das.
      Ich verstehe wirklich nicht, warum jemand mehr als $1,50 pro 1 Mio. Output-Tokens ausgeben will, ganz zu schweigen von $15–50. Gibt es überhaupt Fälle, in denen Verbraucher tatsächlich nutzungsbasierte Gebühren zahlen?

  • Bis gestern schien die Stimmung stark davon geprägt, dass OpenAI und Anthropic uneinholbar vorne liegen. Jetzt haben xAI und Meta zumindest Modelle herausgebracht, die mit praktischen Modellen konkurrieren können, und das auch noch günstig.
    Natürlich bleibt die Aussage, dass die beiden führenden Labs vorne liegen, mit Blick auf Fable und wohl auch das bald kommende GPT-6 weiterhin bestehen, aber es ist kein komplett entschiedenes Spiel, wie es die meinungsführenden Leute dargestellt haben.

    • Modelle sind inzwischen im Großen und Ganzen gut genug. Wenn es keinen großen Durchbruch gibt, zählt ab jetzt vor allem Kosten.
    • Die Leute haben Googles Zurückfallen fälschlicherweise so interpretiert, als wären Anthropic und OpenAI extrem weit voraus. In Wirklichkeit ist es eher so, dass Google zurückgefallen ist wie damals bei Tensorflow, Angular und GCP.
    • Die Nuance ist etwas anders.
      Die Erwartungen an GLM 5.2 waren schon vorher hoch. xAI oder Meta haben nicht auf eine ganz andere Weise einen großen Unterschied gemacht, sondern liegen eher bei ähnlichen Ergebnissen und ähnlichen Preisen wie GLM 5.2.

  • Persönlich mag ich Meta nicht besonders, aber das erkenne ich an. Je mehr Wettbewerb, desto besser für normale Verbraucher und auch für Unternehmen.
    Dass chinesische Modelle, Grok, Meta, Google, OpenAI und Anthropic alle konkurrieren, sehe ich als Gewinn. Solange man diese subventionierten Tokens nutzen kann, baue ich wie verrückt, um das maximal auszunutzen.

    • Metas lokale llama-Modelle waren einmal das Gesicht von Open-Source-KI. Das Feld hat sich wirklich stark verändert.
    • Ich halte das eindeutig für etwas Gutes. Allerdings bin ich innerlich noch uneins, ob diese Fortschritte die Zahl der im KI-Zeitalter benötigten Software Engineers erhöhen oder senken werden.
      Einerseits wird es einfacher, Produkte zu bauen, sodass mehr Menschen Dinge bauen und mehr Produkte und Funktionen entstehen. Auch viele Nicht-Techniker werden bauen wollen, dann aber stecken bleiben, sodass am Ende Engineers gebraucht werden. Die Gesamtmenge an Produkten, die erfahrene Tech-Unternehmen sowie nichttechnische Gründer und angehende Gründer hervorbringen werden, wird enorm sein. Darin liegt das Aufwärtsszenario, dass in naher Zukunft mehr Software Engineers benötigt werden.
      Andererseits werden die Leute in etwa einem Jahr massenhaft solche Produkte bauen, aber die meisten werden sie nicht vermarkten, verkaufen oder monetarisieren können. Am Ende braucht man vielleicht doch nicht so viele Software Engineers. Insgesamt halte ich es aber für wahrscheinlich, dass das Aufwärtsszenario netto überwiegt.
    • Wenn man die chinesischen Modelle genauer aufschlüsselt, sind da DeepSeek, GLM (Z.ai), Minimax, Kimi (Moonshot), Hy3 (Tencent) und Qwen (Alibaba).
      Bei jedem davon kann man die Gewichte herunterladen und lokal ausführen.
    • Er hat diese Nachricht auf X gepostet, nicht auf seinem Meta Threads. Das zeigt, wie groß sein Interesse daran ist, das Thema groß zu machen. Natürlich können die Kosten für uns auf einem tragbaren Niveau bleiben, solange diese Firmen weiter Geld verbrennen.
    • Das ist der größte Technologiewettbewerb, den ich bisher gesehen habe. Die reichsten Unternehmen, die klügsten Leute und die reichsten Länder sind eingestiegen.
      Ob Wettbewerb gut ist, weiß ich nicht; wir werden es in ein paar Jahren sehen. Ich freue mich schon auf den Tag, an dem ich zum ersten Mal seit Langem wieder einen Job mit körperlicher Arbeit haben werde.

  • Wie kann es sein, dass jedes Unternehmen es schafft, auf jedem Benchmark so auszusehen, als wäre es Nummer eins?

    • Zuerst schaut man, welche Modelle in einem selbst ausgewählten Bündel von Benchmarks schlechter sind.
      Danach vergleicht man mit früheren Versionen der Konkurrenzmodelle. Wenn das immer noch nicht gut aussieht, vergleicht man mit dem eigenen Vorgängermodell.
    • Weil der Graben nicht groß ist, Verbesserungen inkrementell sind und man die Vergleichsmodelle selektiv auswählt.
      Fairerweise wirkt es sinnvoller, mit Modellen ähnlicher Leistung zu vergleichen, wenn die Hauptstärke der Preis ist.
    • Ein Vergleich mit Gemini fühlt sich inzwischen wie ein geschenktes Bingo-Feld an.
    • Was sollte man aus Sicht von Leuten, die sich mit KI gut auskennen, beim Coding als Standard-Benchmark ansehen?
    • Man wartet einfach den exakten Moment ab, in dem das eigene Modell in mindestens N Benchmarks vorne liegt, und kündigt es dann an.

  • Ich hatte verpasst, dass Meta ein Closed-Weight-Modell entwickelt und veröffentlicht hat. Schade. Ich würde mir mehr Fortschritt bei Open-Weight-Modellen aus den USA wünschen.

  • Ich habe es zusammen mit codex in einem Container zum Laufen gebracht. Zur Info: Im Codex:Muse-Interface scheint es einen Bug zu geben, auf den die meisten stoßen dürften.
    Meiner Ansicht nach hat codex keine serverseitigen Tool-Calls erwartet, und durch die Art, wie Meta mit diesen IDs umgeht, entsteht eine Art Parsing- oder Integrationsfehler. Als ich codex die ersten Male mit muse ausgeführt habe, scheiterte es beim ersten Nicht-Websuche-Call.
    Ich habe es behoben, und auch wenn ich persönlich von maßgeschneiderten serverseitigen Tool-Calls und unbegrenzter Dateispeicherung noch nicht ganz überzeugt bin, ist es bisher ein ziemlich tolles Modell, und ich nutze es gerne.
    https://github.com/accretional/awesome-muse-spark/blob/main/...

  • Betrachtet man die veröffentlichten Benchmarks, scheinen Coding und Multimodalität ebenfalls ziemlich gut zu sein, aber die Erfolgsquote bei Tool-Aufrufen wirkt sehr stark.
    Welche Use Cases passen wohl am besten zu dieser Art von Leistungsprofil?

    • Debugging und Diagnose erfordern sehr viele Tool-Aufrufe. Dazu gehört, Logs mit grep zu durchsuchen oder zu transformieren, Profiler oder Tracer aufzurufen und bis hin zum Erstellen von Incident-Reports.
      Bug-Diagnose ist ein Bereich, in dem man zwar in gewissem Maße programmieren, aber vor allem Tools gut einsetzen können muss. Wenn ein guter Diagnosebericht vorliegt, kann man die Behebung an Opus weitergeben.
      Opus schreibt zwar auch einigermaßen Berichte, macht aber in typst-Dokumenten immer noch häufig Fehler bei der Tabellenbreite, sodass in der letzten Spalte der Text vollgestopft ist, die Breite aber nur für ein paar Zeichen reicht.
    • Gemini 3.5 Flash ist bei Tool-Aufrufen besser als Fable. Tool-Aufrufe gehören vermutlich zu den Bereichen, die sich durch Post-Training vergleichsweise leicht verbessern lassen.
    • Ich frage mich, ob wir dieses Muster künftig bei jedem neuen Release sehen werden. Tool-Nutzung dürfte sich schnell verändern, sodass möglicherweise immer das neueste Modell einen Vorteil gegenüber dem intelligentesten Modell hat.
    • Das klingt etwas nutzlos. Es ist interessant, dass die Leistung bei constrained Decodern wie JSON hervorragend ist, aber eine Schleife, bei der man bei einem normalen Decoder durch einen Tool-Validator geht, eine gute Fehlermeldung bekommt und es dann erneut versucht, bringt das Tool fast immer beim zweiten Versuch zum Laufen. Da die Eingabe gecacht wird, ist das auch nicht teuer.