Fine-tuning vs RAG vs prompt engineering: decisión ejecutiva con costos en CLP
Decisión ejecutiva entre las 3 técnicas para personalizar un LLM al contexto de tu empresa: fine-tuning, RAG y prompt engineering. Tradeoffs reales y costos en CLP.
Una de las decisiones técnicas más comunes en proyectos IA: ¿cómo hago que el modelo "sepa" sobre mi empresa? Tres caminos posibles: prompt engineering con system prompt + few-shot, RAG (Retrieval-Augmented Generation) con base de conocimiento propia, fine-tuning del modelo con datos del dominio. Cada uno tiene casos donde brilla y casos donde es excesivo. Este satélite entrega la decisión técnica con tradeoffs reales y costos en CLP.
Las 3 técnicas en una frase
**Prompt engineering:** indicar al modelo qué hacer y darle contexto en el prompt mismo (system prompt + few-shot + reglas). No modifica el modelo. Setup: minutos. Costo recurrente: solo tokens.
**RAG:** mantener una base de conocimiento (documentos, datos) y recuperar dinámicamente lo relevante al prompt al momento de cada query. No modifica el modelo. Setup: días. Costo recurrente: embeddings + tokens.
**Fine-tuning:** entrenar versión personalizada del modelo con ejemplos de tu dominio. Modifica el modelo. Setup: semanas. Costo recurrente: tokens del modelo fine-tuned (típicamente más caro que el base).
Cuándo conviene cada uno
Prompt engineering — siempre primero
Para 70-80% de los casos PyME y empresa mediana, prompt engineering bien hecho (system prompt estructurado + few-shot con 3-5 ejemplos + reglas claras) es suficiente. Antes de complicar, agotar esto.
RAG — cuando el conocimiento es dinámico o vasto
- Base de conocimiento que crece o cambia (manuales, FAQs, productos, políticas que se actualizan).
- Volumen de información que no cabe en un system prompt (más de 10-20 mil tokens efectivos).
- Necesidad de citar fuentes literales (auditoría, legal, soporte técnico).
- Multi-tenant donde cada cliente tiene su propia base.
Fine-tuning — cuando el estilo o tarea es muy específica
- Estilo de redacción muy particular que prompt engineering no logra estabilizar.
- Tarea estructurada y repetitiva que se beneficia de "entrenamiento muscular" del modelo.
- Reducción de costo de tokens: fine-tuning de modelo chico puede reemplazar Opus con un Sonnet o Haiku entrenado.
- Conocimiento que NO cambia (procedimientos estables, terminología propietaria).
Tabla comparativa
| Dimensión | Prompt eng. | RAG | Fine-tuning |
|---|---|---|---|
| Setup | Horas | Días-semanas | Semanas |
| Costo proyecto típico CLP | 0 (incluido) | 6-15M | 20-50M+ |
| Costo recurrente vs base | Igual | +15-30% | +10-50% |
| Conocimiento dinámico | No | Sí | No |
| Cita de fuentes | No | Sí | Limitada |
| Modificación del estilo | Sí | Sí | Sí (mejor) |
| Latencia adicional | Cero | +100-300ms | Cero (más bien menor) |
| Mantenimiento | Bajo | Medio | Alto |
| Riesgo lock-in | Bajo | Bajo | Alto (modelo entrenado) |
La combinación que más vemos en clientes
Para casos productivos B2B chilenos, el patrón más común es **Prompt engineering + RAG**:
- System prompt estructurado que define identidad, objetivo, reglas y formato.
- Few-shot con 3-5 ejemplos del dominio para consistencia.
- RAG sobre base documental propia para casos que requieren información actualizada o cita.
- NO fine-tuning salvo casos muy específicos.
Esto cubre 80%+ de los casos B2B con baja inversión y mantenimiento manejable. Fine-tuning entra solo cuando el caso lo justifica claramente.
Errores comunes al elegir
- Saltar a fine-tuning porque "suena más serio": inversión alta, mantenimiento complejo, beneficio marginal vs RAG.
- No intentar prompt engineering primero: termina en sobreingeniería de un caso simple.
- RAG sin disciplina: indexar todo sin estrategia genera respuestas pobres.
- Fine-tuning sin eval suite: no puedes saber si la nueva versión es mejor.
- Combinar las 3 técnicas sin justificación: complejidad operacional alta sin valor adicional.
Cuándo el fine-tuning sí tiene sentido
Tres casos reales donde recomendamos fine-tuning en clientes:
- Generación de descripciones de producto en e-commerce con tono de marca muy específico (miles de productos, consistencia crítica).
- Clasificación masiva de tickets de soporte en categorías propietarias (volumen alto, fine-tuning de Haiku reduce costo vs Sonnet).
- Extracción estructurada de campos en documentos sectoriales específicos (formularios fitosanitarios, declaraciones aduana) con accuracy crítica.
Para casi todo lo demás, prompt engineering + RAG es la respuesta correcta.
Costos de fine-tuning en CLP
- Anthropic Claude fine-tuning: en evaluación pública 2026, pricing aún variable. Estimado USD 50-200 por job de fine-tuning + tokens más caros en producción.
- OpenAI fine-tuning de GPT-5 mini: USD 25 por millón de tokens de entrenamiento + uso ~2x más caro en producción.
- Open source fine-tuning (Llama, Mistral): solo costo de GPU. Para fine-tuning serio requiere H100 = ~USD 4/h en RunPod. Job típico 2-12 horas.
Proyecto de fine-tuning serio: CLP 20-50M+ entre datos, infraestructura y eval suite. Mantenimiento (re-entrenamiento periódico): CLP 5-15M anual.
Decisión en 4 pasos
Cómo elegir entre las 3 técnicas.
- Día 1
Probar prompt engineering
System prompt + few-shot. Eval suite básico.
- System prompt estructurado
- Few-shot 3-5 ejemplos
- Validar con casos golden
- Días 2-3
Si insuficiente, evaluar RAG
Identificar si el problema es conocimiento dinámico/vasto.
- Mapear base de conocimiento
- Decidir indexación
- Setup pgvector + Vercel AI SDK
- Semanas
Solo si insuficiente, considerar fine-tuning
Evaluar caso muy específico.
- Validar que prompt + RAG agotó posibilidades
- Estimar ROI de fine-tuning vs status quo
- Decisión informada con números
- Día final
Documentar la decisión
Para que el equipo futuro sepa por qué se eligió.
- Decisión técnica documentada
- Criterios para revisarla
Preguntas frecuentes
Da el siguiente paso
Hablemos
Cuéntanos sobre tu negocio. Respondemos en 24 horas.
Otros canales
Escríbenos por WhatsApp o agenda una llamada de 30 minutos.