Dados Sintéticos para GenAI

O que significa “Dados Sintéticos para GenAI”

Dados sintéticos são dados gerados por um programa, em vez de serem coletados diretamente do mundo real. Em sistemas de I.A. Generativa (Generative AI) — especialmente LLMs — os dados sintéticos são tipicamente produzidos por um modelo (ou por um pipeline que inclui modelos) e então usados para:

  • Treinamento: aumento de pré-treinamento, ajuste fino supervisionado (SFT, supervised fine-tuning), treinamento por preferências, treinamento de uso de ferramentas
  • Avaliação: construção de conjuntos de teste, sondas adversariais, suítes de regressão, benchmarks específicos de domínio
  • Rotulagem de dados: geração de rótulos, justificativas, anotações estruturadas ou avaliação de saídas do modelo

Na prática, dados sintéticos frequentemente combinam:

  • Conteúdo gerado por modelo (perguntas, respostas, diálogos, código, imagens)
  • Restrições programáticas (esquemas, regras, templates, simuladores)
  • Revisão humana (checagens pontuais, auditorias, red-teaming)
  • Âncoras de dados reais (pequenos conjuntos-semente curados, referências de verdade fundamental)

Este artigo se concentra em duas perguntas centrais:

  1. Como usamos modelos para gerar dados de treinamento e avaliação de forma eficaz?
  2. Como evitamos ciclos de retroalimentação (feedback loops) — em que modelos aprendem com os próprios erros e degradam gradualmente?

Por que dados sintéticos são úteis para GenAI

Dados sintéticos são populares porque podem resolver gargalos recorrentes:

Escalar além da rotulagem humana

Conjuntos de dados de alta qualidade rotulados por humanos são caros e lentos. Dados sintéticos podem gerar grandes volumes rapidamente, especialmente para:

  • Exemplos de seguimento de instruções
  • Trajetórias de uso de ferramentas (chamar ferramenta → observar → raciocinar → responder)
  • Diálogos multi-turno para agentes
  • Saídas estruturadas (JSON, SQL, argumentos de função)

Cobertura de cenários raros ou arriscados

Logs reais sub-representam casos de borda (falhas raras, prompts adversariais, cenários críticos de segurança). Pipelines sintéticos podem mirar intencionalmente:

  • Intenções de usuário de cauda longa
  • Instruções ambíguas
  • Limites de políticas de segurança
  • Problemas de raciocínio “pegadinha”

Iteração mais rápida e melhorias direcionadas

Quando um modelo falha em um comportamento específico (por exemplo, citações, validade de JSON, estilo de recusa), você pode gerar lotes sintéticos de treinamento direcionados para corrigir aquela lacuna — frequentemente mais rápido do que coletar novas interações reais.

Vantagens de privacidade e conformidade (com ressalvas)

Dados sintéticos podem ajudar a reduzir a exposição a dados pessoais, mas não são automaticamente seguros em termos de privacidade. Um modelo ainda pode memorizar e vazar informações de treinamento, e a geração sintética pode reproduzir inadvertidamente texto sensível. Trate privacidade como um requisito de primeira classe, não como um benefício presumido.

Tipos comuns de dados sintéticos em GenAI

1) Instruções e respostas sintéticas (estilo SFT)

Um modelo gera pares instrução–resposta como:

  • Prompt: “Explique recursão com um exemplo em Python.”
  • Response: “Recursão é… aqui está o código…”

Isso é frequentemente usado para expandir conjuntos de dados de ajuste por instruções.

Decisão-chave de design: você gera apenas respostas para prompts existentes, ou também gera os próprios prompts? Gerar ambos aumenta a escala, mas aumenta o risco de se afastar do que os usuários realmente perguntam.

2) Rótulos e anotações sintéticos

Em vez de gerar novas entradas, você pode gerar rótulos para entradas existentes:

  • Tags de classificação (tópico, sentimento, categoria de política)
  • Entidades extraídas
  • Justificativas passo a passo (às vezes armazenadas, às vezes usadas de forma transitória)
  • Julgamentos do tipo “a saída seguiu o esquema JSON?”
  • Preferências pareadas (“A é melhor que B porque…”)

Isso é frequentemente chamado de rotulagem assistida por modelo (model-assisted labeling).

3) Trajetórias sintéticas de uso de ferramentas

Para sistemas agênticos (agentic systems) (veja Recuperação e Ferramentas), você pode gerar sequências como:

  1. Usuário faz uma pergunta
  2. Modelo decide pesquisar
  3. Modelo chama uma ferramenta (busca, banco de dados, calculadora)
  4. Modelo lê a saída da ferramenta
  5. Modelo responde com citações / saída estruturada

