Elegir entre prompting, RAG y fine-tuning (y cuándo combinarlos)

Un equipo recibe el encargo de «mejorar la IA para nuestro caso de uso concreto». Puede escribir prompts mejores, crear un sistema RAG que proporcione datos pertinentes al modelo o aplicar fine-tuning con ejemplos de su dominio.

Estas opciones no son intercambiables: resuelven problemas distintos. Un diagnóstico incorrecto puede consumir tres meses y un presupuesto de fine-tuning cuando bastaba con mejorar el prompt, llevar a construir una compleja infraestructura RAG cuando el fine-tuning habría sido más sencillo o mantener al equipo iterando sobre prompts cuando el modelo carece de la capacidad necesaria.

Este artículo es un marco para elegir — cuándo cada una es la herramienta adecuada, cuándo combinarlas, los costes reales de cada una y qué tiende a funcionar bien y mal en producción.

Lo que cada una realmente hace

Una distinción clara:

El prompting cambia lo que se le pide al modelo. Le das al modelo mejores instrucciones, ejemplos, requisitos de formato, contexto. El modelo en sí no cambia; lo que cambia es la entrada.

RAG cambia los datos que ve el modelo. Recuperas información pertinente en el momento de la consulta y la incluyes en el prompt. El modelo recibe datos actuales, específicos y dinámicos sin haber sido entrenado con ellos.

El fine-tuning cambia lo que sabe el modelo o cómo se comporta. Entrenas al modelo en ejemplos, modificando sus pesos. El modelo en sí se actualiza.

Estas resuelven problemas diferentes:

• Brecha de instrucción: el modelo podría hacer la tarea si se le preguntara correctamente. → Prompting.
• Brecha de conocimiento: el modelo necesita información que no tiene. → RAG.
• Brecha de capacidad: el modelo no puede hacer la tarea de forma confiable incluso con buenos prompts y contexto. → Fine-tuning.

Identificar correctamente la brecha resuelve la mitad del problema.

Diagnóstico de la brecha

Cuando la IA no hace lo que necesitas, pregúntate:

¿Podría una persona inteligente, dada solo la instrucción, hacer esta tarea?

Si la respuesta es sí → brecha de instrucciones. Un prompt mejor debería resolverla.

Si no, ¿podrían hacerlo si les dieras material de referencia relevante?

Si sí → brecha de conocimiento. El RAG puede resolverlo.

Si no, ¿podrían hacerlo después de una práctica extensa y retroalimentación?

Si sí → brecha de capacidad. El fine-tuning podría resolverlo.

Si la respuesta es no → quizá un LLM no pueda resolver la tarea. Replantea el problema.

La mayoría de los problemas descritos como «la IA no funciona» son brechas de instrucciones que un prompting mejor puede resolver. Las brechas de conocimiento ocupan el segundo lugar. Las brechas reales de capacidad son menos frecuentes, pero más difíciles.

Prompting: la palanca subestimada

El prompting es la opción más barata y rápida, y a menudo la correcta. Sin embargo, muchos equipos se lo saltan para pasar directamente a RAG o al fine-tuning.

Algunas cosas que puedes hacer con prompting solo:

• Cambiar el tono, formato, longitud.
• Aplicar patrones de razonamiento (cadena de pensamiento, autorreflexión).
• Codificar restricciones (haz X, no hagas Y).
• Codificar políticas y medidas de protección.
• Adaptarse a casos de uso específicos (diferentes prompts para diferentes características).
• Mejorar la coherencia mediante ejemplos few-shot.

Lo que no puedes hacer con prompting solo:

• Hacer que el modelo conozca hechos que no tiene.
• Hacer que un modelo pequeño se comporte como un modelo grande.
• Cambiar fundamentalmente la voz o estilo del modelo a un nivel profundo.
• Acelerar la inferencia del modelo.

Una regla razonable es probar primero el prompting e iterar durante al menos una semana antes de recurrir a RAG o al fine-tuning. En muchos casos resolverá el problema.

Esfuerzo de ingeniería de prompts

Una semana de iteración intensiva de prompts puede producir mejoras dramáticas. La curva típica:

