Glosario de Fine-tuning y adaptación de modelos

Los términos que aparecen una y otra vez en el Curso de Fine-tuning y en cualquier conversación sobre adaptar un modelo a datos propios. La idea es que puedas leer un paper, un README de Hugging Face o el config de un compañero sin frenar cada dos líneas. Como todo glosario de la academia, crece con cada bloque nuevo del curso.

La decisión: cuándo entrenar

Fine-tuning (afinado) — seguir entrenando un modelo ya entrenado con datos propios, actualizando sus pesos para que se comporte distinto. No agrega conocimiento nuevo de forma confiable: cambia el comportamiento, el formato y el estilo. Ver módulo 1.

Prompting — pedirle al modelo lo que quieres con instrucciones en texto, sin tocar los pesos. Es el primer peldaño de la escalera y resuelve más casos de los que la gente cree. Cuesta minutos y se cambia en caliente.

Few-shot (pocos ejemplos) — meter 3 a 10 ejemplos resueltos dentro del prompt para que el modelo copie el patrón. Es el segundo peldaño: si funciona con few-shot, el fine-tuning normalmente solo te ahorra tokens, no te da capacidad nueva.

RAG (Retrieval-Augmented Generation) — buscar información en tus documentos y pegarla en el prompt antes de responder. Es la respuesta correcta cuando el problema es conocimiento, no comportamiento. Ver el Curso de RAG.

La escalera — el orden en que hay que probar las soluciones: prompt → few-shot → RAG → fine-tuning → continued pretraining. Cada peldaño cuesta un orden de magnitud más que el anterior y solo se sube cuando el de abajo se agotó de verdad.

System prompt — las instrucciones permanentes que preceden a toda conversación. Un fine-tuning bien hecho suele permitir acortarlo drásticamente, porque el comportamiento queda en los pesos en vez de repetirse en cada llamada.

Destilación (distillation) — usar un modelo grande y caro como maestro para generar los datos con que entrenas un modelo chico y barato (el alumno). Es el caso de uso de fine-tuning con mejor retorno económico. Ver módulo 11.

Continued pretraining (preentrenamiento continuado) — seguir el entrenamiento del modelo base sobre texto crudo de tu dominio, sin formato de pregunta-respuesta. Es lo que sí instala conocimiento y vocabulario nuevos, y cuesta un orden de magnitud más que un SFT. Ver módulo 11.

Entrenamiento supervisado

SFT (Supervised Fine-Tuning) — el entrenamiento supervisado clásico: le muestras pares de entrada y salida ideal, y el modelo aprende a producir la salida. Es la gran mayoría del fine-tuning que se hace en la práctica y el corazón del curso. Ver módulo 6.

Full fine-tuning (afinado completo) — actualizar todos los parámetros del modelo. Da el máximo de capacidad de cambio y cuesta el máximo de VRAM: para un modelo de 7B necesitas del orden de 100 GB. Casi siempre LoRA es suficiente.

PEFT (Parameter-Efficient Fine-Tuning) — la familia de técnicas que entrena solo una fracción minúscula de los parámetros. También es el nombre de la librería de Hugging Face que las implementa. LoRA es su miembro más usado.

Modelo base (base) — el modelo tal como salió del preentrenamiento: completa texto, no conversa. Es el punto de partida para continued pretraining o para enseñar un formato desde cero.

Modelo instruct (instruction-tuned) — el modelo base ya afinado para seguir instrucciones y conversar. Es el punto de partida por defecto para un SFT: parte de un comportamiento razonable en vez de cero. Ver módulo 4.

Época (epoch) — una pasada completa por el dataset de entrenamiento. En fine-tuning el rango sano es de 1 a 3: con más, el modelo empieza a memorizar en vez de generalizar.

Loss (pérdida) — el número que mide qué tan equivocado está el modelo. En un LLM es la sorpresa promedio al predecir el siguiente token: si predijo con confianza el token correcto, la loss es baja. Entrenar es minimizarla. Ver módulo 3.

