Fine-tuning, RAG o prompting: elige mal y pierdes meses

Hay una decisión que los equipos que empiezan con agentes IA toman mal con una frecuencia alarmante: eligen la arquitectura de adaptación del modelo antes de entender qué problema tienen.

Algunos empiezan con fine-tuning porque creen que "personalizar el modelo" es lo correcto. Otros van directos a RAG porque "necesitan que el agente conozca nuestros documentos". Muy pocos se preguntan si con prompting bien construido ya basta.

El resultado es siempre el mismo: semanas de trabajo, varios miles de euros y un sistema que no funciona notablemente mejor de lo que funcionaría con una solución más simple.

Este artículo es la guía que debería existir antes de tomar esa decisión.

Tres enfoques, tres contextos distintos

Prompting (in-context learning y few-shot) es usar el modelo tal como está, dándole instrucciones y ejemplos en el propio contexto de la llamada. No modificas nada del modelo. Solo le hablas mejor.

RAG (Retrieval-Augmented Generation) conecta el modelo a una base de conocimiento externa — un vector store, una base de datos, documentos — que recupera información relevante en tiempo real antes de generar la respuesta. El modelo no cambia; cambia lo que sabe en el momento de responder.

Fine-tuning reentrenar el modelo con ejemplos específicos de tu caso de uso. El modelo aprende nuevos patrones y comportamientos. El resultado es un modelo modificado que puedes desplegar como si fuera el base.

Ninguno es superior a los otros en términos absolutos. Son respuestas a problemas distintos, con costes y complejidades distintas. El error está en aplicar la solución más sofisticada sin haber comprobado si la más simple funciona.

Cuándo el prompting es suficiente (y por qué la mayoría lo abandona antes de tiempo)

La mayoría de los agentes que vemos en producción con problemas de comportamiento los tienen por prompts mal construidos, no por limitaciones del modelo base.

Un modelo como Claude Sonnet o GPT-4o bien guiado puede:

• Clasificar documentos con alta precisión si le das ejemplos claros en el prompt
• Responder preguntas sobre un dominio específico si le das el contexto correcto
• Generar outputs estructurados en JSON si usas una instrucción precisa y un schema explícito
• Seguir flujos de toma de decisiones complejos si los describes con claridad

El límite del prompting no es la calidad de la respuesta: es el context window. Si tu agente necesita procesar o recordar más información de la que cabe en una ventana de contexto (típicamente 128k-200k tokens), el prompting puro no escala.

// Ejemplo: agente clasificador con few-shot en TypeScript
const systemPrompt = `Eres un clasificador de tickets de soporte.
Categorías válidas: BILLING, TECHNICAL, ACCOUNT, OTHER.

Ejemplos:
Input: "No puedo acceder a mi cuenta desde ayer"
Output: { "category": "ACCOUNT", "priority": "HIGH" }

Input: "¿Cuándo se renueva mi plan?"
Output: { "category": "BILLING", "priority": "LOW" }

Devuelve siempre JSON válido con category y priority.`;

const response = await anthropic.messages.create({
  model: "claude-sonnet-5",
  max_tokens: 200,
  system: systemPrompt,
  messages: [{ role: "user", content: ticketText }]
});

Cuándo escalar a otra solución: cuando necesitas que el agente conozca información que no cabe en el prompt (documentación extensa, histórico de clientes, catálogos de productos) o cuando el conocimiento cambia frecuentemente.

Cuándo usar RAG — y el error de chunking que lo rompe todo

RAG es la respuesta correcta cuando el agente necesita acceder a conocimiento que no cabe en el contexto o que se actualiza con frecuencia. Ejemplos reales:

• Un agente de soporte que responde basándose en tu documentación interna de 2.000 páginas
• Un asistente que conoce el histórico de interacciones con cada cliente
• Un agente comercial que consulta el catálogo de productos actualizado en tiempo real

La implementación estándar en TypeScript con Supabase y pgvector:

// Función de recuperación semántica con reranking simple
async function retrieveContext(query: string, topK = 5): Promise<string> {
  const embedding = await generateEmbedding(query);

  const { data: chunks } = await supabase.rpc("match_documents", {
    query_embedding: embedding,
    match_threshold: 0.75,
    match_count: topK * 2  // recupera más para luego filtrar
  });

  // Reranking básico por relevancia léxica
  const reranked = chunks
    .map(chunk => ({
      ...chunk,
      score: chunk.similarity + keywordOverlapScore(query, chunk.content)
    }))
    .sort((a, b) => b.score - a.score)
    .slice(0, topK);

  return reranked.map(c => c.content).join("\n\n---\n\n");
}

El error que nadie menciona: el chunking. La mayoría de equipos hace chunking por tamaño fijo (cada 500 tokens) sin respetar la estructura semántica del documento. El resultado: chunks que cortan en mitad de un argumento, pierden contexto y generan respuestas parciales o incorrectas.

