Ajuste fino en 2026: un experimento de LoRA y QLoRA basado en evidencia

La adaptación completa del modelo puede requerir muchos recursos de cómputo, ingeniería de datos y operaciones de ML. Los métodos eficientes en parámetros reducen parte de esa carga, pero la viabilidad sigue dependiendo del modelo seleccionado, la longitud de secuencia, el hardware, las versiones de las bibliotecas, los datos y las pruebas de aceptación.

Los métodos eficientes en parámetros como LoRA y QLoRA reducen cuántos parámetros se entrenan y pueden disminuir los requisitos de memoria. El resultado sigue dependiendo del modelo base, la longitud de secuencia, los datos, los hiperparámetros, el hardware y la tarea. Un trabajo de entrenamiento exitoso no es un sistema listo para producción.

Esto cambia qué experimentos son asequibles; no establece que el ajuste fino supere al diseño de prompts o a la recuperación para una carga de trabajo concreta.

Este artículo proporciona un flujo de trabajo de decisión y experimentación. El panorama de los proveedores se verificó el 4 de agosto de 2026 mediante el aviso de retirada de OpenAI, la documentación de ajuste de Vertex AI y Hugging Face PEFT.

Cuándo está justificado un experimento de ajuste fino

Cubrimos la decisión brevemente en Diseño de prompts vs RAG vs ajuste fino; aquí tienes el análisis más detallado.

1. Formato y consistencia estructural

Si necesitas salidas con un formato muy específico, compara el diseño de prompts por sí solo, la decodificación restringida y el ajuste; el ajuste fino no supera automáticamente a ninguna de las dos líneas base.

Ejemplo: cada salida debe constar exactamente de cinco viñetas, cada una iniciada con un verbo y con un tono concreto. Compara el diseño de prompts por sí solo, la decodificación restringida cuando corresponda y un modelo ajustado sobre los mismos casos retenidos; no existe una mejora del 95 % frente al 99 % que pueda extrapolarse a otros casos.

Un candidato ajustado puede reducir la necesidad de ejemplos repetidos o mejorar el cumplimiento en la distribución objetivo. Mide tanto la corrección semántica como la forma, porque una estructura válida aún puede contener contenido incorrecto.

2. Consistencia de estilo/voz

Si una línea base revisada de prompts no cumple con una rúbrica de voz definida en interacciones representativas, el ajuste es una intervención candidata.

El ajuste fino sobre ejemplos revisados puede mejorar una métrica de coincidencia de voz, pero la cantidad y diversidad de datos requeridos dependen de la carga de trabajo. Traza una curva de aprendizaje y realiza valoraciones humanas ciegas en lugar de asumir que se ha «internalizado» la voz de marca.

3. Dominio especializado o DSL propio

Si tu dominio tiene terminología inusual, un lenguaje de dominio específico (DSL) propio o patrones concretos que el modelo base no conoce bien:

Ejemplo: una empresa tiene su propio lenguaje interno para consultas de datos. El modelo base nunca lo ha visto. Diseñar prompts con ejemplos ayuda pero no es suficiente; el modelo sigue cometiendo errores de sintaxis.

Un corpus etiquetado del DSL puede mejorar las tasas de análisis sintáctico y de corrección semántica. Mide esas tasas frente al diseño de prompts, la generación restringida por gramática y la recuperación de la especificación del DSL; una receta fija de 5.000 ejemplos no constituye una prueba.

4. Modelo más pequeño con calidad comparable

Un modelo ajustado más pequeño a veces puede igualar una línea base mayor en una métrica acotada. Los posibles beneficios son menor coste de servicio, menor latencia, autohospedaje más fácil y comportamiento más consistente para tareas específicas. Cuantifícalos sobre el hardware exacto, la cuantización, la concurrencia y el listón de calidad que planeas usar.

Para una carga de trabajo acotada de alto volumen, calcula si cualquier ahorro medido en servicio compensa los costes de datos, entrenamiento, evaluación, despliegue y mantenimiento.

5. Seguridad conductual

El ajuste fino puede cambiar el comportamiento de rechazo, pero también puede provocar rechazo insuficiente (under-refusal), rechazo excesivo (over-refusal) o regresiones de capacidad.

