Workflow di programmazione agentica con modelli di piccole dimensioni

Okay.

Ciao.

Mi chiamo Jose e sono qui con Ian e Zoe.

Tutti conosciamo gli LLM.

Li usiamo per tutto: trovare ricette, riassumere video di YouTube e scrivere codice.

Esistono LLM molto grandi, come i modelli Gemini, in grado di fare cose davvero incredibili, ma in questo intervento parleremo di modelli linguistici di piccole dimensioni.

Sono anche LLM perché qualcosa che ha 4 miliardi di parametri non può essere piccolo, ma d'ora in poi faremo questa distinzione: modelli pionieristici e modelli linguistici di piccole dimensioni, il razzo e la bicicletta.

Parleremo dei modelli di piccole dimensioni non necessariamente come alternativa ai modelli pionieristici, ma soprattutto come loro complemento.

Esploreremo tutti i vantaggi dei modelli linguistici di piccole dimensioni, in particolare quando sono open source, con pesi aperti e scaricabili, ma diamo un'occhiata ai costi per un secondo.

Per questo intervento, ho eseguito molti benchmark e uno di questi era un set di dati di 200 attività medie e difficili che utilizzavano quasi 131 milioni di token per meno di 9 $.

Per questo ho utilizzato Gemma 4, quindi avrei potuto semplicemente scaricarlo ed eseguirlo sul mio hardware senza costi, ma l'ho eseguito su un gateway commerciale solo per un confronto equo.

Quindi, quanto costerebbe un modello pionieristico?

Circa 20-200 volte di più a seconda della memorizzazione dei token nella cache e di altri fattori.

Quindi, la bicicletta potrebbe non essere il mezzo di trasporto più veloce, ma è sicuramente il più efficiente.

È vero.

A questo punto, la domanda ovvia è: qual è la differenza in termini di qualità e accuratezza?

In questo particolare set di dati, Gemma 4 può risolvere il 53% delle attività.

Ciò significa due cose.

Se utilizzi un modello pionieristico per eseguire queste attività a sinistra, potrebbe essere eccessivo.

Se utilizzi un modello di piccole dimensioni per eseguire queste attività a destra, dovrai guidare il modello verso una soluzione o utilizzarne uno più grande.

In questo intervento, vogliamo aiutarti a ottenere il massimo da ogni token.

Zoe ti spiegherà come scegliere un modello di piccole dimensioni e Ian parlerà dei modelli Gemma per aiutarti a capire come inquadrare il tuo pensiero su ciò che possono consentire.

Poi vi mostrerò rapidamente come provare Gemma 4 in Android Studio e, infine, come inserire modelli di piccole dimensioni nei vostri flussi di lavoro quotidiani, oltre a benchmark reali di sviluppo Android per aiutarvi a capire cosa possono fare.

E ora passo la parola a Zoe.

Grazie mille, Jose.

Quindi, utilizzare un unico modello per tutto è un po' come usare un cannone per uccidere una mosca, giusto?

È efficiente, ma un po' sproporzionato.

Quindi, quando pensi ai modelli di piccole dimensioni, è quasi come se stessi espandendo il tuo set di strumenti.

Per sapere cosa devi inserire nei tuoi flussi di lavoro, devi aprire il set di strumenti, vedere cosa è disponibile, quali sono le specifiche e a cosa servono.

Quindi, per scegliere i modelli di piccole dimensioni, devi conoscerli.

Il tipo di modello a cui la maggior parte delle persone pensa quando pensa a un modello linguistico è un modello linguistico autoregressivo.

È autoregressivo perché, in base a un input suddiviso in token, sceglie il token successivo più probabile da un elenco di candidati.

Il token successivo più probabile scelto viene quindi reinserito nell'input e così via. Questo processo è in grado di produrre risposte coerenti e apparentemente intelligenti, ma presenta alcuni limiti, tra cui, ma non solo, il funzionamento lineare.

Quindi, possiamo lavorare in modo non lineare.

Un modello di diffusione ha lo stesso approccio, ma funziona con un blocco di token alla volta.

È quasi come un bozzetto che sta prendendo forma.

In questo caso, DiffusionGemma lavora su blocchi di 256 token alla volta.

