Flujos de trabajo de programación con agentes con modelos pequeños

Bien.

¡Hola!

Mi nombre es Jose y estoy aquí con Ian y Zoe.

Todos conocemos los LLM.

Los usamos para todo: encontrar recetas, resumir videos de YouTube y programar.

Existen LLM realmente grandes, como los modelos de Gemini, que son capaces de hacer cosas increíbles, pero en esta charla, hablaremos de los modelos de lenguaje pequeños.

También son LLM porque algo que tiene 4, 000 millones de algo no puede ser pequeño, pero de ahora en adelante haremos esta distinción: modelos de frontera y modelos de lenguaje pequeños, el cohete y la bicicleta.

Analizaremos los modelos pequeños no necesariamente como una alternativa a los modelos de frontera, sino principalmente para complementarlos.

Exploraremos todos los beneficios de los modelos de lenguaje pequeños, en especial cuando son abiertos, tienen pesos abiertos y se pueden descargar, pero analicemos el costo por un segundo.

Para esta charla, ejecuté muchas comparativas, y una de ellas fue un conjunto de datos de 200 tareas de dificultad media y alta que usó casi 131 millones de tokens por menos de USD 9.

Usé Gemma 4 para esto, así que podría haberlo descargado y ejecutado en mi propio hardware de forma gratuita, pero lo ejecuté en una puerta de enlace comercial solo para hacer una comparación justa.

Entonces, ¿cuánto costaría un modelo de frontera?

Entre 20 y 200 veces más, según el almacenamiento en caché de tokens y otros factores.

Por lo tanto, la bicicleta podría no ser el medio de transporte más rápido, pero definitivamente es el más eficiente.

Así es.

Ahora, la pregunta obvia es: ¿cuál es la diferencia en cuanto a calidad y exactitud?

En este conjunto de datos en particular, Gemma 4 puede resolver el 53% de las tareas.

Esto significa lo siguiente:

Si usas un modelo de frontera para ejecutar estas tareas de la izquierda, podría ser excesivo.

Y si usas un modelo pequeño para ejecutar estas tareas de la derecha, tendrás que guiarlo hacia una solución o usar uno más grande.

En esta charla, queremos ayudarte a aprovechar al máximo cada token.

Zoe te guiará para elegir un modelo pequeño, e Ian hablará sobre los modelos de Gemma para que entiendas cómo enmarcar tu pensamiento sobre lo que pueden habilitar.

Luego, te mostraré rápidamente cómo probar Gemma 4 en Android Studio y, por último, cómo incorporar modelos pequeños en tus flujos de trabajo diarios y también comparativas reales de desarrollo de Android para ayudarte a comprender lo que pueden hacer.

Ahora, le cedo la palabra a Zoe.

Muchas gracias, José.

Por lo tanto, usar un solo modelo para todo es un poco como usar un mazo para romper una nuez, ¿verdad?

Es eficiente, pero un poco desproporcionado.

Por lo tanto, cuando piensas en modelos pequeños, es casi como si estuvieras expandiendo tu conjunto de herramientas.

Para saber qué debes incorporar a tus flujos de trabajo, debes abrir el conjunto de herramientas, ver qué hay disponible, cuáles son sus especificaciones y para qué sirven.

Por lo tanto, para elegir modelos pequeños, debes conocerlos.

Y el tipo de modelo en el que la mayoría de las personas piensan cuando piensan en un modelo de lenguaje es un modelo de lenguaje autorregresivo.

Esto es autorregresivo porque, en función de una entrada dividida en tokens, elige el siguiente token más probable de una lista de candidatos.

Luego, ese token siguiente más probable que se eligió vuelve a la entrada, y así sucesivamente, lo que permite producir respuestas coherentes y que suenan inteligentes, pero tiene algunas advertencias, incluidos, sin limitaciones, que funciona de forma lineal.

Por lo tanto, podemos trabajar de forma no lineal.

Un modelo de difusión tiene el mismo enfoque, pero funciona con un bloque de tokens a la vez.

Es casi como un boceto que se va enfocando.

En este caso, DiffusionGemma trabaja con fragmentos de 256 tokens a la vez.

