Fluxos de trabalho de programação com agentes com modelos pequenos

Certo.

Olá!

Meu nome é Jose, e estou aqui com Ian e Zoe.

Todos nós conhecemos os LLMs.

Usamos para tudo: encontrar receitas, resumir vídeos do YouTube e programar.

Existem LLMs gigantes, como os modelos do Gemini, que são capazes de coisas realmente incríveis, mas nesta palestra, vamos falar sobre modelos de linguagem pequenos.

Eles também são LLMs, porque algo com 4 bilhões de parâmetros não pode ser pequeno, mas vamos fazer essa distinção a partir de agora: modelos de fronteira e modelos de linguagem pequenos, o foguete e a bicicleta.

Vamos falar sobre os modelos pequenos não necessariamente como uma alternativa aos modelos de fronteira, mas principalmente como um complemento a eles.

Vamos analisar todos os benefícios dos modelos de linguagem pequenos, especialmente quando eles são abertos, têm pesos abertos e podem ser baixados, mas vamos analisar o custo por um segundo.

Para esta palestra, fiz muitos comparativos de mercado, e um deles foi um conjunto de dados de 200 tarefas médias e difíceis usando quase 131 milhões de tokens por menos de US $9.

Usei o Gemma 4 para isso, então poderia ter feito o download e executado no meu próprio hardware sem custo financeiro, mas usei um gateway comercial para fazer uma comparação justa.

Então, quanto custaria um modelo de fronteira?

Cerca de 20 a 200 vezes mais, dependendo do armazenamento em cache de tokens e de outros fatores.

Portanto, a bicicleta pode não ser o meio de transporte mais rápido, mas é definitivamente o mais eficiente.

É verdade.

Agora, a pergunta óbvia é: qual é a diferença na qualidade e na precisão?

Nesse conjunto de dados específico, o Gemma 4 pode resolver 53% das tarefas.

Isso tem dois significados.

Se você estiver usando um modelo de fronteira para executar as tarefas à esquerda, talvez seja um exagero.

E se você estiver usando um modelo pequeno para executar essas tarefas à direita, precisará orientar o modelo para uma solução ou usar um modelo maior.

Nesta palestra, queremos ajudar você a aproveitar ao máximo cada token.

Zoe vai explicar como escolher um modelo pequeno, e Ian vai falar sobre os modelos Gemma para que você entenda como pensar sobre o que eles podem fazer.

Em seguida, vou mostrar rapidamente como testar o Gemma 4 no Android Studio e, por fim, vamos mostrar como encaixar modelos pequenos nos seus fluxos de trabalho diários e também comparativos de mercado reais de desenvolvimento Android para ajudar você a entender o que eles podem fazer.

Agora é com a Zoe.

Muito obrigado, Jose.

Então, usar um modelo para tudo é como usar um canhão para matar uma mosca, certo?

É eficiente, mas um pouco desproporcional.

Então, quando você pensa em modelos pequenos, é como se estivesse expandindo seu conjunto de ferramentas.

Para saber o que você precisa incluir nos seus fluxos de trabalho, abra o conjunto de ferramentas, veja o que está disponível, quais são as especificações e para que servem.

Portanto, para escolher modelos pequenos, você precisa conhecê-los.

E o tipo de modelo que a maioria das pessoas pensa quando pensa em um modelo de linguagem é um modelo de linguagem autorregressivo.

Isso é autorregressivo porque, com base em uma entrada dividida em tokens, ele escolhe o próximo token mais provável em uma lista de candidatos.

Em seguida, o token mais provável escolhido volta para a entrada, e assim por diante. Isso é capaz de produzir respostas coerentes e que parecem inteligentes, mas tem algumas ressalvas, incluindo, entre outras, o funcionamento linear.

Então, podemos trabalhar de forma não linear.

Um modelo de difusão tem a mesma abordagem, mas funciona com um bloco de tokens por vez.

É quase como um esboço que está ganhando foco.

Nesse caso, o DiffusionGemma trabalha com blocos de 256 tokens por vez.

Basicamente, você recebe um passe que funciona em todo o bloco, podendo gerar resultados com menos latência.

Então, nosso conjunto de ferramentas tem modelos que podem escrever, certo?

Errado.

Basicamente, os modelos de embedding transformam objetos como uma imagem, um texto ou qualquer outro conceito em um vetor.

