Fine-tuning vs RAG vs prompt engineering: qué técnica de IA usar en empresa según el caso de uso

La mayoría de empresas medianas españolas que arrancan con IA se atascan en la misma pregunta: ¿hacemos fine-tuning del modelo, montamos un RAG sobre nuestros datos o nos basta con prompt engineering bien hecho? Tres opciones, tres costes muy distintos, tres niveles de complejidad y, sobre todo, tres resultados muy diferentes según el caso de uso. La decisión equivocada en este punto es la diferencia entre un proyecto que ROI en seis meses y uno que se muere en el piloto. Esta guía es la decisión que tomamos en Everglow cuando entramos como implantadora de IA en empresa y nos piden elegir técnica antes de escribir una línea de código.

Spoiler: en el 80% de los casos, prompt engineering bien hecho o RAG resuelven el problema. El fine-tuning es la opción que más empresas piden y la que menos veces tiene sentido. Vamos a desmontarlo con criterio y con cifras.

Las tres técnicas, en una frase cada una

Antes de comparar, dejemos clara la definición operativa de cada técnica, porque muchas conversaciones de comité fracasan porque la gente no habla de lo mismo.

• Prompt engineering: das al modelo instrucciones cuidadosamente diseñadas (system prompt, few-shot examples, structured output, chain of thought) para que se comporte como necesitas. No tocas el modelo. No tocas los datos. Solo escribes mejor.
• RAG (Retrieval-Augmented Generation): el modelo no sabe nada de tu empresa, pero le das contexto en tiempo de consulta recuperando fragmentos relevantes de tu base de conocimiento. El modelo lee y responde sobre ese contexto, no sobre su memoria entrenada.
• Fine-tuning: entrenas (o reentrenas) un modelo base con tus propios ejemplos para que aprenda un comportamiento o un estilo que no se consigue solo con prompts. El modelo se modifica. Los datos quedan codificados en pesos.

Regla mental rápida: prompt engineering cambia cómo responde el modelo. RAG cambia sobre qué responde. Fine-tuning cambia quién es el modelo.

Cualquier discusión sobre fine-tuning vs RAG que no parta de esta distinción acaba en humo de comité.

Cuándo usar prompt engineering (la opción que casi nadie elige primero)

Es la técnica que más subestiman directivos y consultoras, y la que más palanca tiene. En la mayoría de implantaciones que hacemos en Everglow, el 60-70% del impacto se consigue solo con prompt engineering bien diseñado sobre un modelo de frontera (GPT-4.1, Claude Opus, Gemini 2.5).

Casos en los que prompt engineering basta:

• Clasificación de tickets, leads, emails o documentos cortos.
• Extracción estructurada de información (JSON) sobre texto que ya tienes en contexto.
• Generación de borradores estilísticamente consistentes (emails, propuestas, informes).
• Resúmenes de reuniones, llamadas o documentos que caben en la ventana de contexto.
• Razonamiento sobre datos pequeños que pasas en la propia llamada.
• Workflows con LLMs como pieza de un pipeline más amplio (validar, decidir, redirigir).

Coste real: el de tokens. Sin entrenamiento, sin infraestructura especial, sin equipo de ML. Time-to-production: días o semanas, no meses.

Errores típicos al despreciar esta opción:

1. Saltar directamente a “queremos fine-tunear” porque suena más serio.
2. Pedir un RAG cuando todo lo que necesitas cabe en 30.000 tokens.
3. Confundir “prompt mediocre + frustración” con “el modelo no sabe hacerlo”.

Antes de invertir en RAG o fine-tuning, dedica dos semanas a un equipo de uno o dos seniors a exprimir prompt engineering sobre el caso. Vas a sorprender al comité, y a ti mismo.

Cuándo usar RAG (la opción con mejor relación coste/impacto)

RAG es el patrón que más volumen mueve en nuestros squads, y por una razón sencilla: la mayoría de problemas reales de IA en empresa no son “que el modelo sea más listo”, son “que el modelo conozca mis datos sin que yo los suba a un proveedor”. Aquí RAG es imbatible.

Casos donde RAG es la respuesta clara:

