Cómo ajustar un modelo de IA con tus propios datos desde cero

Empieza con un modelo ya entrenado

Para la mayoría de los desarrolladores independientes, entrenar un modelo de lenguaje desde cero no es una opción realista.

Una estrategia mucho más práctica consiste en elegir un modelo de código abierto o de pesos abiertos y utilizar tus propios datos para ajustarlo. De esta forma puedes conseguir que el modelo aprenda determinados conocimientos, estilos de respuesta o tareas específicas.

El proceso completo puede resumirse así:

Modelo base → Preparar tus datos → Limpiar los datos → Convertirlos al formato de entrenamiento → Elegir el método de fine-tuning → Entrenamiento con GPU → Evaluación → Despliegue

Cada etapa influye en el resultado final. En muchos proyectos, la calidad de los datos y la elección del método de ajuste son incluso más importantes que el tamaño del modelo.

Antes de empezar: ¿realmente necesitas Fine-tuning o RAG?

Antes de configurar una GPU o preparar un dataset, hay una pregunta más importante:

¿Realmente necesitas hacer Fine-tuning o sería mejor utilizar RAG (Retrieval-Augmented Generation)?

RAG funciona almacenando documentos en una base de datos vectorial. Cuando el usuario hace una pregunta, el sistema recupera primero los fragmentos relevantes y después los envía al modelo junto con la consulta.

El modelo no cambia, pero puede acceder a información actualizada.

El Fine-tuning funciona de otra manera: utiliza tus datos para modificar determinados parámetros del modelo con el objetivo de que aprenda patrones de comportamiento concretos.

Una regla sencilla puede ayudarte a decidir:

• Si quieres que el modelo «sepa más cosas» → considera primero RAG. Bases de conocimiento internas, documentación de productos, información que cambia con frecuencia y grandes cantidades de datos factuales suelen funcionar mejor con RAG. Puedes actualizar los documentos sin volver a entrenar el modelo.

• Si quieres que el modelo «haga las cosas de una determinada manera» → Fine-tuning suele ser más adecuado. Un estilo de respuesta concreto, un formato de salida fijo o tareas estables de clasificación, extracción y reescritura son ejemplos donde RAG no resuelve directamente el problema. Recuperar documentos no hace que el modelo adopte por sí mismo una determinada forma de razonar o expresarse.

Ambos enfoques también pueden utilizarse conjuntamente.

Una estrategia habitual es empezar creando un prototipo con RAG. Si después de probarlo queda claro que la recuperación de información no puede resolver el problema, entonces tiene sentido plantearse un Fine-tuning.

Para la mayoría de los desarrolladores independientes, probar RAG antes del primer Fine-tuning es probablemente la decisión con menor coste y riesgo.

Elegir el modelo base

Al elegir un modelo base conviene prestar atención a varios aspectos.

Tamaño del modelo

Los modelos de 7B-8B parámetros son un punto de partida bastante realista para un desarrollador independiente. Con una sola GPU de consumo es posible realizar determinados tipos de Fine-tuning.

Los modelos de 14B necesitan más memoria y potencia, pero el aumento de calidad no necesariamente será proporcional.

Longitud de contexto

Si el proyecto implica trabajar con documentos largos, es importante comprobar cuál es la ventana de contexto compatible con el modelo.

Capacidad lingüística

Para tareas en chino, conviene priorizar modelos con una proporción significativa de datos de entrenamiento en chino.

El mismo principio se aplica a otros idiomas: el modelo base debe tener buenas capacidades en el idioma principal de tu aplicación.

Compatibilidad con Fine-tuning

No todos los modelos están disponibles bajo las mismas condiciones.

Algunos modelos, especialmente determinadas versiones de pesos abiertos relacionadas con productos comerciales, pueden tener restricciones adicionales sobre el Fine-tuning.

License y uso comercial

Las licencias permisivas como Apache 2.0 o MIT suelen ofrecer mayor libertad para aplicaciones comerciales.

Sin embargo, algunos modelos pueden establecer límites relacionados con usuarios activos mensuales u otras condiciones.

Es un punto que se pasa por alto con demasiada frecuencia. Antes de elegir un modelo, revisa siempre el campo License de su página oficial.

Un modelo más grande no garantiza mejores resultados

El tamaño del modelo no determina por sí solo la calidad del resultado.

Un modelo de 7B ajustado con datos de alta calidad puede superar claramente a un modelo mucho más grande entrenado con datos deficientes.

La definición de la tarea, la calidad del dataset y los parámetros de entrenamiento son igualmente importantes.

