RAG o fine-tuning: guía para decidir cómo darle conocimiento y comportamiento a un LLM

Por Felipe Traina · 28/9/2026 · 6 min · ia, llm, rag, arquitectura

"¿Hacemos RAG o fine-tuning?" es una de las preguntas más frecuentes en equipos que empiezan a construir con modelos de lenguaje, y muchas veces está mal planteada. Las dos técnicas resuelven problemas distintos. Y en 2026 hay un dato nuevo que cambia la conversación: OpenAI está cerrando su plataforma de fine-tuning. Según su documentación, ya no acepta usuarios nuevos, y los existentes podrán crear trabajos de entrenamiento "durante los próximos meses". La ficha de GPT-6 Sol, por ejemplo, lista el fine-tuning como no soportado.

Esta guía propone un marco para decidir, basado en la documentación de los proveedores y en el paper original de RAG.

El marco: dos ejes, no una elección

La guía de OpenAI sobre cómo optimizar la precisión de un LLM plantea el problema como una matriz de dos ejes:

La misma guía usa una analogía útil: RAG es como rendir un examen con el libro abierto (la información está a mano, en el contexto); el fine-tuning es como haber estudiado (el comportamiento queda incorporado).

Dicho de otro modo: RAG le da al modelo qué saber; el fine-tuning le enseña cómo comportarse.

Qué es RAG, en concreto

Retrieval-Augmented Generation se popularizó con el paper de Lewis et al., presentado en NeurIPS 2020, que combinaba un modelo generativo con un índice vectorial de Wikipedia consultado por un recuperador neuronal. En la práctica actual, un sistema RAG:

  1. Divide los documentos en fragmentos (chunks) y los indexa, en general con embeddings en una base vectorial, a veces combinada con búsqueda por palabras clave.
  2. Ante una consulta, recupera los fragmentos más relevantes.
  3. Los incluye en el prompt y le pide al modelo que responda usándolos.

La guía de OpenAI lo dice sin vueltas: muchos de sus despliegues más grandes con clientes se hicieron solo con prompt engineering y RAG.

Cuándo elegir cada uno

Situación Técnica recomendada
El conocimiento cambia seguido (precios, políticas, documentación) RAG
Hay que citar la fuente de cada respuesta RAG
Hay permisos por usuario sobre los documentos RAG (filtrando en la recuperación)
El modelo no respeta un formato de salida estricto Primero prompting y salidas estructuradas; fine-tuning si no alcanza
Necesitás un tono o estilo muy específico y consistente Fine-tuning (o few-shot si alcanza)
Querés que un modelo chico haga una tarea acotada tan bien como uno grande Fine-tuning (destilación)
El corpus es chico y estable Contexto largo o prompt con los documentos, sin infraestructura de RAG

Y hay combinaciones: la guía de OpenAI describe casos en los que se hace fine-tuning de un modelo con ejemplos que ya incluyen el contexto recuperado, para que aprenda a usar mejor ese contexto.

Empezar por lo más barato

El orden que suele funcionar, de menor a mayor costo y complejidad:

  1. Prompt engineering con instrucciones claras y ejemplos (few-shot).
  2. Salidas estructuradas (JSON con esquema) cuando el problema es de formato.
  3. Contexto directo: si los documentos entran en la ventana de contexto, probá pasarlos completos antes de construir un pipeline de recuperación. Con cuidado del costo: en GPT-6 Sol, por ejemplo, un request que supera los 272.000 tokens de entrada se cobra con recargo completo.
  4. RAG cuando el corpus es grande, cambia o requiere permisos.
  5. Fine-tuning cuando el problema es de comportamiento y lo anterior no alcanzó, medido con evals.

Saltar directo al paso 5 es un error caro y frecuente.

Si necesitás fine-tuning en 2026

Con OpenAI retirando su plataforma, las opciones pasan por otros caminos:

En cualquier caso, si hoy dependés de un modelo fine-tuneado en OpenAI, revisá su página de deprecaciones: la documentación indica que los modelos ya entrenados siguen disponibles para inferencia hasta que se depreque su modelo base.

Los problemas típicos de RAG (y cómo detectarlos)

RAG agrega un nuevo eje que hay que evaluar: la recuperación. La guía de OpenAI lo plantea como una grilla: ¿se recuperó el contexto correcto? ¿el modelo respondió bien con ese contexto? Los fallos típicos:

Una forma simple de medir la recuperación por separado:

def recall_en_k(casos, recuperar, k=5):
    """casos: lista de (pregunta, id_documento_correcto)."""
    aciertos = 0
    for pregunta, doc_correcto in casos:
        ids = [d.id for d in recuperar(pregunta, k=k)]
        aciertos += doc_correcto in ids
    return aciertos / len(casos)

Si el recall en k es bajo, ningún modelo va a responder bien: el problema está antes del LLM.

Qué hacer con esto

¿En tu caso, el problema que querés resolver es de conocimiento o de comportamiento?

Lecturas relacionadas

Fuentes

← Volver al blog