In pratica, ottieni un pass che funziona sull'intero blocco, in modo da poter generare risultati con una latenza inferiore.

Ok, il nostro set di strumenti include modelli in grado di scrivere, giusto?

Sbagliato.

In pratica, i modelli di embedding trasformano oggetti come un'immagine, un testo o qualsiasi altro concetto in un vettore.

In questo modo, otteniamo una mappatura, diciamo, di coordinate in uno spazio ad alta dimensionalità che ci consente di confrontare due cose concettualmente.

Ad esempio, se un hot dog è un panino, è probabile che i due concetti siano vicini o finiscano in uno spazio vicino.

Per questo motivo, la possibilità di verificare se due concetti sono correlati diventa, diciamo, un po' di matematica invece di un passaggio del modello, che probabilmente è anche un po' di matematica, ma questo paradigma va ancora oltre, giusto?

Esistono anche modelli più piccoli e specializzati in grado di svolgere un'attività, e lo fanno molto bene.

Alcuni esempi sono i modelli di funzioni che trasformano il linguaggio naturale in chiamate API, i modelli di visione, di cui sono sicuro che sapete cosa sono in grado di fare dal nome, o, ad esempio, i classificatori che possono assegnare punteggi a un input in base a determinati parametri.

Ok, quindi la scelta è davvero ampia, giusto?

Esistono molti tipi diversi di modelli, con dimensioni, finestre di contesto, funzionalità e footprint della memoria differenti. Una volta aperta la cassetta degli attrezzi e prese in considerazione tutte le possibilità, le opzioni crescono in modo esponenziale, al punto che qualsiasi appassionato del fai da te sarebbe assolutamente entusiasta o paralizzato dall'indecisione.

Quindi, come si sceglie un modello di piccole dimensioni?

Iniziamo aprendo una serie di piccoli modelli aperti che possono essere eseguiti localmente, i modelli Gemma.

Passo la parola a Ian.

Grazie, Zoe.

Come ha detto Jose all'inizio, un modello linguistico di piccole dimensioni può svolgere circa il 50% delle attività senza bisogno di modifiche.

Ma perché dovresti scegliere un modello locale?

In sostanza, si tratta di quattro aspetti.

Il primo è la privacy.

Ad esempio, potresti avere chiavi API, codice proprietario o elementi che non possono letteralmente lasciare il tuo laptop.

Il secondo è la latenza.

Quindi, quando il modello viene effettivamente caricato nella memoria, che si tratti di memoria video o memoria unificata, ricevi una risposta non appena il calcolo è terminato.

Quindi, nessun tempo di round trip ai server, nessun costo di latenza aggiuntivo.

Poi abbiamo il costo marginale pari a zero.

Pertanto, i modelli sono convenienti quando puoi controllare dove vengono eseguiti.

Ad esempio, se esegui un'operazione su una macchina locale, potrebbe eseguire ulteriori tentativi in un loop di errori.

Non ti costa nulla e non ci sono costi imprevisti per l'API per questa parte.

Infine, il quarto è l'accesso offline.

Immagina di poterlo utilizzare su un aereo, un treno, un autobus o in metropolitana, praticamente ovunque il modello sia in esecuzione sul tuo hardware.

Sembra fantastico, ma ci sono due fattori principali da considerare quando si prendono queste decisioni.

La prima è la memoria, la seconda è la velocità.

Se guardi questo diagramma, i due modelli in basso, 26B e 31B, richiedono entrambi oltre 50 GB di RAM video per essere eseguiti in BF16, che è una quantizzazione a 16 bit.

La sfida, in questo caso, è che non si adatterebbe a molti hardware.

Quindi, eseguiamo un processo chiamato quantizzazione che riduce la precisione, ad esempio, a un float a 4 bit.

Ora è un po' più ragionevole.

Stiamo parlando di 14 GB e 17 GB, giusto?

Ora potrebbe essere eseguito su un Mac con memoria unificata.

La sfida con questo approccio è che, nella normale quantizzazione post-addestramento, quando comprimi i pesi, perdi un po' di accuratezza nel modello rispetto al modello di base. Abbiamo una tecnica per contrastare questo problema.

Si chiama addestramento basato sulla quantizzazione.