Cómo preparar tus propios datos

Esta es probablemente una de las etapas más subestimadas de todo el proceso.

Los datos de entrenamiento deben definir claramente qué recibe el modelo y qué esperamos que produzca.

No basta con introducir miles de archivos TXT, PDF o páginas web directamente en el entrenamiento.

El modelo necesita ejemplos estructurados, como pares de entrada-respuesta o instrucción-salida, no simplemente grandes cantidades de texto sin estructura.

Existen diferentes formatos de datos. Tres de los más habituales son los siguientes.

Formato Alpaca

Adecuado para instrucciones de una sola interacción:

{
  "instruction": "Reescribe la siguiente descripción de producto como una reseña breve para una tienda online",
  "input": "Estos auriculares Bluetooth ofrecen 30 horas de autonomía y cancelación activa de ruido",
  "output": "30 horas de autonomía y cancelación activa de ruido: unos auriculares Bluetooth pensados para disfrutar de la música en cualquier lugar."
}

Formato ShareGPT

Adecuado para conversaciones de varios turnos:

{
  "conversations": [
    {"from": "human", "value": "¿Este producto es resistente al agua?"},
    {"from": "gpt", "value": "Este producto cuenta con resistencia al agua IPX5, por lo que puede soportar el sudor y la lluvia durante el uso diario."}
  ]
}

Formato OpenAI Messages

{
  "messages": [
    {"role": "system", "content": "Eres el asistente de atención al cliente de una empresa."},
    {"role": "user", "content": "¿Cuánto tarda en llegar un pedido?"},
    {"role": "assistant", "content": "El envío estándar suele tardar entre 3 y 5 días laborables."}
  ]
}

Los formatos compatibles dependen del modelo y del framework de entrenamiento.

Antes de preparar todo el dataset, consulta la documentación del framework utilizado por el modelo elegido y confirma exactamente qué formato espera.

Es mucho mejor descubrir una incompatibilidad con 10 ejemplos que después de haber preparado 100.000.

La limpieza de datos importa más que la cantidad

1.000 ejemplos de alta calidad pueden ser más valiosos que 100.000 ejemplos deficientes.

Los problemas más habituales incluyen:

• datos duplicados;

• respuestas incorrectas;

• formatos inconsistentes;

• contenido de relleno sin valor;

• información sensible expuesta.

Un flujo de limpieza razonable sería:

Datos originales
    ↓
Eliminar duplicados
    ↓
Limpiar formatos
    ↓
Eliminar ejemplos de baja calidad
    ↓
Unificar formatos
    ↓
Control de calidad
    ↓
Dividir en conjunto de entrenamiento y validación

Reserva siempre una parte de los datos para validación.

No conviene utilizar absolutamente todos los ejemplos para entrenar.

El conjunto de validación permite comprobar si el modelo realmente ha aprendido la tarea o simplemente ha memorizado los ejemplos utilizados durante el entrenamiento.

¿Cuántos datos necesitas?

No existe una cifra universal. La cantidad necesaria depende mucho del tipo de tarea.

• Aprendizaje de formatos sencillos, como una plantilla de salida fija: unos cientos de ejemplos pueden ser suficientes.

• Aprendizaje de estilo, como imitar un determinado tono: normalmente se necesitan varios miles de ejemplos.

• Preguntas y respuestas de un dominio específico: pueden ser necesarios varios miles o decenas de miles de pares de alta calidad.

• Tareas complejas de razonamiento: requieren más datos y, sobre todo, una calidad mucho mayor.

Más datos no significa automáticamente un mejor Fine-tuning.

Si el dataset contiene muchos ejemplos repetidos o incorrectos, añadir más datos puede hacer que el modelo aprenda patrones equivocados.

Para un desarrollador independiente, un buen punto de partida es utilizar unos cientos o unos pocos miles de ejemplos de alta calidad, comprobar que el proceso funciona y ampliar el dataset progresivamente.

LoRA, QLoRA y Fine-tuning completo: ¿cuál es la diferencia?

Fine-tuning completo

El Fine-tuning completo modifica una gran parte o incluso todos los parámetros del modelo.

Ofrece una gran capacidad de adaptación, pero necesita mucha memoria GPU, tiene un coste de entrenamiento elevado y también genera modelos más costosos de almacenar.

Para un modelo de 7B, un Fine-tuning completo suele requerir varias GPU de gama alta, algo poco práctico para la mayoría de los desarrolladores independientes.

LoRA

