Agentische Programmier-Workflows mit kleinen Modellen

Okay.

Hallo zusammen!

Mein Name ist Jose und ich bin hier mit Ian und Zoe.

Wir alle kennen LLMs.

Wir nutzen sie für alles: Rezepte finden, YouTube-Videos zusammenfassen und programmieren.

Es gibt die wirklich großen LLMs wie die Gemini-Modelle, die zu wirklich unglaublichen Dingen fähig sind. In diesem Vortrag geht es jedoch um Small Language Models.

Sie sind auch LLMs, denn etwas mit 4 Milliarden Parametern kann nicht klein sein. Aber wir werden ab jetzt diese Unterscheidung treffen: Frontier-Modelle und Small Language Models, die Rakete und das Fahrrad.

Wir werden kleine Modelle nicht unbedingt als Alternative zu Frontier-Modellen, sondern hauptsächlich als Ergänzung besprechen.

Wir werden uns alle Vorteile von Small Language Models ansehen, insbesondere wenn sie offen sind, offene Gewichtungen haben und herunterladbar sind. Aber lassen Sie uns zuerst einen Blick auf die Kosten werfen.

Für diesen Vortrag habe ich viele Benchmarks ausgeführt. Einer davon war ein Dataset mit 200 mittelschweren und schwierigen Aufgaben, bei dem fast 131 Millionen Tokens für weniger als 9 $ verwendet wurden.

Ich habe dafür Gemma 4 verwendet. Ich hätte es also einfach herunterladen und kostenlos auf meiner eigenen Hardware ausführen können, habe es aber nur für einen fairen Vergleich auf einem kommerziellen Gateway ausgeführt.

Wie viel würde ein Frontier-Modell also kosten?

Etwa 20- bis 200-mal mehr, je nach Token-Caching und anderen Faktoren.

Das Fahrrad ist also vielleicht nicht das schnellste Transportmittel, aber definitiv das effizienteste.

Ihr neues Smartphone

Die offensichtliche Frage ist nun, was der Unterschied in Bezug auf Qualität und Genauigkeit ist.

In diesem speziellen Datensatz kann Gemma 4 53 % der Aufgaben lösen.

Dies hat zwei Auswirkungen:

Wenn Sie ein Frontier-Modell verwenden, um die Aufgaben auf der linken Seite auszuführen, ist das möglicherweise zu viel des Guten.

Wenn Sie ein kleines Modell verwenden, um die Aufgaben auf der rechten Seite auszuführen, müssen Sie das Modell zu einer Lösung führen oder ein größeres Modell verwenden.

In diesem Vortrag möchten wir Ihnen helfen, mehr aus jedem Token herauszuholen.

Zoe zeigt Ihnen, wie Sie ein kleines Modell auswählen, und Ian spricht über die Gemma-Modelle, damit Sie verstehen, wie Sie sich die Möglichkeiten vorstellen können, die sie bieten.

Dann zeige ich Ihnen kurz, wie Sie Gemma 4 in Android Studio ausprobieren können. Zum Schluss sehen wir uns an, wie Sie kleine Modelle in Ihre täglichen Workflows einbinden können, und zeigen Ihnen echte Android-Entwicklungsbenchmarks, damit Sie ein Gefühl dafür bekommen, was sie leisten können.

Und damit übergebe ich an Zoe.

Vielen Dank, Jose.

Ein Modell für alles zu verwenden, ist also ein bisschen so, als würde man mit Kanonen auf Spatzen schießen, oder?

Das ist zwar effizient, aber etwas unverhältnismäßig.

Kleine Modelle sind also wie eine Erweiterung Ihres Toolsets.

Um zu wissen, was Sie in Ihre Workflows einbringen müssen, müssen Sie das Toolset öffnen, sich ansehen, was verfügbar ist, welche Spezifikationen es hat und wofür es gut ist.

Um kleine Modelle auszuwählen, müssen Sie sie kennen.

Der Typ von Modell, an den die meisten Menschen denken, wenn sie an ein Language Model denken, ist ein autoregressives Language Model.

Das Modell ist autoregressiv, da es basierend auf einer in Tokens aufgeteilten Eingabe das wahrscheinlichste nächste Token aus einer Liste von Kandidaten auswählt.

Das wahrscheinlichste nächste Token, das ausgewählt wurde, wird dann wieder in die Eingabe eingefügt und so weiter. Auf diese Weise können kohärente und intelligent klingende Antworten generiert werden. Es gibt jedoch einige Einschränkungen, einschließlich, aber nicht beschränkt auf, die lineare Arbeitsweise.

Wir können also nichtlinear arbeiten.

Ein Diffusionsmodell verfolgt denselben Ansatz, verarbeitet aber jeweils einen Block von Tokens.

Es ist fast wie eine Skizze, die scharf gestellt wird.

