Cómo se crea una familia de modelos

Crear una familia de modelos no tiene por qué empezar por entrenar una inteligencia artificial desde cero. Puede empezar con modelos ya disponibles, una función bien definida y una pregunta: ¿qué necesita hacer bien cada integrante de esa familia?

Entender este trabajo empieza por distinguir conceptos que suelen aparecer juntos: modelo base, merge, fine-tuning, adapter y aprendizaje por refuerzo. Cada uno tiene su papel. Ninguno, por sí solo, define una familia.

Antes de las herramientas, el tronco y las ramas

Un modelo base es un punto de partida ya entrenado. Lleva consigo capacidades y limitaciones de su entrenamiento. No es una página en blanco, y tener un alcance amplio no significa saber de todo ni servir igual de bien para cualquier tarea.

Un modelo orientado a un dominio se prepara para un ámbito: un área de conocimiento, un tipo de documento o una necesidad de uso. Marketing y documentación técnica son ejemplos de ámbitos posibles; mantener un estilo o extraer campos son ejemplos de funciones que pueden existir dentro de ellos.

La imagen de un árbol ayuda: un tronco común puede dar lugar a ramas con funciones diferentes. Es una manera de organizar una familia, no una regla que obligue a todos los proyectos a tener exactamente el mismo origen. La familia es el conjunto planificado; una técnica de adaptación, por sí sola, no define ese conjunto.

El papel de cada modelo

Una familia empieza con funciones definidas. ¿Qué tarea recibe cada modelo? ¿Cómo debe entregar la respuesta? ¿Qué errores vuelven inútil el resultado? ¿Qué queda fuera de su función?

Sin esas respuestas, es fácil terminar con varios archivos de modelos y ninguna diferencia clara entre lo que ofrece cada uno. Una familia especializada necesita papeles que tengan sentido para quienes la van a usar.

La elección de la base

La elección de un modelo base influye en las capacidades, las limitaciones y las posibilidades de adaptación de cada integrante. Esa elección forma parte del diseño de la familia.

También hay que comprobar qué permite hacer cada licencia con los modelos y sus derivados. La licencia de la herramienta utilizada para trabajar con los pesos no sustituye la licencia de los propios modelos.

Una base de dominio puede sostener varias especializaciones

Entre una base de alcance general y un modelo preparado para una tarea específica, puede existir una base de dominio. Concentra conocimiento y patrones de un área, pero sigue siendo un punto de partida para distintas aplicaciones dentro de ese ámbito.

En ese sentido, es más neutra respecto a la aplicación final: todavía no está comprometida con una sola función, un formato de respuesta o un estilo de atención. Esa neutralidad es relativa al uso posterior; no significa ausencia de sesgos o limitaciones.

Una misma base de dominio puede sostener un modelo orientado a la documentación, otro a la extracción de información y otro a la interacción con el usuario. Comparten unos cimientos, pero cada uno necesita preparación y evaluación propias para la función que va a asumir.

Elegir una base existente y desarrollar una base de dominio son decisiones distintas. La segunda puede apoyarse en un modelo ya entrenado y continuar su preparación para esa área. Crear esos cimientos comunes forma parte del diseño de una familia; no exige, por definición, empezar con pesos aleatorios.

Combinar puede ser una etapa

MergeKit es una herramienta para combinar pesos de modelos entrenados. Eso es distinto de reunir respuestas de varios modelos durante una conversación: la operación produce un nuevo artefacto a partir de los pesos elegidos.

Existen distintos métodos para esa combinación. Toman decisiones sobre cómo mezclar las contribuciones de los modelos y manejar sus diferencias. La elección depende de los modelos implicados y del resultado que se quiera investigar; hay que comprobar la compatibilidad.

Combinar un modelo que escribe bien con otro que razona bien no garantiza un resultado que reúna lo mejor de ambos. El merge crea un candidato. La evaluación dirá si conservó capacidades, ganó algo útil o empeoró en lo que importaba.

El proyecto ofrece vías de ejecución en CPU y aceleración por GPU. Eso no convierte una cantidad concreta de memoria en una garantía para cualquier combinación: los requisitos dependen de los modelos y de la configuración.

El objetivo del entrenamiento y la forma de ajustar son cosas distintas

Una forma sencilla de ordenar los términos es plantear dos preguntas: ¿qué queremos que aprenda el modelo y qué parámetros vamos a ajustar para ello?

En el preentrenamiento, el modelo aprende patrones a partir de grandes conjuntos de datos. Ese aprendizaje también puede continuar desde un modelo existente, con material elegido para un dominio. En el ajuste supervisado, o SFT, los ejemplos orientan el comportamiento deseado: el modelo recibe situaciones y respuestas utilizadas como referencias de entrenamiento.

