Informe técnico 4: Metodología del Banco IT Lab (1/2)

Código: ITL-IT-01 · Banco IT Lab, edición 1

Resumen

Este informe describe la metodología del Banco IT Lab, el instrumento con que IT Lab mide si un modelo de IA local termina trabajo de oficina o de desarrollo en un equipo al alcance de una empresa pequeña. Se presentan las familias de prueba, el juez determinista y por etapas, el umbral de aprobación fijado antes de la corrida, la pasada única declarada, el principio de mejor oportunidad por modelo, la separación entre pasada oficial, sondas y diagnósticos, los controles de calidad del propio instrumento, las métricas y la política de publicación.

La motivación es medida. En pruebas públicas de código, la versión ampliada de un mismo examen bajó la nota de un modelo de 82,9 % a 76,2 %, y un conjunto de 148 tareas medía un trabajo distinto del que se buscaba automatizar. Entre los controles, la reparación determinista de formato rescató 16 de 187 respuestas sin ninguna regresión, y una configuración optimizada del motor de inferencia llevó a un mismo modelo de 42,4 a 54,6 tok/s con 13,3 GB de memoria. A juicio de IT Lab, un resultado de evaluación solo sirve para decidir cuando se publica junto con su método; este informe expone el método y reserva el contenido de las pruebas.

1. Introducción y pregunta

Una organización que considera IA local necesita saber qué tarea puede delegar, cuál debe revisar una persona y qué hardware lo permite. La pregunta de este informe es si los instrumentos de evaluación disponibles responden a eso y si no, qué instrumento lo hace. La respuesta de IT Lab es el Banco IT Lab: un conjunto de pruebas propias, orientadas a tareas reconocibles de oficina y de desarrollo, con jueces automáticos fijos y un protocolo que da a cada modelo su mejor oportunidad.

Qué mostraron los benchmarks públicos

IT Lab evaluó modelos locales con pruebas públicas de código antes de definir su propio banco. La nota base de un examen conocido resultó ser la versión fácil del examen. En HumanEval (164 problemas, una muestra por problema), la versión ampliada con casos de prueba adicionales, HumanEval+, bajó la nota de los cuatro modelos medidos.

Leyenda: pass@1, una pasada por modelo y problema; pp: puntos porcentuales. Banco IT Lab, edición 1 (etapa previa al banco).

A juicio de IT Lab, un modelo que pasa de 82,9 % a 76,2 % al añadir casos ocultos tiene soluciones que funcionan, pero son frágiles. La misma comparación muestra por qué una pasada limpia no admite segundas oportunidades: una variante con reintentos dirigidos del primer modelo obtuvo 97,6 % y 93,3 %, y esa cifra no se compara con la pasada directa porque no es la misma prueba.

Un segundo conjunto, BigCodeBench Hard, reúne 148 tareas. Su contenido abarca gráficos científicos, aprendizaje automático, extracción de datos web, criptografía y procesamiento de lenguaje, entre otros. Pide funciones aisladas, no aplicaciones completas con contexto de repositorio, y muchas tareas dependen de red, librerías o datos externos. Por esas razones, un 22 % en ese conjunto no significa que el modelo sirva para el 22 % de una aplicación web, y fallar una autenticación o una extracción web no autoriza a concluir que un modelo no puede desarrollar una aplicación. Una nota baja en un benchmark público no prueba que un modelo sirva para poco; mide otra cosa.

Una tarea real de ingeniería de software, con compilación y suite de pruebas, ya separaba mejor a los modelos que esos exámenes, y mostró otro punto: la velocidad no basta.

Leyenda: diez modelos locales evaluados sobre una misma tarea, se muestran seis; una pasada por modelo; tok/s registrados por el servidor de inferencia. Banco IT Lab, edición 1 (etapa previa al banco).

Un modelo que genera a 74,49 tok/s superó 2 de 8 pruebas. De estas observaciones se desprenden dos decisiones de diseño. La primera es medir el trabajo que la organización quiere automatizar, y no una nota abstracta. La segunda es cambiar la métrica: en lugar del porcentaje de problemas resueltos, el diseño parte de cuatro criterios, a saber, el porcentaje de tareas reales completadas sin intervención manual, el tiempo total hasta la solución correcta, las correcciones posteriores y las regresiones introducidas, y la capacidad de continuar el trabajo en una segunda iteración. La sección de métricas detalla lo que el banco aplica hoy.

2. Método

Familias de prueba

Cada familia corresponde a una capacidad que una pyme usa o querría usar. Se publica qué capacidad mide, por qué representa trabajo real y el tamaño general de la prueba; el contenido de los casos no se publica.