TRL (Transformer Reinforcement Learning) — la librería de Hugging Face que trae SFTTrainer, DPOTrainer, KTOTrainer y compañía. Es la capa que usas en la práctica para todo lo del curso.

Unsloth — librería que reimplementa los kernels críticos del entrenamiento y consigue entrenar más rápido y con menos VRAM que la ruta estándar, con la misma API. Vale la pena cuando la GPU aprieta. Ver módulo 6.

El dataset

El dataset es el modelo — la tesis central del curso: la calidad del resultado la define el dataset, no los hiperparámetros. Ninguna configuración salva datos malos. Ver módulo 2.

JSONL (JSON Lines) — el formato de facto de los datasets de fine-tuning: un objeto JSON por línea, sin comas ni corchetes envolventes. Se puede leer en streaming y agregar una línea sin releer el archivo.

LIMA (Less Is More for Alignment) — el trabajo que mostró que 1.000 ejemplos bien curados pueden superar a decenas de miles ruidosos. Es el argumento empírico de que la curación gana a la cantidad.

Cosechar de producción — armar el dataset a partir de las interacciones reales que ya tiene tu sistema, en vez de escribirlas desde cero. Es la fuente más barata y la que mejor refleja la distribución real de consultas.

Anonimización — reemplazar datos personales por marcadores antes de entrenar. No es opcional: el modelo puede memorizar y repetir textualmente lo que vio, así que un RUT en el dataset es un RUT que puede salir en una respuesta.

PII (Personally Identifiable Information) — información que identifica a una persona: nombre, RUT, correo, dirección, teléfono. Lo que hay que detectar y sacar del dataset antes de entrenar. Ver módulo 12.

Train / validation / test — el train ajusta los pesos; el validation se mira durante el entrenamiento para decidir cuándo parar; el test se toca una sola vez, al final. Si miras el test muchas veces, deja de ser test.

Holdout — el conjunto apartado que el entrenamiento nunca vio. Es la única superficie donde una mejora medida significa algo.

Fuga entre splits (leakage) — que un ejemplo del test aparezca, igual o casi igual, en el train. Infla las métricas y produce mejoras completamente ficticias. Es el error más común y el más difícil de ver.

p99 — el percentil 99 del largo de los ejemplos en tokens. Es el número que decide tu max_length: si lo pones por debajo, estás truncando el 1% más largo sin darte cuenta.

Formato y loss masking

Chat template (plantilla de conversación) — el formato exacto de tokens especiales con que un modelo espera recibir una conversación. Cada familia usa el suyo y usar el equivocado degrada el resultado en silencio. Ver módulo 3.

ChatML — el chat template popularizado por OpenAI, con marcadores <|im_start|> y <|im_end|> delimitando cada turno. Lo usan muchos modelos abiertos.

apply_chat_template — el método del tokenizador que convierte una lista de mensajes en el string exacto que el modelo espera. Usarlo en vez de armar el string a mano evita la mayoría de los errores de formato.

add_generation_prompt — el flag de apply_chat_template que agrega el encabezado del turno del asistente al final, dejando al modelo listo para completar. Va en True al inferir y en False al entrenar.

BOS / EOS (Beginning / End Of Sequence) — los tokens especiales que marcan el inicio y el fin de una secuencia. El EOS es el que le enseña al modelo a parar: si falta en el dataset, tu modelo entrenado no deja de escribir.

BOS duplicado — el error clásico de aplicar el chat template y además dejar que el tokenizador agregue su propio BOS. El modelo ve dos tokens de inicio, algo que nunca vio en el preentrenamiento, y el entrenamiento se degrada.

Loss masking (enmascarado de la pérdida) — decirle al entrenamiento que ignore ciertos tokens al calcular la loss. En un SFT conversacional sirve para que el modelo aprenda a responder y no a inventar las preguntas del usuario. Ver módulo 3.

-100 / ignore_index — el valor convencional con que se marcan las etiquetas que la función de pérdida debe saltarse. Es literalmente cómo se implementa el loss masking en PyTorch.

Collator (data collator) — la función que junta varios ejemplos en un batch: los rellena al mismo largo y arma las etiquetas. Es donde vive la lógica del enmascarado.

