Fine tuning con LoRA: cómo entrenar, evaluar y desplegar

El fine tuning con LoRA es un buen siguiente paso cuando un modelo sigue cometiendo los mismos errores de estilo, formato o ejecución de una tarea, incluso con un prompt bien trabajado. Entrena 2 matrices pequeñas por cada matriz de pesos que se adapta y mantiene congelados los pesos originales; QLoRA, además, almacena la base congelada con una precisión de 4 bits. El objetivo es lograr una mejora medible en la tarea y contar con un plan de despliegue que la conserve.

Documentación y restricciones de despliegue verificadas el 26 de octubre de 2026. Los mecanismos se describen en los artículos originales de LoRA y QLoRA.

Para quien desarrolla una aplicación, la decisión parte de un fallo recurrente. Un modelo de atención al cliente tiene la política correcta en su contexto, pero sigue eligiendo la etiqueta equivocada al derivar una consulta. Un asistente de escritura entiende el encargo, pero incumple una y otra vez el estilo editorial establecido. Son buenos candidatos. Si a un modelo le falta la política de reembolsos vigente, antes de entrenarlo hay que darle acceso a ella.

¿Qué es el fine tuning con LoRA?

LoRA modifica el comportamiento de un modelo al aprender una pequeña corrección para determinadas matrices de pesos. Durante el entrenamiento convencional con LoRA, las matrices originales permanecen congeladas. Una matriz de pesos es una tabla de valores aprendidos que transforma la información dentro del modelo; un adaptador es el conjunto adicional de parámetros aprendidos que modifica esa transformación.

Imagina que instalas un módulo de entrada a medida en un edificio existente. Conservas la estructura y cambias la forma en que las personas circulan por ella. El módulo es más pequeño que el edificio, pero sigue dependiendo de él. Del mismo modo, un adaptador LoRA no es un modelo de lenguaje completo ni sustituye a su modelo base.

El nombre significa adaptación de bajo rango, del inglés Low-Rank Adaptation. En lugar de aprender una actualización del mismo tamaño que la matriz de pesos, LoRA la representa como el producto de matrices más pequeñas, normalmente llamadas A y B. En una capa lineal, la transformación efectiva se puede expresar como W + sBA: los pesos congelados W más la actualización del adaptador multiplicada por un factor de escala. La entrada recorre tanto la ruta de la base como la del adaptador, y ambas salidas se suman. Formulación original de LoRA.

Así, el adaptador puede aprender un formato propio sin guardar una copia modificada de cada peso de la base. Por la misma razón, el modelo base ya debe ofrecer un punto de partida razonable para la tarea. La corrección tiene que funcionar con el modelo elegido.

Un ejemplo de parámetros, no una promesa de ahorro de memoria GPU

Consideremos una capa hipotética con 4,096 × 4,096 pesos, es decir, 16,777,216 parámetros originales. Con un rango de 8, sus matrices LoRA tienen 8 × 4,096 y 4,096 × 8 parámetros. En total, suman 65,536 parámetros entrenables, aproximadamente el 0.39% de los que tiene la matriz original.

Es un cálculo nuestro a partir de las dimensiones de las matrices del artículo, no un benchmark ni una recomendación de rango. Describe una sola matriz adaptada. Los pesos congelados siguen presentes y el entrenamiento también necesita memoria de trabajo para los cálculos intermedios, los gradientes del adaptador y el estado del optimizador. Este estado es la información que el optimizador conserva para decidir la siguiente actualización del entrenamiento.

La lección práctica es distinguir entre cuántos parámetros actualizas y cuánta memoria necesita todo el proceso. Un adaptador diminuto no vuelve diminuto al modelo que lo sostiene.

La distinción entre los métodos se basa en los artículos de LoRA y QLoRA. Ninguna de estas etiquetas garantiza un resultado concreto con tus datos.

Fine tuning con LoRA: rango, módulos objetivo y escala

