RAG vs Fine-Tuning vs Contexto Largo: Cómo Elegir la Arquitectura LLM Correcta en 2026

Estás armando una aplicación con LLMs y necesitás que trabaje con tus propios datos. Tal vez documentación interna, tickets de soporte, contratos legales o un catálogo de productos. El modelo base no sabe nada de eso. Entonces te encontrás con la pregunta que todo ingeniero de IA enfrenta eventualmente:

¿Uso RAG, hago fine-tuning del modelo, o meto todo en la ventana de contexto?

Hace un año, esto era una decisión entre dos opciones. En 2026, es una elección entre tres, y equivocarte significa quemar plata en infraestructura que no necesitás, o lanzar una app que alucina sobre tus datos propietarios.

Esta guía te da el framework de decisión completo. Sin rodeos. Arquitecturas reales, matemática de costos concreta, código de producción, y un árbol de decisión que podés usar hoy.

Las Tres Opciones de un Vistazo

Antes de profundizar, veamos qué hace cada enfoque:

RAG (Retrieval-Augmented Generation) busca fragmentos relevantes de tus datos en el momento de la consulta y los inyecta en el prompt. Los pesos del modelo nunca cambian: le estás dando una hoja de ayuda para cada pregunta.

Fine-tuning modifica los pesos del modelo entrenándolo con tus datos específicos. El conocimiento queda horneado dentro del modelo. Pensalo como enseñarle al modelo a hablar tu idioma de dominio de forma nativa.

Contexto largo simplemente mete todo tu dataset (o grandes porciones) directamente en la ventana de contexto del modelo. Sin pipeline de búsqueda, sin entrenamiento. Con la ventana de 1M tokens de Claude y 1M de Gemini 3.1, esto ahora es viable para datasets que antes eran imposibles de manejar así.

┌──────────────────────────────────────────────────────────────────┐
│                   Tus Datos + LLM = Respuesta                    │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  RAG                    Fine-Tuning            Contexto Largo    │
│  ┌──────────────┐       ┌──────────────┐      ┌──────────────┐  │
│  │ Query → Buscar│       │ Entrenar el  │      │ Meter todos  │  │
│  │ → Top K chunks│       │ modelo con   │      │ los datos en │  │
│  │ → Inyectar en │       │ tus datos    │      │ el prompt    │  │
│  │   prompt      │       │ → Nuevos     │      │ → Preguntar  │  │
│  │ → Generar     │       │   pesos      │      │ → Generar    │  │
│  └──────────────┘       └──────────────┘      └──────────────┘  │
│                                                                  │
│  Modelo sin cambios      Modelo modificado     Modelo sin cambios│
│  Datos externos          Datos internalizados  Datos en prompt   │
│  Conocimiento dinámico   Conocimiento estático Estático por query│
│  Infraestructura pesada  Entrenamiento pesado  Tokens pesados    │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

Vamos a fondo con cada uno.

RAG: Retrieval-Augmented Generation

Cómo Funciona

RAG divide tu pipeline en dos fases: recuperación y generación.

1. Indexación (offline): Tus documentos se dividen en chunks, se convierten en vectores y se guardan en una base de datos vectorial
2. Recuperación (en tiempo de consulta): La query del usuario se embedea y se recuperan los chunks más similares semánticamente
3. Generación: Los chunks recuperados se inyectan en el prompt como contexto, y el LLM genera una respuesta fundamentada

Pipeline RAG de Producción en 2026

Un RAG moderno no es solo "embedear y buscar." Así luce un setup de producción:

import { OpenAIEmbeddings } from "@langchain/openai";
import { PGVectorStore } from "@langchain/community/vectorstores/pgvector";
import { ChatOpenAI } from "@langchain/openai";
import { RecursiveCharacterTextSplitter } from "langchain/text_splitter";

// 1. Chunking con conciencia semántica
const splitter = new RecursiveCharacterTextSplitter({
  chunkSize: 512,
  chunkOverlap: 64,
  separators: ["\n## ", "\n### ", "\n\n", "\n", " "],
});

const chunks = await splitter.splitDocuments(documents);

// 2. Embedear y guardar con metadata
const embeddings = new OpenAIEmbeddings({
  model: "text-embedding-3-large",
  dimensions: 1024,
});

const vectorStore = await PGVectorStore.fromDocuments(chunks, embeddings, {
  postgresConnectionOptions: { connectionString: process.env.PG_URL },
  tableName: "documents",
});