DataCollatorForCompletionOnlyLM — el collator histórico de TRL (eliminado en la versión 0.20, de mediados de 2025) que calculaba la loss solo sobre la respuesta buscando el marcador de inicio de turno. Hoy lo reemplazan assistant_only_loss y completion_only_loss; si lo ves en un tutorial, es código viejo.

response_template / instruction_template — los strings que le indicaban al collator histórico dónde empezaba la respuesta y dónde la instrucción. Con la API actual no hacen falta: la máscara sale de los marcadores {% generation %} del chat template.

assistant_only_loss — el parámetro de SFTConfig que activa el enmascarado automático cuando el dataset viene en formato messages. Es la ruta moderna y evita configurar el collator a mano.

completion_only_loss — el equivalente para datasets en formato prompt/completion: la loss se calcula solo sobre la completación.

Truncación (truncation) — cortar los ejemplos que exceden el largo máximo. Cortar por la izquierda o por la derecha cambia qué se pierde: cortar la respuesta suele ser peor que cortar el contexto.

Packing (empaquetado) — concatenar varios ejemplos cortos hasta llenar la ventana de contexto, para no desperdiciar cómputo en tokens de relleno. Acelera el entrenamiento, pero mezcla ejemplos en la misma secuencia y no siempre conviene.

pad_token (token de relleno) — el token que completa las secuencias cortas hasta el largo del batch. Muchos modelos base no traen uno definido y hay que asignarlo antes de entrenar.

processing_class — el parámetro con que se le pasa el tokenizador al trainer en las versiones actuales de TRL, reemplazando al antiguo tokenizer=. Ver módulo 6.

max_length — el largo máximo de secuencia en tokens que acepta el trainer. En TRL actual reemplaza al viejo max_seq_length.

LoRA y QLoRA

LoRA (Low-Rank Adaptation) — en vez de mover todos los pesos, se congela el modelo y se entrenan dos matrices chicas cuyo producto es la corrección. Entrena menos del 1% de los parámetros con calidad muy cercana al afinado completo. Ver módulo 5.

ΔW = B·A — la ecuación de LoRA: la actualización de una matriz de pesos se aproxima por el producto de dos matrices flacas. A baja la dimensión al rango y B la sube de vuelta.

Rank (r, rango) — el ancho del cuello de botella de LoRA y el parámetro que define su capacidad. Valores típicos: 4 a 8 para formato y tono, 16 a 32 como punto de partida general, 32 a 64 para cambios de comportamiento más profundos.

Intrinsic rank hypothesis — la observación de que la actualización útil de un fine-tuning vive en un subespacio de dimensión baja. Es la razón teórica de por qué LoRA funciona tan bien pese a entrenar tan poco.

lora_alpha (alpha) — el factor de escala del adapter. Lo que llega al modelo es ΔW · (alpha / r), así que alpha regula cuánta influencia tiene lo aprendido. La convención habitual es alpha = 2r.

Scaling (alpha/r) — el multiplicador efectivo del adapter. Entenderlo evita el error de subir el rank y preguntarse por qué el efecto no cambió: si alpha no se movió, el escalado bajó.

use_rslora (rank-stabilized LoRA) — variante que escala por alpha/√r en vez de alpha/r, lo que estabiliza el entrenamiento cuando usas ranks altos. Recomendable a partir de r = 64; con ranks chicos da lo mismo.

lora_dropout — apagado aleatorio de una fracción de las conexiones del adapter durante el entrenamiento, como regularización. Con datasets chicos ayuda a no memorizar.

target_modules — la lista de capas del modelo a las que se les enchufa un adapter. Elegir bien acá mueve más el resultado que casi cualquier otro hiperparámetro de LoRA.

all-linear — el valor de target_modules que aplica LoRA a todas las capas lineales del modelo. Es el default recomendado hoy: cuesta poca VRAM extra y suele rendir mejor que apuntar solo a las de atención.

modules_to_save — capas que se entrenan completas además de los adapters, típicamente los embeddings y la cabeza de salida. Necesario si agregas tokens nuevos al vocabulario.