Ejemplo: si un sistema orientado al cliente nunca debe citar precios obsoletos, aplica esa regla en la autorización de herramientas y la validación de salida. Un ajuste conductual se puede evaluar como una capa adicional; no hace que la prohibición sea robusta por sí solo.

6. Ejemplos repetidos en prompts

Si los ejemplos repetidos consumen contexto o coste significativo, compara el almacenamiento en caché de prompts, la recuperación solo de ejemplos relevantes y el ajuste. Un prompt ajustado más corto es útil solo si la calidad de la tarea y de seguridad en el conjunto retenido sigue siendo aceptable y mejora el coste total del ciclo de vida.

Cuándo pierde el ajuste fino

Igualmente importante: cuándo no hacer ajuste fino.

1. Conocimiento que cambia

Los modelos ajustados son instantáneas (snapshots). Para conocimiento dinámico como eventos actuales, datos específicos de la cuenta o políticas, mantén los hechos de referencia autorizados en una recuperación gobernada o en herramientas. El ajuste puede afectar a cómo el modelo utiliza la evidencia suministrada; no proporciona una fuente de registro actual y atribuible.

2. No tienes suficientes datos

El ajuste fino requiere datos representativos, pero no hay un recuento mínimo universal. Entrena con subconjuntos crecientes y representa gráficamente el rendimiento en el conjunto retenido, la seguridad y la varianza. Deja de añadir datos cuando la curva de aprendizaje se estabilice o cuando los segmentos sin cubrir (no el volumen bruto) sean el factor limitante.

3. El modelo base mejora más rápido de lo que puedes seguir

Los modelos base y los stacks de servicio cambian. Un modelo ajustado puede perder su ventaja o quedar sin soporte, así que compáralo periódicamente con una línea base fijada actual en lugar de asumir que uno u otro candidato gana.

Si no tienes un plan claro de mantenimiento, el ajuste fino se convierte en deuda técnica.

4. No has hecho el trabajo de diseño de prompts/RAG

El ajuste fino sin una línea base de prompts y recuperación hace imposible atribuir el resultado. Construye esas líneas base primero para que la comparación incluya tanto calidad como coste operativo total.

Construye la línea base relevante de prompt, salida restringida, recuperación o herramienta antes del ajuste para que la comparación sea atribuible.

5. No tienes evaluaciones (evals)

El ajuste fino sin evaluaciones retenidas no puede establecer si ayudó, dañó o simplemente sobreajustó los ejemplos inspeccionados durante el desarrollo.

Construye las evaluaciones primero. Luego haz el ajuste fino.

El panorama del ajuste fino en 2026

Un mapa rápido de lo disponible:

Servicios alojados (hosted)

La disponibilidad alojada es específica del proveedor y la cuenta (estado verificado 2026-08-04):

• El ajuste fino autoadministrado de OpenAI se está retirando. Las nuevas organizaciones no pueden crear trabajos; las organizaciones inactivas están restringidas bajo la regla documentada de 60 días; los clientes activos restantes pierden la creación de nuevos trabajos el 2027-01-06 según el aviso oficial de retirada. La inferencia con modelos ajustados existentes continúa solo hasta que se retire el modelo base subyacente.
• Ajuste de Google Vertex AI. Sigue ofreciendo ajuste para la familia Gemini.

Otros proveedores gestionados pueden admitir el ajuste, pero verifica su lista actual de modelos, manejo de datos, ruta de exportación/salida, precios, disponibilidad regional y elegibilidad de cuenta en la documentación oficial antes de añadirlos a un registro de decisiones.

Para una nueva canalización de entrenamiento de larga duración, compara los servicios gestionados restantes con una alternativa basada en modelos de pesos abiertos e incluye el coste de salida. La retirada de un proveedor no demuestra que todos los servicios de ajuste propietarios se estén contrayendo.

Calcula el coste a partir de los precios actuales del proveedor para entrenamiento e inferencia, el número de tokens de entrenamiento, las épocas, los puntos de control y el volumen de servicio previsto; conserva el cálculo con su fecha.

