Cómo distinguir un fallo del modelo de un fallo de integración
Aísla el fallo comparando tres evidencias: qué recibió el modelo, qué llamada propuso y qué ejecutó o devolvió la integración.
Equipo enginerIT· 2 min de lectura
Aísla el fallo comparando tres evidencias: qué recibió el modelo, qué llamada propuso y qué ejecutó o devolvió la integración. La frase final del agente no basta para atribuir la causa al modelo.
Reconstruye una ejecución concreta
Localiza el intento y la versión afectados. Revisa si el dato necesario estaba en el contexto autorizado, si la herramienta estaba disponible y qué parámetros se propusieron. Trabaja con capturas saneadas o referencias protegidas. Si faltan eventos, registra esa incertidumbre; no etiquetes como alucinación cualquier resultado que no puedes explicar.
Comprueba los contratos entre componentes
Una llamada puede ser válida en formato y equivocada en significado. Contrasta identificador, unidad, zona horaria y campos obligatorios con el contrato del conector. Después revisa la petición real enviada y la respuesta recibida. En function calling, la aplicación ejecuta el código: que el modelo pida una consulta no acredita que la consulta se haya realizado ni que conserve los mismos argumentos.
Haz dos pruebas sin escrituras
Primero entrega a la etapa de respuesta un resultado de herramienta fijo y correcto, usando datos de ensayo. Si la salida sigue interpretándolo mal, investiga instrucciones, contexto o modelo. Después prueba el conector con argumentos verificados y compara el resultado con el sistema de referencia. Si falla, investiga autenticación, transformación o disponibilidad. Estas pruebas acotan una causa; no demuestran que solo haya un defecto.
Asigna la corrección a la capa adecuada
Un permiso denegado exige revisar autorización, no ampliar el prompt. Una fecha mal convertida necesita corregir el adaptador; una promesa inventada a partir de un dato estimado exige revisar la generación y sus controles. Incluye casos donde coinciden dos fallos y repite el recorrido completo después de reparar. Evita ensayar escrituras reales para diagnosticar: usa un entorno adecuado o una operación explícitamente sin efectos y verifica el estado de destino antes de cualquier repetición.
Cuando el proveedor devuelva un error, conserva su categoría y referencia saneada. Diferencia un rechazo de la petición de una indisponibilidad transitoria. El tratamiento posterior puede ser distinto y no debería decidirse solo por el texto que el agente redacta para el usuario.
Comprobaciones para cerrar la tarea
- ✓ Entrada, llamada propuesta y petición real comparadas.
- ✓ Unidades e identificadores revisados.
- ✓ Conector probado con argumentos conocidos.
- ✓ Reparación validada de extremo a extremo.
Fuentes y documentación
- OpenAI — Function calling — El modelo propone llamadas; la aplicación ejecuta el código de las herramientas.
- OpenAI Agents SDK — Tracing — El SDK diferencia trazas y spans y permite controlar contenido sensible; verifica tu versión y exportadores.
Aplicarlo en tu empresa
Podemos revisar el entorno y acordar qué actuaciones, validaciones y mantenimiento necesitas.
Conocer el servicio relacionado →