Por lo tanto, básicamente, obtienes un pase que funciona en todo el bloque y que puede generar resultados con menos latencia.

Entonces, nuestro conjunto de herramientas tiene modelos que pueden escribir, ¿verdad?

Todo lo contrario.

Básicamente, los modelos de embeddings convierten objetos como una imagen, un texto o cualquier otro concepto en un vector.

Esto nos proporciona una asignación de, digamos, coordenadas en un espacio de alta dimensión que nos permite comparar dos cosas conceptualmente.

Por ejemplo, si un hot dog es un sándwich, es probable que se acerquen o terminen en un espacio cercano.

Por eso, poder comprobar si dos conceptos están relacionados se convierte en, digamos, un poco de matemática en lugar de un pase de modelo, que también es un poco de matemática, pero este paradigma va aún más allá, ¿verdad?

Y hay modelos más pequeños y especializados que son capaces de hacer un trabajo, y lo hacen muy bien.

Por ejemplo, tenemos modelos de funciones que convierten el lenguaje natural en llamadas a la API, modelos de visión que, por su nombre, seguro sabes lo que pueden hacer, o, por ejemplo, clasificadores que pueden dar puntuaciones a una entrada en función de ciertos parámetros.

Bien, hay muchas opciones para elegir, ¿verdad?

Y hay muchos tipos diferentes de modelos, y tienen diferentes dimensiones, diferentes tamaños, diferentes ventanas de contexto, diferentes capacidades, diferentes espacios en memoria, y una vez que abres la caja de herramientas y tienes en cuenta todas las posibilidades, bueno, las opciones crecen exponencialmente hasta el punto de que cualquier fanático del DIY estaría absolutamente extasiado o congelado por la parálisis de decisión.

Entonces, ¿cómo se elige un modelo pequeño?

Comencemos por abrir una caja de herramientas de modelos pequeños abiertos que se pueden ejecutar de forma local: los modelos de Gemma.

Ian, te cedo la palabra.

Gracias, Zoe.

Como mencionó José al principio, un modelo de lenguaje pequeño puede realizar alrededor del 50% de las tareas de forma inmediata.

Pero ¿por qué específicamente elegirías un modelo local?

Por lo tanto, se reduce a unos cuatro aspectos.

El primero es la privacidad.

Por ejemplo, podrías tener claves de API, código de propiedad o cosas que, literalmente, no pueden salir de tu laptop.

La segunda es la latencia.

Por lo tanto, cuando el modelo se carga en la memoria, ya sea de gráficos o unificada, obtienes una respuesta en cuanto termina de procesarse.

Por lo tanto, no hay tiempos de ida y vuelta a los servidores ni costos de latencia adicionales.

El siguiente es el costo marginal cero.

Por lo tanto, los modelos son rentables cuando puedes controlar dónde se ejecutan.

Por lo tanto, en el caso de ejecutar algo en una máquina local, por ejemplo, podría estar realizando reintentos adicionales en un bucle de error.

No tiene costo, y no hay ningún tipo de costo sorpresa de la API para esa parte.

Por último, el cuarto es el acceso sin conexión.

Imagina que puedes usarlo en un avión, un tren, un autobús o el metro, básicamente en cualquier lugar donde tengas el modelo ejecutándose en tu hardware.

Eso suena genial, pero hay dos factores importantes que debemos tener en cuenta cuando tomamos estas decisiones.

Por lo tanto, uno es la memoria y el segundo es la velocidad.

Si observas este diagrama, en los dos modelos de la parte inferior, el de 26B y el de 31B, ambos requieren más de 50 GB de RAM de video para ejecutarse en BF16, que es una cuantización de 16 bits.

Por lo tanto, el desafío aquí es que no cabría en mucho hardware.

Por lo tanto, realizamos un proceso llamado cuantización que reduce esa precisión, por ejemplo, de 4 bits a un número de punto flotante.

Ahora es un poco más razonable.

Estamos hablando de 14 GB y 17 GB, ¿verdad?

Ahora, eso cabría en una Mac con memoria unificada.

