🤖 machine learning

From Instance Selection to Fixed-Pool Data Recipe Search for Supervised Fine-Tuning

Este artigo apresenta o AutoSelection, um novo framework que reformula a seleção de dados para ajuste fino supervisionado como um problema de busca de receitas em pool fixo, utilizando um solucionador de duas camadas para descobrir eficientemente receitas de curadoria ótimas a partir de um pool bruto de instruções sem gerar novas amostras, superando assim a classificação tradicional de instâncias e o treinamento com dados completos em múltiplos modelos e tarefas.

Autores originais: Haodong Wu, Jiahao Zhang, Lijie Hu, Yongqi Zhang

Publicado 2026-05-14

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Haodong Wu, Jiahao Zhang, Lijie Hu, Yongqi Zhang

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é um chef tentando criar a sopa perfeita. Você tem uma despensa enorme (o pool de dados brutos) cheia de 90.000 ingredientes diferentes (instruções). Seu objetivo é escolher a melhor combinação de ingredientes para fazer uma sopa que tenha um sabor incrível (um modelo de IA inteligente).

O Jeito Antigo: A Lista dos "Top 10"

Tradicionalmente, chefs (e pesquisadores de IA) tentavam resolver isso provando cada ingrediente individualmente, atribuindo uma pontuação a cada um e, em seguida, pegando apenas os 10 itens com as maiores pontuações.

O Problema: Apenas porque um ingrediente tem bom sabor sozinho não significa que ele funcione bem em uma sopa. Talvez você precise de um pouco de pimenta picante antes de adicionar o sal, ou talvez precise remover os vegetais aquosos antes de adicionar as ervas. O método antigo ignorava a ordem e a combinação. Ele tratava a sopa como uma simples lista de "melhores itens" em vez de uma receita.

A Nova Ideia: A "Busca pela Receita"

Este artigo, AutoSelection, sugere uma abordagem diferente. Em vez de apenas escolher os melhores ingredientes, devemos buscar a melhor receita.

Pense em uma receita como um conjunto de instruções:

Filtre todos os vegetais sem sabor.
Misture as pimentas picantes com os limões azedos.
Remova qualquer especiaria duplicada.
Mantenha apenas os 50% superiores da mistura restante.

O artigo chama isso de Busca por Receita de Dados de Pool Fixo. A "despensa" permanece exatamente a mesma (não vamos comprar novos ingredientes nem inventar nenhum); apenas tentamos diferentes sequências ordenadas de operações para ver qual delas cria o melhor prato final.

Como o AutoSelection Funciona (O "Chef Inteligente")

Buscar a receita perfeita é caro. Para testar uma receita, você precisa realmente cozinhar a sopa (treinar o modelo de IA) e prová-la (executar benchmarks). Você tem apenas um orçamento limitado para fazer isso (digamos, 15 tentativas). Você não pode apenas adivinhar aleatoriamente; precisa de uma estratégia inteligente.

O AutoSelection é um sistema de "Chef Inteligente" de duas camadas que ajuda você a encontrar a melhor receita sem desperdiçar seu orçamento:

A "Cola" (Sinais em Cache): Antes mesmo de começar a cozinhar, o sistema olha para a despensa e anota observações sobre cada ingrediente: "Este é picante", "Aquele é pesado", "Estes dois são muito similares". Assim, ao testar uma nova receita, ele não precisa reprová-la do zero. Usa essas anotações pré-escritas para prever como a receita pode ficar.
A "Tentativa" (Aquecimento): Antes de comprometer-se com uma sessão completa de cozimento, o chef faz três testes rápidos e pequenos para ver se a sopa precisa ser grande, média ou pequena. Isso ajuda a preparar o cenário.
O "Teste de Prova" (Vetores de Estado): Quando uma receita é executada, o sistema não olha apenas para a pontuação final. Ele observa o estado da sopa: "Mantivemos ingredientes suficientes? O sabor está equilibrado?" Ele cria um "vetor de estado" (um relatório resumido) dos ingredientes selecionados.
O "Painel de Prova" (O Controlador de Busca):
- Resumidor: Lê o histórico de sopas passadas e diz: "Ei, toda vez que adicionamos sal depois da pimenta, ficou ótimo."
- Propositor: Sugere novas variações de receita com base nesse conselho (por exemplo: "Vamos tentar trocar a ordem do sal e da pimenta").
- Classificador: Olha para as novas sugestões e usa um "Processo Gaussiano" (um adivinhador matemático sofisticado) para prever qual delas tem maior probabilidade de ser boa, escolhendo então o único melhor candidato para realmente cozinhar.
- Ressemeador: Se o chef continuar fazendo a mesma sopa e ela não estiver melhorando (estagnação), o sistema diz: "Ok, vamos descartar a ideia atual e tentar um ponto de partida completamente diferente."

Os Resultados: Funcionou?

Os pesquisadores testaram isso em três modelos de IA diferentes (pequenos e médios) usando um pool de instruções de 90.000 itens. Eles compararam o AutoSelection com:

