Ajuste Fino de LLMs en Producción: Del Conjunto de Datos al Servicio

Ajuste Fino de LLMs en Producción: Del Conjunto de Datos al Servicio

Tienes un modelo Claude o GPT que acierta el 85% de las veces para tu caso de uso. El 15% restante te cuesta correcciones manuales, hinchazón de la ventana de contexto o llamadas a la API que no deberías necesitar. El ajuste fino parece ser la respuesta. Entonces te das cuenta de que no hay un camino sencillo desde «tengo datos etiquetados» hasta «mi modelo funciona mejor».

El ajuste fino no es optimización de prompts. No es RAG (Retrieval Augmented Generation). Son pesos que cambian a través del descenso de gradiente en tu dominio específico. Cuando funciona, obtienes inferencia más rápida, ventanas de contexto más pequeñas y modelos que realmente siguen tu formato. Cuando falla —y falla a menudo—, has desperdiciado semanas en etiquetado de datos y cómputo sin nada que mostrar.

He construido sistemas de ajuste fino en producción en AlgoVesta. También he visto a equipos gastar 40.000 dólares en tiempo de GPU para producir un modelo peor que el base. La diferencia no es inteligencia. Es proceso.

Esta guía cubre el viaje completo: cuándo tiene sentido el ajuste fino, cómo preparar datos que realmente mejoren el rendimiento, elegir entre modelos de código abierto y servicios gestionados, configuración del entrenamiento, evaluación y patrones de despliegue que no fallan en producción.

Cuándo el Ajuste Fino Resuelve el Problema (y Cuándo No)

El ajuste fino es un martillo pesado. Antes de usarlo, entiende qué arregla y qué no.

El ajuste fino realmente ayuda con:

• Terminología y redacción específicas del dominio. Si necesitas que el modelo use consistentemente tu vocabulario, responda en tu tono o siga un formato específico el 95% de las veces, el ajuste fino funciona. GPT-3.5 ajustado con tickets de soporte al cliente aprende el lenguaje de tu empresa.
• Reducción de los requisitos de la ventana de contexto. Si estás pasando 8K tokens de contexto para que el modelo recuerde «responde siempre en JSON», un modelo ajustado internaliza esa regla en sus pesos. Tu contexto promedio se reduce a 2K.
• Patrones de razonamiento específicos de la tarea. Los modelos ajustados con análisis financiero etiquetado, generación de código con patrones de tu base de código o extracción estructurada de texto desordenado aprenden estos patrones más rápido y de manera más confiable que la ingeniería de prompts sola.
• Reducción de la latencia y el costo de inferencia. Un modelo ajustado más pequeño (Llama 3 8B en lugar de GPT-4o) puede superar a modelos base más grandes en tu tarea específica. La inferencia se vuelve 10 veces más barata.

El ajuste fino NO soluciona:

• Lagunas fundamentales de razonamiento. Si el modelo base no puede hacer matemáticas paso a paso, el ajuste fino no creará esa capacidad. Estás ajustando pesos, no añadiendo nuevas capacidades.
• Alucinaciones por contexto faltante. El ajuste fino hace que los modelos imiten mejor los patrones, no que sepan lo que no saben. RAG lo soluciona. El ajuste fino no.
• Conocimiento desactualizado. Un modelo entrenado con datos de 2023 no sabrá de repente eventos de 2025 porque lo ajustes. Necesitas recuperación o reentrenamiento continuo.
• Tipos de tareas que el modelo base nunca vio. Un modelo entrenado principalmente en texto no se convertirá en programador con ajuste fino de datos financieros. La arquitectura no ha cambiado.

Empieza aquí: ¿Puede un prompt de 3 frases con ejemplos resolver tu problema? Usa eso primero. ¿Tu caso de uso requiere adherencia consistente al formato, lenguaje de dominio o reducción del tamaño de la ventana de contexto? Vale la pena explorar el ajuste fino. ¿El modelo base fundamentalmente no entiende tu tarea? Invierte en RAG o en un modelo diferente, no en ajuste fino.

