RAG, fine-tuning y tool use resuelven problemas distintos.

A menudo se presentan como técnicas competidoras porque las tres pueden mejorar una aplicación de IA. Ese enfoque suele producir malas decisiones de arquitectura.

Retrieval-augmented generation cambia qué contexto puede ver el modelo durante la inferencia.

Fine-tuning cambia cómo tiende a comportarse el modelo mediante ejemplos.

Tool use cambia qué puede consultar o hacer el modelo fuera de sí mismo.

Son tres superficies de control diferentes.

Si se tratan como sustitutos, tarde o temprano terminas usando datos de entrenamiento para resolver un problema de acceso a información, retrieval para resolver un problema de comportamiento o prompts para simular acciones que deberían ser herramientas explícitas.

La pregunta correcta no es:

¿Qué técnica es mejor?

Sino:

¿Qué le falta realmente al modelo base: conocimiento, comportamiento o acceso a un sistema externo?

La regla de decisión más corta

Usa RAG cuando la respuesta depende de información privada, extensa, cambiante o externa al conocimiento del modelo.

Usa fine-tuning cuando el modelo ya tiene la información necesaria pero produce de forma repetida el estilo, formato, clasificación o comportamiento equivocado.

Usa tools cuando el modelo necesita leer estado en tiempo real, ejecutar cálculos, consultar un sistema autoritativo o realizar una acción.

En producción, los sistemas sólidos suelen combinar las tres técnicas.

Qué cambia realmente RAG

RAG no enseña hechos nuevos al modelo de forma permanente.

Recupera material relevante en tiempo de ejecución y lo coloca dentro del contexto de trabajo del modelo.

Un flujo típico de RAG se parece a esto:

  1. ingerir documentos;
  2. dividirlos o indexarlos;
  3. convertirlos en una representación consultable;
  4. recuperar los pasajes más relevantes para la pregunta;
  5. entregar esos pasajes al modelo;
  6. generar una respuesta basada en ese material.

La Retrieval API de OpenAI, por ejemplo, realiza búsqueda semántica sobre vector stores, mientras que File Search puede combinar búsqueda semántica y por palabras clave sobre archivos antes de generar la respuesta.

La propiedad arquitectónica importante no es la implementación del proveedor. Es que el material fuente permanece fuera de los pesos del modelo.

Eso hace que RAG encaje bien con:

  • documentación interna;
  • políticas y procedimientos;
  • catálogos de productos;
  • bases de conocimiento de soporte;
  • contratos y manuales;
  • colecciones de research;
  • material de referencia que cambia con frecuencia;
  • información específica por usuario o tenant.

Usa RAG cuando la frescura importa

Si mañana cambia un precio, una política o una especificación, no deberías tener que volver a entrenar el modelo.

Deberías actualizar la fuente de verdad y permitir que retrieval entregue el nuevo material.

Por eso RAG es, en gran medida, una técnica de arquitectura de datos más que una técnica de personalización del modelo.

Qué cambia realmente fine-tuning

Fine-tuning adapta el comportamiento del modelo a partir de ejemplos.

En vez de entregar el mismo documento en cada request, proporcionas ejemplos de entrenamiento que muestran cómo debería verse una buena salida. El modelo ajustado pasa a reproducir con mayor probabilidad esos patrones ante entradas similares.

Puede ser útil para:

  • clasificación estable;
  • estructura de salida consistente;
  • convenciones específicas de un dominio;
  • transformaciones repetitivas;
  • consistencia de estilo o tono;
  • fallos recurrentes de instruction following;
  • reducir prompts extensos cuando el comportamiento es suficientemente estable.

La documentación de supervised fine-tuning de OpenAI plantea precisamente el proceso alrededor de ejemplos de entrada y salida deseada, y recomienda construir evals antes de invertir en entrenamiento.

Ese punto importa.

Fine-tuning sin baseline medible es optimización sin objetivo.

Fine-tuning no es una base de datos

Un error común es intentar entrenar al modelo para que ‘sepa’ un conjunto cambiante de documentos.

Eso genera varios problemas:

  • cada actualización exige nuevo entrenamiento;
  • la procedencia de la información se vuelve más difícil de inspeccionar;
  • corregir un dato específico es más costoso;
  • memorizar no equivale a recuperar de forma confiable;
  • se pierde la separación entre comportamiento del modelo y fuente de verdad.

Si el problema es ‘el modelo no tiene la política más reciente’, retrieval suele ser la arquitectura directa.

Si el problema es ‘el modelo ve la política correcta pero sigue produciendo el formato equivocado’, fine-tuning puede ser relevante.

Qué cambia tool use

Las tools dan al modelo interfaces controladas hacia capacidades externas.

Con function calling, por ejemplo, una aplicación expone funciones mediante schemas. El modelo puede decidir que necesita una función, devolver argumentos, recibir el resultado de la aplicación y continuar a partir de ese resultado.

Esto no es lo mismo que RAG.

Retrieval normalmente responde:

¿Qué información debo leer?

Tool use puede responder:

¿Qué es verdad ahora mismo?

o:

¿Qué acción debo ejecutar en otro sistema?

Ejemplos:

  • consultar el balance actual de una cuenta;
  • buscar una orden por ID;
  • calcular impuestos o envío;
  • leer un registro de base de datos;
  • abrir un ticket;
  • emitir un reembolso después de autorización;
  • ejecutar código;
  • buscar en la web;
  • enviar un mensaje;
  • modificar configuración de infraestructura.

El modelo no debería inventar esos resultados desde sus pesos y, muchas veces, tampoco tiene sentido copiarlos primero a un vector store.

La respuesta autoritativa ya vive en el sistema operacional.

RAG vs. tools: la distinción útil