• Día 1: línea base. Resultados mediocres.
• Día 2-3: cambios estructurales. Mejor formato, instrucciones más claras. Mejoras importantes.
• Día 4-5: ejemplos y casos límite. Captura modos de falla.
• Día 6-7: tono, restricciones, pulido. Mejora final del 10%.

Después de una semana, has extraído la mayoría de lo que el prompting puede ofrecer. Si aún no estás satisfecho, la brecha probablemente es de conocimiento o capacidad.

Cómo son los buenos prompts

Como referencia, un prompt fuerte típicamente tiene:

• Rol y tarea claros.
• Requisitos de formato específicos.
• 1-5 ejemplos representativos (si es necesario).
• Restricciones explícitas (lo que hacer, lo que no hacer).
• Manejo de casos límite.
• Esquema de salida.

Suelen tener 5-10 párrafos: ni tan pocos que falten especificaciones ni tantos que el modelo pierda el foco.

RAG: la solución para el conocimiento

El RAG es la herramienta adecuada cuando:

• El modelo necesita información factual que no tiene.
• La información cambia (datos en vivo, eventos recientes, datos específicos de la cuenta).
• La información es específica para tu dominio u organización.
• Necesitas citas y una fundamentación verificable.

Es la herramienta equivocada cuando:

• El problema es de instrucción, no de conocimiento.
• Los datos son lo suficientemente pequeños como para caber en un prompt directamente.
• Necesitas que el modelo haga algo diferente, no solo conocer algo diferente.

El coste real

Un sistema RAG es ingeniería real:

• Construcción: 4-12 semanas para un sistema serio —ingesta, fragmentación, embeddings, recuperación, reranking y evaluación—.
• Operación: continua; hay que mantener el índice actualizado, monitorizar la calidad y corregir problemas.
• Infraestructura: base de datos vectorial, API de embeddings y reranking. Un sistema de tamaño moderado suele costar €200-2000/mes.
• Coste por consulta: superior al del prompting por los embeddings, la recuperación y un contexto mayor. Suele ser 2-5x el de una llamada convencional a la API.

Esto vale la pena para los problemas adecuados. Pero es una inversión significativa en comparación con el prompting.

La calidad del RAG es un viaje

Un sistema RAG funcional en la semana 1 suele alcanzar una calidad del 60-70%. Llegar al nivel de producción (85%+) requiere 1-2 meses adicionales para mejorar la fragmentación, añadir reranking, corregir modos de fallo y crear evaluaciones.

Planifica esto. No envíes en la semana 1; tendrás usuarios enfadados.

Fine-tuning: cuando el prompting y el RAG no son suficientes

El fine-tuning es la herramienta adecuada cuando:

• Tienes una brecha clara de capacidad — el modelo no puede hacer la tarea de forma confiable incluso con buenos prompts y contexto.
• Tienes un buen lote de ejemplos de entrenamiento de alta calidad — al menos unos pocos cientos para un LoRA muy estrecho, normalmente 1,000+ para un comportamiento general confiable. Consulta el artículo de fine-tuning para los umbrales exactos por técnica.
• Necesitas comportamiento consistente y estrecho (un estilo específico, un formato de salida específico, un dominio específico).
• El coste de inferencia o la latencia importan: un modelo más pequeño con fine-tuning puede ser más barato que otro general y de mayor tamaño.

Es la herramienta equivocada cuando:

• Tus datos están en constante cambio (el modelo fine-tuned se volverá obsoleto rápidamente).
• No has agotado primero el prompting y el RAG.
• No tienes buenas evaluaciones (no puedes saber si el fine-tuning ayudó).
• La tarea necesita información muy actual (el fine-tuning es una captura de momento).
• Intentas enseñar hechos: RAG lo hace mejor, con mayor fiabilidad y citas.

Tipos de fine-tuning

Fine-tuning completo: actualiza todos los pesos del modelo. Es más potente y caro, y requiere mucha capacidad de cómputo. Suele reservarse para laboratorios de modelos fundacionales.

LoRA (Low-Rank Adaptation): solo un subconjunto pequeño de pesos se entrena. Mucho más barato. A menudo produce resultados competitivos con el fine-tuning completo para tareas estrechas.

