Datos sintéticos: cómo generarlos para LLM y pruebas de software

Documentación de proveedores y condiciones de uso de los resultados verificadas el 22 de octubre de 2026. Los ejemplos de solicitudes de soporte y los tamaños del piloto que aparecen a continuación se han creado para ilustrar el proceso; no describen un experimento realizado con un modelo.

¿Qué es la generación de datos sintéticos?

La generación de datos sintéticos consiste en crear registros o ejemplos artificiales para un fin concreto. Al trabajar con un modelo de lenguaje de gran tamaño, o LLM, suele significar producir textos como solicitudes de soporte, pares de preguntas y respuestas, ejemplos de extracción o conversaciones a partir de una especificación y un pequeño conjunto de ejemplos aprobados.

Pensemos en un simulador de conducción. Permite practicar una y otra vez un cruce difícil sin esperar a que esa situación se presente en la carretera. Superar la simulación no demuestra con qué frecuencia aparece ese cruce en el tráfico ni que se pueda conducir por cualquier vía. Los conjuntos de datos sintéticos ofrecen esa misma separación útil entre los casos que se practican y la evidencia sobre el mundo real.

El método importa. Un generador basado en reglas sigue instrucciones como mantener el total de un pedido igual a la suma de sus partidas. Un sintetizador de datos tabulares aprende patrones entre columnas. Un LLM genera lenguaje condicionado por un prompt y por el contexto que recibe. Se pueden combinar: el código crea un pedido válido y el LLM redacta la queja del cliente sobre ese pedido.

Generar datos sintéticos tampoco equivale a enmascarar un registro. Sustituir el nombre de un cliente deja intacto el resto de su historia. El aumento de datos modifica un ejemplo existente, por ejemplo al reformular una pregunta; las variantes siguen vinculadas al original. Ninguna de estas operaciones protege automáticamente la privacidad del registro ni crea evidencia independiente.

Evaluaciones: casos difíciles con respuestas verificadas de forma independiente

Al desarrollar una aplicación, las evaluaciones sintéticas resultan especialmente útiles para fallos conocidos: información incompleta, instrucciones contradictorias, solicitudes que el sistema no puede atender y formas poco habituales de expresarse. Una evaluación, o eval, es una prueba repetible del comportamiento del sistema.

Si un asistente de soporte debe pedir aclaraciones cuando un problema de cuenta es ambiguo, hay que generar solicitudes ambiguas de forma deliberada. Una persona debe comprobar la acción esperada frente a las reglas de atención. La respuesta del generador no debe convertirse en la respuesta de referencia solo porque suene convincente.

Cuando sea posible, mantén un conjunto de evaluación separado con interacciones reales cuyo uso esté permitido. Si no puedes utilizarlas, encarga casos independientes a alguien que conozca la tarea. Eso permite comprobar la especificación, pero no determinar la precisión en toda la población que usa el sistema en producción.

Ajuste fino: enseñar un comportamiento concreto

Al adaptar un modelo, los ejemplos sintéticos pueden mostrar un formato, una regla de clasificación o un estilo de respuesta poco representado en los datos disponibles. El ajuste fino, o fine-tuning, consiste en actualizar un modelo mediante el entrenamiento con ejemplos.

Parte de un fallo observable: el modelo sigue enviando solicitudes ambiguas al área de facturación. Añade casos de ambigüedad revisados y compara el modelo adaptado con la referencia actual usando ejemplos que se hayan mantenido intactos. Aumentar el tamaño del archivo de entrenamiento no es, por sí solo, una medida de éxito.

Sigue el proceso de ajuste fino cuando la tarea y el conjunto de aceptación sean estables. Si el problema es que falta contexto factual o que este cambia, corrige primero el contexto que recibe la aplicación antes de intentar enseñarle hechos mediante respuestas generadas.

Generación de datos sintéticos para pruebas de software

En el desarrollo de software, los datos sintéticos para pruebas deben poner a prueba las reglas de la aplicación: campos ausentes, envíos duplicados, textos de longitudes inusuales, transiciones de estado inválidas y registros relacionados en la base de datos.