Isso nos dá um mapeamento de, digamos, coordenadas em um espaço de alta dimensão que nos permite comparar duas coisas conceitualmente.

Por exemplo, se um cachorro-quente é um sanduíche, eles provavelmente vão ficar próximos ou acabar em um espaço próximo.

Por isso, verificar se dois conceitos estão relacionados se torna, digamos, um pouco de matemática em vez de uma passagem de modelo, que também é um pouco de matemática, mas esse paradigma vai ainda mais longe, certo?

E há modelos menores e especializados que são capazes de fazer um trabalho, e o fazem muito bem.

Alguns exemplos são os modelos de função, que transformam linguagem natural em chamadas de API, os modelos de visão, que você já deve saber o que fazem pelo nome, ou, por exemplo, os classificadores, que podem dar pontuações a uma entrada com base em determinados parâmetros.

São muitas opções, não é?

E há muitos tipos diferentes de modelos, com dimensões, tamanhos, janelas de contexto, recursos e consumo de memória diferentes. Quando você abre a caixa de ferramentas e considera todas as possibilidades, as opções crescem exponencialmente, a ponto de qualquer fã de DIY ficar absolutamente em êxtase ou congelado pela paralisia de decisão.

Então, como escolher um modelo pequeno?

Vamos começar abrindo uma caixa de ferramentas de modelos abertos pequenos que podem ser executados localmente: os modelos Gemma.

É com você, Ian.

Obrigada, Zoe.

Como o Jose mencionou no início, um modelo de linguagem pequeno pode realizar cerca de 50% das tarefas sem precisar de ajustes.

Mas por que escolher um modelo local?

Então, tudo se resume a quatro coisas.

O primeiro é a privacidade.

Por exemplo, você pode ter chaves de API, código proprietário ou coisas que literalmente não podem sair do seu laptop.

A segunda é a latência.

Assim, quando o modelo é carregado na memória, seja gráfica ou unificada, você recebe uma resposta assim que o cálculo é concluído.

Portanto, não há tempos de retorno para os servidores nem custo de latência adicional.

Em seguida, temos o custo marginal zero.

Portanto, os modelos são econômicos quando você pode controlar onde eles são executados.

Por exemplo, no caso de execução em uma máquina local, ele pode estar fazendo novas tentativas em um loop de erro.

Não custa nada, e não há custos inesperados de API para essa parte.

Por fim, o quarto é o acesso off-line.

Imagine que você pode usar isso em um avião, trem, ônibus ou metrô, basicamente em qualquer lugar onde o modelo esteja sendo executado no seu hardware.

Isso parece ótimo, mas há dois fatores principais que precisamos considerar ao tomar essas decisões.

Uma é a memória, e a outra é a velocidade.

Se você olhar para este diagrama aqui, os dois modelos inferiores, o 26B e o 31B, precisam de mais de 50 GB de RAM de vídeo para serem executados no BF16, que é uma quantização de 16 bits.

O desafio é que isso não caberia em muitos hardwares.

Por isso, fazemos um processo chamado quantização, que reduz essa precisão para, digamos, um float de 4 bits.

Agora está um pouco mais razoável.

Estamos falando de 14 GB e 17 GB, certo?

Isso agora caberia em algo como um Mac com memória unificada.

O desafio é que, na quantização pós-treinamento normal, ao compactar esses pesos, você perde um pouco da acurácia do modelo base. Temos uma técnica para combater isso.

Isso é chamado de treinamento com reconhecimento de quantização.

E o que acontece quando fazemos isso é que, conforme o modelo é treinado, ele é treinado para saber que vai estar nesses tamanhos menores e, portanto, há menos perda em comparação com isso.

Assim, temos uma redução de 75% nos requisitos de RAM, e agora ele pode ser usado nesses dispositivos.

E vamos além.

As abordagens de quantização para dispositivos móveis que funcionam em muitos smartphones podem reduzir ainda mais esses modelos, entendendo como todas as camadas operam e em quais tamanhos elas podem operar.

Portanto, temos uma espécie de mistura de quantização.

Assim, passamos de um Gemma E2B de 11,4 GB para 1,1 GB.

Agora, ele é muito mais razoável em smartphones intermediários e de última geração.

O segundo benefício é a velocidade.

Então, ao usar um modelo autorregressivo, como a Zoe mencionou, você prevê o próximo conjunto de tokens.