Estos ajustes controlan el tamaño y la ubicación de la corrección, no cuánta inteligencia adquiere el modelo. El rango es la dimensión interna de A y B: aumentarlo añade parámetros entrenables. Los módulos objetivo indican qué partes del modelo reciben adaptadores. Alpha controla la escala de la actualización, mientras que dropout puede regularizar el entrenamiento del adaptador. La referencia de configuración de LoRA define estos controles.

Parte de una configuración de entrenamiento que se mantenga al día para tu modelo y cambia un ajuste cuando los resultados de validación lo justifiquen. Si el modelo confunde dos categorías de atención al cliente, revisa primero si hay etiquetas contradictorias o faltan ejemplos que delimiten las categorías. Aumentar el rango no le dirá cuál de dos ejemplos contradictorios considera correcto tu empresa.

Revisa también qué parámetros se pueden entrenar. Algunas configuraciones entrenan módulos adicionales, como una capa de salida, junto con los adaptadores. Llamar «LoRA» a un entrenamiento no demuestra que solo hayan cambiado A y B; eso lo determina la configuración.

¿Qué aporta QLoRA y qué queda fuera de su alcance?

QLoRA aborda tanto la memoria que ocupa el modelo base congelado como la cantidad de parámetros que se entrenan. Su configuración principal almacena la base en 4 bits y entrena adaptadores LoRA de mayor precisión a través de ella. La base está congelada, pero sigue participando en los cálculos con los que aprende el adaptador. Artículo de QLoRA.

El artículo combina NF4, una representación numérica diseñada para pesos con distribución normal; doble cuantización, que comprime las constantes utilizadas en la cuantización; y optimizadores paginados, que gestionan los picos de memoria. No necesitas implementar estos mecanismos por tu cuenta para seguir una configuración de entrenamiento QLoRA que se mantenga al día.

La expresión «entrenamiento en 4 bits» puede prestarse a confusión. No significa que cada cálculo, activación y parámetro del adaptador utilice cuatro bits. Tampoco implica que entrenar un modelo requiera la misma memoria que cargar sus pesos cuantizados. Los ejemplos largos y los lotes más grandes siguen consumiendo memoria de trabajo.

Elige QLoRA cuando el obstáculo sea la memoria del modelo base y las herramientas de entrenamiento sean compatibles con el modelo que necesitas. Si LoRA convencional ya cabe en memoria, compara ambos métodos con tus casos de validación en vez de asumir que cuantizar siempre es mejor. La compresión cambia la configuración numérica; su efecto en tu tarea debe formar parte de la evaluación.

Nuestra guía de cuantización de LLM explica una cuestión distinta del despliegue: qué representación comprimida puede ejecutar tu motor de inferencia. Entrenar un adaptador con QLoRA no lo hace compatible con todos los formatos cuantizados de inferencia.

¿Cuándo conviene el fine tuning frente a los prompts o RAG?

Recurre al fine tuning cuando el fallo que persiste sea un comportamiento estable que puedas mostrar con ejemplos aprobados. Sigue usando prompts cuando unas instrucciones claras ya satisfagan tus requisitos. Usa generación aumentada por recuperación, o RAG, para aportar documentos relevantes o datos de una base de datos al recibir cada solicitud. El marco de decisión completo está en RAG frente a fine tuning.

Para el estilo editorial propio, prueba primero con una especificación breve de estilo y ejemplos representativos en el prompt. Considera entrenar cuando el comportamiento deseado esté definido y las mismas infracciones se repitan con entradas variadas. Los ejemplos deben enseñar decisiones, como empezar por la respuesta o evitar superlativos sin fundamento, en lugar de limitarse a repetir una frase característica.

Para el formato, separa la sintaxis del significado. Si tu entorno de ejecución permite restringir la salida a una estructura, pruébalo antes de entrenar solo para obtener JSON válido. Una respuesta puede respetar el esquema y, aun así, elegir la categoría equivocada. LoRA cobra más interés cuando el problema persistente está en esa decisión semántica. Mantén la validación de la aplicación incluso después de que el adaptador mejore.

