En el post anterior vimos cómo guiar al modelo con ejemplos (ICL). Hoy damos el paso que convierte texto en resultados: habilitar herramientas (APIs/funciones) para que el LLM calcule, consulte sistemas, cree tickets, envíe correos o dispare flujos en n8n.

¿Qué significa “que el modelo use herramientas”?

Es permitir que el LLM emita una llamada estructurada (JSON) a funciones que tú expones: calcular impuestos, buscar en DB, consultar un CRM, etc. El orquestador ejecuta y devuelve el resultado al modelo, que lo integra en su respuesta final.

• Modelo: decide cuándo y qué herramienta invocar.
• Herramienta: función/APIs con schema de entrada/salida.
• Orquestador: valida, ejecuta, registra y controla errores (n8n/cola).

Diseño de herramientas: contratos claros o nada

Define cada herramienta con:

1. Nombre descriptivo (snake_case) y propósito de una línea.
2. Schema de entrada (tipos, rangos, obligatorios, enums).
3. Política de uso (cuándo usarla / cuándo NO usarla).
4. Ejemplos 1–2 válidos y 1 contraejemplo.
5. Límites: timeout, reintentos, presupuesto.

{
  "name": "crear_ticket_soporte",
  "description": "Crear ticket en el sistema de soporte",
  "input_schema": {
    "type": "object",
    "required": ["email","asunto","prioridad"],
    "properties": {
      "email": {"type":"string","format":"email"},
      "asunto": {"type":"string","minLength":5,"maxLength":140},
      "prioridad": {"type":"string","enum":["baja","media","alta"]},
      "descripcion": {"type":"string","maxLength":2000}
    }
  },
  "use_policy": "Usar solo si el usuario solicita ayuda accionable; NO usar para dudas generales."
}

Política de herramientas (para el LLM)

• Intención primero: si hay acción explícita → considera herramienta; si es informativo → responde sin herramientas.
• Parámetros válidos: nunca inventes valores ausentes; pregunta antes de ejecutar.
• Modo seguro: ante ambigüedad o alto impacto → pedir confirmación.
• Una cosa a la vez: evita cadenas largas; máximo N pasos por interacción.

Reglas:
1) Usa herramientas solo si aceleran o hacen verificación objetiva.
2) Si falta dato obligatorio -> solicita aclaración concisa.
3) Si la acción es irreversible -> pide confirmación humana.
4) Devuelve siempre un resumen de lo ejecutado (id, estado).

Planner → Executor (breve y auditable)

Patrón en dos fases: el modelo propone un plan JSON y luego el orquestador ejecuta paso a paso con validación.

{
  "plan": [
    {"tool":"buscar_cliente","args":{"email":"ana@ejemplo.com"}},
    {"tool":"crear_ticket_soporte","args":{"email":"ana@ejemplo.com","asunto":"No llega el pedido","prioridad":"media"}}
  ],
  "limits":{"max_steps":3,"max_cost":"$0.02","timeout_ms":8000}
}

Seguridad y cumplimiento mínimo

• Lista blanca de herramientas y validación estricta de args.
• Scopes/roles: tokens de solo lectura cuando sea posible.
• PII: enmascara/anonimiza; registra lo mínimo necesario.
• Aprobación humana para acciones sensibles (pagos, borrados, cambios masivos).

Observabilidad y control de costes

• Traza por paso: prompt → herramienta → result → costo → p95.
• Política de reintentos (máx. 2) con backoff y idempotencia (request_id).
• Presupuesto por interacción y umbrales de alerta.

Micro-workflow n8n: “Herramientas con modo seguro”

1. Webhook → recibe la solicitud del usuario.
2. LLM (decider) → decide si usar herramienta y cuál (emite JSON {tool,args}).
3. Function → valida args contra schema; si falta dato, responde con pregunta aclaratoria.
4. HTTP/Node específico → ejecuta API/DB; captura status e id.
5. LLM (finalizer) → redacta respuesta al usuario con el resultado.
6. Database → guarda trazas: herramienta, costo, latencia, errores.
7. IF → si acción “crítica”, enruta a aprobación humana antes de ejecutar.

Tip Laravel

• Expón herramientas como Jobs (idempotentes) y Actions con validación FormRequest.
• Define un ToolRegistry (tabla tools + JSON Schema) y un middleware que valide {tool,args}.
• Guarda request_id para reintentos sin duplicar efectos.

Errores comunes (y cómo evitarlos)

• Herramientas sin schema claro → parámetros ambiguos.
• Permitir ejecución con datos faltantes → resultados erróneos.
• Cadena de herramientas demasiado larga → costos y fallos acumulados.
• Sin auditoría → imposible explicar qué pasó ante incidencias.

Conclusión

“Toolformer mental” no es magia, es disciplina: contratos, política de uso, validación y trazas. Con eso, tu asistente deja de improvisar y empieza a ejecutar acciones seguras y auditables.

← Anterior: In-context learning en serio: enseñando a tu modelo con pocos ejemplos

Siguiente: JSON perfecto o nada: cómo controlar la salida de tu LLM →