Em uma tarefa de programação, por exemplo, muitos desses tokens são bastante previsíveis, como o final de uma assinatura de método ou uma chave de abertura ou fechamento.

Para isso, você pode usar uma técnica chamada decodificação especulativa.

Isso significa que ele vai usar um modelo de rascunho menor para prever um número de tokens que serão validados por um modelo maior.

E o motivo disso funcionar na arquitetura do Gemma 4 é que eles compartilham o mesmo cache de KV.

Pense nisso como a memória de curto prazo do modelo.

Então, o que vai acontecer é que um modelo de rascunho pequeno vai prever três ou quatro tokens com antecedência, e o modelo maior vai analisar o mesmo cache de KV e validar a saída.

Isso pode resultar em um aumento de cerca de 3 vezes na performance, sem perda real de qualidade na saída do modelo, porque ele apenas prevê as coisas e decide se elas são aprovadas ou reprovadas, se estão corretas ou não.

Então, depende um pouco da tarefa que você está fazendo.

Portanto, isso não funciona tão bem em coisas como escrita criativa, porque há mais variabilidade, mas funciona muito bem em coisas previsíveis, como estruturas JSON e programação.

Então, como você avaliaria um desses modelos?

Então, a coisa mais óbvia que você pode fazer é olhar para um comparativo de mercado, como o LiveCodeBench ou o MMLU, e ver uma pontuação.

Mas isso só vai dar um indicador de alto nível sobre a capacidade do modelo.

O que você realmente precisa fazer é avaliar toda a pilha em que ele está sendo executado.

Esse é o modelo que você está usando, os pesos e a abordagem de quantização, a inferência do ambiente de execução, então você pode usar algo como llama.cpp, Ollama ou LiteRT, a estrutura de agentes que você está usando, seja Pi, OpenCode ou Antigravity, e a janela de contexto, que é o espaço para todos os dados que você quer que o modelo processe.

E a combinação de tudo isso resulta na viabilidade.

Para dar um exemplo rápido, estávamos fazendo alguns testes com o Gemma 4 no Android Bench e executando uma versão do Ollama com um contexto padrão de 32 mil.

E o que descobrimos é que, em um dos testes, em que ele estava procurando um bug, a compactação da estrutura do agente movia esse arquivo para fora da memória, e o modelo não conseguia concluir a tarefa, falhando.

Então, ao aumentar o contexto de 32 mil para 256 mil, ele consegue manter isso na memória e passar nesse teste específico.

E vimos que a taxa de sucesso desse job específico dobrou.

Isso mostra que até mesmo um desses pequenos fatores pode ter um grande impacto na adequação do modelo.

Então, como você faz suas próprias avaliações?

Então, aqui estão três sugestões rápidas.

Uma delas é usar um histórico do Git, ou seja, um monte de PRs que você já tem e que foram bem-sucedidos, e usá-los como entradas de comando para o modelo e ver como ele se sai.

Em seguida, você precisa de algo como um avaliador determinista que ajude a avaliar se a saída do modelo está correta ou não.

Temos dois exemplos muito bons disso.

Temos um compilador e testes de unidade.

O que for gerado pode ser executado por ele, que vai informar se você passou ou não na tarefa em questão.

E o terceiro é registrar trajetórias.

Portanto, ao executar um agente, você quer rastrear os diferentes comportamentos dele, ver onde ele tem sucesso e onde falha, e usar isso para avaliar se o modelo consegue interagir e usar ferramentas.

E quero que você tente mudar a forma como faz a pergunta, de "Esse modelo é tão inteligente quanto esse grande modelo de fronteira?"

Para: "É possível realizar essa tarefa neste hardware com essa configuração específica?"

Para descobrir isso, inventamos um framework chamado "Já chegamos lá?"

Ou AWTY.

E o princípio de todo esse framework é pontuar nesse eixo todas as tarefas em termos de prontidão.

Ou seja, o modelo em si, o mecanismo de inferência que você está usando, o harness e a configuração de hardware.

Isso vai indicar se você já está pronto.

Por exemplo, você pode analisar a confiabilidade de uma tarefa específica.

Se você executá-lo, digamos, 10 vezes seguidas, ele fará a mesma coisa todas as vezes?

Talvez você esteja analisando a latência.

Talvez você precise de uma resposta em tempo real.

Então, quais são seus limites para a velocidade de execução da tarefa?

