¿Qué es RAG en términos simples?

RAG (Retrieval-Augmented Generation) es un patrón donde antes de llamar al modelo, buscás los documentos relevantes en una base vectorial y los inyectás en el prompt como contexto. El modelo no aprende nada nuevo: simplemente recibe la información correcta justo cuando la necesita. Es como darle a un becario inteligente el manual abierto en la página justa antes de cada pregunta del cliente.

¿Qué es fine-tuning y cuándo conviene?

Fine-tuning es entrenar al modelo base con ejemplos tuyos para que cambie su comportamiento. Conviene cuando necesitás que responda en un formato muy específico (siempre JSON con campos X). Un tono particular de marca, o cuando hacés millones de inferencias y el costo de tokens de contexto en RAG pesa. No conviene para meter conocimiento, para eso siempre gana RAG.

¿Cuánto cuesta cada uno?

RAG: USD 0 de entrenamiento, USD 0.10 a 0.50 por embedding inicial del corpus, USD 0.0002 a 0.005 por query según modelo (gpt-4o-mini vs gpt-4o). Fine-tuning con OpenAI: USD 25 a 100 de entrenamiento para datasets pequeños, USD 12 por millón de tokens de input al inferir. Para corpus medianos, RAG sale entre 3 y 8 veces más barato en el primer año.

¿Cuál es más rápido de implementar?

RAG. Un primer prototipo funcional con pgvector + OpenAI embeddings + un chunker decente tarda 2 a 4 días. Fine-tuning bien hecho lleva 1 a 3 semanas: necesitás dataset de calidad (mínimo 200 ejemplos curados), iteración de hiperparámetros, evaluación, y un loop de retraining cuando los datos cambian. Por eso casi siempre arranco con RAG y solo paso a fine-tuning si los resultados lo piden.

¿Se pueden combinar RAG y fine-tuning?

Sí, y a veces conviene. El fine-tuning ajusta el formato y tono; el RAG mete el conocimiento actualizado. Patrón típico: fine-tunear un modelo chico (gpt-4o-mini) para que responda siempre en formato estructurado y tono de marca, y usar RAG por encima para inyectar el contenido específico de cada cliente. Es una v3, no empieces por ahí.

¿Y los modelos open-source como Llama o Mistral?

Para v1 de un MVP, casi nunca. Auto-alojar suma costos de GPU, ops, latencia y testing. Los modelos cerrados (gpt-4o-mini, claude-haiku) son más baratos por token, mejores en calidad y no requieren infra. Open-source gana cuando tenés requisitos de privacidad on-prem, volumen masivo que paga la GPU dedicada, o necesidad de fine-tuning profundo. Decisión de v2 o v3, no de v1.

RAG vs fine-tuning para chatbots: cuál elegir en 2026

Por Ignacio (IGNAX) · Publicado 2026-05-27 · Actualizado 2026-05-27 · 6 min de lectura

La pregunta llega cada vez que un cliente quiere un chatbot que conozca su negocio: ¿RAG o fine-tuning? La respuesta corta es RAG, casi siempre. La útil necesita entender qué hace cada técnica, cuánto cuesta y cuándo se justifica saltar al fine-tuning. Construí chatbots con RAG para varios proyectos de soporte (KB pública, KB privada por cliente, híbrido con tools) y todos arrancaron con RAG puro; solo uno terminó incluyendo fine-tuning, y nada más que para forzar formato estructurado en la respuesta.

¿Qué hace exactamente RAG bajo el capó?

El patrón funciona en tres pasos:

Indexación (una vez, después cada vez que el corpus cambia). Partís los documentos en chunks (típicamente 300 a 800 tokens), generás un embedding por chunk con un modelo como text-embedding-3-small, y los guardás en una base vectorial.
Retrieval (cada query del usuario). Convertís la pregunta del usuario en embedding, buscás los k chunks más similares (típicamente k=4 a 8).
Generación. Le pasás esos chunks al modelo como contexto, junto con la pregunta original y el system prompt.

