
Cuantos Ejemplos de Entrenamiento Realmente Necesitas? El Mito de las 100 Muestras
Los requisitos reales de datos para el fine-tuning de modelos de AI. La investigacion muestra que 50-500 ejemplos pueden ser suficientes para muchas tareas. Esto es lo que dicen los papers y como construir tu dataset.
"Me encantaria hacer fine-tuning de un modelo, pero no tengo suficientes datos."
Esta es la razon mas comun por la que los desarrolladores nunca comienzan. Y para la mayoria de los casos de uso, es incorrecta.
La suposicion de que el fine-tuning requiere millones de ejemplos etiquetados viene de una era anterior del machine learning, antes de que existieran los modelos de lenguaje grandes. Los LLMs pre-entrenados ya conocen lenguaje, gramatica, patrones de razonamiento y una enorme cantidad de conocimiento de dominio. No estas ensenando a un modelo a entender texto desde cero. Lo estas empujando hacia un estilo, vocabulario o patron de tarea especifico. Ese es un trabajo mucho mas pequeno, y requiere muchos menos datos de lo que la gente espera.
Esto es lo que la investigacion realmente muestra.
Lo Que Dice la Investigacion
Los articulos mas importantes sobre fine-tuning eficiente en datos apuntan todos en la misma direccion: la calidad supera a la cantidad, y el umbral para "suficiente" es menor de lo que la intuicion sugiere.
La Propia Recomendacion de OpenAI: Comienza con 50-100 Ejemplos
La documentacion de fine-tuning de OpenAI recomienda comenzar con 50 a 100 ejemplos para el fine-tuning de GPT-3.5 y GPT-4o. No como un minimo para apenas salir del paso, sino como un punto de partida genuino que produce mejoras medibles. La documentacion explicitamente nota que mas ejemplos pueden ayudar, pero las primeras docenas de ejemplos tipicamente entregan las mayores ganancias.
Si una empresa que cobra por token de inferencia recomienda comenzar con 50 ejemplos, esa es una senal significativa sobre donde realmente se ubica el umbral de datos.
Stanford Alpaca: 52K Ejemplos Sinteticos por $500
El proyecto Stanford Alpaca (arXiv:2303.16199) demostro a principios de 2023 que un modelo ajustado de 7B parametros podia igualar el rendimiento de GPT-3.5 en muchas tareas. El dataset total fue de 52,000 ejemplos de seguimiento de instrucciones generados sinteticamente usando GPT-3.5, a un costo de aproximadamente $500. El hallazgo clave no fue el numero de 52K en si. Fue la prueba de concepto: datos sinteticos generados por un modelo capaz podian entrenar un modelo mas pequeno para un rendimiento casi equivalente en seguimiento de instrucciones.
Ese benchmark desde entonces ha sido sustancialmente mejorado.
QLoRA: 9,000 Ejemplos, 97.8% de ChatGPT
El paper de QLoRA (arXiv:2305.14314, NeurIPS 2023) introdujo el fine-tuning LoRA cuantizado en 4 bits, haciendo accesible el fine-tuning de modelos grandes en hardware de consumidor. Como demostracion, los autores entrenaron un modelo llamado Guanaco usando solo 9,000 ejemplos del dataset OASST1, una coleccion de conversaciones reales de asistentes humanos.
El resultado: Guanaco alcanzo el 97.8% del rendimiento de ChatGPT en el benchmark Vicuna, evaluado por calificadores humanos. En una sola GPU de consumidor. Con 9,000 ejemplos de entrenamiento.
Este no es un caso limite seleccionado a conveniencia. El dataset OASST1 cubre una amplia gama de tareas conversacionales, y 9K ejemplos es modesto por cualquier medida. La arquitectura QLoRA es lo que lo hizo funcionar: el fine-tuning basado en adaptadores preserva el conocimiento general del modelo base mientras aprende el nuevo comportamiento de ejemplos limitados.
LIMA: 1,000 Ejemplos para AI Conversacional
El paper de LIMA (arXiv:2305.11206) de Meta AI puede ser el resultado mas sorprendente en este espacio. Los investigadores hicieron fine-tuning de un modelo de 65 mil millones de parametros con exactamente 1,000 ejemplos de entrenamiento cuidadosamente seleccionados. Sin RLHF, sin modelado de recompensas, sin datos de preferencias. Solo 1,000 conversaciones bien elegidas.
El resultado produjo un modelo que evaluadores humanos prefirieron sobre las respuestas de GPT-4 en el 19% de las comparaciones y consideraron equivalente en muchas otras. El argumento central del paper ahora se conoce como la "hipotesis de alineacion superficial": casi todo el conocimiento que un modelo necesita ya esta presente en los pesos pre-entrenados. El fine-tuning principalmente ensena al modelo el formato y estilo de las salidas deseadas.
La palabra clave en el resultado de LIMA es "cuidadosamente." Los investigadores dedicaron un esfuerzo significativo a curar esos 1,000 ejemplos para asegurar diversidad, cobertura y calidad. Mil ejemplos aleatorios no producirian el mismo resultado.
Microsoft Phi-3: Calidad de Libro de Texto Sobre Volumen
La familia de modelos Phi-3 (arXiv:2404.14219, Microsoft Research) llevo esto mas lejos. Los modelos Phi-3, algunos tan pequenos como 3.8 mil millones de parametros, logran rendimiento competitivo con modelos de tres a cinco veces su tamano. La estrategia de entrenamiento priorizo deliberadamente lo que los investigadores llamaron datos de "calidad de libro de texto": contenido claro, bien estructurado y educativamente denso sobre volumen crudo.
La leccion para practicantes del fine-tuning: la senal en tus datos importa mas que el tamano de tu dataset. Un ejemplo que demuestra claramente el comportamiento objetivo una vez vale mas que diez ejemplos ambiguos.
Requisitos de Datos por Tipo de Tarea
No todas las tareas de fine-tuning son iguales. Un modelo aprendiendo a reformatear salidas en una estructura JSON consistente necesita muchos menos ejemplos que un modelo aprendiendo a razonar a traves de analisis financiero de multiples pasos. Aqui hay un desglose practico basado en hallazgos de la comunidad, benchmarks de papers y la guia publicada de OpenAI:
| Tipo de Tarea | Minimo | Punto Optimo |
|---|---|---|
| Adaptacion de formato y estilo | 50-100 | 200-500 |
| Clasificacion | 100-500 | 500-2K |
| Preguntas y respuestas de dominio | 200-1K | 1K-5K |
| Razonamiento complejo | 1K-5K | 5K-20K |
Algunas notas sobre como leer esta tabla:
Adaptacion de formato y estilo cubre casos como: "siempre responde en esta estructura JSON", "usa este vocabulario especifico", "coincide con este tono." El modelo base ya sabe como producir salida estructurada. Le estas ensenando una preferencia, no una habilidad. Cincuenta ejemplos bien elegidos pueden lograr esto de forma confiable.
Clasificacion varia significativamente segun el numero de clases y su similitud. El analisis de sentimiento binario con 100 ejemplos es alcanzable. Una taxonomia de productos de 50 clases necesita mas datos, especialmente para categorias raras.
Preguntas y respuestas de dominio se beneficia de la diversidad sobre el volumen. Cien ejemplos de diez sub-temas diferentes tipicamente superaran a 100 ejemplos todos extraidos del mismo sub-tema estrecho.
Razonamiento complejo es donde el hambre de datos genuinamente aumenta. Ensenar a un modelo a razonar a traves de un analisis legal de multiples pasos o una decision clinica involucra patrones de razonamiento genuinamente nuevos, no solo adaptacion estilistica. Planifica para mas datos aqui.
Calidad Sobre Cantidad: Que Hace un Buen Ejemplo de Entrenamiento
El hallazgo de LIMA y el enfoque de Phi-3 comparten un hilo comun: los investigadores fueron selectivos. No volcaron datos al entrenamiento. Los curaron.
Un ejemplo de entrenamiento de alta calidad tiene cuatro propiedades:
Demuestra el comportamiento objetivo claramente. No deberia haber ambiguedad sobre como se ve una respuesta correcta. Si estas entrenando un bot de soporte, la respuesta de ejemplo deberia ser la calidad exacta de respuesta que quieres que los usuarios reciban, no un borrador.
Representa una distribucion de entrada real. Los ejemplos deben reflejar los tipos de entradas que tus usuarios realmente envian. Entrenar con ejemplos cuidadosamente construidos que no coinciden con el comportamiento real del usuario produce un modelo que se desempena bien en tu conjunto de entrenamiento y mal en trafico en vivo.
Cubre los casos limite. Aqui es donde la mayoria de la recoleccion de datos falla. Los equipos recopilan 200 ejemplos de los casos faciles y comunes y cero ejemplos de las entradas inusuales que componen el 20% del trafico en produccion. Tus datos deben incluir intencionalmente los casos dificiles.
Es consistente con tus otros ejemplos. Ejemplos de entrenamiento contradictorios, donde el modelo ve entradas similares con diferentes salidas esperadas, confunden el fine-tuning y degradan el rendimiento. Antes de entrenar, revisa tus datos para consistencia interna.
Construyendo Tu Dataset de lo que Ya Tienes
La barrera para comenzar usualmente no es que los datos no existan. Es que los datos no estan formateados. Aqui estan las fuentes mas comunes en desarrollo de apps y como convertirlas en ejemplos de entrenamiento.
Logs de App e Historial de Conversaciones
Si tu app ya tiene una funcion de AI respaldada por una API de modelo fundacional, tienes datos de entrenamiento. Tus conversaciones en produccion son un registro directo de lo que tus usuarios preguntan y como se ven las buenas respuestas.
El flujo de trabajo:
- Exporta los ultimos 30-90 dias de conversaciones.
- Filtra por interacciones de alta calidad. Si tienes retroalimentacion de pulgar arriba/pulgar abajo, usala. Si no, muestrea y revisa manualmente.
- Elimina cualquier informacion de identificacion personal. Aplica la anonimizacion que tu politica de privacidad requiera.
- Convierte a tu formato de entrenamiento (tipicamente JSONL con arrays de
messages).
Incluso 200-300 conversaciones de alta calidad del trafico en produccion produciran un modelo ajustado mejor que 1,000 ejemplos creados a mano que no coinciden con patrones de uso real.
Tickets de Soporte y Datos de Mesa de Ayuda
Los tickets de soporte al cliente son datos de entrenamiento extraordinariamente valiosos para casos de uso de automatizacion de soporte. Contienen:
- Lenguaje real del usuario, incluyendo errores ortograficos y frases inusuales
- Un registro de como se ve la resolucion correcta
- Volumen que escala con tu base de usuarios
El proceso de conversion: extrae el ticket inicial mas la respuesta final del agente que cerro el ticket. Descarta tickets donde la resolucion requirio juicio humano que no deberia automatizarse. Limpia las respuestas del agente para eliminar notas internas o numeros de caso. Ahora tienes pares de seguimiento de instrucciones que representan directamente tu tarea.
Retroalimentacion y Correcciones de Usuarios
Si tu app tiene algun mecanismo para que los usuarios senalen malas salidas o soliciten correcciones, esa retroalimentacion es oro de entrenamiento. Un usuario que dice "esta respuesta es incorrecta, la respuesta correcta es X" te ha dado un ejemplo etiquetado de exactamente donde tu modelo falla y como se ve el comportamiento correcto.
Incluso un volumen pequeno de datos de correccion es de alta senal. Cincuenta ejemplos de fallos del modelo con etiquetas correctas mejoraran un modelo ajustado de forma medible.
Documentacion Interna y Bases de Conocimiento
Para casos de uso de preguntas y respuestas de dominio, tu documentacion de producto, base de conocimiento interna y contenido de FAQ se pueden convertir en ejemplos de entrenamiento. El proceso:
- Toma una seccion de documentacion.
- Genera preguntas plausibles de usuario sobre ese contenido (manualmente o con otro LLM).
- Escribe respuestas de calidad de modelo basadas en la documentacion.
- Revisa la precision y consistencia.
Esto es mas lento pero produce ejemplos confiables con respuestas correctas verificadas.
Datos Sinteticos: El Enfoque Stanford Alpaca
Si no tienes suficientes datos existentes, puedes generarlos. El enfoque Stanford Alpaca demostro que esto funciona a escala, y la economia ha mejorado significativamente desde 2023.
El metodo basico:
- Escribe 20-30 ejemplos semilla que demuestren tu tarea objetivo. Estos deben ser los mejores ejemplos que puedas producir.
- Da un prompt a un modelo capaz (GPT-4o, Claude Opus, etc.) con tus ejemplos semilla y pidele que genere variaciones diversas.
- Revisa los ejemplos generados por calidad. Espera descartar un 10-20%.
- Usa los ejemplos sinteticos aprobados como datos de entrenamiento.
El costo por 500-1,000 ejemplos sinteticos usando precios actuales de modelos de frontera es tipicamente $50-200, dependiendo de la longitud de salida y el numero de pasadas de revision de calidad. Para la mayoria de las tareas, esto es menor al costo de unas pocas horas de recoleccion manual de datos.
Una advertencia importante: los datos sinteticos generados por un modelo cerrado (como GPT-4o o Claude) no se pueden usar para entrenar modelos competidores de proposito general segun los terminos de servicio de la mayoria de los proveedores. Para fine-tuning especifico de tarea con alcance estrecho para tu propia aplicacion, esta restriccion generalmente no aplica, pero revisa los terminos aplicables antes de proceder.
El Enfoque Iterativo: Comienza Pequeno
El mayor error en la recoleccion de datos para fine-tuning es esperar hasta tener "suficientes" datos antes de comenzar. El enfoque correcto es comenzar con lo que tienes, entrenar, evaluar y aprender.
Aqui esta la progresion recomendada:
Comienza con 100 ejemplos. Entrena un adaptador LoRA en tu modelo base. Evalua en un conjunto de prueba reservado de 20-30 ejemplos. Nota donde falla el modelo.
Identifica los modos de fallo. El modelo se equivoca en el formato? Falla en ciertas areas tematicas? Rechaza entradas que deberia responder? Cada modo de fallo te dice exactamente que tipo de datos de entrenamiento adicionales recolectar.
Agrega ejemplos dirigidos. Recolecta 50-100 ejemplos que aborden especificamente los modos de fallo que identificaste. Reentrena.
Repite. En la mayoria de los casos, tres a cuatro iteraciones te llevan a un modelo de calidad de produccion. En la mayoria de los casos, el dataset final es menor a 1,000 ejemplos.
Este enfoque iterativo funciona porque dirige tus esfuerzos de recoleccion de datos a las brechas reales en el comportamiento de tu modelo en lugar de recolectar datos uniformemente a traves del espacio de entrada. No estas construyendo un dataset que cubra todas las entradas posibles. Estas construyendo un dataset que cubra las entradas que tus usuarios realmente envian y arreglando los casos donde tu modelo actualmente se equivoca.
La Conclusion
Casi seguramente tienes suficientes datos para comenzar. Tal vez tienes 200 resoluciones de tickets de soporte en una hoja de calculo. Tienes una base de conocimiento de producto. Tienes unas pocas semanas de logs de conversaciones en produccion. Puedes generar 500 ejemplos sinteticos por menos de $100.
La investigacion es inequivoca: 50 ejemplos pueden mejorar la consistencia de estilo. 100 ejemplos pueden cambiar significativamente el comportamiento de un modelo. 1,000 ejemplos bien curados pueden producir un modelo conversacional que se mantiene firme frente a modelos de frontera en tareas especificas.
Los desarrolladores que nunca comienzan porque estan esperando un dataset mas grande estan esperando un umbral que, para su caso de uso, puede no ser necesario. Los desarrolladores que comienzan con 100 ejemplos, evaluan honestamente e iteran son los que envian a produccion.
Tu dataset es mas pequeno de lo que piensas. Tu modelo esta mas cerca de lo que piensas. Comienza con lo que tienes.
Ship AI that runs on your users' devices.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Keep reading

Fine-Tuning for App Developers: A Non-ML-Engineer's Guide
A practical guide to fine-tuning AI models for mobile app developers. Learn LoRA, QLoRA, and GGUF export without needing an ML background.

Fine-Tuned 3B vs GPT-4: Why Smaller Models Win at Domain Tasks
Academic research shows fine-tuned 3B-7B models consistently beat GPT-4 on domain-specific tasks. Here's the evidence, the pattern, and how to apply it in your app.

Fine-Tuning vs RAG for Mobile: Why RAG Still Needs a Server
RAG is the go-to solution for giving AI domain knowledge. But on mobile, RAG reintroduces the server dependency you are trying to eliminate. Fine-tuning bakes the knowledge into the model itself.