In diesem Fall verarbeitet DiffusionGemma jeweils Blöcke mit 256 Tokens.

Im Grunde erhalten Sie also einen Pass, der für den gesamten Block gilt, und können Ergebnisse mit geringerer Latenz generieren.

Unser Toolset enthält also Modelle, die schreiben können, richtig?

Falsch.

Im Grunde wandeln Einbettungsmodelle Objekte wie Bilder, Text oder andere Konzepte in einen Vektor um.

So erhalten wir eine Zuordnung von Koordinaten in einen hochdimensionalen Raum, die es uns ermöglicht, zwei Dinge konzeptionell zu vergleichen.

Wenn ein Hotdog beispielsweise ein Sandwich ist, werden sie wahrscheinlich nahe beieinander liegen oder in einem engen Raum enden.

Aus diesem Grund ist die Möglichkeit, zu prüfen, ob zwei Konzepte miteinander verwandt sind, sagen wir, ein bisschen Mathematik statt eines Modelldurchlaufs, was wohl auch ein bisschen Mathematik ist, aber dieses Paradigma geht noch weiter, oder?

Und es gibt kleinere und spezialisierte Modelle, die eine Aufgabe wirklich gut erledigen können.

Einige Beispiele: Wir haben Funktionsmodelle, die natürliche Sprache in API-Aufrufe umwandeln, Vision-Modelle, deren Fähigkeiten Sie sicher am Namen erkennen, oder Klassifikatoren, die einer Eingabe basierend auf bestimmten Parametern Bewertungen zuweisen können.

Okay, es gibt also eine große Auswahl, oder?

Es gibt viele verschiedene Arten von Modellen mit unterschiedlichen Dimensionen, Größen, Kontextfenstern, Funktionen und Speicherbedarf. Wenn Sie die Toolbox öffnen und alle Möglichkeiten berücksichtigen, wachsen die Optionen exponentiell, sodass jeder DIY-Fan entweder absolut begeistert oder von der Entscheidungsfindung überfordert wäre.

Wie wählen Sie also ein kleines Modell aus?

Öffnen wir zuerst eine Toolbox mit offenen kleinen Modellen, die lokal ausgeführt werden können: die Gemma-Modelle.

Ich übergebe jetzt an Ian.

Vielen Dank, Zoe.

Wie Jose zu Beginn erwähnt hat, kann ein kleines Sprachmodell etwa 50 % der Aufgaben sofort erledigen.

Aber warum sollten Sie sich für ein lokales Modell entscheiden?

Es kommt also auf etwa vier Dinge an.

Der erste Punkt ist der Datenschutz.

Beispielsweise haben Sie API-Schlüssel, proprietären Code oder Dinge, die Ihren Laptop buchstäblich nicht verlassen dürfen.

Der zweite Punkt ist die Latenz.

Wenn das Modell also in den Speicher geladen wird, entweder in den Grafikspeicher oder den Unified Memory, erhalten Sie eine Antwort, sobald die Berechnung abgeschlossen ist.

Es gibt also keine Umlaufzeiten zu Servern und keine zusätzlichen Latenzkosten.

Als Nächstes kommen die Grenzkosten von null.

Modelle sind also kostengünstig, wenn Sie steuern können, wo sie ausgeführt werden.

Wenn Sie beispielsweise etwas auf einem lokalen Computer ausführen, werden möglicherweise zusätzliche Wiederholungsversuche in einer Fehlerschleife ausgeführt.

Es kostet Sie nichts und es fallen keine unerwarteten API-Kosten für diesen Teil an.

Und schließlich der vierte Punkt: Offlinezugriff.

Stellen Sie sich vor, Sie könnten diese Funktion im Flugzeug, im Zug, im Bus oder in der U-Bahn nutzen – also überall dort, wo das Modell auf Ihrer Hardware ausgeführt wird.

Das klingt gut, aber es gibt zwei wichtige Faktoren, die wir bei diesen Entscheidungen berücksichtigen müssen.

Das eine ist also der Speicher und das andere die Geschwindigkeit.

Wenn Sie sich dieses Diagramm ansehen, sehen Sie, dass die beiden unteren Modelle, 26B und 31B, jeweils über 50 GB Video-RAM benötigen, um in BF16 ausgeführt zu werden, was einer 16-Bit-Quantisierung entspricht.

Die Herausforderung besteht darin, dass diese nicht in viele Hardwaregeräte passen würden.

Wir führen also einen Prozess namens Quantisierung durch, bei dem die Genauigkeit auf einen 4-Bit-Float-Wert reduziert wird.

Jetzt ist es etwas vernünftiger.

Wir sprechen hier von 14 GB und 17 GB, richtig?

Das würde jetzt auf einen Mac mit Unified Memory passen.

