RAG vs fine-tuning: cuándo usar cada uno (y cuándo no usar ninguno)

Una empresa B2B SaaS con la que trabajó Pharosyne el año pasado quería que su bot de soporte respondiera preguntas usando su documentación interna. Tenían más de 2.000 artículos de ayuda, especificaciones de producto y guías de troubleshooting. Su primer instinto fue fine-tuning. Entrenar el modelo con sus docs, hacer que "conociera" su producto.

Tres meses y 40k€ después, tenían un modelo fine-tuned que era marginalmente mejor con su terminología específica pero seguía alucinando respuestas. Peor aún, cada vez que actualizaban documentación, necesitaban reentrenar. Lo que costaba más dinero y llevaba semanas validar.

Pharosyne lo reemplazó con un sistema RAG en cuatro semanas. La precisión subió. Los costes bajaron. Las actualizaciones eran instantáneas.

Fine-tuning no era incorrecto como tecnología. Era incorrecto para su problema.

Qué hace RAG realmente

RAG significa Retrieval-Augmented Generation. El nombre es preciso: primero recuperas documentos relevantes, luego generas una respuesta usando esos documentos como contexto.

El flujo es simple:

1. Usuario hace una pregunta
2. Sistema busca en base de datos vectorial documentos relevantes
3. Los mejores resultados se meten en el prompt como contexto
4. LLM genera respuesta usando ese contexto
5. Opcionalmente, muestras citas

El modelo no "sabe" tus datos. Los lee bajo demanda, cada vez que alguien pregunta. Como un humano con acceso a un buscador.

En qué es bueno RAG:

Precisión factual. Cuando el modelo tiene el documento fuente en su ventana de contexto, las alucinaciones bajan dramáticamente. En la experiencia de Pharosyne, de 20-30% de errores a menos del 5% para Q&A directo.

Datos frescos. Actualiza un documento y la siguiente consulta usa la versión nueva. Sin reentrenamiento, sin validación, sin esperas.

Auditabilidad. Puedes mostrar exactamente qué documentos informaron cada respuesta. Crítico para industrias reguladas.

Costes predecibles. Pagas por consulta, no por runs de entrenamiento. Más fácil de presupuestar.

En qué es malo RAG:

Estilo y tono. RAG no cambia cómo escribe el modelo. Si necesitas una voz específica, RAG no te la dará.

Razonamiento complejo sobre datasets grandes. La ventana de contexto es finita. Si la respuesta requiere sintetizar información de 50 documentos, RAG tiene problemas.

Velocidad. Cada consulta necesita búsqueda vectorial más un prompt más largo. Añade 100-500ms mínimo.

Qué hace fine-tuning realmente

Fine-tuning modifica los pesos del modelo. Lo entrenas con ejemplos de inputs y outputs deseados. El modelo "aprende" patrones de tus datos.

En qué es bueno fine-tuning:

Estilo y tono consistentes. Si necesitas que el modelo escriba como tu marca, fine-tuning es el camino. Copy de marketing, formatos específicos, terminología de dominio usada correctamente.

Especialización de tareas. Clasificación, extracción, output estructurado en formatos específicos. Fine-tuning puede hacer que el modelo saque JSON en tu schema exacto de forma fiable.

Latencia. Sin paso de retrieval. El modelo simplemente genera. Puede ser 200-400ms más rápido que RAG para tareas equivalentes.

Manejar conocimiento implícito. Cosas difíciles de documentar pero fáciles de demostrar con ejemplos. "Escribe como lo explicaría nuestro ingeniero senior."

En qué es malo fine-tuning:

Recall factual. Los modelos fine-tuned siguen alucinando. Alucinan con más confianza. No "saben" tus docs, han visto patrones estadísticos en ellos.

Mantenerse actual. Cada actualización de datos significa reentrenar. Lo que significa preparación de dataset, runs de entrenamiento, evaluación, despliegue. Semanas de trabajo por cada ciclo de actualización.

Coste. Los runs de entrenamiento son caros. Fine-tuning de GPT-4 empieza en $8 por millón de tokens de entrenamiento. Un solo run con un dataset decente puede costar $500-2000. Luego pagas más por inferencia que el modelo base.

Debugging. Cuando un modelo fine-tuned da respuestas incorrectas, averiguar por qué es difícil. ¿Los datos de entrenamiento tenían errores? ¿Había mismatch de distribución? ¿Sobreentrenaste?