QLoRA: LoRA cuantizado. Aún más barato. Menor calidad a gran escala pero razonable para muchas tareas.

Prompt tuning / prefix tuning: aún más pequeño; solo se entrena prompts suaves. Más barato. Capacidad limitada.

Instruction tuning: entrena al modelo para seguir instrucciones. Suele aplicarse al modelo base y rara vez resulta útil para usuarios finales.

RLHF / DPO / KTO: entrenar al modelo para alinear con datos de preferencia (respuestas A vs B). Potente para cambios de comportamiento; complejo de hacer bien.

En 2026, la mayoría de los equipos utilizan LoRA sobre un modelo base sólido. Ofrece un buen equilibrio entre coste y capacidad para la mayoría de los casos.

El coste real

Los costes de fine-tuning dependen del enfoque y la escala, pero típicamente para un fine-tuning de LoRA de un modelo abierto de tamaño medio con 5K-10K ejemplos:

• Preparación de datos: 1-4 semanas. A menudo la mayor parte del trabajo. Curar, limpiar, formatear ejemplos.
• Entrenamiento: de horas a días, según el tamaño del conjunto de datos y la infraestructura. €100-2000 en cómputo.
• Evaluación: 1-2 semanas para crear suites y comparar el modelo ajustado con el base.
• Iteración: 1-3 ciclos antes de que algo esté listo para producción.
• Implementación: si usas una API gestionada (fine-tuning de OpenAI, Anthropic, Vertex), sencillo. Si autohospedas, más trabajo.
• Mantenimiento: reentrenamiento cuando los datos se actualizan, cuando el modelo base se actualiza, cuando el caso de uso cambia.

Total: 6-12 semanas de trabajo, €1K-€20K en cálculo (dependiendo de la escala), mantenimiento continuo.

Inversión significativa. Asegúrate de que valga la pena.

Cuando el fine-tuning brilla

Escenarios específicos donde el fine-tuning claramente gana:

Requisitos estrictos de formato. Las salidas deben seguir un esquema o estilo específico de forma consistente. El prompting puede llevarte al 95%; el fine-tuning al 99%.

Dominios especializados. Terminología médica, formulación legal, código en un DSL interno. El fine-tuning enseña al modelo tu dialecto específico.

Personalidad y voz. Mantiene una voz coherente durante miles de interacciones. Los prompts pueden desviarse; el fine-tuning la estabiliza.

Optimización de latencia y coste. Un modelo de 7B ajustado para la tarea puede ser más barato y rápido que un modelo general de 70B. Con un volumen elevado, la inversión se amortiza.

Seguridad comportamental. Fine-tuning el modelo para rechazar ciertas cosas o agregar medidas de seguridad específicas puede ser más robusto que medidas de protección basadas en prompts.

Cuando el fine-tuning falla

Formas comunes en que el fine-tuning decepciona:

Datos insuficientes. El fine-tuning en 100 ejemplos normalmente no ayuda mucho. Un LoRA muy estrecho puede funcionar a veces con unos pocos cientos de ejemplos; para un comportamiento general confiable, planifica 1,000+ ejemplos de alta calidad.

Datos deficientes. Si los ejemplos son incoherentes o de baja calidad, el modelo resultante también lo será.

Olvido catastrófico. Fine-tuning pesado en tareas estrechas puede dañar capacidades generales. El modelo se vuelve bueno en tu tarea pero peor en todo lo demás.

Conocimiento obsoleto. Un modelo ajustado refleja una instantánea. Incorporar información nueva exige reentrenarlo, lo que supone un coste permanente en dominios dinámicos.

Mejoras del modelo base superan al fine-tuning. El modelo base mejora lo suficiente que el fine-tuning ya no es mejor. Ahora estás manteniendo un fine-tuning de un modelo base obsoleto.

Problemas de evaluación. Sin evaluaciones sólidas, no sabes si el fine-tuning ayudó, perjudicó o no tuvo efecto. Muchos “éxitos” de fine-tuning son ganancias placebo.

Los patrones de combinación

En producción, los mejores sistemas combinan los tres.

