Desarrollo de Modelos y Ajuste Fino

La mayoría de los proyectos de ajuste fino fracasan antes de que empiece el entrenamiento

La factura de GPU no es la parte cara del ajuste fino empresarial. Un modelo de 7B parámetros se ajusta en una sola A100 por 100-400 USD en cómputo; un modelo de 70B cuesta 4000-9750 USD por ejecución de entrenamiento. Lo que mata los proyectos es todo lo que rodea al bucle de entrenamiento: curar miles de ejemplos específicos del dominio, evitar que el modelo olvide lo que ya sabe, validar que la alineación de seguridad sobrevivió al entrenamiento, cuantizar para el servicio en producción y construir la canalización de monitorización que detecta la deriva.

Gartner predice que para 2027, las organizaciones usarán modelos de IA pequeños y específicos por tarea tres veces más que los LLM de propósito general. El cambio ya está en marcha: el 68% de las empresas que ajustaron modelos en 2024 reportaron hasta 3 veces de mejora en la precisión de las tareas. Pero la brecha entre un experimento en cuaderno y un despliegue en producción es donde se estancan la mayoría de los proyectos. Nuestro enfoque consiste en diseñar la canalización completa, no solo el bucle de entrenamiento (una disciplina detallada en nuestra investigación sobre la ingeniería de sistemas más allá de los envoltorios de API).

Cuándo el ajuste fino es la decisión correcta (y cuándo no lo es)

La ingeniería de prompts tarda horas. RAG tarda de una a cuatro semanas. El ajuste fino tarda de dos a ocho semanas, incluida la creación del conjunto de datos, el entrenamiento, las pruebas de seguridad y el endurecimiento para producción. Comenzamos cada proyecto evaluando si el ajuste fino es realmente necesario.

Haga ajuste fino cuando:

• el modelo necesita un nuevo comportamiento o formatos de salida que los prompts no pueden producir de forma fiable;
• su dominio tiene patrones de razonamiento especializados que los modelos genéricos manejan de forma inconsistente;
• necesita una inferencia rentable a escala: un modelo de 7B ajustado a 0,20 USD/M de tokens reemplaza a uno de 70B a 2 USD/M;
• está construyendo sistemas agénticos donde la fiabilidad de la invocación de herramientas importa: los SLM ajustados mejoraron el éxito de la invocación de herramientas del 10% al 79% en las pruebas de referencia (véase una demostración funcional de uno de esos sistemas agénticos de programación).

No haga ajuste fino cuando:

• el problema es la recuperación de conocimiento (use RAG);
• el conjunto de datos tiene menos de 1000 ejemplos por tarea;
• la ingeniería de prompts ya logra una precisión aceptable;
• el modelo base cambia más rápido que su cadencia de reentrenamiento.

Cuando RAG resuelve el problema y el ajuste fino solo desperdiciaría presupuesto, nuestro enfoque consiste en decirlo antes de dimensionar cualquier entrenamiento, en lugar de vender un proyecto que no necesita. Esa honestidad está integrada en cómo dimensionamos un proyecto.

La elección del marco de trabajo importa

El panorama de 2026 se ha consolidado en torno a herramientas diferenciadas, cada una de las cuales resuelve un problema distinto.

Elegimos en función de su escala de entrenamiento, la arquitectura del modelo y los objetivos. La mayoría de los despliegues en producción usan más de uno: Axolotl para el ajuste fino supervisado, TRL para la optimización de preferencias y Unsloth para el prototipado rápido.

La alineación de seguridad no sobrevive a un ajuste fino ingenuo

La investigación de EMNLP 2024 demostró que ajustar los LLM con nuevo conocimiento factual aumenta la propensión a la alucinación. Por separado, investigadores de Princeton, Stanford, Virginia Tech e IBM mostraron que el ajuste fino estándar permitía a los modelos eludir por completo el entrenamiento de seguridad. Desde entonces, la investigación de ICLR 2026 ha mostrado que un ajuste cuidadoso de los hiperparámetros mitiga estos riesgos, pero las configuraciones predeterminadas de los marcos de trabajo se distribuyen sin protecciones.

El mecanismo: las actualizaciones agresivas de parámetros en las capas superiores sobrescriben las características responsables de la seguridad. La selección del rango de LoRA es crítica: los adaptadores de mayor rango en las capas de atención pueden desestabilizar los circuitos de rechazo, y la configuración segura depende de la arquitectura específica del modelo y de los datos de la tarea.

Nuestro enfoque consiste en implementar canalizaciones que preservan la seguridad (fundamentadas en nuestra investigación sobre la gobernanza de la seguridad de la IA en el espacio latente):

