Dados sintéticos: como gerar exemplos úteis para LLMs e testes

Documentação dos provedores e termos de uso dos resultados verificados em 22 de outubro de 2026. Os exemplos de chamados de suporte e os tamanhos do piloto apresentados abaixo foram criados para ilustrar o processo; não são resultados de um experimento com modelos.

O que é geração de dados sintéticos?

Gerar dados sintéticos é criar registros ou exemplos artificiais para uma finalidade definida. Para quem desenvolve com um modelo de linguagem de grande porte, ou LLM, isso costuma significar produzir textos — chamados de suporte, pares de perguntas e respostas, exemplos de extração ou conversas — a partir de uma especificação e de um pequeno conjunto de exemplos aprovados.

Pense em um simulador de direção. Ele permite praticar repetidamente uma situação difícil em um cruzamento sem esperar que ela aconteça na rua. Passar no simulador, porém, não revela com que frequência aquela situação ocorre no trânsito nem prova que você consegue dirigir em qualquer via. Os datasets sintéticos oferecem a mesma distinção útil entre a cobertura da prática e as evidências sobre o mundo real.

O método faz diferença. Um gerador baseado em regras segue instruções, como manter o total de um pedido igual à soma dos itens. Um sintetizador tabular aprende padrões entre colunas. Já um LLM gera linguagem condicionada por um prompt e pelo contexto fornecido. É possível combinar essas abordagens: o código cria um pedido válido, e o LLM escreve a reclamação do cliente sobre ele.

Dados sintéticos também são diferentes de registros mascarados. Trocar o nome de um cliente mantém o restante da história intacto. A ampliação de dados, ou data augmentation, modifica um exemplo existente — ao parafrasear uma pergunta, por exemplo —, mas as versões derivadas continuam ligadas à origem. Nenhuma dessas operações torna um registro privado automaticamente nem produz evidências independentes.

Avaliações: crie desafios com respostas verificadas de forma independente

Para quem desenvolve aplicações, as avaliações sintéticas são mais úteis quando exploram falhas conhecidas: informações ausentes, instruções conflitantes, solicitações fora do escopo e formulações incomuns. Uma avaliação, ou eval, é um teste repetível do comportamento do sistema.

Se um assistente de suporte deve pedir esclarecimentos quando um problema de conta é ambíguo, gere solicitações ambíguas de propósito. Peça a alguém que confira a ação esperada com base na política. A resposta do gerador não deve virar gabarito só porque parece convincente.

Mantenha um conjunto de avaliação separado, extraído de interações reais cujo uso seja permitido, quando elas estiverem disponíveis. Se não puder usar interações reais, encomende casos escritos de forma independente por alguém que conheça a tarefa. Isso permite conferir a especificação, mas não estabelecer a acurácia para toda a população atendida em produção.

Fine-tuning: ensine um comportamento específico

Para quem adapta um modelo, exemplos sintéticos podem demonstrar um formato, uma regra de classificação ou um estilo de resposta pouco representado nos dados disponíveis. Fine-tuning é a atualização de um modelo por meio de treinamento com exemplos.

Comece por uma falha observável: o modelo insiste em encaminhar chamados ambíguos para cobrança. Acrescente casos de ambiguidade revisados e compare o modelo adaptado com a versão de referência em exemplos que não foram usados no processo. Um arquivo de treinamento maior, por si só, não é uma métrica de sucesso.

Recorra ao fluxo de trabalho de fine-tuning quando a tarefa e o conjunto de aceitação estiverem estáveis. Se o problema for a falta de contexto factual ou informações que mudam, corrija o contexto fornecido à aplicação antes de tentar ensinar fatos por meio de respostas geradas.

Como gerar dados de teste sintéticos

Para quem desenvolve software, a geração de dados de teste sintéticos deve colocar as regras da aplicação à prova: campos ausentes, envios duplicados, textos com comprimentos incomuns, transições de estado inválidas e registros relacionados no banco de dados.

Um teste de checkout precisa de relações válidas entre pedidos, clientes e pagamentos. Não precisa que um modelo de linguagem invente a aritmética. Implemente essas restrições em código e use um LLM quando a linguagem realista agregar valor, como em uma observação de entrega que contradiz o endereço de envio.

Quem compra um dataset deve perguntar a qual desses objetivos ele atende. Um conjunto adequado para uma demonstração não é necessariamente útil para treinamento, e um corpus de treinamento não se torna automaticamente um conjunto de avaliação.

Exemplo prático: dos casos iniciais aos candidatos revisados

Comece com uma tarefa bem delimitada, cujas respostas corretas você consiga explicar sem consultar o gerador. Este passo a passo cria exemplos candidatos para encaminhar chamados fictícios de suporte às categorias billing, access ou human_review.