Cuándo preseleccionar una opción gestionada: cuando el contrato y los controles del proveedor se ajustan a los datos, se admiten el modelo y el método de ajuste necesarios, y el coste total medido y el riesgo de salida resultan más favorables que los de una alternativa propia. No califiques todo ajuste propietario de «heredado» por la retirada de un solo proveedor.

Ajuste fino en infraestructura propia

Tú proporcionas las GPU, el código y la infraestructura.

• Modelos de pesos abiertos: las familias de modelos incluyen Llama, Qwen, Mistral, DeepSeek, Phi y Gemma. Las licencias y términos de uso aceptable varían por modelo y versión; revisa el artefacto exacto antes del entrenamiento o distribución.
• Herramientas: Hugging Face TRL, Axolotl, Unsloth y LLaMA-Factory son candidatas. Fija la versión elegida y verifica su soporte para modelos, tokenizadores, cuantización, entrenamiento distribuido y exportación.
• Cómputo: depende del tamaño del modelo, cuantización, longitud de secuencia, estrategia de lote (batch), optimizador y configuración distribuida. Obtén un presupuesto con fecha o mide tu propio hardware.

Coste: tokens de entrenamiento ÷ rendimiento medido × precio del hardware, más almacenamiento, ejecuciones fallidas, evaluación, ingeniería y tiempo de revisores.

Cuándo preseleccionarlo: cuando el modelo elegido o los límites aplicables a los datos exigen un entorno propio y el equipo puede operar el entrenamiento, los artefactos, el servicio, la aplicación de parches y la recuperación. Compara el uso medido y el coste de personal; realizar muchas ejecuciones no demuestra por sí solo que operar infraestructura propia resulte más barato.

Opciones ligeras

Para experimentos acotados:

• Unsloth en una GPU compatible. Verifica su matriz actual de modelos/hardware y mide el margen de memoria disponible.
• MLX en Apple Silicon. Adecuado para experimentos con modelos pequeños compatibles cuando el modelo y la memoria lo permiten.
• Notebooks alojados. Útiles para experimentos, pero se deben verificar los límites de sesión, almacenamiento, privacidad, disponibilidad y precios antes del uso.

Estas son posibles superficies de experimentación, no garantías de que el modelo elegido se ajuste o que la vía de entrenamiento funcione.

El flujo de trabajo práctico

Para un equipo que construye un ajuste fino para producción, el flujo de trabajo:

Paso 1: Validar la necesidad

Antes de cualquier trabajo con datos, valida:

• ¿Has construido la línea base más simple relevante de prompt, salida restringida, recuperación o herramienta?
• ¿Tienes evaluaciones que muestran que el enfoque actual es insuficiente?
• ¿Puedes articular qué específicamente debe hacer mejor el ajuste fino?

Si la brecha, la línea base, los derechos, los criterios de aceptación, el presupuesto y la vía de servicio no están definidos, no comiences el entrenamiento aún.

Paso 2: Construir evaluaciones (evals)

Sin evaluaciones retenidas, un trabajo de entrenamiento exitoso no establece un mejor modelo.

• Construye un conjunto retenido con potencia suficiente que cubra el comportamiento objetivo y los segmentos críticos; justifica su tamaño a partir de las tasas de error esperadas y del riesgo de la decisión.
• Define métricas: ¿en qué consiste el éxito? Cumplimiento de formato, coincidencia de voz, precisión, etc.
• Línea base: ejecuta la evaluación en el modelo base. Captura la puntuación actual.

Necesitarás esto para saber si el ajuste fino ayudó.

Paso 3: Preparar y gobernar los datos

La mayor parte del trabajo. La calidad de los datos de entrenamiento determina la calidad del ajuste fino.

Fuentes:

• Salidas existentes de alta calidad de tu equipo.
• Interacciones pasadas con clientes curadas.
• Ejemplos generados (usa un modelo fuerte + diseño cuidadoso de prompts).
• Datos específicos del cliente (si es apropiado; respeta permisos y PII).

Formato:

Formato típico para ajuste fino de chat:

{
  "messages": [
    {"role": "system", "content": "..."},
    {"role": "user", "content": "..."},
    {"role": "assistant", "content": "..."}
  ]
}

