Qué es RAG y cuándo usarlo en vez de fine tuning

Qué es RAG se responde mejor junto a su alternativa, porque la elección se plantea como técnica y en realidad es un diagnóstico. Antes de elegir, nombra el problema: ¿al modelo le falta conocimiento o se comporta mal? La recuperación arregla lo primero. El entrenamiento arregla lo segundo. Elegir mal produce un proyecto caro que no mueve el fallo del que partiste.

A los clientes les pido una cosa antes de seguir esta conversación: enséñame cinco salidas con las que no estés contento. La respuesta suele verse ahí.

Qué es RAG y en qué se diferencia del fine tuning#

Retrieval augmented generation busca los fragmentos relevantes de tus documentos en el momento de la pregunta y los mete en el prompt. El modelo responde entonces desde material que puede citar. Nada del modelo cambia. Actualizas un documento y la siguiente respuesta lo refleja de inmediato.

El fine tuning continúa entrenando el modelo con tus ejemplos, ajustando sus pesos. Aprende patrones de comportamiento: tu formato de salida, tu tono, cómo clasificas tú las cosas. No aprende datos de forma fiable, y los datos aprendidos así no se corrigen sin volver a entrenar.

La versión comprimida: RAG cambia lo que el modelo tiene delante. El fine tuning cambia el modelo.

Diagnostica antes de construir#

Esa última fila importa. Ninguna de las dos técnicas hace que un modelo razone mejor. Si la tarea es genuinamente difícil, descomponla en pasos en vez de esperar que el entrenamiento lo arregle.

Por qué RAG es el valor por defecto para conocimiento de empresa#

Tres razones, prácticas más que teóricas.

Los datos cambian. Precios, políticas, documentación, personal. La recuperación refleja una edición en cuanto se guarda. Reentrenar no.

Las citas. Un sistema de recuperación puede enseñar de qué documento salió la respuesta, que es la diferencia entre una herramienta en la que la gente confía y una que revisan dos veces. En trabajo regulado no es opcional.

Los permisos. Puedes filtrar la recuperación por lo que el usuario tiene permitido ver. Los pesos no tienen concepto de control de acceso, así que un modelo entrenado con material confidencial se lo repetirá encantado a cualquiera.

El coste es real: pagas el contexto recuperado en cada llamada. En precios de la API de Claude explico cómo mantenerlo a raya con caché y recuperando tres párrafos en vez de adjuntar el manual entero.

Dónde el fine tuning se gana su coste#

Formato a escala. Cuando cada respuesta debe tener la misma estructura y el prompt te lleva al 95%, el entrenamiento cierra el hueco y elimina la lógica de reintentos.

Voz. Un tono que los prompts aproximan pero nunca clavan, a lo largo de miles de salidas.

Clasificación estrecha. Tus categorías, tus casos límite, a volumen. Un modelo pequeño entrenado suele ganar aquí a uno grande con prompt, y cuesta una fracción.

Latencia y coste unitario. Si el entrenamiento te permite bajar de un modelo grande a uno pequeño en un paso de alto volumen, la economía puede ser decisiva.

El requisito que se subestima: necesitas buenos ejemplos. De cientos a miles, consistentes, que representen lo que de verdad quieres. Montar ese conjunto es casi todo el trabajo y casi todo el coste, y los ejemplos inconsistentes producen un modelo consistentemente inconsistente.

El orden en que probar cosas#

1. Mejora el prompt y el contexto. Una instrucción clara, un ejemplo resuelto, un esquema explícito. Un día de trabajo, y resuelve una parte sorprendente de los proyectos que ya habían presupuestado entrenamiento. En ejemplos de prompts y few-shot prompting están las técnicas.

2. Añade recuperación. Si el fallo es de conocimiento, esta es tu respuesta. Empieza por la versión más simple que funcione.

3. Restringe la salida. Pide JSON contra un esquema y valídalo. Esto elimina casi todas las quejas de formato sin tocar un modelo.

4. Haz fine tuning. Solo cuando tengas ejemplos del comportamiento que quieres, a volumen, y un hueco medible que los tres primeros no cerraron.

La mayoría de los equipos se quedan en el paso dos y hacen bien.

Montar bien la versión RAG#

La versión ingenua decepciona y luego se culpa a la técnica. Cuatro cosas arreglan casi todo.

Trocea por significado, no por número de caracteres. Un fragmento que parte una tabla por la mitad se recupera mal.

Guarda metadatos. Fuente, fecha, sección y ámbito de permiso. Vas a necesitar los cuatro.

Recupera menos y mejor. Diez fragmentos mediocres son peores que tres relevantes, y cuestan más.

Evalúa la recuperación por separado de la generación. Cuando una respuesta esté mal, necesitas saber si el documento correcto se encontró y se ignoró o si nunca se encontró. Son fallos distintos con arreglos distintos.

En ingeniería de contexto cubro la disciplina más amplia de decidir qué entra en la ventana.

La versión corta#

Diagnostica primero: conocimiento o comportamiento. Usa recuperación para los datos, porque cambian y hay que citarlos. Usa entrenamiento para formato, voz y clasificación estrecha a volumen, cuando tengas los ejemplos. Prueba un prompt mejor antes que cualquiera de las dos.

Si quieres esto diseñado alrededor de tus documentos y a tu equipo formado para mantenerlo, es lo que cubren mis formaciones de IA para empresas, y en la agencia de inteligencia artificial es donde hago este trabajo para clientes.