12.05.26

Modelos Ligeros Fine-Tuned vs Modelos Frontier: Por qué el 84% de Operaciones de MYPES no Requieren GPT-4 ni Grok ni Gemini Ultra

Planteamiento del Problema

Entre febrero y mayo 2026, Odysea Eval ejecutó 312 tareas operacionales reales de 9 MYPES del sur del Perú usando seis arquitecturas de inferencia: tres modelos frontier vía API (GPT-4o, Claude Sonnet 3.5, Gemini 1.5 Pro) y tres modelos ligeros corriendo localmente con Ollama (Llama 3.1 8B, Mistral 7B, Phi-3 Mini 3.8B), estos últimos ajustados mediante fine-tuning sobre documentación interna de cada empresa.

Objetivo: Determinar si modelos ligeros fine-tuned sobre datos de dominio pueden igualar o superar a modelos frontier en tareas operacionales específicas de MYPES, y cuantificar el diferencial de costo.

Hipótesis central: Un modelo de 8B parámetros entrenado con la documentación, procedimientos, catálogos y comunicaciones de una empresa específica superará a modelos de 400B+ parámetros de propósito general en tareas operacionales de esa empresa, porque el conocimiento de dominio es más relevante que la capacidad de razonamiento general para el 80%+ de operaciones cotidianas.

Brecha identificada:

El mercado actual empuja a las MYPES hacia modelos frontier —GPT-4o, los últimos GPT (GPT-4.5/5), Fable 5, Grok, Gemini Ultra— con argumentos de "mayor inteligencia" y "mejores resultados". Lo que nadie cuantifica es cuánta de esa inteligencia general es realmente necesaria para responder consultas sobre el catálogo de una ferretería, generar reportes según el formato estándar de una distribuidora, o atender preguntas frecuentes de clientes de un estudio contable.

Odysea Eval midió exactamente eso.

Diseño Experimental

Hipótesis testeables

H1: Modelos ligeros fine-tuned en dominio específico alcanzarán F1 ≥ 0.82 en tareas operacionales de la empresa cuyos datos se usaron para el ajuste.

H2: Modelos frontier sin fine-tuning tendrán F1 ≤ 0.80 en las mismas tareas por falta de conocimiento específico de la empresa (precios actuales, procedimientos internos, terminología propia).

H3: El diferencial de costo operacional entre modelos locales y frontier superará el 90% en contextos donde el hardware es propiedad de la empresa.

Modelos evaluados

Dataset empresarial

Recopilamos 312 tareas operacionales reales de 9 MYPES del sur del Perú durante enero-febrero 2026:

Ubicación: Arequipa (6 empresas), Cusco (2), Puno (1)

Categorías de tarea:

• Consulta de información específica de empresa (n=142, 46%): Preguntas sobre precios, stock, procedimientos, horarios, políticas. La respuesta correcta requiere conocimiento interno.
• Generación de documentos con formato propio (n=89, 29%): Cotizaciones, reportes, actas, comunicados siguiendo plantillas de la empresa.
• Clasificación y enrutamiento (n=81, 26%): Categorizar consultas de clientes, derivar al área correcta, priorizar tickets.

Ground truth: Respuestas validadas por 2 empleados senior de cada empresa (acuerdo inter-evaluador κ=0.88).

Proceso de fine-tuning

Datos de entrenamiento por empresa (promedio):
• Catálogo de productos/servicios: 340 páginas
• Manual de procedimientos internos: 180 páginas
• Historial de consultas resueltas (Q&A): 1,240 pares
• Plantillas de documentos: 47 formatos
• Comunicaciones con clientes (anonimizadas): 2,800 ejemplos

Total dataset de fine-tuning por empresa: 4,607 documentos / ~2.1M tokens

Proceso técnico:
• Método: QLoRA (Quantized Low-Rank Adaptation)
• Base: Meta Llama 3.1 8B Instruct
• Rank (r): 16 · Alpha: 32 · Dropout: 0.05
• Epochs: 3 · Batch size: 4 · Learning rate: 2e-4
• Quantización: 4-bit (NF4)
• Hardware: NVIDIA RTX 4090 24GB
• Tiempo de entrenamiento: 4.2 horas promedio por empresa