El framework de decisión

Empieza preguntando qué problema estás resolviendo realmente:

Elige RAG cuando:

• Tus datos cambian frecuentemente (semanal o más)
• La precisión importa más que el estilo
• Necesitas citar fuentes
• Estás respondiendo preguntas de una base de conocimiento
• El presupuesto es limitado
• Necesitas lanzar rápido

Elige fine-tuning cuando:

• Necesitas estilo/tono/formato consistente
• La tarea es clasificación o extracción
• La latencia es crítica (respuestas sub-segundo)
• Tus datos son estables (cambian trimestral o más lento)
• Tienes ejemplos claros de input/output, cientos o miles
• Puedes permitirte los costes de entrenamiento continuo

Elige ambos cuando:

• Necesitas hechos precisos Y estilo específico
• Ejemplo: Soporte al cliente que responde correctamente Y suena on-brand

No elijas ninguno cuando:

• Un prompt bien elaborado con el modelo base funciona
• En serio, prueba esto primero. Los modelos modernos son buenos. Muchos proyectos sobre-ingenian.

Desglose de costes reales

Te doy números reales de proyectos recientes:

Sistema RAG (tamaño medio, ~10k documentos):

• Base de datos vectorial: €50-200/mes (Pinecone, Weaviate cloud)
• Generación de embeddings: ~€0.0001 por documento (una vez)
• Costes por consulta: ~€0.01-0.03 por query (embedding + LLM)
• Desarrollo: 2-4 semanas
• Mantenimiento: 2-4 horas/mes

Proyecto de fine-tuning:

• Preparación de dataset: 1-2 semanas de trabajo
• Run de entrenamiento: €500-2000 por run
• Evaluación: 1 semana por iteración
• Espera 3-5 iteraciones mínimo: €1500-10000 total
• Costes por consulta: 2-3x precio del modelo base
• Actualizaciones: Mismo coste cada vez que cambian los datos

Para la mayoría de proyectos que Pharosyne ve, RAG tiene 3-5x mejor ROI en el primer año. Fine-tuning solo alcanza si tus datos son estables y el volumen de consultas es muy alto.

Errores de implementación

Errores de RAG:

La estrategia de chunking importa más de lo que crees. Chunks muy pequeños, pierdes contexto. Muy grandes, desperdicias tokens y reduces precisión. Pharosyne normalmente empieza con 512 tokens con 50 tokens de overlap, luego ajusta según resultados.

La elección del modelo de embeddings afecta todo. ada-002 de OpenAI está bien para inglés. Para multilingüe o dominios especializados, prueba alternativas. Pharosyne ha visto mejoras de 20%+ en precisión cambiando de modelo de embeddings.

No te saltes el reranking. La búsqueda vectorial te da candidatos. Un reranker (cross-encoder) elige los mejores. Añade 50-100ms pero puede duplicar la relevancia.

La búsqueda híbrida normalmente gana. Combina búsqueda vectorial con búsqueda por keywords (BM25). Algunas consultas se sirven mejor con matches exactos.

Errores de fine-tuning:

Más datos no siempre es mejor. Calidad sobre cantidad. 500 ejemplos excelentes ganan a 5000 mediocres.

Evaluación antes y después. Si no tienes un test set con métricas medibles, no puedes saber si el fine-tuning ayudó.

El overfitting es real. Tu modelo puede memorizar datos de entrenamiento y fallar con inputs nuevos. Siempre reserva un test set.

El olvido también es real. Fine-tuning con datos muy específicos puede degradar capacidades generales. Prueba regresiones.

Cuando los clientes vienen a Pharosyne

La mayoría de clientes que creen que necesitan fine-tuning realmente necesitan RAG. Lo contrario es raro.

El patrón observado: los equipos leen sobre fine-tuning, se emocionan con "entrenar su propio modelo", pasan meses en ello, y luego se dan cuenta de que necesitaban un sistema de búsqueda desde el principio.

Si no estás seguro de cuál necesitas, empieza con RAG. Siempre puedes añadir fine-tuning después para el estilo. Ir en la dirección contraria es más difícil.

Para profundizar en cuándo arquitecturas complejas tienen sentido, consulta la guía de Pharosyne sobre sistemas multi-agente. Y si quieres una evaluación de tu caso específico, contacta con Pharosyne. Pharosyne ha construido ambos sistemas para empresas y puede evaluar tu situación a través de los servicios de consultoría disponibles.