RAG y tools pueden aportar información externa, así que la frontera puede parecer borrosa.

Una regla útil es:

Usa retrieval para conocimiento. Usa tools para estado y operaciones.

Supón que un cliente pregunta:

¿Cuál es su política de reembolso y pueden reembolsar la orden 18472?

La política es conocimiento. Puede vivir en documentación y recuperarse.

Si la orden 18472 existe, si es elegible, cuánto se pagó y si se puede ejecutar el reembolso son hechos operacionales actuales. Eso pertenece detrás de tools.

Un sistema sólido podría:

  1. recuperar la política de reembolso;
  2. llamar get_order(18472);
  3. comparar el estado de la orden contra la política;
  4. pedir aprobación si hace falta;
  5. llamar issue_refund(...);
  6. responder con el estado real de la transacción.

Intentar resolver todo eso sólo con RAG sería un error de arquitectura.

Fine-tuning vs. prompting

Antes de hacer fine-tuning, prueba si el comportamiento se puede corregir con:

  • instrucciones más claras;
  • mejores ejemplos en el prompt;
  • structured outputs;
  • mejor descomposición de la tarea;
  • criterios de evaluación más fuertes.

Fine-tuning tiene costo operacional: construcción de dataset, revisión de calidad, entrenamiento, versionado, evaluación, rollback y monitoreo.

Si un cambio pequeño de prompt arregla el comportamiento, entrenar no aporta mucho.

Fine-tuning se vuelve más atractivo cuando el comportamiento deseado es estable, repetido a alto volumen y difícil de obtener con consistencia sólo mediante prompting.

Tabla práctica de decisión

Problema RAG Fine-tuning Tool use
Documentación privada Buen encaje Normalmente no A veces
Conocimiento que cambia seguido Buen encaje Mal encaje A veces
Estado exacto y actual de cuenta/orden Mal encaje No Buen encaje
Ejecutar una acción externa No No Buen encaje
Formato de salida consistente A veces Buen encaje A veces
Clasificación específica de dominio A veces Buen encaje A veces
Citar material fuente Buen encaje Mal encaje Bueno si el sistema fuente lo soporta
Reducir ejemplos extensos en prompts No Buen encaje No
Corpus grande y consultable Buen encaje Mal encaje A veces
Cálculo dinámico No No Buen encaje

Se pueden combinar por capas

Estas técnicas funcionan mejor cuando se tratan como capas y no como alternativas excluyentes.

Imagina un asistente empresarial de soporte.

Puede usar:

RAG para recuperar documentación de producto y políticas internas.

Fine-tuning para que las decisiones de escalamiento sigan una taxonomía estable y la salida conserve un formato estricto.

Tools para inspeccionar la cuenta del cliente, revisar estado del servicio, crear un ticket o ejecutar un cambio aprobado.

El modelo coordina las capas, pero cada una conserva una responsabilidad distinta.

Eso mejora el debugging.

Si la respuesta usa la política equivocada, inspecciona retrieval.

Si ve la evidencia correcta pero viola de forma repetida el formato requerido, inspecciona prompting o fine-tuning.

Si reporta el balance actual incorrecto, inspecciona la integración de tools y el sistema fuente.

Sin esa separación, todos los fallos terminan describiéndose como ‘el modelo se equivocó’.

La evaluación debe corresponder a la capa

Cada técnica necesita un objetivo de evaluación distinto.

Evalúa RAG por calidad de retrieval

Mide si el sistema recupera la evidencia necesaria para responder correctamente.

Señales útiles:

  • recall de pasajes relevantes;
  • precisión de chunks recuperados;
  • calidad del ranking;
  • corrección de citas;
  • fidelidad de la respuesta a la evidencia;
  • comportamiento cuando no existe evidencia suficiente.

Evalúa fine-tuning por comportamiento

Compara el modelo ajustado contra un baseline usando un dataset separado.

Mide exactamente lo que entrenaste:

  • accuracy de clasificación;
  • cumplimiento de formato;
  • task success;
  • consistencia de estilo;
  • adherencia a políticas;
  • latencia y ahorro de tokens cuando corresponda.

Evalúa tools por corrección de ejecución

Revisa:

  • si eligió la herramienta correcta;
  • si los argumentos fueron válidos;
  • si respetó permisos;
  • si los side effects coincidieron con la intención;
  • si los reintentos duplicaron acciones;
  • si manejó correctamente fallos del tool.

Una aplicación puede tener retrieval excelente y aun ser insegura si su capa de tools está mal controlada.

Tres errores a evitar

1. Meter todo en un vector database

No todo dato externo pertenece en RAG.

Datos muy estructurados o en tiempo real suelen pertenecer detrás de una API o una tool de base de datos.

2. Hacer fine-tuning antes de tener evals

Si no puedes medir mejora, no puedes saber si el entrenamiento ayudó o sólo cambió el modo de falla.

3. Dar demasiada autoridad a las tools

El acceso a herramientas debe ser estrecho, tipado, auditable y con permisos explícitos.

Un modelo que necesita leer una orden no debería recibir automáticamente permiso para reembolsarla.

La regla de diseño

Usa la técnica que corresponda a la capacidad faltante.

Si el modelo necesita conocimiento relevante adicional, recupéralo.

Si necesita comportamiento más consistente, optimiza prompting o fine-tuning.

Si necesita estado en vivo o capacidad de actuar, dale una tool controlada.

Combina técnicas sólo donde la aplicación realmente necesite esa combinación.

Así el sistema es más fácil de evaluar porque conocimiento, comportamiento y acciones permanecen separados.

La mejor arquitectura no es la que usa más técnicas de IA.

Es la que da a cada técnica una responsabilidad clara y una razón medible para existir.

Fuentes