print_trainable_parameters() — el método de PEFT que reporta cuántos parámetros vas a entrenar y qué porcentaje del total son. Es la verificación de un segundo que confirma que la configuración quedó como creías.

Adapter — el conjunto de matrices LoRA entrenadas, guardado como un archivo de unos pocos MB. Se carga sobre el modelo base y se puede intercambiar sin recargar el modelo.

QLoRA (Quantized LoRA) — LoRA sobre un modelo base cargado en 4 bits. Reduce la VRAM del base a un cuarto y permite entrenar modelos de 7B a 13B en una GPU de consumo. Ver módulo 5.

NF4 (4-bit NormalFloat) — el tipo de dato de 4 bits de QLoRA, con niveles distribuidos según la campana de Gauss que siguen los pesos de una red. Pierde menos calidad que un FP4 uniforme y es el default correcto.

Double quantization (doble cuantización) — cuantizar también las constantes de cuantización. Ahorra del orden de 0,4 bits por parámetro, es gratis en calidad y se activa con un flag.

Paged optimizers (optimizadores paginados) — estados del optimizador que se mueven a la RAM del sistema cuando la VRAM se llena, evitando el OOM en los peaks. Es lo que hace que un entrenamiento al límite termine en vez de morir.

BitsAndBytesConfig — el objeto que configura la carga cuantizada: bits, tipo de dato, doble cuantización y tipo de cómputo. Se pasa a from_pretrained.

prepare_model_for_kbit_training — la función de PEFT que deja un modelo cuantizado listo para entrenar: activa gradient checkpointing, arregla las capas de norma y prepara los tipos. Saltársela produce entrenamientos que no convergen.

Hardware y memoria

VRAM — la memoria de la GPU. Es el recurso que limita todo en fine-tuning y el que define qué modelo puedes entrenar. Ver módulo 2 del Curso de GPU.

Presupuesto de VRAM — la suma de pesos, gradientes, estados del optimizador y activaciones. Calcularlo antes de arrancar evita descubrir el OOM a los veinte minutos. Ver módulo 4.

Estados del optimizador — lo que Adam guarda por cada parámetro entrenable: momento y varianza, en FP32. Son unos 8 bytes por parámetro y suelen ser el componente más pesado de un full fine-tuning.

BF16 (bfloat16) — formato de 16 bits con el mismo rango de exponente que FP32. Es el estándar para entrenar en GPU moderna: la mitad de memoria que FP32 sin los problemas de desbordamiento de FP16.

Gradient checkpointing — no guardar todas las activaciones y recalcular las que falten en la pasada hacia atrás. Recorta la memoria de activaciones de forma importante a cambio de un 20 a 30% más de tiempo.

Gradient accumulation (acumulación de gradiente) — sumar los gradientes de varios micro-batches antes de actualizar los pesos, para simular un batch grande con poca VRAM. Es la palanca principal cuando la memoria aprieta.

Batch efectivo — el batch real que ve el optimizador: batch por dispositivo × acumulación × número de GPUs. Es el número que hay que mantener constante al mover las otras piezas.

Hiperparámetros y curvas

Learning rate (tasa de aprendizaje) — cuánto se mueven los pesos en cada actualización. Es el hiperparámetro que más impacto tiene: con LoRA el rango habitual es 2e-4, con full fine-tuning 1e-5 y con DPO cerca de 5e-6.

Scheduler (planificador) — la regla que va cambiando el learning rate a lo largo del entrenamiento. cosine es el default sano; linear y constant_with_warmup son las otras opciones frecuentes.

Warmup (calentamiento) — arrancar con un learning rate cerca de cero y subirlo gradualmente durante los primeros pasos. Evita que las primeras actualizaciones, con gradientes ruidosos, destrocen el modelo.

weight_decay — penalización que empuja los pesos hacia cero, como regularización. Valores del orden de 0,01 son lo habitual.

max_grad_norm / gradient clipping — recortar el gradiente cuando su norma supera un umbral, típicamente 1,0. Es el seguro contra un batch raro que dispare la loss.