// 3. Búsqueda híbrida: vectorial + filtrado por metadata
async function retrieve(query: string, filters?: Record<string, any>) {
  const results = await vectorStore.similaritySearchWithScore(query, 10, filters);
  const reranked = await rerank(query, results);
  return reranked.slice(0, 5);
}

// 4. Generar respuesta con contexto recuperado
async function generateAnswer(query: string) {
  const context = await retrieve(query);
  const contextText = context.map(([doc]) => doc.pageContent).join("\n\n---\n\n");

  const llm = new ChatOpenAI({ model: "gpt-4.1", temperature: 0 });
  const response = await llm.invoke([
    {
      role: "system",
      content: `Respondé basándote en el contexto proporcionado. Si el contexto 
                no contiene la respuesta, decilo. Citá el documento fuente.
                
                Contexto:
                ${contextText}`,
    },
    { role: "user", content: query },
  ]);
  return response.content;
}

Cuándo Gana RAG

RAG es la opción correcta cuando:

• Los datos cambian seguido: Catálogos de productos, tickets de soporte, noticias, documentación que se actualiza semanalmente
• La atribución de fuentes importa: Legal, medicina, compliance. Necesitás señalar exactamente de dónde viene la respuesta
• El dataset es grande: Cientos de miles de documentos donde solo necesitás pequeños fragmentos relevantes por consulta
• La precisión importa más que el estilo: Cuando la exactitud factual pesa más que cómo suena la respuesta
• Aplicaciones multi-tenant: Diferentes usuarios necesitan respuestas de diferentes subsets de datos

Cuándo RAG No Alcanza

• Razonamiento complejo cruzando muchos documentos: Si responder requiere sintetizar información de 50+ documentos, la recuperación puede fallar en piezas críticas
• Requisitos de estilo/tono/formato: RAG no cambia cómo habla el modelo, solo lo que sabe al momento de la consulta
• Apps sensibles a la latencia: El paso de búsqueda agrega 100-500ms a cada request
• Datasets chicos y estables: Si tus datos entran en una ventana de contexto y rara vez cambian, RAG es excesivo

Perfil de Costos de RAG

El costo oculto: tiempo de ingeniería. Armar y mantener un pipeline RAG de producción (estrategia de chunking, selección de modelo de embedding, reranking, filtrado por metadata, monitoreo de calidad) es una inversión de ingeniería significativa.

Fine-Tuning

Cómo Funciona

Fine-tuning toma un LLM pre-entrenado y lo entrena más con tus datos específicos, modificando los pesos del modelo para internalizar conocimiento de dominio, estilo o patrones de comportamiento.

Fine-Tuning en la Práctica

Así se ve el fine-tuning con la API de OpenAI en 2026:

import openai
import json

# 1. Preparar datos de entrenamiento en formato JSONL
training_data = [
    {
        "messages": [
            {
                "role": "system",
                "content": "Sos un ingeniero senior de seguridad en Acme Corp. "
                           "Respondé sobre políticas de seguridad y procedimientos "
                           "de respuesta a incidentes con lenguaje preciso y "
                           "accionable. Siempre referenciá el número de sección."
            },
            {
                "role": "user",
                "content": "¿Cuál es el procedimiento ante una sospecha de data breach?"
            },
            {
                "role": "assistant",
                "content": "Según Política §4.2.1 - Respuesta a Data Breach:\n\n"
                           "1. **Contención inmediata** (15 min): Aislá los "
                           "sistemas afectados. NO apagues. Preservá evidencia "
                           "forense.\n"
                           "2. **Escalación** (30 min): Notificá al Comandante "
                           "de Incidentes vía #security-incidents en Slack.\n"
                           "3. **Evaluación** (2 horas): Determiná el alcance "
                           "usando el modelo DREAD (§4.2.3).\n"
                           "4. **Notificación** (24 horas): Si hay PII "
                           "involucrado, Legal debe ser notificado por §7.1 GDPR.\n\n"
                           "NO comuniqués externamente hasta tener OK de Legal."
            }
        ]
    },
    # ... cientos de ejemplos más
]

with open("training_data.jsonl", "w") as f:
    for example in training_data:
        f.write(json.dumps(example) + "\n")

# 2. Subir y arrancar el fine-tuning
client = openai.OpenAI()
file = client.files.create(file=open("training_data.jsonl", "rb"), purpose="fine-tune")
job = client.fine_tuning.jobs.create(
    training_file=file.id,
    model="gpt-4.1-mini",
    hyperparameters={"n_epochs": 3, "learning_rate_multiplier": 1.0},
)