Una prueba del proceso de compra necesita relaciones válidas entre pedidos, clientes y pagos. No necesita que un modelo de lenguaje invente la aritmética. Implementa esas restricciones en código y utiliza un LLM donde un lenguaje realista aporte valor, por ejemplo en una nota de entrega que contradiga la dirección de envío.

Quien compra un conjunto de datos debe preguntar a cuál de estas tareas responde. Un conjunto adecuado para una demostración no necesariamente sirve para entrenar, y un corpus de entrenamiento no se convierte automáticamente en un conjunto de evaluación.

Un ejemplo completo: de los casos iniciales a los candidatos revisados

Empieza con una tarea acotada cuyas respuestas correctas puedas explicar sin consultar al generador. Este procedimiento crea ejemplos candidatos para clasificar solicitudes ficticias de soporte como billing, access o human_review.

Las reglas ficticias son sencillas: los problemas con pagos y facturas van a facturación; los de inicio de sesión y contraseñas, a acceso; las solicitudes poco claras o que combinan ambos tipos, a revisión humana. No se deben inferir hechos que el cliente no haya aportado.

Ejemplos de datos sintéticos: seis casos iniciales con etiquetas explícitas

Estos casos creados para el ejemplo muestran dónde está el límite:

• «Me cobraron dos veces en la tarjeta». → billing
• «Esta factura indica un plan incorrecto». → billing
• «El enlace para restablecer la contraseña caducó». → access
• «No puedo iniciar sesión después de restablecer mi contraseña». → access
• «Pagué, pero no puedo iniciar sesión». → human_review
• «Sigue sin funcionar». → human_review

Los últimos ejemplos importan tanto como los evidentes. Enseñan al generador que la incertidumbre es un resultado válido. La guía de few-shot prompting explica cómo los ejemplos transmiten reglas que una instrucción general puede dejar poco claras.

Un candidato depurado podría tener este aspecto. Es un registro ilustrativo, no una respuesta capturada de una 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."
}

El resultado que importa es un caso revisado y trazable. Que el generador inicial haya devuelto todos los candidatos solicitados es secundario. Nunca rellenes una celda deficiente solo para alcanzar la cantidad objetivo.

Herramientas para generar datos sintéticos: qué ofrece su documentación

Elige las herramientas según la parte del proceso que controlan. La API de un modelo es la interfaz que usa tu código para solicitar respuestas; su servicio por lotes programa esas solicitudes. Una biblioteca de conjuntos de datos organiza la generación y la retroalimentación. Un sintetizador tabular aprende relaciones en datos estructurados. Ninguna de esas funciones sustituye tus criterios de aceptación.

IA generativa para crear datos sintéticos: las API por lotes

OpenAI API ofrece Batch para solicitudes asíncronas enviadas en un archivo JSONL, con un objeto JSON por línea. Su documentación exige un custom_id único y advierte que el orden de salida puede diferir del de entrada. Asocia los resultados por identificador y revisa los fallos y las generaciones incompletas antes de procesar los candidatos. Documentación de OpenAI Batch.

Claude API, de Anthropic, ofrece Message Batches para solicitudes independientes de Messages. Los resultados distinguen entre solicitudes completadas con éxito, con errores, canceladas y caducadas, y custom_id vincula cada resultado con su entrada. La limitación es operativa: que un lote haya sido aceptado no demuestra que todos sus ejemplos se hayan completado. Reintenta el trabajo pendiente por identificador en lugar de regenerar todo el conjunto de datos. Documentación de lotes de Claude.

Gemini API, de Google, ofrece Batch con objetos de solicitud incluidos directamente o mediante un archivo JSONL cargado. Las solicitudes basadas en archivos llevan una key que identifica el resultado correspondiente. Usa la opción de archivo para conjuntos más grandes procesados sin interacción en tiempo real; el plazo documentado es un objetivo, así que evita que un flujo interactivo dependa de una finalización inmediata. Documentación de Gemini Batch.