A política fictícia é simples: problemas com pagamentos e faturas vão para cobrança; problemas de login e senha vão para acesso; solicitações pouco claras ou que combinam os dois tipos vão para revisão humana. Não deduza fatos que o cliente não informou.

Exemplos de dados sintéticos: seis casos iniciais com rótulos explícitos

Use estes exemplos criados para mostrar os limites entre as categorias:

• “Meu cartão foi cobrado duas vezes.” → billing
• “Esta fatura mostra o plano errado.” → billing
• “O link de redefinição expirou.” → access
• “Não consigo entrar depois de redefinir minha senha.” → access
• “Eu paguei, mas não consigo entrar.” → human_review
• “Ainda não funciona.” → human_review

Os últimos exemplos são tão importantes quanto os mais óbvios. Eles ensinam ao gerador que a incerteza é um resultado válido. O guia de few-shot prompting explica como exemplos comunicam regras que uma instrução genérica pode deixar em aberto.

Um candidato após a limpeza poderia ficar assim. Este registro é ilustrativo, não uma saída capturada de uma API:

{
  "case_id": "billing-frustrated-indirect-a",
  "text": "Another invoice with the wrong plan, seriously?",
  "proposed_label": "billing",
  "policy_reason": "The customer identifies an invoice problem."
}

O resultado que importa é um caso rastreável e revisado. Se o gerador entregou todos os candidatos solicitados na primeira tentativa é secundário. Nunca complete uma célula fraca só para atingir a quantidade prevista.

Ferramentas para gerar dados sintéticos: o que a documentação promete

Escolha as ferramentas pela parte do processo que elas controlam. A API de um modelo é a interface que seu código usa para solicitar respostas; o serviço de processamento em lote agenda essas solicitações. Uma biblioteca de datasets organiza a geração e o feedback. Um sintetizador tabular aprende relações em dados estruturados. Nenhuma dessas funções substitui seus critérios de aceitação.

IA generativa para dados sintéticos: APIs de processamento em lote

A API da OpenAI oferece o Batch para solicitações assíncronas enviadas em um arquivo JSONL, formato com um objeto JSON por linha. A documentação exige um custom_id exclusivo e alerta que a ordem das respostas pode ser diferente da ordem de entrada. Associe os resultados pelo identificador e inspecione falhas e gerações incompletas antes de extrair os candidatos. Documentação do OpenAI Batch.

A API do Claude, da Anthropic, oferece Message Batches para solicitações independentes à API Messages. Os resultados distinguem solicitações concluídas com sucesso, com erro, canceladas e expiradas, e o custom_id conecta cada resultado à respectiva entrada. O limite aqui é operacional: a aceitação de um lote não prova que todos os exemplos foram concluídos. Reenvie o que faltou pelo identificador, em vez de gerar o dataset inteiro novamente. Documentação de processamento em lote do Claude.

A API do Gemini, do Google, oferece Batch com objetos de solicitação enviados diretamente ou com um arquivo JSONL carregado. As solicitações baseadas em arquivo têm uma key que identifica o resultado correspondente. Use arquivos para datasets maiores processados offline; o prazo documentado é uma meta, portanto evite fazer um fluxo interativo depender da conclusão imediata. Documentação do Gemini Batch.

Estes são os limites por lote que afetam a divisão do processamento, verificados nas documentações vinculadas. Eles não limitam o tamanho total do dataset que você pode construir com vários lotes.

Uma solicitação em lote e um exemplo candidato são unidades diferentes. Se cada solicitação bem-sucedida retorna vários candidatos, acompanhe as duas contagens. Registre falhas de interpretação dos dados, recusas e saídas truncadas junto com os erros de transporte. Uma resposta HTTP bem-sucedida, sozinha, não produz uma linha utilizável para treinamento.

Distilabel: organize a geração e o feedback

Distilabel é um framework de dados sintéticos e feedback de IA que reúne etapas de geração, avaliação e tratamento de dados em pipelines. A documentação descreve usos em classificação, extração, diálogo e geração de instruções. Ele é útil quando um script pontual evolui para várias etapas de geração e filtragem. Documentação do Distilabel.

O projeto usa a licença Apache-2.0. O repositório também informa que os autores originais seguiram para outros projetos e que colaboradores da comunidade cuidam da manutenção. Fixe e valide a versão que adotar. O limite prático continua sendo o avaliador: orquestrar o julgamento de um modelo não torna esse julgamento independente nem correto. Repositório do Distilabel.

Faker: crie dados de teste sem um modelo de linguagem

Faker é um pacote Python que gera dados fictícios por meio de provedores, com suporte a localidades e sementes para geração aleatória. É útil para criar fixtures de aplicações quando você precisa de campos controlados, e não de raciocínio em linguagem natural. O repositório identifica a licença como MIT. Documentação do Faker, repositório do Faker.

