Cómo saber por qué tu agente respondió eso un martes a las 3 AM

Un miércoles a la mañana, un cliente te reenvía una respuesta equivocada de tu agente. Fue el martes a las 3 AM. Hacés la misma pregunta y ahora responde bien. ¿Se arregló? ¿Fue casualidad? ¿Le pasó a alguien más?

Si solo guardaste la pregunta y la respuesta, no tenés forma de saberlo. Un modelo puede responder distinto ante la misma pregunta, y desde el martes pudieron cambiar los documentos, el prompt o el modelo.

Por qué un log común no alcanza

En un sistema tradicional, una falla suele dejar rastro: un error, una excepción, un servicio caído. Un agente puede equivocarse con todo funcionando. La llamada dio 200, el tiempo de respuesta fue normal y el error está en el contenido.

Por eso no alcanza con saber que el sistema anduvo. Hay que poder reconstruir qué vio y qué hizo.

Qué registrar en cada ejecución

Un identificador único: une todos los pasos de una misma ejecución.
La entrada: qué recibió el agente y por qué canal.
La versión del prompt y del modelo: la exacta, no "el de siempre".
Lo que recuperó: qué fragmentos usó y de qué versión de cada documento.
Las herramientas: a cuáles llamó, con qué datos, qué devolvieron y si fallaron.
La salida: lo que respondió o hizo.
Tokens, tiempo y costo: por ejecución, no solo en la factura del mes.

Volvamos al martes

Con ese registro, la pregunta deja de ser "¿qué le pasó?" y pasa a tener respuestas concretas:

Recuperó un documento viejo: el problema es la actualización del índice.
No recuperó nada y respondió igual: faltan reglas o pruebas para que diga "no sé".
Una herramienta falló: el agente siguió sin un dato que necesitaba.
Tenía todo y se equivocó: es un caso para sumar a tu lista de pruebas.

Cada causa se arregla en un lugar distinto. Sin registro, lo más probable es que termines tocando el prompt a ciegas.

No esperes a que alguien se queje

Conviene poner alertas sobre la tasa de errores, las herramientas que fallan, el tiempo de respuesta y el gasto. También revisar una muestra de conversaciones reales cada tanto, porque una respuesta equivocada no dispara ninguna alarma por sí sola.

Sin guardar de más

Lo que los clientes escriben termina en tus registros, y puede incluir datos personales. Definí quién puede verlos, cuánto tiempo se guardan y qué se enmascara.

Los secretos no deberían llegar nunca. En nuestro servicio interno de documentación, por ejemplo, los errores de un proveedor registran su código y no su mensaje, porque el mensaje puede repetir lo que se le envió.

Por dónde empezar

No hace falta una plataforma grande. Empezá con un identificador por ejecución y un registro de esos datos en un solo lugar. Si después querés un formato estándar, OpenTelemetry tiene convenciones para IA generativa. Probá tu registro con una pregunta simple: si mañana alguien te reenvía una respuesta equivocada, ¿podés explicar por qué ocurrió?

Cómo lo encaramos en Nerdlabs

Para nosotros, un agente sin registro no está terminado. Cuando armamos uno, la observabilidad es parte del trabajo desde el primer día, no un extra para más adelante:

Cada respuesta se puede reconstruir: qué recibió, qué buscó, qué herramientas usó, cuánto costó y qué respondió.
Cada error se convierte en una prueba: lo que falló una vez entra en la lista que se corre antes de cada cambio.
Las alertas llegan antes que las quejas: errores, herramientas caídas, tiempos y gasto.
Queda en tus manos: los registros y la documentación son tuyos, para que no dependas de nosotros para entender qué pasa.

También lo aplicamos en casa: en nuestro servicio interno de documentación, cada búsqueda queda registrada con quién preguntó, qué versión estaba indexada y qué documentos devolvió.