Esses rastros podem treinar melhor seleção de ferramentas e melhor formatação.

4) Conjuntos de avaliação sintéticos

Avaliações sintéticas são atraentes porque você pode gerar muitos casos de teste rapidamente e cobrir casos de borda. Exemplos incluem:

  • Suítes de prompts adversariais
  • Perguntas e respostas específicas de domínio com respostas conhecidas (quando geradas a partir de uma base de conhecimento estruturada)
  • Testes de conformidade de formato (JSON, XML, chamadas de função)
  • Regressões de conversas multi-turno

Importante: avaliação sintética é fácil de fazer mal — especialmente se a mesma família de modelos gerar tanto o teste quanto as respostas.

5) Dados sintéticos baseados em simulação

Para robótica, direção autônoma, sistemas de recomendação e certas tarefas multimodais, dados sintéticos podem vir de simuladores ou geradores procedurais (motores de física, cenas sintéticas). Para GenAI, simulação também pode significar “usuários simulados” ou “conversas simuladas”.

Fundamentos teóricos: o que você está otimizando (e o que pode dar errado)

Dados sintéticos como design de distribuição

O treinamento funciona melhor quando a distribuição de treinamento corresponde à distribuição de implantação. Dados sintéticos permitem projetar uma distribuição, mas você corre o risco de treinar em um mundo que existe apenas na imaginação do seu gerador.

Um modelo mental útil:

  • Distribuição de usuários reais: ( p_{\text{real}}(x, y) )
  • Distribuição do gerador sintético: ( p_{\text{syn}}(x, y) )

Treinando em uma mistura: [ p_{\text{train}} = \alpha , p_{\text{real}} + (1-\alpha), p_{\text{syn}} ] A escolha de (\alpha), além de quão bem (p_{\text{syn}}) cobre regiões úteis sem distorcer a realidade, determina se dados sintéticos ajudam.

Treinamento professor–aluno e destilação

Um padrão comum é um modelo professor (teacher) mais forte gerar dados para treinar um modelo aluno (student) mais barato. Isso se assemelha à destilação de conhecimento, mas com uma diferença importante: você não está apenas fazendo correspondência de logits — você está gerando novos exemplos de treinamento que refletem os comportamentos, vieses e pontos cegos do professor.

Ciclos de retroalimentação e “colapso do modelo”

Um ciclo de retroalimentação ocorre quando:

  1. Um modelo gera dados sintéticos.
  2. Esses dados são usados para treinar o próximo modelo (ou atualizar o mesmo modelo).
  3. O próximo modelo gera ainda mais dados, e assim por diante.

Se não for gerenciado, isso pode levar a:

  • Reforço de erros: padrões incorretos são repetidos e amplificados
  • Perda de diversidade: saídas tornam-se mais genéricas e com colapso de modos (mode collapse)
  • Amplificação de vieses: estereótipos e distribuições enviesadas se intensificam
  • Superotimização para idiossincrasias do gerador: o aluno aprende o estilo do professor em vez da tarefa

Isso às vezes é descrito como uma forma de degeneração distribucional (distributional degeneration): a distribuição sintética deriva gradualmente para longe da distribuição real.

Padrões práticos para gerar dados sintéticos de treinamento

Padrão A: Dados reais semente + expansão sintética

Você começa com um conjunto-semente curado (mesmo algumas centenas de exemplos) e então expande ao redor dele.

Exemplo: assistente de suporte ao cliente

  • Comece com 500 tickets reais (anonimizados).
  • Gere variantes:
    • Paráfrases do problema do usuário
    • Perguntas adicionais de esclarecimento
    • Versões “modo difícil” (detalhes faltando, informação conflitante)
  • Gere respostas que sigam sua política e guia de tom.

Isso mantém os dados sintéticos ancorados na intenção real do usuário.

Padrão B: Geração programática de prompts com restrições

Em vez de deixar o modelo inventar tudo, gere entradas via templates ou esquemas.

Exemplo: chamadas estruturadas de ferramenta

  • Você define um esquema JSON para argumentos da ferramenta.
  • Você gera muitas combinações programaticamente (válidas/inválidas/casos de borda).
  • O modelo aprende a produzir chamadas corretas e a lidar com erros.

Isso é especialmente eficaz para conformidade de formato e uso de ferramentas.

Padrão C: Pipelines no estilo self-instruct (com guardrails)

O modelo propõe tarefas e então as responde. Isso pode ser muito escalável, mas aumenta o risco de ciclos de retroalimentação.