optim — el optimizador a usar. adamw_torch es el estándar; paged_adamw_8bit es la variante que ahorra VRAM y es la compañera natural de QLoRA.

Seed (semilla) — el número que fija la aleatoriedad del entrenamiento: inicialización, orden de los datos, dropout. Sin seed fija no puedes reproducir ni comparar dos corridas.

Overfitting (sobreajuste) — el modelo memoriza el train en vez de aprender el patrón. Se ve en la curva: la loss de entrenamiento sigue bajando y la de validación empieza a subir.

Curva de loss — el gráfico de la pérdida contra los pasos. Su forma dice qué está pasando: divergencia, meseta, sobreajuste o convergencia sana. Ver módulo 7.

EarlyStoppingCallback — el callback que corta el entrenamiento cuando la métrica de validación deja de mejorar durante N evaluaciones seguidas. Ahorra GPU y evita sobreajustar.

Trackio / Weights & Biases / MLflow — herramientas de seguimiento de experimentos: registran hiperparámetros, métricas y artefactos de cada corrida para poder comparar. Ver el Curso de MLOps.

Evaluación

A/B contra el base — comparar el modelo afinado contra el modelo sin afinar sobre el mismo conjunto de casos. Es la única comparación que responde “¿sirvió el fine-tuning?”.

disable_adapter() — el contexto de PEFT que apaga el adapter LoRA y deja el modelo base puro. Permite hacer el A/B en el mismo proceso, con la misma GPU y los mismos datos cargados.

do_sample=False — generar de forma determinista (greedy) durante la evaluación. Si dejas el muestreo activo, la diferencia entre corridas puede ser puro ruido.

% de JSON válido — para modelos que deben responder estructurado, la tasa de salidas que parsean. Es una de las métricas donde el fine-tuning suele dar saltos más grandes.

LLM-as-judge (LLM como juez) — usar un modelo fuerte para puntuar las respuestas cuando no hay respuesta única correcta. Requiere una rúbrica explícita y calibración contra juicio humano.

Comparación pairwise (por pares) — mostrarle al juez dos respuestas, A y B, y pedirle que elija. Es mucho más confiable que pedir una nota absoluta del 1 al 10.

Position bias (sesgo de posición) — la tendencia del juez a preferir la respuesta que ve primero. Se corrige evaluando cada par en los dos órdenes y promediando.

Win rate (tasa de victoria) — el porcentaje de casos en que el modelo afinado le gana al base según el juez. Es el número que se reporta.

Catastrophic forgetting (olvido catastrófico) — el modelo mejora en la tarea entrenada y empeora en todo lo demás: razonamiento general, otros idiomas, seguir instrucciones fuera del dominio. Es el costo oculto del fine-tuning y hay que medirlo explícitamente.

Suite de regresión — un conjunto fijo de casos, incluyendo capacidades generales que no entrenaste, que se corre en cada versión del modelo. Es lo que detecta el olvido catastrófico antes que el usuario.

Golden dataset — el conjunto de casos con respuesta esperada, curado a mano, que sirve de vara de medición estable a lo largo de las versiones.

Preferencias: DPO y compañía

Alineación por preferencias — la etapa posterior al SFT donde el modelo aprende de comparaciones (“esta respuesta es mejor que esta otra”) en vez de ejemplos ideales. Sirve para tono, matices y cosas difíciles de escribir pero fáciles de reconocer. Ver módulo 9.

chosen / rejected (elegida / rechazada) — el par que forma un ejemplo de preferencia: para el mismo prompt, la respuesta buena y la mala. Es todo el formato del dataset de DPO.

DPO (Direct Preference Optimization) — el método que aprende directamente de los pares chosen/rejected sin entrenar un modelo de recompensa ni usar RL. Es lo que reemplazó a RLHF en la práctica por ser mucho más simple.

beta — el hiperparámetro de DPO que regula cuánto puede alejarse el modelo de la referencia. Bajo (0,01–0,05) permite cambios grandes con riesgo de degradar; alto (0,3–0,5) es conservador. El rango habitual es 0,1.

