El cliente dice: "Queremos subir nuestra documentación corporativa a GPT-5 / Claude / Llama, para que responda a las preguntas de nuestros empleados / clientes / partners". Una mitad imagina fine-tuning, otra mitad RAG, y una tercera mitad una mezcla incierta de ambos. Este artículo es un marco de decisión para el primer workshop: cuándo RAG, cuándo fine-tuning, cuándo combinación, y cuándo debería esperar medio año y no desplegar nada.
Dos mundos, dos objetivos
**RAG (Retrieval-Augmented Generation):** - Los datos son externos, el modelo no los ve durante el entrenamiento - En inference el modelo recibe la pregunta + trozos relevantes de los datos como contexto - "Dame los 5 fragmentos más relevantes de la documentación que responden a la pregunta X" → los enviamos al modelo - El modelo responde teniendo en cuenta la documentación precisa, puede citar la fuente
**Fine-tuning:** - Los datos se cocen en los pesos del modelo durante el entrenamiento - En inference el modelo "recuerda" los datos (o al menos su reflejo estadístico) - El modelo responde con el estilo / formato / conocimiento de dominio que le hemos enseñado - La fuente original NO ESTÁ accesible en inference, solo su representación paramétrica
Estos dos mundos **no resuelven el mismo problema.** El error más común de los clientes: deciden hacer fine-tuning, cuando su problema real exige RAG.
Test: ¿cuál es su tarea?
Responda a estas cuatro preguntas:
1. ¿Busca en los datos HECHOS, o enseña ESTILO?
- **Hechos** ("¿Cuál es nuestro precio por hora para el cliente X?", "¿Cuáles son los parámetros de la máquina Y?") → **RAG**. El hecho debe cargarse exactamente desde la fuente autoritativa. Un modelo fine-tuned se inventa el hecho (la alucinación es una función impredecible de los datos de entrenamiento).
- **Estilo** ("Escribe en lenguaje jurídico formal", "Responde en el formato estructurado de nuestros informes técnicos") → **fine-tuning** puede ayudar. RAG con system prompts adecuados a menudo alcanza el 80-90% del mismo resultado.
2. ¿Con qué frecuencia cambian los datos?
- **Diariamente / semanalmente** → **RAG**. Re-entrenar el modelo en cada cambio de datos cuesta $50-500 y 2-8 horas. Re-indexar la knowledge base RAG = 5 minutos, 0,5 EUR.
- **Mensualmente / trimestralmente** → cualquiera. RAG es igual de cómodo.
- **Una vez cada 2+ años** → fine-tuning puede considerarse, si es conocimiento de dominio estable (protocolos médicos, códigos jurídicos, normas técnicas).
3. ¿Debe ser la respuesta auditable?
- **Sí (sectores regulados)** → **RAG es casi obligatorio**. Al cliente hay que poder demostrarle: "El modelo dijo X, porque vio Y en el documento Z". Un modelo fine-tuned "dijo X" sin posibilidad de demostrar de dónde lo sabe.
- **No** → fine-tuning entra en juego.
4. ¿Qué volumen de datos tiene?
- **< 100 k tokens** → ni RAG ni fine-tuning. Insértelos directamente en el system prompt de un modelo con ventana de 200k context (Claude Sonnet 4.6, Gemini 2.5 Pro). Lo más simple, lo más rápido.
- **100 k - 10 M tokens** → **RAG** es óptimo. Un índice vectorial sobre 1-10 M tokens son 200 MB de memoria, sub-100ms de latencia.
- **10 M - 1 B tokens** → RAG funciona, pero requiere arquitectura más sofisticada (multi-stage retrieval, hybrid search, reranking). Fine-tuning como ayuda, no como sustituto.
- **> 1 B tokens** → fine-tuning como pre-training step + RAG encima.
Cuándo gana fine-tuning sin discusión
1. Lenguaje / terminología de dominio
Jurisprudencia eslovaca, latín médico, abreviaturas técnicas de su empresa ("PVRZ" = nombre de protocolo de producción que ni Google adivinará). El modelo base no lo conoce. El fine-tuning se lo enseña.
Ejemplo: Mistral 7B fine-tunado en 5.000 ejemplos de documentación jurídica eslovaca → responde en el lenguaje jurídico correcto, conoce la terminología "demandado", "demandante", "acuerdo extrajudicial", "atenuación de sanción" en el contexto correcto. Un modelo base escribe en estilo Wikipedia.
Coste: SFT en 5.000 ejemplos, RTX 4090, ~6 horas, ~10 EUR de electricidad. Real en la práctica.
2. Salidas estructuradas con formato estricto
"Responde siempre JSON con este schema". El system prompt logra el 95% de precisión. El fine-tuning logra el 99,5+% de precisión. En sistemas de producción la diferencia 95% vs. 99,5% es vital — con 95% tiene 5% parse errors, que escurren toda la downstream pipeline.
3. Velocidad (latencia + cost) en high-throughput
RAG = embedding (50 ms) + retrieval (100 ms) + LLM con prompt ampliado (8.000 tokens × 100 RPS = expensive). Modelo fine-tuned = LLM con prompt corto (500 tokens × 100 RPS).
En workloads >100 RPS el fine-tuning es 5-10× más barato. En <10 RPS da igual.
4. Despliegue off-line / on-device
Un cliente móvil no puede llamar a una RAG knowledge base. Un modelo fine-tuned de 1B-4B corriendo en dispositivo (CoreML, ExecuTorch, llama.cpp) — tiene todo el conocimiento de dominio cocido, sin internet necesario.
Cuándo gana RAG sin discusión
1. Los datos cambian rápido
Customer support knowledge base, FAQ, product documentation, internal wikis. Añadir un nuevo documento = re-indexar (segundos). El fine-tuning supondría nuevo entrenamiento cada día.
2. Las citas son obligatorias
Compliance, derecho, medicina, asesoramiento financiero. El cliente tiene que ver: "El modelo cree X, porque el artículo 12 párrafo 3 de la ley Y lo dice así". El fine-tuning no produce citas — produce respuesta parafraseada sin audit trail.
3. Personalización per-user
El usuario A ve sus datos, el usuario B ve los suyos. El modelo es el mismo, pero la knowledge base se filtra por usuario. Un modelo fine-tuned no puede cambiar lo que sabe según el usuario.
4. Multi-language / multi-domain
El cliente tiene documentación en SK, EN, DE y quiere responder en el idioma de la pregunta. RAG: un modelo, 3 knowledge bases (o 1 base con metadatos de idioma). Fine-tuning: 3 modelos, o multi-task training más complejo.
Enfoque híbrido — la realidad de producción más común
En despliegues reales en 2026 se combina típicamente:
1. **Modelo base:** Claude Sonnet 4.6 o Llama 3.3 70B (open-weight) 2. **Fine-tuning ligero (LoRA):** sobre 1-5 k ejemplos de Q&A domain-specific, enseña al modelo "cómo responder" en el estilo y formato de su empresa 3. **RAG:** sobre datos vivos (documentos, base de datos, ticket system) 4. **System prompt:** resume contexto, identity, guardrails 5. **Reranker:** BGE-Reranker, Cohere Rerank — tras el retrieval reordena fragmentos, para que los más relevantes queden arriba
Este stack resuelve: el modelo conoce "cómo responder" (fine-tune), conoce "datos actuales" (RAG), conoce "quiénes somos y cuáles son las reglas" (system prompt). Más citas de fuentes, más auditabilidad.
Tooling concreto 2026
Stack RAG — nuestra elección por defecto
- **Vector DB:** Qdrant (self-hosted) o Weaviate. PostgreSQL + pgvector para casos de uso pequeños (< 1 M vectores).
- **Embedding model:** BGE-M3 (open, SK/EN/DE multilingual) o OpenAI text-embedding-3-large para setups cloud-only.
- **Reranker:** BGE-Reranker-Large o Cohere Rerank 3.
- **Orchestration:** LangChain o LlamaIndex para PoC rápido, código Python propio para producción (la capa de abstracción LangChain se vuelve impuesto en sistemas mayores).
- **Document parsing:** Docling (IBM, open) o Unstructured.io para PDF/DOCX/HTML.
- **Chunking strategy:** semantic chunking (250-500 tokens por chunk), 10-20% overlap, metadata-rich.
Stack fine-tuning — cuándo lo usamos
- **Framework:** Unsloth (2-5× más rápido que TRL vanilla), HuggingFace TRL para workflows estándar.
- **Method:** LoRA (rank 16-32) o QLoRA para setups VRAM-constrained. Full fine-tuning solo con >100 k ejemplos.
- **Modelo base:** Llama 3.3 70B, Mistral Small 3 (22B), Qwen 2.5 32B según licencia + idioma.
- **Eval:** Custom eval set con 200+ preguntas + standard benchmarks (MMLU, HellaSwag) para detectar regression.
- **Serving:** vLLM o SGLang para throughput, llama.cpp para local / on-device.
Costes — cifras reales 2026
Despliegue RAG (knowledge base B2B típica)
- 50 k documentos, 10 M tokens, peak 500 RPS
- Vector DB: Qdrant en VPS de 32GB, $80/mes
- Embedding (BGE-M3 self-hosted): servidor RTX 4090, amortización $200/mes
- LLM (Claude Sonnet 4.6): ~$3/M input tokens, ~$15/M output tokens. A 500 RPS con media 8 k input + 500 output → **$4.500-6.000 mensuales**
- Total: **~$5.500-6.500/mes** más inicialización única $5-15 k
O un stack íntegramente local con Llama 3.3 70B en 2× H100: hardware $80-120 k de una vez, operativa $300/mes de electricidad + mantenimiento. Retorno frente a cloud-only: 12-18 meses.
Despliegue fine-tuning
- Entrenamiento único (LoRA, 5.000 ejemplos, Llama 3.3 70B): $30-80 cloud GPU, o $5 de electricidad en RTX 4090 si tiene propia
- Eval + iteration cycle: 3-6 iteraciones × $50 = $150-300
- Hosting del modelo fine-tuned: igual que el base (sobrecoste LoRA es cero con merged weights)
- Mantenimiento: re-entrenar cada 3-6 meses cuando cambia el dominio
Coste real del fine-tuning en sistema productivo: **< $1.000 anuales**, si tiene un equipo capaz de mantenerlo. El hidden cost es "la persona que sabe hacer eval e interpreta los resultados" — no la GPU.
Cuándo no desplegar ninguno
- Los datos son pequeños (< 50 documentos) → use cloud LLM (Claude Project, GPT Custom GPT, Gemini Workspace) directamente, ninguna custom infra.
- El equipo no tiene capacidad MLOps y no está dispuesto a invertir en un data engineer durante 6+ meses.
- El dominio cambia rápidamente (MVP startup, experimentación con producto) → espere a que los datos se estabilicen.
- Los datos de cliente están altamente regulados y no tiene listo el DPIA (GDPR impact assessment) — primero resuelva compliance, luego despliegue.
---
*Hacemos RAG y fine-tuning como parte de integraciones IA. Si está pensando en desplegar un LLM sobre una base corporativa, la primera consulta (90 minutos) repasa estas cuatro preguntas de decisión sobre su caso de uso real y le da arquitectura orientativa y presupuesto antes de comprometerse con uno u otro camino.*