IA local en código: completar una base vs crear

En el Banco IT Lab, tres de diez modelos locales completan una base existente con huecos marcados y superan las seis etapas del juez. Creando la aplicación desde cero, ninguno de los diez locales supera el criterio; cuatro modelos de pago se miden aparte.

• Sobre la base existente, tres modelos locales superan las seis etapas, entre 16,8 y 43,5 s por corrida.
• Desde cero, los diez locales se detienen antes de la última etapa; dos modelos de pago aprueban sus dos pasadas.
• A juicio de IT Lab, lo local sirve para completar y mantener código; crear desde cero exige revisión obligatoria.

La pregunta de negocio

Una empresa con equipo de desarrollo necesita saber para qué trabajo puede usar un modelo que corre dentro de su infraestructura, sin enviar código a un proveedor. Mantener un sistema y escribir un módulo nuevo son tareas distintas; el banco las mide por separado.

Qué mide la prueba y por qué representa trabajo real

Las dos pruebas usan la misma aplicación, con motor en Rust y API web en Ruby on Rails, de modo que el trabajo cruza dos lenguajes.

• Completar sobre base existente. El sistema ya existe y tiene huecos marcados: el modelo implementa la lógica faltante del motor y las piezas que faltan en la capa web.
• Crear desde cero. No hay esqueleto. El modelo diseña y escribe el motor y el puente web, y entrega exactamente los archivos pedidos.

En ambas, los archivos de prueba los fija el laboratorio y el instrumento invalida las corridas que no respetan las reglas de entrega. El contenido del encargo no se publica.

Cómo se aprueba

El juez es un programa determinista, sin un modelo evaluando a otro, y funciona por etapas encadenadas (compilación, comportamiento, pruebas de la capa web y prueba de extremo a extremo): se detiene en la primera que falla. La prueba sobre base existente tiene seis etapas; la prueba desde cero, cinco.

Así el resultado indica dónde se rompió el trabajo: "no entregó archivos", "no compila", "compila pero no cumple el comportamiento pedido" y "el motor funciona y la capa web falla" son fallos distintos. Una salida truncada deja de existir como entrega.

Resultados: completar sobre base existente

Diez modelos locales, una sola pasada por modelo, criterio de aprobación: superar las seis etapas. Banco IT Lab, edición 1.

Los dos que no entregaron nada fallan por causas distintas: uno agotó su presupuesto de salida antes de escribir archivos, un fallo de presupuesto y no de comprensión; el otro devolvió contenido inutilizable. Una nota numérica los habría confundido.

Un ensayo en modo equipo, con varios agentes coordinados, no arrojó resultado concluyente.

Resultados: crear desde cero

Una pasada por modelo local; dos pasadas por modelo de pago salvo indicación. Criterio de aprobación: superar las cinco etapas. Banco IT Lab, edición 1.

Modelos locales, agregados.

Ningún modelo local supera el criterio. El más avanzado compila, pero su código no hace lo pedido.

Modelos de pago. Las dos pasadas de gpt-6-luna y de muse-spark-1.3 corresponden a una configuración con razonamiento desactivado y otra con razonamiento bajo.

Sonda de razonamiento. En diez corridas locales con razonamiento medio, el contenido entregado fue de cero caracteres, porque el razonamiento consumió todo el presupuesto de salida. Esta sonda se informa aparte y no forma parte de la pasada oficial.

Qué implica para una empresa chilena

A juicio de IT Lab:

• Qué automatizar. Completar y mantener código sobre una base existente con pruebas ya escritas: hay modelos locales que lo superan en menos de un minuto, sin que el código salga de la empresa.
• Qué revisar. Todo módulo creado desde cero exige revisión humana obligatoria de los entregables, incluso si el código compila. Esta prueba mostró código que compila y no hace lo pedido.
• Qué definir antes. El formato de entrega, con archivos y rutas explícitos: una no aprobación puede deberse al empaque y no al código.
• Cuándo pagar. Si el código puede salir hacia un proveedor, gpt-6-luna y muse-spark-1.3 aprobaron en ambas pasadas; la decisión depende de riesgo y volumen.

Preguntas frecuentes

¿Puede una IA local programar? Sobre una base existente con huecos, tres de diez modelos locales superan las seis etapas del juez. Creando la aplicación desde cero, ninguno de los diez lo logra.

¿Para qué sirve hoy en un equipo de desarrollo? A juicio de IT Lab, para completar y mantener código; crear desde cero exige revisión obligatoria.

¿El código sale de la empresa? No con un modelo local: corre dentro de la infraestructura de la empresa, sin enviar código a un proveedor.

¿Qué tan rápido trabaja? Los tres modelos locales que superan las seis etapas lo hacen entre 16,8 y 43,5 s por corrida.

Limitaciones y alcance

• Una sola pasada por modelo local y caso, y dos por modelo de pago salvo indicación; las diferencias pequeñas son ruido.
• La pasada oficial se informa aparte de la sonda.
• Los jueces por etapas solo permiten comparar dentro del mismo encargo y con el mismo juez; un resultado aquí no se extrapola a "Rust en general".
• Tope de memoria de GPU de las corridas locales: 15,5 GiB.
• "Razonamiento desactivado" no es homogéneo entre familias de modelos y no se compara entre ellas.
• El banco no mide costos. Operar IA local implica costos reales (energía, inversión inicial en hardware, mantención y tiempo) y a juicio de IT Lab, los precios actuales de los servicios de pago pueden no reflejar su costo real.
• Medición de IT Lab sobre un equipo; no es una recomendación de compra ni una certificación.

Ficha de medición

• Equipo: las mediciones se realizaron en un equipo que IT Lab definió y armó específicamente para pruebas: procesador Ryzen 7 5700X, 31 GiB de RAM y una tarjeta gráfica AMD Radeon RX 9070 XT de 16 GiB, con Linux. La tarjeta se eligió por ser hoy la opción más asequible con buena relación costo-beneficio que una empresa pequeña puede comprar. Los modelos evaluados cuentan con versiones optimizadas para tarjetas NVIDIA, por lo que se espera que el patrón general sea comparable en ese hardware; las cifras publicadas corresponden a este equipo.
• Cuantización: de 3 o 4 bits, según el modelo local.
• Tope de memoria de GPU: 15,5 GiB.
• Pasadas: una por modelo local; dos por modelo de pago salvo indicación.
• Banco IT Lab, edición 1.

Método general: Cómo evalúa IT Lab un modelo de IA local

Informe técnico relacionado: Informe técnico 2: Código

Contacto: IT Lab evalúa modelos de IA local para organizaciones chilenas con su propio código y sus propios datos. Conversemos

El Banco IT Lab es un instrumento vivo, en perfeccionamiento continuo. Parte de las mediciones proviene de versiones previas del instrumento y de modelos de generaciones anteriores, y algunas cifras pueden contener imprecisiones que se corrigen en cada nueva edición. Las conclusiones expresan el criterio de IT Lab a partir de sus propias mediciones.