Preguntas frecuentes sobre fiabilidad, evaluación y observabilidad

Con casos reales, casos límite, errores esperados, entradas ambiguas y escenarios donde debería negarse a actuar.

Es el proceso de medir si responde, recupera información o ejecuta acciones con la calidad necesaria.

Es la capacidad de analizar qué ocurrió dentro del sistema: llamadas, herramientas, errores, costes, tiempos y resultados.

Sí. Antes de cada cambio, cada respuesta se compara con la correcta, anotada en la batería de pruebas. En producción, las preguntas que el sistema no supo contestar quedan registradas y se revisan cada semana.

Sí, pero no basta con mirar los registros de error. Los fallos peligrosos de un sistema con IA no dan error: el sistema contesta algo equivocado con total normalidad.

Por eso cada semana pasamos una tanda de conversaciones de prueba sobre el sistema en marcha y revisamos el panel de Phoenix, una herramienta de seguimiento instalada en servidor propio, y las preguntas que el agente no supo contestar. Esas tres cosas son también lo que entregamos al cliente.

Sí. Por eso se fijan límites, un tiempo máximo de espera, un número de reintentos y una alternativa para cuando nada de eso funciona, como pasar el caso a una persona.

Es un control que limita o valida el comportamiento del sistema antes o después de una acción. En nuestros sistemas esos límites los aplica el código, no una instrucción al modelo.

Sí. Un agente solo debería disponer de las herramientas necesarias para su función.

Sí, si el sistema mantiene suficiente trazabilidad de estados, llamadas y errores.

No, y no lo prometemos. Lo que sí prometemos es enterarnos antes que el usuario cuando algo falla y dejar escrito por qué falló. En uno de nuestros sistemas asumimos un techo cercano al 92 %, porque perseguir el cien acaba ajustando las pruebas en vez de mejorar el sistema.

Sí. La intervención humana puede formar parte del flujo normal.

Con lo que entregamos al cliente: el panel de Phoenix, los resultados de cada ejecución semanal del golden dataset (batería de pruebas) y las preguntas que el agente no supo contestar. Con eso se decide si se añade un glosario, se cambia el prompt o se cambia la arquitectura. Si el cliente lo necesita, también entregamos un informe semanal.

Es una prueba sobre un conjunto de casos conocidos, con su respuesta correcta anotada, antes de que un cambio llegue a los usuarios. En nuestros proyectos es el golden dataset (batería de pruebas), y ningún cambio llega a producción sin pasarlo.

Es la medición del comportamiento del sistema mientras opera con usuarios y datos reales. En nuestros proyectos incluye una tanda de pruebas cada semana contra el sistema en producción.

Nosotros no lo hacemos. Medimos contra un golden dataset (batería de pruebas) con la respuesta correcta anotada, y los controles los hace el código, no otro modelo. En uno de nuestros sistemas un segundo modelo revisaba al primero y lo retiramos, porque también se equivocaba.

Es un conjunto de casos representativos, sacados de conversaciones reales, con la respuesta correcta anotada para medir el sistema.

Sí, y en nuestros sistemas es una regla, no un consejo. Ningún cambio de prompt, modelo, recuperación, herramientas o reglas llega a producción sin pasar la batería de pruebas. Antes de aplicarlo se hace copia de la base de datos y, si después el servicio no responde, se vuelve solo a la versión anterior.

Es una pérdida de calidad en casos que antes funcionaban correctamente después de introducir cambios.

Sí, si se registra consumo por sesión, usuario o flujo.

Sí. Puede registrarse qué funciones ejecuta el agente y con qué parámetros.

Sí. Alertas y métricas permiten detectar cambios en tasas de fallo.

Sí. Se pueden ejecutar evaluaciones sobre los mismos casos para comparar precisión, coste y latencia.

No llega a producción. El modelo va fijado y un cambio de modelo pasa las pruebas antes de salir. Si algo falla al aplicar cualquier cambio, se vuelve solo a la versión anterior, porque antes se hace copia de la base de datos.

Sí. Puede compararse el comportamiento de dos configuraciones sobre tráfico controlado.