Ahora, el desafío con esto es que, en la cuantización posterior al entrenamiento normal, lo que sucederá es que, a medida que comprimas esos pesos, perderás un poco de la exactitud del modelo base, y tenemos una técnica para combatir eso.

Se llama entrenamiento con cuantización.

Cuando hacemos eso, a medida que se entrena el modelo, se entrena para saber que se va a ejecutar en estos tamaños más pequeños y, por lo tanto, hay menos pérdida en comparación con eso.

Por lo tanto, obtenemos una reducción del 75% en los requisitos de RAM, y ahora puede caber en esos dispositivos.

Y vamos un paso más allá.

Por lo tanto, los enfoques de cuantización para dispositivos móviles que tenemos y que funcionan en muchos teléfonos celulares pueden reducir aún más esos modelos, ya que comprenden cómo funcionan todas las diferentes capas y en qué tamaños pueden operar.

Por lo tanto, tenemos una especie de bolsa de cuantización mixta.

Por lo tanto, pasamos de un Gemma E2B de 11.4 GB a uno de 1.1 GB.

Por lo tanto, ahora es mucho más razonable en teléfonos de gama media a alta.

La siguiente es la velocidad.

Por lo tanto, cuando usas un modelo autorregresivo, como mencionó Zoe, predices el siguiente conjunto de tokens.

Por lo tanto, en una tarea de programación, es posible que muchos de estos tokens sean bastante predecibles, como el final de la firma de un método o una llave de apertura o cierre.

Por lo tanto, lo que puedes hacer es usar una técnica llamada decodificación especulativa.

Esto usará un modelo de redactor más pequeño para predecir una cantidad de tokens que, luego, se validarán con un modelo más grande.

Y la razón por la que esto funciona en la arquitectura de Gemma 4 es que comparten la misma caché de KV.

Por lo tanto, piensa en esto como la memoria a corto plazo del modelo.

Por lo tanto, lo que sucederá es que un modelo de borrador pequeño predecirá tres o cuatro tokens con anticipación, y el modelo más grande analizará esa misma caché de KV y, básicamente, validará el resultado.

Esto puede dar como resultado una aceleración de aproximadamente 3 veces en términos de rendimiento sin pérdida real de calidad del resultado del modelo, porque solo predice cosas y, luego, decide si se aprueba o no, si es correcto o no.

Por lo tanto, una vez más, depende un poco de la tarea que estés realizando.

Por lo tanto, esto no funciona tan bien en cosas como la escritura creativa, porque hay más variabilidad, pero sí funciona muy bien en cosas predecibles, como las estructuras JSON y la programación.

Entonces, ¿cómo evaluarías uno de estos modelos?

Entonces, lo más obvio que podrías hacer es consultar una comparativa como, por ejemplo, LiveCodeBench o MMLU, y ver una puntuación.

Pero eso solo te dará un indicador de alto nivel sobre la capacidad del modelo.

Lo que realmente debes hacer es evaluar toda la pila en la que se ejecuta.

Este es el modelo que estás usando, los pesos y el enfoque de cuantización, es la inferencia del entorno de ejecución, por lo que podrías usar algo como llama.cpp, Ollama o LiteRT, el arnés de agentes que estás usando, ya sea Pi, OpenCode o Antigravity, y, luego, la ventana de contexto, que es el espacio para todos los datos que quieres que tu modelo pueda procesar.

Y la combinación de todos estos factores determina si es viable.

Para darte un ejemplo rápido, estábamos haciendo algunas pruebas con Gemma 4 en Android Bench y ejecutando una versión de Ollama con un contexto predeterminado de 32,000 tokens.

Y lo que descubrimos es que, en una de las pruebas, en la que se buscaba un error, la compactación del arnés del agente movía ese archivo fuera de la memoria y, luego, el modelo no podía completar la tarea y fallaba.

Por lo tanto, con solo aumentar el contexto de 32,000 a 256,000, ahora puede mantenerlo en la memoria y el modelo puede aprobar esa prueba en particular.

Y vimos que se duplicó la tasa de éxito en ese trabajo en particular.

Esto demuestra que incluso uno de estos pequeños factores puede tener un gran impacto en la idoneidad de este modelo.

Entonces, ¿cómo puedes realizar tus propias evaluaciones?