Para una tarea acotada, define el límite entre decisiones. Una consulta sobre un cargo desconocido puede requerir verificar la cuenta, mientras que un pago duplicado confirmado exige una revisión de facturación. Entrena con pares de entrada y salida aprobados que muestren esa diferencia, incluidos los casos que requieren pedir aclaraciones. El beneficio es tomar mejor una decisión repetible, no poder afirmar de forma general que el modelo es más inteligente.

Para el conocimiento que cambia, la recuperación sigue siendo la fuente de referencia más adecuada. Un adaptador de estilo no debe determinar cuál es la disponibilidad actual de un producto. Puedes combinar recuperación y fine tuning: recupera la política más reciente y entrena al modelo para que use la evidencia aportada y responda con la estructura requerida. Evalúa esa aplicación combinada con el mismo contexto recuperado en ambos lados de la comparación.

Para quienes desarrollan, esto significa medir el error que persiste antes de elegir las herramientas de entrenamiento. Para quienes operan el sistema, significa hacerse responsables de los ejemplos aprobados y decidir qué errores importan. Para quienes compran, significa pedir los resultados comparativos de antes y después y el artefacto exacto que se puede desplegar, sin aceptar «modelo personalizado» como prueba de mejora.

Si un modelo profesor de mayor tamaño genera ejemplos de entrenamiento para otro más pequeño, también se trata de un proceso de destilación de modelos. LoRA describe qué parámetros actualiza el alumno; la destilación describe de dónde procede la señal con la que aprende. Ambos métodos pueden combinarse, pero las respuestas objetivo generadas siguen necesitando revisión.

Cómo elegir entre una API alojada y tu propia GPU

Elige un servicio alojado si sus modelos compatibles, el tratamiento de los datos y las opciones de despliegue encajan con tu aplicación. Usa tu propia GPU si necesitas controlar el checkpoint, la configuración de entrenamiento y el entorno de ejecución, y puedes operar ese conjunto de herramientas. Decide cómo servirás el modelo antes de iniciar el entrenamiento.

Together AI: entrenamiento LoRA explícito y exportación

Together AI ofrece una API de fine tuning alojada cuya guía de inicio rápido lanza expresamente un entrenamiento LoRA. Su llamada de Python, client.fine_tuning.create(), utiliza LoRA por defecto y permite establecer lora=True de forma explícita. El proceso consiste en preparar datos conversacionales, validarlos y subirlos, entrenar y desplegar el resultado. Guía de inicio rápido de Together AI.

La limitación está en qué modelos se pueden desplegar. Que un modelo admita entrenamiento no significa que esté disponible en modalidad serverless; la guía actual sirve los modelos ajustados mediante inferencia dedicada. Antes de comprometerte con una base, comprueba que tenga una opción de despliegue dedicado compatible.

La exportación se decide por separado. Together documenta checkpoint="adapter" para exportar solo los pesos del adaptador y checkpoint="merged" para obtener un checkpoint que combine la base y el adaptador. Usa el adaptador si tu entorno de ejecución lo va a cargar sobre la base correspondiente; elige el artefacto fusionado si necesitas un modelo autónomo. Despliegue y tipos de checkpoint.

Fireworks AI: comprueba por separado el entrenamiento y la inferencia

Fireworks AI documenta LoRA dentro de su proceso de fine tuning supervisado gestionado. El fine tuning supervisado, o SFT, aprende de ejemplos de la respuesta deseada. Para solicitar expresamente un entrenamiento de adaptadores, su API REST usa loraRank; el SDK de Python usa lora_rank. Documentación de SFT de Fireworks.

Conviene distinguir entre Tunable y Supports Lora. Una base puede admitir un adaptador entrenado fuera de la plataforma para hacer inferencia sin permitir que se entrene en Fireworks. La guía de entrenamiento también acepta un evaluation_dataset independiente, de modo que puedes aportar tus propios ejemplos de validación en lugar de depender de la división automática de los datos.