Você ainda precisa codificar as relações de negócio. Endereços, datas e transações gerados de forma independente não estabelecem um histórico de cliente realista. Use identificadores e domínios reservados para testes sempre que possível e impeça que as fixtures geradas acionem mensagens ou outras ações em produção.

Synthetic Data Vault: modele tabelas e suas relações

Synthetic Data Vault, ou SDV, oferece síntese tabular e avaliação estatística, com abordagens documentadas para tabelas únicas, dados sequenciais e tabelas relacionadas. Os sintetizadores treinados aprendem com os dados que você fornece; eles não eliminam a necessidade de um dataset de origem cujo uso seja permitido. Documentação do SDV.

No SDV, o GaussianCopulaSynthesizer usa métodos estatísticos clássicos para aprender distribuições de colunas e relações entre elas. O CTGANSynthesizer usa uma rede adversarial generativa, modelo treinado com um gerador e um discriminador que competem entre si. Ambos recebem dados e metadados que descrevem sua estrutura. São sintetizadores tabulares, não modelos de chat de uso geral. Documentação do Gaussian Copula, documentação do CTGAN.

O limite é a fidelidade à tarefa. Distribuições de colunas que parecem semelhantes não provam que combinações raras, regras entre tabelas ou o comportamento de um modelo que usará esses dados foram preservados. Valide as relações das quais sua aplicação depende, incluindo chaves estrangeiras que vinculam registros filhos a registros pais.

Escolha o gerador de dados sintéticos pelo que falta comprovar

Use uma API de modelo quando faltar variação de linguagem. Acrescente Distilabel quando a orquestração repetível de geração e feedback justificar a dependência extra. Escolha Faker quando as fixtures precisarem de valores controlados. Considere SDV quando as relações estatísticas entre tabelas forem importantes e você tiver dados de origem que possa usar na modelagem.

Não compre um gerador maior para resolver uma política de rotulagem pouco clara. Esse problema vem antes de qualquer ferramenta apresentada aqui.

O que os termos dos provedores dizem sobre treinar com as respostas

Confira as restrições de uso dos resultados antes de escolher um modelo professor, isto é, o modelo que gera exemplos para outro modelo aprender. Os pontos abaixo resumem os termos padrão dos três provedores de LLMs hospedados apresentados acima; eles não atestam que um projeto de treinamento específico se enquadre nas condições.

• OpenAI: O Services Agreement restringe o uso de resultados para desenvolver modelos de IA concorrentes, com exceções expressas para modelos voltados principalmente a categorizar, classificar ou organizar dados, desde que não sejam distribuídos nem disponibilizados comercialmente a terceiros, e para a personalização de modelos por meio dos serviços especificados pela OpenAI. Contrato de serviços.
• Anthropic: Os Commercial Terms proíbem acessar os serviços para criar produtos ou serviços concorrentes, incluindo treinar modelos de IA concorrentes, salvo aprovação expressa da Anthropic. Termos comerciais.
• Google: Os termos adicionais da API do Gemini proíbem o uso dos serviços para desenvolver modelos concorrentes; as disposições sobre Google Search Grounding proíbem, separadamente, treinar com Grounded Results ou Search Suggestions. Termos da API do Gemini.

A licença de uma biblioteca é uma questão separada dos termos do modelo que ela chama, da licença dos pesos de qualquer modelo e dos seus direitos sobre os exemplos de origem. A titularidade dos resultados, sozinha, não resolve todas essas questões.

A privacidade dos dados de teste exige uma verificação própria

A origem sintética não garante privacidade. Se você copiar registros confidenciais para um serviço de geração não aprovado, produzir depois substitutos com aparência fictícia não desfaz essa divulgação.

A pesquisa de Stadler, Oprisanu e Troncoso sobre publicação de dados sintéticos constatou que os ganhos de privacidade e a utilidade variavam entre os modelos avaliados. A lição prática é avaliar os dados liberados e o processo de geração, em vez de tratar a palavra “sintético” como um certificado de anonimato. Artigo de pesquisa da USENIX.

Prefira exemplos iniciais fictícios, escritos a partir de um esquema e de uma política aprovados, quando isso bastar para os testes de software. Quando for necessário preservar padrões estatísticos reais, mantenha o tratamento das fontes em um ambiente aprovado e avalie quais informações o dataset gerado pode revelar.

Procure identificadores diretos, trechos copiados, combinações raras e vínculos com informações que alguém já possa conhecer. Trocar um nome e preservar um episódio peculiar, o local e a data pode manter a pessoa reconhecível. Para liberações sensíveis, algumas verificações manuais por amostragem e uma busca por duplicatas não bastam; a avaliação de privacidade precisa corresponder à ameaça e aos destinatários previstos.