# 3. Usar el modelo fine-tuneado
response = client.chat.completions.create(
    model="ft:gpt-4.1-mini:acme-corp:security-bot:abc123",
    messages=[{"role": "user", "content": "¿Cómo manejamos un incidente de phishing?"}]
)

Cuándo Gana Fine-Tuning

Fine-tuning es la opción correcta cuando:

• Necesitás cambiar el comportamiento del modelo: Formato de salida específico, tono, estilo de razonamiento, voz de marca
• Tu conocimiento es estable: Políticas internas, expertise de dominio, estándares de código que no cambian semanalmente
• La latencia importa: Sin paso de búsqueda, las respuestas son más rápidas (solo inferencia)
• Costo a escala: Para apps de alto volumen con conocimiento estable, un modelo fine-tuneado chico evita el bloat de tokens de RAG por query
• Razonamiento especializado: Enseñarle al modelo patrones de razonamiento específicos de dominio

Cuándo Fine-Tuning No Alcanza

• Los datos cambian seguido: Cada actualización requiere re-entrenamiento
• No podés producir datos de entrenamiento de alta calidad: Basura entra, basura sale
• Catastrophic forgetting: El modelo puede "olvidar" capacidades generales al entrenarse agresivamente con datos estrechos
• Atribución de fuentes: Los modelos fine-tuneados no pueden apuntar a dónde aprendieron algo
• Equipos chicos: El overhead de ingeniería ML es significativo

Perfil de Costos de Fine-Tuning

El costo oculto: curación de datos. Necesitás cientos a miles de conversaciones de ejemplo de alta calidad.

Ventanas de Contexto Largo

Cómo Funciona

El enfoque más simple de todos: tomá tus documentos, concatenalos, y metelos en la ventana de contexto del modelo junto con la query. Sin pipelines de embedding, sin bases vectoriales, sin entrenamiento.

import Anthropic from "@anthropic-ai/sdk";
import { readFileSync, readdirSync } from "fs";
import { join } from "path";

const anthropic = new Anthropic();

function loadDocuments(dir: string): string {
  const files = readdirSync(dir).filter((f) => f.endsWith(".md"));
  return files
    .map((f) => {
      const content = readFileSync(join(dir, f), "utf-8");
      return `--- ${f} ---\n${content}`;
    })
    .join("\n\n");
}

const allDocs = loadDocuments("./docs"); // 500K+ tokens

async function askQuestion(question: string) {
  const response = await anthropic.messages.create({
    model: "claude-sonnet-4-20250514",
    max_tokens: 4096,
    messages: [{
      role: "user",
      content: `Acá está toda nuestra documentación:\n\n${allDocs}\n\n` +
               `Basándote en la documentación, respondé: ${question}`,
    }],
  });
  return response.content[0].text;
}

Eso es todo. Sin chunking, sin embeddings, sin vector DB, sin reranking. Solo documentos y una pregunta.

Tamaños de Ventana de Contexto en 2026

Cuándo Gana Contexto Largo

• Dataset chico a mediano: Menos de ~500K tokens (unos cientos de páginas), esta es la opción más simple
• Lo necesitás ya: Cero infraestructura para configurar. Empezá a consultar en minutos
• Razonamiento cruzando documentos: El modelo ve todo de una, así que puede sintetizar información que RAG podría perder
• Etapa de prototipo/MVP: Hacé que funcione primero, optimizá la arquitectura después
• Consultas infrecuentes: Si hacés unos cientos de preguntas por día, el costo por query es manejable

Cuándo Contexto Largo No Alcanza

• Costo a escala: Mandar 500K tokens por query a $3/M tokens de entrada =$1.50 por query. A 10K queries/día, son $15,000/día
• Latencia: Procesar 500K tokens toma significativamente más que un prompt RAG enfocado de 2K tokens
• El problema "aguja en el pajar": Los modelos pueden fallar en encontrar detalles específicos enterrados en contextos masivos ("Lost in the Middle")
• Dataset excede la ventana: Si tu dataset tiene 10M tokens y la ventana es 1M, este enfoque simplemente no funciona

Perfil de Costos de Contexto Largo

El costo oculto: no escala. Lo que arranca como la opción más barata se convierte en la más cara con volumen.

El Framework de Decisión