Herramientas:
• Ollama 0.1.32 para serving local
• Unsloth 2025.3 para fine-tuning eficiente
• LangChain 0.2.1 para integración con aplicaciones

Infraestructura de prueba

Hardware on-premise (servidor compartido entre 3 empresas piloto en Arequipa):
• GPU: NVIDIA RTX 4090 24GB VRAM
• CPU: AMD Ryzen 9 7950X (16 cores)
• RAM: 128GB DDR5
• Almacenamiento: 2TB NVMe
• Conectividad: Fibra 300Mbps dedicada
• Costo del servidor: S/. 8,400 (amortización a 36 meses = S/. 233/mes)

Métricas evaluadas

• Precisión (F1-score): Exactitud de respuesta vs ground truth. Evaluación híbrida: GPT-4o como juez automático + validación humana en 30% de muestra (correlación: 0.89).
• Latencia: p50 y p95 de tiempo de respuesta completo (desde query hasta primera palabra de respuesta para streaming, o respuesta completa para comparación directa).
• Costo operacional: Costo por consulta incluyendo API (modelos cloud), electricidad y amortización de hardware (modelos locales).
• Tasa de alucinación de dominio: Afirmaciones sobre la empresa que contradicen datos internos reales (ej: precio incorrecto, procedimiento inexistente).
• Tasa de respuesta "No sé": Porcentaje de consultas respondidas con alguna información útil vs rechazadas por falta de conocimiento.

Resultados Cuantitativos

Tabla 3: Métricas principales (312 tareas totales)

Desglose por tipo de tarea

Análisis de alucinación de dominio

Este es el hallazgo más importante para decisores empresariales.

¿Qué es una alucinación de dominio?
GPT-4o respondiendo "El precio del producto SKU-F847 es S/. 124" cuando el precio real es S/. 89 y ese dato nunca estuvo en su entrenamiento. El modelo no sabe, pero tampoco lo admite.

Ejemplos documentados (empresas anonimizadas):

Implicación operacional: Un chatbot de atención al cliente usando GPT-4o sin contexto adicional informará precios incorrectos en 1 de cada 9 consultas. En una ferretería con 200 consultas/día, eso representa ~22 errores diarios que dañan la confianza del cliente.

Gráfico 1: Trade-off Precisión vs Costo por consulta

Proyección de costos operacionales

Escenario: MYPE con 3,000 consultas/mes

Break-even Llama FT vs GPT-4o: Mes 15
Break-even Llama FT vs Gemini: Mes 23 (Gemini es más competitivo en precio cloud)

Conclusión de costos a largo plazo: Para empresas con >18 meses de horizonte de operación, la infraestructura local fine-tuned es invariablemente más económica.

Análisis e Interpretación

Hallazgo 1: El 84% de tareas operacionales de MYPES son de dominio, no de razonamiento general

Clasificamos las 312 tareas según qué tipo de capacidad requieren:

Las 51 tareas donde frontier gana:

• Análisis legal de contratos no estándar
• Resolución de situaciones de negocio sin precedente
• Síntesis de información de múltiples fuentes externas
• Redacción persuasiva y creativa

Las 261 tareas donde fine-tuned gana:

• Consultas sobre precios, stock, especificaciones (conocimiento interno)
• Generación de documentos según formatos propios
• Respuestas a preguntas frecuentes de clientes
• Clasificación según criterios propios de la empresa
• Aplicación de políticas y procedimientos internos

Implicación práctica: Una MYPE que implementa Fable 5, GPT-5 o cualquier modelo frontier para todas sus operaciones está pagando capacidad de razonamiento de nivel PhD para responder preguntas que cualquier empleado nuevo aprende en su primera semana de trabajo.

Hallazgo 2: El problema no es el tamaño del modelo, es el conocimiento del dominio

La creencia común es que "más parámetros = mejor performance". Nuestros datos muestran que esta relación se invierte cuando el conocimiento de dominio es el factor limitante.

Analogía técnica: GPT-4o con 200B parámetros sabe todo sobre el mundo pero nada sobre tu empresa. Llama 3.1 con 8B parámetros ajustado a tu documentación interna sabe mucho sobre tu empresa y suficiente sobre el mundo.