Usar toda a despensa (Dados Completos).
Escolher receitas aleatoriamente.
Apenas escolher os "Top 10" melhores ingredientes (Operador Único).

As Descobertas:

Sopa Melhor: O AutoSelection criou modelos que eram mais inteligentes em tarefas de raciocínio do que até mesmo os modelos treinados no conjunto completo de dados de 90.000 itens.
A Ordem Importa: Eles provaram que a sequência dos passos importa. Por exemplo, fazer "Passo A depois Passo B" produziu um resultado muito melhor do que "Passo B depois Passo A", mesmo que os ingredientes fossem os mesmos.
Estabilidade: O sistema não teve apenas sorte uma vez; encontrou consistentemente boas receitas em múltiplas tentativas.
Transferibilidade: Uma receita que funcionou bem em um modelo pequeno (1,5B de parâmetros) tendeu a funcionar bem em um modelo maior (7B de parâmetros), sugerindo que a própria "receita" captura algo fundamental sobre bons dados.

A Conclusão

Este artigo argumenta que tornar a IA mais inteligente não se trata apenas de encontrar os "melhores" pontos de dados. Trata-se de encontrar o melhor processo para filtrar e misturar esses dados. Ao tratar a seleção de dados como uma busca por receita em vez de uma simples lista de classificação, e ao usar um mecanismo de busca inteligente e consciente do orçamento (AutoSelection) para encontrar essa receita, podemos construir modelos de IA melhores com menos esforço desperdiçado.

O que NÃO é:

Não inventa novos dados nem reescreve as instruções.
Não usa IA para gerar novas amostras de treinamento.
Não afirma funcionar para diagnóstico médico ou usos clínicos específicos (foca estritamente em benchmarks de raciocínio geral, como matemática e quebra-cabeças de lógica).

Resumo Técnico: Da Seleção de Instâncias à Busca de Receitas de Dados de Pool Fixo

Formulação do Problema

As abordagens atuais para seleção de dados de Ajuste Fino Supervisionado (SFT) são predominantemente formuladas como classificação ao nível de instância: pontuando amostras individuais com base em heurísticas, estimativas de influência ou representações aprendidas, e retendo um subconjunto dos top- $k$ . Embora eficazes, essa visão abstrai a realidade prática da montagem de conjuntos de dados para SFT, que frequentemente envolve fluxos de trabalho de curadoria em múltiplos estágios, incluindo filtragem, mistura de fontes, deduplicação e limpeza.

Este artigo reformula o problema como busca de receitas de dados de pool fixo. Neste cenário:

O pool de instruções bruto ( $D_0$ ) é fixo.
Existe uma biblioteca de operadores fundamentados ( $O$ ) (por exemplo, filtragem por dificuldade, deduplicação, mistura).
Uma "receita" candidata é uma sequência ordenada desses operadores.
O objetivo não é atribuir uma pontuação final a cada instância, mas descobrir uma receita executável que construa um subconjunto selecionado de alta qualidade sob um orçamento limitado de avaliações completas de SFT.
Crucialmente, o método não gera, reescreve ou aumenta amostras de treinamento; ele apenas seleciona e compõe dados existentes.

Esta formulação subsume a seleção top-k de operador único (vista como uma receita degenerada de comprimento um), mas otimiza explicitamente a composição de operadores, a ordenação e os estados resultantes de subconjuntos intermediários.

Metodologia: AutoSelection

Os autores introduzem o AutoSelection, um solucionador de duas camadas projetado para navegar eficientemente no espaço de receitas composicionais sob restrições de validação dispendiosas.