Otro objetivo es aprender preferencias entre respuestas posibles. Puede implicar evaluaciones humanas, señales automáticas o combinaciones, según el método. No todo entrenamiento por preferencias es aprendizaje por refuerzo: existen enfoques que utilizan esas comparaciones directamente.

Dónde entra el aprendizaje por refuerzo

En el aprendizaje por refuerzo, el entrenamiento utiliza una señal de recompensa para orientar el comportamiento del modelo. La recompensa representa un criterio elegido para la tarea; no es una prueba automática de que la respuesta sea correcta.

RLHF significa aprendizaje por refuerzo con retroalimentación humana. En un enfoque habitual, las personas evalúan respuestas y esas evaluaciones ayudan a construir un modelo de recompensa, que orienta el ajuste del modelo que responde. Es una manera de convertir preferencias en una señal de entrenamiento.

Eso no significa que alguien deba aprobar manualmente cada respuesta una vez que el sistema esté en uso. Tampoco garantiza una alineación perfecta: la señal puede representar mal lo que se pretendía y favorecer comportamientos que parecen buenos en la evaluación, pero fallan en situaciones reales.

El fine-tuning puede usar adapters, y adapter no es sinónimo de LoRA

Fine-tuning es el ajuste de un modelo ya entrenado. Puede actualizar todos los parámetros de la base o utilizar estrategias que ajustan solo una parte de ellos o parámetros adicionales. Esa elección es distinta del objetivo del entrenamiento: seguir ejemplos o aprender preferencias, por ejemplo.

Un adapter es un mecanismo de adaptación asociado al modelo. Según el método, puede añadir componentes entrenables o representar ajustes que trabajan junto a la base, manteniendo congelados sus pesos originales. La forma exacta depende del método y de la implementación.

LoRA es un tipo de adapter en este sentido amplio: representa actualizaciones mediante matrices entrenables más pequeñas. El término adapter no significa exclusivamente LoRA. Hay otras formas de adaptación, y el nombre utilizado en el proyecto debe indicar cuál está en juego.

Un adapter tampoco es, por sí solo, el modelo completo. Depende de una base compatible. Por eso, una colección de adapters no debe confundirse automáticamente con una familia de modelos completos ni con una receta única de especialización.

Ajustar para el ámbito es otra etapa posible

Cuando el objetivo requiere adaptación con datos específicos, herramientas como Axolotl ayudan a organizar el entrenamiento. La configuración describe elementos como el modelo, los datos y la estrategia de ajuste, lo que permite registrar el proceso y seguir sus resultados.

Eso no vuelve obligatorio el ajuste después de cada merge. Tampoco convierte fine-tuning y familia de modelos en lo mismo. Uno es una forma de adaptar; la otra es la organización de modelos con propósitos definidos. El camino de construcción de cada integrante depende del proyecto.

Elegir datos adecuados sigue siendo una parte central del trabajo. Una herramienta de entrenamiento organiza la ejecución; no decide por sí sola qué representa una buena respuesta para el dominio.

Evaluar antes de presentarlo como especialista

Cada candidato debe compararse con una referencia: el modelo de partida, otra alternativa adecuada o ambos. Los ejemplos de evaluación deben permitir observar el comportamiento en situaciones que no se hayan repetido simplemente durante la preparación.

Lo que se mide depende de la función. Puede ser la corrección de los campos extraídos, el respeto al formato, la fidelidad a una referencia o la cantidad de revisión necesaria. Cuando hay variación, una sola ejecución no basta para representar el rendimiento.

También es importante registrar las pérdidas. Un modelo puede mejorar en un ámbito y empeorar en otro. La especialización no implica reducción automática de tamaño, eliminación de errores ni superioridad garantizada.

De la colección a la familia

El resultado que se busca es un conjunto con funciones claras, versiones identificables y criterios para decidir cuándo está listo cada modelo para su uso. Si esos modelos se ofrecen por API, quienes los integran necesitan comprender la función de cada uno y los límites de la entrega.

Esa es la dirección de la familia de modelos especializados de Kuaapy. En nuestra propuesta, el trabajo de fine-tuning de la fase 3 y la construcción de la familia en la fase 4 tienen alcances distintos. Adaptar un modelo para una necesidad y desarrollar una familia con funciones propias son entregas diferentes.

Para conocer esta dirección y conversar sobre una necesidad específica, visita el área de Servicios de Kuaapy.

Para seguir leyendo

El punto de partida es reutilizar conocimiento existente. Lo que transforma esa reutilización en una familia con propósito es definir funciones, construir candidatos y comprobar lo que entrega realmente cada uno.