Para el 84% de tus tareas operacionales, "saber sobre tu empresa" importa más que "saber sobre el mundo".

Evidencia del estudio: Tomamos la misma consulta ("¿Cuáles son las condiciones de crédito para clientes mayoristas?") y la evaluamos en todos los modelos:
• GPT-4o: Generó condiciones comerciales genéricas plausibles pero incorrectas (tasa de interés inventada, plazos no válidos para la empresa)
• Llama FT: Citó exactamente las condiciones del contrato marco vigente, incluyendo el descuento por pronto pago que se aplica en esa empresa específica

El modelo de 8B con contexto correcto supera al de 200B sin él. No porque sea más inteligente. Porque sabe lo que necesita saber.

Hallazgo 3: La latencia local vs cloud depende de la conexión, no del modelo

Hallazgo crítico: Los modelos locales no tienen latencia de red variable. Su latencia de inferencia es constante (4.6s p50 para Llama 8B) independientemente de la conexión a internet.

Implicación para sur del Perú: En contextos con conectividad irregular (Puno, zonas rurales de Cusco, distritos alejados de Arequipa), la arquitectura local no es solo más barata, es más confiable.

Hallazgo 4: El "No sé" rate de modelos fine-tuned es un feature, no un bug

Los modelos fine-tuned tienen un "No sé" rate de 8-12% vs 3-4% de modelos frontier. A primera vista parece peor. No lo es.

Análisis de los casos "No sé" en Llama FT:
• 89% de los casos: Consulta genuinamente fuera del alcance de la documentación interna (requiere decisión humana)
• 11% de los casos: Información que sí existe en documentación pero no fue recuperada eficientemente

Análisis de los casos donde GPT-4o sí respondió (pero Llama dijo "No sé"):
• 67% de esas respuestas de GPT-4o contenían alucinaciones de dominio
• 33% eran respuestas genéricas correctas pero no específicas de la empresa

Conclusión: El modelo fine-tuned sabe cuándo no sabe. GPT-4o no. En operaciones empresariales, un "No sé, consulta con el equipo" es infinitamente mejor que una respuesta incorrecta dicha con confianza.

Variables confusoras identificadas

1. Calidad de datos de fine-tuning
Empresas con documentación bien estructurada (SOPs claros, catálogos actualizados, Q&A históricas) mostraron F1 de 0.91 en sus modelos fine-tuned. Empresas con documentación caótica o desactualizada obtuvieron F1 de 0.79.

Regla de oro Odysea Eval: El fine-tuning amplifica la calidad de tu documentación. Si tu documentación es mala, el modelo será malo. Garbage in, garbage out se aplica aquí más que en ningún otro contexto.

2. Frecuencia de actualización de información
Modelos fine-tuned requieren re-entrenamiento cuando la información cambia significativamente (nuevos precios, nuevos productos, nuevos procedimientos). Medimos:
• Re-entrenamiento completo (3 epochs): 4.2 horas, S/. 12 en electricidad
• Fine-tuning incremental (delta de cambios): 1.1 horas, S/. 3 en electricidad

Frecuencia de cambio promedio en empresas estudiadas: Cada 6-8 semanas.

Alternativa: Combinar Llama FT (conocimiento base estable) con RAG (información cambiante). Evaluaremos esta arquitectura híbrida en Q3 2026.

3. Complejidad del hardware
El modelo local requiere alguien que sepa administrar el servidor. En las 9 empresas del estudio, ninguna tenía equipo IT interno. Odysea Eval proveyó soporte técnico remoto (~2 horas/mes de mantenimiento). Esto debe considerarse en el cálculo real de costos.

Limitaciones del Estudio

Lo que NO evaluamos

1. Tareas que requieren conocimiento del mundo actualizado
Si una MYPE necesita que su IA responda preguntas sobre noticias recientes, regulaciones nuevas, o información del mercado en tiempo real, un modelo fine-tuned sin RAG no es suficiente. No evaluamos arquitecturas híbridas (fine-tuning + RAG), que son el próximo paso natural de esta investigación.