As políticas dos provedores sobre uso de dados para treinamento respondem a uma pergunta diferente do seu direito de treinar com os resultados. Por exemplo, os termos dos serviços gratuitos do Gemini alertam contra o envio de informações sensíveis, enquanto os termos de uso de dados dos serviços pagos dizem que prompts e respostas não são usados para melhorar os produtos do Google. Os termos também aplicam as regras de uso de dados dos serviços pagos ao uso gratuito no EEE, na Suíça e no Reino Unido. Termos de uso de dados do Gemini.

Nem o compromisso de um provedor de não usar os dados para treinamento nem a execução local provam que o dataset resultante seja seguro para compartilhar. Mantenha a procedência e os controles de acesso vinculados a ele até concluir a revisão de liberação.

Onde está o exagero sobre dados sintéticos?

O maior exagero é dizer que mais linhas geradas resolvem a falta de evidências. Elas podem ampliar a prática e expor falhas, mas também reproduzir as mesmas suposições em escala.

Textos diferentes podem esconder situações repetidas

Um dataset pode conter frases distintas e ainda assim repetir um conjunto minúsculo de situações. Acompanhe a cobertura dos cenários depois da filtragem: quais regras de negócio, ambiguidades e tipos de falha continuam representados?

No exemplo dos chamados, reclamações repetidas sobre faturas não compensam a ausência de solicitações que combinam cobrança e acesso. Revise os vizinhos mais próximos e examine tanto os exemplos rejeitados quanto os aceitos. Um filtro de qualidade rigoroso demais pode remover silenciosamente os casos difíceis que você queria acrescentar.

O viés pode sobreviver à reescrita

Não presuma que parafrasear um exemplo inicial enviesado elimina suas suposições. Revise as escolhas de rótulos considerando estilo de linguagem, dialeto, qualidade da ortografia e grupos de usuários relevantes. Uma solicitação com tom frustrado ou erros de escrita não deve receber outro encaminhamento, a menos que a política justifique essa distinção.

Peça aos revisores que comparem pares de casos em que apenas um atributo irrelevante muda. Se os rótulos mudarem, investigue o exemplo inicial, o prompt e o filtro em conjunto. Um gerador e um avaliador podem reforçar o mesmo erro.

Um modelo corrigindo a própria prova pode parecer convincente

Zheng e seus colegas documentaram vieses de posição, verbosidade e favorecimento das próprias respostas em LLMs avaliadores. Um modelo pode premiar a redação ou a apresentação em vez da propriedade que você pretendia medir. Pesquisa sobre LLM-as-a-judge.

Use verificações determinísticas sempre que a resposta puder ser conferida mecanicamente. Para critérios subjetivos, calibre o avaliador com base em decisões humanas, oculte a identidade do gerador quando for viável e revise as divergências. Trocar o provedor do avaliador pode reduzir uma dependência compartilhada; isso não garante erros independentes.

O guia de LLM-as-a-judge explica como verificar o avaliador antes de confiar em sua nota. Na geração sintética, essa verificação deve acontecer antes de o avaliador decidir quais exemplos serão tratados como corretos no treinamento.

O colapso de modelos é um risco específico, não uma sentença universal

Shumailov e seus colegas estudaram o treinamento recursivo com dados gerados e mostraram como partes menos comuns da distribuição original podem desaparecer. Isso justifica cautela ao substituir repetidamente as evidências de origem por exemplos derivados do próprio modelo. Não demonstra que todo fine-tuning com dados sintéticos revisados para uma tarefa específica esteja fadado ao fracasso. Artigo de pesquisa na Nature.

Mantenha as evidências originais cujo uso seja permitido, preserve deliberadamente os casos raros e compare o comportamento resultante com uma referência intocada. Não existe uma proporção universal entre dados sintéticos e reais que substitua essa avaliação.

O que mudar na prática a partir de segunda-feira

Comece agora se você consegue apontar um caso ausente, escrever o comportamento correto e revisar os candidatos gerados com base em uma regra estável. Comece pela pequena grade de cobertura e expanda apenas as células que acrescentam casos úteis.

Adie o fine-tuning se os revisores discordam dos rótulos-alvo ou se falta um conjunto de aceitação independente. Resolva primeiro a política e a avaliação.

Use fixtures comuns se a tarefa for preencher um banco de dados, testar valores-limite ou verificar a integridade de transações. Acrescente linguagem gerada apenas quando ela exercitar um comportamento que dados mais simples não alcançam.

Antes da próxima versão, compare o sistema de referência e o sistema alterado nos mesmos casos intocados. No classificador de suporte, examine por categoria os encaminhamentos incorretos e os casos que deveriam ter sido escalados e não foram. Mantenha os dados sintéticos apenas se melhorarem o comportamento pretendido sem regressões inaceitáveis em outras áreas.

Perguntas frequentes sobre dados sintéticos

Assine a newsletter para receber guias práticos sobre como criar e avaliar sistemas de IA.