Quando LLMs pequenos superam o enxame: como dividir os dados em seções multiplicou por 4 o desempenho de um modelo fraco

Por que modelos pequenos são necessários, mas não em enxames

Um chefe de departamento em uma organização de engenharia com 14 anos de experiência passou a primavera tentando criar um enxame emergente a partir de modelos locais fracos. O experimento se chamava Micélio, inspirado em trabalhos sobre estruturas dissipativas e populações de modelos que distribuem papéis e negociam uma linguagem comum por conta própria. Mas o enxame não deslanchou: em 200 tarefas do MBPP ele resolveu 29%, contra 52% do simples best-of-N, no qual os modelos apenas recebem várias tentativas. No caminho, porém, ele descobriu que uma ideia emprestada da prática de escritórios de projetos sustenta uma carga colossal.

Todos os experimentos foram executados em uma GTX 1660 SUPER com 6 GB de memória. O autor foi forçado a usar modelos realmente pequenos: qwen2.5-coder-1.5b, qwen3-1.7b, llama-3.2-1b, internvl3-2b, gemma-3-1b e smollm2-1.7b. As limitações de memória exigiam manter vários modelos carregados ao mesmo tempo e executá-los em milhares de chamadas. Todo o código dos experimentos foi escrito por agentes de IA; o autor definia as tarefas e checava os números com rigor.

Estrutura de escritório de projetos em vez de enxame

A ideia veio da história de Albert Kahn, o arquiteto americano que projetou fábricas para a Ford. Entre 1929 e 1932, sua firma projetou cerca de 500 fábricas para a URSS, incluindo a fábrica de tratores de Stalingrado. Diz-se que os institutos de projetos soviéticos nasceram de seu escritório em Moscou. O autor vive diariamente dentro dessa estrutura organizacional.

O engenheiro-chefe do projeto divide o objeto em seções: climatização, elétrica, construção civil, automação — cada uma a cargo de seu próprio departamento. Uma seção concluída é verificada dentro do próprio departamento (verificação intradisciplinar). Depois, as seções são confrontadas entre si nos pontos de contato (verificação interdisciplinar) — um departamento tem uma bomba, o de construção precisa colocar uma fundação sob ela, e os dois precisam combinar.

Pontos controversos vão para o especialista-chefe. No final, o controle normativo verifica a formatação, e só então os conjuntos de desenhos vão para o cliente. Ninguém guarda a usina inteira na cabeça — simplesmente não cabe.

Um modelo pequeno ao qual se dão 18 registros e se pede para encontrar os certos está na mesma posição.

O que foi testado

Em 40 tarefas de teste, os modelos tinham que encontrar todas as transações com uma determinada categoria E região em um conjunto de 18 registros. Entre 2 e 5 correspondiam, com de 2 a 4 armadilhas por perto — registros com a categoria certa mas a região errada, e vice-versa. O modelo tinha que devolver APENAS uma lista de IDs separados por vírgula, sem explicações, e indicar exatamente o conjunto correto — sem sobras e sem omissões.

Modelos usados, em 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). As respostas sobre a lista completa foram retiradas do disco de execuções anteriores para eliminar a variabilidade da geração. No total, 720 chamadas, 614 segundos na GTX 1660 SUPER.

Resultados: divisão em seções

Mesmo sem fragmentação, já era visível uma distribuição ruim por posição: os modelos encontravam o primeiro registro em 61% dos casos, e o último em apenas 21%. O autor inicialmente supôs que, perto do fim da lista, o modelo simplesmente dizia "não" com mais frequência, mas ao verificar descobriu que estava errado. Perto do fim, o modelo se torna apenas um pouco mais econômico (0,21 contra 0,50 no início), mas distingue muito piorlinhas semelhantes. Ele encontra menos acertos (0,30 contra 0,50), e aumentam os falsos positivos entre os registros que não correspondem (0,16 contra 0,14).

Em seguida, os 18 registros foram divididos por um script em 3 blocos de 6 consecutivos, mantendo a ordem dentro de cada bloco. Cada um dos seis modelos lia cada bloco separadamente. Se um modelo citasse um ID que não estava em seu bloco, isso era considerado uma invenção e o código descartava essa resposta (apenas 5 invenções foram detectadas em toda a execução). O voto por um registro só contava a partir do bloco ao qual ele realmente pertencia.

Resultados de correspondência exata (o modelo indicou exatamente o conjunto correto):

| Modelo | Sem fragmentação | Com blocos de 6 | Ganho | |--------|-----------|-----------------|----------| | 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 |

Quanto mais fraco o modelo, maior o ganho. A diferença entre o começo e o fim da lista caiu de 20 pontos para 2 pontos. Na lista completa, a cobertura no final era 0,30; com a fragmentação, passou para 0,57.

O mito da emergência

O principal objetivo era encontrar a emergência — um caso em que a resposta combinada estivesse correta sem que nenhum modelo individual tivesse acertado por conta própria. Na comparação original, equivocada, isso ocorria em 34 das 40 tarefas. O autor quase abriu o champanhe, mas então olhou com mais atenção o que estava sendo comparado com o quê. De um lado estava todo o pipeline: blocos, verificação, votação, montagem. Do outro, um único modelo ao qual se davam os 18 registros de uma vez. As condições são diferentes, então essa comparação não significa nada.

Em uma comparação justa (submetendo o melhor modelo, qwen3-1.7b, ao mesmo pipeline de blocos), ele obtém 0,850. Os seis modelos juntos obtêm 0,900. Um oráculo que considera sucesso se "pelo menos um dos seis acertou" obtém 0,975. A emergência estrita deu zero: a resposta combinada nunca superou o que pelo menos um modelo já conseguia fazer por conta própria. O enxame acrescentou apenas 5 pontos sobre o melhor modelo individual.

De sete elementos do escritório de projetos, só um funcionou

A carga foi sustentada apenas pela divisão em seções. O que cada elemento contribuiu: o engenheiro-chefe dividindo o objeto em seções (dividir os 18 registros em 3 blocos de 6) contribuiu com quase tudo: a diferença caiu de 0,20 para 0,02, a precisão exata subiu de 0,75 para 0,90. Os executores (6 modelos, um por bloco) contribuíram com +0,05 sobre o melhor modelo individual.

O controle intradisciplinar (um ID que não pertence ao seu bloco é descartado) detectou 5 invenções. O controle interdisciplinar (confronto nos pontos de contato entre blocos) não teve nada para confrontar, pois os blocos são independentes. O controle normativo (verificação do formato) não encontrou erros.

O especialista-chefe (uma pergunta pontual sobre uma única linha) não foi necessário. As revisões (uma nova rodada quando a resposta é incerta) não foram necessárias.

Conclusão prática: corte os modelos pequenos em pedaços ao alimentá-los com um lote de documentos ou uma lista longa. Neste experimento, o ideal foi de 6 registros por bloco — as primeiras 6 posições eram as encontradas com mais confiabilidade. Fragmentar por tokens é quase grátis: três pedaços de um terço cada um dão o mesmo volume total, mais três repetições do cabeçalho do prompt. Três vezes mais chamadas, mas cada uma mais curta. Um enxame de seis modelos em cima disso custa seis vezes mais e ganha 5 pontos. O autor não aprova essa troca, mas a ferramenta — a divisão em seções — funciona.