2. Escala >10,000 consultas/mes
A alto volumen, los costos de hardware y el throughput del modelo local se vuelven cuellos de botella. No evaluamos escenarios con múltiples usuarios simultáneos (>20 requests concurrentes).

3. Tareas multimodales
Solo evaluamos texto. Modelos como GPT-4o tienen ventaja en tareas que combinan imágenes y texto (ej: verificar visualmente una factura escaneada).

4. Modelos frontier con fine-tuning
OpenAI ofrece fine-tuning de GPT-3.5 y GPT-4o. No evaluamos si frontier fine-tuned podría competir con modelos ligeros fine-tuned. Hipótesis: mayor costo sin ventaja de performance en dominio específico.

5. Seguridad y datos sensibles
Operar on-premise tiene ventajas de privacidad que no cuantificamos. Datos empresariales sensibles nunca salen del servidor local. Este es un beneficio real no capturado en nuestras métricas.

Generalización limitada

Aplica directamente a:
• MYPES 10-200 empleados con documentación interna >200 páginas
• Tareas de conocimiento de dominio (consultas, reportes, clasificación)
• Volúmenes de 500-10,000 consultas/mes
• Contextos donde conectividad es variable o costos cloud son limitantes

Requiere validación adicional si:
• Empresa actualiza información >1 vez por semana (fine-tuning frecuente puede no ser práctico)
• Tareas requieren razonamiento complejo multi-paso (frontier mantiene ventaja)
• Empresa no puede invertir en hardware inicial (ROI de largo plazo no aplica)
• Industria regulada donde el modelo debe ser auditado (complejidad de compliance con modelos propios)

Conclusiones Odysea Eval

Hallazgo principal

Para el 84% de operaciones cotidianas de MYPES del sur del Perú, Llama 3.1 8B fine-tuned supera a GPT-4o en precisión de dominio (F1: 0.86 vs 0.79) con 97% menos costo operacional (S/. 0.021 vs S/. 0.32 por consulta).

El argumento de "usa el modelo más inteligente" es correcto cuando la tarea requiere inteligencia general. Es incorrecto cuando la tarea requiere conocimiento específico. La mayoría de tareas operacionales de MYPES son del segundo tipo.

Y el mercado empuja cada vez más fuerte: cada nueva versión (GPT-5, Fable 5, Gemini Ultra, Grok) promete más capacidad que la anterior. Pero para el 84% de operaciones de una MYPE, esa capacidad adicional es irrelevante: el dato correcto de tu propia empresa vale más que todo el conocimiento general del mundo.

Matriz de decisión

Recomendación técnica para MYPES (500-3,000 consultas/mes)

Arquitectura recomendada: Llama 3.1 8B Fine-Tuned + Ollama

Hardware mínimo viable:
• GPU: NVIDIA RTX 3090 (24GB VRAM) — S/. 3,800 segunda mano
• CPU: AMD Ryzen 7 7700X — S/. 1,200
• RAM: 64GB DDR5 — S/. 480
• SSD: 1TB NVMe — S/. 180
• Total hardware: S/. 5,660

Opción compartida (recomendada para MYPES):
• Compartir servidor entre 3-5 empresas: S/. 1,130-1,887 por empresa

Fine-tuning inicial:
• Preparación de datos: 8-12 horas consultor
• Entrenamiento: 4.2 horas (automático)
• Validación: 4 horas con equipo empresa

Costo setup completo con Odysea Technologies: S/. 3,800-6,200
Costo operacional mensual: S/. 180-320
Break-even vs GPT-4o (3K consultas/mes): Mes 14-18

Próximos experimentos Odysea Eval (Q3-Q4 2026)

1. Llama FT + RAG híbrido para información cambiante (inicio: julio 2026)
Hipótesis: Combinar fine-tuning (conocimiento base) con RAG (info actualizada) reduce necesidad de re-entrenamiento frecuente manteniendo F1 >0.85
Dataset: Empresas retail con actualizaciones de precios semanales