Die Herausforderung bei der normalen Quantisierung nach dem Training besteht darin, dass beim Komprimieren dieser Gewichtungen ein Teil der Genauigkeit des Basismodells verloren geht. Wir haben eine Technik, um dem entgegenzuwirken.

Das nennt sich quantisierungsbewusstes Training.

Wenn wir das tun, wird das Modell so trainiert, dass es weiß, dass es auf diese kleineren Größen angewendet wird. Daher ist der Verlust im Vergleich dazu tatsächlich geringer.

So konnten wir die RAM-Anforderungen um 75 % reduzieren, sodass es jetzt auf diese Geräte passt.

Und wir gehen noch einen Schritt weiter.

Die Ansätze zur Quantisierung für Mobilgeräte, die auf vielen Smartphones funktionieren, können diese Modelle noch weiter verkleinern, indem sie die Funktionsweise der verschiedenen Ebenen und die Größen, in denen sie funktionieren können, analysieren.

Wir haben also eine Art gemischte Quantisierung.

Wir reduzieren also die Größe von 11,4 GB für Gemma E2B auf 1,1 GB.

Jetzt ist es also auch auf Smartphones im mittleren bis gehobenen Preissegment viel besser nutzbar.

Der nächste Punkt ist die Geschwindigkeit.

Wenn Sie also ein autoregressives Modell verwenden, sagen Sie, wie Zoe erwähnt hat, die nächste Gruppe von Tokens vorher.

Bei einer Programmieraufgabe sind viele dieser Tokens tatsächlich ziemlich vorhersehbar, z. B. das Ende einer Methodensignatur oder eine öffnende oder schließende Klammer.

Sie können eine Technik namens „spekulative Decodierung“ verwenden.

Dabei wird ein kleineres Drafter-Modell verwendet, um eine Reihe von Tokens vorherzusagen, die dann von einem größeren Modell validiert werden.

Der Grund, warum das in der Gemma 4-Architektur funktioniert, ist, dass sie denselben KV-Cache verwenden.

Sie können sich das wie das Kurzzeitgedächtnis des Modells vorstellen.

Ein kleines Drafter-Modell sagt drei oder vier Tokens im Voraus vorher. Das größere Modell prüft dann denselben KV-Cache und validiert die Ausgabe.

Das kann zu einer etwa dreifachen Leistungssteigerung führen, ohne dass die Qualität der Modellausgabe beeinträchtigt wird, da nur Vorhersagen getroffen und dann entschieden wird, ob sie richtig oder falsch sind.

Es hängt also ein wenig von der Aufgabe ab, die Sie ausführen.

Bei kreativem Schreiben funktioniert das nicht so gut, weil es mehr Variabilität gibt. Bei vorhersehbaren Dingen wie JSON-Strukturen und Programmierung funktioniert es aber sehr gut.

Wie würden Sie eines dieser Modelle bewerten?

Am naheliegendsten ist es, sich einen Benchmark wie LiveCodeBench oder MMLU anzusehen und die Punktzahl zu prüfen.

Das gibt Ihnen aber nur einen groben Überblick über die Fähigkeiten des Modells.

Sie müssen den gesamten Stack bewerten, in dem sie ausgeführt wird.

Das ist also das Modell, das Sie verwenden, die Gewichtungen und der Quantisierungsansatz, die Inferenz der Laufzeit, also etwa llama.cpp, Ollama oder LiteRT, das Agenten-Framework, das Sie verwenden, etwa Pi, OpenCode oder Antigravity, und dann das Kontextfenster, also der Bereich für alle Daten, die Ihr Modell verarbeiten können soll.

Die Kombination all dieser Dinge entscheidet darüber, ob es sich um eine tragfähige Lösung handelt.

Ein kurzes Beispiel: Wir haben Gemma 4 auf Android Bench getestet und eine Ollama-Version mit einem Standardkontext von 32k ausgeführt.

In einem der Tests, bei dem nach einem Fehler gesucht wurde, wurde die Datei durch die Komprimierung des Agenten-Frameworks aus dem Arbeitsspeicher verschoben. Das Modell konnte die Aufgabe dann nicht abschließen und der Test schlug fehl.

Durch die Erhöhung des Kontexts von 32k auf 256k kann das Modell diese Informationen im Speicher behalten und den Test bestehen.

Und wir haben eine Verdoppelung der Erfolgsquote bei diesem speziellen Job gesehen.

Das zeigt, dass selbst einer dieser kleinen Faktoren einen großen Einfluss darauf haben kann, ob dieses Modell geeignet ist oder nicht.

Wie führen Sie also Ihre eigenen Bewertungen durch?

Hier sind drei kurze Vorschläge.

Eine Möglichkeit besteht darin, einen Git-Verlauf zu verwenden, also eine Reihe von erfolgreichen PRs, die Sie bereits haben, und diese als Prompt-Eingaben für das Modell zu verwenden, um zu sehen, wie gut es damit funktioniert.