Estos límites por lote, verificados en la documentación enlazada, determinan cómo dividir los trabajos. No limitan el tamaño total del conjunto de datos que puedes crear mediante varios trabajos.

Una solicitud por lotes y un ejemplo candidato son unidades distintas. Si cada solicitud completada devuelve varios candidatos, registra ambos recuentos. Anota los fallos de procesamiento, las negativas del modelo y las salidas truncadas junto con los errores de transporte. Una respuesta HTTP correcta no basta para obtener una fila útil para entrenamiento.

Distilabel: organizar la generación y la retroalimentación

Distilabel es un framework para datos sintéticos y retroalimentación de IA que combina etapas de generación, evaluación y manejo de datos en flujos de procesamiento. Su documentación describe casos de uso de clasificación, extracción, diálogo y generación de instrucciones. Resulta útil cuando un script puntual ha crecido hasta incorporar varias etapas de generación y filtrado. Documentación de Distilabel.

El proyecto utiliza la licencia Apache-2.0. Su repositorio también indica que los autores originales dejaron el proyecto y que colaboradores de la comunidad se encargan del mantenimiento. Fija y valida la versión que adoptes. La limitación práctica sigue siendo el evaluador: coordinar el juicio de un modelo no lo vuelve independiente ni correcto. Repositorio de Distilabel.

Faker: crear datos de prueba sin un modelo de lenguaje

Faker es un paquete de Python que genera datos ficticios mediante proveedores, con soporte de configuración regional y semillas aleatorias. Sirve para crear datos de prueba de aplicaciones, o fixtures, cuando necesitas campos controlados en lugar de razonamiento en lenguaje natural. Su repositorio identifica la licencia como MIT. Documentación de Faker, repositorio de Faker.

Aun así, debes codificar las relaciones de negocio. Generar direcciones, fechas y transacciones de forma independiente no crea un historial de cliente realista. Utiliza identificadores y dominios reservados para pruebas siempre que sea posible, y evita que los datos generados activen mensajes u otras acciones en producción.

Synthetic Data Vault: modelar tablas y sus relaciones

Synthetic Data Vault, o SDV, ofrece síntesis tabular y evaluación estadística, con métodos documentados para tablas individuales, datos secuenciales y tablas relacionadas. Sus sintetizadores entrenados aprenden de los datos que les proporcionas; no eliminan la necesidad de contar con un conjunto de origen cuyo uso esté permitido. Documentación de SDV.

Dentro de SDV, GaussianCopulaSynthesizer utiliza métodos estadísticos clásicos para aprender distribuciones y relaciones entre columnas. CTGANSynthesizer utiliza una red generativa adversaria, un modelo que se entrena mediante un generador y un discriminador que compiten entre sí. Ambos reciben datos y metadatos que describen su estructura. Son sintetizadores tabulares, no modelos de chat de propósito general. Documentación de Gaussian Copula, documentación de CTGAN.

La limitación está en la fidelidad a la tarea. Que las distribuciones de las columnas se parezcan no demuestra que se conserven las combinaciones poco frecuentes, las reglas entre tablas o el comportamiento de un modelo que use esos datos después. Valida las relaciones de las que depende tu aplicación, incluidas las claves foráneas que vinculan registros hijos con sus registros padres.

Elige el generador de datos sintéticos según la evidencia que falte

Usa la API de un modelo cuando lo que falte sea variedad lingüística. Añade Distilabel cuando la coordinación repetible de generación y retroalimentación justifique una dependencia adicional. Elige Faker cuando los datos de prueba necesiten valores controlados. Considera SDV cuando importen las relaciones estadísticas entre tablas y dispongas de datos de origen que tengas permiso para modelar.

No compres un generador más grande para resolver unas reglas de etiquetado poco claras. Ese problema debe resolverse antes de usar cualquiera de estas herramientas.

Qué permiten los proveedores al entrenar con sus resultados