Para servir el modelo, Fireworks documenta live merge, que fusiona un adaptador al desplegarlo, y multi-LoRA, que aplica el adaptador seleccionado a una base compartida. Su guía actual de despliegue indica que los LoRA entrenados requieren despliegues dedicados bajo demanda; no se admite el despliegue serverless. También señala que las configuraciones de despliegue FP8 y FP4 no admiten complementos LoRA. Por tanto, una opción de despliegue comprimida no es necesariamente compatible con adaptadores. Guía de despliegue de Fireworks.

¿PEFT o Unsloth para el ajuste fino con LoRA?

Hugging Face PEFT es la biblioteca abierta de métodos de fine tuning eficientes en parámetros, entre ellos LoRA. Elígela si quieres controlar de forma explícita el modelo, la configuración de cuantización y los módulos del adaptador. Su guía de cuantización documenta cómo cargar una base cuantizada, prepararla para el entrenamiento y añadir después el adaptador.

El procedimiento documentado para QLoRA usa BitsAndBytesConfig con load_in_4bit=True, NF4 y doble cuantización; prepare_model_for_kbit_training() prepara el modelo antes de que get_peft_model() lo encapsule. Para aplicar adaptadores a las capas lineales al estilo de QLoRA, la guía usa target_modules="all-linear". Entiéndelo como un patrón de configuración compatible, no como prueba de que cualquier arquitectura o entorno de inferencia posterior acepte cualquier adaptador.

La limitación de PEFT está en el resto del sistema de entrenamiento: no elige tus ejemplos, no corrige tu plantilla de chat ni aporta la métrica de éxito de tu producto.

Unsloth es un conjunto abierto de herramientas de entrenamiento con guías y notebooks de fine tuning que se mantienen al día. Su guía documenta LoRA, QLoRA y el fine tuning completo, incluido load_in_4bit=True para la opción cuantizada. Elígelo cuando haya un notebook actualizado que encaje con el modelo y el hardware que piensas usar, y tómalo como configuración inicial. Guía de fine tuning de Unsloth.

La limitación de Unsloth es la compatibilidad de la configuración de entrenamiento. Que un notebook termine de entrenar no demuestra que el modelo exportado conserve el mismo comportamiento en otro entorno. Mantén coherentes el tokenizador, la plantilla de chat y los ajustes de generación, y evalúa después el artefacto que se sirve. Una plantilla de chat es el formato que identifica para el modelo los roles de usuario, asistente y demás mensajes.

Hugging Face TRL aporta SFTTrainer, un bucle de entrenamiento supervisado que se integra con PEFT. Admite conjuntos de datos de entrenamiento y evaluación, así como assistant_only_loss=True con plantillas de chat compatibles para aprender de las respuestas del asistente en lugar de todos los tokens de la conversación. Su limitación es que la plantilla debe admitir la máscara necesaria para identificar los tokens del asistente; revisa cómo quedan formateados los ejemplos de entrenamiento. SFTTrainer de TRL.

Para un experimento con GPU propia, la secuencia es concreta: selecciona una base y una configuración de entrenamiento compatibles, aplica la plantilla a una conversación de ejemplo, comprueba qué tokens contribuyen a la función de pérdida, añade el adaptador, aporta los datos de entrenamiento y validación, y guarda checkpoints. Un checkpoint es una versión guardada que puedes evaluar o restaurar. Nuestra guía para hacer fine tuning de un LLM aborda las demás decisiones del proyecto.

Cómo servir los adaptadores y cambiar entre ellos

Un adaptador debe ir acompañado de la identidad y la configuración de su modelo base. En PEFT, save_pretrained() guarda los pesos del adaptador y adapter_config.json; esos archivos no sustituyen a los pesos de la base. Conserva junto al adaptador la revisión exacta de la base, el tokenizador, la plantilla de chat y la configuración de entrenamiento. Formato de checkpoints de PEFT.

