Preparación de Datasets de Tool-Calling para Agentes de AI Empresarial: Un Flujo de Trabajo On-Premise

La mayoría de los proyectos de agentes de AI empresarial se estancan en el mismo punto: el agente puede mantener una conversación, pero no puede llamar de manera confiable a la herramienta interna correcta con los argumentos correctos en el momento correcto. La causa raíz es casi siempre la misma — el modelo nunca fue entrenado con datos de tool-calling que reflejen las herramientas reales de la organización.

El prompting por sí solo no resuelve esto. Puedes llenar un system prompt con definiciones de funciones y ejemplos few-shot, pero una vez que tienes más de 40 herramientas internas con capacidades superpuestas, los enfoques basados en prompts alcanzan un techo. El modelo confunde herramientas similares, alucina argumentos o recurre a la herramienta más común independientemente del contexto.

La solución es directa: ajusta el modelo con datos de tool-calling específicos de tu entorno. El desafío es que estos datos no existen hasta que los creas — y para empresas, el proceso de creación debe ocurrir completamente on-premise porque las propias definiciones de herramientas son sensibles.

Por Qué los Agentes Necesitan Datos de Entrenamiento de Tool-Calling

La capacidad de un agente de AI para seleccionar e invocar herramientas es un comportamiento aprendido, no uno emergente. Los modelos base e incluso los modelos ajustados por instrucciones tienen capacidades generales de tool-calling, pero estas fueron entrenadas con esquemas de API públicos — piensa en APIs del clima, motores de búsqueda, funciones de calculadora. Las herramientas empresariales no se parecen en nada a esto.

Una empresa típica tiene APIs internas para recuperación de datos CRM, transacciones ERP, gestión de documentos, verificaciones de cumplimiento, flujos de aprobación, y docenas de operaciones específicas del dominio. Cada herramienta tiene formatos de argumentos específicos, contextos de autenticación requeridos y reglas de negocio sobre cuándo debe o no debe invocarse.

Cuando ajustas con ejemplos de tool-calling específicos de la empresa, tres cosas mejoran de manera medible. Primero, la precisión de selección de herramientas salta del 60-70% (solo prompt) al 90-95% (ajustado) en benchmarks internos. Segundo, los errores de formateo de argumentos caen un 80% o más porque el modelo aprende el esquema exacto. Tercero, el modelo aprende ejemplos negativos — cuándo no llamar a una herramienta — lo que reduce llamadas innecesarias a APIs y costos asociados.

El Formato del Dataset de Tool-Calling

Cada ejemplo de entrenamiento de tool-calling tiene la misma estructura, independientemente de la familia de modelos que estés ajustando. El formato consiste en cinco componentes:

System prompt: Define el rol del agente e instrucciones generales. Mantenlo consistente entre ejemplos.

Definiciones de funciones: Descripciones de esquema JSON de las herramientas disponibles — nombre, descripción, parámetros (con tipos y restricciones) y campos requeridos.

Consulta del usuario: Una solicitud en lenguaje natural que debería activar una llamada de herramienta específica.

Llamada de función esperada: El nombre de la herramienta que el modelo debería seleccionar.

Argumentos esperados: Los argumentos JSON exactos que el modelo debería pasar a la herramienta.

Un ejemplo de entrenamiento individual se ve así en la práctica:

{
  "messages": [
    {
      "role": "system",
      "content": "You are an enterprise assistant with access to internal tools."
    },
    {
      "role": "user",
      "content": "Pull the Q3 revenue numbers for the EMEA region."
    }
  ],
  "tools": [
    {
      "name": "query_financial_report",
      "description": "Retrieves financial metrics by quarter, region, and metric type.",
      "parameters": {
        "quarter": "string (Q1-Q4)",
        "year": "integer",
        "region": "string",
        "metric": "string"
      }
    }
  ],
  "expected_call": {
    "name": "query_financial_report",
    "arguments": {
      "quarter": "Q3",
      "year": 2026,
      "region": "EMEA",
      "metric": "revenue"
    }
  }
}

Necesitas 50-200 ejemplos por herramienta para un fine-tuning confiable. Para un sistema con 30 herramientas, eso significa 1,500-6,000 ejemplos totales. Suena como mucho, pero el pipeline de preparación lo hace manejable.

Documentos Fuente Comunes

Los datasets de tool-calling empresarial se construyen a partir de documentos que ya existen en la mayoría de las organizaciones:

Documentación de API: Las especificaciones OpenAPI/Swagger son la fuente más rica. Contienen definiciones de endpoints, esquemas de parámetros, y frecuentemente solicitudes de ejemplo. Si tus APIs internas tienen especificaciones, ya tienes el 40% hecho.