Modelo de referencia (reference model) — la copia congelada del modelo antes de DPO, contra la que se mide cuánto se está desviando. Con LoRA sale gratis: es el mismo modelo con el adapter apagado.

is_trainable=True — el flag al cargar el adapter para DPO que evita que PEFT lo congele. Olvidarlo produce un entrenamiento que corre sin errores y no aprende nada.

Pares on-policy — pares donde la respuesta rechazada la generó tu propio modelo, no otro. Enseñan a corregir los errores que tu modelo comete de verdad, y rinden bastante más que pares genéricos.

Length bias (sesgo de largo) — la tendencia de DPO a alargar las respuestas, porque las preferidas por humanos suelen ser más largas. Hay que vigilarlo: se corrige con datos donde la mejor sea la más corta.

ORPO (Odds Ratio Preference Optimization) — método que combina SFT y preferencias en un solo entrenamiento, partiendo del modelo base y sin modelo de referencia. Ahorra una etapa completa. Ver módulo 11.

KTO (Kahneman-Tversky Optimization) — alineación con etiquetas sueltas de bueno/malo en vez de pares. Encaja perfecto cuando lo que tienes es el pulgar arriba/abajo de tu producto, sin comparaciones.

desirable_weight / undesirable_weight — los pesos de KTO que compensan el desbalance entre ejemplos buenos y malos, que en producción rara vez llegan en la misma proporción.

rewards/margins — la métrica de TRL que mide cuánto separa el modelo la respuesta elegida de la rechazada. Debe subir durante el entrenamiento; si no sube, algo está mal configurado.

rewards/accuracies — la fracción de pares donde el modelo prefiere la respuesta correcta. Un valor sano ronda 0,7 a 0,9; llegar a 1,0 en pocos pasos huele a pares demasiado fáciles o a sobreajuste.

logps/chosen y logps/rejected — las log-probabilidades de cada respuesta. Ambas suelen bajar durante DPO; lo que importa es que la brecha entre ellas se abra.

Servir el modelo

merge_and_unload() — el método de PEFT que fusiona el adapter dentro de los pesos del modelo y devuelve un modelo normal, sin dependencia de LoRA. Es el paso previo a servir con cualquier motor. Ver módulo 10.

W’ = W + B·A·s — la aritmética del merge: la matriz original más el producto del adapter escalado. Después de esto el adapter deja de existir como pieza separada.

Merge sobre 4 bits — el error clásico: fusionar el adapter sobre el modelo cargado en 4 bits. Los errores de cuantización quedan horneados en los pesos y el modelo pierde calidad de forma permanente. Hay que mergear en fp16 o bf16.

GGUF — el formato de llama.cpp y Ollama, un archivo único que empaqueta pesos cuantizados, tokenizador y metadatos. Es la ruta para correr en CPU o en Mac. Ver módulo 6 del Curso de GPU.

AWQ (Activation-aware Weight Quantization) — cuantización a 4 bits que protege los canales de peso más importantes según las activaciones observadas. Rápida en GPU y de las mejores en calidad por bit. Hoy se produce con llm-compressor (AutoAWQ quedó archivada en 2025).

GPTQ — cuantización a 4 bits por capas que minimiza el error de reconstrucción usando datos de calibración. Alternativa madura a AWQ, con amplio soporte en motores de servido.

Datos de calibración — la muestra de texto con que AWQ o GPTQ deciden qué preservar. Usar texto de tu dominio en vez del genérico por defecto mejora notoriamente la calidad del modelo cuantizado.

vLLM — motor de servido de alto rendimiento con batching continuo y PagedAttention. Es el estándar para servir un modelo afinado con tráfico real. Ver módulo 7 del Curso de GPU.

Multi-LoRA — servir un solo modelo base con varios adapters cargados a la vez, eligiendo cuál usar por request. Permite N modelos especializados al costo de VRAM de uno. Ver módulo 10.

—enable-lora / —lora-modules — los flags de vLLM que activan multi-LoRA y declaran los adapters disponibles con su nombre de endpoint.