Un ejemplo por línea en JSONL.

Volumen: construye una curva de aprendizaje desde subconjuntos crecientes y estratificados. «Más» es beneficioso solo cuando los ejemplos añadidos son correctos, tienen licencia, son representativos y cubren una brecha medida.

Calidad > cantidad.

La calidad, diversidad y cobertura importan independientemente del recuento. Audita etiquetas y elimina duplicados de ejemplos casi idénticos antes del entrenamiento.

Diversidad.

El conjunto de datos debe abarcar el rango completo de entradas que verás. Si solo entrenas en casos fáciles, el modelo falla en los difíciles. Si solo entrenas en casos extremos (edge cases), sobrecorregirás.

Datos de seguridad/rechazo.

Incluye ejemplos de rechazos apropiados. De lo contrario, los modelos ajustados a menudo se vuelven más complacientes (harán cualquier cosa) — una regresión en seguridad.

División entrenamiento/evaluación.

Mantén un conjunto de desarrollo para iteración y un conjunto final de prueba que esté aislado del entrenamiento, cambios de prompt y selección de hiperparámetros. Elige tamaños que preserven los segmentos importantes; un porcentaje por sí solo puede dejar riesgos poco frecuentes sin probar.

Paso 4: Ejecutar un experimento de entrenamiento fijado (pinned)

Para servicios alojados de pesos abiertos (Together, Fireworks y similares), el flujo es: subir un conjunto de datos JSONL de chat, iniciar un trabajo LoRA contra un modelo base nombrado, esperar un adaptador o endpoint desplegable. Los campos exactos del SDK varían por proveedor; sigue su documentación actual de ajuste fino.

# Flujo alojado independiente del proveedor: este no es un ejemplo de la API de un proveedor concreto.
# Verifica primero los campos actuales, los modelos base compatibles, los precios y la retención.
carga JSONL validado → inicia trabajo LoRA → evalúa conjunto retenido → despliega adaptador

Para autohospedaje (con Axolotl) — la vía que este artículo recomienda para nuevo trabajo:

base_model: Qwen/Qwen3-8B
load_in_4bit: true

adapter: lora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_modules:
  - q_proj
  - v_proj
  - k_proj
  - o_proj

datasets:
  - path: ./data/train.jsonl
    type: chat_template

num_epochs: 3
micro_batch_size: 2
gradient_accumulation_steps: 4
learning_rate: 0.0002
warmup_steps: 100

output_dir: ./output

Ejecuta: accelerate launch -m axolotl.cli.train config.yaml

Registra el hardware, los controladores, el resumen criptográfico del contenedor o de la imagen, el archivo de bloqueo de paquetes, el hash del conjunto de datos, los tokens, el rendimiento, el tiempo total de ejecución, los puntos de control y el coste. No deduzcas el tiempo de ejecución a partir de este boceto.

Hiperparámetros para registrar y variar deliberadamente: épocas o pasos, programa de tasa de aprendizaje, optimizador, tamaño efectivo del lote, longitud de secuencia y empaquetado, rango/alpha/dropout del adaptador y módulos objetivo, precisión/cuantización, calentamiento (warmup), cadencia de puntos de control/evaluación y semilla. Comienza desde una receta mantenida para el modelo exacto y versión fijada de la biblioteca, perfila una ejecución pequeña, luego varía una hipótesis a la vez contra métricas retenidas y de seguridad. No copies los valores YAML ilustrativos como predeterminados.

Paso 5: Evaluar

Ejecuta el conjunto de evaluaciones en el modelo ajustado.

• ¿Mejoró la puntuación sobre la línea base?
• ¿En cuánto?
• ¿Hubo regresiones en algo (capacidades generales, seguridad, casos extremos)?

Clasifica la evidencia sin adivinar la causa: cambio en la tarea objetivo con confianza/varianza, cada regresión de segmento crítico, cambio en calibración y seguridad, coste/latencia de servicio y desacuerdo entre revisores. Una regresión puede provenir de datos, optimización, formato, filtración de evaluación o varianza aleatoria; diagnostica con ejecuciones controladas antes de prescribir más datos o diferentes hiperparámetros.

Paso 6: Pruebas en sombra (shadow), canario y reversión

