🤖 machine learning

Sketch-and-Verify: Structured Inference-Time Scaling via Program Sketching

El artículo introduce Sketch-and-Verify, una estrategia de escalado en tiempo de inferencia rentable para modelos de código pequeños que supera al muestreo plano mediante la enumeración de bocetos algorítmicos diversos y su relleno con múltiples candidatos, aunque no puede reemplazar completamente el rendimiento de los niveles de modelos más potentes.

Autores originales: Shan Jiang, Zijian Yi, Chenguang Zhu

Publicado 2026-05-12

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Shan Jiang, Zijian Yi, Chenguang Zhu

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás intentando resolver un rompecabezas complicado, pero solo tienes un robot pequeño y económico para ayudarte. Este robot es rápido y barato, pero tiene un mal hábito: cuando intenta resolver un problema, casi siempre elige la misma forma incorrecta de pensar. Si le pides que lo intente 100 veces, simplemente te dará 100 versiones ligeramente diferentes de esa misma respuesta errónea.

Este es el problema que el artículo "Sketch-and-Verify" (Bosquejar y Verificar) intenta resolver. Ofrece una nueva forma de utilizar ese robot pequeño y barato para que pueda resolver más problemas sin necesidad de actualizarse a un robot gigante y supercostoso.

Así es como funciona el método, desglosado en pasos simples:

1. El Problema: "La misma vieja canción"

Por lo general, cuando le pedimos a una IA que escriba código, simplemente decimos: "Inténtalo 100 veces y dame la mejor".

El defecto: Si la idea "predeterminada" de la IA es incorrecta, pedirle que lo intente 100 veces es como pedirle a una persona que escriba 100 versiones diferentes de una mala canción. Podrías cambiar la letra o el tempo, pero la melodía sigue estando mal. La IA se queda atrapada en un bucle de cambios "cosméticos" (cambiar nombres de variables o formato) sin intentar nunca un enfoque fundamentalmente diferente.

2. La Solución: "El Arquitecto y el Constructor"

Los autores proponen un proceso de dos pasos llamado Sketch-and-Verify. En lugar de pedirle a la IA que escriba todo el código de inmediato, dividen el trabajo en dos roles:

Paso 1: El Arquitecto (El Bosquejo)
Primero, piden a la IA que actúe como un arquitecto. Dicen: "No escribas el código todavía. Solo enumera 5 formas completamente diferentes de resolver este problema."
- Ejemplo: "Estrategia A: Usar un mapa. Estrategia B: Ordenar la lista primero. Estrategia C: Usar un bucle."
- Una vez que la IA elige una estrategia, dibuja un "plano" aproximado (un bosquejo) con huecos. El plano tiene la estructura principal (las paredes y el techo) pero deja los detalles específicos (el color de la pintura, el pomo de la puerta) como espacios vacíos marcados con ??.
- Por qué esto ayuda: Esto obliga a la IA a detenerse y pensar en diferentes caminos antes de empezar a construir. Garantiza que la IA explore diferentes "barrios" de soluciones en lugar de simplemente dar vueltas en círculos en el mismo.
Paso 2: El Constructor (El Relleno)
Ahora, para cada plano, la IA actúa como un constructor. Rellena los huecos ?? para crear un programa completo.
- Si la IA hizo 5 planos (estrategias) y rellenó cada uno 10 veces, ahora tiene 50 programas completamente diferentes para probar.
- Debido a que los planos eran diferentes, estos 50 programas son estructuralmente diversos. No son solo reescrituras de la misma idea; son enfoques genuinamente diferentes.
Paso 3: El Inspector (Verificar)
Finalmente, ejecutan todos estos programas a través de una prueba. Mantienen los que funcionan y eligen el mejor.

3. Los Resultados: Barato vs. Costoso

Los investigadores probaron esto en una prueba de codificación estándar llamada HumanEval+ utilizando tres versiones de la IA Gemini de Google:

Lite: El modelo pequeño, barato y rápido.
Flash: El modelo mediano.
Pro: El modelo grande, costoso e inteligente.

Los Grandes Hallazgos:

Para el Robot Barato (Lite): El método "Sketch-and-Verify" fue un cambio radical.
- Si simplemente le pidieron al robot Lite que lo intentara 100 veces normalmente (Muestreo Plano), resolvió aproximadamente el 53% de los problemas difíciles.
- Si usaron el método Sketch-and-Verify (haciendo 10 planos y rellenándolos 10 veces), resolvió el 79% de los problemas difíciles.
- La Analogía: Es como decirle a un estudiante: "No escribas solo 100 ensayos sobre el mismo tema. Escribe 10 esquemas para 10 temas diferentes, luego rellénalos". El estudiante aprende más y obtiene una mejor calificación por la misma cantidad de esfuerzo.
Para el Robot Costoso (Pro): El método no ayudó mucho.
- El robot Pro ya es tan inteligente que su idea "predeterminada" suele ser correcta. Obligarlo a bosquejar diferentes estrategias en realidad lo hizo ligeramente peor porque se distrajo de su mejor instinto.
- La Regla: Si tienes un robot superinteligente, simplemente déjalo pensar con fuerza (Greedy). Si solo tienes un robot barato, usa Sketch-and-Verify para obligarlo a pensar creativamente.

