Diferenciar recuperación, herramientas y estado

«Dar acceso a información» puede significar cuatro cosas distintas: incluir datos directamente, recuperar conocimiento, ejecutar una función o conservar estado entre pasos. Mezclarlas produce aplicaciones difíciles de asegurar y evaluar.

La decisión correcta empieza por preguntar qué necesita el modelo y qué necesita realmente la aplicación.

Contexto directo

La aplicación incorpora datos concretos en la invocación: una solicitud, una tabla pequeña, una política breve o un conjunto de instrucciones.

Tiene sentido cuando la información es pequeña, conocida y pertinente para esa tarea. Es sencillo de depurar porque puedes ver exactamente qué recibió el modelo.

No escala bien cuando el corpus es grande, cambia con frecuencia o requiere permisos y citas granulares.

Recuperación

RAG o un sistema de búsqueda recupera contenido relevante antes de generar. Su función es aportar conocimiento externo a la invocación.

Recuperación es adecuada para documentación, políticas, conocimiento interno o colecciones donde el usuario pregunta «qué dicen nuestras fuentes».

No debe confundirse con una consulta de estado vivo. Preguntar por el saldo actual de un cliente suele corresponder a una herramienta o consulta estructurada, no a recuperar un fragmento de documentación.

RAG tampoco ejecuta acciones por definición. Puede aportar la política para decidir cómo actuar, pero no modifica un ERP por el hecho de haber recuperado un documento.

Herramientas

Una herramienta conecta el modelo con una capacidad externa: consultar inventario, crear una tarea, calcular un precio, obtener un expediente o actualizar un registro.

En APIs actuales, el modelo puede producir una llamada estructurada con nombre y argumentos. OpenAI documenta function calling como un flujo en el que el modelo solicita una función y la aplicación ejecuta el código correspondiente; Anthropic documenta un patrón equivalente de tool use.

La aplicación debe conservar autoridad:

1. el modelo propone;
2. la aplicación valida argumentos;
3. comprueba permisos;
4. ejecuta;
5. registra el resultado;
6. devuelve datos al modelo si hace falta.

El modelo no debería poseer directamente credenciales o permisos que no necesita.

Herramientas de lectura y escritura

Distingue capacidades.

Una herramienta de lectura puede consultar datos. Una de escritura produce efectos: crear, borrar, enviar, aprobar, mover dinero o modificar estado.

Las herramientas con efecto requieren controles más estrictos:

• autenticación;
• autorización;
• validación;
• idempotencia cuando corresponda;
• límites;
• aprobación humana en acciones sensibles;
• auditoría.

No concedas una herramienta de escritura únicamente porque «el modelo podría usarla».

Estado persistente

El estado es información que la aplicación conserva entre invocaciones. Puede incluir:

• usuario;
• expediente;
• fase;
• decisiones;
• IDs de herramientas;
• datos confirmados;
• tareas pendientes;
• versión del proceso.

No confíes en que todo sobreviva como texto conversacional. Para procesos empresariales, guarda estado crítico en una estructura que el sistema pueda validar y consultar.

Recuperación no es memoria

Un sistema puede recuperar un resumen de interacciones anteriores y presentarlo al modelo. Eso es una arquitectura de memoria implementada mediante almacenamiento y recuperación. No significa que el modelo tenga memoria persistente por sí mismo.

Esta distinción importa para privacidad, borrado, consistencia y pruebas.

Workflow frente a agente

Un workflow sigue rutas definidas por código o configuración. Puede contener llamadas a LLM, reglas y herramientas.

Un agente, según una distinción utilizada por Anthropic, permite que el modelo dirija dinámicamente parte del proceso y la selección de herramientas. No es una taxonomía universal, pero resulta útil para explicar autonomía.

Usa la menor autonomía necesaria. Si la secuencia es estable y predecible, un workflow suele ser más fácil de probar, observar y recuperar ante fallos. La autonomía añade valor cuando el orden de pasos no puede predefinirse razonablemente y la decisión dinámica del modelo mejora el resultado.

Ejemplo: «¿puedo ofrecer este producto a este cliente?»

La respuesta puede requerir varios mecanismos:

• RAG recupera la política comercial vigente;
• herramienta consulta stock y condiciones actuales;
• regla verifica región y límite de descuento;
• estado conserva cliente y producto durante el flujo;
• modelo explica el resultado y resume evidencia;
• persona aprueba si el caso supera determinado riesgo.

Intentar resolverlo todo con un prompt largo escondería responsabilidades.

Diseña contratos de herramienta

Una herramienta debe tener nombre, objetivo, argumentos, tipos, límites y errores comprensibles. Define con claridad cuándo usarla y cuándo no.

Si existen varias funciones parecidas, evita ambigüedad. La calidad de la interfaz modelo-herramienta forma parte del sistema. Anthropic, por ejemplo, recomienda documentar herramientas con suficiente contexto, parámetros claros y ejemplos porque la definición condiciona cómo el modelo decide utilizarlas.

Datos estructurados: consulta antes que generación

Existe una categoría que suele olvidarse entre RAG y herramientas: la consulta estructurada. Si una aplicación necesita conocer saldo, fecha, estado o inventario, el dato puede provenir directamente de SQL, ERP, CRM o API. El modelo no necesita «razonar» sobre cómo obtenerlo si la consulta ya está definida.

El LLM puede ayudar a interpretar la intención del usuario y seleccionar la consulta adecuada, pero la fuente de verdad sigue siendo el sistema transaccional.

Diseña resultados de herramientas como contratos

Una herramienta no termina al ejecutar. Su resultado también debe ser tipado y manejable. Distingue éxito, ausencia de dato, conflicto, no autorizado, timeout y error temporal.

Evita devolver al modelo mensajes humanos ambiguos como «algo salió mal». Un resultado estructurado permite decidir si repetir, pedir otro dato o escalar.

También limita el contenido que la herramienta devuelve. Una búsqueda de cliente no debería retornar todo su expediente si la tarea solo necesita un identificador y un estado.

Estado y concurrencia

Si varias acciones pueden ocurrir sobre el mismo caso, define versión o mecanismo de concurrencia. Un modelo que actúa sobre un estado antiguo puede preparar una acción válida para una realidad que ya cambió.

El estado debe tener identidad y actualización controladas fuera del texto conversacional.

Ejercicio: matriz de mecanismos

Para diez necesidades de tu aplicación, clasifica cada una como:

• contexto directo;
• recuperación;
• consulta estructurada;
• herramienta;
• estado;
• regla;
• workflow;
• agente;
• revisión humana.

Añade para cada fila:

• origen del dato;
• permiso;
• validación;
• efecto;
• fallo esperado;
• trazabilidad;
• motivo por el que no eliges el mecanismo alternativo.

Resultado de la lección

Debes terminar con una arquitectura donde conocimiento, datos vivos, acciones y estado tienen mecanismos distintos. En la siguiente lección podrás comparar alternativas reales por latencia, coste, privacidad y dependencia sin reducir la decisión a «qué modelo responde mejor en una demo».