Estas son tres sugerencias rápidas.

Por ejemplo, podrías tomar un historial de Git, es decir, un montón de PR que ya tienes y que son exitosas, y usarlas como entradas de instrucciones para el modelo y ver qué tan bien se desempeña con ellas.

Luego, necesitas un calificador determinista que te ayude a evaluar si el resultado del modelo es correcto o no.

Tenemos dos ejemplos muy buenos de eso.

Tenemos un compilador y pruebas de unidades.

Independientemente de lo que se genere, puedes ejecutarlo a través de eso, y te dirá si aprobaste o reprobaste, es decir, si tuviste éxito en esa tarea en particular.

Y el tercero es registrar trayectorias.

Por lo tanto, cuando ejecutas un agente, quieres poder rastrear los diferentes comportamientos que tiene, ver dónde tiene éxito y dónde falla, y puedes usar eso para evaluar qué tan bien el modelo puede interactuar y usar herramientas.

Y quiero que intentes cambiar el enfoque de la pregunta de, ya sabes, "¿Este modelo es tan inteligente como este gran modelo de frontera?"

A "¿Es posible realizar esta tarea en este hardware con esta configuración en particular?"

Para descubrirlo, inventamos un marco de trabajo llamado "¿Ya llegamos?".

O AWTY.

Y todo el principio de este marco de trabajo es calificar en ese eje todas estas tareas diferentes en términos de preparación.

Es decir, el modelo en sí, el motor de inferencia que usas, el arnés y, luego, la configuración del hardware.

Eso te indicará si ya estás listo.

Por ejemplo, podrías analizar qué tan confiable es esa tarea en particular.

Si lo ejecutas, por ejemplo, 10 veces seguidas, ¿hace lo mismo cada vez?

Es posible que estés observando la latencia.

Tal vez necesites que sea una respuesta en tiempo real.

Entonces, ¿cuáles son tus umbrales para la velocidad de realización de la tarea?

Y, luego, es posible que estés analizando los requisitos de RAM.

Por lo tanto, no se trata solo de la RAM que tiene el dispositivo, sino de la RAM que el dispositivo, la parte que puedes tomar, y las otras aplicaciones y otras herramientas que también necesitarás ejecutar en ese hardware.

Por lo tanto, ¿puedes ocupar el 50% o solo el 10% de la RAM?

Y obtienes este tipo final de nivel de recuperación.

Por lo tanto, si está en verde, significa que la configuración está lista para usarse.

Si es naranja, amarillo o rojo, significa que tal vez debas cambiar algo de la configuración.

Tal vez necesites un acelerador más rápido para una latencia más baja, o un modelo más grande que sea más capaz.

Por lo tanto, te sugiero que lo revises.

En este momento, tenemos una versión preliminar y nos encantaría recibir tus comentarios sobre la utilidad de esta herramienta.

Zoe explicará un poco más sobre cómo configuramos algunas de las evaluaciones más adelante, pero ahora le daré la palabra a José, quien les mostrará una forma muy rápida de comenzar a usar Gemma 4.

Gracias, Ian.

Por lo tanto, la forma más rápida de probar Gemma 4 hoy es, probablemente, a través de Android Studio.

Te mostraré cómo hacerlo.

Cambiemos a la laptop, por favor.

¡Muy bien!

Si voy a la página de proveedores de modelos en la configuración y selecciono Gemma, se puede ver claramente el tamaño de cada modelo.

Solo tengo que descargar los modelos en mi disco duro.

Esto abre o inicia un servidor de llama.cpp y lo configura correctamente desde el principio.

Pero también puedes usar tu propio servidor de llama.cpp, Ollama o LM Studio, lo que quieras.

Para ello, solo debes venir aquí y agregar un proveedor local.

Además, tiene mucho sentido usar modelos pequeños a través de un proveedor remoto.

Puedes agregar uno aquí, siempre que sea compatible con OpenAI o Anthropic, puedes conectarte a él.

Muy bien, veamos.

Por cierto, la forma de seleccionar un modelo en Android Studio es a través de este menú desplegable, obviamente.