4. La Conclusión

El artículo argumenta que Sketch-and-Verify es una forma inteligente de gastar poder de computación adicional cuando estás atascado con un modelo de IA más pequeño y barato.

No es magia: No hace que un modelo débil sea más fuerte que un modelo fuerte. Si puedes permitirte el modelo costoso "Pro", úsalo simplemente.
Es una estrategia: Si debes usar el modelo barato (por presupuesto o velocidad), este método es la mejor manera de extraer un rendimiento extra de él. Evita que la IA se estanque en una rutina y la obliga a explorar diferentes soluciones, muy parecido a una sesión de lluvia de ideas humana.

En resumen: No le pidas a la IA que intente más duro; pídele que intente diferente.

Resumen Técnico: Sketch-and-Verify: Escalado Estructurado en Tiempo de Inferencia mediante Bocetos de Programa

1. Enunciado del Problema

El artículo aborda una restricción operativa específica que enfrentan los profesionales: dado un modelo de código fijo, pequeño y rentable (por ejemplo, Gemini 3.1 Flash Lite) elegido por razones de latencia o presupuesto, ¿cómo se debe asignar una cantidad limitada de cómputo adicional en tiempo de prueba para mejorar la precisión?

Los enfoques estándar implican muestreo plano (generar $N$ programas candidatos independientes y seleccionar el mejor mediante ejecución). Los autores argumentan que el muestreo plano es ineficiente porque trata el espacio de programas como homogéneo. Los modelos de lenguaje grandes (LLM) a menudo asignan una masa de probabilidad alta a una única estrategia algorítmica "modal". En consecuencia, incluso con una temperatura alta o un $N$ grande, el conjunto de candidatos resultante carece de diversidad estructural; consiste principalmente en variantes cosméticas superficiales (diferentes nombres de variables, formato) de las mismas 2–3 estrategias. Si la estrategia predeterminada del modelo es incorrecta para un problema específico, es probable que el muestreo plano no logre descubrir la solución correcta, independientemente del número de muestras.

2. Metodología: SKETCHVERIFY

Los autores proponen SKETCHVERIFY, un método que reestructura el cómputo en tiempo de inferencia al factorizar el espacio de búsqueda en estrategia algorítmica y detalles de implementación. Inspirado en el bocetado de programas (Solar-Lezama, 2008, 2013) y trabajos previos sobre pruebas de compiladores impulsadas por LLM (OBsmith, Jiang et al., 2026b), el método opera en cuatro etapas:

Etapa 1: Generación de Bocetos (Prompting Primero Categoría)
- Enumeración de Categorías: Se solicita al LLM que enumere $K$ estrategias algorítmicas fundamentalmente diferentes (por ejemplo, "tabla hash", "dos punteros", "programación dinámica") en lenguaje natural. Esto obliga al modelo a razonar sobre el espacio de estrategias antes de codificar.
- Bocetado: Para cada estrategia, el LLM genera un programa parcial (un "boceto") donde el algoritmo, las estructuras de datos y el flujo de control están completamente especificados, pero los detalles de implementación (expresiones, condiciones, límites de bucle) se reemplazan por marcadores de posición ??. El objetivo es de 4 a 8 huecos por boceto.
- Innovación Clave: Este proceso de dos pasos evita que el modelo autoregresivo se fije en una única estrategia predeterminada, asegurando diversidad estructural entre los $K$ bocetos.
Etapa 2: Relleno
- Cada boceto válido se rellena $M$ veces para producir $K \times M$ programas candidatos completos.
- Para fomentar la variación dentro de un solo boceto, cada tercer relleno se condiciona al relleno anterior y se le pide que proporcione una implementación diferente.
Etapa 3: Verificación
- Los candidatos se filtran para asegurar la compilación y la ejecución sin fallos.
- Los candidatos supervivientes se ejecutan en $D$ entradas de prueba diversas (generadas mediante un enfoque similar basado en bocetos).
- Se genera una huella digital de ejecución para cada candidato: un vector de pares (estado, salida). Huellas digitales idénticas indican equivalencia comportamental.
Etapa 4: Selección
- Los candidatos se agrupan según sus huellas digitales de ejecución.
- Se selecciona el grupo más grande (que representa el consenso comportamental más robusto).
- Del grupo más grande, se devuelve el programa más corto (navaja de Occam). Esta regla de selección es idéntica a la línea de trabajo concurrente "Votación Semántica", aislando el beneficio de la generación estructurada del mecanismo de selección.

3. Contribuciones Clave