In questo modo, durante l'addestramento, il modello impara che verrà eseguito su queste dimensioni più piccole e, di conseguenza, la perdita è minore.

In questo modo, otteniamo una riduzione del 75% dei requisiti di RAM e ora il modello può essere eseguito su questi dispositivi.

E facciamo un ulteriore passo avanti.

Quindi, gli approcci di quantizzazione mobile che abbiamo e che funzionano su molti smartphone possono ridurre ulteriormente questi modelli comprendendo come funzionano tutti i diversi livelli e con quali dimensioni possono operare.

Quindi, abbiamo una sorta di quantizzazione mista.

Quindi, passiamo da un Gemma E2B da 11,4 GB a un modello da 1,1 GB.

Quindi, ora è molto più ragionevole su smartphone di fascia medio-alta.

Il secondo è la velocità.

Quindi, quando utilizzi un modello autoregressivo, come ha detto Zoe, stai prevedendo il prossimo insieme di token.

Quindi, in un'attività di programmazione, potresti scoprire che molti di questi token sono in realtà abbastanza prevedibili, ad esempio la fine della firma di un metodo o una parentesi graffa di apertura o chiusura.

Quindi, puoi utilizzare una tecnica chiamata decodifica speculativa.

In questo modo, verrà utilizzato un modello di bozza più piccolo per prevedere un numero di token che vengono poi convalidati da un modello più grande.

Il motivo per cui questo funziona nell'architettura di Gemma 4 è che condividono la stessa cache KV.

Quindi, immagina che sia una sorta di memoria a breve termine del modello.

Quindi, un piccolo modello di bozza prevede tre o quattro token in anticipo e il modello più grande esamina la stessa cache KV e convalida l'output.

Ciò può comportare un aumento di circa 3 volte delle prestazioni senza alcuna perdita effettiva di qualità dell'output del modello, perché si limita a prevedere le cose e poi a decidere se sono corrette o meno.

Quindi, ancora una volta, dipende un po' dall'attività che stai svolgendo.

Quindi, questo non funziona molto bene su cose come la scrittura creativa, perché c'è più variabilità, ma funziona molto bene su cose prevedibili come le strutture JSON e la programmazione.

Quindi, come valuteresti effettivamente uno di questi modelli?

Quindi, la cosa più ovvia che potresti fare è andare a guardare un benchmark come, ad esempio, LiveCodeBench o MMLU, e guardare un punteggio.

Tuttavia, questo ti darà solo un indicatore di alto livello sulla capacità del modello.

Quello che devi fare è valutare l'intero stack in cui viene eseguito.

Quindi, questo è il modello che stai utilizzando, i pesi e l'approccio di quantizzazione, è l'inferenza del runtime, quindi potresti utilizzare qualcosa come llama.cpp o Ollama o LiteRT, l'infrastruttura agentica che stai utilizzando, che sia Pi o OpenCode o Antigravity, e poi la finestra contestuale, che è una sorta di spazio per tutti i dati che vuoi che il tuo modello sia in grado di elaborare.

La combinazione di tutti questi elementi determina la fattibilità del progetto.

Per fare un esempio rapido, stavamo eseguendo alcuni test con Gemma 4 su Android Bench e stavamo utilizzando una versione di Ollama con un contesto predefinito di 32k.

Abbiamo scoperto che in uno dei test, in cui cercava un bug, la compressione dell'infrastruttura agentica spostava il file out of memory, impedendo al modello di completare l'attività e causandone il fallimento.

Quindi, semplicemente aumentando il contesto da 32k a 256k, ora è in grado di mantenerlo in memoria e il modello è in grado di superare quel particolare test.

Abbiamo visto raddoppiare il tasso di successo per quel particolare lavoro.

Questo dimostra che anche uno solo di questi piccoli fattori può avere un grande impatto sull'idoneità o meno di questo modello.

Quindi, come si eseguono effettivamente le valutazioni?

Ecco tre rapidi suggerimenti.

Ad esempio, potresti prendere una cronologia Git, ovvero un gruppo di PR che hai già ottenuto e che hanno avuto esito positivo, e utilizzarle come input dei prompt per il modello e vedere come si comporta.

