Volver al blog

Cómo los datos sintéticos permiten mejores modelos de IA

Un joven profesional mirando hacia arriba

Cómo los datos sintéticos generados de forma sistemática permiten modelos de IA precisos y eficientes en sanidad cuando los datos reales son escasos o sensibles.

Hace casi un mes participé en el hackathon de datos sintéticos sanitarios organizado por el Hospital Clínico de Madrid. Lo que más me llamó la atención fue que, pese a los esfuerzos y las enormes inversiones en sistemas de información, la información de calidad escasea. Eso convierte una eventual transformación del sistema sanitario mediante datos e inteligencia artificial casi en una quimera.

David Rey, doctor
18 de diciembre de 2025

Aunque, en realidad, no me sorprendió del todo. En mi experiencia de los últimos años, este problema se repite en cualquier sector. Incluso en las empresas nativas digitales, obtener datos de calidad exige cambiar la forma de trabajar, y ya sabemos que “la cultura se come a la estrategia para desayunar”... y a veces no hay nada más rígido que el cerebro humano.

Pero pronto, a medida que avanzaba el día, me tranquilicé un poco. Parecía que, si los datos reales no existían, podíamos construir una réplica suficientemente buena (datos sintéticos). Aunque, claramente, siguen siendo datos “inventados”, y en un entorno tan sensible como este me vino a la cabeza una segunda pregunta: ¿son lo bastante buenos?

Casi de inmediato recordé el proceso de construcción de DeepSeek R1 a principios de este año, en el que —simplificando al extremo— el modelo de razonamiento se entrenó con datos generados por un modelo auxiliar (DeepSeek R1-Zero). Mediante aprendizaje por refuerzo, el modelo adquirió capacidades de razonamiento cada vez más sofisticadas. Una parte relevante de ese éxito residió precisamente en el uso de datos sintéticos.

C

CONDITION

Enfermedades, diagnósticos, trastornos, síntomas y signos.

D

DRUG

Medicamentos, principios activos y productos farmacéuticos.

P

PROCEDURE

Procedimientos médicos, pruebas de imagen, cirugías e intervenciones.

M

MEASUREMENT

Pruebas o métricas clínicas (el concepto medido).

L

LAB_RESULT

Resultados numéricos o cualitativos mencionados en el texto.

O

OBSERVATION

Hechos no diagnósticos: hábitos, factores sociales, hallazgos.

V

DEVICE

Dispositivos médicos usados, insertados o implantados.

A

ANATOMY

Localizaciones corporales, estructuras o regiones anatómicas.

U

UNIT

Unidades de medida.

T

TEMPORAL

Expresiones temporales clínicamente relevantes: frecuencia, duración, momento.

Tipos de entidad del OMOP Common Data Model

Por otro lado, en las últimas semanas en Tietai estábamos mejorando el módulo de identificación de entidades de datos sobre texto libre, siguiendo el modelo de datos OMOP CDM (que pretende ser un modelo de datos común y estandarizado que recoja cualquier tipo de dato clínico).

Nuestro objetivo era crear un sistema muy eficiente y preciso que tratara grandes volúmenes de textos del sistema sanitario sin tener en cuenta a priori su estructura: historias clínicas en texto natural, informes de alta, seguimientos, etc.

El problema no es nuevo, porque este tipo de cuestiones sufrían niveles de precisión escasos con las técnicas tradicionales de procesamiento del lenguaje natural. Sin embargo, la reciente aparición de los grandes modelos de lenguaje (LLM) y sus versiones reducidas (SLM) ha abierto una ventana de mejora: la complejidad técnica ha bajado, pero el coste y los tiempos necesarios para ejecutar procesos grandes siguen siendo altos.

¿Sería posible mejorar las aproximaciones más tradicionales de etiquetado de entidades en texto (que son más eficientes) mediante datos sintéticos? Es decir, ¿podemos construir un modelo capaz de detectar en el texto elementos de los siguientes tipos?

En concreto, me había centrado en modelos específicos basados en arquitecturas tipo BERT, como Clinical Bert, pero orientados a mi tarea. El primer problema era que necesitaba construir una base de datos, y el segundo, cómo asegurarme de no haber cometido sobreajuste por la endogamia de consumir datos que yo mismo había producido.