Hot-swap (intercambio en caliente) — cambiar el adapter activo sin reiniciar el servidor ni recargar el modelo base. Es lo que hace viable tener un modelo por cliente.

KV cache — el caché de claves y valores de la atención que evita recalcular los tokens ya generados. Es lo que hace rápida la inferencia y lo que consume VRAM proporcional al contexto y a la concurrencia.

Técnicas avanzadas

Vocabulary expansion (expansión de vocabulario) — agregar tokens nuevos al tokenizador para representar mejor la jerga o un idioma poco cubierto. Obliga a entrenar también embeddings y cabeza de salida vía modules_to_save. Ver módulo 11.

RAFT (Retrieval-Augmented Fine-Tuning) — entrenar al modelo con contexto recuperado que incluye distractores, para que aprenda a usar lo relevante e ignorar lo que no sirve. Es la técnica que combina RAG y fine-tuning en vez de elegir uno.

Model merging (fusión de modelos) — combinar los pesos de varios modelos afinados en uno solo, sin volver a entrenar. Permite juntar capacidades entrenadas por separado a costo casi cero.

SLERP (Spherical Linear Interpolation) — fusión por interpolación esférica entre dos modelos. Es el método más simple y solo admite dos a la vez.

TIES (TrIm, Elect Sign, merge) — fusión de varios modelos que poda los cambios chicos, resuelve conflictos de signo por votación y promedia el resto. Reduce la interferencia entre modelos.

DARE (Drop And REscale) — descarta aleatoriamente una fracción alta de los cambios y reescala los que quedan. Se combina habitualmente con TIES.

mergekit — la herramienta estándar para hacer model merging: se le describe la receta en YAML y produce el modelo fusionado.

Tool calling (llamada a herramientas) — entrenar al modelo para emitir llamadas a funciones con el formato exacto que tu sistema espera. Es uno de los casos donde el fine-tuning da saltos grandes de confiabilidad.

Constrained decoding (decodificación restringida) — forzar en tiempo de inferencia que la salida cumpla una gramática o un esquema JSON. Es la alternativa determinista al fine-tuning para garantizar formato, y las dos se complementan.

Producción y mantención

El trío — las tres cosas que hay que versionar juntas para que un modelo sea reproducible: dataset, configuración de entrenamiento y pesos resultantes. Con dos de las tres no puedes reconstruir nada. Ver módulo 12.

Manifiesto — el archivo que registra todo lo necesario para reproducir una corrida: hash del dataset, hiperparámetros, revision del modelo base y versiones exactas de las librerías.

revision — el commit específico de un repositorio de Hugging Face. Fijarlo evita que el modelo base cambie bajo tus pies entre dos entrenamientos que creías idénticos.

No determinismo en GPU — dos corridas con la misma seed pueden dar pesos levemente distintos, porque la suma en coma flotante no es asociativa y los kernels eligen su orden. Se puede acotar, pero la reproducibilidad bit a bit no es un objetivo realista.

Gatillo de reentrenamiento — la condición definida de antemano que dispara una nueva versión: caída de métrica, nuevos casos acumulados, cambio de producto o del modelo base. Sin gatillos explícitos el reentrenamiento se hace por corazonada.

Drift (deriva) — el desplazamiento de la distribución real de consultas respecto de la que tenía el dataset. Es la causa silenciosa de que un modelo bueno se vaya degradando. Ver el Curso de MLOps.

Costo por iteración — lo que cuesta de verdad una ronda de fine-tuning. Alrededor del 90% son horas humanas de curación y evaluación; la GPU es la parte barata.

Licencia del modelo base — lo que define si puedes usar tu modelo afinado comercialmente. Apache 2.0 y MIT son permisivas; hay licencias comunitarias con condiciones y otras que prohíben el uso comercial. Ver módulo 4.

Memorización — que el modelo repita textualmente ejemplos del entrenamiento. Es el riesgo de privacidad concreto del fine-tuning y la razón por la que la anonimización va antes de entrenar.