Preparación de Datos: El Verdadero Trabajo

Aquí es donde la mayoría de los proyectos de ajuste fino fallan silenciosamente.

Reúnes 500 ejemplos etiquetados. Se ven bien en una hoja de cálculo. Entrenas. Obtienes una mejora del 2%. Culpa al modelo. En realidad, tu conjunto de datos le enseñó ruido al modelo.

Esto es lo que realmente importa:

Tamaño y composición del conjunto de datos. El recuento de tokens importa más que el recuento de ejemplos. La documentación pública de ajuste fino de Anthropic (a marzo de 2025) recomienda un mínimo de 10.000 tokens para un ajuste fino significativo, aunque 100.000+ tokens muestran una señal más clara. Eso son aproximadamente 20-50 ejemplos bien etiquetados si cada uno tiene 2.000 tokens, o 500+ ejemplos si cada uno tiene 200 tokens.

La distribución de tus ejemplos da forma a lo que aprende el modelo. Si el 80% de tus ejemplos son casos extremos y el 20% son operaciones normales, el modelo ajustado se convierte en un especialista en casos extremos. Equilibra tu conjunto de datos para reflejar la distribución de producción.

Calidad sobre cantidad. Cinco ejemplos que representan perfectamente el comportamiento deseado superan a cincuenta ejemplos mediocres. Cada ejemplo debe mostrar al modelo exactamente cómo se ve el éxito: salida correcta, formato correcto, tono correcto.

Aquí tienes un escenario concreto de AlgoVesta: Ajustamos Claude 3 Haiku en análisis financiero estructurado. Enfoque incorrecto: 300 ejemplos de «el analista escribió un informe, muéstrame las métricas clave». Enfoque correcto: 60 ejemplos cuidadosamente seleccionados que mostraban exactamente el esquema JSON que necesitábamos, con salidas que cumplían al 100% los requisitos de producción.

Estructura de pares entrada/salida. Cada ejemplo de entrenamiento es un par prompt-completado. El prompt debe ser realista, exactamente cómo tu sistema de producción llamará al modelo. La completación debe ser exactamente lo que quieres de vuelta.

Par de entrenamiento incorrecto:

{
  "prompt": "Analiza estos datos",
  "completion": "Aquí tienes el análisis..."
}

Par de entrenamiento correcto:

{
  "prompt": "Analiza los siguientes datos de ingresos trimestrales y extrae el margen de beneficio, el crecimiento interanual y el EBITDA. Devuelve como JSON.

Ingresos T3 2024: 2.1M $
Costos: 1.4M $
Año anterior T3: 1.9M $",
  "completion": "{\"profit_margin\": 33.3, \"yoy_growth\": 10.5, \"ebitda\": 0.7}"
}

El primero enseña generalidades. El segundo enseña tu tarea específica.

Evitar fugas y contaminación de datos. Si tus datos de entrenamiento contienen ejemplos de tu conjunto de prueba, ya has perdido. Divide antes de etiquetar: 70% entrenamiento, 15% validación, 15% prueba reservada. Etiqueta solo el conjunto de entrenamiento. Evalúa solo en la prueba.

También verifica duplicados o ejemplos casi duplicados. Si tienes la misma entrada expresada de tres maneras con salidas idénticas, el modelo sobrepondera ese patrón. La deduplicación antes del entrenamiento evita esto.

Pipeline de datos práctico:

1. Obtén datos brutos de producción (consultas reales de usuarios, salidas reales)
2. Muestra 200-500 ejemplos representativos en proporción a la distribución de producción
3. Divide: 70 entrenamiento / 15 validación / 15 prueba inmediatamente
4. Etiqueta solo el conjunto de entrenamiento con las salidas deseadas exactas
5. Almacena como JSONL (un objeto JSON por línea) en el formato que espera tu proveedor de ajuste fino
6. Ejecuta una validación rápida: muestra 10 ejemplos de entrenamiento y 10 de prueba; verifica manualmente que no haya solapamiento