E talvez você esteja analisando os requisitos de RAM.

Portanto, não é apenas a RAM que o dispositivo tem, é a RAM que o dispositivo, a parte que você pode usar, e os outros aplicativos e ferramentas que você também precisará executar nesse hardware.

Então, você pode usar 50% ou apenas 10% da RAM?

E você recebe esse tipo final de pontuação de disposição.

Se estiver verde, significa que a configuração está pronta.

Se estiver laranja, amarelo ou vermelho, talvez seja necessário mudar algo na configuração.

Talvez você precise de um acelerador mais rápido para reduzir a latência ou de um modelo maior e mais capaz.

Então, sugiro que você dê uma olhada nisso.

No momento, temos uma prévia e gostaríamos de receber seu feedback sobre a utilidade dessa ferramenta.

A Zoe vai falar um pouco mais sobre como configuramos algumas das avaliações mais tarde, mas agora vou passar a palavra para o Jose, que vai mostrar uma maneira muito rápida de começar a usar o Gemma 4.

Obrigado, Ian.

Então, sim, a maneira mais rápida de testar o Gemma 4 hoje é pelo Android Studio.

Vou mostrar como.

Vamos mudar para o laptop, por favor.

Isso aí.

Se eu acessar a página de provedores de modelos nas configurações e selecionar o Gemma, você terá uma ideia bem clara do tamanho de cada modelo.

Só preciso baixar os modelos no meu disco rígido.

Isso abre ou inicia um servidor llama.cpp, que é configurado corretamente para você desde o início.

Mas você também pode usar seu próprio servidor llama.cpp, Ollama ou LM Studio, o que preferir.

Para isso, basta acessar esta página e adicionar um provedor local.

Além disso, faz muito sentido usar modelos pequenos por um provedor remoto.

Então, você pode adicionar um aqui, desde que seja compatível com a OpenAI ou a Anthropic.

Certo, vamos ver.

Para selecionar um modelo no Android Studio, use este menu suspenso.

Com o Gemma 4 26B selecionado, posso perguntar: "O que é um ViewModel?"

Ok.

Uma coisa muito importante que você precisa lembrar é que, sempre que você muda de modelo, toda a conversa é enviada novamente para o novo modelo desde o início.

Portanto, se você gerar uma conversa muito longa com um modelo e quiser mudar para um novo, provavelmente deverá iniciar uma nova conversa, compactá-la ou algo assim.

Agora, vamos voltar aos slides e à Zoe para aprender sobre os diferentes fluxos de trabalho que você pode executar com modelos pequenos.

Muito obrigado, Jose, e obrigado, Ian, pela visão geral dos modelos Gemma e por nos dizer se já chegamos lá ou não.

Já vimos os tipos de modelos que existem e as especificações deles. Agora, vamos entender quais tipos de tarefas eles podem realizar.

O primeiro tipo de trabalho que você provavelmente já faz são os fluxos de trabalho de programação, como depuração ou solução de problemas, ou algo que, tenho certeza, todos, ou pelo menos eu, vamos sentir muita falta de fazer manualmente, que é aumentar a cobertura de testes.

Certo?

Então, essas são algumas das coisas que tenho certeza de que todo mundo já faz, provavelmente sem perceber.

Mas eu gostaria de incentivar você a pensar além disso, certo?

Considerando que os modelos pequenos podem ter pesos abertos e ser executados localmente, o que poderia economizar seu tempo?

Certo?

Estamos falando de não usar o foguete, então por que estamos usando um cérebro para isso?

Se pudéssemos ir além disso, o que os modelos pequenos poderiam fazer?

Quais são alguns fluxos de trabalho em que você poderia usá-los para facilitar sua vida e ter mais tempo para fazer coisas que, sei lá, você gostaria de fazer mais?

Por exemplo, garantir que a documentação esteja sempre atualizada com as mudanças feitas, que você tenha testes de regressão automáticos que façam parte de um gancho de pré-commit ou até mesmo que o contexto que o agente recebe como parte dos fluxos de trabalho esteja otimizado para ele e funcione ainda mais rápido.

Esses são alguns exemplos, certo?

No fim das contas, o céu é o limite, ou a arquitetura é o limite, e há muitas maneiras de implementar isso.

Mas, mesmo com as especificações, as ferramentas e os fluxos de trabalho, você ainda não sabe por onde começar?

É para isso que servem os comparativos de mercado.