Tengo seleccionado Gemma 4 26B y puedo preguntar: "¿Qué es un ViewModel?".

Bien.

Por lo tanto, algo muy importante que debes recordar es que, cada vez que cambias de modelo, toda la conversación se vuelve a enviar al nuevo modelo desde el principio.

Por lo tanto, si generas una conversación muy larga con un modelo y quieres cambiar a uno nuevo, probablemente deberías iniciar una conversación nueva, compactarla o lo que sea.

Ahora, volvamos a las diapositivas y a Zoe para conocer los diferentes flujos de trabajo que puedes ejecutar con modelos pequeños.

Muchas gracias, José, y gracias, Ian, por la descripción general de los modelos de Gemma y por decirnos si ya llegamos o no.

Ya vimos qué tipos de modelos existen y cuáles son sus especificaciones. Ahora, es cuestión de comprender qué tipos de tareas pueden realizar.

El primer tipo de tareas que, probablemente, ya estés haciendo son, ya sabes, flujos de trabajo de programación, como la depuración o la solución de problemas, o algo que, estoy seguro, todo el mundo, o, al menos, yo, extrañaré con mucho sarcasmo hacer a mano, que es aumentar la cobertura de las pruebas.

¿Cierto?

Estas son, ya sabes, algunas de las cosas que estoy bastante seguro de que todo el mundo ya está haciendo, incluso, probablemente, sin darse cuenta.

Pero me gustaría alentarte, o me gustaría alentarte a pensar más allá de eso, ¿verdad?

Teniendo en cuenta que los modelos pequeños pueden ser de pesos abiertos y ejecutarse de forma local, ¿qué podría ahorrarte tiempo?

¿Cierto?

Estamos hablando de no usar el cohete, así que ¿por qué usamos un cerebro para eso?

Entonces, si pudiéramos ir más allá, ¿qué podrían hacer los modelos pequeños?

¿En qué flujos de trabajo podrías incorporarlos para facilitarte la vida y darte más capacidad para hacer cosas que, ya sabes, tal vez quieras hacer más?

Por ejemplo, asegurarte de que tu documentación siempre esté actualizada con los cambios que realizaste, o asegurarte de tener pruebas de regresión automáticas que formen parte de un hook de preconfirmación, o incluso asegurarte de que el contexto que tu agente recibe como parte de tus flujos de trabajo esté optimizado para él y funcione aún más rápido.

Estos son algunos ejemplos, ¿verdad?

Y, al final del día, el cielo es el límite hasta cierto punto, o la arquitectura es el límite, y hay muchas cosas que podrías pensar sobre cómo implementarla.

Pero, con las especificaciones, las herramientas y los flujos de trabajo, ¿todavía no sabes por dónde empezar?

Bueno, para eso sirven las comparativas.

Y, como dijo Ian, una tabla de clasificación genérica, en especial una para Python, te dirá muy poco sobre si un modelo pequeño será útil para tus flujos de trabajo de Android.

Es como un taladro para paneles de yeso, que no te dice mucho sobre un taladro para concreto.

Sin embargo, deberías invertir en tus propias evaluaciones.

Deberías invertir en probar tu propia arquitectura, pero antes de hacerlo, tal vez no quieras poner todos los recursos.

Requiere tiempo, dinero y esfuerzo, por lo que consultar comparativas disponibles públicamente puede darte una idea y una lista breve antes de que decidas invertir en tus propias evaluaciones.

Hay tres aspectos que debes tener en cuenta cuando evalúes la comparativa, ¿verdad?

Es un poco meta, pero, básicamente, lo primero es saber qué tipo de tarea realiza este modelo, ¿verdad?

Qué tan específico es.

¿Se parece al tipo de tarea que le darás?

El segundo sería el alcance de la tarea.

¿Se trata de escribir documentación, resolver una solicitud de extracción o algo que se parece al tipo de trabajo que tienes?

Por último, ¿la complejidad del sistema es similar a la complejidad que vas a dar?

Y aquí es donde podemos ver por qué una comparativa de Python no será muy representativa de Android.

Por eso creamos Android Bench, que es una evaluación comparativa que captura el ecosistema Android y el trabajo de Android.