Combinación 1: Prompted RAG (más común)

La opción predeterminada para aplicaciones con alto contenido de conocimiento.

• Prompts cuidadosamente diseñados codifican instrucciones, formato, restricciones.
• RAG proporciona información actual y específica.
• Sin fine-tuning; confía en un modelo base fuerte.

Este es el patrón de producción más común en 2026. Funciona para la mayoría de los casos de uso.

Combinación 2: Modelo fine-tuned + RAG

Cuando necesitas especialización comportamental y conocimiento dinámico.

• Fine-tuning para voz, formato, dominio.
• RAG para información actual.
• Los prompts orquestan el flujo.

Ejemplo: un modelo fine-tuned para la voz específica de soporte al cliente de una empresa, con RAG sobre políticas y documentación actuales. El fine-tuning maneja la voz consistente; RAG maneja el conocimiento cambiante.

Combinación 3: Fine-tunes especializados para tareas específicas

Diferentes fine-tunes para diferentes partes del sistema.

• Fine-tune de clasificación para enrutamiento.
• Fine-tune de resumen para resúmenes.
• Fine-tune de generación para respuestas de clientes.
• Cada uno más pequeño, más rápido, especializado.

Este patrón se utiliza cuando importan la escala y la optimización de costes. Cada modelo ajustado realiza bien una tarea específica y la orquestación decide cuándo invocarlo.

Combinación 4: Router fine-tuned + modelos generales

El router se ajusta para clasificar las consultas de forma fiable. Una vez clasificadas, se envían a modelos generales para realizar el trabajo principal.

El fine-tune es pequeño, rápido, estrecho. El trabajo caro y general se hace con modelos generales, manteniéndolos actualizados.

Combina economía (fine-tune es pequeño) con capacidad (modelos generales para el trabajo difícil).

El marco de decisión

Un flujo de decisión práctico:

Pregunta 1: ¿El problema es soluble con el modelo actual y un buen prompt?

Si la respuesta es sí: escribe el prompt, itera durante una semana y publícalo.

Si no, ve a la Pregunta 2.

Pregunta 2: ¿El problema implica conocimiento que el modelo no tiene?

Si la respuesta es sí: crea RAG, invierte el tiempo necesario para alcanzar calidad de producción y combínalo con prompts sólidos.

Si no, ve a la Pregunta 3.

Pregunta 3: ¿El problema es sobre formato consistente, dominio estrecho o comportamiento específico?

Si la respuesta es sí y tienes varios cientos de ejemplos de alta calidad —idealmente 1,000+—: aplica fine-tuning y combínalo con prompting y, si corresponde, RAG.

Si no tienes los ejemplos: invierte en recopilarlos, O intenta un mejor prompting / RAG antes del fine-tuning.

Pregunta 4: ¿Has hecho el trabajo de evaluación para saber qué enfoque realmente ayuda?

Esta pregunta se aplica en cada paso. Sin evaluaciones, estás adivinando.

Ejemplos de producción

Unos pocos ejemplos reales de combinaciones:

Ejemplo 1: Soporte al cliente con IA

Configuración: La IA de atención al cliente de una empresa SaaS gestiona consultas de nivel 1.

Componentes:

• Prompts fuertes para tono, formato, políticas de escalado.
• RAG sobre documentos actuales, políticas, historial de tickets.
• Fine-tuning ligero para la voz y los patrones de derivación propios de la empresa (1,500 ejemplos seleccionados de tickets anteriores).

Resultado: Maneja el 65% de los tickets de forma autónoma. El fine-tuning se encarga de la voz consistente; RAG mantiene la precisión; los prompts manejan las políticas.

Ejemplo 2: Revisión de documentos legales

Configuración: Un producto de tecnología legal revisa contratos para riesgos.

Componentes:

• Prompts detallados que indican qué buscar —categorías jurídicas y rúbrica de gravedad—.
• RAG sobre leyes relevantes y precedentes.
• Sin fine-tuning; modelos de razonamiento manejan el trabajo pesado.

Resultado: Prompting + RAG funciona bien porque el modelo ya cuenta con formación jurídica. El beneficio marginal del fine-tuning no justificaba la inversión.