La regla práctica: chunking por sección semántica (párrafos, secciones H2, pasos numerados) con overlap del 10-15% entre chunks consecutivos. Si tienes documentos técnicos, añade los metadatos (título de sección, número de página) al inicio de cada chunk.

La arquitectura de RAG en producción es mucho más delicada de lo que parece en los tutoriales: chunking, embedding, retrieval, reranking y context assembly son cinco puntos de fallo independientes que hay que calibrar juntos.

Fine-tuning: cuándo tiene sentido y cuándo es un error caro

Fine-tuning es la opción correcta en un conjunto de casos bastante más estrecho de lo que se suele pensar:

• El modelo necesita adoptar un estilo de escritura o tono muy específico que no se puede replicar con instrucciones en el prompt
• Tienes miles de ejemplos etiquetados de inputs/outputs correctos para tu caso de uso
• El comportamiento que necesitas es consistentemente diferente del comportamiento por defecto del modelo base
• El coste de inferencia es crítico y necesitas un modelo más pequeño que se comporte como uno grande para tu tarea específica

Lo que fine-tuning no resuelve:

• Que el modelo sepa cosas que no están en su training data (para eso está RAG)
• Que el modelo sea más preciso en datos que cambian (el fine-tune es estático)
• Que el modelo no alucine (el fine-tuning puede reducirlo, pero no eliminarlo)

El coste real de un fine-tuning bien hecho incluye: preparación y limpieza del dataset, iteraciones de entrenamiento, evaluación contra un benchmark propio, y el mantenimiento cuando el modelo base cambia de versión o cuando tu tarea evoluciona. Antes de empezar, pregúntate si prompting + RAG no llega al mismo resultado con un 10% del esfuerzo.

// Cuándo usar cada uno — árbol de decisión en código
type LLMStrategy = "prompting" | "rag" | "fine-tuning";

function selectStrategy(requirements: {
  knowledgeSize: "small" | "medium" | "large";
  knowledgeChanges: boolean;
  dataAvailable: number; // ejemplos etiquetados
  behaviorIsSpecific: boolean;
}): LLMStrategy {
  const { knowledgeSize, knowledgeChanges, dataAvailable, behaviorIsSpecific } = requirements;

  // Primero intenta siempre prompting
  if (knowledgeSize === "small" && !knowledgeChanges) return "prompting";

  // Si el conocimiento es grande o cambia, RAG
  if (knowledgeSize === "large" || knowledgeChanges) return "rag";

  // Fine-tuning solo si RAG+prompting no da el comportamiento específico
  // y tienes datos suficientes
  if (behaviorIsSpecific && dataAvailable > 1000) return "fine-tuning";

  // Por defecto, RAG resuelve más casos que el fine-tuning
  return "rag";
}

El patrón correcto: escalada progresiva

La arquitectura que funciona en producción no es elegir uno de los tres enfoques: es empezar por el más simple y escalar solo cuando hay evidencia de que no llega.

1. Primero: prompting — construye el agente con few-shot y un system prompt preciso. Mide calidad con casos de prueba reales.
2. Si el contexto no alcanza: añade RAG — conecta el vector store a los documentos o datos que el agente necesita. No reemplaza el prompting: lo complementa.
3. Si el comportamiento sigue siendo insuficiente tras iterar: evalúa fine-tuning — con un dataset de al menos 500-1000 ejemplos, un conjunto de evaluación separado y métricas claras de éxito.

En los proyectos de integración de IA con agentes de automatización que implementamos, más del 70% de los casos se resuelven con prompting bien construido + RAG. Fine-tuning es raro, y cuando aparece es porque el caso de uso es muy específico y el volumen de datos lo justifica.

Resultados reales

El error más caro que hemos visto en equipos que llegan a nosotros: seis semanas de fine-tuning para un agente de soporte que respondía mal. El problema real era el chunking de la documentación y un system prompt ambiguo. Prompting mejorado + RAG con chunking correcto → 92% de precisión en dos días de trabajo.

No porque el fine-tuning sea malo. Sino porque no era la herramienta correcta para ese problema.

La decisión de arquitectura es deuda técnica antes de escribir código

Elegir la arquitectura incorrecta no es solo un problema técnico: es deuda que se acumula. Un sistema construido sobre fine-tuning cuando RAG era suficiente necesita reentrenamiento cada vez que el conocimiento cambia. Un sistema en RAG cuando prompting bastaba tiene complejidad operativa innecesaria.

La evaluación correcta toma un día. El coste de elegir mal puede ser un mes.

Si estás diseñando la arquitectura de tu agente IA y quieres que alguien con experiencia real en producción lo revise antes de comprometer semanas de trabajo, cuéntanos el caso.

Revisamos tu arquitectura antes de que empieces →