LLM Observabilidad para las tormentas retrasadas: coste por resultado verificado

La observabilidad de LLM debe contar tokens, latencia, errores y llamadas de modelo. Para un agente que puede volver a intentar trabajar, eso es sólo el numerador. El denominador operativo es el número de resultados previstos verificados en el destino. Por lo tanto, una señal de coste útil es: Mantenga el costo de la repetición, el propietario de la repetición y el estado de resultado bajo un run id estable. No dividas el gasto por respuestas de API exitosas o por el propio mensaje completo del agente. Ambos pueden parecer saludables mientras un flujo de trabajo se repite, un resultado está ausente, o dos capas silenciosamente intentan nuevamente el mismo fracaso. Esta guía aplica esa regla a un experimento fijo de ocho carreras. La cohorte constante cuesta $0.012 por resultado verificado. La cohorte de tormenta de retraso parece costar $0.041 por cada finalización declarada, pero su verificación de destino prueba solo un resultado, por lo que la cifra real es $0.12310.3 veces la cohorte estable. Los importes en dólares son sintéticos; el error contable es real y reproducible. Mantenga la capa de observabilidad normal de LLM El defecto razonable sigue siendo la telemetría de las llamadas de modelo. Registra la duración de la solicitud, los tokens de entrada y salida, la clase de error, el proveedor, el modelo, la operación y la correlación de seguimiento. Esas señales te dicen si un proveedor se desaceleró, un contexto se expandió, un modelo cambió o una llamada falló. El OpenTelemetry Convenciones métricas GenAI actual hace que el hormigón de base. En el compromiso fijado el 24 de julio de 2026, definen gen ai.client.token.usage y gen ai.client.operation.duration . También definen el número de inferencias a nivel de agente y de herramientas. El documento marca las convenciones Development , así que pin la versión que implementas y espera que los campos se muevan. El uso de tokens no es un costo automático. Un proveedor puede devolver cuentas de tokens facturables, una puerta de entrada puede calcular una estimación y una factura puede reconciliar el importe posteriormente. Mantenga la procedencia junto al valor: Utilice un identificador de ejecución opaco. Las instrucciones, las respuestas, las credenciales, los argumentos de las herramientas, el contenido de los clientes y los caminos absolutos no pertenecen a una dimensión de costes. El rastro protegido puede permanecer disponible para una investigación autorizada; el agregado solo necesita suficiente información para localizar el intento y explicar su contabilidad. Los gráficos por llamada siguen siendo valiosos. Simplemente responden a una pregunta diferente. Un coste decreciente por respuesta de modelo puede coexistir con un aumento de los intentos por flujo de trabajo. Un retiro exitoso puede reparar un error de proveedor transitorio mientras oculta que la misma tarea también fue retiro por una cola y luego por el agente. El modelo de telemetría describe las llamadas. La contabilidad de ejecución describe la promesa. Hacer que el resultado verificado sea el denominador Definir el resultado antes de la ejecución. El modelo de texto devuelto es un resultado de llamada. La solicitud de extracción tiene el compromiso esperado, el informe existe bajo la clave acordada,o el mapa del sitio contiene la URL publicada es un resultado. El récord mínimo de carreras necesita cuatro estados: El Estado Significado Tratamiento de los costes Tratamiento sanitario verified Un predicado nativo de destino aprobado Incluya el costo e incrementa el denominador Completado missing El agente declaró la finalización pero el predicado falló. Incluya el coste; no incremente el denominador Falso éxito waiting Una dependencia nombrada o una decisión humana es sobresaliente Incluya el costo; no lo llames éxito o fracaso todavía Ruta hacia el propietario de la dependencia unavailable El verificador no se ejecutó o sus pruebas están obsoletas Incluya el costo conocido; deje la relación desconocida si no existe un denominador válido Investigar la cobertura de la evidencia Esta distinción evita un atajo conveniente pero destructivo. Si una persona no ha aprobado un cambio, el agente está esperando; ejecutar el modelo repetidamente no crea autoridad. Si el verificador está desconectado, tratar su ausencia como un fallo puede provocar efectos secundarios duplicados. Si el agente dice done pero el destino está vacío, tratar la declaración como un éxito recompensa la falsa finalización. Unirse al registro de resultados a los intentos, en lugar de copiar el producto entregado en la tienda de observabilidad: El verificador debe ser determinista siempre que sea posible. Compruebe un hash de archivo, fila de base de datos, campo de API, resultado de prueba o estado de destino. Un evaluador cualitativo puede proporcionar evidencia cuando el resultado no puede expresarse como un predicado, pero su versión, calibración e incertidumbre pertenecen al lado de la puntuación. Reproducir la brecha entre los costes de la reutilización El experimento que acompaña utiliza ocho carreras sintéticas: cuatro estables y cuatro en una tormenta de nuevo intento. Cada ejecución contiene tokens de nivel de intento y campos de costos más un estado final de resultado. La tormenta incluye un resultado verificado, dos declaraciones falsas de éxito, y una aprobación legítima esperando. Guarde un objeto NDJSON por ejecución. Este par abreviado muestra la forma: Agrega cada intento bajo su cohorte, y luego calcula: El conjunto completo y la auditoría conservados con esta publicación producen: Tres observaciones cambian la decisión de operación. En primer lugar, el costo de la tormenta por la finalización declarada subestima el costo por resultado verificado en 3x. La declaración del agente es un mal denominador de facturación. En segundo lugar, la amplificación del intento aumenta de 1.25 a 3.00. Un panel de llamadas de modelo puede mostrar doce llamadas normales individualmente sin mostrar que pertenecen a sólo cuatro promesas. Tercero, el 62,6% del gasto de tormenta ocurre después de los intentos iniciales, y dos capas diferentes poseen esos retos. El problema no es sólo un modelo caro. Es un camino de control ilimitado. Este experimento no estima una tasa de fallas de producción. Sus precios y casos se construyen para comprobar la regla contable. Realice el mismo cálculo en su propia facturación o costos derivados del proveedor, mantenga la versión de origen y precio, y compare flujos de trabajo similares a lo largo del tiempo. Da una capa el presupuesto de nuevo intento Las retrasas a menudo son correctas. Una solicitud acelerada o un error de red transitorio pueden tener éxito después de un retraso. El fracaso comienza cuando cada capa decide de forma independiente que es dueña de la recuperación. El Orientación sobre el límite de tasas de OpenAI recomienda un respaldo exponencial aleatorio y advierte que las solicitudes fallidas aún contribuyen al límite por minuto. Por consiguiente, la reutilización continua consume la capacidad necesaria para la recuperación. El Referencia de prueba de nuevo de AWS SDK actual documenta los mismos principios de control en un entorno de API más amplio: intentos máximos limitados, retroceso exponencial con jitter y un cubo de tokens de cuota de retraso que detiene los retraso cuando se agota su presupuesto. Estas fuentes no prescriben una política universal de agentes. Apoyan un contrato más seguro: 1. Seleccione un propietario de retraso para una operacióngeneralmente la capa más baja que pueda clasificar el error transitorio y preservar la idempotencia. 2. Cuente la solicitud inicial y cada nuevo intento contra un intento de nivel de ejecución y presupuesto de costos. 3. Propagar los metadatos hacia arriba para que un ejecutor de flujo de trabajo no confunda el error final de un SDK con un primer error. 4. Hacer explícitos los estados no retriebibles: el permiso negado, la entrada inválida, la autoridad faltante y la verificación de resultados fallidos necesitan enrutamiento o investigación, no repetición ciega. 5. Deténgase cuando se agota el tiempo, el esfuerzo o el presupuesto. Regresa un estado visible con la última evidencia. 6. Verifique el destino después de un nuevo intento. Un comando que regresó con éxito no es el resultado prometido. Las temporadas necesitan cuidados especiales. Un tiempo de espera del cliente no prueba que el lado remoto no haya hecho nada. Antes de volver a probar una herramienta de efectos secundarios, utilice una tecla de idempotencia o consulte el destino. De lo contrario, un sistema de observabilidad puede informar correctamente del segundo intento mientras el sistema empresarial recibe dos facturas, mensajes o publicaciones. Alerta de regresión, luego inspeccionar el resultado No vuelvas a intentarlo. Comience con líneas de base específicas del flujo de trabajo y requiere persistencia. Una primera advertencia útil puede combinar tres condiciones: Ajusta esos valores al flujo de trabajo. Un proceso de lote con ventilador barato e impotente puede tolerar más intentos. Un flujo de trabajo de pago, publicación o mensajes de clientes puede permitir menos. El proveedor separado se estrangula por el fallo de la herramienta y por el resultado de ausencia de destino. Tienen diferentes propietarios y diferentes acciones de seguridad. La alerta debe indicar la promesa afectada, los intentos totales, los propietarios de la nueva prueba, la procedencia de los costes, el resultado del verificador y su frescura, y la próxima acción limitada. Un mensaje útil dice: La publicación del informe utilizó 12 intentos en todo el SDK y el ejecutor del flujo de trabajo; el gasto de repetición es del 63%; se verifica uno de los cuatro resultados; inspeccionar la propiedad de repetición y el verificador del mapa de sitio. No debe decir que sólo el costo de los tokens es alto. Hay dos límites importantes. Los datos de costos pueden ser retrasados, estimados o incompletos, así que muestren cobertura y no fabriquen ceros. Los controles de resultados también pueden fallar de forma independiente, por lo que unavailable debe permanecer distinto de missing . Una carrera waiting legítima se mantiene fuera del denominador verificado sin ser etiquetada como atascada hasta que su dependencia o fecha límite cambie. La dirección del producto de Sidewisp incluye el costo como una señal de salud junto con la disponibilidad, ejecución, memoria, herramientas y resultados. Está destinado a funcionar además de los tiempos de ejecución existentes, no a convertirse en una puerta de entrada de modelo obligatoria o en un fijaje autónomo. Sidewisp se encuentra actualmente en versión preliminar privada. El sitio público y la biblioteca de artículos están en vivo; los adaptadores de monitoreo de producción, el análisis de costos de tokens y la ejecución de recuperación generalmente no se envían. Únete a la vista previa privada si quieres ayudar a dar forma a cómo deben cumplirse las pruebas, los costos y los resultados verificados mientras los humanos conservan la autoridad.