• LoRA selectivo que protege los circuitos críticos;
• pruebas de referencia de seguridad reservadas en cada punto de control;
• detención temprana basada en métricas compuestas que equilibran el rendimiento de la tarea frente a la preservación de las capacidades;
• monitorización continua de la degradación de la alineación a lo largo de todo el entrenamiento.

La curación de datos es el verdadero cuello de botella

Las horas de GPU son una partida presupuestaria. La curación de datos es el proyecto:

• conseguir que los expertos en la materia etiqueten de 5000 a 50 000 ejemplos de alta calidad;
• resolver los desacuerdos de anotación con métricas de acuerdo entre anotadores;
• ejecutar la deduplicación MinHash/LSH;
• verificar la contaminación frente a los conjuntos de evaluación;
• documentar la procedencia con hojas de datos.

El RLAIF (usando GPT-4 como etiquetador) reduce el costo de los datos de preferencia, pero introduce el sesgo del modelo maestro. Los datos sintéticos mediante destilación maestro-estudiante impulsan los conjuntos de entrenamiento, aunque la calidad está limitada por las capacidades del modelo maestro.

Un proyecto se dimensiona para cubrir el diseño de la canalización de datos, los flujos de trabajo de anotación, la validación de calidad y la documentación para sectores regulados: la validación de software de la FDA, los informes de validación de modelos financieros y la documentación técnica de la Ley de IA de la UE con fichas de modelo que cumplen los requisitos del Artículo 11(1).

Del entrenamiento a la producción

Cuantización

Haga el ajuste fino en FP16, fusione los adaptadores y luego cuantice. AWQ INT4 con el kernel Marlin ofrece la mejor relación rendimiento-calidad para el servicio con vLLM (741 tok/s). GPTQ se integra con TensorRT-LLM y TGI. GGUF es nativo para llama.cpp y Ollama. Adaptamos la cuantización a su pila de servicio.

Proveedor frente a código abierto

OpenAI cobra ~3 USD/M de tokens por el ajuste fino de GPT-4.1. El Small 3.1 ajustado de Mistral a 0,20 USD/M iguala a su Large 3 a 2 USD/M en tareas específicas. Anthropic no ofrece ajuste fino público. Las API de proveedores funcionan para una iteración rápida cuando la gobernanza de datos permite el uso de infraestructura de terceros.

Los modelos de código abierto (Llama 3, Mistral, Qwen) con entrenamiento autoalojado son la opción adecuada cuando los datos deben permanecer en su infraestructura o cuando los requisitos regulatorios lo exigen. La mayoría de las empresas usan ambos.

Monitorización y reentrenamiento

Los modelos en producción se desvían. Nuestro enfoque consiste en construir canalizaciones que rastrean la calidad de las predicciones, detectan la deriva de datos y de concepto, y activan el reentrenamiento cuando se cruzan los umbrales. MLflow o Weights and Biases se encargan del seguimiento de experimentos, con registros de modelos que proporcionan el linaje completo desde los datos de entrenamiento hasta el artefacto desplegado.

Alineación posentrenamiento: más allá del SFT

El estándar de producción de 2026 es una canalización modular: SFT para el seguimiento de instrucciones, DPO o SimPO para la alineación de preferencias y GRPO para el razonamiento.

El DPO desplazó al RLHF PPO al eliminar el modelo de recompensa. SimPO eliminó el modelo de referencia mientras superaba al DPO en 6,4 puntos en AlpacaEval 2. GRPO (de DeepSeek R1) usa recompensas verificables para entrenar el razonamiento mediante RL puro (una técnica que exploramos en nuestra investigación sobre el aprendizaje por refuerzo en grafos), con autorreflexión y verificación emergentes. Implementamos estos métodos usando TRL, el marco de trabajo que acierta con la dinámica del entrenamiento por RL.

Lo que entregamos

Cada proyecto se dimensiona para producir un sistema desplegable:

• el modelo ajustado con fichas de modelo completas;
• la canalización de entrenamiento como código reproducible con seguimiento de experimentos;
• un conjunto de evaluación que compara el rendimiento frente al modelo base y las alternativas en cuanto a precisión, latencia, robustez y calibración;
• el artefacto de despliegue cuantizado con una configuración de servicio optimizada;
• paneles de monitorización con detección de deriva y activadores de reentrenamiento;
• para sectores regulados, documentación de validación específica del sector (Ley de IA de la UE, FDA, validación de modelos financieros).

El proyecto también produce una evaluación honesta: si el ajuste fino era el enfoque adecuado, qué no puede hacer el modelo y dónde se sitúa el techo de rendimiento. Las limitaciones documentadas de antemano ahorran más dinero que las proyecciones optimistas.