O Scaffold Pertence ao Sinal de Treinamento. Ao Menos Metade Dele.

“O conhecimento de tarefa contido no scaffold pertence ao sinal de treinamento.” Essa frase, de um paper da Thinking Machines com a UIUC sobre text-to-SQL publicado em agosto de 2026, é o argumento mais afiado até agora contra uma tese que defendemos repetidamente neste site: a de que o harness em volta do modelo, e o conhecimento de orquestração dentro dele, é onde mora o valor durável de engenharia. Os autores foram além do argumento abstrato. Treinaram um modelo, mediram contra a fronteira e publicaram os números.

Escrevemos que capacidade vira commodity e orquestração é o moat. Escrevemos que governança deve mirar o harness, e que o modelo vem depois. Se esse resultado generalizar, os dois ensaios precisam de um asterisco. Antes de discordar de qualquer coisa, o movimento honesto é apresentar o caso deles na força máxima.

O Resultado, na Versão Mais Forte

O time partiu do Kimi-K2.6 como modelo base e o treinou com reinforcement learning na plataforma Tinker, produzindo o ReViSQL-K2.6. No Arcwise-Plat-SQL, o modelo resultante marcou 88,55% de Pass@1, à frente do GPT-5.6 Sol Ultra com 86,75% e do Claude Fable 5 com 84,94%. Os autores resumem: mais preciso que o Fable 5 e o GPT-5.6 Sol Ultra a 12 a 15% do custo deles. Com self-consistency de 16 amostras, o número sobe para 92,97%, empatando com o nível humano no BIRD, de 92,96%.

O lado do custo é tão incisivo quanto o da precisão: US$ 0,035 por tarefa no modo greedy, US$ 0,56 por tarefa com self-consistency de 16 amostras. Um modelo base treinado, rodando barato, vencendo dois modelos de fronteira na tarefa.

O que torna isso um argumento sério, e um resultado que merece resposta, é o alvo que ele escolhe. Um pipeline típico de text-to-SQL com scaffold encadeia etapas como schema linking, recuperação de exemplos similares, geração de candidatos, loops de autocorreção, um verificador no final. Cada estágio codifica expertise de tarefa que algum engenheiro escreveu. A alegação do paper é que esse tipo de expertise pertence aos pesos, migrada através do sinal de treinamento, e o resultado se lê como o pipeline virando overhead: o modelo treinado venceu as alternativas com scaffold, com precisão maior e uma fração do custo.

Para quem vem argumentando, como nós, que a linha de montagem é o ativo, esse resultado dá nome ao preço da posição. O conhecimento de tarefa que o seu scaffold codifica está a um treinamento de distância de ser absorvido. O scaffold é legível. Está escrito em prompts e em código de pipeline. É, na prática, uma especificação do que treinar em seguida.

Duas ressalvas cabem aqui, e as duas vêm da própria fonte. O resultado é escopado a text-to-SQL, um único domínio de tarefa com saída verificável, e os autores reivindicam apenas isso. E a Thinking Machines vende o Tinker, a plataforma de treinamento usada no trabalho, então a conclusão “treine em vez de montar scaffold” também é o pitch comercial deles. Nenhuma das ressalvas enfraquece os números medidos. As duas deveriam disciplinar até onde alguém os extrapola.

Duas Coisas Que Vínhamos Chamando de Uma

Levado a sério, o paper força uma distinção que a nossa própria escrita anterior borrava. “O harness” vinha carregando dois empregos diferentes.

O primeiro emprego é o scaffolding de capacidade: componentes como um schema linker, uma etapa de retrieval, um ranqueador de candidatos, um loop de autocorreção. O propósito dele é fazer o modelo produzir saída melhor. Essa é a parte que o paper ataca, e, pela evidência, o ataque acerta. Scaffolding de capacidade é conhecimento de tarefa em forma externalizada, e conhecimento de tarefa em forma externalizada é exatamente o que um sinal de treinamento consegue ingerir. Toda melhoria desse tipo deveria ser tratada como um aluguel temporário, renovável até alguém treiná-la para dentro de um modelo perto de você.

O segundo emprego é o scaffolding de controle: fronteiras de permissão, trilhas de auditoria, contenção de efeitos colaterais, a camada que decide o que um sistema pode fazer e registra o que ele fez. O propósito dele é restringir o modelo, e uma restrição absorvida pela coisa que ela restringe deixa de ser restrição. Treinar um modelo para ser o próprio sistema de permissões falha pela mesma razão que promover o réu a juiz falha. A camada de controle precisa ficar fora dos pesos porque a autoridade dela depende de ficar fora dos pesos.

