Cuando los LLM pequeños superan al enjambre: cómo dividir los datos en secciones multiplicó por 4 a un modelo débil

Por qué se necesitan modelos pequeños, pero no en enjambres

Un jefe de departamento en una organización de ingeniería con 14 años de experiencia pasó la primavera intentando crear un enjambre emergente a partir de modelos locales débiles. El experimento se llamaba Micelio, inspirado en trabajos sobre estructuras disipativas y poblaciones de modelos que distribuyen roles y acuerdan un lenguaje común por sí mismos. Pero el enjambre no despegó: en 200 tareas de MBPP resolvió el 29%, frente al 52% del simple best-of-N, donde los modelos solo tienen varios intentos. Sin embargo, en el camino descubrió que una idea tomada de las oficinas de proyectos soporta una carga colosal.

Todos los experimentos se ejecutaron en una GTX 1660 SUPER con 6 GB de memoria. El autor se vio obligado a usar modelos realmente pequeños: qwen2.5-coder-1.5b, qwen3-1.7b, llama-3.2-1b, internvl3-2b, gemma-3-1b y smollm2-1.7b. Las limitaciones de memoria exigían mantener varios modelos cargados a la vez y ejecutarlos con miles de llamadas. Todo el código de los experimentos lo escribieron agentes de IA; el autor planteaba las tareas y revisaba las cifras con lupa.

Estructura de oficina de proyectos en lugar de enjambre

La idea surgió de la historia de Albert Kahn, el arquitecto estadounidense que diseñó fábricas para Ford. Entre 1929 y 1932, su firma diseñó alrededor de 500 fábricas para la URSS, incluida la planta de tractores de Stalingrado. Se dice que los institutos de proyectos soviéticos surgieron de su oficina de Moscú. El autor vive a diario dentro de esa estructura organizativa.

El ingeniero jefe de proyecto divide el objeto en secciones: climatización, eléctrica, construcción, automatización; cada una a cargo de su propio departamento. Una sección terminada se revisa dentro del propio departamento (control intradisciplinario). Después, las secciones se cotejan entre sí en los puntos de contacto (control interdisciplinario): un departamento tiene una bomba, el de construcción tiene que poner una cimentación debajo, y ambos deben coincidir.

Los puntos conflictivos se llevan al especialista jefe. Al final, el control normativo revisa el formato, y solo entonces los planos se entregan al cliente. Nadie tiene toda la planta en la cabeza: simplemente no entra.

Un modelo pequeño al que se le dan 18 registros y se le pide que encuentre los correctos está en esa misma situación.

Qué se probó

En 40 tareas de prueba, los modelos debían encontrar todas las transacciones con una categoría Y una región determinadas dentro de un conjunto de 18 registros. Entre 2 y 5 coincidían, y había de 2 a 4 señuelos cerca: registros con la categoría correcta pero la región equivocada, y viceversa. El modelo debía devolver SOLO una lista de IDs separados por comas, sin explicaciones, y nombrar exactamente el conjunto correcto, sin omisiones ni añadidos.

Modelos usados, en formato GGUF: qwen2.5-coder-1.5b-instruct (Q4_0), llama-3.2-1b-instruct (Q4_0), qwen3-1.7b (Q4_0), internvl3-2b (Q4_K_M), gemma-3-1b-it (Q5_K_S), smollm2-1.7b-instruct (Q4_K_M). Las respuestas sobre la lista completa se tomaron de ejecuciones anteriores guardadas en disco para eliminar la variabilidad de la generación. En total, 720 llamadas, 614 segundos en la GTX 1660 SUPER.

Resultados: división en secciones

Sin fragmentar, ya se apreciaba una mala distribución por posición: los modelos encontraban el primer registro en el 61% de los casos, y el último en solo el 21%. El autor supuso al principio que hacia el final de la lista el modelo simplemente decía "no" con más frecuencia, pero al comprobarlo resultó estar equivocado. Hacia el final, el modelo se vuelve apenas un poco más tacaño (0,21 frente a 0,50 al principio), pero distingue mucho peor entre filas parecidas. Encuentra menos aciertos (0,30 frente a 0,50) y aumentan los falsos positivos entre los registros que no corresponden (0,16 frente a 0,14).

