RAG o fine-tuning: ¿qué necesita tu proyecto de IA?

Usa RAG (generación aumentada por recuperación, retrieval-augmented generation) cuando el modelo necesite conocer datos, sobre todo datos que cambian o que son propios de tu empresa, como políticas, datos de producto o documentación. Usa fine-tuning cuando el modelo deba comportarse de otra manera: seguir un estilo, un formato o un patrón de tarea muy acotado con más constancia de la que logran los prompts. El RAG cambia lo que ve el modelo; el fine-tuning cambia cómo responde. Para la mayoría de proyectos empresariales, el orden correcto es primero prompting, después RAG, y fine-tuning solo cuando las pruebas muestren una carencia que los dos primeros no resuelven.

Cómo funciona el RAG

El RAG añade un paso de búsqueda antes de que responda el modelo:

1. Preparar los documentos. Tu contenido se divide en pasajes (chunks) y se indexa, a menudo con embeddings: representaciones numéricas del significado que permiten buscar por similitud.
2. Recuperar. Cuando llega una pregunta, el sistema busca en el índice los pasajes más relevantes. Muchos sistemas combinan búsqueda semántica y por palabras clave.
3. Aumentar. Los pasajes recuperados se insertan en el prompt junto con las instrucciones.
4. Generar. El modelo redacta una respuesta basada en esos pasajes, idealmente citándolos.

El modelo no cambia: actualiza y reindexa un documento y la siguiente respuesta lo reflejará.

Cómo funciona el fine-tuning

El fine-tuning continúa el entrenamiento de un modelo existente con tus propios ejemplos, normalmente pares de entrada y salida deseada:

1. Reunir ejemplos. Muchos pares de entrada y salida de calidad que muestren el comportamiento que buscas.
2. Entrenar. El proveedor o tu propia infraestructura ajusta el modelo con esos ejemplos.
3. Evaluar. Compara el modelo ajustado con el modelo base más prompts en un conjunto de prueba reservado.
4. Desplegar. Usa el modelo ajustado para tu tarea.

El modelo aprende patrones de los ejemplos: formato, tono, límites de clasificación, expresiones del sector. No se convierte en una base de datos fiable. Enseñar datos mediante fine-tuning es ineficiente, difícil de actualizar y no permite mostrar fuentes.

Comparación lado a lado

Criterio	RAG	Fine-tuning
Propósito principal	Aportar conocimiento en el momento de la solicitud	Moldear comportamiento y estilo
Mantiene los datos al día	Sí, actualizando los documentos	No, hay que reentrenar
Muestra fuentes	Sí, puede citar los pasajes recuperados	No
Datos necesarios	Tus documentos	Muchos ejemplos de entrada y salida bien preparados
Esfuerzo de puesta en marcha	Proceso de indexación, ajuste de la recuperación	Preparación de datos, entrenamiento, evaluación
Coste recurrente	Más tokens de entrada por solicitud (contexto recuperado) más la infraestructura de búsqueda	Quizá prompts más cortos; los modelos ajustados pueden tener otros precios
Mantenimiento	Mantener los documentos limpios y el índice al día	Reentrenar cuando cambien los requisitos o los modelos base
Reduce alucinaciones	Sí, cuando la recuperación encuentra los pasajes correctos	No de forma fiable en los datos
Control de acceso	Puede filtrar documentos por usuario	El conocimiento queda integrado para todos

Cuándo el RAG es la opción correcta

• Asistentes de conocimiento interno: responder dudas del personal a partir de manuales, políticas y procedimientos.
• Atención al cliente: respuestas basadas en el centro de ayuda, los datos de producto y la información de pedidos.
• Preguntas sobre documentos: contratos, manuales técnicos, colecciones de investigación.
• Todo lo que tenga datos cambiantes: precios, existencias, normativa, gamas de producto.
• Cuando necesitas trazabilidad: citar el pasaje de origen ayuda a revisores y usuarios a verificar las respuestas, una técnica clave para reducir las alucinaciones de la IA.
• Cuando el acceso varía según el usuario: la recuperación puede respetar permisos para que cada persona solo reciba respuestas de documentos que puede ver.

Cuándo el fine-tuning es la opción correcta

• Formato o estilo constantes con mucho volumen, cuando los prompts largos con ejemplos serían caros o no lo bastante consistentes.
• Tareas acotadas de clasificación o extracción con muchos ejemplos etiquetados disponibles.
• Expresiones del sector que el modelo base maneja mal incluso con buenos prompts.
• Usar un modelo más pequeño y barato para una tarea que de otro modo requiere uno mayor. Un modelo pequeño ajustado a veces iguala a uno grande en una tarea acotada y reduce el coste por solicitud, como se explica en cómo reducir los costes de API de LLM.