Antes del despliegue completo, prueba A/B:

• Comienza en modo sombra donde sea práctico, luego elige un tamaño de canario a partir del radio de impacto, el tráfico, la potencia estadística y la velocidad de reversión.
• Compara métricas: puntuaciones de calidad, retroalimentación de usuarios, señales posteriores.

Decide después de que se cumplan el tamaño de muestra predeclarado y la ventana de observación: expandir, iterar o revertir.

Paso 7: Desplegar con una vía de reversión

Para endpoints alojados de pesos abiertos: dirige el tráfico al ID del modelo ajustado o adaptador que devuelva tu proveedor.

Para autohospedaje: selecciona un motor de servicio que admita explícitamente el modelo base fijado y el formato del adaptador, verifica su guía de seguridad y haz benchmarks de carga, descarga, concurrencia, reversión e identidad base/adaptador. vLLM es un candidato, no un estándar universal.

Paso 8: Monitorización (continua)

El ajuste fino está en producción. Monitoriza:

• Métricas de calidad (evaluaciones online, retroalimentación de usuarios).
• Deriva a lo largo del tiempo.
• Si las mejoras del modelo base han cerrado la brecha (reevalúa periódicamente frente al modelo base más reciente).

Paso 9: Mantenimiento basado en desencadenantes

Un ajuste fino no es «lanzarlo una vez y olvidarse».

• El modelo base se actualiza: vuelve a hacer el ajuste fino sobre el nuevo modelo base periódicamente.
• Los datos derivan (drift): refresca los datos de entrenamiento para reflejar patrones actuales.
• La suite de evaluación se expande: revalida a medida que surgen nuevos casos de prueba.

Reevalúa ante deriva de datos, cambio de política, cambio del modelo base, nuevos clústeres de fallo o una revisión programada de frescura. Reentrena solo si el nuevo candidato supera a la versión desplegada y pasa todas las puertas de regresión.

Un ejemplo trabajado

Un plan de experimento modelado, no una ejecución completada: ajuste fino para una voz de soporte al cliente. El fragmento de Axolotl es una hipótesis inicial y debe reconciliarse con el esquema actual de Axolotl y la tarjeta del modelo seleccionado antes de la ejecución.

El problema: una empresa SaaS tiene una voz fuerte, amigable y en lenguaje llano en sus comunicaciones de soporte. Los prompts la reproducen de forma inconsistente. El equipo quiere coincidencia confiable de voz en todas las comunicaciones asistidas por IA.

El plan de datos: ejemplos históricos de soporte con los derechos de uso verificados, revisión de privacidad, procedencia, deduplicación, segmentos representativos, etiquetas de revisores y un conjunto retenido. Determina el recuento a partir de la cobertura y de una curva de aprendizaje, no de este artículo.

El enfoque a probar: LoRA sobre un modelo base abierto compatible con un rango inicial y un número de épocas tomados de una receta mantenida. Ejecuta primero un trabajo pequeño de perfilado; solo entonces estima hardware, tiempo transcurrido y coste. El servicio es un benchmark separado vía un servidor de inferencia compatible o host gestionado.

Cómo juzgarlo (decide esto antes del entrenamiento): haz que varios revisores de contenido cualificados califiquen a ciegas los borradores base y ajustados en un segmento retenido, define por adelantado el margen de aceptación y el tratamiento entre evaluadores, y puntúa también factualidad, cumplimiento de la tarea, política y seguridad. Si la diferencia no es concluyente, investiga la potencia estadística, la fiabilidad de la rúbrica, la cobertura de datos y el comportamiento del entrenamiento; no asumas una sola causa.

Mantenimiento: reevalúa cuando cambien la distribución de tickets, la política de marca, el modelo base o el registro de fallos. Mide el trabajo por ciclo en lugar de prometer un día.

Deliberadamente no imprimimos porcentajes precisos antes/después aquí: serían los números de nuestro escenario, no los tuyos, y las puntuaciones de coincidencia de voz no se transfieren entre conjuntos de datos. Cuando publiquemos nuestra propia ejecución medida, vendrá con el conjunto de evaluación y el protocolo de juicio adjuntos.