Así que me puse manos a la obra para construir el conjunto de datos con este formato:

{
  "text": "Ibuprofen 500 mg every morning for headache after bronchoscopy of the left lung",
  "tokens": ["Ibuprofen", "500", "mg", "every", "morning", "for", "headache",
             "after", "bronchoscopy", "of", "the", "left", "lung"],
  "tags":   ["B-D", "O", "B-U", "B-T", "I-T", "O", "B-C",
             "O", "B-P", "O", "O", "B-A", "I-A"]
}
  • B- Primer token de una entidad
  • I- Tokens siguientes de la misma entidad
  • O Fuera de cualquier entidad
  • Las letras tras el guion son los tipos de entidad anteriores (D = DRUG, U = UNIT, T = TEMPORAL…)

Registro ilustrativo.

Estructura del conjunto de datos (JSON con etiquetado BIO)

En total se generarían 20.873 registros, repartidos en tres grupos:

  • Conjunto de entrenamiento: 16.699 (80 %)
  • Conjunto de prueba: 2.087 (15 %)
  • Conjunto de validación: 2.087 (15 %)

Estos datos no se han generado de forma completamente aleatoria; se fuerza que los registros contengan una proporción mínima de casos positivos de cada categoría, así como casos negativos o claramente negativos.

¿Cómo construimos el conjunto de datos y el modelo?

La idea general es construir un conjunto de datos que se refina generalizando los errores observados. El proceso consta de una serie de pasos:

  1. Generar datos sintéticos con un gran modelo tutor.
  2. Validar la calidad de los datos sintéticos con otro modelo tutor, para asegurar la calidad de los datos utilizados.
  3. Dividir el conjunto generado en 3 partes disjuntas: (1) entrenamiento (60 %), (2) prueba/validación en entrenamiento (20 %), (3) validación fuera de muestra (20 %).
  4. Ajustar un modelo eficiente y pequeño, que incorpore conocimiento del dominio pero que no incluya el conjunto de validación. En este caso sería PlanTL-GOB-ES/bsc-bio-ehr-es, preentrenado con 278.000 documentos y notas clínicas.
  5. Sobre el conjunto de validación original, analizamos con otro modelo tutor (Gemini 2.5 Flash) para generalizar patrones de los datos observados en los errores del conjunto de prueba.
  6. Para cada uno de los errores, generamos un nuevo conjunto de datos con 3 observaciones por patrón.
  7. Por último, volvemos a refinar el modelo en el paso 4 durante 3 iteraciones, hasta que las métricas de validación del sistema dejan de mejorar.
  1. 1

    Generar

    Un gran modelo tutor escribe registros sintéticos.

  2. 2

    Validar

    Un segundo modelo tutor comprueba su calidad.

  3. 3

    Dividir

    Entrenamiento 60 %, prueba durante el entrenamiento 20 %, validación fuera de muestra 20 %.

  4. 4

    Ajustar

    Un modelo pequeño de dominio (bsc-bio-ehr-es) aprende del conjunto de entrenamiento.

  5. 5

    Analizar errores

    Gemini 2.5 Flash generaliza los patrones de error observados en el conjunto de prueba.

  6. 6

    Reforzar

    Tres ejemplos nuevos por patrón de error vuelven al ajuste, durante tres iteraciones.

Los pasos 4 a 6 se repiten hasta que las métricas de validación dejan de mejorar.
Proceso general

Antes: una única OBSERVATION amplia

OStates that in recent months he has had high work stress, but denies persistent sadness, loss of interest in activities, negative thoughts or problems sleeping.

Después: entidades Condition y Temporal separadas

States that Tin recent months he has had Chigh work stress, but denies Cpersistent sadness, Closs of interest in activities, Cnegative thoughts or Cproblems sleeping.

Patrón de error: entidades distintas agrupadas en un solo tramo y tipadas como OBSERVATION.

Análisis de patrones de error

La imagen anterior explica mejor la clave del proceso: el modelo tutor revisa los errores e intenta explicar una clasificación incorrecta. Esa será la entrada para que otro modelo genere sintéticamente observaciones positivas que refuercen una clasificación correcta.