Model card — el documento que acompaña al modelo: para qué sirve, con qué datos se entrenó, cómo se evaluó y cuáles son sus límites conocidos. Es la pieza de gobernanza mínima.

Embeddings y rerankers

Bi-encoder — el modelo de embeddings clásico: codifica query y documento por separado en vectores y compara por similitud. Es rápido porque los documentos se indexan una vez. Ver módulo 13.

Cross-encoder — modelo que recibe query y documento juntos y devuelve un puntaje de relevancia. Mucho más preciso que el bi-encoder y mucho más caro, así que se usa para reordenar un top-k chico.

Reranker (reordenador) — el cross-encoder que reordena los resultados que trajo el retriever. Afinarlo es la mejor relación esfuerzo/resultado de todo el curso: sube MRR y nDCG y no obliga a reindexar.

Par (query, positivo) — la unidad del dataset de embeddings: una consulta y un documento que la responde. Mucho más barato de conseguir que un ejemplo de SFT.

Hard negative (negativo difícil) — un documento que se parece mucho al positivo pero no responde la pregunta. Es el ejemplo que enseña la distinción fina del dominio y el que decide el resultado del entrenamiento.

Minería de negativos — buscar con tu retriever actual y tomar como negativos los documentos que salieron arriba y no eran el correcto. Por construcción, son los que hoy te están confundiendo.

Falso negativo — un documento que sí responde la pregunta pero nadie anotó como relevante. Entrenar con él le enseña al modelo a alejar documentos correctos: es la forma más rápida de empeorar el sistema.

Segunda ronda de minería — volver a minar negativos con el modelo recién entrenado y entrenar otra vez. El modelo nuevo se equivoca en otras cosas, así que hay señal nueva. Suele dar una segunda mejora y aplanarse ahí.

MNRL (MultipleNegativesRankingLoss) — la función de pérdida por defecto para entrenar embeddings: para cada query, su positivo es el correcto y los positivos de las demás queries del batch son los negativos.

In-batch negatives — los negativos que provee el propio batch, gratis, sin tener que anotarlos. Es el mecanismo que hace eficiente a MNRL.

Batch size como calidad — en MNRL, más batch significa más negativos por query (127 con batch 128 contra 7 con batch 8). Acá el batch no es una optimización de velocidad: es un hiperparámetro de calidad.

Triplet loss — la formulación clásica (ancla, positivo, negativo) con margen. Usa un solo negativo por ejemplo, así que rinde menos que MNRL para retrieval de texto; aparece en literatura y código heredado.

sentence-transformers — la librería estándar para entrenar y usar modelos de embeddings. Desde la v3 trae SentenceTransformerTrainer, con la misma forma que el Trainer de transformers.

InformationRetrievalEvaluator — el evaluador de sentence-transformers que mide recall, MRR y nDCG dentro del bucle de entrenamiento. Necesario porque la loss baja bonito sin decirte si el retrieval mejoró.

Prefijos query: / passage: — los marcadores que exigen algunos modelos de embedding (E5, BGE) para distinguir consulta de documento. Tienen que usarse igual al entrenar, al indexar y al consultar: ponerlos en unos sí y otros no es peor que no ponerlos.

Reindexado — recalcular los vectores de todo el corpus. Es obligatorio al cambiar de modelo de embeddings, porque los vectores viejos y los nuevos viven en espacios distintos y no se pueden comparar.

recall@k — la fracción de preguntas donde el documento correcto está entre los primeros k resultados. Es el techo de todo el sistema: el LLM no puede responder con lo que nunca llegó.

MRR (Mean Reciprocal Rank) — mide qué tan arriba salió el primer resultado correcto. Sube con el reranker, no con más recall.

nDCG (normalized Discounted Cumulative Gain) — métrica de orden con relevancia graduada, que premia tener lo más relevante más arriba.

Diagnóstico por síntoma — la herramienta práctica del cierre: recall bajo se arregla con el bi-encoder o el chunking; recall alto con MRR bajo, con el reranker; ambos altos y respuesta mala, con el LLM o el prompt; fallas solo con códigos y SKU, con BM25 y no con fine-tuning.