E, como o Ian disse, um ranking genérico, especialmente um para Python, não vai dizer muito sobre se um modelo pequeno será útil para seus fluxos de trabalho do Android.

Assim como uma broca para drywall não diz muito sobre uma broca para concreto.

Mas você precisa investir nas suas próprias avaliações.

É importante investir no teste da sua própria arquitetura, mas, antes de fazer isso, talvez você não queira colocar todos os recursos.

Isso leva tempo, dinheiro e esforço. Por isso, analisar comparativos de mercado disponíveis publicamente pode dar uma ideia e uma lista curta antes de você decidir investir nas suas próprias avaliações.

E há três coisas que você deve analisar ao avaliar o comparativo de mercado, certo?

É um pouco meta, mas, basicamente, a primeira coisa é: qual é o tipo de tarefa que esse modelo está fazendo?

O nível de especificação.

Ela se parece com o tipo de tarefa que você vai dar a ela?

O segundo seria o escopo da tarefa.

É escrever documentação, resolver uma solicitação de envio ou algo que se parece com o tipo de trabalho que você faz?

Por fim, a complexidade do sistema é semelhante à complexidade que você vai fornecer?

E é aqui que podemos ver por que um comparativo de mercado do Python não é muito representativo do Android.

Por isso, criamos o Android Bench, um benchmark que captura o ecossistema Android e o trabalho do Android.

A primeira versão tem 100 tarefas do Android do tamanho de uma solicitação de envio, e você pode executá-la hoje mesmo pelo Harbor para verificar qualquer combinação de agente, modelo e habilidade.

Lançamos a versão 2.0 com tarefas mais complexas e de longa duração para entender as capacidades dos modelos de fronteira em trabalhos como os que você atribui a eles hoje.

Agora, vou passar a palavra para o Jose, que vai mostrar os resultados que conseguimos com isso e algumas maneiras de otimizar o trabalho com modelos pequenos.

Ok, obrigada, Zoe.

Vamos analisar as tarefas que um modelo pequeno pode resolver e onde ele começa a ter dificuldades.

Vamos definir arbitrariamente quatro categorias de tarefas: pequenas, médias, grandes e de longo alcance.

As tarefas de longo alcance são aquelas que podem levar dias ou semanas para serem concluídas por um ser humano.

Por exemplo, uma migração, uma grande refatoração e, spoiler, não é possível fazer isso com um modelo pequeno.

Pelo menos não de uma vez.

Vamos falar sobre isso mais tarde.

Certo, tarefas pequenas.

São jobs que exigem a leitura e a gravação de um ou dois arquivos e não exigem muito conhecimento.

Por exemplo, modelos pequenos são muito bons no Compose, pelo menos no básico.

Por exemplo, deve haver 8 dp entre os elementos, use um tema em vez de cores fixadas no código ou extraia strings.

Essas são tarefas muito fáceis para um modelo pequeno.

Este, no entanto, aborda um tópico mais avançado, mas a tarefa ainda é fácil.

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

A dificuldade, nesse caso, é sobre o escopo, não sobre o conhecimento.

O comando informa qual elemento combinável precisa ser otimizado e o que há de errado com ele: está sendo recomposto em cada frame.

Isso facilita o trabalho até mesmo para um modelo pequeno, como o Gemma 4.

Nesse caso, levou três minutos e é uma mudança de uma linha.

Certo.

Acho que já temos uma boa ideia do que é um modelo pequeno.

Vamos ver o que é uma tarefa pequena.

Vamos analisar as tarefas médias.

Os modelos pequenos devem ser capazes de fazer a maioria delas.

Nesta tarefa, no app Pocket Casts, o user agent está ausente em uma solicitação, e também há um erro na lógica de nova tentativa.

Este é um pouco mais difícil porque, primeiro, estamos solicitando duas coisas ao mesmo tempo, e não há dicas sobre onde elas estão na base de código.

Mas passou.

Levou 10 minutos.

Ele modificou três arquivos.

E, aliás, custou 6 centavos pelo OpenRouter.

Agora, vamos analisar uma tarefa que falhou no mesmo conjunto de dados.

Este é um exemplo do Now in Android com um relatório ou comando bastante abrangente, mas que não menciona um nome de classe ou um arquivo. Por isso, o agente precisa se esforçar mais para entender a arquitetura do app, a camada de dados, o mecanismo de sincronização e, neste caso, etc. Portanto, nessa execução específica, ele falhou.

