01-01-2026

Fine-Tuning vs RAG: Estudio comparativo de precisión, costo y latencia en 247 pruebas empresariales

Planteamiento del problema

Entre enero y marzo 2025, en Odysea Tech recibimos 47 consultas de MYPES peruanas preguntando la misma variante: "¿Necesitamos fine-tuning o es suficiente con RAG?" Las respuestas genéricas abundan online, pero carecen de datos empíricos en contextos empresariales reales con restricciones presupuestarias típicas del sur del Perú.

Problema técnico específico: Las empresas necesitan sistemas de IA que respondan preguntas sobre documentación interna (manuales de producto, políticas, procedimientos) con tres restricciones simultáneas:

• Presupuesto limitado (S/. 800-2,500/mes para inferencia)
• Latencia aceptable (<2s respuesta percibida)
• Precisión factual >85% (margen de error empresarial tolerable)

‍Fallo de soluciones actuales:

• Proveedores internacionales recomiendan fine-tuning sin considerar costos iniciales (USD $200-800 por entrenamiento)
• Implementaciones RAG locales reportan latencias >5s por mala configuración de vectorización
• Ausencia de benchmarks en español con documentación técnica empresarial

‍Brecha que investigamos:

¿Bajo qué condiciones cuantificables cada aproximación es óptima para MYPES peruanas con corpus documentales de 50-5,000 páginas?

Diseño Experimental

Hipótesis principal

H1: RAG superará a fine-tuning en precisión factual para corpus documentales <2,000 páginas debido a acceso directo a fuente, pero con penalización de latencia >200ms.

‍H2: Fine-tuning mostrará ventaja en tareas de formato/estilo específico con latencia inferior, pero degradación de precisión factual vs conocimiento actualizado.

Configuración del experimento

Modelos Evaluados

Configuración	Modelo base	Método	Especificaciones
FT-GPT3.5	gpt-3.5-turbo-1106	Fine-tuning	2,847 Q&A · 3 epochs · LR 0.02
FT-GPT4	gpt-4-0613	Fine-tuning	2,847 Q&A · 2 epochs · LR 0.01
RAG-Basic	gpt-3.5-turbo-0125	RAG + ChromaDB	embedding-small · top-k=3
RAG-Advanced	gpt-4-turbo-2024-04-09	RAG + Pinecone	embedding-large · top-k=5 · rerank
Baseline	gpt-3.5-turbo-0125	Vanilla	Sin contexto (control)

Dataset Empresarial

Construimos un corpus representativo de documentación empresarial real de 8 MYPES del sur del Perú:

Origen: Manufactura (2), retail (3), servicios profesionales (2), logística (1)
Ubicación: Arequipa (5), Cusco (2), Puno (1)
‍
Tamaño corpus:
‍
    • Promedio: 847 páginas/empresa (σ=412)
    • Rango: 284-2,103 páginas
    • Formato: 73% PDF, 21% DOCX, 6% TXT
‍
Idioma: 100% español peruano con terminología técnica sectorial

Generación de consultas de evaluación:

• 247 preguntas reales extraídas de tickets de soporte interno de las 8 empresas
‍
Categorización:
‍
• Factual directa: 112 preguntas (ej: "¿Cuál es el plazo de garantía del producto X?")
• Inferencia: 78 preguntas (ej: "¿Qué hacer si el proveedor incumple la cláusula 4.2?")
• Formato específico: 57 preguntas (ej: "Redacta un memo siguiendo el template corporativo")

‍Ground truth: Respuestas validadas por 3 expertos de cada empresa (acuerdo inter-evaluador κ=0.89)

Infraestructura técnica

Software:

• Embeddings: OpenAI text-embedding-3-small/large
• Vector DBs: ChromaDB 0.4.22 (local), Pinecone serverless
• Framework: LangChain 0.1.9, Python 3.11
• API: OpenAI Python SDK 1.12.0

Conexión:

• Proveedor: Fibra óptica dedicada 1000Mbps
• Latencia promedio a api.openai.com: 118ms (medida en 10,000 pings durante 30 días)
• Uptime: 99.4% durante periodo de pruebas

Métricas evaluadas

1. Precisión Métrica (Métrica primaria)

• Definición: F1-score calculado sobre exactitud factual de la respuesta vs ground truth
• Justificación: Balance entre recall (capturar información correcta) y precision (evitar alucinaciones)
• Cálculo: Evaluadores humanos + GPT-4 como juez (correlación con humanos: 0.87)

2. Latencia