Mantén los adaptadores separados si varias variantes de una tarea deben compartir una base o si necesitas poder cambiar entre ellas. En PEFT, load_adapter() carga otro adaptador con nombre propio y set_adapter() lo selecciona. Cargar y activar son operaciones distintas. El gestor de contexto disable_adapter() permite hacer inferencia con el comportamiento de la base. API de modelos de PEFT.

La distinción resulta útil para evaluar, pero la selección de adaptadores en una aplicación compartida también debe funcionar correctamente con solicitudes concurrentes. No cambies el adaptador activo de un único modelo global mientras se procesan solicitudes independientes dando por hecho que cada una recibirá el comportamiento previsto. Usa un entorno de inferencia que defina de forma explícita cómo asigna el adaptador a cada solicitud.

vLLM es un motor de inferencia que admite LoRA en implementaciones de modelos compatibles. Su servidor usa --enable-lora y --lora-modules para registrar adaptadores; las solicitudes seleccionan uno mediante el campo model. Comprueba la compatibilidad del modelo con LoRA, el rango máximo del adaptador y la capacidad configurada de adaptadores simultáneos. Son restricciones de inferencia, no ajustes de entrenamiento. Documentación de LoRA en vLLM.

También se documentan la carga y descarga de adaptadores durante la ejecución, pero vLLM desaconseja usar esta capacidad en producción salvo que el entorno esté aislado y sea plenamente confiable. En un despliegue habitual, registrar adaptadores conocidos al iniciar el servidor simplifica la operación.

Fusiona el adaptador si quieres un modelo autónomo y no necesitas cambiar de adaptador en ese artefacto. En PEFT, merge_and_unload() incorpora la actualización a la base y devuelve un modelo sin las funciones de adaptadores de PEFT. Algunas configuraciones de cuantización no permiten la fusión. Conserva el adaptador original y la base por separado si quieres recuperar más adelante esa forma de trabajar. Limitaciones de la fusión en PEFT.

La portabilidad tiene una última condición: la base correspondiente debe tener los pesos exactos, no basta con que pertenezca a una familia de modelos conocida. Fireworks advierte expresamente que el checkpoint del proveedor utilizado para entrenar puede diferir de los pesos públicos. Confirma esa dependencia antes de sacar un adaptador de la plataforma. Guía de exportación de adaptadores.

Fine tuning con LoRA: cómo comparar el antes y el después

Publica el adaptador elegido solo si mejora el comportamiento objetivo en ejemplos que no hayan influido en su selección. Que la pérdida de entrenamiento disminuya significa que el modelo se ajusta mejor a sus ejemplos de entrenamiento; no es un criterio suficiente para lanzarlo.

Usa este protocolo de evaluación para el ejemplo de clasificación y derivación de consultas de atención al cliente. Es un procedimiento recomendado, no el informe de un experimento de entrenamiento.

1. 1

   Define los criterios de aceptación antes de entrenar

   Establece las etiquetas permitidas, los campos obligatorios de la salida y el comportamiento de derivación. Decide qué errores impiden el lanzamiento. Para el estilo editorial, escribe reglas observables, como «dar la respuesta antes de explicar el contexto» y «no añadir afirmaciones sin respaldo». Una instrucción vaga como «que suene mejor» no permite una comparación fiable.

2. 2

   Separa los casos de entrenamiento, validación y prueba final

   Los casos de entrenamiento actualizan el adaptador. Los de validación sirven para elegir la configuración y el checkpoint. La prueba final permanece reservada hasta que esas decisiones estén cerradas. Mantén las consultas relacionadas, las paráfrasis de un mismo documento y los ejemplos casi duplicados en la misma partición. De lo contrario, la prueba puede premiar la familiaridad en vez de la capacidad de generalizar.

3. 3

   Registra una referencia sólida

   Ejecuta la base sin ajustar con el mejor prompt que puedas usar en la práctica y con los controles de salida estructurada que pienses conservar. En una aplicación con recuperación, registra también la evidencia recuperada. Guarda la revisión del modelo, el prompt, la plantilla, los ajustes de generación, las salidas y la versión del evaluador. El adaptador debe superar una alternativa viable, no un prompt deliberadamente débil.