# Ejemplo simplificado de RAG con pgvector + OpenAI
from openai import OpenAI
import psycopg

client = OpenAI()
conn = psycopg.connect(DATABASE_URL)

def answer(question: str) -> str:
    # 1. Embedding de la pregunta
    q_emb = client.embeddings.create(
        model="text-embedding-3-small",
        input=question
    ).data[0].embedding

    # 2. Retrieval, top 5 chunks más similares
    with conn.cursor() as cur:
        cur.execute(
            "SELECT content FROM kb_chunks ORDER BY embedding <-> %s LIMIT 5",
            (q_emb,)
        )
        chunks = [r[0] for r in cur.fetchall()]

    # 3. Generación con contexto
    context = "\n\n".join(chunks)
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "Respondé solo con info del CONTEXTO. Si no está, decí que no sabés."},
            {"role": "user", "content": f"CONTEXTO:\n{context}\n\nPREGUNTA: {question}"}
        ],
        temperature=0.1,
    )
    return resp.choices[0].message.content

Esto es ~30 líneas. En producción se le suma reranking, caching, citation tracking y observabilidad, pero el corazón es esto. Matriz de decisión RAG vs fine-tuning comparando costo, latencia, frescura y precisión en cuadrantes

¿Qué hace exactamente fine-tuning?

Fine-tuning toma un modelo base y lo reentrena con ejemplos tuyos en formato (prompt, completion). El modelo ajusta sus pesos internos para reproducir el patrón. Después de fine-tunear:

El modelo "sabe" responder en cierto formato sin que se lo expliques cada vez.
Podés usar prompts más cortos (ahorra tokens en inferencia).
El conocimiento general del modelo base se preserva, no es "aprender desde cero", es ajustar.

Ejemplo: fine-tunear gpt-4o-mini con 300 pares (consulta_cliente, respuesta_soporte_de_marca) para que tu chatbot responda con tono de marca consistente, sin tener que escribir un system prompt de 800 palabras en cada llamada.

Lo que fine-tuning no hace bien:

Memorizar facts específicos (qué dice el manual del producto X versión 4.2).
Adaptarse a contenido que cambia semanal o mensualmente.
Citarte la fuente de donde sacó la respuesta.

Eso último es clave para soporte: si el bot dice "su garantía es de 12 meses" pero el contrato dice 6, querés saber de dónde sacó esa info. RAG te da la cita; fine-tuning te da una respuesta sin fuente. La misma lógica de citación con fuentes la explico desde el lado del SEO en qué es AEO.

¿En qué se diferencian en la práctica?

Tabla rápida comparativa:

Dimensión	RAG	Fine-tuning
Tiempo de implementación	2 a 4 días	1 a 3 semanas
Costo inicial	USD 0 a 50 (embeddings del corpus)	USD 25 a 500 (training jobs)
Costo por query	Más alto (contexto largo)	Más bajo (prompt corto)
Actualizar conocimiento	Reindexar (minutos)	Reentrenar (horas + dataset nuevo)
Citas de fuente	Sí, nativo	No, hay que inventar workaround
Cambio de tono/formato	Cuesta más	Es para lo que sirve
Debuggeabilidad	Alta (ves los chunks recuperados)	Baja (caja negra)
Privacidad	Datos en tu DB, embeddings en API	Datos enviados a OpenAI/Anthropic

La columna "debuggeabilidad" suele decidirlo. Cuando un cliente reclama que el bot dio una respuesta mala, en RAG abrís el log, ves qué chunks recuperó, y entendés en 2 minutos si el problema fue retrieval o generación. En fine-tuning. La respuesta vino de un modelo opaco, no sabés por qué dijo lo que dijo.

¿Cuándo conviene RAG?

RAG es la default para:

