80 diálogos sintéticos bastam para sondas de ativação do Gemma-3-27B, mas não em todos os casos

Quantos diálogos sintéticos são necessários para treinar uma sonda que acompanha o comportamento de um modelo de linguagem em produção? Os autores de um trabalho recente no arXiv cs.LG mediram isso diretamente e chegaram a uma resposta que depende do que a sonda monitora. No Gemma-3-27B-IT, as sondas para «situações de alto risco» (high-stakes) e para respostas nocivas a pessoas ficam a poucos centésimos do seu platô já com 80 exemplos. As sondas que detectam o descumprimento de uma instrução do usuário precisam de várias vezes mais.

Como o experimento foi montado

Uma sonda de ativação é um classificador pequeno que opera sobre as representações internas do modelo. Em geral, ela é treinada com conversas geradas por outro LLM, e até agora o orçamento dessa geração era definido no olhômetro. Os pesquisadores construíram curvas de aprendizado variando de 10 a 590 amostras sintéticas, para três conceitos: alto risco, resposta nociva a uma pessoa e resposta que não segue a instrução. A qualidade foi medida em 14 distribuições held-out. Em paralelo, eles variaram o modelo gerador e o nível de detalhe do prompt.

Principais parâmetros do estudo:

• três conceitos de monitoramento: high-stakes, harmful, instruction;
• quatro modelos de sonda, sendo o principal o Gemma-3-27B-IT;
• 14 distribuições held-out de avaliação;
• de 10 a 590 amostras sintéticas na curva;
• a ordem dos conceitos por «apetite» de dados se mantém em três modelos menores e em amostras reais do conjunto de dev.

Cobertura em vez de dificuldade

Para comparar as curvas, os autores criaram uma métrica, o half-gain size: o número de amostras necessário para atingir metade do ganho final de qualidade. Conceito e distribuição juntos explicam 42–45% da variância dessa métrica. Gerador, modelo da sonda e nível de detalhe do prompt, somados, respondem por menos de 10%. Segundo esses dados, escolher um modelo gerador mais caro ou um prompt mais detalhado influencia a necessidade de dados muito menos do que o próprio objeto do monitoramento.

Os autores rejeitam a explicação intuitiva de que alguns conceitos são simplesmente mais difíceis. Quando cada «tipo» de dado é considerado separadamente (um por distribuição de avaliação), o half-gain size mediano fica entre 7 e 11 amostras sintéticas próprias, e isso vale igualmente para os três conceitos. Dentro de um único tipo, a dificuldade é comparável em todos os casos. O que muda é outra coisa: o quanto amostras de um tipo ajudam nos demais tipos do mesmo conceito. Em high-stakes, a transferência é quase total; em harmful, é pior; em instruction, é a mais fraca. Os autores atribuem a maior parte da diferença entre os conceitos a esse desequilíbrio, tanto nos dados gerados quanto nos reais.

Daí vem uma conclusão para o debate «amplitude ou profundidade». A recomendação anterior, de gastar o orçamento de geração com a diversidade de tipos de dados e não com o volume de cada tipo, vale de forma desigual. Para instruction, muitos tipos são indispensáveis: nenhum tipo cobre outro. Para high-stakes, eles são quase redundantes, porque um tipo cobre os demais.

O que fazer com o orçamento de geração

Para uma equipe que monta o monitoramento de um deploy, vale começar verificando a transferência entre tipos de dados, e não escolhendo o gerador. Se o conceito se parece com high-stakes, algumas dezenas de exemplos bem escolhidos bastam, e gastar mais rende pouco. Se ele se parece com instruction, a diversidade de tipos precisa estar prevista desde o início, e o volume deve ser contado em centenas. Um modelo gerador caro e um prompt superdetalhado economizam menos do que parece: sua contribuição para a variância da necessidade de dados é inferior a 10%.

Ressalva: todas as conclusões vêm de três conceitos e quatro sondas. Para outros conceitos, a necessidade de dados terá de ser medida de novo, e a verificação de transferência entre tipos parece uma ferramenta viável para isso. Os autores publicaram os conjuntos de avaliação, os conjuntos de dev e os dados gerados, então é possível reproduzir as curvas na sua própria stack sem anotação própria.