4. 4

   Selecciona con la validación y compara después en la prueba reservada

   Usa los resultados de validación para elegir el checkpoint y deja esa elección cerrada. Ejecuta ese adaptador y el sistema de referencia sobre las mismas entradas de la prueba final, con ajustes equivalentes. Si la aplicación prevista utiliza un prompt más corto después del entrenamiento, mídelo por separado de la comparación controlada del adaptador para que quede claro de dónde procede la mejora.

5. 5

   Evalúa el artefacto que vas a servir

   Después de fusionar, cuantizar o cambiar de motor de inferencia, vuelve a ejecutar los controles de aceptación sobre el artefacto desplegado. Incluye entradas largas, solicitudes ambiguas y casos que deban conservar el comportamiento de la base. Lanza el modelo solo si la mejora buscada se mantiene tras el despliegue y los controles de regresión siguen dando resultados aceptables.

Puntúa por separado la sintaxis, el acierto en la tarea y el estilo. Para el modelo de atención al cliente, un objeto JSON impecable con una decisión de derivación equivocada sigue siendo un error. Para el modelo de escritura, una respuesta más pulida que inventa una afirmación sobre el producto supone una regresión.

Informa de los denominadores y los resultados por categoría, no solo de un porcentaje global de éxito. La precisión mide cuántas veces es correcta una categoría predicha; la exhaustividad mide cuántos de los casos reales de esa categoría detecta el modelo. Si la mayoría de los ejemplos son preguntas rutinarias de facturación, el promedio general puede ocultar fallos en una categoría de derivación poco frecuente pero importante. Incluye tanto los aciertos que se convirtieron en fallos como los fallos que pasaron a ser aciertos.

Para la revisión subjetiva del estilo, oculta de qué modelo procede cada salida y varía el orden de presentación. Un modelo evaluador puede ayudar a organizar la revisión, pero contrasta sus decisiones con juicios humanos antes de usar su puntuación como criterio de lanzamiento. Lo que determina su utilidad es la rúbrica, no la fluidez con la que explica su juicio.

No conviertas la prueba final en un segundo conjunto de validación. En cuanto examinas sus fallos y los usas para modificar la configuración de entrenamiento, esos casos ya han influido en el desarrollo. Consérvalos como casos de regresión y reserva otros nuevos, aún sin utilizar, para la siguiente comparación final. Aquí no hay una regla universal sobre el tamaño del conjunto de datos: lo decisivo es si la evaluación representa las decisiones que encontrará tu aplicación.

Por último, compara la latencia y el consumo de recursos del sistema desplegado con la carga de trabajo que tendrá que atender. El ahorro de parámetros de LoRA no demuestra que la inferencia sea más rápida. Conserva la versión de base y adaptador que superó las pruebas, guarda una versión a la que puedas volver y supervisa las mismas categorías de error después del lanzamiento.

¿Qué se exagera sobre LoRA?

«Fine tuning barato» describe una optimización más limitada que «personalización barata». Sigues necesitando ejemplos aprobados, evaluación, infraestructura de inferencia y mantenimiento. Ni un checkpoint más pequeño ni un registro de entrenamiento sin errores demuestran que la aplicación haya mejorado.

Congelar los pesos no congela el comportamiento. El adaptador cambia deliberadamente las salidas del modelo, por lo que hay que seguir comprobando posibles regresiones en sus capacidades generales, su comportamiento de rechazo y la calidad de las respuestas. Quitar el adaptador puede restablecer la ruta de la base; mantenerlo activo no garantiza que las respuestas a otras tareas sigan iguales.

LoRA no tiene garantizado igualar al fine tuning completo. El artículo original presenta buenos resultados en las tareas evaluadas. Eso aporta evidencia a favor del método, no demuestra una equivalencia universal. Si un adaptador bien evaluado sigue sin cumplir el requisito, investiga los datos, el modelo base y la tarea antes de asumir que la solución es un entrenamiento de mayor alcance.