• Copiloto interno sobre conocimiento propio: documentación, manuales, contratos, políticas, tickets, Confluence, Notion, SharePoint, base de PDFs históricos.
• Atención al cliente con base de conocimiento dinámica: FAQs, catálogo, manuales de producto, histórico de tickets resueltos.
• Investigación interna: legal, regulatorio, técnico, científico, donde la información cambia y no puedes fine-tunear cada vez que se publica una norma.
• Búsqueda semántica + generación sobre cualquier base de conocimiento que tu plantilla consulta a diario.
• Onboarding y soporte interno: nuevos empleados que necesitan responder dudas operativas sin saturar a managers.

Coste real: vector store (Pinecone, Qdrant, pgvector — cualquiera vale para arrancar), embeddings (céntimos por millón de tokens), pipeline de ingesta, evaluación. Para una mediana empresa española, un RAG decente arranca entre 8.000 y 25.000 euros de implantación y luego cuesta entre 200 y 1.500 euros/mes operativo según volumen. En Everglow lo escribimos en detalle en nuestros artículos sobre coste real de operar IA.

Lo que casi nadie te cuenta del RAG:

• El 80% del trabajo es preparar y trocear los datos, no la parte vectorial. Si tus datos están sucios, tu RAG va a alucinar bonito.
• La gestión de permisos por documento (que cada usuario solo vea lo que puede ver) es lo que más se subestima.
• La evaluación —cómo sabes si responde bien— se planifica al final y debería planificarse al principio.
• Los chunks mal hechos arruinan más proyectos RAG que la elección del modelo.

RAG no es magia, es buena ingeniería de datos disfrazada de IA. Quien gana en RAG es quien tiene su casa ordenada, no quien tiene el modelo más grande.

Si tu pregunta es “queremos algo tipo ChatGPT pero que conozca nuestros datos”, la respuesta casi siempre es RAG. No fine-tuning.

Cuándo usar fine-tuning (mucho menos a menudo de lo que crees)

Fine-tuning tiene casos legítimos. Pocos, pero existen. El problema es que es la primera opción que muchos directivos piden porque “queremos un modelo nuestro”, y casi siempre es la peor decisión que se puede tomar al principio.

Casos donde fine-tuning sí merece la pena:

• Estilo o voz muy específica que el prompt no consigue replicar de forma consistente (atención al cliente con tono de marca muy marcado, generación de copy en una voz concreta a escala).
• Tareas de clasificación a muy alto volumen donde un modelo pequeño fine-tuneado es mucho más barato que llamar a GPT-4 millones de veces.
• Formatos de salida muy estructurados que el modelo base no respeta bien aunque le insistas (extracción de información en esquemas muy raros).
• Conocimiento estable y cerrado que no va a cambiar (ej: traducción especializada en un dominio cerrado).
• Reducción de latencia o coste a escala: un modelo pequeño fine-tuneado bien puede responder en 100ms a coste irrisorio comparado con un frontier model.

Casos donde fine-tuning NO es la respuesta (y muchos lo piden):

• “Queremos que el modelo sepa de nuestra empresa”. → Esto es RAG, no fine-tuning. El modelo no “aprende” tus datos de forma fiable con fine-tuning; los olvida, los mezcla, y no puedes auditarlos.
• “Queremos que sea seguro y no filtre datos”. → Esto es arquitectura y permisos, no fine-tuning.
• “Queremos que actualice cuando cambien los datos”. → Imposible con fine-tuning sin reentrenar. Es RAG.
• “Queremos que sea más listo que GPT-4”. → Olvídalo. No vas a superar a un frontier model con un fine-tune sobre 5.000 ejemplos.

Coste real: dataset etiquetado (la parte cara, casi siempre infravalorada), entrenamiento, evaluación, infraestructura de inferencia si lo despliegas tú. Hablar de fine-tuning serio en empresa española son cifras desde 30.000-150.000 euros de proyecto inicial, y con mantenimiento permanente si los datos cambian.

Y la pregunta que casi nunca se hace: ¿quién va a mantener este modelo dentro de seis meses? Porque un modelo fine-tuneado es un activo vivo que requiere reentrenamientos cuando cambian datos, métricas y casos. Si no tienes equipo de ML o un implantador comprometido a largo plazo, el modelo se pudre.

Tabla de decisión rápida

Para zanjar discusiones de comité, esta es la heurística que usamos en Everglow cuando entramos en una empresa nueva:

• ¿El caso de uso se resuelve con datos que caben en el contexto? → Prompt engineering.
• ¿Necesitas que el modelo responda sobre datos propios cambiantes? → RAG.
• ¿Necesitas controlar quién ve qué información? → RAG con permisos.
• ¿Necesitas un estilo o formato muy específico imposible vía prompt? → Fine-tuning ligero.
• ¿Tienes 10M+ de llamadas/mes y un modelo pequeño te ahorraría 70% de coste? → Fine-tuning de modelo pequeño.
• ¿Estás pensando en fine-tuning para “que sepa de tu empresa”? → Stop. Es RAG.

En el 80% de los proyectos que hemos arrancado en los últimos 18 meses, la combinación ganadora es prompt engineering + RAG. Fine-tuning aparece como tercera capa en menos del 15% de los casos, y casi siempre después de meses de operar con RAG y datos suficientes para etiquetar.

El error de combinar antes de tiempo

Otro patrón que vemos repetirse: equipos que arrancan queriendo “hacer las tres cosas a la vez” porque suena ambicioso. Resultado: seis meses de PoC, ninguno de los tres pilares bien construido, comité quemado y proyecto cancelado.

La secuencia correcta es:

1. Mes 1: prompt engineering sobre frontier model. Mides qué tan lejos llegas.
2. Mes 2-3: si te quedas corto por falta de contexto sobre datos propios, añades RAG.
3. Mes 6-12: si llegas a escala suficiente y detectas un cuello concreto (coste, latencia, formato), evalúas fine-tuning sobre ese subproblema.

Saltar pasos cuesta dinero. Saltar el primero, especialmente, cuesta meses y credibilidad.

Riesgos específicos de cada técnica

Cada opción introduce riesgos distintos que conviene anticipar antes de firmar un proyecto:

Prompt engineering:

• Dependencia del proveedor del modelo (si OpenAI cambia GPT-4 mañana, tus prompts pueden degradarse).
• Difícil de versionar y auditar sin la tooling adecuada (Langfuse, PromptLayer, MLflow).
• Tentación de meter lógica de negocio crítica en strings sin tests.

RAG:

• Calidad solo tan buena como tus datos (basura entra, basura sale).
• Permisos y privacidad: el RAG mal montado es la vía rápida a una fuga de datos cruzada entre usuarios.
• Coste de embeddings y vector store crece con el corpus.
• Evaluación es difícil sin un golden set bien construido.

Fine-tuning:

• Coste y tiempo muy superiores a lo que parece en el primer presupuesto.
• Datos de entrenamiento mal etiquetados envenenan el modelo de forma silenciosa.
• Mantenimiento perpetuo: si los datos cambian, el modelo se desactualiza.
• Vendor lock-in si fine-tuneas sobre modelos propietarios (no puedes llevártelo a otro proveedor).
• Difícil de explicar al comité de cumplimiento: el modelo deja de ser “una caja conocida”.

Lo que pedimos siempre antes de elegir técnica

Cuando un cliente nos pide en Everglow ayuda con esta decisión, lo primero que hacemos no es proponer arquitectura. Es responder estas preguntas:

• ¿Qué problema concreto resolvemos y cómo mediremos el éxito?
• ¿Cuántas consultas/mes esperamos y a qué latencia?
• ¿Qué datos necesita el modelo y dónde viven hoy?
• ¿Quién puede ver qué? (permisos)
• ¿Cómo de a menudo cambian esos datos?
• ¿Cuánto presupuesto operativo mensual estamos dispuestos a quemar?
• ¿Qué pasa cuando el modelo se equivoca? (humano en el bucle, fallback, escalado)
• ¿Quién mantiene esto dentro de 12 meses?

Sin estas respuestas, cualquier decisión de fine-tuning vs RAG es una apuesta. Con ellas, la elección se vuelve obvia el 90% de las veces.

Conclusión: empieza por lo simple, escala con criterio

La industria empuja a las empresas a querer fine-tuning porque suena sofisticado y vende horas. La realidad es que el patrón ganador hoy en empresa es prompt engineering excelente + RAG bien ingenierizado, con fine-tuning como tercera capa cuando hay datos suficientes y un caso muy específico. Quien se salte este orden, paga la novatada con tiempo, dinero y credibilidad ante el comité.

En Everglow entramos en empresas medianas españolas como implantadora de IA justo en esta decisión: ayudamos a elegir técnica, a medir el ROI antes de invertir y a construir solo lo necesario para llegar a producción rápido. Si estás en este punto y quieres una segunda opinión técnica antes de firmar nada, escríbenos por el contacto y te decimos sin humo qué te toca hacer primero.