El árbol de decisión práctico:

                    INICIO
                      │
                      ▼
            ┌─────────────────┐
            │ ¿Cada cuánto    │
            │ cambian tus     │
            │ datos?          │
            └───────┬─────────┘
                    │
         ┌──────────┼──────────┐
         ▼          ▼          ▼
      Diario/    Mensual/   Rara vez/
      Semanal    Trimestral  Nunca
         │          │          │
         ▼          ▼          ▼
   ┌───────────┐  ┌──────┐  ┌───────────────┐
   │ RAG       │  │ ¿Qué │  │ ¿Qué importa │
   │ (búsqueda │  │ tan  │  │ más?          │
   │ dinámica) │  │grande?│  └──────┬────────┘
   └───────────┘  └──┬───┘         │
                     │        ┌────┼─────┐
              ┌──────┼──────┐ ▼    ▼     ▼
              ▼      ▼      ▼ Conocim. Comportam.
           < 500K  500K-5M  > 5M │      │
           tokens  tokens   tokens▼      ▼
              │      │       │   RAG  Fine-Tune
              ▼      ▼       ▼
          Contexto  RAG     RAG
          Largo     o       (única
                   Híbrido  opción)

Matriz de Comparación

Patrones de Arquitectura del Mundo Real

Patrón 1: RAG (Dinámico) + Fine-Tuning (Comportamiento) = Híbrido

El patrón más poderoso. Fine-tune para cómo se comporta el modelo, RAG para qué sabe.

Ejemplo: Un chatbot de salud fine-tuneado para seguir guías de comunicación clínica mientras usa RAG para acceder a la literatura médica más reciente.

Patrón 2: Contexto Largo para Prototipo → RAG para Producción

Arrancá con contexto largo para validar tu enfoque, después migrá a RAG cuando necesites escalar.

Patrón 3: Arquitectura por Tiers

Usá las tres en un solo sistema, ruteando queries al enfoque más eficiente:

async function routeQuery(query: string, queryType: string) {
  switch (queryType) {
    case "factual_lookup":
      // Búsqueda de hechos simple: RAG es lo más barato
      return await ragPipeline(query);
    case "complex_analysis":
      // Necesita razonamiento cruzado: contexto largo
      return await longContextAnalysis(query);
    case "formatted_report":
      // Necesita formato específico: modelo fine-tuneado + RAG
      return await fineTunedWithRAG(query);
    default:
      return await ragPipeline(query);
  }
}

Patrón 4: RAG Agéntico

La evolución 2026 de RAG donde un agente de IA decide dinámicamente cómo buscar, de qué fuentes, y si hace búsqueda multi-paso:

import { ChatOpenAI } from "@langchain/openai";
import { createReactAgent } from "@langchain/langgraph/prebuilt";

const tools = [
  vectorSearchTool,     // Buscar en vector DB
  sqlQueryTool,         // Consultar base estructurada
  webSearchTool,        // Buscar info actual en la web
  graphTraversalTool,   // Navegar knowledge graph
  calculatorTool,       // Hacer cálculos
];

const agent = createReactAgent({
  llm: new ChatOpenAI({ model: "gpt-4.1" }),
  tools,
  messageModifier: `Sos un agente de investigación. Para cada consulta:
    1. Decidí qué herramientas usar según el tipo de pregunta
    2. Si es necesario, buscá información en múltiples fuentes
    3. Verificá cruzando los hallazgos
    4. Sintetizá una respuesta completa con citas`,
});

Errores Comunes

Error 1: Usar RAG para Todo

RAG se convirtió en la opción "segura", pero no siempre es la correcta. Si tu dataset son 50 páginas de documentación estable y recibís 100 queries por día, contexto largo es más simple, más barato, y muchas veces más preciso.

Regla: Si tus datos entran en una ventana de contexto y cambian menos de una vez por mes, arrancá con contexto largo.

Error 2: Fine-Tunear Cuando Necesitás RAG

"Nuestro modelo no sabe de nuestros productos" → Esto es un problema de conocimiento, no de comportamiento. RAG lo resuelve.

Regla: Si el problema es "el modelo no sabe X", usá RAG. Si el problema es "el modelo no habla/piensa como X", usá fine-tuning.

Error 3: Ignorar el Problema "Lost in the Middle"

Las ventanas de contexto largo son impresionantes, pero los modelos todavía luchan con la recuperación de información del medio de contextos muy largos.

Error 4: Over-Engineering de RAG

