Generación de prompts, RAG o ajuste fino: Diagnóstique la capa correspondiente antes de elegir.
Una forma práctica de elegir entre la generación de prompts, RAG y el ajuste fino en 2026, utilizando tres preguntas, un flujo de decisión, los costos, la actualidad de la información y los errores comunes.
Fuentes: Fine-Tuning vs RAG vs Prompting: How to Actually Choose in 2026
En el trabajo aplicado con LLM, el error recurrente más costoso es recurrir al ajuste fino cuando el problema real es un prompt o una brecha en la recuperación de información. En aproximadamente nueve de cada diez casos, un equipo convencido de que necesita ajustar el modelo está a punto de perder tres semanas y un presupuesto para GPU en resolver el problema incorrecto. Este error es casi siempre evitable.
La confusión es comprensible. El ajuste fino, la generación mejorada por recuperación de información (RAG) y la ingeniería de prompts modifican todo lo que produce un modelo, por lo que parecen intercambiables. Pero no lo son. Cada uno actúa en una capa distinta del sistema, así que cuando queda claro dónde radica el problema, la elección suele ser obvia.
Tres preguntas, no tres técnicas rivales
Es útil dejar de tratarlas como técnicas competidoras y verlas como tres preguntas diferentes que se le plantean a un modelo:
- Inducción modifica la forma en que se le hace una pregunta al modelo. El comportamiento se dirige en el momento de la inferencia, y no se necesita entrenamiento ni alojamiento alguno.
- RAG cambia lo que el modelo sabe en ese momento. Coloca información externa, actual o propietaria en la ventana de contexto cuando llega una consulta.
- Afinamiento modifica el comportamiento por defecto del modelo. Patrones, estilo o habilidades para tareas se integran en los pesos del modelo.
La idea clave es que la inducción y RAG actúan sobre el contexto, es decir, la entrada, mientras que el afinamiento actúa sobre los parámetros, es decir, el propio modelo. Los problemas de conocimiento son casi siempre problemas de contexto. Los problemas de comportamiento a veces son problemas de parámetros. Si no está claro si la queja se refiere a “el modelo no sabe X” o “el modelo no actúa como Y”, aún no ha llegado el momento de elegir una técnica.
Cuando el prompt es suficiente
Los modelos de vanguardia actuales son excepcionalmente capaces desde el primer uso. Comience asumiendo que el modelo ya puede realizar la tarea y que su objetivo es potenciar esa capacidad. La mayoría de las quejas del tipo “el modelo es malo en esto” en realidad se deben a que el prompt es vago.
El uso de prompts es adecuado cuando:
- El modelo base ya cuenta con los conocimientos y habilidades necesarias y solo requiere orientación.
- Los requisitos cambian con frecuencia, ya que un prompt se puede editar en segundos.
- Es necesario entregar el resultado hoy y no en la siguiente fase de desarrollo.
- El trabajo consiste en razonamiento, clasificación, extracción, resumen o generación a partir de la información ya incluida en el prompt.
El costo es casi nulo, la iteración es inmediata y lo único que hay que mantener es el texto. Este es siempre el punto de partida adecuado.
Cuando RAG es la solución
RAG existe para el conocimiento. Cuando una respuesta correcta depende de información privada, propietaria, más reciente que el punto de corte de entrenamiento o demasiado grande como para caber en un prompt, es necesario realizar una recuperación.
Es la opción adecuada cuando:
- Las respuestas deben reflejar datos actuales, como los precios de hoy, la documentación de esta semana o el inventario en tiempo real.
- El conocimiento es propietario, como una wiki interna, registros de clientes o un catálogo de productos.
- El corpus es grande y está en constante cambio. Pegar una base de conocimientos de 4,000 páginas en cada solicitud es poco práctico, y volver a ajustarla cada vez que cambia un documento es absurdo.
- La trazabilidad es importante, es decir, la capacidad de indicar qué fuente generó una respuesta, lo cual ayuda enormemente con la confianza y la depuración.
La frescura es su principal ventaja. Edita un documento en el almacén vectorial y la siguiente consulta ya reflejará el cambio, sin necesidad de reentrenamiento ni reimplementación.
Cuándo el ajuste fino tiene sentido
Esta es una herramienta que la gente utiliza demasiado pronto. El ajuste fino es eficaz para la forma, el estilo y la especialización en tareas específicas. Sin embargo, es deficiente para enseñar nuevos hechos. Inyectar datos mediante ajuste fino es un método conocido por fallar: el modelo absorbe la estructura de las respuestas sin aprender de manera fiable su contenido, lo que provoca que genere información falsa con total confianza.
Es la opción adecuada cuando:
- Se necesita un formato o estilo de salida consistente y resulta tedioso especificarlo en cada solicitud.
- La tarea es específica y de gran volumen, y un modelo ajustado a menor escala puede igualar la calidad de uno grande a una fracción del costo por llamada.
- Los prompts deberían acortarse, con ejemplos de pocos casos e instrucciones integradas en los pesos, para que cada solicitud sea más económica y rápida.
- Tanto el uso de prompts como RAG han sido llevados al límite posible, pero sigue habiendo una brecha específica y medible.
Esa última condición es la más importante. El ajuste fino rara vez es la primera herramienta que se utiliza; se emplea después de que los prompts y RAG hayan cubierto la mayor parte del camino, cuando queda una brecha persistente y bien definida, generalmente en el comportamiento, la latencia o el costo por solicitud a gran escala.
Comparación de los tres métodos
Una comparación aproximada muestra sus diferencias:
- Prompts: sin costo de desarrollo, costo por solicitud más alto en prompts largos, se pueden cambiar al instante, no tienen mecanismo propio para gestionar la actualidad de la información.
- RAG: costo moderado de desarrollo y mantenimiento, costo por solicitud algo más alto debido al contexto adicional, es el mejor opción en cuanto a actualidad de la información.
- Ajuste fino: alto costo inicial, costo potencialmente más bajo por llamada, más lento para realizar cambios y menos eficaz cuando los hechos cambian.
Flujo de toma de decisiones
Responda a las preguntas en orden y deténgase en la primera que resuelva el problema.
- ¿Un prompt mejor lo solucionaría? Las instrucciones claras, unos pocos ejemplos y un formato de salida estructurado deben ir primero. Alrededor del 80% de los problemas terminan aquí. Si el modelo tiene la capacidad y solo necesita orientación, el trabajo está hecho.
- ¿La tarea requiere información que el modelo no posee? Si la corrección depende de conocimientos privados, recientes o de un corpus grande, añada RAG. Los hechos deben recuperarse y no entrenarse.
- ¿Existe una brecha específica y medible en el comportamiento, el formato o el costo que ni los prompts ni RAG pueden cerrar? Solo ahora entra en juego el ajuste fino, y se necesita una evaluación real que muestre dicha brecha, además de datos etiquetados para cerrarla.
Muchos equipos adquieren el hábito de elegir solo uno de ellos. Los sistemas de producción más robustos los combinan: un modelo ajustado fino que sigue el estilo de la empresa, alimentado por un pipeline RAG para obtener conocimientos actualizados, y guiado por prompts bien diseñados que unen todo. Cada capa realiza su propia función.
Un caso concreto: un asistente de soporte
Tomemos un asistente de soporte al cliente y supongamos que llegan tres quejas diferentes.
- No puede responder preguntas sobre el producto. Para eso se necesita RAG, ya que requiere documentación que nunca ha visto. El ajuste fino enseñaría el tono de las respuestas, pero no los hechos.
- Sus respuestas son correctas, pero demasiado largas y no se ajustan al estilo de la marca. Lo primero es dar una indicación, junto con una instrucción de estilo y un ejemplo breve. Si esto resulta incoherente a gran escala, se debe realizar un ajuste fino para el uso por voz.
- Es preciso y se ajusta al estilo de la marca, pero cinco millones de llamadas al mes lo hacen demasiado costoso. Es mejor ajustar un modelo más pequeño con transcripciones de las respuestas de modelos grandes de calidad, de modo que un modelo más económico pueda manejar ese volumen.
Un producto, tres problemas, tres herramientas. La habilidad radica en diagnosticar en qué capa se encuentra el problema, no en conocer las técnicas.
Un costo que nadie calcula
Estos enfoques difieren no solo en el esfuerzo inicial. Sus costos tienen formas completamente distintas, y la elección adecuada suele depender de dónde se destinan los recursos.
La generación de prompts cuesta casi nada al inicio y se factura por llamada. Sin embargo, un prompt efectivo suele ser largo, con instrucciones detalladas, ejemplos de pocos casos y contexto recuperado, y cada token se cobra en cada solicitud. Con millones de llamadas, un prompt del sistema de 2,000 tokens se convierte en un gasto significativo. El caché de prompts atenúa esto considerablemente, ya que el prefijo estable se almacena en caché y se cobra a una fracción de la tarifa, pero la estructura se mantiene: no hay costo de creación, sino que se paga con una factura más alta en cada llamada.
RAG implica un costo de implementación moderado, que incluye un almacén de vectores, un pipeline de incrustación y lógica de recuperación, además de un costo continuo para mantener el índice actualizado. En el momento de la inferencia, la consulta se incrusta y el contexto recuperado se cobra como tokens de prompt. Por lo tanto, las llamadas a RAG suelen ser más costosas que un simple prompt, ya que se agrega contexto en lugar de eliminarlo. Esto se acepta porque la alternativa, un modelo que cometa errores graves con los datos propios de la empresa, es inaceptable.
El ajuste fino invierte la tendencia. Requiere un pago inicial elevado para la preparación de datos, el uso de GPUs, la evaluación y el trabajo de ingeniería, pero a cambio el costo por llamada suele reducirse. Las instrucciones y ejemplos están incluidos en los pesos, por lo que los prompts se acortan, y un modelo pequeño ajustado puede reemplazar a uno grande que necesite prompts complejos. A un alto volumen, los ahorros por llamada se acumulan hasta superar con creces el costo inicial. A un volumen bajo, nunca compensan los gastos.
La regla general: el ajuste fino es una inversión que se amortiza a medida que aumenta el volumen de llamadas. Sin suficiente tráfico para que los ahorros por llamada cubran el costo de su desarrollo y mantenimiento, las cuentas no salen positivas, y la mayoría de los proyectos no generan tanto tráfico. Los métodos de prompt y RAG siguen siendo más económicos en general hasta que se alcanza una escala real.
La actualidad resuelve los debates en silencio
Un factor acaba con los debates más rápido que cualquier otro: la frecuencia con la que cambia la respuesta correcta y la rapidez con la que el sistema debe reflejarlo.
- La respuesta nunca cambia, como ocurre en las tareas de razonamiento general y de lenguaje. La actualidad es irrelevante, por lo que no hay necesidad de actuar rápidamente.
- La respuesta cambia constantemente y debe aparecer de inmediato, como en el caso de los precios, el inventario, las noticias de hoy o un documento editado hace cinco minutos. En estos casos, RAG es claramente superior. Basta actualizar la fuente para que la siguiente consulta lo refleje. El ajuste fino es una trampa aquí, ya que el modelo se vuelve obsoleto en cuanto los datos cambian y el reentrenamiento no puede mantener el ritmo.
- Lo que se busca capturar es un comportamiento estable y no hechos en constante cambio, como el estilo de escritura de una persona o un esquema de salida fijo. El ajuste fino es adecuado, ya que lo que ya está integrado no se vuelve obsoleto.
Una historia común: un equipo perfecciona un modelo basado en una versión actualizada de su base de conocimientos, lo lanza al uso y, tres meses después, descubre que el modelo responde con entusiasmo preguntas sobre una versión del producto que ya no existe. Eso no es un defecto del proceso de perfeccionamiento; se trata de utilizar la herramienta inadecuada para resolver un problema sensible a la actualidad, y RAG siempre ha sido la solución.
Dónde cometen errores los ingenieros
Existen algunos patrones que aparecen constantemente:
- Perfeccionar el modelo para introducir conocimientos nuevos. Este método es poco fiable y pierde validez tan pronto como cambian los datos. Utilice RAG.
- Recurrir primero al perfeccionamiento del modelo porque parece más serio que el uso de instrucciones. El uso de instrucciones no es un truco para principiantes, y ofrece el mayor valor por hora invertida.
La versión breve
En 2026, lo estándar es: primero el prompt, luego recuperar la información cuando sea necesaria, y ajustar fino únicamente para cerrar una brecha de comportamiento medida. Las consideraciones de costo, esfuerzo y actualidad deben guiar la decisión, no qué técnica suena más impresionante en una reunión.
Los equipos que entregan rápido y a bajo costo diagnostican primero la capa lógica antes de usar las herramientas. Si eso se hace bien, la mayoría de las decisiones difíciles desaparecen.
Leer más
- De la demostración a la producción RAG: fragmentación, pgvector, reclasificación y FastAPI — Qué contiene realmente un backend RAG en producción: ETL y fragmentación, embeddings en pgvector, índices HNSW, reclasificación con cross-encoder y un orquestador FastAPI.
- Ajuste fino de un modelo de visión en Apple Silicon con MLX y Ollama — Reduce las alucinaciones al leer gráficos ajustando finamente Qwen2-VL con MLX LoRA en una Mac, luego conviértelo a formato GGUF y sírvelo a través de Ollama en una aplicación RAG existente.