Luego, los 18 registros se dividieron mediante un script en 3 bloques de 6 consecutivos, manteniendo el orden dentro de cada bloque. Cada uno de los seis modelos leía cada bloque por separado. Si un modelo mencionaba un ID que no estaba en su bloque, se consideraba una invención y el código descartaba esa respuesta (en total se detectaron solo 5 invenciones en toda la ejecución). El voto por un registro solo contaba desde el bloque al que realmente pertenecía.

Resultados de coincidencia exacta (el modelo nombró exactamente el conjunto correcto):

| Modelo | Sin fragmentar | Con bloques de 6 | Ganancia | |--------|-----------|-----------------|----------| | qwen2.5-coder-1.5b | 17,5% | 70% | +52,5 pts | | llama-3.2-1b | 40% | 72,5% | +32,5 pts | | internvl3-2b | 57,5% | 82,5% | +25 pts | | qwen3-1.7b | 72,5% | 85% | +12,5 pts | | gemma-3-1b | 0% | 5% | +5 pts | | smollm2-1.7b | 0% | 0% | 0 pts |

Cuanto más débil es el modelo, mayor es la mejora. La brecha entre el principio y el final de la lista se redujo de 20 puntos a 2 puntos. En la lista completa, la cobertura al final era 0,30; con la fragmentación, pasó a 0,57.

El mito de la emergencia

El objetivo principal era encontrar emergencia: un caso en el que la respuesta combinada fuera correcta sin que ningún modelo individual hubiera acertado por sí solo. Bajo la comparación original, defectuosa, esto ocurría en 34 de 40 tareas. El autor casi abrió el champán, pero luego se fijó en qué se estaba comparando con qué. Por un lado, estaba toda la canalización: bloques, revisión, votación, ensamblaje. Por otro, un modelo único al que se le daban los 18 registros de golpe. Las condiciones son distintas, así que esa comparación no significa nada.

Con una comparación honesta (pasar al mejor modelo, qwen3-1.7b, por la misma canalización de bloques), obtiene 0,850. Los seis modelos juntos obtienen 0,900. Un oráculo que considera éxito si "al menos uno de los seis acertó" obtiene 0,975. La emergencia estricta resultó ser cero: la respuesta combinada nunca superó lo que al menos un modelo ya sabía hacer por sí solo. El enjambre solo añadió 5 puntos sobre el mejor modelo individual.

De siete elementos de la oficina de proyectos, solo uno funcionó

La carga la soportaba únicamente la división en secciones. Lo que aportó cada elemento: el ingeniero jefe dividiendo el objeto en secciones (dividir los 18 registros en 3 bloques de 6) aportó casi todo: la brecha pasó de 0,20 a 0,02, la precisión exacta pasó de 0,75 a 0,90. Los ejecutores (6 modelos, uno por bloque) aportaron +0,05 sobre el mejor modelo individual.

El control intradisciplinario (un ID que no pertenece a su bloque se descarta) detectó 5 invenciones. El control interdisciplinario (cotejar en los puntos de contacto entre bloques) no tuvo nada que cotejar, porque los bloques son independientes. El control normativo (revisión del formato) no encontró errores.

El especialista jefe (una pregunta puntual sobre una sola fila) no fue necesario. Las revisiones (otra ronda cuando la respuesta es dudosa) no fueron necesarias.

Conclusión práctica: corte los modelos pequeños en fragmentos cuando los alimente con un lote de documentos o una lista larga. En este experimento, el óptimo fue de 6 registros por bloque; las primeras 6 posiciones eran las que se encontraban mejor. Fragmentar por tokens es casi gratis: tres fragmentos de un tercio cada uno dan el mismo volumen total, más tres repeticiones de la cabecera del prompt. Tres veces más llamadas, pero cada una más corta. Un enjambre de seis modelos encima de eso cuesta seis veces más y gana 5 puntos. El autor no aprueba ese intercambio, pero la herramienta —la división en secciones— funciona.