Esto lleva una semana para la mayoría de los equipos. Es la diferencia entre un modelo ajustado que funciona y uno que desperdicia cómputo.

Elección de Modelo y Enfoque de Entrenamiento

Tienes tres caminos. Cada uno tiene diferentes compensaciones.

Opción 1: Servicios de ajuste fino gestionados (Claude, GPT-4, Cohere).

Subes tu conjunto de datos. Ellos manejan la infraestructura, los bucles de entrenamiento y el servicio. La API de ajuste fino de Anthropic (lanzada a principios de 2025) cuesta aproximadamente 3 dólares por 1M de tokens de datos de entrenamiento más el precio por token de inferencia del modelo ajustado. El ajuste fino de OpenAI para GPT-4o cuesta 25 dólares por 1M de tokens de entrenamiento.

Pros: Sin gestión de infraestructura. Calidad consistente. Métricas de evaluación incorporadas. Fácil de iterar.

Contras: Bloqueado en los modelos de ese proveedor. Mayor costo por inferencia. Control limitado sobre los hiperparámetros de entrenamiento. Menos adecuado si necesitas privacidad extrema (los datos van a sus servidores).

Cuándo usar esto: Quieres la mejor precisión con la mínima complejidad operativa y no eres sensible al costo de la inferencia. El ajuste fino de Claude es sólido para tareas intensivas en razonamiento; el ajuste fino de GPT-4o para tareas en las que GPT-4o ya es fuerte.

Opción 2: Modelos de código abierto con tu propia infraestructura (Llama 3, Mistral, etc.).

Alquilas una GPU (A100 en Lambda Labs o RunPod: 1-2 dólares por hora), descargas el modelo base, ejecutas un script de ajuste fino y despliegas los pesos.

Pros: Control total. Puedes optimizar para tu hardware exacto y necesidades de latencia. Costo de entrenamiento único, luego inferencia barata. Ningún dato sale de tu infraestructura.

Contras: Eres responsable de todas las decisiones de infraestructura. Requiere algo de conocimiento de ML ops. Los modelos más pequeños pueden no alcanzar el rendimiento de GPT-4o en tareas complejas. El entrenamiento requiere una cuidadosa sintonización de hiperparámetros.

Cuándo usar esto: Tienes tareas de complejidad estándar (clasificación, extracción, generación simple), requisitos de privacidad y quieres minimizar los costos a largo plazo.

Esto es lo que realmente funciona: Mistral 7B ajustado en tareas de extracción a menudo iguala la precisión de Claude 3 Haiku con 1/10 del costo de inferencia. Llama 3 8B ajustado en soporte al cliente puede manejar el 80% de los tickets para los que un modelo base necesita GPT-4o.

Opción 3: Enfoque híbrido (usar servicio gestionado inicialmente, luego pasar a código abierto).

Ajusta en Claude o GPT-4 para establecer la verdad fundamental de la calidad. Luego usa las salidas de ese modelo ajustado como datos sintéticos para ajustar un modelo de código abierto más barato. Es un pipeline de dos etapas.

Esto funciona porque el modelo caro enseña patrones al modelo barato. Llama 3 8B entrenado con salidas de Claude ajustado aprende a imitar el razonamiento de Claude a una fracción del costo.

Compensación: Tarda más en implementarse, pero los costos de inferencia a largo plazo se reducen en más del 80%.

Matriz de selección de modelos:

Entrenamiento: Configuración, Hiperparámetros y Depuración

Tienes tus datos. Has elegido tu camino. Ahora el entrenamiento real.

Uso de la API de ajuste fino de Claude (enfoque gestionado):

import anthropic

client = anthropic.Anthropic(api_key="tu-clave-api")

# Tus datos de entrenamiento como JSONL
with open("training_data.jsonl", "r") as f:
    training_data = f.read()

# Crear trabajo de ajuste fino
response = client.beta.messages.fine_tuning.jobs.create(
    model="claude-3-5-sonnet-20241022",
    training_data=training_data,
    learning_rate=1.0,  # Predeterminado de Anthropic
)