Guardrails tipicamente incluem:

  • Restrições de diversidade (categorias de tópico, categorias de dificuldade)
  • Filtragem automática (remover duplicatas, baixa qualidade, conteúdo inseguro)
  • Revisão humana de uma amostra
  • Mistura com prompts reais

Padrão D: “Gerar múltiplos candidatos + selecionar”

Em vez de usar a primeira geração, produza vários candidatos e selecione o melhor via:

  • Um modelo de recompensa (reward model) (preditor de preferência)
  • Um modelo juiz (judge model) (LLM-como-juiz, com ressalvas conhecidas)
  • Checagens baseadas em regras (validação de esquema, testes unitários)
  • Avaliação humana para uma pequena fração

Isso reduz ruído e melhora consistência.

Padrão E: Dados sintéticos adversariais

Gere prompts projetados para quebrar o sistema:

  • Tentativas de injeção de prompt (relevante para Prompting)
  • Instruções ambíguas
  • Restrições conflitantes
  • Casos de borda de segurança

Use as falhas para criar dados direcionados de ajuste fino (veja Playbook de Ajuste Fino).

Exemplo prático: dados sintéticos de uso de ferramentas (pseudocódigo)

Abaixo está um padrão simplificado para gerar rastros de uso de ferramentas com validação automática.

import random
from jsonschema import validate, ValidationError

TOOL_SCHEMA = {
  "type": "object",
  "properties": {
    "city": {"type": "string"},
    "unit": {"type": "string", "enum": ["C", "F"]},
  },
  "required": ["city", "unit"]
}

def generate_user_query():
    cities = ["Tokyo", "Nairobi", "São Paulo", "Reykjavík"]
    return f"What is the weather in {random.choice(cities)} in Celsius?"

def model_generate_tool_call(user_query, model):
    # model returns something like: {"tool": "get_weather", "args": {...}}
    return model.tool_call(user_query)

def is_valid_tool_args(args):
    try:
        validate(instance=args, schema=TOOL_SCHEMA)
        return True
    except ValidationError:
        return False

def build_trace(model):
    q = generate_user_query()
    call = model_generate_tool_call(q, model)
    if call["tool"] != "get_weather":
        return None
    if not is_valid_tool_args(call["args"]):
        return None
    # Optionally simulate tool output, then ask model to write final answer.
    return {"user": q, "tool_call": call}

# Generate many traces, keep only validated ones.
traces = [build_trace(model) for _ in range(10000)]
traces = [t for t in traces if t is not None]

Por que isso funciona: o modelo é restringido por um esquema, e gerações inválidas são filtradas automaticamente — elevando a qualidade média do conjunto de dados sintético.

Dados sintéticos para avaliação: poderosos, mas fáceis de usar incorretamente

Para que avaliações sintéticas são boas

Conjuntos sintéticos de avaliação são especialmente úteis para:

  • Testes de regressão: “Quebramos a formatação de JSON?”
  • Testes de cobertura: “Lidamos com 200 variantes da mesma intenção?”
  • Sondas adversariais: “Seguimos a política sob pressão?”
  • Checagens tipo teste unitário para geração de código (compilar, rodar testes)

A maior armadilha: viés compartilhado do gerador

Se você gerar perguntas de teste e respostas de referência usando a mesma família de modelos que está avaliando, você corre o risco de medir “concordância com o gerador” em vez de correção real.

Mitigações:

  • Usar geradores independentes (famílias ou versões diferentes de modelos)
  • Usar fontes fundamentadas (por exemplo, gerar perguntas a partir de um banco de dados em que as respostas são conhecidas)
  • Usar avaliações escritas por humanos para capacidades críticas
  • Manter holdouts limpos e não sintéticos para decisões de alto impacto

Contaminação e vazamento

A avaliação sintética ainda pode ser contaminada:

  • O modelo pode ter visto itens sintéticos similares durante o treinamento.
  • O teste pode incluir inadvertidamente artefatos de treinamento.

Boas práticas incluem:

  • Rastreamento de proveniência do conjunto de dados
  • Deduplicação (detecção de quase-duplicatas via embeddings/minhash)
  • Separação estrita entre geradores e conjuntos de dados de treinamento vs avaliação

Entendendo ciclos de retroalimentação (e como evitá-los)

Como é um ciclo de retroalimentação em GenAI

Um ciclo típico:

  1. O modelo v1 gera pares sintéticos instrução–resposta.
  2. O modelo v2 é ajustado finamente nesses dados sintéticos.
  3. O modelo v2 gera ainda mais dados (frequentemente “mais limpos”, mas também mais estreitos).
  4. Com o tempo, o conjunto de dados passa a ser dominado pelo estilo e pelos erros do próprio modelo.