Antes de ajustar, esfuérzate más con el prompting: instrucciones más claras, un prompt de sistema bien estructurado y unos pocos buenos ejemplos (few-shot prompting). Cambiarlos es más barato y a menudo cierran la brecha.

De qué depende la calidad del RAG

El RAG no es un interruptor que se enciende. La calidad de las respuestas depende de varios componentes:

Componente	Qué puede fallar	Qué ayuda
Documentos de origen	Contenido obsoleto, duplicado o contradictorio	Limpiar y asignar responsables antes de indexar
División en pasajes	Pasajes cortados a mitad de idea, pérdida de contexto	Dividir por títulos y secciones; incluir los títulos
Recuperación	No se encuentra el pasaje relevante o llegan pasajes irrelevantes	Combinar búsqueda semántica y por palabras clave, reordenar resultados, ajustar el número de pasajes
Prompt	El modelo ignora las fuentes o añade su propio conocimiento	Regla explícita de responder solo con las fuentes y decir cuándo falta información
Evaluación	No se sabe si las respuestas son correctas	Conjunto de preguntas con respuesta conocida, incluidas las que no tienen respuesta

En la práctica, muchos problemas de RAG son problemas de documentos. Si tu base de conocimiento se contradice, la IA también.

Qué requiere el fine-tuning

• Suficientes ejemplos buenos. Importa más la calidad que la cantidad, pero un puñado no basta; los proveedores documentan mínimos y recomendaciones.
• Etiquetas coherentes. Si las personas no coinciden en cuál es la salida correcta, el modelo aprende esa incoherencia.
• Un conjunto de prueba apartado del entrenamiento para medir la mejora con honestidad.
• Un punto de partida: el mejor resultado solo con prompts, para saber si el fine-tuning aporta valor.
• Un plan de mantenimiento. Cuando el proveedor publique un nuevo modelo base o cambien tus requisitos, quizá tengas que volver a ajustar.

Consideraciones de coste

Los costes difieren en su estructura más que en ser simplemente mayores o menores:

• El RAG añade pasajes recuperados a cada solicitud, lo que aumenta los tokens de entrada, y requiere infraestructura de búsqueda. Recuperar menos pasajes, pero mejores, contiene el coste. Usa la calculadora de coste de API de LLM para ver el efecto de la longitud del contexto en tu factura.
• El fine-tuning tiene costes iniciales de preparación de datos y entrenamiento, y los modelos ajustados pueden tener precios distintos a los modelos base. Puede reducir el coste por solicitud si permite prompts más cortos o modelos más pequeños.

Consulta los precios actuales con tu proveedor: las condiciones varían y cambian.

Una guía de decisión

Hazte estas preguntas por orden:

1. ¿Funciona ya un prompt bien escrito con el contexto adecuado? Si es así, para aquí.
2. ¿Necesita el modelo datos que no tiene, o datos que cambian? Usa RAG.
3. ¿Las respuestas deben citar fuentes o respetar permisos de usuario? Usa RAG.
4. ¿El problema que queda es de estilo, formato o constancia? Prueba primero con ejemplos few-shot.
5. ¿Los ejemplos en el prompt siguen sin bastar, y tienes muchos ejemplos buenos y mucho volumen? Plantéate el fine-tuning.
6. ¿Necesitas a la vez datos actuales y un comportamiento muy específico? Combínalos: RAG para el conocimiento y un modelo ajustado para el comportamiento.

Enfoques híbridos

• RAG con un modelo ajustado: el modelo se ajusta para seguir tu formato y tono de respuesta; los datos salen de la recuperación.
• Componentes de recuperación ajustados: algunos equipos mejoran la búsqueda adaptando a su ámbito los modelos de embeddings o de reordenación.
• Enrutado: las preguntas sencillas van a un modelo pequeño; las complejas, a uno mayor con más contexto recuperado.

Esto añade complejidad. Úsalos cuando esté demostrado que las configuraciones más sencillas no bastan, no como arquitectura de partida.

Errores habituales

• Ajustar para enseñar datos. Es poco fiable, difícil de actualizar y no permite citar fuentes.
• Indexar documentos desordenados. El RAG amplifica las incoherencias.
• Recuperar demasiado. Más pasajes suman coste y ruido; un contexto enfocado suele dar mejores respuestas.
• Saltarse la evaluación. Sin conjunto de prueba no puedes comparar enfoques.
• Elegir la arquitectura antes de definir la tarea. Empieza por el problema, los usuarios y cómo es una buena respuesta.

Resumen

El RAG da al modelo acceso a tu conocimiento; el fine-tuning cambia sus hábitos. Empieza con prompting, añade RAG cuando el modelo necesite tus datos y plantéate el fine-tuning solo para comportamientos que los ejemplos en el prompt no logren de forma fiable. Elijas lo que elijas, pruébalo con preguntas reales y mantén el proceso de revisión descrito en nuestra guía para implantar la IA en una pyme.