Poi, hai bisogno di un valutatore deterministico che ti aiuti a valutare se l'output del modello è corretto o meno.

Abbiamo due ottimi esempi di questo.

Abbiamo un compilatore e dei test delle unità.

Qualunque cosa venga generata, puoi eseguirla tramite questo strumento, che ti dirà se hai superato o meno l'attività specifica.

Infine, il terzo è Log Trajectories.

Quindi, quando esegui un agente, vuoi essere in grado di tracciare i diversi comportamenti dell'agente, vedere dove ha successo e dove fallisce, e puoi usarlo per valutare quanto il modello è in grado di interagire e utilizzare gli strumenti.

E voglio che proviate a cambiare il modo in cui ponete la domanda, ad esempio: "Questo modello è intelligente quanto questo grande modello pionieristico?"

A "Questa attività è possibile su questo hardware con questa particolare configurazione?"

Per capirlo, abbiamo inventato un framework chiamato "Are we there yet?"

O AWTY.

L'intero principio di questo framework consiste nel valutare su quell'asse tutte queste diverse attività in termini di idoneità.

Quindi, il modello stesso, il motore di inferenza che stai utilizzando, l'harness e la configurazione hardware.

Questo ti dirà se sei pronto.

Ad esempio, potresti voler valutare l'affidabilità di una determinata attività.

Se lo esegui, ad esempio, 10 volte di seguito, fa la stessa cosa ogni volta?

Potresti riscontrare una latenza.

Forse hai bisogno di una risposta in tempo reale.

Quindi, quali sono le tue soglie per la velocità di esecuzione dell'attività?

Poi potresti esaminare i requisiti di RAM.

Quindi, non si tratta solo della RAM del dispositivo, ma della RAM del dispositivo, della parte che puoi utilizzare e delle altre applicazioni e degli altri strumenti che dovrai eseguire su quell'hardware.

Quindi, puoi occupare il 50% o solo il 10% della RAM?

E ottieni questo tipo di punteggio di recupero finale.

Se è verde, significa che la configurazione è pronta.

Se è arancione, giallo o rosso, significa che potrebbe essere necessario modificare qualcosa nella configurazione.

Forse hai bisogno di un acceleratore più veloce per una latenza inferiore o di un modello più grande e più potente.

Quindi, sì, ti suggerisco di dare un'occhiata a questo.

Al momento abbiamo un'anteprima e ci piacerebbe ricevere il tuo feedback sull'utilità di questo strumento.

Zoe parlerà un po' più in dettaglio di come abbiamo configurato alcune delle valutazioni in un secondo momento, ma ora passo la parola a Jose, che vi mostrerà un modo molto rapido per iniziare a utilizzare Gemma 4.

Grazie, Ian.

Quindi, sì, il modo più veloce per provare Gemma 4 oggi è probabilmente tramite Android Studio.

Vediamo come.

Passiamo al laptop, per favore.

Così.

Quindi, se vado alla pagina dei provider di modelli nelle impostazioni e seleziono Gemma, questo ti dà un'idea abbastanza chiara delle dimensioni di ogni modello.

Devo solo scaricare i modelli sul mio disco rigido.

In questo modo, si apre o si avvia un server llama.cpp, che viene configurato correttamente fin dall'inizio.

Tuttavia, puoi anche utilizzare il tuo server llama.cpp, Ollama o LM Studio, a seconda delle tue preferenze.

Per farlo, basta andare qui e aggiungere un provider locale.

Inoltre, è molto sensato utilizzare modelli di piccole dimensioni tramite un provider remoto.

Quindi, puoi aggiungerne uno qui, purché sia compatibile con OpenAI o Anthropic, puoi connetterti.

Bene, vediamo.

A proposito, il modo in cui selezioni un modello in Android Studio è tramite questo menu a discesa, ovviamente.

Ho selezionato Gemma 4 26B e posso chiedere: "Che cos'è un ViewModel?"

Ok.

Quindi, una cosa molto importante da ricordare è che, ogni volta che cambi modello, l'intera conversazione viene inviata di nuovo al nuovo modello dall'inizio.

Quindi, se generi una conversazione molto lunga con un modello e vuoi passare a un altro, probabilmente dovresti iniziare una nuova conversazione, comprimerla o altro.