LoRA (Low-Rank Adaptation) no modifica directamente los pesos del modelo base.

En su lugar, añade pequeñas matrices junto a determinadas matrices de pesos y solo entrena esas matrices adicionales.

Por ejemplo, en un modelo Llama 70B, un Fine-tuning completo tendría que optimizar decenas de miles de millones de parámetros, mientras que LoRA solo necesita entrenar una pequeña fracción de ellos.

Al terminar, normalmente obtienes un archivo Adapter de unos pocos MB o decenas de MB en lugar de una copia completa del modelo.

QLoRA

QLoRA lleva esta idea un paso más allá.

Primero carga el modelo base utilizando cuantización de 4 bits y después aplica LoRA.

Esto reduce considerablemente el consumo de memoria GPU.

Como referencia práctica, QLoRA puede utilizar aproximadamente una cuarta parte de la memoria que necesitaría un escenario equivalente de LoRA sin esa cuantización, aunque existen compromisos relacionados con velocidad y precisión.

Para la mayoría de los desarrolladores independientes, el primer Fine-tuning debería empezar con LoRA o QLoRA, no con Fine-tuning completo.

Con 16 GB de VRAM, QLoRA permite trabajar con modelos de alrededor de 7B bajo determinadas configuraciones. Con 8 GB también pueden realizarse experimentos utilizando modelos pequeños o configuraciones muy ajustadas.

¿Puede una sola GPU encargarse del entrenamiento?

La memoria necesaria depende de varios factores:

• tamaño del modelo;

• método de cuantización;

• batch size;

• sequence length;

• configuración de LoRA;

• otras opciones de entrenamiento.

Como referencia aproximada:

• 8 GB de VRAM: QLoRA con modelos de 1-3B o intentar modelos de 7B con batch size muy pequeño.

• 12 GB: QLoRA con modelos de 7B utilizando una sequence length relativamente pequeña.

• 16 GB: QLoRA con modelos de 7B es un punto de partida bastante cómodo.

• 24 GB: QLoRA con modelos de 7B o 14B, o LoRA en 16 bits con modelos de 7B.

• 48 GB o más: permite experimentar con modelos mayores o realizar Fine-tuning completo de modelos relativamente pequeños.

Entrenamiento y generación no consumen la misma cantidad de memoria

La VRAM necesaria para entrenar un modelo no es equivalente a la necesaria para utilizarlo.

Durante el entrenamiento hay que almacenar gradientes, estados del optimizador y activaciones.

Por eso el entrenamiento suele necesitar bastante más memoria que la inferencia.

Un modelo que puede ejecutarse para inferencia en una GPU de 8 GB podría necesitar más de 16 GB durante el Fine-tuning.

Preparar el entorno de entrenamiento

El ecosistema de entrenamiento de modelos abiertos se apoya principalmente en estas herramientas:

• PyTorch: framework fundamental de aprendizaje profundo.

• Transformers: carga de modelos y tokenizers.

• PEFT: implementación de LoRA y otros métodos de Fine-tuning eficiente.

• TRL: incluye SFTTrainer y simplifica el proceso de entrenamiento supervisado.

• bitsandbytes: proporciona cuantización de 4 y 8 bits y es fundamental para QLoRA.

• Unsloth: ofrece kernels optimizados que pueden acelerar el entrenamiento y reducir el consumo de VRAM.

Es recomendable utilizar un entorno virtual mediante conda o venv para evitar conflictos entre dependencias.

También es importante que la versión de CUDA sea compatible con la versión de PyTorch instalada. Esta es una de las causas más habituales de problemas al configurar el entorno.

Un flujo completo de Fine-tuning con LoRA

Como ejemplo, vamos a utilizar un dataset de conversaciones de atención al cliente para ajustar un modelo de aproximadamente 7B.

Paso 1: preparar los datos

Organiza las conversaciones en formato Alpaca o ShareGPT y divide los datos en:

• 90 % para entrenamiento;

• 10 % para validación.

Paso 2: cargar el tokenizer y el modelo

El tokenizer convierte el texto en una secuencia de tokens que el modelo puede procesar.

En este ejemplo cargaremos el modelo utilizando cuantización de 4 bits:

from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig
import torch

model_name = "meta-llama/Llama-3.1-8B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_name)

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
)

model = AutoModelForCausalLM.from_pretrained(
    model_name,
    quantization_config=bnb_config,
    device_map="auto",
)

load_in_4bit=True activa la cuantización de 4 bits, que constituye la base de QLoRA.

