Fine-tuning vs RAG vs prompting: una guía de decisión

Cuando un modelo de lenguaje no se comporta como quieres, tienes tres grandes palancas que accionar: cambiar el prompt, darle al modelo el material adecuado para leer, o cambiar los pesos del modelo. Esto es prompting, generación aumentada por recuperación (RAG) y fine-tuning. Suelen presentarse como rivales, pero responden a preguntas distintas, y la mayoría de los equipos recurre primero a la más pesada y costosa cuando una más ligera habría bastado.

Esta guía trata de elegir en el orden correcto. El orden importa porque cada palanca tiene un coste distinto, un modo de fallo distinto y un problema distinto que realmente resuelve. Si aciertas con el diagnóstico, la elección suele hacerse sola.

Qué cambia realmente cada palanca

Conviene ser preciso sobre qué estás modificando.

• Prompting cambia las instrucciones y el contexto que envías en el momento de la petición. El modelo queda intacto; estás dirigiendo un sistema fijo con palabras y ejemplos.
• RAG cambia el conocimiento disponible para el modelo en el momento de la petición. Recuperas documentos relevantes y los colocas en el contexto del modelo antes de que responda. El modelo sigue intacto; has cambiado lo que le toca leer.
• Fine-tuning cambia el modelo en sí. Continúas el entrenamiento con tus propios ejemplos para que los pesos se desplacen hacia el comportamiento deseado. Esta es la única palanca que altera el modelo.

Fíjate en que dos de las tres dejan el modelo en paz. Esa es la idea central: la mayoría de los problemas no son problemas del modelo. Son problemas de lo que pediste o de lo que aportaste.

Prompting: la opción por defecto, no el premio de consolación

El prompting tiene fama de ser la opción barata que usas antes de hacer el trabajo "de verdad". Ese encuadre está al revés. El prompting es lo primero que hay que probar porque es rápido, reversible y sorprendentemente capaz. Una instrucción clara, uno o dos ejemplos resueltos, un formato de salida definido y una indicación explícita de qué hacer ante la duda: esto resuelve buena parte de las quejas de "el modelo está actuando raro".

El prompting es la herramienta adecuada cuando el modelo ya tiene la capacidad y el conocimiento, y solo necesitas extraerlo de forma fiable. Sus límites también son claros. No puede enseñarle al modelo hechos que nunca aprendió, y no puede imponer un comportamiento de forma fiable a través de miles de entradas variadas si la instrucción es larga y frágil. Cuando tu prompt se convierte en un reglamento desbordado que aún deja escapar casos límite, eso es señal de que quizá necesitas otra palanca, pero deberías llegar a esa conclusión tras agotar primero el prompting, no saltándotelo.

RAG: cuando el problema es el conocimiento

Si los fallos del modelo son sobre lo que sabe —le faltan tus documentos privados, no puede ver información reciente, inventa datos concretos que nunca recibió—, el problema es de conocimiento, y la respuesta suele ser RAG, no fine-tuning. Este es el diagnóstico erróneo más común del sector. Los equipos sienten que el modelo "no conoce nuestro dominio" y suponen que deben reentrenarlo, cuando en realidad lo que necesitan es entregarle las páginas adecuadas para leer.

RAG brilla porque el conocimiento que vive en documentos recuperables se mantiene actualizado, auditable y fácil de corregir. Actualiza un documento y las respuestas del modelo se actualizan con él. Muestra qué pasajes se usaron y una persona puede verificar la respuesta. El fine-tuning, en cambio, hornea el conocimiento dentro de los pesos, donde es difícil de inspeccionar, difícil de actualizar y propenso a quedarse desfasado. Como regla: si la respuesta debería cambiar cuando cambian tus documentos, usa recuperación, no entrenamiento.

Fine-tuning: cuando el problema es el comportamiento, no los hechos