Wikis internas y runbooks: Contienen descripciones en lenguaje natural de cuándo usar qué herramienta y cómo. Son la fuente para variaciones de consultas de usuarios — la forma en que los usuarios reales describen las tareas.

Definiciones de flujos de trabajo: Diagramas BPMN, flujos de trabajo de Jira, cadenas de aprobación. Estos codifican secuencias de tool-calling de múltiples pasos donde la salida de la Herramienta A alimenta la entrada de la Herramienta B.

Procedimientos operativos estándar (SOPs): Instrucciones paso a paso que mapean directamente a cadenas de tool-calling. "Primero, busca al cliente en el CRM. Luego verifica su estado crediticio. Luego crea el pedido." Cada paso es una llamada de herramienta.

Tickets de soporte y registros de chat: Consultas reales de usuarios que activaron uso manual de herramientas. Son oro para generar variaciones realistas de consultas porque capturan cómo las personas realmente formulan solicitudes — errores tipográficos, abreviaciones y todo.

El Pipeline de Preparación

El pipeline de extremo a extremo tiene cinco etapas. Cada etapa puede ejecutarse on-premise sin dependencias externas.

Etapa 1: Extrae Definiciones de Herramientas de Especificaciones de API

Parsea especificaciones OpenAPI/Swagger para extraer esquemas de funciones. Para cada endpoint, captura el nombre, descripción, método HTTP, parámetros de ruta, parámetros de consulta, esquema del cuerpo de solicitud y esquema de respuesta. Convierte estos al formato JSON de tool-calling que tu modelo objetivo espera.

Si tienes 30 APIs internas con un promedio de 8 endpoints cada una, esta etapa produce 240 definiciones de herramientas crudas. No todas serán relevantes para tu agente — filtra al subconjunto que el agente realmente debería usar.

Etapa 2: Genera Variaciones de Consultas de Usuarios

Para cada herramienta, crea 50-200 consultas en lenguaje natural que deberían activarla. Comienza con las consultas de tu documentación wiki y SOPs. Luego usa un LLM local (Llama 3 70B via Ollama funciona bien) para generar variaciones.

La clave es diversidad: consultas formales ("Recupera el estado de la cuenta del cliente para el ID de cuenta 44891"), consultas informales ("cuál es el estado de la cuenta 44891"), consultas ambiguas ("revisa esa cuenta"), y consultas que requieren inferencia de argumentos ("obtén los números de EMEA del último trimestre" — el modelo debe inferir el año actual).

Etapa 3: Crea Pares de Llamada/Respuesta Esperados

Para cada combinación consulta-herramienta, define la llamada de función esperada y los argumentos. Esta es la etapa más intensiva en mano de obra y requiere experiencia en el dominio. La persona creando estos ejemplos debe conocer la herramienta correcta y el mapeo correcto de argumentos.

Aquí es donde los expertos de dominio demuestran su valor. Un ingeniero que ha usado estas APIs diariamente durante tres años puede producir 200 ejemplos en un día. Alguien no familiarizado con las APIs producirá errores que se propagarán a través del modelo ajustado.

Etapa 4: Valida y Deduplica

Ejecuta validación automatizada: ¿Los argumentos coinciden con el esquema de la herramienta? ¿Están presentes los campos requeridos? ¿Son válidos los valores enum? Luego verifica duplicados — consultas similares con llamadas esperadas idénticas agregan ruido sin agregar señal de aprendizaje.

También valida ejemplos negativos: incluye consultas que NO deberían activar ninguna llamada de herramienta. "¿Cómo está el clima?" no debería invocar tu API interna de CRM. Los modelos necesitan aprender restricción.

Etapa 5: Exporta como JSONL

Formatea los ejemplos validados como JSONL en el esquema que tu framework de fine-tuning espera. Para la mayoría de modelos open-source (Llama, Mistral, Qwen), este es el formato ChatML con extensiones de tool-calling. Exporta tanto un conjunto de entrenamiento (80%) como un conjunto de validación (20%).

Requisitos On-Premise

Los datasets de tool-calling están entre los artefactos de preparación de datos más sensibles que una empresa produce. Aquí está por qué.

Las definiciones de herramientas mismas revelan la arquitectura interna de APIs. Un atacante con tu dataset de tool-calling conoce cada endpoint interno, cada esquema de parámetros y cada regla de negocio codificada en las descripciones de herramientas. Esto es un plano de la infraestructura operacional de la organización.

Los ejemplos de entrenamiento revelan patrones de uso — qué consultas mapean a qué herramientas, qué argumentos son comunes, y cómo se conectan diferentes sistemas. Esto es inteligencia operacional que competidores o adversarios encontrarían valiosa.