bnb_4bit_compute_dtype define la precisión utilizada durante los cálculos.

Paso 3: configurar LoRA

Utilizamos LoraConfig de PEFT:

from peft import LoraConfig, get_peft_model

lora_config = LoraConfig(
    r=16,                # rango de LoRA
    lora_alpha=32,       # factor de escala
    lora_dropout=0.05,   # ayuda a evitar overfitting
    target_modules=["q_proj", "v_proj", "k_proj", "o_proj"],
    task_type="CAUSAL_LM",
)

model = get_peft_model(model, lora_config)

r y lora_alpha son dos de los parámetros más importantes.

target_modules determina en qué capas se añaden los adaptadores LoRA.

Paso 4: configurar el entrenamiento

Utilizaremos SFTTrainer de TRL:

from trl import SFTTrainer, SFTConfig

training_args = SFTConfig(
    output_dir="./fine-tuned-model",
    num_train_epochs=2,
    per_device_train_batch_size=2,
    gradient_accumulation_steps=4,
    learning_rate=2e-4,
    warmup_ratio=0.1,
    logging_steps=10,
    save_strategy="epoch",
    eval_strategy="epoch",
    max_length=512,
)

trainer = SFTTrainer(
    model=model,
    args=training_args,
    train_dataset=train_dataset,
    eval_dataset=eval_dataset,
)
trainer.train()

Paso 5: guardar y probar

Cuando termine el entrenamiento, guarda el Adapter de LoRA:

trainer.save_model("./lora-adapter")

Después puedes cargar el modelo base junto con el Adapter y realizar pruebas de inferencia.

Lo importante es comparar las respuestas con las obtenidas antes del Fine-tuning.

Cómo entender los principales parámetros de entrenamiento

Learning rate

El learning rate determina cuánto cambian los pesos durante el entrenamiento.

Para LoRA/QLoRA, un rango habitual puede situarse entre 2e-4 y 5e-6, aunque el valor adecuado depende del modelo y del dataset.

Un punto de partida puede ser 2e-4.

Un valor demasiado alto puede hacer que el entrenamiento sea inestable, mientras que uno demasiado bajo puede impedir que el modelo aprenda suficientemente.

Con ranks pequeños de LoRA, como 8-16, pueden utilizarse learning rates relativamente altos. Con ranks mayores, como 64 o más, puede ser conveniente reducirlo por debajo de 1e-4.

Epoch

Un epoch representa una pasada completa por el conjunto de entrenamiento.

Para muchos Fine-tuning pequeños, entre 1 y 3 epochs puede ser un punto de partida razonable.

Más de 3 epochs pueden ofrecer rendimientos decrecientes y aumentar el riesgo de overfitting.

Batch size y gradient accumulation

Cuando la VRAM no permite utilizar un batch grande, puedes combinar un batch pequeño con gradient accumulation.

El sistema acumula los gradientes de varios pequeños batches antes de actualizar los pesos.

Esto permite simular un batch efectivo mayor sin necesitar toda esa memoria de una sola vez.

Max sequence length

Define la longitud máxima de la secuencia utilizada durante el entrenamiento.

Un valor demasiado pequeño puede truncar respuestas largas y eliminar información importante.

Un valor demasiado grande aumenta significativamente el consumo de VRAM.

Warmup

Durante los primeros 5-10 % de los pasos de entrenamiento, el learning rate puede aumentar progresivamente desde cero hasta el valor objetivo.

Esto ayuda a estabilizar el entrenamiento inicial.

Cómo saber si el Fine-tuning ha funcionado

No basta con observar si el loss disminuye.

Como mínimo deberías realizar tres tipos de pruebas:

rendimiento en el conjunto de entrenamiento, rendimiento en el conjunto de validación y rendimiento en escenarios reales.

Hay varios aspectos importantes que revisar.

• ¿Ha aprendido la tarea? El modelo debería responder siguiendo el patrón que aparece en los datos de entrenamiento.

• ¿Existe overfitting? Si el loss de validación empieza a subir mientras el loss de entrenamiento continúa bajando, puede existir sobreajuste.

• ¿Ha perdido capacidades generales? Comprueba si el rendimiento en tareas generales ha empeorado, algo que puede ocurrir como consecuencia del olvido catastrófico.

• ¿Han aumentado las alucinaciones? El modelo podría empezar a inventar información que no aparece en los datos.

• ¿El formato de salida es correcto? Busca respuestas repetidas, estructuras incorrectas o formatos inconsistentes.

