Pruebas y depuración

Copiar enlace al artículo

Copiado

Contenido

1. Chat de prueba
   • Es gratis
   • Está aislado
   • Reinicio: desde cero
2. En qué se diferencia el chat de prueba de uno normal
3. Una respuesta son varias iteraciones
4. Bloques de datos en el chat de prueba
5. Prueba constantemente
6. Cómo leer el chat cuando algo va mal

Un agente no se puede configurar «a ciegas» y soltarlo de inmediato a los clientes. Su comportamiento se compone de muchos detalles —instrucciones, pasos del escenario, condiciones, señales, base de conocimientos— y es imposible predecir el resultado sobre el papel. Por eso, el desarrollo del agente debe ir acompañado de pruebas constantes de su trabajo. El chat de prueba permite al usuario del sistema comunicarse con el agente como un cliente, analizar todas sus acciones internas y comprobar lo bien que resuelve las tareas planteadas.

Chat de prueba

El botón «Probar Agente de IA» abre un chat en la página de configuración del agente. Le escribes al agente igual que lo haría un cliente, y él responde según su configuración actual: la versión que está abierta en la ficha.

Para esto no hace falta activar al agente: también se puede probar un borrador. Así compruebas por completo una versión antes de activarla, y esta no empezará a funcionar en el canal con clientes reales antes de que estés seguro de ella.

Es gratis

Cuantas pruebas quieras y sin ningún cobro: el chat de prueba no se tarifica (ver «Qué no se tarifica»). Por eso se puede y se debe probar mucho el trabajo del agente.

Está aislado

La conversación ocurre solo entre tú y el agente; a los clientes reales no les llega nada, y no se crean diálogos, clientes ni pedidos reales en el CRM.

Reinicio: desde cero

El botón con el icono de papelera borra la conversación: el agente olvida el contexto, los datos recopilados y su lugar en el escenario, y arranca de nuevo. Así es cómodo recorrer un mismo escenario desde cero muchas veces.

En qué se diferencia el chat de prueba de uno normal

En un chat normal solo se ven las intervenciones: los mensajes del cliente y las respuestas del agente. Todo lo que ocurre entre ellas está oculto. El chat de prueba muestra esa «cocina» oculta: qué pasos tenía disponibles el agente, sobre qué razonó, qué pasos decidió invocar y por qué, qué le devolvió el sistema, los datos guardados, qué errores surgieron y por qué se detuvo al final.

Esto es la depuración. La mayoría de los problemas de configuración se resuelven no al azar, sino leyendo estos datos: lo más frecuente es que el agente se haya comportado de forma bastante lógica, simplemente a partir de lo que tenía disponible y de cómo entendió la situación.

Una respuesta son varias iteraciones

Antes de analizar los bloques, conviene entender cómo trabaja el agente. Una respuesta al cliente no es una sola acción, sino un ciclo de varias iteraciones. En cada iteración, el agente mira qué pasos tiene disponibles ahora y qué se ha recopilado ya, decide qué pasos invocar, el sistema los ejecuta y devuelve el resultado, y así sucesivamente hasta que el agente decide detenerse: responder al cliente o terminar el trabajo. El ciclo en sí se describe en detalle en la sección «Ciclo de trabajo del agente».

El chat de prueba muestra cada iteración seguida, bloque por bloque. Por eso, después de un solo mensaje tuyo se muestran muchos datos: es normal, ves todo el desarrollo del trabajo del agente, no solo la respuesta final. La mayoría de los bloques se pueden desplegar (el icono «>») para ver los detalles.

Bloques de datos en el chat de prueba

Los bloques aparecen en el chat poco a poco, durante el trabajo del agente. Dentro de una iteración suelen ordenarse así:

• Pasos activados por evento: un bloque naranja de dos líneas: arriba, con el icono de un rayo, se indica el evento que se activó («Mensaje del cliente», «Asignación de diálogo», etc.), y abajo, con el icono de ramificación, el paso que ese evento arrancó. Estos pasos suelen ejecutarse antes que el propio agente.
• Pasos disponibles: un bloque gris «N pasos disponibles». La lista de pasos que el agente puede invocar en esta iteración, teniendo en cuenta su visibilidad, sus condiciones de activación y el tipo de evento. Es lo primero que conviene revisar: si el paso necesario no está en la lista, el agente físicamente no podrá invocarlo, por bien escrito que esté el prompt. La causa casi siempre está en las condiciones o la visibilidad del paso (ver «Condiciones»).
• Tareas del dashboard: bloques naranjas. El estado actual que el sistema le resalta al agente: sobre qué paso del escenario está trabajando ahora, cuántos datos se han recopilado («Datos recopilados: 1 de 6») y qué campos obligatorios faltan, los valores de las señales establecidas y el contexto acumulado. En esencia es aquello con lo que el sistema dirige al agente: si la tarea está mal planteada, el agente puede comportarse de forma imprevisible. En más detalle, «Dashboard de trabajo».
• Razonamiento del agente: un bloque verde con el icono de una bombilla. El agente describe con sus propias palabras cómo entendió la situación antes de actuar. Son sus «pensamientos en voz alta» y un bloque valioso para la depuración: muestra directamente por qué el agente va a actuar de una forma y no de otra.
• Pasos que el agente decidió invocar: bloques verdes con el icono de reproducción. Cada bloque es un paso que eligió el agente, con la explicación de para qué lo invoca y con los datos que pasa (por ejemplo, qué guardar exactamente en la ficha). En una iteración el agente puede invocar varios pasos: entonces habrá varios bloques seguidos.
• Resultado de la ejecución: bloques celestes. Después de que los pasos se ejecutaron, el sistema muestra qué hicieron realmente y qué le devolvieron al agente: «Cliente creado» o «Cliente actualizado» (con la lista de campos modificados), «Pedido creado» o «Pedido actualizado», los recordatorios programados. Es este resultado lo que el agente recibe como entrada de la siguiente iteración y en lo que se apoya después.
• Errores: bloques destacados. Si un paso no se ejecutó o el modelo devolvió una respuesta incorrecta, se ve en un bloque aparte con el nombre del paso y el texto del error.
• Motivo de la detención: un bloque con el icono de pausa. Al final, el agente muestra por qué terminó las iteraciones: Esperando al cliente —respondió o hizo una pregunta y espera la reacción del cliente—; trabajo finalizado —la tarea está hecha y no espera respuesta (por ejemplo, el diálogo se traspasó al asesor o se cerró)—; continúa trabajando —aún no terminó y pasa a la siguiente iteración—.

Después de todos estos bloques viene el propio mensaje del agente al cliente: lo único que en un chat real vería el cliente.

Prueba constantemente

El chat de prueba es gratis no por casualidad: hay que usarlo constantemente. Comprueba enseguida cualquier cambio en el agente: hiciste un ajuste, recorriste el escenario, viste qué cambió.

Una sola prueba no basta. El agente funciona sobre un LLM, por eso sus respuestas no son estrictamente deterministas: ante un mismo mensaje puede comportarse de distinta forma en distintas ejecuciones. Que el agente haya respondido bien una vez no garantiza que vaya a responder así siempre. Por eso, recorre los escenarios importantes varias veces, reiniciando la conversación, y observa cuán estable es el comportamiento. Es precisamente la estabilidad lo que compruebas antes de activar una versión con clientes reales (ver «Versiones y estados del agente»).

Cómo leer el chat cuando algo va mal

Cuando el agente se comporta de forma distinta a la que esperabas, la respuesta casi siempre ya está en el chat de prueba:

• Revisa los pasos disponibles. Si el agente «no hizo» lo que configuraste, mira si el paso necesario estaba en la lista de disponibles. Si no está, el problema no es del agente, sino de las condiciones, la visibilidad o el tipo de evento del paso.
• Lee el razonamiento del agente. Los bloques verdes con los «pensamientos» muestran cómo entendió el agente la situación. A menudo resulta que razonó de forma lógica, simplemente a partir de un panorama distinto al que tú tenías en mente. Eso indica enseguida qué corregir en el prompt o el escenario.
• Revisa las tareas del dashboard. Si el agente recopila datos equivocados o va por un paso que no toca, mira qué tareas tenía planteadas. Una tarea mal planteada es una causa frecuente de comportamiento «incorrecto».