job_id = response.id
print(f"Trabajo de ajuste fino iniciado: {job_id}")

Verificar estado:

job_status = client.beta.messages.fine_tuning.jobs.retrieve(job_id)
print(job_status.status)  # training, completed, failed

Eso es todo para los servicios gestionados. Anthropic se encarga de la tasa de aprendizaje, el tamaño del lote, las épocas. Tú proporcionas los datos y esperas.

Uso de modelos de código abierto (enfoque autoalojado):

Usarás herramientas como Hugging Face Transformers con un script de ajuste fino. Aquí tienes un ejemplo realista usando Mistral 7B:

from transformers import AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments
from datasets import load_dataset
import torch

# Cargar modelo y tokenizador
model_name = "mistralai/Mistral-7B-v0.1"
model = AutoModelForCausalLM.from_pretrained(model_name, torch_dtype=torch.bfloat16, device_map="auto")
tokenizer = AutoTokenizer.from_pretrained(model_name)
tokenizer.pad_token = tokenizer.eos_token

# Cargar tus datos de entrenamiento JSONL
dataset = load_dataset("json", data_files="training_data.jsonl")["train"]

# Función de tokenización
def tokenize_function(examples):
    prompt_completion = [p + c for p, c in zip(examples["prompt"], examples["completion"])]
    return tokenizer(prompt_completion, truncation=True, max_length=2048)

tokenized_dataset = dataset.map(tokenize_function, batched=True)

# Argumentos de entrenamiento
training_args = TrainingArguments(
    output_dir="./mistral-finetuned",
    num_train_epochs=3,
    per_device_train_batch_size=4,  # Ajustar según memoria GPU
    learning_rate=2e-4,
    warmup_steps=100,
    weight_decay=0.01,
    logging_steps=50,
    save_steps=500,
    eval_strategy="steps",
    eval_steps=500,
    load_best_model_at_end=True,
)

# Entrenar
trainer = Trainer(
    model=model,
    args=training_args,
    train_dataset=tokenized_dataset,
)

trainer.train()

Hiperparámetros clave y qué hacen realmente:

• Tasa de aprendizaje (2e-4 a 5e-4 para Llama/Mistral). Demasiado alta: el modelo diverge y produce basura. Demasiado baja: apenas mejora. Empieza en 2e-4, monitoriza la pérdida, ajusta. Modelos más pequeños (7B) usan tasas de aprendizaje más bajas que los más grandes.
• Número de épocas (típicamente 3–5). Más épocas = más aprendizaje pero mayor riesgo de sobreajuste. Si tienes <1000 ejemplos, 5 épocas es seguro. Si tienes 10.000+ ejemplos, 3 épocas suele ser suficiente.
• Tamaño del lote (4–16 según memoria GPU). Lotes más grandes son más estables pero requieren más VRAM. Las GPUs A100 pueden manejar 16; las RTX 4090 de 24GB necesitan 4–8. Empieza conservadoramente, aumenta si el entrenamiento es estable.
• Pasos de calentamiento (50–200). Número de pasos donde la tasa de aprendizaje aumenta gradualmente. Evita inestabilidad temprana en el entrenamiento. 100 funciona para la mayoría de los conjuntos de datos.

Depuración de entrenamiento fallido:

¿Tu pérdida deja de mejorar o aumenta después de una época? Revisa: ¿Tu conjunto de validación tenía un formato diferente al de entrenamiento? ¿Incluiste accidentalmente tu conjunto de prueba en el entrenamiento? ¿Tu tasa de aprendizaje es demasiado alta (la pérdida explota) o demasiado baja (la pérdida se aplana inmediatamente)?

Ejecuta una pequeña verificación de cordura primero: ajusta solo 100 ejemplos. Si eso no mejora la precisión en esos ejemplos, algo está mal con tu configuración o datos, no con el modelo. Depura antes de escalar al conjunto de datos completo.