Marco SKETCHVERIFY: Introduce una política de rendimiento-costo dentro de un nivel que aplica el bocetado de programas al escalado en tiempo de inferencia. Factoriza el espacio de búsqueda en $K$ (estrategias) y $M$ (implementaciones), logrando una curva de escalado pass@1 más pronunciada que el muestreo plano en modelos débiles.
Análisis de Pareto Costo-Calidad: Proporciona un análisis riguroso en la referencia HumanEval+, específicamente reanalizando un "subconjunto difícil" de 19 problemas donde el modelo Lite de base (greedy) falla.
- Dentro del Nivel: El bocetado domina al muestreo plano con conteos de candidatos iguales. En el subconjunto difícil, Lite Sketch ( $K=2, M=5$ ) recupera el 58% de los problemas frente al 26% del muestreo plano ( $N=10$ ). Incluso con un aumento de presupuesto de 3 veces, el muestreo plano ( $N=50$ ) solo alcanza el 47%, perdiendo aún frente a la configuración de boceto más barata.
- Entre Niveles: El bocetado no reemplaza la actualización del modelo. Niveles más fuertes (por ejemplo, Gemini Pro greedy) dominan las configuraciones Lite+Sketch tanto en costo como en precisión. El bocetado es un complemento, no un sustituto, de la actualización del nivel del modelo.
Descomposición Primero Categoría: Propone una estrategia específica de prompting (enumerar nombres de estrategias antes de codificar) que es crítica para generar diversidad estructural en lugar de variantes cosméticas.
Caracterización del Compromiso K-vs-M: Mediante barridos de escalado, los autores muestran que la relación entre $K$ y $M$ es no monótona. Las asignaciones mixtas (por ejemplo, $K=2, M=5$ ) a menudo superan a los extremos puramente planos ( $K=1$ ) o puramente de boceto ( $M=1$ ), y simplemente aumentar $K$ no siempre produce ganancias lineales (por ejemplo, $K=5, M=10$ tuvo un rendimiento inferior a $K=2, M=5$ en algunas métricas).
Componibilidad: Demuestra que la generación estructurada se compone limpiamente con la selección basada en ejecución (Votación Semántica). El método actúa como un generador de un conjunto diverso de candidatos, mientras que el selector permanece agnóstico al método de generación.

4. Resultados Experimentales

Referencias: Evaluado en HumanEval+ (164 problemas de Python con suites de pruebas aumentadas). Se señala la validación entre referencias en MBPP+ y LiveCodeBench como trabajo futuro.
Modelos: Tres niveles de modelos Google Gemini (Pro, Flash, Flash Lite) con niveles de pensamiento bajos.
Rendimiento en Subconjunto Difícil (19 problemas donde Lite greedy falla):
- Lite Sketch ( $K=10, M=10$ ): 79% pass@1.
- Lite Flat ( $N=100$ ): 53% pass@1.
- Lite Sketch ( $K=2, M=5$ ): 58% pass@1 (a un costo menor que Flat $N=50$ ).
- Flash/Pro Greedy: Supera a todas las configuraciones Lite, confirmando que la capacidad del modelo es el principal impulsor de la precisión.
Curvas de Escalado: En el conjunto completo de HumanEval+, el muestreo plano de Lite se satura en ~89% pass@1. SKETCHVERIFY rompe este techo, alcanzando el 93% en $K=10, M=10$ . Sin embargo, en Flash y Pro, donde los modelos están cerca de la saturación, las ganancias del bocetado son marginales o inexistentes en comparación con la decodificación greedy.

5. Significado y Afirmaciones

El artículo posiciona a SKETCHVERIFY como una política de rendimiento-costo dentro de un nivel, no como una mejora universal de precisión.

Regla para el Profesional: Si está disponible un nivel de modelo más fuerte, utilice decodificación greedy en ese nivel. Si está restringido a un modelo más débil (debido a latencia, despliegue o presupuesto), SKETCHVERIFY es la forma más rentable de gastar cómputo adicional en tiempo de prueba.
Mecanismo: El método tiene éxito al forzar explícitamente la exploración de diferentes estrategias algorítmicas (diversidad estructural) en lugar de depender de la estocasticidad del muestreo plano para encontrar accidentalmente un nuevo enfoque.
Limitaciones: Los autores reconocen limitaciones que incluyen la dependencia de una sola familia de modelos (Gemini), un solo nivel de pensamiento, y el hecho de que la calidad del boceto está limitada por la propia distribución de estrategias del modelo (si el modelo no puede concebir la estrategia correcta, el bocetado no puede generarla). También señalan una sobrecarga de ~7% en tokens para la fase de generación de bocetos.

El artículo concluye que, aunque el bocetado es altamente efectivo para modelos débiles que luchan con la diversidad estratégica, no es una panacea para modelos que ya han alcanzado su techo de capacidad o para problemas donde la estrategia correcta está completamente fuera del conocimiento latente del modelo.