Nosso argumento do moat sobrevive apenas para o segundo tipo. Essa é uma concessão real. Uma parcela considerável do que consultorias, times de plataforma e startups de agentes vendem hoje como “expertise de orquestração” é scaffolding de capacidade, e esse paper é evidência de que a meia-vida disso é mais curta do que os donos assumem.

Para Onde Foi o Trabalho de Governança

O paper fica mais interessante justamente onde descreve o que o time precisou fazer para o treinamento funcionar, porque esse trabalho é governança com outro nome. Ele mudou de endereço quando o pipeline saiu de cena.

Primeiro endereço novo: os dados de treinamento. O time auditou 2,5 mil instâncias amostradas do BIRD Train, o conjunto de treinamento de que o paper parte, e encontrou pelo menos um erro em 61,1% delas. O próprio SQL de referência estava incorreto em 52,1% das instâncias. A maioria das respostas de referência da amostra auditada estava errada. Limpar pesou mais que método: treinar no BIRD-Platinum corrigido, em vez do original, melhorou a generalização em 16%, 12% e 14% no Arcwise-Plat-SQL, no Spider2-SQLite e no Spider2-Snow, respectivamente, em termos percentuais, como o próprio paper formula.

Segundo endereço novo: o canal de recompensa. Usando o VeriEQL para auditar recompensas baseadas em resultado, encontraram que 32,8% das recompensas positivas tinham sido dadas a queries que não eram totalmente equivalentes à referência. Cerca de um em cada três sinais de “correto” premiava o comportamento errado. Um treinamento de RL sobre esse canal, sem auditoria, aprende os defeitos junto com a habilidade.

Ou seja: o método que elimina o scaffold depende de duas auditorias, uma sobre o que o modelo aprende e outra sobre como ele é pontuado. Essas são superfícies de controle. São exatamente o tipo de coisa que fica fora dos pesos, porque o trabalho delas é julgar o que entra nos pesos. Fizemos uma observação parente sobre avaliação em benchmark inválido, e por que contaminação é o diagnóstico menor: instrumento errado é um problema diferente, e pior, que instrumento vazado. Este paper encontrou a mesma doença no conjunto de treinamento e na função de recompensa, e precisou construir a camada que checa o instrumento antes de o resultado de manchete existir.

O quadro que emerge é uma realocação, com troca de dono. No mundo do scaffold, a governança da tarefa morava em código de pipeline que engenheiros de aplicação escreviam e podiam inspecionar. No mundo treinado, ela mora em auditoria de dados e verificação de recompensa, rio acima dos pesos, sob a responsabilidade de quem roda o treinamento. A superfície encolheu. O peso de cada decisão cresceu, porque um erro no sinal de treinamento se replica em toda saída, em vez de uma.

Uma das nossas alegações anteriores sai confirmada, e vale registrar. Em text-to-SQL contra um warehouse real cobrimos a distância entre condições de benchmark e bancos de produção. Os números de auditoria deste paper quantificam parte da origem dessa distância, e a discussão fica lá. Um modelo em nível humano num benchmark corrigido ainda vai encontrar a lógica de join não documentada do seu warehouse nos termos dela.

O Que Fazer Com Isso

Faça agora: inventarie o seu stack de agentes e rotule cada componente com uma palavra, capacidade ou controle. As dicas de schema, os loops de retry e reparo, as regras de domínio codificadas em prompt são capacidade. Trate-os como ativos que depreciam e pare de construir moat sobre eles. As checagens de permissão, o log de auditoria, o harness de recompensa ou avaliação, as checagens de qualidade de dados rio acima de qualquer fine-tune são controle. Esses compõem valor. Se o seu time faz fine-tune ou RL sobre qualquer coisa, aplique a lição do paper antes da manchete dele: audite o conjunto de treinamento e audite o canal de recompensa primeiro, porque, com taxas de defeito de 61,1% e 32,8% no corpus que o paper mediu, a auditoria é de onde o resultado veio.

Fontes

Thinking Machines + UIUC. “Putting Task Expertise into RL (On Text-to-SQL).” Agosto de 2026.

A Victorino ajuda organizações de engenharia a separar o scaffolding que o treinamento vai absorver da camada de controle que precisa sobreviver a ele: contato@victorino.com.br | www.victorino.com.br