Tu pipeline RAG no necesita GraphRAG, búsqueda agéntica, HyDE, expansión multi-query y un reranker el día uno. Arrancá con búsqueda vectorial básica. Medí la calidad de búsqueda. Agregá complejidad solo cuando los datos muestren que ayuda.

Error 5: No Medir Calidad de Búsqueda

La falla RAG más común no es el LLM, es la mala búsqueda. Si no estás midiendo recall@k y precision@k, estás volando a ciegas.

def evaluate_retrieval(test_queries, ground_truth_docs, retriever, k=5):
    recalls = []
    for query, expected_doc_ids in zip(test_queries, ground_truth_docs):
        retrieved = retriever.retrieve(query, k=k)
        retrieved_ids = {doc.id for doc in retrieved}
        expected_ids = set(expected_doc_ids)
        recall = len(retrieved_ids & expected_ids) / len(expected_ids)
        recalls.append(recall)
    avg_recall = sum(recalls) / len(recalls)
    print(f"Recall@{k}: {avg_recall:.2%}")
    return avg_recall

La Matemática de Costos: Un Ejemplo Concreto

Comparemos costos para un escenario concreto: un bot de soporte atendiendo 50,000 queries/mes contra una base de 10,000 artículos FAQ (~2M tokens total).

Opción A: RAG

Opción B: Fine-Tuning + RAG (Híbrido)

Opción C: Contexto Largo

El veredicto es claro para este escenario: RAG gana por un margen de 100x a escala. Pero para un prototipo con 50 queries/día? Contexto largo cuesta ~$60/mes y requiere cero setup.

La lección: siempre hacé la matemática de costos para tu escala específica antes de comprometerte con una arquitectura.

El Panorama 2026: Qué Cambió

Tres cambios mayores están reformando esta decisión:

1. Las Ventanas de Contexto Siguen Creciendo

La ventana de 10M tokens de Llama 4 Scout sugiere que vamos hacia modelos que pueden contener codebases enteros o bibliotecas de documentos completas. Esto no mata a RAG, pero achica los casos donde RAG es estrictamente necesario. A medida que los modelos manejan más contexto de forma nativa, la pregunta cambia de "¿puedo meter todo en contexto?" a "¿debería?", y la respuesta depende del costo y la latencia.

2. El Auge del RAG Agéntico

Los pipelines estáticos de búsqueda-generación están evolucionando a sistemas agénticos que deciden autónomamente cómo buscar, de dónde, y si hacer búsqueda multi-paso. Esto combina la precisión de RAG con la flexibilidad de agentes, y es una de las tendencias más importantes en AI engineering.

3. Fine-Tuning Es Cada Vez Más Barato y Rápido

Técnicas como LoRA (Low-Rank Adaptation) y QLoRA recortaron drásticamente los costos de fine-tuning. Podés fine-tunear un modelo de 70B parámetros en una sola GPU en horas. Esto hace que el caso de uso "conocimiento estable + comportamiento" sea cada vez más atractivo comparado con pipelines RAG complejos.

4. RAFT (Retrieval-Augmented Fine-Tuning)

El enfoque híbrido de fine-tunear un modelo específicamente para trabajar bien con contexto recuperado emerge como un patrón poderoso. El modelo aprende a extraer información relevante de chunks ruidosos y a ignorar lo irrelevante, combinando las fortalezas de ambos enfoques. RAFT es especialmente prometedor para escenarios donde necesitás tanto precisión de recuperación como calidad de output.

Conclusión

No hay un enfoque universalmente "mejor." La arquitectura correcta depende de tus datos, tu escala, tus requisitos de latencia y las capacidades de tu equipo.

La hoja de referencia:

¿Los datos cambian seguido? → RAG

¿Necesitás cambiar cómo se comporta el modelo? → Fine-tuning

¿Dataset chico, lo necesitás ya? → Contexto largo

¿Mejor calidad a escala? → Modelo fine-tuneado + RAG

¿Prototipando? → Contexto largo → migrá a RAG cuando funcione

Dejá de tratar esto como un debate religioso. Hacé la matemática de costos para tu escala. Medí la calidad de búsqueda. Arrancá simple. Agregá complejidad cuando los datos te lo pidan.

Los ingenieros que están armando las mejores apps con LLM en 2026 no son los que tienen los pipelines más sofisticados. Son los que eligieron el enfoque correcto para su problema específico y lo ejecutaron bien.