El fine-tuning se gana su sitio cuando necesitas cambiar cómo se comporta el modelo de una manera que el prompting no puede alcanzar de forma fiable: un tono o formato consistente a gran volumen, una tarea especializada y acotada que el modelo base maneja con torpeza, o una salida estructurada de la que sigue desviándose pese a instrucciones claras. La señal para el fine-tuning es un comportamiento que puedes demostrar con muchos ejemplos pero que no puedes capturar en una instrucción breve.

Es la palanca más pesada por una buena razón. Requiere datos de entrenamiento curados, una ejecución de entrenamiento, evaluación y un compromiso de mantenimiento, porque un modelo afinado es algo que ahora posees y debes mantener alineado a medida que tus necesidades evolucionan. Y algo crucial: el fine-tuning es malo para enseñar hechos. Desplaza tendencias y estilos con mucha más fiabilidad de la que implanta una base de conocimiento. Recurrir al fine-tuning para arreglar una laguna de conocimiento es la forma cara de obtener un resultado frágil.

La decisión en orden

Una secuencia práctica, primero lo más barato y reversible:

1. Empieza con el prompting. Escribe la instrucción más clara que puedas, añade unos ejemplos, define la salida e indica el plan B cuando el modelo no esté seguro. Mide sobre casos reales.
2. Si los fallos son de conocimiento, añade RAG. Hechos que faltan, información obsoleta, documentos privados, datos inventados: dale al modelo el material adecuado para leer.
3. Si los fallos son de comportamiento consistente, considera el fine-tuning. Un patrón demostrable que no puedes comprimir en una instrucción, repetido a escala.
4. Combina cuando esté justificado. No son mutuamente excluyentes. Una configuración madura habitual es un modelo afinado y RAG y un prompt cuidado, cada uno haciendo el trabajo para el que es mejor.

La mayoría de los equipos debería recorrer esta lista, no saltar al final. El orden es un gradiente de coste: cada paso hacia arriba exige más esfuerzo, más datos y más mantenimiento continuo.

Cómo saber qué problema tienes

La forma más rápida de elegir es diagnosticar el fallo con honestidad. Ante una mala respuesta, pregúntate: ¿lo habría arreglado el documento adecuado? Si es así, es un problema de conocimiento, y RAG es tu palanca. Pregúntate: ¿lo habría arreglado una instrucción o un ejemplo más claros? Si es así, es un problema de prompting. Pregúntate: ¿es un patrón que el modelo se equivoca de forma consistente, que puedo mostrar en muchos ejemplos pero no decir en una frase? Si es así, el fine-tuning entra en juego.

Cuando más de uno es cierto, arregla primero el más barato y vuelve a medir. A menudo el arreglo más barato resuelve lo suficiente del problema como para que el caro resulte innecesario. Los equipos que se atascan suelen ser los que eligieron una palanca según cuál sonaba más seria, en lugar de según de qué estaban hechos realmente los fallos.

Lo que ninguna de ellas arregla

Ninguna palanca convierte un modelo en algo que no es. El prompting no puede invocar conocimiento que nunca estuvo presente. RAG ancla las respuestas en el texto suministrado pero no hace que el modelo razone mejor, y hereda los errores de tus documentos. El fine-tuning desplaza el comportamiento pero no instala hechos de forma fiable y no rescatará una tarea que el modelo subyacente fundamentalmente no puede hacer. Las tres mejoran la extracción, el anclaje o la tendencia; ninguna fabrica capacidad de la nada. Conocer el techo de cada una te evita gastar semanas en la equivocada.

En resumen

Prompting, RAG y fine-tuning no son rivales; son respuestas a tres preguntas distintas. El prompting arregla cómo lo pediste. RAG arregla qué puede leer el modelo. El fine-tuning arregla cómo se comporta el modelo. Diagnostica el fallo y luego sube el gradiente de coste solo hasta donde el problema lo exija: empieza por el prompt, añade recuperación cuando la laguna sea de conocimiento, y reserva el fine-tuning para comportamientos que puedas demostrar pero no enunciar. La palanca más barata que resuelve tu problema es la correcta.