Ora torniamo alle slide e a Zoe per scoprire i diversi workflow che puoi eseguire con i modelli di piccole dimensioni.

Grazie mille, Jose, e grazie, Ian, per la panoramica sui modelli Gemma e per averci detto se siamo già arrivati o meno.

Abbiamo visto quali tipi di modelli esistono e quali sono le loro specifiche. Ora si tratta di capire quali sono alcuni tipi di attività che puoi affidare loro.

Il primo tipo di attività che probabilmente stai già svolgendo sono i workflow di programmazione, come il debug o la risoluzione dei problemi, o qualcosa che, ne sono certo, tutti, o almeno io, rimpiangeremo con profondo sarcasmo di fare manualmente, ovvero l'aumento della copertura dei test.

molto utile.

Queste sono alcune delle cose che sono abbastanza sicuro che tutti stiano già facendo, anche, probabilmente, senza rendersene conto.

Ma vorrei incoraggiarti a pensare oltre, giusto?

Quindi, considerando che i modelli di piccole dimensioni possono essere open-weight ed essere eseguiti localmente, cosa potrebbe farti risparmiare tempo?

molto utile.

Stiamo parlando di non usare il razzo, quindi perché usiamo un cervello per questo?

Quindi, se potessimo andare oltre, quali sono alcune cose che i modelli di piccole dimensioni potrebbero fare?

Quali sono alcuni flussi di lavoro in cui potresti integrarli per semplificarti la vita e darti più tempo per fare cose che, sai, magari vorresti fare di più?

Ad esempio, assicurarsi che la documentazione sia sempre aggiornata con le modifiche apportate o che siano presenti test di regressione automatici che fanno parte di un hook pre-commit, o anche assicurarsi che il contesto che l'agente riceve nell'ambito dei flussi di lavoro sia ottimizzato per l'agente e funzioni ancora più velocemente.

Questi sono alcuni esempi, giusto?

E, alla fine, non ci sono limiti, o meglio, l'architettura è il limite, e ci sono molte cose che potresti pensare di implementare.

Ma, avendo le specifiche, gli strumenti e i flussi di lavoro, non sai ancora da dove iniziare?

Beh, è a questo che servono i benchmark.

E, come ha detto Ian, una classifica generica, in particolare una per Python, ti dirà molto poco sull'utilità di un modello di piccole dimensioni per i tuoi workflow Android.

Proprio come un trapano per cartongesso potrebbe non darti molte informazioni su un trapano per calcestruzzo.

Tuttavia, dovresti investire nelle tue valutazioni.

Dovresti investire nel test della tua architettura, ma prima di farlo, potresti non voler impiegare tutte le risorse.

Richiede tempo, denaro e impegno, quindi l'esame dei benchmark disponibili pubblicamente può darti un'idea e un elenco ristretto prima di decidere di investire nelle tue valutazioni.

Ci sono tre aspetti da considerare quando si valuta il benchmark, giusto?

È un po' meta, ma, in pratica, la prima cosa è: qual è il tipo di attività che sta svolgendo questo modello?

Quanto è specifico.

Assomiglia al tipo di attività che gli assegnerai?

La seconda è l'ambito dell'attività.

Quindi, si tratta di scrivere documentazione, risolvere una PR o qualcosa che assomiglia al tipo di lavoro che svolgi?

Infine, la complessità del sistema è simile a quella che intendi fornire?

Ed è qui che possiamo vedere perché un benchmark Python non sarà molto rappresentativo di Android.

Ecco perché abbiamo creato Android Bench, un benchmark che acquisisce l'ecosistema Android e il lavoro su Android.

La prima versione contiene 100 attività Android di dimensioni PR e puoi eseguirla oggi stesso tramite Harbor per controllare qualsiasi combinazione di agente, modello e skill.

Lanceremo la versione 2.0 con attività più complesse e di lunga durata per capire quali sono le capacità dei modelli pionieristici di svolgere lavori come quelli che gli affidiamo oggi.

Ora lascio la parola a Jose, che vi mostrerà i risultati che abbiamo ottenuto e alcuni modi per ottimizzare il lavoro con i modelli di piccole dimensioni.