Als Nächstes benötigen Sie etwas wie einen deterministischen Grader, mit dem Sie bewerten können, ob die Ausgabe des Modells korrekt ist oder nicht.

Wir haben zwei wirklich gute Beispiele dafür.

Wir haben einen Compiler und wir haben Unit-Tests.

Was auch immer generiert wird, Sie können es damit überprüfen und erhalten eine Art Bestanden/Nicht bestanden-Ergebnis, das Ihnen zeigt, ob Sie die jeweilige Aufgabe erfolgreich abgeschlossen haben.

Der dritte Punkt sind Log-Trajektorien.

Wenn Sie einen Agenten ausführen, möchten Sie die verschiedenen Verhaltensweisen des Agenten nachvollziehen und sehen, wo er erfolgreich ist und wo er scheitert. So können Sie bewerten, wie gut das Modell interagieren und Tools verwenden kann.

Ich möchte, dass Sie versuchen, die Frage nicht so zu formulieren: „Ist dieses Modell so intelligent wie dieses große Frontier-Modell?“

bis hin zu „Ist diese Aufgabe auf dieser Hardware mit dieser speziellen Konfiguration möglich?“

Um das herauszufinden, haben wir ein Framework namens „Sind wir schon da?“ entwickelt.

Oder AWTY.

Das Prinzip dieses Frameworks besteht darin, alle diese verschiedenen Aufgaben im Hinblick auf die Bereitschaft auf dieser Achse zu bewerten.

Also das Modell selbst, die verwendete Inferenz-Engine, das Harness und die Hardwarekonfiguration.

So erfahren Sie, ob Sie schon bereit sind.

Sie könnten sich zum Beispiel ansehen, wie zuverlässig die jeweilige Aufgabe ist.

Wenn Sie es zehnmal hintereinander ausführen, macht es dann jedes Mal dasselbe?

Möglicherweise sehen Sie sich die Latenz an.

Vielleicht benötigen Sie eine Antwort in Echtzeit.

Welche Schwellenwerte haben Sie für die Geschwindigkeit, mit der die Aufgabe erledigt wird?

Und dann sehen Sie sich vielleicht die RAM-Anforderungen an.

Es geht also nicht nur um den Arbeitsspeicher, den das Gerät hat, sondern um den Arbeitsspeicher, den das Gerät – den Teil, den Sie nutzen können, und die anderen Anwendungen und Tools, die Sie auch auf dieser Hardware ausführen müssen.

Können Sie also 50 % oder nur 10 % des RAM belegen?

Und du erhältst diesen endgültigen Tagesform-Index.

Wenn es grün ist, ist die Konfiguration bereit.

Wenn es orange, gelb oder rot ist, müssen Sie möglicherweise etwas an der Konfiguration ändern.

Vielleicht benötigen Sie einen schnelleren Beschleuniger für eine geringere Latenz oder ein größeres, leistungsfähigeres Modell.

Ich empfehle Ihnen, sich das anzusehen.

Derzeit ist eine Vorabversion verfügbar und wir würden uns über Ihr Feedback dazu freuen, wie nützlich dieses Tool ist.

Zoe wird später noch genauer darauf eingehen, wie wir einige der Bewertungen einrichten. Jetzt übergebe ich aber an Jose, der Ihnen einen sehr schnellen Einstieg in Gemma 4 zeigen wird.

Danke, Ian.

Der schnellste Weg, Gemma 4 auszuprobieren, ist also wahrscheinlich über Android Studio.

Ich zeige Ihnen, wie das geht.

Wechseln wir bitte zum Laptop.

Genau.

Wenn ich in den Einstellungen die Seite der Modellanbieter aufrufe und Gemma auswähle, sehen Sie, wie groß die einzelnen Modelle sind.

Ich muss die Modelle nur auf meine Festplatte herunterladen.

Dadurch wird ein llama.cpp-Server geöffnet oder gestartet, der von Anfang an korrekt konfiguriert ist.

Sie können aber auch Ihren eigenen llama.cpp-Server, Ollama oder LM Studio verwenden.

Dazu fügen Sie hier einfach einen lokalen Anbieter hinzu.

Außerdem ist es sehr sinnvoll, kleine Modelle über einen Remote-Anbieter zu verwenden.

Sie können hier also einen hinzufügen, solange er mit OpenAI oder Anthropic kompatibel ist.

Okay, mal sehen.

Übrigens: In Android Studio wählen Sie ein Modell über dieses Drop-down-Menü aus.

Ich habe Gemma 4 26B ausgewählt und kann fragen: „Was ist ein ViewModel?“

Okay.

Ein sehr wichtiger Punkt, den Sie beachten sollten, ist, dass bei jedem Modellwechsel die gesamte Unterhaltung noch einmal von vorn an das neue Modell gesendet wird.