No existe un rango mágico, una cantidad de ejemplos ni una estimación de horas de GPU que sirva para todo. La arquitectura del modelo, la longitud de las secuencias, los módulos objetivo y la tarea concreta cambian el experimento. Parte de una configuración documentada y deja que la validación justifique el siguiente cambio.

Preguntas frecuentes sobre fine tuning con LoRA

¿En qué consiste el fine tuning con LoRA?

Consiste en entrenar matrices adicionales de bajo rango mientras los pesos originales de la base permanecen congelados. El adaptador aprendido modifica el cálculo de la base y necesita ese modelo base para la inferencia, salvo que se fusionen los pesos.

¿Se ha demostrado que el fine tuning no funciona?

Un experimento fallido o un benchmark no permiten emitir un veredicto general. Para tu aplicación, compara el mejor sistema de referencia con prompts que puedas usar en la práctica con el modelo entrenado, utilizando casos reservados. Si no mejora el comportamiento requerido, no lo despliegues.

¿Cuánto cuesta hacer fine tuning?

Depende del modelo, los datos procesados, la configuración de entrenamiento y la forma de servirlo. LoRA reduce los parámetros entrenables, pero no elimina la preparación de datos, la evaluación ni el alojamiento. Elige un proceso compatible de entrenamiento e inferencia antes de consultar sus tarifas publicadas vigentes; no hay un precio universal por entrenamiento que resulte útil.

¿Cuál es un ejemplo de fine tuning?

Entrenar con mensajes de atención al cliente aprobados, cada uno asociado a la categoría, la acción de derivación y el formato de respuesta correctos. Los ejemplos enseñan un patrón de decisión recurrente; los datos actuales del cliente siguen teniendo que aportarse al recibir cada solicitud.

¿Se sigue utilizando el fine tuning?

Sí. Together AI, Fireworks AI, Hugging Face PEFT y Unsloth documentan opciones actuales de entrenamiento. Que sea la elección adecuada depende del fallo que persista después de trabajar el prompt y, cuando haga falta, la recuperación de información.

¿Cómo puedo hacer fine tuning?

Define una métrica para la tarea, establece un sistema de referencia, prepara datos separados de entrenamiento y evaluación, elige un modelo y una configuración compatibles, entrena, selecciona mediante validación y compara en una prueba final reservada antes de desplegar. Comprueba también el artefacto desplegado.

¿Qué son PEFT y LoRA?

PEFT significa fine tuning eficiente en parámetros: una familia de métodos que entrena un conjunto limitado de parámetros. Hugging Face PEFT es también una biblioteca que implementa esos métodos. LoRA es uno de los métodos de esa familia.

¿Qué modelos permiten hacer fine tuning?

Consulta la lista exacta de modelos compatibles con tu proveedor alojado o tus herramientas abiertas de entrenamiento, junto con la licencia del modelo. La compatibilidad con el entrenamiento, la inferencia con adaptadores y la disponibilidad de los pesos de la base son comprobaciones distintas. El nombre de una familia de modelos no basta.

¿Cómo se dice fine tuning en español?

En este contexto, ajuste fino, adaptación a una tarea o continuación del entrenamiento con ejemplos específicos. La ingeniería de prompts cambia las instrucciones que se proporcionan durante la inferencia; el fine tuning cambia los parámetros aprendidos.

El siguiente paso para tu aplicación

La próxima semana, toma un fallo recurrente de la aplicación que ya operas y conviértelo en una prueba de aceptación explícita. Reúne ejemplos aprobados, agrupa los casos relacionados antes de dividir los datos y mide el mejor sistema de referencia con prompts. Si ese sistema falla en un comportamiento estable, elige un procedimiento documentado de LoRA cuyo resultado puedas servir. Entrena solo cuando esas decisiones estén claras.

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