Okay, thank you, Zoe.

Bene, diamo un'occhiata alle attività che un modello di piccole dimensioni può risolvere e dove inizia a incontrare difficoltà.

Definiamo, in modo arbitrario, quattro categorie di attività: piccole, medie, grandi e a lungo termine.

Le attività a lungo termine sono attività che potrebbero richiedere giorni o settimane per essere completate da un essere umano.

Ad esempio, una migrazione, un grande refactoring e, spoiler, non puoi farlo con un modello di piccole dimensioni.

Almeno non in una sola volta.

Ne parleremo più avanti.

Ok, piccole attività.

Si tratta di job che richiedono la lettura e la scrittura di uno o due file e non richiedono molte conoscenze.

Ad esempio, i modelli di piccole dimensioni sono piuttosto efficaci con Compose, almeno per quanto riguarda le nozioni di base.

Ad esempio, deve esserci uno spazio di 8 dp tra gli elementi, oppure bisogna utilizzare un tema anziché colori impostati come hardcoded o estrarre stringhe.

Queste sono molto semplici per un modello di piccole dimensioni.

Questa, invece, riguarda un argomento più avanzato, ma l'attività è comunque semplice.

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

La difficoltà, in questo caso, riguarda l'ambito, non la conoscenza.

Quindi, il prompt ci dice effettivamente quale composable ottimizzare e cosa c'è che non va: si sta ricomponendo su ogni frame.

Questo semplifica molto il lavoro anche per un modello di piccole dimensioni, come Gemma 4.

In questo caso, l'operazione ha richiesto 3 minuti ed è una modifica di una riga.

Okay.

Quindi, penso che abbiamo un'idea abbastanza chiara di cosa sia un modello di piccole dimensioni.

Diamo un'occhiata a un'attività di piccole dimensioni.

Diamo un'occhiata alle attività di media difficoltà.

I modelli di piccole dimensioni dovrebbero essere in grado di eseguire la maggior parte di queste attività.

In questa attività, nell'app Pocket Casts, lo user agent non è presente in una richiesta e si verifica un errore nella logica di ripetizione.

Questa è un po' più difficile perché, innanzitutto, stiamo richiedendo due cose contemporaneamente e non ci sono indizi su dove si trovino queste cose nella codebase.

Ma è passato.

Ci sono voluti 10 minuti.

Ha modificato tre file.

E, tra l'altro, è costato 6 centesimi tramite OpenRouter.

Ora diamo un'occhiata a un'attività non riuscita dello stesso set di dati.

Questo è un esempio di Now in Android con un report o un prompt piuttosto completo, ma non menziona il nome di una classe o di un file, quindi l'agente deve impegnarsi di più per comprendere l'architettura dell'app, il livello dati, il meccanismo di sincronizzazione e, in questo caso, ecc. Quindi, in questa particolare esecuzione, non è riuscito.

Tutto è stato implementato quasi correttamente, ma si è semplicemente ipotizzato che il valore della sincronizzazione iniziale sarebbe stato -1, mentre in realtà è 0.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

È tutto.

Questo bug sarebbe stato rilevato se l'agente avesse eseguito il test delle unità, i test delle unità esistenti.

Questo dimostra che, in generale, i modelli più piccoli tendono a fermarsi un po' prima di quelli di frontiera.

Abbiamo chiesto all'agente di risolvere il problema, non di verificarlo.

Quindi, forse dovremmo modificare l'attività in modo che contenga un passaggio di verifica.

Ne parleremo tra un attimo.

Ok, parliamo di attività di grandi dimensioni.

Circa la metà delle attività di grandi dimensioni, in questa definizione, viene superata ogni volta.

Alcuni di quelli che non vanno a buon fine sono in realtà troppo lunghi e complessi per un modello di piccole dimensioni, quindi non c'è molto da fare.

Ma ce ne sono alcuni che, quando guardi cosa è successo effettivamente, ti rendi conto che il modello era al 90 o al 90% lì.

Scegliamone uno.

Ho scelto questo perché è un test instabile.

Viene superato circa la metà delle volte in cui viene eseguito.

Quindi, considero questo un esempio di ciò che un modello di piccole dimensioni può fare.