Tudo foi implementado quase corretamente, mas ele assumiu que o valor da sincronização inicial seria -1, mas na verdade é 0.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

É isso.

Esse bug teria sido detectado se o agente tivesse executado os testes de unidade atuais.

Isso mostra como os modelos menores, em geral, tendem a parar um pouco antes dos modelos de fronteira.

Pedimos ao agente para corrigir o problema, não para verificá-lo.

Portanto, talvez seja melhor modificar a tarefa para que ela contenha uma etapa de verificação.

Vamos falar sobre isso em breve.

Então, vamos falar sobre tarefas grandes.

Cerca de metade das tarefas grandes, nessa definição, são aprovadas todas as vezes.

Alguns dos que falham são, na verdade, muito longos e complexos para um modelo pequeno, não há muito o que fazer.

Mas, em alguns casos, quando você analisa o que realmente aconteceu, percebe que o modelo estava 90% correto.

Vamos escolher uma delas.

Escolhi este porque ele é instável.

Ele passa em cerca de metade das vezes em que é executado.

Por isso, considero que esse é o limite do que um modelo pequeno pode fazer.

Ou, pelo menos, um modelo de abril.

É sobre a análise de URLs inválidos na biblioteca Coil.

Como você pode ver, a descrição da solicitação de envio é bem abrangente, o que é ótimo, mas não atendeu a um requisito.

Vamos analisar isso rapidamente.

Todas as execuções verificaram codificações e erros típicos de URL, mas apenas algumas, metade delas, adicionaram testes para caracteres mal codificados, então esse caso de teste está ali.

As que não foram aprovadas na avaliação.

Todas as execuções são quase perfeitas, mas isso mostra que os modelos pequenos nem sempre dão o passo extra.

Eles seguem instruções, mas não tentam impressionar você como os modelos de fronteira.

Você sabe como definir o esforço em um agente hoje em dia?

Basta considerar que ele está definido como muito baixo quando você usa um modelo pequeno.

Então, vamos definir tarefas grandes como aquelas que podem ser concluídas por modelos pequenos em cerca de 50% do tempo, que é o que o Gemma 4 31B pode alcançar em relação ao conjunto de dados do Android Bench v1, que é o que a Zoe mencionou antes.

Antes de falar sobre tarefas de longo alcance, podemos fazer algo para ajudar os modelos menores com elas?

Com certeza, e essas coisas não exigem nenhum esforço.

Primeiro, se você usa um modelo como o Gemma 4 localmente, como o Ian mencionou, verifique se ele está configurado corretamente.

Por exemplo, se você usar o Ollama para disponibilizar o Gemma 4, ele vai usar por padrão uma janela de contexto de 32.000 tokens, quando na verdade ele é compatível com oito vezes mais.

Se você usar o Gemma 4 pelo Android Studio, não vai precisar configurá-lo.

Ele vem configurado corretamente por padrão.

No nosso conjunto de avaliações, ativar o contexto completo fez os resultados passarem de 26% para 53%.

Em seguida, use a CLI do Android, a ferramenta de CLI do Android, especialmente para pesquisar documentação.

Isso nem sempre se aplica, já que os modelos são muito bons no básico, mas sempre que você usa uma API nova ou de nicho, ter a documentação é fundamental.

Muito melhor do que usar ferramentas de pesquisa na Web, na nossa experiência.

Em seguida, adicione dicas de verificação.

Já conversamos sobre isso.

Informe ao modelo como executar testes, quais tipos de testes estão disponíveis, como gerenciar emuladores etc. Você pode fazer isso em um arquivo AGENTS.md, o que disponibilizaria as instruções para todos os agentes, mas isso é bom de qualquer forma.

Você precisa ter.

Mas também tome cuidado com arquivos AGENTS.md muito longos, porque se você testar agentes diferentes, vai notar que alguns deles têm comandos de sistema e descrições de ferramentas enormes, o que parece prejudicar o desempenho de modelos pequenos.

Tentamos executar esses comparativos com o OpenCode, mas o desempenho foi muito menor do que o do pi, provavelmente porque ele usa descrições de ferramentas e comandos do sistema maiores.

Em seguida, adicione e remova habilidades.

Os modelos pequenos podem precisar de um empurrãozinho ao usar APIs novas e de nicho, mas é melhor não preencher o contexto deles com habilidades gerais do Compose, por exemplo.