Para industrias reguladas, la situación es más aguda. El dataset de tool-calling de una institución financiera revela exactamente cómo se ejecutan operaciones, cómo se realizan verificaciones de cumplimiento, y qué flujos de aprobación existen. Enviar estos datos a un proveedor de LLM en la nube para aumento sintético es una violación de cumplimiento en la mayoría de los marcos regulatorios.

Todo el pipeline — desde el parsing de especificaciones de API hasta la generación sintética de consultas hasta la exportación de JSONL — debe ejecutarse en infraestructura que la organización controle.

Usando LLMs Locales para Aumento Sintético

La etapa de generación de consultas se beneficia enormemente de la asistencia de LLM. Un modelo local puede generar 10 variaciones de consultas por minuto, cada una formulada de manera suficientemente diferente para agregar valor de entrenamiento.

Ejecuta Ollama con un modelo capaz (Llama 3.3 70B o Qwen 2.5 72B) en tu infraestructura GPU on-premise. Aliméntalo con una definición de herramienta y 5 consultas semilla escritas por expertos de dominio, luego pide 50 variaciones. Revisa la salida — espera retener 70-80% después del filtrado de calidad.

El prompt de aumento importa. Especifica el dominio, la persona del usuario (analista junior, trader senior, agente de soporte al cliente), y el nivel de formalidad. Esto produce consultas diversas que cubren el rango de cómo diferentes personas en la organización formularían solicitudes.

Para un dataset de 5,000 ejemplos, el aumento sintético reduce el esfuerzo del experto de dominio de aproximadamente 200 horas a aproximadamente 50 horas. El experto escribe ejemplos semilla y revisa los generados en lugar de escribir cada ejemplo desde cero.

Validación de Calidad

Dos verificaciones de calidad determinan si tu dataset de tool-calling está listo para producción.

Prueba de cobertura: ¿Cada herramienta tiene suficientes ejemplos? Grafica la distribución de ejemplos por herramienta. Si 5 herramientas tienen más de 200 ejemplos y 10 herramientas tienen menos de 20, el modelo estará sesgado hacia las herramientas bien representadas. La cobertura mínima viable es 50 ejemplos por herramienta.

Cobertura de casos extremos: Para cada herramienta, verifica que tengas ejemplos cubriendo: todas las combinaciones de parámetros requeridos, uso de parámetros opcionales, inferencia de parámetros desde el contexto (por ejemplo, inferir "trimestre actual" desde la fecha), consultas multi-herramienta que requieren llamadas secuenciales, y consultas que son similares al propósito de la herramienta pero que NO deberían activarla.

Ejecuta un fine-tune rápido de validación en el 20% del dataset. Si el modelo alcanza más del 85% de precisión en selección de herramientas en ejemplos reservados, la calidad del dataset es suficiente. Por debajo del 85%, busca errores sistemáticos — usualmente unas pocas herramientas mal definidas son responsables de la mayoría de los errores.

Consideraciones Prácticas

Tamaño del dataset: Para un sistema de 30 herramientas, apunta a 3,000-6,000 ejemplos totales. Por debajo de 1,500, verás confusión de herramientas en las menos comunes. Por encima de 10,000, llegas a rendimientos decrecientes a menos que tus herramientas sean inusualmente complejas.

Frecuencia de actualización: Las APIs internas cambian. Presupuesta actualizaciones trimestrales del dataset — nuevos endpoints, herramientas deprecadas, esquemas modificados. Un dataset de tool-calling desactualizado produce un modelo que llama endpoints que ya no existen.

Secuencias multi-turno: Las interacciones reales de agentes involucran cadenas de llamadas de herramientas. Incluye ejemplos multi-turno donde el agente llama a la Herramienta A, procesa el resultado, luego llama a la Herramienta B. Estos representan 20-30% del uso en producción y están subrepresentados en la mayoría de los datasets.

Manejo de errores: Incluye ejemplos donde la respuesta correcta es pedir aclaración en lugar de adivinar argumentos. "Actualiza la cuenta" es demasiado ambiguo — el modelo debería preguntar qué cuenta y qué actualización, no llamar a la API con argumentos inventados.

El dataset de tool-calling es el artefacto de mayor impacto en un proyecto de agente de AI empresarial. Hazlo bien y el agente funciona. Hazlo mal y ninguna cantidad de prompt engineering lo compensará.

Lectura Adicional

• Cómo Crear Datasets de Entrenamiento de Tool-Calling para Fine-Tuning — La guía fundamental sobre formatos de datasets de tool-calling y flujos de trabajo de fine-tuning.
• Preparación de Datos para Agentes de AI Empresarial — Una mirada más amplia a todos los requisitos de preparación de datos para despliegues de agentes empresariales.
• Construyendo Bases de Conocimiento de Agentes de AI para Empresas — Cómo preparar la capa de conocimiento que los agentes de tool-calling consultan.