¿Son generalizables estos resultados?

Ahora bien, ya tenemos un modelo capaz de etiquetar información clínica con precisión (respecto a nuestro conjunto inicial), pero la pregunta es: ¿esta calidad es real o solo se debe a que hemos “cocinado” los datos a nuestro gusto?

Antes de desvelar ningún misterio, me detengo a mostrar el resultado del modelo. Como vemos, es capaz de identificar en el texto patrones que corresponden a las entidades:

Has also noticed Cdifficulty concentrating at work and lower tolerance to exercise: before ran L5 Ukm without difficulty and now gets Texhausted L1–L2 Ukm.

  • C CONDITION
  • L LAB_RESULT
  • U UNIT
  • T TEMPORAL
Texto libre de una nota clínica etiquetado por nuestro modelo

El modelo de clasificación también había obtenido métricas más que dignas:

  • Exactitud: 98 %
  • Recall: 92 %
  • F1: 94 %

Hasta aquí, todo bien, pero era necesario confirmar que el experimento había generalizado bien. Para ello, decidí ver cómo funcionaba con un conjunto público de enfermedades llamado CANTEMIST. Al usar estos datos, me aseguraba de evaluar resultados con datos fuera de muestra.

Por otro lado, quería comparar el rendimiento de mi modelo con otro similar entrenado para una tarea específica. Por suerte, SEDIA y el BSC habían entrenado un modelo de clasificación sobre la misma base que el mío, pero usando CANTEMIST como conjunto de entrenamiento y validación. En su caso, lo habían entrenado con 30.565 observaciones.

Para comparar ambos modelos, usé medidas de exactitud a nivel de registro (en lugar de a nivel de token, como se hace en el artículo del modelo mencionado en el párrafo anterior). Los resultados fueron más que sorprendentes: ambos modelos funcionaban de forma muy parecida.

Exactitud, precisión, recall y F1 del modelo OMOP CDM de Tietai y del modelo del BSCModelo OMOP CDM de TietaiModelo del BSC entrenado con CANTEMIST0%25%50%75%100%DiferenciaExactitud97,73%97,82%−0,09 ppPrecisión97,80%97,83%−0,03 ppRecall97,73%97,82%−0,09 ppF197,69%97,82%−0,13 pp
Comparación de métricas de los modelos (BSC frente al etiquetador OMOP CDM de Tietai)

Con esto me quedé algo más tranquilo. El modelo construido no solo tenía niveles de precisión similares a los de un modelo entrenado específicamente para la tarea, sino que además era capaz de clasificar otros tipos de entidades. Así, mi hipótesis sobre la utilidad de los datos sintéticos en este ámbito quedaba confirmada experimentalmente.

Conclusiones

Para cerrar, podríamos decir que el uso de datos sintéticos generados y validados de forma sistemática no solo es técnicamente viable, sino que es una alternativa adecuada para los casos en que los datos son difíciles de obtener.

En sectores tan sensibles como la salud, los datos sintéticos pueden ser una buena alternativa (a veces incluso la única).

Ideas clave que conviene tener en cuenta:

  • Es posible construir modelos multipropósito que ofrecen un rendimiento comparable al de soluciones muy especializadas, reducen la dependencia de desarrollos ad hoc y facilitan la reutilización en distintos casos de uso.
  • La transferencia de conocimiento de modelos grandes a modelos más pequeños y eficientes permite equilibrar calidad y coste, y hace posibles despliegues en producción con menores requisitos de infraestructura.
  • El pipeline basado en generación, validación automática y refinamiento iterativo de datos sintéticos minimiza los riesgos de sobreajuste y mejora la generalización.
  • El coste muy bajo de adquisición de datos (35 $) es una ventaja clara de este método, sobre todo en sectores donde el acceso a datos reales es limitado o caro.
  • Aun así, quiero dejar claro que el etiquetado humano es lo ideal, pero con esta prueba podemos asegurar que es una fuente válida siempre que dispongamos de conjuntos de validación (como en nuestro caso).

Despeja el camino para la salud.