Comprueba las restricciones de uso de los resultados antes de elegir un modelo maestro, es decir, el modelo que generará ejemplos para que otro aprenda de ellos. Los puntos siguientes resumen las condiciones estándar de los tres proveedores de LLM alojados mencionados antes; no afirman que un proyecto de entrenamiento concreto cumpla sus requisitos.

• OpenAI: Su acuerdo de servicios restringe el uso de los resultados para desarrollar modelos de IA competidores, con excepciones expresas para modelos dedicados principalmente a categorizar, clasificar u organizar datos que no se distribuyan ni se pongan a disposición comercial de terceros, y para personalizar modelos mediante los servicios especificados por OpenAI. Acuerdo de servicios.
• Anthropic: Sus condiciones comerciales prohíben acceder a los servicios para crear productos o servicios competidores, incluido el entrenamiento de modelos de IA competidores, salvo aprobación expresa de Anthropic. Condiciones comerciales.
• Google: Las condiciones adicionales de Gemini API prohíben utilizar los servicios para desarrollar modelos competidores; por separado, las disposiciones de Google Search Grounding prohíben entrenar con Grounded Results o Search Suggestions. Condiciones de Gemini API.

La licencia de software de una biblioteca es una cuestión distinta de las condiciones del modelo al que llama, de la licencia de sus pesos y de tus derechos sobre los ejemplos de origen. La titularidad de los resultados no resuelve por sí sola todas esas cuestiones.

La privacidad de los datos de prueba exige una revisión propia

El origen sintético no garantiza la privacidad. Si copias registros confidenciales en un servicio de generación no aprobado, producir después sustitutos de apariencia ficticia no revierte esa divulgación.

La investigación de Stadler, Oprisanu y Troncoso sobre la publicación de datos sintéticos encontró que las mejoras de privacidad y la utilidad variaban entre los modelos evaluados. La lección práctica es evaluar tanto los datos publicados como el proceso de generación, en lugar de tratar la palabra «sintético» como un certificado de anonimato. Artículo de investigación de USENIX.

Da preferencia a ejemplos iniciales ficticios redactados a partir de un esquema y unas reglas aprobados cuando eso baste para las pruebas de software. Si necesitas conservar patrones estadísticos reales, maneja las fuentes dentro de un entorno aprobado y evalúa qué información puede revelar el conjunto generado.

Revisa los identificadores directos, los pasajes copiados, las combinaciones poco frecuentes y los vínculos con información que alguien ya podría conocer. Sustituir un nombre mientras se conservan un incidente singular, un lugar y una fecha puede dejar reconocible a la persona. Para publicar datos sensibles, unas pocas comprobaciones manuales y una búsqueda de duplicados no bastan; la evaluación de privacidad debe ajustarse a la amenaza y a los destinatarios previstos.

Las políticas de entrenamiento del proveedor responden a una pregunta distinta de tu derecho a entrenar con sus resultados. Por ejemplo, las condiciones de los servicios gratuitos de Gemini advierten que no se debe enviar información sensible, mientras que las condiciones de uso de datos de sus servicios de pago indican que los prompts y las respuestas no se utilizan para mejorar los productos de Google. Esas condiciones también aplican las reglas de uso de datos de los servicios de pago al uso gratuito en el EEE, Suiza y el Reino Unido. Condiciones de uso de datos de Gemini.

Ni el compromiso de un proveedor de no entrenar con los datos ni la ejecución local demuestran que sea seguro compartir el conjunto resultante. Mantén asociados sus datos de procedencia y sus controles de acceso hasta que finalice la revisión previa a su publicación.

¿Qué se exagera sobre los datos sintéticos?

La mayor exageración es que generar más filas resuelve la falta de evidencia. Pueden ampliar la práctica y revelar fallos, pero también reproducir los mismos supuestos a gran escala.

Distintas palabras pueden ocultar las mismas situaciones

Un conjunto puede contener oraciones distintas y aun así repetir un repertorio mínimo de situaciones. Comprueba la cobertura de escenarios después del filtrado: ¿qué reglas de negocio, ambigüedades y tipos de fallo siguen representados?

