La pregunta llega casi siempre en el mismo momento: un equipo terminó su primer prototipo con GPT-4, funciona bien en demo, y alguien pregunta “¿no deberíamos entrenar nuestro propio modelo con nuestros datos?”.
La intuición tiene sentido. Pero en la mayoría de los casos, es la decisión equivocada.
Qué es cada cosa
RAG (Retrieval Augmented Generation) es una arquitectura donde el modelo base (sin modificar) recibe contexto relevante en el prompt antes de responder. El “retrieval” es una búsqueda semántica sobre una base de conocimiento propia.
Fine-tuning es reentrenar parcialmente un modelo base con tus propios datos para que aprenda un estilo, un formato, o conocimiento específico.
Por qué RAG gana casi siempre
RAG y fine-tuning no son mutuamente excluyentes. Pero si tenés que elegir uno para empezar, elegí RAG el 95% de las veces.
1. El conocimiento cambia
Tu documentación, tus precios, tus productos — cambian. RAG se actualiza en tiempo real: modificás el documento fuente, el sistema ya responde diferente en segundos.
Con fine-tuning, cada cambio implica un ciclo de reentrenamiento que puede durar días y costar miles de dólares.
2. Fine-tuning no inyecta conocimiento factual
Este es el error más común. Fine-tuning sirve para cambiar cómo responde el modelo, no qué sabe.
Si entrenás un modelo con tu documentación de producto, no estás “enseñándole” los hechos. Estás ajustando el estilo. El modelo igual puede alucinar sobre tu producto. RAG, en cambio, le entrega el texto exacto antes de que responda.
3. Costo y tiempo
Los números son orientativos, pero el delta es real. Para la mayoría de las empresas, el ROI de fine-tuning no justifica el costo en las etapas tempranas.
Cuándo fine-tuning tiene sentido
No es que fine-tuning sea malo. Tiene casos de uso legítimos:
- Formato muy específico: si necesitás que el modelo siempre responda en un JSON con estructura exacta, o en un tono corporativo muy particular.
- Latencia crítica: prompts más cortos = respuestas más rápidas. Si el contexto de RAG agrega 10k tokens y necesitás respuestas en < 500ms, fine-tuning puede ayudar.
- Tareas muy acotadas: clasificación de texto en categorías fijas, extracción de entidades en un dominio muy específico.
Si tu razón para hacer fine-tuning es “que el modelo sepa de nuestra empresa”, RAG es lo que necesitás.
La arquitectura que usamos
En Iridia, el stack estándar para un sistema RAG en producción es:
- Chunking inteligente del documento fuente (no solo split por tokens)
- Embeddings con
text-embedding-3-smallde OpenAI o modelos open-source - Vector store — Supabase (pgvector) para la mayoría de los casos, Pinecone si la escala lo requiere
- Reranking para mejorar la precisión antes de enviar al LLM
- LLM con prompt estructurado + contexto recuperado
Este stack es deployable en una semana y escala hasta millones de documentos sin cambiar la arquitectura.
Si estás evaluando qué arquitectura usar para tu caso, hablemos. En 30 minutos podemos darte una respuesta concreta.