O, almeno, un modello di aprile.

Riguarda l'analisi di URL non corretti nella libreria Coil.

Come puoi vedere, la descrizione della PR è piuttosto completa, il che è ottimo, ma ha tralasciato un requisito.

Diamo un'occhiata veloce.

Tutte le esecuzioni hanno verificato la presenza di codifiche ed errori URL tipici, ma solo alcune, la metà, hanno aggiunto test per i caratteri codificati in modo errato, quindi quello scenario di test.

Quelli che non l'hanno fatto non hanno superato la valutazione.

Quindi, tutte le esecuzioni sono quasi perfette, ma questo dimostra ancora una volta che i modelli di piccole dimensioni non sempre fanno il passo successivo.

Seguono le istruzioni, ma non cercano di impressionarti come fanno i modelli pionieristici.

Sai che oggi puoi impostare l'impegno di un agente?

Tieni presente che è impostato su un valore troppo basso quando utilizzi un modello di piccole dimensioni.

Definiamo quindi le attività di grandi dimensioni come quelle che potrebbero essere completate da modelli di piccole dimensioni circa il 50% delle volte, ovvero ciò che Gemma 4 31B può raggiungere rispetto al set di dati Android Bench v1, di cui Zoe ha parlato prima.

Quindi, prima di parlare di attività a lungo termine, possiamo fare qualcosa per aiutare i modelli di piccole dimensioni con queste attività?

Assolutamente sì, e queste cose non richiedono alcuno sforzo.

Innanzitutto, se utilizzi un modello come Gemma 4 localmente, come ha menzionato Ian, assicurati che sia configurato correttamente.

Ad esempio, se utilizzi Ollama per gestire Gemma 4, per impostazione predefinita viene utilizzata una finestra contestuale di 32.000 token, quando in realtà ne supporta otto volte di più.

Naturalmente, se utilizzi Gemma 4 tramite Android Studio, non devi configurarlo.

È configurato correttamente per impostazione predefinita.

Nel nostro set di valutazioni, l'attivazione del contesto completo ha fatto passare i risultati dal 26% al 53%.

Poi, utilizza la CLI Android, lo strumento CLI Android, in particolare per la ricerca della documentazione.

Questo non è sempre vero, poiché i modelli sono piuttosto bravi con le nozioni di base, ma ogni volta che utilizzi un'API nuova o di nicchia, la documentazione è fondamentale.

Molto meglio che utilizzare gli strumenti di ricerca web, secondo la nostra esperienza.

Poi, aggiungi i suggerimenti per la verifica.

Ne abbiamo parlato.

Spiega al modello come eseguire i test, quali tipi di test sono disponibili, come gestire gli emulatori e così via. Puoi farlo in un file AGENTS.md, che renderebbe le istruzioni disponibili per tutti gli agenti, ma, voglio dire, è comunque una buona cosa.

Dovresti averlo.

Tuttavia, fai attenzione anche ai file AGENTS.md molto lunghi, perché se provi diversi agenti, vedrai che alcuni di loro hanno prompt di sistema e descrizioni degli strumenti enormi e sembrano peggiorare le prestazioni dei modelli di piccole dimensioni.

Abbiamo provato a eseguire questi benchmark con OpenCode e i risultati sono stati molto inferiori rispetto a pi, probabilmente perché utilizza descrizioni degli strumenti e prompt di sistema più grandi.

Poi, aggiungi le skill, ma rimuovile anche.

I modelli di piccole dimensioni potrebbero aver bisogno di un aiuto quando utilizzano API nuove e di nicchia, ma è meglio non riempire il loro contesto con competenze generali di Compose, ad esempio.

E per quanto riguarda le attività a lungo termine?

Si tratta di attività che coinvolgono decine di file, richiedono decisioni architettoniche importanti e vengono normalmente gestite da un modello di ragionamento che crea un piano e avvia uno sciame di sub-agenti che eseguono le diverse attività.

Esempi di attività a lungo termine sono la migrazione di un'intera app da XML a Compose, la creazione di un'app complessa da zero o la conversione di app multipiattaforma in Android nativo.

Se esaminiamo i risultati di Android Bench V2, che si concentra esclusivamente sul lungo termine, vediamo che i modelli pionieristici ottengono un punteggio compreso tra il 3% e il 40%.