En el ejemplo de soporte, repetir quejas sobre facturas no compensa la ausencia de solicitudes que combinan facturación y acceso. Revisa los ejemplos más cercanos por similitud e inspecciona tanto los rechazados como los aceptados. Un filtro de calidad demasiado estricto puede eliminar sin que lo adviertas los casos difíciles que intentabas incorporar.

Reformular no siempre elimina el sesgo

No des por hecho que parafrasear un ejemplo inicial sesgado elimina sus supuestos. Revisa las decisiones de etiquetado según el estilo lingüístico, el dialecto, la calidad ortográfica y los grupos de usuarios pertinentes. Una solicitud frustrada o mal escrita no debería enviarse a otra categoría a menos que las reglas justifiquen esa diferencia.

Pide a quienes revisan que comparen casos equivalentes en los que solo cambie un atributo irrelevante. Si cambian las etiquetas, investiga conjuntamente el ejemplo inicial, el prompt y el filtro. El generador y el evaluador pueden reforzar el mismo error.

Un modelo que corrige sus propios ejercicios puede resultar convincente

Zheng y sus colaboradores documentaron sesgos de posición, de preferencia por respuestas extensas y de preferencia por las propias respuestas en LLM evaluadores. Un modelo puede premiar la redacción o la presentación en lugar de la propiedad que se pretendía medir. Investigación sobre LLM como evaluadores.

Usa comprobaciones deterministas siempre que la respuesta pueda verificarse mecánicamente. Para las evaluaciones subjetivas, calibra el evaluador frente a decisiones humanas, oculta la identidad del generador cuando sea viable y revisa los desacuerdos. Cambiar de proveedor del evaluador puede reducir una dependencia compartida; no garantiza que sus errores sean independientes.

La guía de LLM como evaluadores explica cómo comprobar el evaluador antes de confiar en su puntuación. En la generación sintética, esa comprobación debe hacerse antes de que el evaluador decida qué ejemplos se tomarán como correctos para entrenar.

El colapso del modelo es un riesgo concreto, no un destino inevitable

Shumailov y sus colaboradores estudiaron el entrenamiento recursivo con datos generados y mostraron cómo pueden desaparecer las partes menos frecuentes de la distribución original. Eso justifica la cautela al sustituir repetidamente la evidencia de origen por ejemplos derivados del propio modelo. No demuestra que todo ajuste fino con datos sintéticos revisados y específicos de una tarea deba fracasar. Artículo de investigación de Nature.

Conserva la evidencia original cuyo uso esté permitido, protege deliberadamente los casos poco frecuentes y compara el comportamiento posterior con una referencia que se haya mantenido intacta. No hay una proporción universal de mezcla entre datos sintéticos y reales que sustituya esa evaluación.

Qué cambiar en tu próxima jornada de trabajo

Empieza ahora si puedes identificar un caso que falte, describir su comportamiento correcto y revisar los candidatos generados frente a una regla estable. Comienza con la pequeña matriz de cobertura y amplía después solo las celdas que aporten casos útiles.

Espera para hacer ajuste fino si quienes revisan discrepan sobre las etiquetas objetivo o si careces de un conjunto de aceptación independiente. Resuelve primero las reglas y la evaluación.

Usa datos de prueba convencionales si la tarea consiste en poblar una base de datos, comprobar valores límite o verificar la integridad de las transacciones. Añade lenguaje generado solo donde permita probar comportamientos que los datos más sencillos no cubren.

Antes de la próxima versión, compara el sistema de referencia y el modificado con los mismos casos intactos. Para el clasificador de soporte, examina por categoría las asignaciones incorrectas y las solicitudes que debían derivarse a revisión y no se derivaron. Conserva los datos sintéticos solo si mejoran el comportamiento previsto sin retrocesos inaceptables en otras áreas.

Preguntas frecuentes sobre datos sintéticos

Suscríbete al boletín para recibir guías prácticas sobre cómo crear y evaluar sistemas de IA.