E as tarefas de longo alcance?

São tarefas que abrangem dezenas de arquivos, exigem decisões arquitetônicas sérias e normalmente são processadas por um modelo de raciocínio que cria um plano e inicia um grupo de subagentes que executam as diferentes tarefas.

Exemplos de tarefas de longo alcance incluem migrar um app inteiro de XML para o Compose, criar um app complexo do zero ou converter apps multiplataforma em Android nativo.

Se analisarmos os resultados do Android Bench V2, que se concentra exclusivamente em tarefas de longo alcance, vemos que os modelos de fronteira estão pontuando de 3% a 40%.

Portanto, para modelos pequenos, acho que é seguro dizer que está fora do alcance deles.

No entanto, rotear a análise inicial por um modelo de fronteira e, em seguida, distribuir tarefas mais simples para modelos menores seria muito mais eficiente em termos de tokens e créditos.

Vamos ver como fazer isso.

De volta para Zoe.

Muito obrigado, Jose.

Vamos falar sobre a cascata, mas antes de mostrar algumas maneiras ou de nos aprofundarmos nisso, quero dar um passo atrás e mostrar outras maneiras de como a orquestração de diferentes modelos pode ajudar você.

Então, a orquestração pode, por exemplo, ajudar você a nunca ser bloqueado, certo?

Portanto, se um provedor ficar indisponível, se você atingir um limite de taxa de API ou se estiver em um avião ou trem, como o Ian estava dizendo, é possível configurar um modelo de fallback e fazer com que, seja on-line ou localmente, você possa continuar se algo acontecer.

Outra coisa que você pode fazer com a orquestração é receber respostas melhores.

Por exemplo, você pode ter um modelo pequeno que trabalha sozinho e chama um consultor sempre que precisa de um pouco de suporte para receber ajuda.

Você também pode configurar um conselho em que diferentes tipos de modelos, ou modelos diferentes, executam a mesma tarefa ao mesmo tempo. Depois, você pode avaliar as diferentes respostas e como os pesos e vieses de cada modelo afetaram o resultado.

Você também pode usar um modelo separado como, digamos, os testes.

É como uma revisão por pares.

E você pode ver isso aqui.

E, claro, a orquestração pode ajudar você a ser econômico com algo como essa cascata.

Basicamente, você pode configurar manualmente, definindo um modelo para planejamento, outro para execução e um terceiro para testes.

Há várias maneiras de fazer isso, seja na nuvem ou configurando um proxy LiteLLM para fazer isso localmente.

Ou você pode usar um classificador para encaminhar automaticamente para o tipo certo de modelo com base na solicitação, que é a ideia de proxy que o Ian mencionou, mas automática.

Para encerrar, vamos voltar à pergunta que o Jose fez no início da conversa: qual é a diferença de qualidade e precisão entre modelos pequenos e modelos de fronteira?

E a resposta, como em muitos casos na ciência da computação, é: depende.

No entanto, eu gostaria de lembrar que isso é algo que você pode projetar.

Você pode fazer a diferença dependendo de como configurar e usar as peças.

A primeira parte é escolher a ferramenta certa, certo?

Há vários tipos de ferramentas.

Conheça e explore os dados, certo?

Depois, descubra para quais trabalhos eles são bons ou até mesmo quais trabalhos eles poderiam estar fazendo.

A segunda é ajustar o escopo que o modelo está recebendo para realizar o trabalho.

Por exemplo, as instruções para a tarefa, o contexto certo para a tarefa (e apenas o contexto certo) e maneiras de verificar o próprio trabalho.

Depois, é claro, você precisa definir, testar toda a configuração e não apenas o modelo isoladamente, porque isso vai fazer diferença e talvez os resultados que você está recebendo possam ser ajustados se você configurar com, digamos, uma configuração diferente de elementos.

No fim das contas, você precisa configurar ou criar suas próprias avaliações.

Por fim, você pode combinar a bicicleta e o foguete para nunca ter que escolher entre um ou outro e gastar de forma eficaz.

Mas o mais importante é que você pode continuar explorando, criando e se divertindo, certo?

E você pode começar hoje mesmo, definindo uma lista de modelos com o Android Bench e as descobertas que você tem lá, ou começando com o Gemma 4 no Android Studio.

Então, muito obrigado.