• p50 (mediana): Experiencia de usuario típica
• p95: Casos extremos que afectan percepción de lentitud
• p99: Outliers para debugging
• Justificación: En interfaces empresariales, latencia >2s causa abandono según nuestros A/B tests previos

3. Costo Operacional

• Costo por consulta (S/.): Incluye inferencia + embeddings + almacenamiento prorrateado
• Costo setup (S/.): Inversión inicial (fine-tuning training, indexación vectorial)
• Costo mensual proyectado: Asumiendo 5,000 consultas/mes (promedio MYPE mediana según nuestros clientes)
• Justificación: ROI es decisor crítico para MYPES con presupuestos ajustados

4. Métricas Secundarias

• Tasa de alucinación (afirmaciones no soportadas por corpus)
• Cobertura de respuesta (% de preguntas respondidas vs "no sé")
• Estabilidad (desviación estándar entre 5 ejecuciones de misma pregunta)

Baseline de comparación

Sistema control: GPT-3.5-turbo vanilla sin acceso a documentación empresarial

• Propósito: Cuantificar valor agregado real de fine-tuning y RAG vs modelo base
• Expectativa: Precisión <0.30 en preguntas específicas de empresa (el modelo no puede saber procedimientos internos)

Resultados cuantitativos

Tabla 1: Métricas Principales

Configuración	Precisión (F1)	Latencia p50	Latencia p95	Costo / consulta	Costo setup
Baseline	0.23 (±0.08)	890ms	1,340ms	S/. 0.014	S/. 0
FT-GPT3.5	0.71 (±0.11)	980ms	1,520ms	S/. 0.039	S/. 1,247
FT-GPT4	0.76 (±0.09)	1,840ms	2,910ms	S/. 0.284	S/. 3,680
RAG-Basic	0.84 (±0.07)	1,420ms	2,180ms	S/. 0.048	S/. 87
RAG-Advanced	0.89 (±0.05)	2,240ms	3,560ms	S/. 0.312	S/. 124

Intervalos de confianza: 95% calculados mediante bootstrap (1,000 iteraciones)

Desglose por tipo de consulta: Tabla 2: F1-score segmentado

Tipo de consulta	Baseline	FT-GPT3.5	FT-GPT4	RAG-Basic	RAG-Advanced
Factual directa (n=112)	0.19	0.68	0.73	0.91	0.94
Inferencia (n=78)	0.24	0.71	0.77	0.81	0.86
Formato específico (n=57)	0.31	0.91	0.89	0.79	0.82

Intervalos de confianza: 95% calculados mediante bootstrap (1,000 iteraciones)

Hallazgo: RAG domina en recuperación factual (+26% vs mejor fine-tuning), pero fine-tuning supera en replicación de formatos corporativos (+13% vs RAG-Advanced).

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

Precisión (F1-score)

0.90

0.85

0.80

0.75

0.70

0.25

S/.0.01

S/.0.10

S/.0.30

Costo por consulta

Baseline

FT-GPT3.5

FT-GPT4

RAG-Basic

RAG-Adv

Zona óptima MYPES: F1 > 0.80, Costo < S/.0.10
→ Solo RAG-Basic cumple ambos criterios

Análisis de latencia detallado:

Tabla 3: Distribución de latencia (milisegundos)

Configuración	p50	p75	p90	p95	p99	Max
FT-GPT3.5	980	1,180	1,380	1,520	1,940	2,870
RAG-Basic	1,420	1,680	1,940	2,180	2,690	3,450

Desglose de latencia RAG - Basic (promedio):

• Generación de embedding consulta: 140ms
• Búsqueda vectorial (ChromaDB): 87ms
• Recuperación documentos: 124ms
• Inferencia LLM con contexto: 1,069ms

• Total: 1,420ms

Optimización identificada: 65% del tiempo es inferencia LLM. Cambiar a gpt-3.5-turbo-0125 vs gpt-4 reduciría latencia p95 en ~800ms manteniendo F1 >0.84.

Costos operacionales proyectados

Tabla 4: Escenario de 5000 consultas/mes

Concepto	FT-GPT3.5	RAG-Basic	Delta
Inferencia	S/. 195	S/. 240	+23%
Embeddings	S/. 0	S/. 18	—
Vector DB	S/. 0	S/. 12	—
Mensual	S/. 195	S/. 270	+38%
Setup inicial	S/. 1,247	S/. 87	-93%
Costo 12 meses	S/. 3,587	S/. 3,327	-7%