Una buena práctica es preparar un conjunto de preguntas de comparación antes vs. después del Fine-tuning.

Primero prueba el modelo base y guarda sus resultados. Después repite exactamente las mismas pruebas con el modelo ajustado.

Establecer una línea base del modelo original es el primer paso de una evaluación seria.

Sin esa referencia no puedes saber si el Fine-tuning realmente ha mejorado el modelo.

¿Qué obtienes realmente después del entrenamiento?

Cuando terminas un Fine-tuning con LoRA, normalmente tienes:

un archivo Adapter + el modelo base original.

El Adapter puede ocupar solo unas pocas decenas de MB y no contiene todos los pesos del modelo.

Para utilizarlo, normalmente necesitas cargar simultáneamente el modelo base y el Adapter.

También puedes fusionar el Adapter con el modelo base y obtener un modelo completo independiente.

LoRA no crea un modelo completamente nuevo

Es más preciso pensar en LoRA como una capa de adaptación sobre un modelo existente.

El modelo base conserva sus capacidades generales y el Adapter introduce ajustes específicos que hacen que funcione mejor para una determinada tarea.

Cómo desplegar tu modelo

El entorno de entrenamiento y el entorno de producción no tienen por qué ser la misma máquina.

Una arquitectura habitual es:

Modelo base + LoRA Adapter
        ↓
Framework de inferencia
        ↓
API
        ↓
Aplicación

Transformers + PEFT

Una combinación adecuada para desarrollo y pruebas.

Puedes cargar directamente el modelo base y el Adapter para realizar inferencia.

vLLM

Una opción más apropiada para producción.

Está orientada a escenarios de alta concurrencia y ofrece una API compatible con OpenAI.

También permite trabajar con modelos base y LoRA Adapters.

Ollama / llama.cpp

Son alternativas interesantes para despliegues locales.

En este caso normalmente tendrás que fusionar el modelo y convertirlo al formato GGUF antes de utilizarlo.

Los errores más habituales

Formato de datos incorrecto

El formato esperado por el framework no coincide con el dataset.

Síntoma: el tokenizer genera errores al comenzar el entrenamiento o el loss no disminuye.

Solución: revisa la documentación del framework y prueba primero el flujo completo con solo 10 ejemplos.

Falta de VRAM

El batch_size o sequence_length es demasiado grande.

Solución: reduce el batch size, activa gradient checkpointing y disminuye la sequence length.

Learning rate incorrecto

Un valor demasiado alto puede provocar oscilaciones en el loss. Uno demasiado bajo puede hacer que el modelo prácticamente no aprenda.

Solución: comienza alrededor de 2e-4 y ajusta el valor observando la evolución del loss.

Demasiados epochs

El modelo comienza a memorizar los ejemplos de entrenamiento y el rendimiento en validación empeora.

Solución: empieza con 1-3 epochs y controla el loss de validación.

El resultado apenas cambia después del entrenamiento

Puede deberse a:

• learning rate demasiado bajo;

• dataset demasiado pequeño;

• configuración incorrecta de target_modules;

• Adapter LoRA aplicado incorrectamente.

Solución: comprueba que LoRA está realmente conectado a las capas objetivo y que los parámetros del Adapter se están actualizando durante el entrenamiento.

El entrenamiento funciona bien, pero el modelo funciona mal en producción

Una causa frecuente es que la distribución de los datos de entrenamiento no coincide con las situaciones reales.

Solución: utiliza preguntas y ejemplos procedentes de escenarios reales para construir el conjunto de validación.

Una ruta práctica para desarrolladores independientes

Una estrategia razonable sería:

Elegir un modelo base de aproximadamente 7B/8B
→ Preparar unos cientos o miles de ejemplos de alta calidad
→ Empezar con QLoRA
→ Realizar experimentos con una escala de entrenamiento pequeña
→ Preparar un conjunto de pruebas independiente
→ Comparar el modelo antes y después del Fine-tuning
→ Ajustar primero los datos en función de los resultados, en lugar de aumentar los epochs sin criterio
→ Solo después plantearse un entrenamiento a mayor escala

El objetivo del primer Fine-tuning no debería ser crear «tu propio ChatGPT».

El objetivo es comprobar si tus datos pueden conseguir que un modelo existente mejore de forma estable en una tarea claramente definida.

Si consigues demostrarlo, ya has recorrido todo el proceso fundamental de Fine-tuning. A partir de ahí, las siguientes iteraciones consisten principalmente en mejorar los datos, ajustar los parámetros y aumentar progresivamente la escala.