Registros de ejecución reproducibles para agentes: registrar cada llamada al modelo y a las herramientas

Qué es

Un registro reproducible es un registro de la ejecución de un agente a partir del cual puede reconstruirse cada paso: la solicitud exacta enviada al modelo (prompt del sistema, mensajes, definiciones de herramientas, parámetros de muestreo), la respuesta (contenido, llamadas a herramientas, razón de parada, uso), y para cada llamada a herramienta sus argumentos, resultado y estado de error, en orden y con marcas de tiempo. Las convenciones semánticas GenAI de OpenTelemetry definen nombres de atributos para esto; todavía están marcadas como en desarrollo y ahora residen en un repositorio separado, semantic-conventions-genai, mientras que el registro de atributos en opentelemetry.io las lista con una nota de que se han trasladado. Entre ellas están gen_ai.request.model, gen_ai.request.temperature, gen_ai.request.seed, gen_ai.response.id, gen_ai.response.finish_reasons, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, gen_ai.tool.call.id, gen_ai.tool.call.arguments, gen_ai.tool.call.result y gen_ai.conversation.id para agrupar. Los marcos de evaluación conservan la misma información por muestra; Inspect, por ejemplo, escribe un archivo de registro para cada tarea evaluada y lo expone como un objeto EvalLog.

Por qué importa

Las salidas del modelo no son deterministas, los resultados de las herramientas cambian con el mundo, y una ejecución puede tener cientos de pasos. Sin el registro, «el agente borró el archivo equivocado» no puede rastrearse hasta el paso donde la ruta incorrecta entró en el contexto. Con él, la solicitud que produjo una mala decisión puede reenviarse tal cual para probar una corrección del prompt, y los resultados de las herramientas pueden sustituirse a partir del registro para que el resto de la ejecución se reproduzca sin efectos secundarios.

Cómo aplicarlo

• Registrar en el límite donde la solicitud sale del proceso, no a partir de la plantilla del prompt: lo que importa son los bytes realmente enviados.
• Dar a cada ejecución un identificador y a cada paso un número de secuencia; vincular los resultados de las herramientas al identificador de la llamada en lugar de depender del orden.
• Almacenar el contenido completo, pero redactar secretos y datos personales antes de escribir (las mismas reglas que para los registros de la aplicación) y fijar un período de retención.
• Registrar el identificador de la respuesta y, cuando el proveedor lo ofrezca, una versión o huella del modelo servido.
• Construir un modo de reproducción: dado un registro, el harness sirve los resultados de herramientas registrados para llamadas idénticas y marca las llamadas que divergen de lo registrado.
• Usar los mismos identificadores en trazas y métricas para que los paneles de coste y latencia enlacen de vuelta con una transcripción.

Trampas

Registrar solo la respuesta final. Truncar los resultados de las herramientas en el registro, lo que oculta la instrucción inyectada o la carga malformada que causó el fallo. Tratar la reproducción contra un modelo en vivo como determinista: la reproducción reproduce las entradas, no la decisión. Los registros que repiten todo el conjunto de documentos en cada paso crecen rápido; deduplicar por hash de contenido.