Ejemplo 3: Completar código en un DSL personalizado

Configuración: Una herramienta especializada de datos con su propio DSL.

Componentes:

• Prompts con ejemplos.
• Sin RAG (el DSL es lo suficientemente pequeño como para caber en contexto).
• Fine-tuning de LoRA en 10K ejemplos del DSL.

Resultado: El fine-tuning fue esencial. Sin él, el modelo no podía producir DSL válido de forma confiable. Solo los prompts y contexto no eran suficientes.

Ejemplo 4: Asistente interno de la empresa

Configuración: Un asistente general para empleados de la empresa.

Componentes:

• Prompts de sistema fuertes (voz, comportamiento, rechazos).
• RAG sobre wiki de la empresa, Slack, documentos.
• Sin fine-tuning; la “voz” de la empresa se captura en los prompts.

Resultado: RAG + prompts manejan la mayoría de los casos de uso. La empresa no es lo suficientemente peculiar como para necesitar fine-tuning para la voz.

Errores que vemos

Algunos patrones de mala asignación:

Error 1: Recurrir primero al fine-tuning. El equipo decide que «deberíamos ajustar nuestro propio modelo» y empieza por ahí. El 90% de las veces, prompting + RAG sería igual de eficaz, más rápido y más barato.

Error 2: Saltar RAG cuando es la solución. Los equipos construyen prompts elaborados para “recordar” al modelo información de la empresa que claramente debería recuperarse en tiempo de consulta. Mejor recuperar.

Error 3: Fine-tuning sin evaluaciones. «Lo hemos ajustado y ahora es mejor», pero no existen métricas. A menudo no mejora nada o incluso perjudica el rendimiento. Sin evaluaciones, no puedes saberlo.

Error 4: Fine-tuning obsoleto. Un fine-tuning de hace 6 meses, cuando GPT-4 era el mejor. Hoy en día, los modelos de vanguardia sin el fine-tuning superan al modelo fine-tuned más antiguo. Los fine-tuning necesitan reevaluación a medida que el campo avanza.

Error 5: Intentar enseñar hechos mediante fine-tuning. El modelo memoriza algunos y alucina otros. RAG gestiona el conocimiento factual; el fine-tuning, el comportamiento.

Error 6: No iterar suficientemente en los prompts. Dos días de iteración de prompts es un punto de partida. Dos semanas te dan la respuesta real.

Error 7: Sobrediseñar RAG cuando el prompting podría hacerlo. Un documento de 50K tokens de la empresa volcado en el prompt a veces es más simple que RAG. Especialmente para corpora pequeños.

Comparación de costes y esfuerzo

Una comparación aproximada para un proyecto típico de tamaño medio:

La elección correcta depende del problema y los recursos. Para la mayoría de los equipos, prompting + RAG es el punto óptimo: aporta una mejora significativa sin exigir toda la inversión del fine-tuning.

Conclusión

Prompting, RAG y fine-tuning resuelven problemas diferentes. Elegir correctamente requiere diagnóstico honesto: ¿es esto una brecha de instrucción, una brecha de conocimiento o una brecha de capacidad?

El orden honesto para probarlos:

1. Prompting (1-2 semanas de iteración). Más barato, más rápido, a menudo suficiente.
2. RAG si hay una brecha clara de conocimiento. Inversión significativa pero bien delimitada.
3. Fine-tuning si hay una brecha clara de capacidad que prompting + RAG no pueden cerrar. Más caro; hazlo último.
4. Combinaciones para sistemas de producción maduros.

Los equipos que tienen éxito son honestos sobre qué brecha tienen y disciplinados sobre las evaluaciones. Sin evaluaciones, no puedes saber qué enfoque ayudó. Con ellas, el camino suele ser claro.

Al analizarlos con detalle, la mayoría de los proyectos planteados como «necesitamos ajustar nuestro propio modelo» deberían convertirse en «necesitamos escribir prompts mejores y añadir RAG». Reserva el fine-tuning para los casos que realmente lo exijan.

El resultado son sistemas mejores, entregados más rápido y con un coste menor. Ese debe ser el objetivo al llevar IA a producción.