Quindi, per i modelli di piccole dimensioni, penso che sia sicuro affermare che non sono in grado di farlo.

Tuttavia, l'instradamento dell'analisi iniziale tramite un modello pionieristico e l'assegnazione di attività più semplici a modelli più piccoli sarebbe molto più efficiente in termini di token e crediti.

Vediamo come fare.

Torniamo a Zoe.

Grazie mille, Jose.

Parleremo della cascata, ma prima di mostrarvi alcuni modi o di approfondire l'argomento, voglio fare un passo indietro e mostrarvi altri modi in cui l'orchestrazione di modelli diversi può aiutarvi.

Quindi, l'orchestrazione può, ad esempio, aiutarti a non essere mai bloccato, giusto?

Quindi, se un provider non è disponibile, se raggiungi un limite di frequenza dell'API o se sei su un aereo o un treno, come diceva Ian, puoi configurare un modello di riserva e fare in modo che, online o localmente, tu possa continuare se succede qualcosa.

Un'altra cosa che puoi fare tramite l'orchestrazione è ottenere risposte migliori.

Ad esempio, potresti far lavorare un modello di piccole dimensioni in autonomia e chiamare un consulente ogni volta che ha bisogno di un po' di supporto per ottenere l'aiuto necessario.

Potresti anche creare un consiglio in cui diversi tipi di modelli, o modelli diversi, eseguono tutti la stessa attività contemporaneamente, per poi valutare le diverse risposte e il modo in cui i pesi e i bias di ciascun modello hanno influito sul risultato.

Puoi anche utilizzare un modello separato, ad esempio per i test.

In pratica, è come una revisione tra pari.

E lo si poteva vedere attraverso questo.

Infine, l'orchestrazione può aiutarti a ottimizzare i costi attraverso un processo come quello della cascata.

In pratica, puoi configurarlo manualmente, in modo da impostare un modello per la pianificazione, un modello diverso per l'esecuzione e un altro per i test.

Esistono diversi modi per farlo, sia sul cloud sia configurando un proxy LiteLLM per farlo localmente.

Oppure potresti semplicemente utilizzare un classificatore per indirizzarla automaticamente al tipo di modello giusto in base alla richiesta, che è l'idea del proxy menzionata da Ian, ma automatica.

Quindi, concludiamo tornando alla domanda che Jose ha posto all'inizio del discorso, ovvero: qual è la differenza in termini di qualità e accuratezza tra i modelli di piccole dimensioni e i modelli pionieristici?

La risposta, come per molte cose in informatica, è: dipende.

Tuttavia, questo è un aspetto che vorrei approfondire con te, perché è qualcosa che puoi progettare.

Questo è un aspetto in cui puoi fare la differenza, a seconda di come lo configuri e di come giochi con i pezzi.

Quindi, il primo passo è scegliere lo strumento giusto, no?

Esistono diversi tipi di strumenti.

Conoscerli, esplorarli, giusto?

E poi scoprire quali lavori sono adatti a loro o anche quali lavori potrebbero fare.

Il secondo è assicurarsi di modificare l'ambito che il modello sta ricevendo per svolgere il lavoro.

Ad esempio, le istruzioni per l'attività, la fornitura del contesto giusto per l'attività e solo del contesto giusto per l'attività, nonché i modi per controllare il proprio lavoro.

Poi, ovviamente, devi impostare e testare l'intera configurazione e non solo il modello in isolamento, perché questo farà la differenza e forse i risultati che stai ottenendo potrebbero essere modificati se lo configuri con, diciamo, una configurazione diversa degli elementi.

In fin dei conti, devi lavorare alla configurazione o alla creazione delle tue valutazioni.

Infine, puoi orchestrare la bicicletta e il razzo in modo da non dover mai scegliere tra l'uno o l'altro e spendere in modo efficace.

Ma soprattutto, puoi continuare a esplorare, a creare e a divertirti, giusto?

Puoi iniziare oggi stesso creando una rosa di modelli tramite Android Bench e i risultati che hai ottenuto, oppure iniziando con Gemma 4 su Android Studio.

Quindi, grazie mille.