RAG (Retrieval-Augmented Generation) es una técnica que inyecta datos externos al contexto del LLM en tiempo real, ideal cuando la información cambia frecuentemente; mientras que fine-tuning modifica los pesos del modelo para alterar su comportamiento, tono o formato de salida. Usa RAG para conocimiento dinámico y fine-tuning para cambiar cómo responde el modelo. En nodo. hemos implementado ambas en producción para empresas chilenas.
En nodo. hemos implementado ambas técnicas en producción: RAG con pgvector para búsqueda semántica en CRM, RAG con Amazon Bedrock Knowledge Bases para NLQ (Natural Language Queries) sobre BI, y fine-tuning para adaptar modelos a dominios especializados como compliance legal chileno. Este artículo entrega un framework de decisión basado en esa experiencia.
¿Cuándo conviene usar RAG en lugar de fine-tuning?
RAG es la opción correcta cuando el conocimiento que necesita el modelo es dinámico, propietario o demasiado extenso para caber en un prompt. En términos prácticos, funciona cuando se cumplen estas condiciones:
- Los datos cambian frecuentemente (precios, inventario, tickets de soporte, documentos legales actualizados)
- Necesitas citar fuentes y mostrar de dónde viene la información
- El corpus es grande (más de lo que cabe en el context window del modelo)
- La precisión factual es crítica y las alucinaciones tienen costo real
Ejemplo real: CRM conversacional con pgvector
Para un cliente de nodo., construimos un bot de WhatsApp que responde preguntas sobre el historial del cliente. La base: PostgreSQL con la extensión pgvector, embeddings generados con el modelo text-embedding-3-small de OpenAI (1536 dimensiones, USD $0.02/1M tokens), y Claude Sonnet como modelo de generación.
El pipeline: la pregunta del usuario se convierte en embedding, se buscan los 5 documentos más similares con distancia coseno (threshold 0.75), y se inyectan al prompt de Claude con instrucciones de citar el documento fuente. Latencia promedio: 1.2 segundos end-to-end. Costo: USD $0.003 por query. En nuestra experiencia, RAG con pgvector reduce el costo de contexto en un ~60% vs enviar documentos completos al modelo, porque solo inyecta los chunks relevantes en lugar del corpus entero.
¿Cuándo es mejor fine-tuning que RAG?
Fine-tuning es la opción correcta cuando necesitas cambiar cómo el modelo se comporta, no qué información tiene. Los casos más claros:
- Tono y estilo específicos (vocabulario técnico de un sector, jerga chilena, formalidad legal)
- Formato de output consistente (el modelo debe generar JSON con estructura exacta el 100% del tiempo)
- Reducción de latencia y costos (un modelo pequeño fine-tuned puede reemplazar un modelo grande con prompt largo)
- Razonamiento domain-specific que el modelo base no hace bien
Ejemplo real: clasificación de documentos legales
Para el sistema de compliance de nodo., necesitábamos clasificar documentos en 23 categorías del derecho chileno. Con Claude Sonnet y un prompt detallado, la precisión era 87%. Con fine-tuning de GPT-4o mini sobre 2,400 ejemplos etiquetados, la precisión subió a 96% y el costo por clasificación bajó de USD $0.008 a $0.0004 (20x más barato). Según benchmarks internos, el modelo fine-tuned procesa cada documento en ~200ms vs ~1.8s del modelo grande con prompt largo, una reducción de latencia del 89%.
¿Por qué falla RAG cuando necesitas cambiar el comportamiento del modelo?
El error más común. Síntomas: el modelo recupera documentos relevantes pero genera respuestas en un formato incorrecto, con un tono inadecuado o sin seguir las reglas del dominio. Inyectar más contexto no resuelve un problema de comportamiento.
Un caso que vimos: un equipo tenía un chatbot legal que usaba RAG para inyectar artículos del Código del Trabajo chileno. El retrieval funcionaba bien, los artículos correctos llegaban al contexto. Pero el modelo respondía en un tono coloquial inapropiado para comunicación legal y no formateaba las citas según la convención jurídica chilena. La solución no era más RAG, sino fine-tuning del modelo para el dominio legal.
¿Por qué falla fine-tuning cuando necesitas acceso a datos actualizados?
Fine-tuning no es una base de datos. Los datos usados en fine-tuning quedan "horneados" en los pesos del modelo y no se actualizan sin re-entrenar. Si tus datos cambian semanalmente, fine-tuning te da un modelo que alucina con información desactualizada.
Además, fine-tuning tiene costo fijo alto: según el pricing público de OpenAI, fine-tuning de GPT-4o mini cuesta USD $3.00 por 1M tokens de training, lo que para un dataset de 2,400 ejemplos equivale a USD $30-50 por entrenamiento, y toma 2-4 horas. Con Claude se usa prompt engineering avanzado. Con Gemini, Google ofrece tuning vía Vertex AI desde USD $3/hora.
¿Cómo decidir entre RAG y fine-tuning para tu caso?
Esta tabla resume cuándo usar cada enfoque basado en las características del problema:
| Criterio | RAG | Fine-tuning | Ambos |
|---|---|---|---|
| Datos cambian semanalmente | Sí | No | - |
| Necesitas citar fuentes | Sí | No | - |
| Tono/estilo específico | No | Sí | - |
| Formato de output estricto | No | Sí | - |
| Datos propietarios + estilo | - | - | Sí |
| Reducir costos por query | Parcial | Sí | - |
| Corpus > 100K documentos | Sí | No | - |
¿Cuándo no necesitas ni RAG ni fine-tuning?
A veces la respuesta correcta no es RAG ni fine-tuning. Si tu caso de uso se resuelve con un prompt bien estructurado y el context window del modelo (200K tokens en Claude, 128K en GPT-4o, 2M en Gemini), no necesitas infraestructura adicional. En nuestra experiencia en nodo., estimamos que el 40% de los proyectos que nos consultan sobre RAG se resuelven con prompt engineering y tool calling.
La regla: empieza con el prompt más simple que funcione. Agrega RAG solo cuando necesites conocimiento externo dinámico. Agrega fine-tuning solo cuando necesites cambiar el comportamiento base del modelo. Y si necesitas ambos, implementa RAG primero porque es reversible y más rápido de iterar.
¿Cuál es el stack recomendado para RAG en 2026?
RAG rápido: pgvector en PostgreSQL (si ya usas Postgres), Pinecone o Weaviate para escala. Embeddings con text-embedding-3-small. Modelo de generación: Claude Sonnet 4 o GPT-4o.
RAG enterprise: Amazon Bedrock Knowledge Bases (integración nativa con S3, Aurora, OpenSearch). Google Vertex AI Search para ecosistemas GCP.
Fine-tuning: GPT-4o mini para clasificación y extracción. Gemini vía Vertex AI para ecosistemas Google. Modelos open source (Llama 3.1, Mistral) en GPU propia para máximo control.
Evaluación: RAGAS para métricas de RAG (faithfulness, answer relevancy). Datasets de regresión custom de 200+ casos para fine-tuning.
¿RAG o fine-tuning: cuál elegir en 2026?
RAG y fine-tuning resuelven problemas fundamentalmente distintos. RAG extiende el conocimiento del modelo. Fine-tuning modifica su comportamiento. La elección correcta depende de si tu problema es de información o de capacidad, y la mayoría de los equipos fallan porque no hacen esta distinción antes de elegir.
En nodo. ayudamos a empresas a tomar esta decisión con datos, no con intuición. Si estás evaluando cómo integrar IA con tus datos propietarios, podemos hacer un PoC funcional en 24 horas para validar el enfoque correcto.