RAG vs fine-tuning en empresas: cómo decidir

Un patrón muy común en SaaS B2B: el equipo de soporte quiere que un bot responda desde documentación interna. Hay artículos de ayuda, especificaciones de producto, guías de resolución de incidencias y respuestas habituales de soporte. El primer impulso suele ser fine-tuning. Entrenar el modelo con los documentos. Hacer que "conozca" el producto.

Ese impulso suele ser equivocado.

Fine-tuning puede hacer que un modelo mejore en una tarea o estilo. No convierte documentación cambiante en una fuente fiable de verdad. Si los datos cambian cada semana y la respuesta necesita citas, RAG suele ser la primera arquitectura que hay que probar.

Fine-tuning no es una mala tecnología. Muchas veces es mala solución para el problema que el comprador realmente tiene.

Decisión rápida

Usa RAG cuando el sistema tenga que responder desde datos de empresa, citar fuentes y mantenerse actualizado sin reentrenar. Usa fine-tuning cuando el sistema tenga que aprender un comportamiento, formato, estilo o patrón de tarea estable. Usa ambos solo si necesitas hechos anclados en fuentes y una forma de respuesta muy específica. No uses ninguno si un prompt sencillo con el modelo base ya supera tu evaluación.

Si estás contratando consultoría, esta diferencia importa porque el alcance cambia por completo. RAG es un problema de recuperación y arquitectura de producto. Fine-tuning es un problema de dataset, entrenamiento y evaluación.

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 respuestas inventadas bajan mucho en preguntas directas. La mejora exacta depende de la calidad de recuperación, no solo del modelo.

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 tandas de entrenamiento. Es 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 entradas y salidas deseadas. 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 y salidas estructuradas en formatos específicos. Fine-tuning puede ayudar a que el modelo devuelva JSON con tu esquema de forma más 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 implica reentrenar. Eso significa preparar dataset, lanzar entrenamiento, evaluar y desplegar. Semanas de trabajo por cada ciclo de actualización.

Coste. Las tandas de entrenamiento son caras. Un solo entrenamiento con un dataset decente puede costar cientos o miles de euros, y luego la inferencia puede ser más cara que con 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?

Marco 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 cientos o miles de ejemplos claros de entrada y salida
• 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 se complican antes de tiempo.

Nota para compradores: RAG con documentos internos

La mayoría de empresas que preguntan por "entrenar un modelo con nuestros documentos" realmente quieren una de estas cosas:

• Búsqueda interna con respuestas citadas.
• Soporte al cliente sobre documentación de producto.
• Ayuda a ventas u operaciones sobre políticas, contratos o procedimientos.
• Investigación sobre informes, tickets, manuales o notas de reuniones.

Eso suele ser primero un problema de recuperación. Las preguntas importantes son: si el sistema encuentra la fuente correcta, si puede enseñar esa fuente, si sabe decir "no lo sé" cuando la fuente es débil y si el equipo puede medir la calidad de recuperación con el tiempo.

Si esas respuestas no están claras, fine-tuning no va a salvar el proyecto.

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 fragmentación importa más de lo que parece. Fragmentos muy pequeños pierden contexto. Fragmentos muy grandes desperdician tokens y reducen precisión. Lo sensato es empezar con una hipótesis medible y ajustar 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 sobreajuste es real. Tu modelo puede memorizar datos de entrenamiento y fallar con entradas nuevas. Reserva siempre un conjunto de prueba.

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 sobre sistemas multi-agente. Si la duda está ligada a documentación interna, empieza por consultoría RAG. Si ya tienes un sistema y necesitas decidir si arreglarlo o reconstruirlo, lee la guía de auditoría técnica de IA o envía el contexto.