Wenn Sie also eine sehr lange Unterhaltung mit einem Modell generieren und zu einem neuen Modell wechseln möchten, sollten Sie wahrscheinlich eine neue Unterhaltung beginnen oder die Unterhaltung komprimieren.

Kommen wir nun zurück zu den Folien und zu Zoe, um mehr über die verschiedenen Workflows zu erfahren, die Sie mit kleinen Modellen ausführen können.

Vielen Dank, Jose, und vielen Dank, Ian, für die Übersicht über die Gemma-Modelle und die Frage, ob wir schon so weit sind.

Wir haben uns also die verschiedenen Modelltypen und ihre Spezifikationen angesehen. Jetzt geht es darum, zu verstehen, welche Arten von Aufgaben sie erledigen können.

Die erste Art von Aufgaben, die Sie wahrscheinlich bereits erledigen, sind Programmierworkflows wie Debugging oder Fehlerbehebung oder etwas, das ich, und ich bin mir sicher, alle anderen auch, sehr sarkastisch vermissen werde, nämlich die Erhöhung der Testabdeckung.

Nicht wahr?

Das sind also einige der Dinge, die wahrscheinlich jeder schon tut, ohne es zu merken.

Ich möchte Sie jedoch ermutigen, darüber hinaus zu denken.

Kleine Modelle können Open-Weight-Modelle sein und lokal ausgeführt werden. Was könnte Ihnen also Zeit sparen?

Nicht wahr?

Wir sprechen darüber, die Rakete nicht zu verwenden. Warum verwenden wir dafür ein Gehirn?

Was können kleine Modelle darüber hinaus leisten?

In welche Workflows könnten Sie sie einbinden, um sich das Leben leichter zu machen und mehr Zeit für Dinge zu haben, die Sie vielleicht lieber tun?

Beispielsweise sollten Sie dafür sorgen, dass Ihre Dokumentation immer auf dem neuesten Stand ist und Ihre Änderungen widerspiegelt. Außerdem sollten Sie automatische Regressionstests einrichten, die Teil eines Pre-Commit-Hooks sind. Sie können auch dafür sorgen, dass der Kontext, den Ihr Agent im Rahmen Ihrer Workflows erhält, optimiert ist, damit er noch schneller arbeitet.

Das sind also einige Beispiele.

Letztendlich sind die Möglichkeiten unbegrenzt, oder die Architektur ist die Grenze, und es gibt viele Dinge, die Sie sich vorstellen können, wie Sie sie implementieren könnten.

Aber auch wenn Sie die Spezifikationen, die Tools und die Workflows haben, wissen Sie vielleicht immer noch nicht, wo Sie anfangen sollen.

Dafür gibt es Benchmarks.

Und wie Ian schon sagte, sagt eine allgemeine Bestenliste, insbesondere eine für Python, sehr wenig darüber aus, ob ein kleines Modell für Ihre Android-Workflows hilfreich ist.

Genauso wie ein Trockenbaubohrer Ihnen nicht viel über einen Betonbohrer verrät.

Sie sollten aber in Ihre eigenen Bewertungen investieren.

Sie sollten in das Testen Ihrer eigenen Architektur investieren, aber bevor Sie das tun, möchten Sie vielleicht nicht alle Ressourcen einsetzen.

Das kostet Zeit, Geld und Mühe. Wenn Sie sich öffentlich verfügbare Benchmarks ansehen, können Sie sich einen Überblick verschaffen und eine Vorauswahl treffen, bevor Sie in eigene Bewertungen investieren.

Es gibt drei Dinge, die Sie bei der Bewertung des Benchmarks berücksichtigen sollten:

Das ist ein bisschen Meta, aber im Grunde geht es zuerst darum, welche Art von Aufgabe dieses Modell ausführt.

Wie genau es ist.

Ähnelt sie der Art von Aufgabe, die Sie ihr geben werden?

Der zweite wäre der Umfang der Aufgabe.

Ist es das Schreiben von Dokumentation, das Lösen eines PR oder etwas, das wie die Art von Job aussieht, den Sie haben?

Und schließlich: Entspricht die Komplexität des Systems der Komplexität, die Sie bieten werden?

Hier sehen wir, warum ein Python-Benchmark für Android nicht sehr repräsentativ ist.

Deshalb haben wir Android Bench entwickelt, einen Benchmark, der das Android-Ökosystem und die Android-Arbeit erfasst.

Die erste Version enthält 100 Android-Aufgaben in PR-Größe. Sie können sie noch heute über Harbor ausführen, um jede Kombination aus Agent, Modell und Skill zu prüfen.

Wir führen 2.0 mit komplexeren, länger laufenden Aufgaben ein, um die Fähigkeiten von Frontier-Modellen bei der Erledigung von Aufgaben wie denen, die Sie ihnen heute geben, zu verstehen.