Así es un plan de ajuste fino verificable. Un resultado de producción exitoso requiere los artefactos de ejecución que faltan, controles de despliegue y una comparación medida.

Modos de fallo comunes

Algunos patrones:

Fallo 1: Sobreajuste (Over-fitting). Las métricas de entrenamiento mejoran mientras las métricas del conjunto retenido o con entrada desplazada se degradan. Diagnostica filtración, duplicación, capacidad, pasos, regularización y cobertura de segmentos; el remedio es específico de cada experimento.

Fallo 2: Olvido catastrófico. El entrenamiento intensivo en tareas acotadas degrada las capacidades generales. El modelo se vuelve bueno en tu tarea y peor en las demás. Solución: baja la tasa de aprendizaje, menos épocas o incluye datos diversos no relacionados con la tarea.

Fallo 3: Incompatibilidades de formato de datos. Los datos de entrenamiento tienen un formato distinto del que se usa con el modelo en producción. El ajuste fino aprende la distribución incorrecta. Solución: asegúrate de que los formatos de entrenamiento e inferencia coincidan exactamente.

Fallo 4: Cobertura insuficiente de evaluaciones. El conjunto de evaluación es fácil; la producción es difícil. El ajuste fino puntúa bien en evaluaciones; falla con usuarios reales. Solución: incluye casos difíciles en las evaluaciones.

Fallo 5: Caos de hiperparámetros. Ajustar hiperparámetros sin metodología. A veces mejor, a veces peor, sin aprendizaje. Solución: cambia una cosa a la vez, evalúa, aprende.

Fallo 6: Descuido en el mantenimiento. El adaptador desplegado no se reevalúa después de cambios del modelo base, servicio, datos, política o carga de trabajo. Solución: desencadena una comparación; reentrena solo cuando un nuevo candidato pase las puertas.

Fallo 7: Atención insuficiente a la seguridad. El ajuste puede cambiar los rechazos y otro comportamiento de seguridad en cualquier dirección. Evalúa segmentos de rechazo insuficiente, rechazo excesivo, jailbreak y uso legítimo; los ejemplos de entrenamiento no reemplazan a los controles deterministas.

Fallo 8: Ajuste para la métrica incorrecta. El entrenamiento empuja al modelo a optimizar una métrica específica, pero el valor real del usuario es algo diferente. Solución: elige métricas que se alineen con el valor del usuario, no solo proxies fáciles de medir.

Plantillas de experimento, no recetas copiadas

Úsalas como diseños de comparación. Selecciona el modelo, el volumen de datos, la configuración del adaptador y los valores de optimización a partir de la documentación fijada del modelo y la biblioteca, más el perfilado y las curvas de aprendizaje.

La pregunta estratégica

Más allá de la mecánica, el ajuste fino es una pregunta estratégica:

• ¿Queremos invertir en esta capacidad a largo plazo o usar modelos de vanguardia para todo?
• ¿Estamos dispuestos a mantener un ajuste fino indefinidamente?
• ¿Vale la pena la ganancia de calidad frente a la complejidad continua?

Decide a partir de la ganancia medida, las restricciones de servicio y gobernanza, y la carga continua de mantenimiento. La cartera correcta puede contener cero ajustes finos, un único adaptador acotado o varios modelos gestionados de forma independiente; este artículo no tiene evidencia de encuestas para un recuento universal.

Lanza selectivamente, mantén deliberadamente

Los métodos eficientes en parámetros hacen que más experimentos de adaptación sean técnicamente factibles para equipos pequeños. El calendario y el coste de producción siguen siendo específicos de la carga de trabajo y deben incluir datos, evaluación, servicio, gobernanza y mantenimiento — no solo cómputo de entrenamiento.

«La IA no es lo suficientemente buena» no es un objetivo entrenable. Nombra la tarea fallida y el segmento crítico, construye la línea base relevante, obtén los derechos sobre los datos, declara las puertas de aceptación y regresión, y luego prueba si el ajuste añade valor. Las ganancias duraderas solo se pueden afirmar tras obtener evidencia repetida en conjuntos retenidos, de seguridad, de servicio y de mantenimiento sobre el sistema lanzado.