Chatbots de soporte sobre KB de la empresa. Manuales, FAQs, documentación de producto, políticas internas.
Bots de research over corpus. Q&A sobre papers, reportes financieros, contratos legales.
Asistentes que necesitan citar fuentes. Legal, médico, educativo.
Productos donde el conocimiento cambia rápido. Catálogo de productos, precios, disponibilidad.
Multi-tenant con datos aislados por cliente. Cada workspace tiene su propio corpus indexado.

Si tu caso de uso cae en cualquiera de los anteriores, empezá con RAG y no mires fine-tuning hasta que tengas un problema concreto que RAG no resuelve.

¿Cuándo conviene fine-tuning?

Fine-tuning gana en estos casos:

Formato de salida muy estricto. Necesitás siempre JSON con cierta estructura, y los prompts complejos no rinden 100%.
Tono de marca muy específico. Una vez que el chatbot responde en producción miles de veces por día. El tono inconsistente se nota.
Volumen masivo de inferencia. Si hacés 10 millones de queries/mes. El ahorro en tokens de prompt corto se paga el costo de fine-tuning fácil.
Tareas no-conversacionales. Clasificación, extracción de entidades, generación de SQL desde texto natural. Acá fine-tuning de modelos chicos puede superar a GPT-4 con prompt elaborado.

Detalle importante: fine-tuning sin un buen dataset es plata tirada. Necesitás mínimo 200 ejemplos curados a mano, idealmente 500 a 2.000, y un set de validación separado. Si no tenés ese dataset, primero generalo (manual + asistido por modelo grande), después fine-tuneás.

La documentación oficial de OpenAI sobre fine-tuning y la guía de Anthropic sobre patrones de retrieval son las referencias que mando más seguido.

¿Qué stack uso yo para RAG en producción?

Mi default para chatbots RAG en 2026:

Vector DB: pgvector sobre la misma Postgres que usa la app. Hasta ~1 millón de vectores rinde bien. Por encima, evalúo Qdrant o Pinecone, pero no antes.
Embeddings: text-embedding-3-small de OpenAI (1536 dims, USD 0.02 por millón de tokens). Para multilingual conviene text-embedding-3-large o BGE-M3.
Chunker: semántico con overlap del 15%. Tamaño 400 tokens default, ajustable por tipo de documento.
Retrieval: top-k=8 con un reranker (Cohere Rerank o un cross-encoder local) que reduce a top-4 antes de generar. El reranker mejora la calidad un 15-25% sin costo prohibitivo.
Generación: gpt-4o-mini para 80% de queries, gpt-4o para queries marcadas como críticas. claude-haiku también es válido y más barato en algunos volúmenes.
Caching: hash de la pregunta + corpus version → respuesta. Redis o Cloudflare KV.

Construí este stack para varios proyectos (mirá el caso de chatbots de soporte con IA si querés ver una implementación real). Es lo bastante simple para mantener solo y lo bastante robusto para producción.

¿Cómo decidir en tu caso concreto?

Respondé estas tres preguntas en 5 minutos:

¿El conocimiento que el bot necesita cambia más rápido que mensual? Sí → RAG. No → cualquiera.
¿Necesitás citar fuentes? Sí → RAG. No → cualquiera.
¿El formato/tono de salida es más importante que el contenido? Sí → fine-tuning eventualmente. No → RAG.

Si dos de tres dieron RAG, no pierdas tiempo evaluando fine-tuning para v1. Lo construís en una semana, lo subís a producción, y si en tres meses descubrís que el formato es inconsistente, ahí evaluás un fine-tune. Para los rangos de costo del MVP completo donde encaja el chatbot, mirá cuánto cuesta un SaaS MVP.

Si querés discutir tu caso específico, escribime a [email protected] con una descripción del corpus. El volumen estimado y qué tipo de respuestas esperás del bot. En 30 minutos te digo si conviene RAG, fine-tuning, o ninguno de los dos. Mirá también cómo crear un MVP rápido con IA para entender cómo encaja esto en un MVP completo.