Todo el mundo tiene una opinión sobre el fine-tuning frente al RAG. Deslízate por cualquier foro de IA y encontrarás hilos acalorados llenos de diagramas de arquitectura y afirmaciones de benchmarks. La mayoría de las personas que escriben esos comentarios nunca han entrenado un modelo con sus propios datos ni han visto fallar silenciosamente un pipeline de RAG en producción.

Pasé meses realizando experimentos. Doce de ellos, para ser exactos. Hice fine-tuning de LLMs. Hice fine-tuning de embedders. Construí seis configuraciones de RAG diferentes. El dominio era la predicción financiera, específicamente intentando pronosticar resultados de mercado ruidosos a partir de datos históricos desordenados. Me impuse estándares estadísticos estrictos porque quería respuestas reales, no afirmaciones de publicaciones de blog.

La mayoría de los experimentos fallaron. Resultó que esos fracasos fueron mucho más útiles que cualquier éxito fortuito.

La dura verdad sobre la señal

Antes de entrar en detalles, aquí está la lección que lo une todo. El fine-tuning y el RAG son herramientas para cambiar lo que un modelo sabe o lo que ve. No son varitas mágicas que fabrican señal de la nada. Si tus datos subyacentes no contienen un patrón real y explotable, estas técnicas no crearán uno. Solo te ayudarán a construir una historia más convincente en torno al ruido aleatorio.

En la predicción financiera, esta trampa es especialmente peligrosa. Los mercados son ruidosos por diseño. Cuando conectas un LLM potente a datos de precios históricos y añades recuperación (retrieval) o fine-tuning, no obtienes automáticamente una ventaja. Obtienes una forma más articulada de racionalizar lanzamientos de moneda. Si la señal no está ahí, el modelo se vuelve muy bueno mintiéndote. Tienes que comprobar eso primero.

Cuando lo más grande memoriza en lugar de aprender

Mi primer gran error fue asumir que la escala lo solucionaría todo. Probé un modelo de 14 mil millones de parámetros frente a uno de 7 mil millones de parámetros con exactamente 777 ejemplos de entrenamiento. El modelo más grande logró un eval_loss notablemente mejor. Su perplejidad disminuyó. En el papel, estaba aprendiendo.

Luego analicé la tasa de éxito (win rate), la tasa real a la que el modelo realizaba predicciones correctas. El modelo de 14B funcionó significativamente peor que el de 7B. Había memorizado el ruido de entrenamiento. Con menos de 3,000 ejemplos, el modelo más grande tenía capacidad suficiente para sobreajustarse (overfit) a correlaciones espurias y fluctuaciones aleatorias en los datos. Básicamente, construyó una tabla de consulta de ruido.

Probé ocho configuraciones de RAG distintas para tareas de predicción. En general, añadir la recuperación cambió aproximadamente el 30 por ciento de las decisiones del modelo. Eso suena impactante. No lo fue. Esos cambios fueron puro ruido. La precisión general no mejoró. Lo que sí cambió fue la confianza del modelo. El RAG hizo que el sistema sonara más seguro, citara más fuentes y produjera justificaciones más largas. Todo esto mientras seguía cometiendo los mismos errores.

Este exceso de confianza es un riesgo de producto. Un usuario ve las citas y asume que el modelo ha hecho su tarea. En realidad, estaba haciendo conjeturas con apariencia sofisticada.

La lección más dolorosa provino del backtesting de una variante de RAG. Mostró un beneficio anual del 11 por ciento. A simple vista, parece una estrategia ganadora. Pero su AUC, el área bajo la curva ROC y una medida de la capacidad de clasificación, era de 0,486. Eso es peor que lanzar una moneda al aire, que se sitúa en 0,500. El beneficio fue una casualidad del periodo específico del mercado, no una ventaja repetible. Usar solo el P&L como métrica es peligroso. Los mercados reparten rachas de suerte todo el tiempo. Necesitas métricas de habilidad estadística para separar las casualidades de la competencia.

Saber qué hace realmente cada herramienta

Entonces, ¿en qué situación nos deja esto? Usa el fine-tuning cuando el modelo necesite aprender nuevas palabras, formatos específicos o un estilo distintivo. Usa RAG cuando el modelo necesite acceso a hechos, repositorios de código o memoria institucional que resida fuera de sus pesos. No uses ninguna de las dos herramientas para descubrir señales en datos que no las tienen. Si el patrón subyacente no está ahí, la recuperación y el fine-tuning solo te ayudarán a vestir el ruido con un traje más elegante.

El verdadero cuello de botella

La infraestructura para el fine-tuning y el RAG nunca ha sido tan fácil de configurar. Puedes montar un pipeline en una tarde. La técnica ya no es el cuello de botella. La evaluación lo es. La mayoría de los equipos se saltan el arduo trabajo estadístico y, en su lugar, celebran métricas de vanidad. Lanzan sistemas que suenan inteligentes pero fallan silenciosamente.

Realiza pruebas honestas antes de gastar dinero. Cuestiona tus métricas. Comprueba si hay sobreajuste (overfitting). Asegúrate de que el modelo sea realmente mejor,