Fine-tuning vs RAG vs prompting: ¿cuál deberías usar?
Traducción automática
Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Usa prompting para aclarar la tarea, generación aumentada por recuperación (RAG) para aportar conocimiento actual o privado, y fine-tuning para cambiar comportamientos repetibles del modelo. Estas técnicas resuelven problemas distintos y a menudo forman parte del mismo sistema.
Empieza con una línea base de prompting medida. Añade RAG cuando las respuestas necesiten evidencia externa o datos que cambien con frecuencia. Considera fine-tuning para errores persistentes de tono, clasificación, tool use o lenguaje de dominio cuando existan suficientes ejemplos revisados. Para errores de formato de respuesta, prueba primero con structured output restringido por un esquema.
Elige según los errores observados, la frecuencia con la que cambian los datos y los datos disponibles para probar una corrección.
Tabla de decisión
| Problema | Primera intervención | Motivo |
|---|---|---|
| Las instrucciones no son claras o faltan ejemplos | Prompting | Permite comprobar si unas instrucciones y unos ejemplos más claros resuelven los fallos observados. |
| Los datos son privados, deben citarse o cambian a menudo | RAG | La recuperación de información actualiza el conocimiento sin reentrenar y puede conservar la procedencia de las fuentes. |
| Un comportamiento estable sigue fallando tras probar los prompts | Considerar fine-tuning | Los ejemplos revisados pueden enseñar estilo, etiquetas o comportamiento al usar herramientas; compara el resultado con la línea base de prompting. |
| Una línea base de prompting cuidadosa sigue fallando | Probar otro modelo o diseño del sistema | Compara alternativas con los mismos casos; un fallo de prompting por sí solo no demuestra que el fine-tuning vaya a ayudar. |
| Las respuestas necesitan datos actuales y comportamiento especializado | RAG más fine-tuning | La recuperación de información aporta evidencia, mientras que el fine-tuning cambia cómo la utiliza el modelo. |
Usa prompting primero
Prompting es una forma de diagnosticar fallos con poca configuración. Define la tarea, el contrato de salida, los ejemplos, las herramientas permitidas y las condiciones de rechazo. Crea un conjunto de evaluación pequeño antes de añadir más infraestructura. Si un prompt mejor resuelve los fallos representativos, detente ahí.
Si un prompt cada vez más largo resulta más difícil de mantener, identifica qué se ha añadido. Los datos cambiantes del producto pueden suministrarse mediante recuperación de información. Los ejemplos repetidos de comportamiento pueden servir como datos de entrenamiento. La longitud del prompt por sí sola no demuestra que ninguno de estos cambios vaya a mejorar el resultado.
Usa RAG para el conocimiento y la procedencia
RAG encaja con manuales de producto, políticas, documentos internos, acontecimientos recientes y respuestas que deben citar una fuente. El artículo original sobre RAG combina un generador con pasajes recuperados; la evidencia recuperada se proporciona en el momento de la solicitud. Su calidad depende del análisis, la segmentación en fragmentos, la recuperación de información, la clasificación por relevancia, los permisos y la compatibilidad con citas. Cambiar solo el generador no aporta una fuente que la recuperación de información haya omitido.
RAG no es un método de entrenamiento del comportamiento. Puede mostrar al modelo un ejemplo o una regla, pero no hace que ese comportamiento sea estable en todas las solicitudes.
En un asistente de soporte, una respuesta desactualizada sobre la garantía indica que falta la política vigente: proporciónala mediante recuperación de información. Si la política correcta ya está presente, pero el asistente asigna repetidamente una categoría incorrecta a la reclamación, prueba primero con ejemplos más claros. El fine-tuning pasa a ser una opción si ese error de clasificación persistente se mantiene y existen ejemplos de entrenamiento revisados.
Usa fine-tuning para comportamientos repetibles
El fine-tuning supervisado se entrena con ejemplos de entrada y salida, tal como se describe en la guía de entrenamiento de TRL. Es una opción para clasificación, estilo de extracción, estructura de respuesta, terminología de dominio y patrones recurrentes de tool use. Para fallos que solo afectan al formato, prueba primero con structured output restringido por un esquema si tu runtime lo admite. Una estructura válida aún requiere comprobaciones de que los valores de los campos sean correctos.
El fine-tuning requiere datos de entrenamiento revisados, un conjunto de evaluación separado, versionado de modelos y una vía de rollback. No hagas fine-tuning sobre datos que cambian a menudo cuando la recuperación de información puede proporcionarlos en el momento de la solicitud.
Una secuencia práctica
- Define el éxito y crea un conjunto de evaluación representativo.
- Establece una línea base basada solo en prompting con el modelo más potente aceptable.
- Añade RAG si los fallos se deben a evidencia ausente o cambiante.
- Recopila y revisa ejemplos de los fallos estables que persistan.
- Haz fine-tuning solo si la mejora de calidad, latencia o coste compensa los datos y las operaciones adicionales del modelo.
- Repite la misma evaluación después de cada cambio en el prompt, el índice, el modelo o el adaptador.
Lecturas recomendadas
- Fine-tuning de LLMs aborda los datos, LoRA, la evaluación y el despliegue.
- Métricas de evaluación de RAG muestra cómo localizar fallos por etapa del pipeline.
- Context engineering para agentes AI aborda el contexto de runtime que rodea a los prompts y la recuperación de información.