La primera versión tiene 100 tareas de Android de tamaño de PR, y puedes ejecutarla hoy mismo a través de Harbor para verificar cualquier combinación de agente, modelo y habilidad.

Lanzamos la versión 2.0 con tareas más complejas y de larga duración para comprender cuáles son las capacidades de los modelos de frontera para trabajar en tareas como las que les asignas hoy.

Ahora, le daré la palabra a José para que les muestre los resultados que obtuvimos con esto y algunas formas en que pueden optimizar el trabajo con modelos pequeños.

Bien, gracias, Zoe.

Muy bien, veamos las tareas que puede resolver un modelo pequeño y dónde empiezan a tener dificultades.

Y definamos, de forma arbitraria, cuatro categorías de tareas: pequeñas, medianas, grandes y de largo horizonte.

Las tareas de largo horizonte son aquellas que a un ser humano le puede llevar días o semanas completar.

Por ejemplo, una migración o una gran refactorización. Alerta de spoiler: no puedes hacer eso con un modelo pequeño.

Al menos, no de una sola vez.

Hablaremos de eso más adelante.

Bien, tareas pequeñas.

Son trabajos que requieren leer y escribir tal vez uno o dos archivos, y no requieren muchos conocimientos.

Por ejemplo, los modelos pequeños son bastante buenos en Compose, al menos en los conceptos básicos de Compose.

Por ejemplo, debe haber 8 dp entre los elementos, o bien se debe usar un tema en lugar de colores codificados o extraer cadenas.

Esas son muy fáciles para un modelo pequeño.

Sin embargo, este abarca un tema más avanzado, pero la tarea sigue siendo 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 }) {}
 }

En este caso, la dificultad se relaciona con el alcance, no con el conocimiento.

Por lo tanto, la instrucción nos indica qué elemento componible debemos optimizar y qué problema tiene: se vuelve a componer en cada fotograma.

Esto hace que el trabajo sea bastante fácil, incluso para un modelo pequeño, como Gemma 4.

En este caso, tardó 3 minutos y es un cambio de una sola línea.

Bien.

Creo que tenemos una idea bastante clara de lo que es un modelo pequeño.

Veamos una tarea pequeña.

Veamos las tareas de dificultad media.

Los modelos pequeños deberían poder realizar la mayoría de ellas.

En esta tarea, en la app Pocket Casts, falta el usuario-agente en una solicitud y también hay un error en la lógica de reintento.

Esta es un poco más difícil porque, primero, solicitamos dos cosas al mismo tiempo y no hay pistas sobre dónde se encuentran estas cosas en la base de código.

Pero ya pasó.

Tardó 10 minutos.

Se modificaron tres archivos.

Y, por cierto, costó 6 centavos a través de OpenRouter.

Ahora, veamos una tarea que falló en el mismo conjunto de datos.

Este es un ejemplo de Now in Android con un informe o una instrucción bastante completos, pero no menciona un nombre de clase ni un archivo, por lo que el agente debe esforzarse más para comprender la arquitectura de la app, la capa de datos, el mecanismo de sincronización y, en este caso, etc. Por lo tanto, en esta ejecución en particular, falló.

Todo se implementó casi correctamente, pero se supuso que el valor de la sincronización inicial sería -1, pero en realidad es 0.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

Eso es todo.

Este error se habría detectado si el agente hubiera ejecutado la prueba de unidades, las pruebas de unidades existentes.

Esto muestra cómo los modelos más pequeños, en general, tienden a detenerse un poco antes que los de vanguardia.

Solo le pedimos al agente que solucionara el problema, no que lo verificara.

Por lo tanto, tal vez deberíamos modificar la tarea para que contenga un paso de verificación.

También hablaremos de eso en un momento.

Muy bien, hablemos de las tareas grandes.

Aproximadamente la mitad de las tareas grandes, en esta definición, se aprueban siempre.

Algunas de las que fallan son demasiado largas y complejas para un modelo pequeño, por lo que no hay mucho que hacer en esos casos.

Sin embargo, hay algunos casos en los que, cuando miras lo que realmente sucedió, te das cuenta de que el modelo estaba en un 90% o 90% de avance.

Elijamos uno de ellos.