Ich übergebe jetzt an Jose, der Ihnen die Ergebnisse zeigt, die wir damit erzielt haben, und einige Möglichkeiten, wie Sie die Arbeit mit kleinen Modellen optimieren können.

Okay, vielen Dank, Zoe.

Sehen wir uns also an, welche Aufgaben ein kleines Modell lösen kann und wo es an seine Grenzen stößt.

Wir definieren willkürlich vier Kategorien von Aufgaben: klein, mittel, groß und langfristig.

Langfristige Aufgaben sind Aufgaben, für die ein Mensch Tage oder Wochen benötigen würde.

Zum Beispiel eine Migration oder ein großes Refactoring. Und Spoiler-Alarm: Das geht nicht mit einem kleinen Modell.

Zumindest nicht auf einmal.

Darauf gehen wir später noch ein.

Okay, kleine Aufgaben.

Das sind Jobs, bei denen vielleicht ein oder zwei Dateien gelesen und geschrieben werden müssen und die nicht viel Wissen erfordern.

Kleine Modelle sind beispielsweise ziemlich gut in Compose, zumindest was die Grundlagen betrifft.

Zum Beispiel, dass zwischen Elementen 8 dp Abstand sein müssen, dass ein Design anstelle von hartcodierten Farben verwendet werden muss oder dass Strings extrahiert werden müssen.

Diese sind für ein kleines Modell sehr einfach.

Dieses Lab behandelt ein fortgeschritteneres Thema, die Aufgabe ist aber trotzdem einfach.

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

Die Schwierigkeit liegt in diesem Fall im Umfang, nicht im Wissen.

Der Prompt gibt also an, welches Composable optimiert werden muss und was das Problem ist: Es wird bei jedem Frame neu zusammengesetzt.

Das macht die Aufgabe selbst für ein kleines Modell wie Gemma 4 ziemlich einfach.

In diesem Fall hat es 3 Minuten gedauert und es ist eine einzeilige Änderung.

Okay.

Wir haben also eine ziemlich gute Vorstellung davon, was ein kleines Modell ist.

Sehen wir uns an, was eine kleine Aufgabe ist.

Sehen wir uns die Aufgaben mit mittlerem Aufwand an.

Kleine Modelle sollten die meisten davon ausführen können.

In dieser Aufgabe fehlt in der App Pocket Casts der User-Agent in einer Anfrage und es gibt einen Fehler in der Wiederholungslogik.

Diese Aufgabe ist etwas schwieriger, weil wir hier zwei Dinge gleichzeitig anfordern und es keine Hinweise darauf gibt, wo sich diese Dinge in der Codebasis befinden.

Aber Nest Audio hat sie bestanden.

Das hat 10 Minuten gedauert.

Es wurden drei Dateien geändert.

Und übrigens hat es über OpenRouter 6 Cent gekostet.

Sehen wir uns nun eine Aufgabe aus demselben Dataset an, die fehlgeschlagen ist.

Dies ist ein Beispiel für Now in Android mit einem ziemlich umfassenden Bericht oder Prompt, aber es wird kein Klassenname oder keine Datei erwähnt. Der Agent muss also mehr Aufwand betreiben, um die Architektur der App, die Datenschicht, den Synchronisierungsmechanismus usw. zu verstehen. In diesem Fall ist der Durchlauf fehlgeschlagen.

Alles wurde fast richtig implementiert, aber es wurde davon ausgegangen, dass der Wert der ersten Synchronisierung -1 ist, obwohl er tatsächlich 0 ist.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

Das war's.

Dieser Fehler wäre erkannt worden, wenn der Agent die vorhandenen Unittests ausgeführt hätte.

Das zeigt, dass kleinere Modelle im Allgemeinen etwas früher aufhören als Frontier-Modelle.

Wir haben den KI-Agenten nur gebeten, das Problem zu beheben, nicht es zu überprüfen.

Vielleicht sollten wir die Aufgabe so ändern, dass sie einen Überprüfungsschritt enthält.

Darauf kommen wir gleich noch zu sprechen.

Sprechen wir also über große Aufgaben.

Etwa die Hälfte der großen Aufgaben in dieser Definition wird jedes Mal bestanden.

Einige der fehlgeschlagenen Anfragen sind tatsächlich zu lang und komplex für ein kleines Modell. Da kann man nicht viel machen.

Aber bei einigen sieht man, dass das Modell zu 90 % richtig lag.

Wählen wir eine davon aus.

Ich habe diesen ausgewählt, weil er unzuverlässig ist.

Sie wird etwa die Hälfte der Zeit ausgeführt.

Ich denke, dass dies die Grenzen dessen sind, was ein kleines Modell leisten kann.

Oder zumindest ein Modell von April.