Evaluación: Midiendo lo que Realmente Importa

Terminaste de entrenar. Tu curva de pérdida se ve suave. No importa si el modelo no funciona con datos reales.

Configura la evaluación antes de entrenar. Reserva el 15% de tus datos como conjunto de prueba. Nunca muestres esto al modelo durante el entrenamiento. Después de entrenar, evalúa contra este conjunto de prueba.

Usa métricas específicas de la tarea, no solo la pérdida.

Si tu tarea es clasificación («¿es urgente este ticket de soporte?»), usa precisión, recall, F1 y exactitud. La pérdida no te dice nada sobre si el modelo clasifica correctamente.

Si tu tarea es extracción («extrae el número de factura y el monto»), compara los campos extraídos contra el estándar de oro usando coincidencia exacta y coincidencia aproximada (90%+ de similitud). Un solo error tipográfico en la extracción numérica falla los sistemas posteriores.

Si tu tarea es generación («escribe un resumen»), compara contra resúmenes de referencia usando ROUGE o BLEU, pero también revisa manualmente 20 salidas. Las métricas pueden mentir. La evaluación humana detecta las mentiras.

Compara con la línea base. La precisión del modelo ajustado no es significativa por sí sola. Necesitas una línea base: ¿Qué hace el modelo original? ¿Qué logra la ingeniería de prompts? ¿Qué hace un sistema más simple basado en reglas?

Si tu Mistral ajustado obtiene un 82% de precisión y el Mistral base obtiene un 76%, es una mejora real. Si el ajustado obtiene un 82% y el GPT-4o con ingeniería de prompts ya obtiene un 88%, no has justificado la complejidad.

De mi trabajo en AlgoVesta: Ajustamos Claude 3 Haiku para la clasificación de señales comerciales. Precisión ajustada: 91%. Haiku base con prompting de 3 disparos: 87%. Mejora: 4%. ¿Valieron la pena 200 ejemplos etiquetados? Sí, porque ejecutamos 10.000 llamadas de inferencia diarias. Una mejora del 4% = 400 errores menos por día. Recuperación de 3-4 meses del costo de etiquetado.

Flujo de trabajo de evaluación práctico:

1. Después de que el entrenamiento se complete, ejecuta inferencia en tu conjunto de prueba reservado del 15%
2. Calcula métricas específicas de la tarea (precisión/recall para clasificación, coincidencia exacta para extracción, ROUGE para generación)
3. Ejecuta el mismo conjunto de prueba a través del modelo base y obtén métricas de línea base
4. Revisa manualmente 20 ejemplos de prueba lado a lado: base vs. ajustado. Anota dónde mejora el ajustado y dónde falla
5. Calcula el ROI: (ganancia de precisión × volumen diario de inferencia × costo por error) vs (costo de entrenamiento + infraestructura)

Si el ROI es negativo, probablemente sobreajustaste o la calidad de tus datos fue pobre. Considera la aumentación de datos o un modelo base diferente.

Despliegue: Poner Modelos Ajustados en Producción

Tienes un modelo ajustado que funciona. Ahora necesita servir solicitudes reales.

Despliegue de servicio gestionado (ajuste fino de Claude, GPT-4):

Trivial. Tu modelo ajustado tiene un ID. Llámarlo como una API normal:

import anthropic

client = anthropic.Anthropic()

# Usa el ID del modelo ajustado devuelto por el entrenamiento
response = client.messages.create(
    model="claude-3-5-sonnet-20241022::ft_4b64e5d8-1234-5678",  # Tu ID ajustado
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Analiza este informe trimestral..."}
    ]
)

print(response.content[0].text)

Hecho. Sin infraestructura. Anthropic se encarga del escalado, caché, balanceo de carga.

Despliegue de modelo autoalojado:

Más control, más responsabilidad. Necesitas:

1. Servidor de inferencia. Usa vLLM (código abierto, optimizado para LLMs) o TorchServe. vLLM es más rápido.
2. Contenerización. Imagen Docker con tus pesos de modelo ajustado
3. Plataforma de despliegue. Kubernetes, Modal o VM simple
4. Monitorización. Rastrea latencia, rendimiento, utilización de GPU

Aquí tienes una configuración mínima de vLLM:

# requirements.txt
vllm==0.5.0
torch==2.2.0
transformers==4.40.0

# inference.py
from vllm import LLM, SamplingParams

llm = LLM(model="./mistral-finetuned", dtype="bfloat16", max_num_seqs=32)
sampling_params = SamplingParams(temperature=0.7, top_p=0.95, max_tokens=512)

prompt = "Analiza esta factura: [detalles]..."
outputs = llm.generate(prompt, sampling_params)
print(outputs[0].outputs[0].text)

vLLM maneja el batching, la memoria de GPU y el servicio de manera eficiente. Una máquina con una A100 maneja cientos de llamadas de inferencia por minuto para un modelo de 8B.

Cuantización para menor latencia/costo:

Si necesitas latencia inferior a 100 ms o ejecutar en GPUs más pequeñas, cuantiza tus pesos ajustados. La cuantización de 8 bits (usando bitsandbytes) reduce la memoria en un 75% con una pérdida mínima de precisión. La cuantización de 4 bits (GPTQ o AWQ) reduce la memoria al 25% del original.

# Cuantizar después del ajuste fino
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model = AutoModelForCausalLM.from_pretrained("./mistral-finetuned")
quantized_model = model.quantize(quantization_config=bitsandbytes.Int8Config())
quantized_model.save_pretrained("./mistral-finetuned-int8")

Compensación: La cuantización cuesta 1-3% de precisión. Vale la pena si necesitas latencia inferior a 50 ms o ejecutas en hardware de consumo.

Cuándo Falla el Ajuste Fino: Modos de Falla Comunes y Soluciones

Entrenaste un modelo. Es peor que el modelo base. ¿Por qué?

Modo de fallo 1: Sobreajuste en los datos de entrenamiento.

Síntoma: Precisión de entrenamiento 95%, precisión de prueba 62%. El modelo memorizó ejemplos de entrenamiento pero no generaliza.

Causa: Demasiadas épocas, muy pocos ejemplos, o el conjunto de validación es demasiado similar al conjunto de entrenamiento.

Solución: Reduce las épocas a 2, recopila más ejemplos diversos o usa un conjunto de validación que represente verdaderamente datos no vistos.

Modo de fallo 2: Mala calidad de datos envenenando el entrenamiento.

Síntoma: El modelo produce salidas de menor calidad que el modelo base. Precisión 5-10% menos.

Causa: Los datos de entrenamiento tienen errores, inconsistencias o ejemplos que se contradicen entre sí.

Solución: Audita manualmente 50 ejemplos de entrenamiento. Busca:
– Pares contradictorios (misma entrada, salidas diferentes)
– Errores tipográficos o gramaticales en las salidas
– Ejemplos que no coinciden con la distribución de producción
Limpia los datos antes de reentrenar.

Modo de fallo 3: Olvido catastrófico.

Síntoma: El modelo es bueno en tu tarea específica, terrible en la comprensión general del lenguaje. Rechaza solicitudes simples fuera de tu dominio.

Causa: Ajuste fino demasiado fuerte en una tarea estrecha. Las habilidades generales del modelo base se sobrescriben.

Solución: Mezcla 10-20% de ejemplos de propósito general en tu conjunto de entrenamiento (preguntas y respuestas simples, matemáticas, codificación). Evita que el modelo pierda sus capacidades base.

Modo de fallo 4: Desajuste de tarea entre entrenamiento e inferencia.

Síntoma: El modelo se entrenó en extracción pero lo usas para generación. O se entrenó en JSON estructurado pero los prompts de inferencia son conversacionales.

Causa: Tus prompts de entrenamiento no coinciden con cómo llamarás realmente al modelo en producción.