Isso pode acontecer mesmo que você também tenha dados reais, se o volume sintético os sobrepujar ou se os filtros de seleção preferirem saídas “com cara de modelo”.

Modos de falha

Reforço de erros

Se um modelo entende sistematicamente mal um conceito (por exemplo, orientação jurídica sutil), dados sintéticos replicarão esse equívoco em escala — tornando mais difícil corrigir depois.

Perda de diversidade (colapso de modos no espaço de dados)

Se seu processo de seleção recompensa respostas “seguras e genéricas”, seu conjunto de dados sintético fica sem graça. O modelo aprende a ser sem graça também, reduzindo utilidade.

Amplificação de vieses

Personas sintéticas ou “distribuições de usuários” sintéticas podem super-representar certas demografias, dialetos ou pontos de vista — especialmente se os prompts forem gerados pelo modelo sem restrições.

Overfitting ao juiz

Se você usa um juiz automatizado (outro modelo) para filtrar/selecionar, pode acabar otimizando para as preferências do juiz em vez da utilidade no mundo real.

Estratégias concretas para reduzir o risco de ciclos de retroalimentação

1) Sempre misture dados reais de alto sinal

Dados sintéticos normalmente deveriam ser uma minoria nas etapas de treinamento mais importantes, a menos que você tenha forte fundamentação (por exemplo, simulação com rótulos conhecidos).

Heurísticas práticas:

  • Manter uma proporção fixa de dados reais em cada época/batch.
  • Fazer upsample de dados humanos de alta qualidade em relação aos sintéticos.
  • Usar sintéticos principalmente para lacunas direcionadas, não como padrão.

2) Fundamentar tarefas sintéticas em verdade externa quando possível

Prefira geração sintética que seja restringida por algo verificável:

  • Um banco de dados (respostas conhecidas)
  • Testes unitários (para código)
  • Um simulador (para trajetórias)
  • Esquemas e validadores (para chamadas de ferramenta)
  • Geração fundamentada em recuperação (retrieval-grounded generation) (gerar perguntas a partir de documentos recuperados e então responder com citações)

Isso conecta a distribuição sintética à realidade, e não às crenças do próprio modelo. (Veja Recuperação e Ferramentas.)

3) Use modelos independentes para geração, julgamento e treinamento

Evite usar exatamente o mesmo checkpoint (ou a mesma família) para:

  • gerar dados sintéticos
  • julgá-los/filtrá-los
  • treinar o próximo modelo

Mesmo independência parcial ajuda:

  • Provedores/arquiteturas diferentes
  • Snapshots de treinamento diferentes
  • Estilos de prompting e temperaturas diferentes

4) Impor restrições de diversidade explicitamente

Não confie apenas em “temperatura”. Adicione estrutura:

  • Estratificação por tópico (cotas iguais por categoria de tópico)
  • Estratificação por dificuldade (fácil/médio/difícil)
  • Restrições de estilo (tons diferentes, comprimentos diferentes)
  • Cotas adversariais (injetar casos difíceis sistematicamente)

5) Filtre agressivamente, mas não filtre em direção à falta de graça

Filtros comuns:

  • Deduplicar itens quase idênticos
  • Remover respostas com pouca informação (“Depende…” sem detalhes)
  • Remover conteúdo que viola políticas
  • Remover citações alucinadas (se citações forem exigidas)

Mas também adicione filtros positivos:

  • Exigir passos concretos ou exemplos
  • Exigir verificações (por exemplo, código deve passar nos testes)
  • Exigir citações fundamentadas (se usar recuperação)

6) Manter holdouts “ouro” que nunca veem dados sintéticos

Para avaliação e alerta precoce:

  • Manter uma suíte de benchmarks curada por humanos.
  • Manter um conjunto de consultas de usuários reais (anonimizadas).
  • Nunca usar essas consultas como prompts para geração sintética.
  • Acompanhar deriva de desempenho ao longo do tempo.

Isso é essencial para detectar colapso sutil.

7) Rastrear proveniência e linhagem

Trate conjuntos de dados sintéticos como artefatos de software:

  • Qual modelo/versão gerador produziu?
  • Qual template de prompt?
  • Quais filtros e limiares?
  • Que fração foi revisada por humanos?
  • Quais execuções de treinamento consumiram?

Sem linhagem, você não consegue diagnosticar ciclos.

8) Considerar correção iterativa (“criticar e revisar”)