Es geht um das Parsen fehlerhafter URLs in der Coil-Bibliothek.

Wie Sie sehen, ist die PR-Beschreibung ziemlich umfassend, was gut ist, aber eine Anforderung wurde nicht erfüllt.

Sehen wir uns das kurz an.

Alle Durchläufe wurden auf typische URL-Codierungen und Fehler geprüft, aber nur einige, die Hälfte, haben Tests für schlecht codierte Zeichen hinzugefügt, also diesen Testfall.

Diejenigen, die das nicht taten, haben die Bewertung nicht bestanden.

Alle Durchläufe sind also fast perfekt, aber das zeigt wieder, dass kleine Modelle nicht immer den zusätzlichen Schritt gehen.

Sie befolgen Anweisungen, versuchen aber nicht, Sie zu beeindrucken, wie es Frontier-Modelle tun.

Sie wissen, wie Sie den Aufwand für einen Agenten festlegen können?

Beachten Sie, dass er bei einem kleinen Modell zu niedrig eingestellt ist.

Definieren wir also große Aufgaben als solche, die von kleinen Modellen in etwa 50 % der Fälle erledigt werden können. Das ist das, was Gemma 4 31B mit dem Android Bench v1-Dataset erreichen kann, über das Zoe vorhin gesprochen hat.

Bevor wir über langfristige Aufgaben sprechen: Können wir etwas tun, um kleine Modelle bei diesen Aufgaben zu unterstützen?

Auf jeden Fall. Und diese Dinge erfordern überhaupt keinen Aufwand.

Wenn Sie ein Modell wie Gemma 4 lokal verwenden, wie Ian erwähnt hat, achten Sie darauf, dass es richtig konfiguriert ist.

Wenn Sie beispielsweise Ollama verwenden, um Gemma 4 bereitzustellen, wird standardmäßig ein Kontextfenster von 32.000 Tokens verwendet, obwohl das Modell tatsächlich achtmal mehr unterstützt.

Wenn Sie Gemma 4 über Android Studio verwenden, müssen Sie es natürlich nicht konfigurieren.

Sie ist standardmäßig richtig konfiguriert.

In unseren Bewertungen stieg die Erfolgsquote durch die Aktivierung des vollständigen Kontexts von 26 % auf 53 %.

Verwenden Sie als Nächstes die Android-Befehlszeile, das Android-Befehlszeilentool, insbesondere für die Suche in der Dokumentation.

Das ist nicht immer der Fall, da Modelle die Grundlagen recht gut beherrschen. Wenn Sie jedoch eine neue oder eine Nischen-API verwenden, ist die Dokumentation entscheidend.

Unserer Erfahrung nach ist das viel besser als die Verwendung von Websuchtools.

Fügen Sie als Nächstes Bestätigungshinweise hinzu.

Wir haben darüber gesprochen.

Teilen Sie dem Modell mit, wie Tests ausgeführt werden, welche Arten von Tests verfügbar sind, wie Emulatoren verwaltet werden usw. Sie können dies in einer AGENTS.md-Datei tun, wodurch die Anweisungen für alle Agenten verfügbar sind. Das ist aber ohnehin eine gute Sache.

Du solltest es haben.

Achten Sie aber auch auf sehr lange AGENTS.md-Dateien. Wenn Sie verschiedene Agents ausprobieren, werden Sie feststellen, dass einige von ihnen riesige System-Prompts und Toolbeschreibungen haben, die die Leistung kleiner Modelle zu beeinträchtigen scheinen.

Wir haben diese Benchmarks auch mit OpenCode durchgeführt und die Leistung war deutlich geringer als bei pi, wahrscheinlich weil größere Toolbeschreibungen und System-Prompts verwendet werden.

Fügen Sie als Nächstes Skills hinzu, entfernen Sie aber auch Skills.

Kleine Modelle benötigen möglicherweise einen Anstoß, wenn sie neue und Nischen-APIs verwenden. Es ist jedoch besser, ihren Kontext nicht mit allgemeinen Compose-Fähigkeiten zu füllen.

Wie sieht es mit langfristigen Aufgaben aus?

Diese Aufgaben umfassen Dutzende von Dateien, erfordern wichtige Architekturentscheidungen und werden normalerweise von einem Denkmodell verarbeitet, das einen Plan erstellt und eine Gruppe von Sub-Agents startet, die die verschiedenen Aufgaben ausführen.

Beispiele für langfristige Aufgaben sind die Migration einer gesamten App von XML zu Compose, die Erstellung einer komplexen App von Grund auf oder die Konvertierung plattformübergreifender Apps in native Android-Apps.

Wenn wir uns die Ergebnisse von Android Bench V2 ansehen, das sich ausschließlich auf langfristige Aufgaben konzentriert, sehen wir, dass Frontier-Modelle 3 % bis 40 % erreichen.