Elegí esta porque es inestable.

Se aprueba alrededor de la mitad de las veces que se ejecuta.

Por lo tanto, considero que esto está en la frontera de lo que puede hacer un modelo pequeño.

O, al menos, un modelo de abril.

Se trata de analizar URLs con formato incorrecto en la biblioteca de Coil.

Como puedes ver, la descripción de la PR es bastante completa, lo cual es genial, pero no incluyó un requisito.

Así que veámoslo rápidamente.

Todas las ejecuciones verificaron las codificaciones y los errores típicos de las URLs, pero solo algunas, la mitad de ellas, agregaron pruebas para caracteres mal codificados, por lo que ese caso de prueba está ahí.

Las que no lo hicieron, no aprobaron la evaluación.

Por lo tanto, todas las ejecuciones son casi perfectas, pero esto demuestra una vez más que los modelos pequeños no siempre dan el paso adicional.

Siguen instrucciones, pero no intentan impresionarte como lo hacen los modelos de frontera.

¿Sabes cómo puedes establecer el esfuerzo en un agente hoy en día?

Solo ten en cuenta que se establece en un valor demasiado bajo cuando usas un modelo pequeño.

Por lo tanto, definamos las tareas grandes como aquellas que los modelos pequeños podrían completar alrededor del 50% de las veces, que es lo que Gemma 4 31B puede alcanzar con el conjunto de datos de Android Bench v1, que es de lo que Zoe habló antes.

Antes de hablar de las tareas de largo horizonte, ¿podemos hacer algo para ayudar a los modelos pequeños con esas tareas?

Por supuesto, y estas cosas no requieren ningún esfuerzo.

Primero, si usas un modelo como Gemma 4 de forma local, como mencionó Ian, asegúrate de que esté configurado correctamente.

Por ejemplo, si usas Ollama para entregar Gemma 4, el valor predeterminado es una ventana de contexto de 32,000 tokens, cuando en realidad admite ocho veces más.

Por supuesto, si usas Gemma 4 a través de Android Studio, no tienes que configurarlo.

Viene configurado correctamente de forma predeterminada.

En nuestro conjunto de evaluaciones, habilitar el contexto completo hizo que los resultados pasaran del 26% al 53%.

A continuación, usa Android CLI, la herramienta de CLI de Android, especialmente para buscar documentación.

Esto no siempre se aplica, ya que los modelos son bastante buenos con los conceptos básicos, pero cada vez que uses una API nueva o de nicho, tener la documentación es clave.

Según nuestra experiencia, es mucho mejor que usar herramientas de búsqueda web.

Luego, agrega sugerencias de verificación.

Ya hablamos de esto.

Indícale al modelo cómo ejecutar pruebas, qué tipos de pruebas están disponibles, cómo administrar emuladores, etcétera. Puedes hacerlo en un archivo AGENTS.md, lo que haría que las instrucciones estén disponibles para todos los agentes, pero, de todos modos, eso es algo bueno.

Deberías tenerlo.

Pero también ten cuidado con los archivos AGENTS.md muy largos, porque si pruebas diferentes agentes, verás que algunos de ellos tienen instrucciones del sistema y descripciones de herramientas enormes, y parecen degradar el rendimiento de los modelos pequeños.

De hecho, intentamos ejecutar estas comparativas con OpenCode, y su rendimiento fue mucho menor que el de pi, probablemente porque usa descripciones de herramientas y mensajes del sistema más grandes.

A continuación, agrega habilidades, pero también quita algunas.

Es posible que los modelos pequeños necesiten un empujón cuando usen APIs nuevas y de nicho, pero es mejor no llenar su contexto con habilidades generales de Compose, por ejemplo.

¿Qué ocurre con las tareas de largo horizonte?

Son tareas que abarcan decenas de archivos, requieren decisiones de arquitectura importantes y, por lo general, las maneja un modelo de razonamiento que crea un plan y, luego, inicia un enjambre de subagentes que ejecutan las diferentes tareas.

Algunos ejemplos de tareas de largo horizonte serían migrar una app completa de XML a Compose, crear una app compleja desde cero o convertir apps multiplataforma en apps nativas para Android.