Solución: Asegúrate de que la estructura del prompt de cada ejemplo de entrenamiento coincida exactamente con cómo el código de producción llama al modelo. Prueba de extremo a extremo antes de entrenar.

Análisis Costo-Beneficio: ¿Realmente Deberías Hacer un Ajuste Fino?

El ajuste fino no es la opción por defecto. Es una elección con compensaciones reales.

Ajuste fino gestionado (Claude, GPT-4):

• Costo de entrenamiento: 100-500 dólares (para 100.000 tokens de datos)
• Costo de inferencia: 50%-200% más sobre el modelo base (depende del modelo)
• Costo de infraestructura: 0 dólares
• Tiempo hasta producción: 1-2 semanas (preparación de datos + entrenamiento)

Ajuste fino autoalojado (Llama, Mistral):

• Costo de entrenamiento: 50-300 dólares (alquiler de GPU por 1-5 horas)
• Costo de inferencia: 0.01-0.10 dólares por 1.000 tokens (tu propio hardware)
• Costo de infraestructura: 50-500 dólares/mes para servicio (o un pago único de 5.000 dólares por hardware)
• Tiempo hasta producción: 4-6 semanas (preparación de datos + entrenamiento + configuración de infraestructura)

Cuándo el ROI del ajuste fino es positivo:

• Tu caso de uso requiere >100 llamadas de inferencia diarias Y puedes mejorar la precisión en un 3%+ con datos de dominio
• Tienes requisitos estrictos de latencia (<100 ms) que los modelos base no pueden cumplir
• Tu volumen justifica la complejidad operativa del autoalojamiento
• Tienes fuertes necesidades de privacidad/regulatorias que requieren modelos on-premise

Cuándo el ROI del ajuste fino es negativo:

• Tu tarea funciona con ingeniería de prompts estándar y tienes <10 llamadas diarias
• La precisión es secundaria a la velocidad de comercialización
• Tu equipo carece de experiencia en operaciones de ML (autoalojado) y no puede soportar la complejidad
• El modelo base ya es fuerte para tu tarea (>90% de precisión) y tu necesidad de precisión es modesta

Prueba antes de comprometerte: Elige tus 50 mejores ejemplos de entrenamiento. Ajusta Claude 3 Haiku solo con esos 50. ¿La precisión mejora significativamente? Si no, no tienes suficiente señal en tus datos. No escales.

Haz Esto Hoy: Tu Primer Prueba de Concepto de Ajuste Fino

Deja de leer y empieza a construir. Aquí tienes tus próximas 48 horas:

1. Hora 1-2: Elige una tarea repetitiva. No un «sería bueno tener». Una tarea que tu equipo realiza >50 veces al mes y donde la consistencia del formato importa. (Ejemplos: extraer campos de documentos, clasificar tickets de soporte, formatear salidas a un esquema).
2. Hora 3-12: Reúne 30 ejemplos. Realiza esa tarea con tu método actual (ingeniería de prompts, trabajo manual, lo que sea). Captura la entrada y la salida correcta. Ese es tu conjunto de datos inicial.
3. Hora 13-24: Prepara los datos y crea un trabajo de ajuste fino gestionado. Formatea tus 30 ejemplos como JSONL. Usa la API de ajuste fino de Claude para entrenar con ellos (cuesta 5-10 dólares). Espera a que termine el entrenamiento (generalmente 1-2 horas).
4. Hora 25-48: Evalúa. Ejecuta tu modelo ajustado contra 10 ejemplos que reservaste. Compara con el modelo base. ¿Mejoró la precisión? Si es así, itera reuniendo 50 ejemplos más y reentrenando. Si no, la calidad de tus datos es el problema: audita los ejemplos y corrígelos.

Eso es todo. Sabrás en 48 horas si el ajuste fino vale la pena para tu caso de uso. La mayoría de los equipos descubren después de esta PoC que la ingeniería de prompts es suficiente. Algunos descubren una mejora del 10-15% en la precisión que justifica la siguiente fase. Ambas son señales valiosas.