Leyenda: tamaño y criterio tal como los declara cada informe de familia. Banco IT Lab, edición 1.

La edición 1 evaluó 14 modelos en las familias de oficina: diez locales y cuatro de pago, con el mismo protocolo para ambos grupos. Un modelo sin la capacidad requerida, por ejemplo sin visión, se omite de esa familia y no se penaliza.

Juez determinista y juez por etapas

La aprobación la decide un juez automático y fijo: programas deterministas, sin un modelo que evalúe a otro. Las respuestas válidas se admiten mediante listas de aceptación definidas antes de la corrida, y la verdad de terreno de cada caso se fija midiendo sobre el material, no transcribiéndola de memoria.

En las familias de código el juez avanza por etapas encadenadas y se detiene en la primera que falla. Las etapas son genéricas y se presentan en el orden en que se ejecutan:

1. Compila. El código entregado se construye sin errores.
2. Comportamiento. El componente central responde como el encargo exige.
3. Pruebas internas. Las pruebas del propio componente pasan.
4. Capa web. La capa de aplicación y sus pruebas pasan.
5. Extremo a extremo. Una llamada real atraviesa los dos lenguajes.

Las etapas varían según el ejercicio; el de base existente tiene seis y el de código desde cero tiene cinco. Este diseño convierte el resultado en un diagnóstico: no entregar archivos, no compilar, compilar sin cumplir el contrato y fallar solo en la integración son situaciones distintas, y el informe de cada modelo indica en cuál se detuvo. Las pruebas son ciegas para el modelo. Editarlas o entregar archivos que el ejercicio no pide invalida la corrida. Una salida truncada por límite de generación, o un razonamiento que consume todo el presupuesto de salida, no se penaliza a medias: se registra como ausencia de entrega.

El instrumento no se modifica para favorecer a un modelo. Una corrección al juez o al formato solo se admite si vale para todos los modelos y se aplica por igual a todas las corridas; si no, es un apaño y no se hace. Los informes se escriben a partir de los datos de la corrida y las conclusiones no se redactan de antemano.

Umbral fijado antes y una pasada declarada

Cada familia fija su criterio antes de la corrida. En trabajo agéntico el umbral de aprobación es 80 sobre 100. Un modelo supera o no supera el criterio; el banco no usa expresiones como ganar o fracasar, y no ordena por una diferencia de pocos puntos.

La pasada oficial es una sola por modelo y por caso, salvo que el informe de la familia declare otro número. El banco la declara en cada tabla: una diferencia pequeña obtenida en una sola pasada es ruido, y no establece que un modelo sea superior a otro. Cuando una familia incluye repeticiones, se declaran en su informe y no se promedian con la pasada oficial de otra familia.

Mejor oportunidad por modelo

El protocolo exige investigar la documentación de cada modelo y usar sus mejores parámetros y su mejor forma de instrucción, incluida su escala de razonamiento, de modo que cada uno resuelva cada caso lo mejor que puede. No hay una configuración universal. La escala de razonamiento difiere entre familias de modelos: algunos distinguen varios niveles, otros solo encendido y apagado, y en al menos una familia pedir el razonamiento desactivado no garantiza que el servidor deje de razonar. Por eso la configuración se documenta por modelo y los valores concretos se reservan.

Este principio tiene dos funciones. Es un criterio de evaluación equitativa, porque una configuración genérica atribuye al modelo defectos que son del montaje. Y es un hallazgo práctico: en el banco, la configuración cambia el resultado tanto como la elección del modelo. El mismo trabajo sirvió para afinar las pruebas y eliminar ambigüedades en los encargos. La consecuencia para la comparabilidad es que los resultados de campañas con jueces o contratos distintos no se equiparan entre sí, y de ahí el uso de ediciones numeradas.

Pasada oficial, sondas y diagnósticos

El banco distingue tres tipos de corrida y los informa por separado, en párrafos o tablas rotulados.

• Pasada oficial. Formato estricto, una pasada por modelo, ejecución secuencial y de una sola sesión, con el máximo contexto que admite el modelo y el mismo protocolo para modelos locales y de pago. Es la única que determina si un modelo supera el criterio.
• Sonda. Corrida breve que responde una pregunta de diseño del instrumento, por ejemplo si un fallo corresponde al formato de entrega o al contenido, o cómo ordenar las imágenes respecto de sus preguntas. Una sonda no produce resultados por modelo.
• Diagnóstico. Repetición con una sola variable modificada, como activar el razonamiento, para medir cuánto corrige y cuánto cuesta en tokens y tiempo.