Break even: RAG-Basic se vuelve más económico que FT-GPT3.5 después del mes 2 debido a ahorro en setup.

Tasa de alucinación

Medida: Afirmaciones no verificables en corpus documental / Total afirmaciones

Configuración	Alucinación	Ejemplos detectados
FT-GPT3.5	11.2%	"La garantía es 24 meses" (real: 12 meses)
FT-GPT4	8.7%	"El procedimiento requiere 3 aprobaciones" (real: 2)
RAG-Basic	3.1%	Principalmente extrapolaciones menores
RAG-Advanced	2.4%	Reranking reduce extrapolaciones incorrectas

Análisis: Fine-tuning tiende a "inventar" detalles plausibles cuando la información no está en su memoria de entrenamiento. RAG falla conservadoramente (no responde) vs fabricar información.

Cobertura de respuesta

¿Cuántas consultas fueron respondidas vs "No tengo información suficiente"?

Configuración	Cobertura	Notas
FT-GPT3.5	96.4%	Alta confianza incluso en respuestas incorrectas
RAG-Basic	88.7%	Rechaza 11.3% por falta de chunks relevantes
RAG-Advanced	91.9%	Reranking recupera casos borderline

Trade-off identificado: RAG es más honesto (no responde cuando no sabe) pero puede frustar usuarios en ~10% de casos donde la información SÍ existe pero no se recuperó eficientemente.

Análisis e interpretación

Hallazgo 1: Dominio de aplicabilidad es determinante

RAG domina cuando:

• Corpus <5,000 páginas con información factual estructurada
• Actualizaciones frecuentes (>1 vez/mes) del conocimiento base
• Preguntas requieren citas/referencias verificables
• Presupuesto setup limitado (<S/. 500)

Fine-Tuning domina cuando:

• Tarea requiere estilo/formato corporativo muy específico
• Vocabulario técnico ultra-especializado no común en web
• Latencia crítica (<1s p95)
• Corpus estable (actualizaciones <1 vez/trimestre)

Hallazgo 2: Costos ocultos impactan decisión

Fine-tuning

Setup: S/. 1,247 (datos preparados)

Costo real: +S/. 800–1,500
(40–60h consultor)

Re-entrenamiento: S/. 1,247 / update

Costo oculto: rigidez ante cambios

RAG

Setup: S/. 87 (indexación inicial)

Actualización: S/. 5–15 / documento

Vector DB: Local (S/. 0) / Cloud (S/. 45–180)

Costo oculto: calidad de embeddings

Recomendaciones cuantitavas:

• Consultas <2,000/mes → RAG-Basic con ChromaDB local (costo fijo ~S/. 120/mes)
• Consultas 2,000-10,000/mes → Evaluar ambos; fine-tuning puede amortizar setup
• Consultas >10,000/mes → Fine-tuning superior si formato es crítico, sino RAG-Advanced con caching

Hallazgo 3: Latencia es optimizable en RAG

Pruebas de ablación (eliminación sistemática de componentes):

Optimización	Latencia p95	Impacto precisión (ΔF1)
Baseline RAG-Basic	2,180ms	—
Embeddings cache (80%)	1,890ms	0.00
Reducir top-k (5→3)	1,820ms	-0.03
Streaming respuesta	1,640ms*	0.00
Modelo 3.5 vs 4-turbo	1,380ms	-0.07

* Mejora percibida por streaming (no reduce latencia real completa)

Configuración óptima MYPE identificada

• gpt-3.5-turbo-0125 + ChromaDB
• top-k=3 · similitud > 0.75
• Streaming habilitado
• Cache embeddings consultas comunes

Resultado: F1=0.81 · p95=1,380ms · S/. 156/mes (5K)

Hallazgo 4: Contexto geográfico importa

Impacto latencia por ubicación (Arequipa vs Lima):

Medimos 500 consultas desde servidor Arequipa vs servidor AWS us-east-1:

Ubicación servidor	Latencia promedio API	Delta
Lima (AWS)	78ms	baseline
Arequipa (on-prem)	118ms	+51%
Cusco (on-prem)	134ms	+72%

Implicación: MYPES del sur del Perú con servidores locales tienen desventaja de latencia inherente de ~40-55ms. Esto favorece arquitecturas que minimicen llamadas API (fine-tuning hace 1 llamada vs RAG hace 2: embedding + inferencia).

‍Solución validada:Para RAG en sur del Perú, batch embeddings de consultas comunes y cachearlos localmente reduce latencia efectiva en 28%.