Se você precisar usar respostas geradas por modelo, use geração em múltiplas etapas:

  1. Resposta rascunho
  2. Crítica quanto a factualidade/política/formato
  3. Revisão
  4. Validação com testes/regras

Isso reduz propagação de erros — especialmente quando a validação é externa (testes/esquemas).

Dados sintéticos e ajuste fino: onde se encaixa

Dados sintéticos são mais comumente usados em:

  • Ajuste fino supervisionado para ensinar formatação, tom, uso de ferramentas, padrões de resposta de domínio
  • Treinamento por preferências (quando comparações sintéticas são confiáveis, frequentemente com calibração humana)
  • Ciclos de melhoria contínua em que novas falhas geram novos dados direcionados

Mas nem sempre é a melhor alavanca. Muitos comportamentos podem ser melhorados com:

Uma abordagem prática comum:

  • Usar prompting/RAG para tratar problemas de conhecimento
  • Usar ajuste fino (possivelmente com dados sintéticos) para tratar problemas de comportamento (formato, estilo de política, uso de ferramentas)

Um cenário trabalhado: construindo um conjunto de dados sintético sem um ciclo de retroalimentação

Objetivo: Melhorar um “assistente de SQL” interno que transforma linguagem natural em SQL.

  1. Fonte de verdade fundamental

    • Use um esquema real e um conjunto-semente de perguntas reais de negócio (mesmo 200–500).

  2. Expansão programática

    • Gere variantes de cada pergunta:
      • Formulações diferentes
      • Restrições adicionais (“últimos 30 dias”, “excluir reembolsos”)
      • Casos de ambiguidade (“principais clientes” → definir métrica)

  3. Geração pelo modelo

    • Peça a um modelo forte para gerar SQL.

  4. Validação externa

    • Execute o SQL contra um banco de dados de staging ou um validador de consultas.
    • Rejeite consultas que falhem ao analisar/parsear, referenciem tabelas inexistentes ou violem políticas.

  5. Seleção

    • Mantenha apenas itens validados; opcionalmente mantenha “negativos difíceis” (SQL inválido) para um classificador ou para treinar o modelo a se autocorrigir.

  6. Mistura de treinamento

    • Ajuste finamente em uma mistura:
      • 60% perguntas reais + SQL verificado por humanos
      • 40% itens sintéticos validados

  7. Avaliação independente

    • Avalie em um conjunto separado de perguntas reais que nunca foram usadas como sementes.
    • Acompanhe tanto correção de execução quanto restrições de segurança (por exemplo, sem deletes irrestritos).

Esse pipeline é pesado em sintéticos, mas ancorado em verdade externa (esquema + execução), o que reduz drasticamente o risco de ciclos de retroalimentação.

Limitações e desafios em aberto

  • Dados sintéticos não podem criar nova verdade fundamental do nada. Se o gerador não souber, ele vai chutar.
  • Confiabilidade do juiz é uma grande fraqueza: LLM-como-juiz pode ser inconsistente e enviesado, especialmente em tarefas nuançadas.
  • Transferência de estilo vs ganho de capacidade: SFT sintético frequentemente melhora formatação e consistência mais do que raciocínio profundo.
  • Deriva de distribuição: “usuários” sintéticos raramente correspondem a usuários reais; depender deles pode induzir decisões de produto ao erro.
  • Complexidades multimodais: para imagem/áudio/vídeo, a geração sintética pode introduzir artefatos aos quais modelos fazem overfitting.

Checklist de boas práticas

  • Use dados sintéticos para mirar lacunas específicas, não como substituição total de dados reais.
  • Ancore a geração sintética em restrições verificáveis (testes, esquemas, simuladores, recuperação).
  • Mantenha holdouts de dados reais e avaliações escritas por humanos para decisões críticas.
  • Evite usar o mesmo modelo para geração + julgamento + treinamento sempre que possível.
  • Rastreie proveniência e imponha higiene do conjunto de dados (dedup, checagens de vazamento).
  • Meça não apenas acurácia, mas também diversidade, calibração e robustez ao longo do tempo.

Resumo

Dados sintéticos são uma alavanca poderosa para GenAI porque podem escalar treinamento e avaliação, aumentar a cobertura de casos de borda e acelerar a iteração. O risco central são ciclos de retroalimentação — treinar modelos em suas próprias saídas de maneiras que amplificam erros, reduzem diversidade e derivam para longe das necessidades reais dos usuários. Os pipelines mais robustos de dados sintéticos são fundamentados, validados, misturados com dados reais e avaliados em benchmarks limpos e independentes.