Los reintentos dirigidos tampoco se mezclan con la pasada oficial: la variante con reintentos descrita en la introducción se informó aparte por esa razón. Además, el razonamiento desactivado no es homogéneo entre familias de modelos y los niveles equivalentes no se comparan entre ellas.

Controles de calidad del instrumento

Un instrumento mal calibrado puede descartar configuraciones viables o aprobar las que no lo son. El protocolo vigente aplica los controles siguientes, que se describen como funciones y no como componentes.

Reparación de formato determinista y ajena al modelo. Una cadena fija corrige defectos de formato de las respuestas, como comillas sueltas, comas finales o caracteres de control, sin interpretar su contenido y sin pedir nunca al modelo que se corrija a sí mismo. Una salida cortada por límite no es reparable: se aumenta el presupuesto de salida. El control existe porque parte de los fallos de entrega pertenecen al envoltorio y no al modelo: en un caso documentado, un modelo fallaba al procesar su formato en sus dos corridas y el juez lo aprobó por completo al evaluar el mismo contenido sin el envoltorio.

Cada imagen junto a sus preguntas. En las pruebas de visión, el formato oficial intercala cada imagen con las preguntas que le corresponden. Colocar todos los adjuntos al inicio, con etiquetas, mezclaba la asociación entre imagen y pregunta en dos modelos; la disposición intercalada es la oficial.

Contexto real prearmado de una sola pieza. Las pruebas de contexto largo usan documentos reales completos, armados antes de la corrida y registrados con su conteo de tokens por tokenizador, y no un llenado artificial por tramos de 2.000 tokens. El banco dispone de cinco longitudes, de 79.964 a 247.581 tokens.

Medición del contexto que cabe en memoria. Si un modelo no cabe con el contexto máximo bajo el tope de memoria de la tarjeta, se mide el contexto máximo que admite con una sonda de carga y una búsqueda por bisección sobre el consumo de memoria, en lugar de excluirlo. Dos modelos recibieron así 131.072 y 200.704 tokens bajo un tope de 15,4 GiB. La decisión se documenta en la prueba y no se toma en silencio.

Control de memoria de la GPU. El margen se calibra contra el estado real del equipo: se exige un mínimo de 100 MB libres sobre ese estado de referencia, en lugar de un límite absoluto fijo de 15,5 GiB. Un límite mal fijado descarta en silencio configuraciones que sí caben.

Velocidad con decodificación especulativa. La velocidad se mide con una tarea nueva y se declara la tasa de aceptación del borrador, porque el contenido repetido infla la cifra. En las corridas del banco la tasa fue de 0,57 a 0,67. Además, esta técnica rinde distinto según el muestreo, de modo que no se mezclan en una misma gráfica cifras obtenidas con muestreos distintos.

Métricas

La métrica central es la tarea completada sin intervención humana: la corrida aprueba o no según el criterio de la familia, y no según la apariencia de la respuesta. Se registran además:

• Tiempo. Segundos de pared de la corrida; para las familias de oficina se informa en cada tabla.
• Velocidad. Tokens por segundo de generación y de lectura del contexto, registrados por el servidor de inferencia.
• Memoria. Pico de memoria de la tarjeta durante la corrida, registrado por el servidor, contrastado con el tope de la configuración citada.

Equipo y ejecución

El equipo, definido y armado por IT Lab específicamente para pruebas, se describe en la ficha de medición.

La cuantización de los modelos locales es de 3 o 4 bits, según el modelo. Los modelos locales se ejecutan de a uno: dos modelos simultáneos en la misma tarjeta corrompen la medición y violan el control de memoria. Los modelos de pago se evalúan con el mismo juez y el mismo formato de entrega.

Política de publicación y ediciones

IT Lab publica qué se mide, para qué sirve el resultado, los resultados por modelo, los tiempos, la memoria y los patrones de fallo en términos generales. Reserva los enunciados, las rúbricas, las ponderaciones internas de la nota, las respuestas correctas, el contenido de los documentos e imágenes de prueba y la configuración fina de cada modelo, porque son conocimiento acumulado que pone al servicio de sus clientes.

Cada modelo nuevo relevante se somete al mismo banco, con el mismo juez y el mismo criterio, y se publica con el número de edición, de modo que los resultados de una misma edición son comparables entre sí. Si el instrumento cambia, los resultados de ediciones distintas no se mezclan sin declararlo. La tabla de resultados del banco se actualiza con cada modelo incorporado.

Continúa en la Parte 2.

Contacto: IT Lab evalúa modelos de IA local para organizaciones chilenas con sus propios documentos y 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.