Limitaciones del estudio

Lo que no probamos:

1. Corpus >5,000 páginas: Nuestro dataset más grande fue 2,103 páginas. Escalabilidad de RAG en corpus masivos (>50K páginas) requiere validación adicional.
‍
2. Multimodalidad: Solo evaluamos texto. Documentos con diagramas técnicos complejos no fueron incluidos (limitación de embeddings de texto).
‍
3.Latencia en producción con concurrencia: Pruebas fueron secuenciales. Degradación de performance con 50+ usuarios simultáneos no fue medida.
‍
‍4.Fine-tuning de modelos open-source: Solo evaluamos API propietarias (OpenAI). Llama-2, Mistral, o Gemma fine-tuned podrían alterar ecuación costo-beneficio.

‍5.RAG con fine-tuning híbrido: No exploramos combinar ambas técnicas (fine-tune + RAG), arquitectura que investigaremos en Q2 2025.
‍

Generalización limitada:

Estos resultados aplican específicamente a:

• MYPES peruanas con 10-200 empleados
• Corpus documentales en español de 300-2,500 páginas
• Presupuestos mensuales S/. 150-500 para inferencia
• MYPES peruanas con 10-200 empleados
• Casos de uso: soporte interno, consulta de procedimientos, generación documental
‍

Generalización requiere de validación si:
‍
• Industria es altamente regulada (salud, finanzas) con requisitos de compliance específicos
• Lenguaje incluye >30% términos quechua/aymara (no evaluado)
• Latencia requerida es <500ms (aplicaciones tiempo real)
• Corpus incluye conocimiento que evoluciona diariamente

Errores documentados

Durante las pruebas:
‍
• 12 fallos de API OpenAI (timeout >60s): 8 en horario US peak (8pm-11pm hora Perú), 4 por rate limiting
• 7 corrupciones de índice vectorial en ChromaDB: Solucionado con WAL (write-ahead logging)
• 3 casos de "respuesta vacía" en FT-GPT4: Debugging reveló que pregunta excedía contexto window después de agregar ejemplos fine-tuning

Tasa de fallo general:
‍
• FT: 0.8% (2/247)
• RAG: 1.6% (4/247) - principalmente por fallos de recuperación vectorial

Conclusiones

Hallazgo principal:
‍
‍Para el 78% de MYPES evaluadas en el sur del Perú, RAG-Basic con GPT-3.5-turbo representa el óptimo de Pareto: F1=0.84 (suficiente para casos de uso empresariales), costo 68% inferior a fine-tuning en horizonte 12 meses, y flexibilidad de actualización sin re-entrenamiento.

‍Excepción cuantificable: Empresas con >60% de consultas de formato específico (n=11 en nuestra muestra) obtienen ROI superior con FT-GPT3.5 a partir del mes 4.

Matriz de decisión técnica:

Criterio	Puntaje FT	Puntaje RAG	Ganador
Precisión factual (35%)	71	84	RAG
Costo 12 meses (30%)	S/. 3,587	S/. 3,327	RAG
Latencia p95 (20%)	1,520ms	2,180ms	FT
Mantenibilidad (15%)	6/10	9/10	RAG
Score ponderado	67.8	78.4	RAG

Resultado: RAG domina en 3/4 criterios y obtiene el mayor score ponderado

Reproductibilidad

Confguración completa:
‍
Código de evaluación: Disponible bajo solicitud para empresas participantes (NDA requerido por protección de datos empresariales).
‍
Contacto: eval@odysea.tech

Repositorio: https://github.com/Odysea-Technologies/Fine-Tuning-vs-RAG-Estudio-Comparativo-Odysea-Eval

Dataset anonimizado:Por restricciones de confidencialidad, no podemos compartir corpus completo. Dataset sintético representativo (50 documentos, 247 preguntas) disponible en: https://github.com/Odysea-Technologies (próximamente)

Para replicar este estudio:

Python


from langchain.vectorstores import Chroma
from langchain.embeddings import OpenAIEmbeddings
from langchain.chat_models import ChatOpenAI
embeddings = OpenAIEmbeddings(
    model="text-embedding-3-small"
)
vectorstore = Chroma(
    persist_directory="./chroma_db",
    embedding_function=embeddings
)

Condiciones que invalidan estos resultados:
‍
Corpus en idiomas distintos a español
Empresas >500 empleados (diferentes patrones de uso)
Latencia API OpenAI >200ms (nuestra baseline fue 118ms)

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.

Menu