2. Quantización INT4 vs INT8 en RTX 3090 (inicio: agosto 2026)
Hipótesis: Quantización INT4 reduce VRAM en 40% (permite correr Llama 13B) con degradación de F1 <3%
Objetivo: Ampliar capacidad sin cambio de hardware

3. Benchmark multi-empresa con modelo compartido (inicio: septiembre 2026)
Hipótesis: Un solo modelo fine-tuned sobre datos de 3 empresas del mismo sector puede ser más eficiente que 3 modelos separados
Desafío: Aislar conocimiento de empresa sin filtración cross-empresa

4. Evaluación de Gemma 3 9B como alternativa (inicio: octubre 2026)
Google Gemma 3 muestra mejoras en español peruano vs Llama 3.1
Evaluaremos si supera a Llama FT en datasets de dominio en español con terminología andina

Reproducibilidad

Código base

from unsloth import FastLanguageModel
from trl import SFTTrainer
from transformers import TrainingArguments

# Cargar modelo base
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="meta-llama/Meta-Llama-3.1-8B-Instruct",
    max_seq_length=4096,
    dtype=None,
    load_in_4bit=True,
)

# Configurar LoRA
model = FastLanguageModel.get_peft_model(
    model,
    r=16,
    target_modules=["q_proj", "k_proj", "v_proj",
                    "o_proj", "gate_proj", "up_proj", "down_proj"],
    lora_alpha=32,
    lora_dropout=0.05,
    bias="none",
    use_gradient_checkpointing="unsloth",
)

# Entrenar
trainer = SFTTrainer(
    model=model,
    tokenizer=tokenizer,
    train_dataset=dataset,
    dataset_text_field="text",
    max_seq_length=4096,
    args=TrainingArguments(
        per_device_train_batch_size=4,
        gradient_accumulation_steps=4,
        num_train_epochs=3,
        learning_rate=2e-4,
        output_dir="outputs/empresa_model",
    ),
)
trainer.train()

# Exportar para Ollama
model.save_pretrained_gguf(
    "empresa_model_gguf",
    tokenizer,
    quantization_method="q4_k_m"
)
  

Servir con Ollama:

# 1. Crear Modelfile
cat > Modelfile << 'EOF'
FROM ./empresa_model_gguf/model.gguf

SYSTEM """
Eres el asistente especializado de [NOMBRE EMPRESA].
Responde ÚNICAMENTE basándote en el conocimiento de la empresa.
Si no sabes la respuesta, di exactamente: "No tengo información sobre eso.
Por favor consulta con nuestro equipo."
"""
EOF

# 2. Crear modelo en Ollama
ollama create empresa-assistant -f Modelfile

# 3. Servir
ollama serve
# Disponible en localhost:11434
  

Condiciones que invalidan estos resultados:
• Modelos base posteriores a Llama 3.1 (Meta actualiza cada 6-8 meses)
• Empresas con <200 páginas de documentación (insuficiente para fine-tuning efectivo)
• Tareas que requieren conocimiento post-training del modelo (regulaciones nuevas, eventos recientes)
• Conectividad LAN inestable (modelo local en servidor requiere red interna confiable)

Última actualización: 12 de mayo, 2026 · Revisión: v1.0
Contacto investigación: eval@odysea.tech
Citación sugerida: Ramos, D., Vargas, K., & Quispe, R. (2026). "Modelos Ligeros Fine-Tuned vs Modelos Frontier: Evaluación de Viabilidad en 312 Tareas Operacionales de MYPES Peruanas". Odysea Eval Technical Report OE-2026-09. Arequipa, Perú.
Repositorio: https://github.com/Odysea-Technologies/Modelos-Ligeros-Fine-Tuned-vs-Frontier-Odysea-Eval

Odysea Eval es el centro de investigación aplicada de Odysea Technologies, dedicado a validación empírica de soluciones de IA para el contexto empresarial peruano. Operamos desde Arequipa con colaboraciones en Cusco, Puno y Lima. Este estudio fue ejecutado sin financiamiento de proveedores de modelos evaluados. Las 9 MYPES participantes contribuyeron datos anonimizados bajo acuerdo de confidencialidad. Los hallazgos son representativos de empresas de 10-150 empleados en sectores retail, distribución, manufactura y servicios profesionales.