Für kleine Modelle ist das also definitiv eine Nummer zu groß.

Es wäre jedoch weitaus token- und guthabeneffizienter, die erste Analyse über ein Frontier-Modell zu leiten und dann einfachere Aufgaben an kleinere Modelle weiterzugeben.

Sehen wir uns an, wie das funktioniert.

Zurück zu Zoe.

Vielen Dank, Jose.

Wir kommen gleich zur Kaskade, aber bevor ich Ihnen einige Möglichkeiten zeige oder wir uns näher damit befassen, möchte ich einen Schritt zurückgehen und Ihnen andere Möglichkeiten zeigen, wie die Orchestrierung verschiedener Modelle Ihnen helfen kann.

Durch Orchestrierung können Sie also beispielsweise verhindern, dass Sie blockiert werden, oder?

Wenn also ein Anbieter ausfällt, Sie ein API-Ratenlimit erreichen oder Sie sich in einem Flugzeug oder Zug befinden, wie Ian sagte, können Sie ein Fallback-Modell einrichten, damit Sie online oder lokal weitermachen können, wenn etwas passiert.

Eine weitere Möglichkeit, bessere Antworten zu erhalten, ist die Orchestrierung.

Sie könnten beispielsweise ein kleines Modell selbstständig arbeiten lassen und einen Advisor aufrufen, wenn es ein wenig Unterstützung benötigt, um diese Hilfe zu erhalten.

Sie können auch ein Gremium einrichten, in dem verschiedene Arten von Modellen oder verschiedene Modelle dieselbe Aufgabe gleichzeitig ausführen. Anschließend können Sie die verschiedenen Antworten bewerten und sehen, wie sich die Gewichtungen und Biases der einzelnen Modelle auf das Ergebnis ausgewirkt haben.

Sie könnten auch ein separates Modell verwenden, sagen wir, für die Tests.

Es ist also wie eine Begutachtung durch Kollegen.

Und das konnte man hier sehen.

Und schließlich kann die Orchestrierung Ihnen helfen, durch eine solche Kaskade kosteneffizient zu sein.

Sie können es manuell einrichten und ein Modell für die Planung, ein anderes für die Ausführung und ein weiteres für Tests festlegen.

Es gibt mehrere Möglichkeiten, dies zu tun, entweder in der Cloud oder Sie können einen LiteLLM-Proxy einrichten, um es lokal zu tun.

Oder Sie verwenden einfach einen Klassifikator, um die Anfrage basierend auf der Anfrage automatisch an den richtigen Modelltyp weiterzuleiten. Das ist die Proxy-Idee, die Ian erwähnt hat, aber automatisch.

Kommen wir zum Schluss noch einmal auf die Frage zurück, die Jose zu Beginn des Vortrags gestellt hat: Was ist der Unterschied in Bezug auf Qualität und Accuracy zwischen kleinen Modellen und Frontier-Modellen?

Die Antwort lautet wie bei vielen Dingen in der Informatik: Es kommt darauf an.

Aber ich möchte noch einmal betonen, dass Sie das selbst beeinflussen können.

Hier können Sie je nach Einrichtung und Nutzung der einzelnen Elemente einen Unterschied machen.

Der erste Schritt ist also, das richtige Tool auszuwählen.

Es gibt verschiedene Arten von Tools.

Lernen Sie sie kennen, erkunden Sie sie, oder?

Und dann herausfinden, für welche Jobs sie geeignet sind oder welche Jobs sie sogar machen könnten.

Zweitens: Passen Sie den Umfang der Daten an, die das Modell für die Aufgabe erhält.

Dazu gehören beispielsweise die Anweisung für die Aufgabe, die Bereitstellung des richtigen Kontexts für die Aufgabe und nur des richtigen Kontexts für die Aufgabe sowie Möglichkeiten, die eigene Arbeit zu überprüfen.

Dann müssen Sie natürlich die gesamte Einrichtung testen und nicht nur das Modell isoliert, da dies einen Unterschied macht und die Ergebnisse, die Sie erhalten, möglicherweise optimiert werden könnten, wenn Sie es mit einer anderen Konfiguration von Elementen einrichten.

Letztendlich müssen Sie Ihre eigenen Bewertungen einrichten oder erstellen.

Und schließlich können Sie das Fahrrad und die Rakete so aufeinander abstimmen, dass Sie sich nie zwischen dem einen oder dem anderen entscheiden müssen und Ihr Budget effektiv einsetzen können.

Aber am wichtigsten ist, dass ihr weiter erkunden, weiter bauen und weiter Spaß haben könnt, oder?

Sie können noch heute damit beginnen, indem Sie eine Liste von Modellen über Android Bench und die dortigen Ergebnisse erstellen oder mit Gemma 4 in Android Studio beginnen.

Vielen Dank.