1. Camada de Materialização de Pool Fixo (Raciocínio Barato no Lado da Busca)
Para evitar recalcular sinais caros para cada candidato, o AutoSelection armazena em cache sinais fundamentados sobre o pool bruto canônico ( $D'_0$ ):

Sinais do lado da tarefa: Similaridade de ativação condicionada a benchmarks (seguindo o MONA).
Sinais do lado dos dados: Propriedades intrínsecas como diversidade léxica (entropia de N-gramas) e ramificação ação-objeto.
Sinais do lado do modelo: Respostas do modelo base em cache, incluindo dificuldade de seguimento de instruções (IFD), varentropia e estatísticas de ativação esparsa.
Vetores de Estado: Para qualquer receita materializada, um vetor de estado $z(r)$ resume as propriedades do subconjunto realizado (por exemplo, proporções de tokens retidos, deriva de distribuição, relevância da tarefa). Isso permite que o controlador de busca compare subconjuntos candidatos antes de comprometer uma avaliação completa de SFT.

2. Camada Controladora de Busca (Alocação de Orçamento)
O controlador gerencia o trade-off exploração-exploração usando um orçamento de $B$ avaliações completas:

Sondas de Aquecimento: A busca começa sondando três regimes distintos de escala de dados (baixa, média, alta retenção) para estabelecer uma âncora de semente inicial e identificar níveis de retenção promissores.
Refinamento Local: Usando um Resumidor, o sistema converte o histórico avaliado em hipóteses baseadas em dados. Um Propositor então gera receitas candidatas irmãos realizando edições locais (inserindo, deletando, trocando ou reajustando etapas) ao redor da semente atual.
Classificação: Um Classificador seleciona o único melhor candidato para avaliação completa. Ele combina:
- A estrutura da receita.
- O vetor de estado realizado (propriedades do subconjunto).
- Um prior de substituto de Processo Gaussiano (GP) baseado em codificações de receita.
- Dados históricos de busca.
Ressementeamento Acionado por Estagnação: Se a busca falhar em melhorar a melhor pontuação incumbente por $P$ etapas consecutivas, um Ressementeador atualiza a âncora de semente selecionando um novo motivo promissor do histórico, impedindo que a busca fique presa em regiões locais saturadas.

Modelos de linguagem (especificamente DeepSeek-R1) são usados estritamente como assistentes no lado da busca para resumir histórico, propor edições fundamentadas, classificar candidatos e resssemear; eles não reescrevem nem geram dados de treinamento.

Contribuições Principais

Formulação do Problema: Os autores formalizam a curadoria de dados de SFT como um problema de otimização de caixa preta orçamentada sobre receitas executáveis em um pool bruto fixo, tornando a composição e a ordenação de operadores alvos explícitos de otimização.
Método (AutoSelection): Um solucionador de duas camadas que desacopla a materialização de candidatos em cache da avaliação completa de SFT dispendiosa, utilizando sondas de aquecimento, edições locais conscientes de estado, classificação assistida por GP e ressementeamento acionado por estagnação.
Evidência Empírica: Avaliação abrangente em três modelos base (Qwen2.5-1.5B/3B, Llama3.2-1B) em um pool de 90K instruções.

Resultados Experimentais

Avaliado em um pool de instruções de 90K amostras com um orçamento de 15 avaliações completas de SFT:

Desempenho: O AutoSelection alcançou a média de raciocínio dentro da distribuição mais forte em todos os três modelos base, superando o treinamento com dados completos, busca aleatória de receitas, top-k aleatório e seletores de operador único.
- Melhorias sobre o treinamento com dados completos: +1,82 (Llama3.2-1B), +3,40 (Qwen2.5-1.5B) e +3,72 (Qwen2.5-3B) pontos.
- Melhorias sobre a melhor linha de base não-AutoSelection: +0,90 a +2,89 pontos.
Generalização OOD: Em benchmarks de raciocínio em gráfico retidos (GraphWiz, NLGraph), o AutoSelection permaneceu competitivo, classificando-se em primeiro lugar no Qwen2.5-1.5B e quase empatando com a melhor linha de base no Qwen2.5-3B.
Estabilidade: Três execuções independentes no modelo de 1.5B mostraram uma faixa estreita de pontuação (0,59 pontos), indicando que os ganhos não são devidos a uma única execução sortuda.
Ablações:
- Remover o Aquecimento fez com que a busca gastasse avaliações iniciais em regiões de baixa pontuação.
- Remover o Resumidor resultou em uma trajetória mais suave, mas uma receita final melhor mais fraca.
- Remover o Ressementeamento levou a uma curva de melhor até o momento mais plana, indicando dificuldade em escapar de ótimos locais.
- Remover os Vetores de Estado expôs a busca a candidatos com formas promissoras, mas estados de subconjuntos realizados fracos.
Sensibilidade Estrutural: Ablações estruturais com sementes correspondidas confirmaram que a ordenação e a composição de operadores impactam significativamente o desempenho além da mera presença de operadores específicos.
Transferibilidade: Uma verificação de transferência de 1.5B para 7B mostrou uma correlação de posto de Spearman positiva ( $\rho=0,82$ ), sugerindo que motivos de dados de alta qualidade descobertos em modelos menores podem ser úteis para modelos maiores, embora a preservação exata do posto não seja garantida.

Significado e Alegações

O artigo afirma que o valor do AutoSelection não reside em descobrir um único seletor universalmente melhor, mas em alocar um pequeno número de avaliações completas para encontrar uma composição mais forte de decisões de curadoria fundamentadas.

Os autores argumentam que:

A Estrutura da Receita Importa: A ordenação e a interação de operadores (por exemplo, filtragem antes da deduplicação versus depois) têm um impacto mensurável no desempenho downstream de SFT, apoiando a visão de receitas de dados como objetos de otimização de primeira classe.
Controle de Pool Fixo: Ao restringir a busca a um pool bruto fixo sem geração ou reescrita, o método isola os efeitos das escolhas de operadores de confusões introduzidas por síntese de dados ou engenharia de prompts.
Eficiência: A abordagem demonstra que estratégias de busca eficientes (aquecimento, classificação consciente de estado, ressementeamento) podem produzir subconjuntos melhores do que o treinamento com dados completos ou busca aleatória dentro de um orçamento estrito de avaliação.

O trabalho se posiciona como uma alternativa controlada aos sistemas de geração de dados impulsionados por LLM, focando na otimização de fluxos de trabalho de dados existentes em vez da síntese de novos dados.