Si observamos los resultados de Android Bench V2, que se enfoca exclusivamente en tareas de largo horizonte, vemos que los modelos de frontera obtienen puntuaciones de entre el 3% y el 40%.

Por lo tanto, para los modelos pequeños, creo que es seguro decir que está fuera de su alcance.

Sin embargo, enrutar el análisis inicial a través de un modelo de frontera y, luego, enviar en cascada las tareas más sencillas a modelos más pequeños sería mucho más eficiente en términos de tokens y créditos.

Veamos cómo podemos hacerlo.

Volvamos con Zoe.

Muchas gracias, José.

Llegaremos a la cascada, pero antes de mostrarte algunas formas o de profundizar en esto, quiero dar un paso atrás y mostrarte otras formas en las que la organización de diferentes modelos puede ayudarte.

Por lo tanto, la organización puede, por ejemplo, ayudarte a que nunca te bloqueen, ¿verdad?

Por lo tanto, ya sea que veas que un proveedor deja de funcionar, que alcances un límite de frecuencia de la API o que estés en un avión o un tren, como decía Ian, puedes configurar un modelo de resguardo y hacer que, ya sea en línea o de forma local, puedas seguir adelante si ocurre algo.

Otra cosa que podrías hacer con la organización es obtener mejores respuestas.

Por ejemplo, podrías tener un modelo pequeño que trabaje por su cuenta y llame a un asesor cada vez que necesite un poco de asistencia para obtener esa ayuda.

También podrías configurar un consejo en el que diferentes tipos de modelos, o diferentes modelos, ejecuten la misma tarea a la vez y, luego, evaluar las diferentes respuestas y cómo los pesos y sesgos de cada modelo afectaron el resultado.

También podrías usar un modelo independiente para las pruebas.

Por lo tanto, es como una revisión por pares.

Y se podía ver a través de esto.

Por último, por supuesto, la organización puede ayudarte a ser rentable a través de algo como esa cascada.

Básicamente, puedes configurarlo de forma manual, por lo que podrías establecer un modelo para la planificación, otro para la ejecución y otro para las pruebas.

Hay varias maneras de hacerlo, ya sea en la nube o configurando un proxy de LiteLLM para hacerlo de forma local.

O simplemente podrías usar un clasificador para enrutarla automáticamente al tipo de modelo correcto según la solicitud, que es la idea de proxy que mencionó Ian, pero automática.

Para terminar, volvamos a la pregunta que hizo José al principio de la charla: ¿cuál es la diferencia en calidad y exactitud entre los modelos pequeños y los modelos de frontera?

Y la respuesta, como con muchas cosas en la informática, es que depende.

Sin embargo, esto es algo que me gustaría retomar contigo: es algo que puedes diseñar.

Esto es algo en lo que puedes marcar la diferencia según cómo lo configures y cómo juegues con las piezas.

Entonces, el primer paso es elegir la herramienta adecuada, ¿no?

Existen varios tipos de herramientas.

Conócelos, explóralos, ¿verdad?

Y, luego, averiguar para qué trabajos son buenos o incluso qué trabajos podrían estar haciendo.

El segundo es asegurarse de ajustar el alcance que tiene el modelo para realizar el trabajo.

Por ejemplo, la instrucción para la tarea, proporcionar el contexto adecuado para la tarea y solo el contexto adecuado para la tarea, y formas de verificar su propio trabajo.

Luego, por supuesto, debes configurar, probar toda la configuración y no solo el modelo de forma aislada, porque esto marcará la diferencia y tal vez los resultados que obtengas se puedan modificar si lo configuras con, digamos, una configuración diferente de elementos.

Y, al final del día, debes trabajar en configurar o crear tus propias evaluaciones.

Por último, puedes coordinar la bicicleta y el cohete para que nunca tengas que elegir entre uno y otro, y así invertir de forma eficaz.

Pero, lo más importante, puedes seguir explorando, creando y divirtiéndote, ¿verdad?

Puedes comenzar hoy mismo configurando una lista de modelos con Android Bench y los hallazgos que obtengas, o bien con Gemma 4 en Android Studio.

Muchas gracias.