Monitoreo LLM: Qué medir más allá de la latencia, errores y tokens

El monitoreo de LLM debe comenzar con la salud de las llamadas de modelo: latencia, errores, volumen de solicitud, tokens y calidad de salida. Esa es la opción predeterminada razonable para una función de chat, un tubo de recuperación o un envoltorio de API. Una vez que la misma aplicación pueda planificar, llamar herramientas, esperar la aprobación, reanudar más tarde, o declarar una tarea completa, añadir un segundo libro mayor para la salud operativa. Los dos libros principales responden a preguntas diferentes. La primera pregunta: ¿Se comportó normalmente el servicio de modelo? La segunda pregunta: ¿Ha hecho el agente progresos útiles y ha producido el resultado esperado? run id ; no convierta un gráfico de latencia verde en una afirmación de que el trabajo es saludable. Comience con la capa de monitoreo LLM por defecto Un primer tablero útil no necesita docenas de paneles. Necesita suficiente evidencia para separar el fracaso del proveedor, el fracaso de la aplicación, la deriva de costes y la deriva de calidad de salida. Signales Pregunta que responde Práctico primer alerta Lo que no puede probar Taxa de error de solicitud ¿Están fallando las llamadas modelo? Precio por ventana, dividido por proveedor y modelo Si las llamadas exitosas avanzaron en la tarea P50/p95 latencia ¿El tiempo de respuesta ha retrocedido? Comparar operaciones y modelos similares Si una carrera lenta finalmente se entregó Tokens de entrada y salida ¿El contexto o la generación creció? Cambios respecto a una línea de base específica de la tarea Si los tokens adicionales fueron útiles Capacidad de transmisión ¿Está cambiando la carga? Solicitudes por minuto más concurrencia Si se perdió una carrera programada Puntuación de calidad ¿El resultado de la muestra cumplió con una rúbrica? Evaluador de versión más calibración humana Si existe un archivo, un ticket o un despliegue Capacitación de las huellas ¿Puede un operador reconstruir la ejecución? Las huellas faltantes o incompletas por tiempo de ejecución Si el resultado previsto está presente Esta línea de base coincide con la intención de búsqueda actual. Langfuse describe el monitoreo en torno a la latencia, el rendimiento y las tasas de error, con rastros para los caminos de ejecución y la evaluación de la calidad de salida. Splunk y Dynatrace amplían el conjunto a recursos, seguridad, costo, retroalimentación y señales de aplicación. Estas son vistas útiles de una aplicación LLM; ninguna debe descartarse simplemente porque existe una capa de agente. Las convenciones semánticas GenAI de OpenTelemetry hacen que la separación sea visible en la propia instrumentación. La especificación de desarrollo define gen ai.client.token.usage y gen ai.client.operation.duration , luego separando los instrumentos de flujo de trabajo y agentes como gen ai.invoke agent.duration , el recuento de inferencias y el recuento de herramientas. Desarrollo importa aquí: fija la versión que implementas y espera que los nombres cambien. La implementación limpia es un libro mayor de llamadas de modelo con teclas run id , operation , provider , model y timestamp. Agregarlo para alertas de nivel de servicio, pero retenga un camino de regreso a la carrera individual. Un token spike sin un identificador de carrera es una factura; un token spike unido a una carrera estancada es una pista de incidente. Añadir un libro mayor de tareas de salud cuando la aplicación se convierte en un agente Una función respaldada por LLM cruza el límite operativo cuando posee trabajo a lo largo del tiempo. Puede llamar a una base de datos, escribir un informe, abrir una solicitud de extracción, esperar a una persona o despertar en un horario. En ese punto, las respuestas de modelo exitosas son sólo eventos intermedios. El OpenAI Agents SDK ilustra lo rico que pueden llegar a ser esos eventos. Sus registros de seguimiento incorporados generaciones, llamadas de herramientas de funciones, entregas, barandillas y ejecuciones de agentes. Eso es valiosa evidencia de depuración. La misma documentación también señala que los intervalos de generación y función pueden contener entradas y salidas sensibles, lo que es una razón para hacer que la captura de contenido sea una elección explícita y no un requisito previo de monitoreo. Un libro mayor de tareas de salud puede permanecer más pequeño que el rastro. Para cada carrera, registro: expected outcome : un predicado como report exists and parses , no la frase terminar la tarea; outcome verified : true , false o unavailable , con versión verificadora; progress delta : un cambio en el recuento o la digestión de tareas específicas durante una ventana declarada; waiting on : una dependencia denominada como human approval o null ; last heartbeat at y last progress at , porque la actividad y el progreso son relojes diferentes; declared complete : el tiempo de ejecución reportado; collector freshness : cuando se observaron estos hechos por última vez. Este libro mayor deliberadamente no repite cada instante, finalización o período. Almacena la mínima evidencia necesaria para decidir si la carrera está funcionando, esperando, atascada, inaccesible o completa. Los rastros crudos permanecen disponibles para la investigación cuando la política lo permita. La importante opción de modelado es la evidencia de tres estados. Si un colector no puede comprobar el producto entregado, registre outcome verified: "unavailable" . No convierta la evidencia faltante en true , y no califique una carrera desconocida como fallida simplemente porque su señal está ausente. Reproduce la brecha con seis carreras El accesorio que acompaña contiene seis correos sintéticos. Las alertas del libro mayor LLM cuando los errores de solicitud son al menos 20%, la latencia p95 excede de 5.000 ms, o el uso de tokens excede de 20.000. El libro mayor de tareas de salud verifica la espera explícita, la finalización declarada con un resultado determinista y la actualidad del progreso. Ejecutar la auditoría con Node.js 20 o más reciente: El resultado exacto es: El desacuerdo es el resultado, no un defecto en ninguno de los libros principales. La ejecución de errores de proveedor necesita una investigación de modelo de servicio aunque el agente todavía está progresando. La carrera lenta se completó con un resultado verificado, por lo que es un problema de rendimiento en lugar de un incidente de falta de trabajo. La espera de aprobación y el fallo de éxito parecen normales para el monitor LLM porque sus llamadas fueron rápidas, baratas y exitosas. Sólo el contrato de tareas expone lo que necesita atención. Los números son un contraejemplo, no un punto de referencia. Seis registros sintéticos no pueden establecer umbrales de alerta universales. Reemplaza los recortes con líneas de base de tu tiempo de ejecución, y reemplaza progress delta con evidencia vinculada al trabajo real. Transformar el contrato de tarea en alertas Comience con un flujo de trabajo de alto valor. Escriba su predicado de finalización antes de agregar otro tablero. Un trabajo de investigación puede requerir un archivo Markdown, al menos dos fuentes accesibles y un libro mayor de pruebas válido de esquema. Un trabajo de codificación podría requerir un parche limpio más un comando de prueba nombrado. Un agente de apoyo podría requerir un boleto creado o una escalada registrada. Luego evalúa las señales en un orden que preserve el significado: 1. Si el tiempo de ejecución o el colector está obsoleto, marque el tiempo de ejecución inaccesible o incierto. 2. Si waiting on es explícito, envía la dependencia en lugar de reiniciar la carrera. 3. Si el tiempo de ejecución declara la finalización, evalúe el predicado del resultado. 4. Si la carrera está activa, pero progress delta se mantiene cero más allá de su ventana, marque que está atascado. 5. Si no se aplica ninguno y el progreso útil es nuevo, deje que funcione. Esta orden impide tres intervenciones ruidosas. Una espera legítima de aprobación no es un estancamiento. Un comando que salió de cero no es automáticamente una tarea completada. Un rastro ocupado con herramientas repetidas no es progreso si el artefacto relevante nunca cambia. Alerta sobre la próxima acción segura, no sólo el síntoma. Una alerta de error del proveedor va al propietario de la aplicación con modelo, operación, clase de error y enlace de rastreo. Una espera de aprobación va a la persona que puede decidir, con el alcance exacto solicitado. Una alerta de resultado faltante apunta al predicado fallido. Un ciclo de retraso recomienda una pausa o investigación limitada; no debe autorizar una corrección irreversible. Mantenga la unión útil sin recoger todo Utilice un run id opaco en ambos libros principales. No ponga en ese identificador el texto del cliente, los secretos, los caminos absolutos o las cargas útiles de las herramientas. Un registro de correlación útil puede contener: Mantenga diferentes las reglas de retención y acceso si los riesgos de los datos difieren. Los histogramas de latencia y de tokens agregados pueden requerir una retención más larga que los intervalos de transmisión rápida. La evidencia del resultado a menudo puede ser un digesto, un conteo, un código de estado o un resultado de esquema en lugar del artefacto en sí. Cuando un operador perfora un rastro, muestre su frescura y el límite de muestreo para que la ausencia no se confunda con la prueba. También hay un límite para la evaluación automática. Las verificaciones deterministas son preferibles para archivos, estado HTTP, filas de base de datos, pruebas y campos estructurados. Si el resultado previsto es cualitativo, un evaluador versionado puede ayudar, pero su puntaje es evidencia con incertidumbreno verdad basada. Calibrarlo contra la revisión humana y preservar un estado unavailable . Donde encaja Sidewisp La dirección del producto de Sidewisp es el segundo libro mayor: una visión de la salud en torno a los tiempos de funcionamiento de los agentes existentes, con evidencia, frescura, prioridad de emisión y límites de aprobación explícitos. No está destinado a reemplazar el tiempo de ejecución, la puerta de entrada modelo o el sistema de rastreo crudo. Esa es la dirección, no una declaración de vigilancia enviada. Sidewisp se encuentra actualmente en versión preliminar privada. El sitio público y el sistema de artículos están en vivo, mientras que la recopilación de agentes de producción y salud, los adaptadores de tiempo de ejecución y la ejecución de recuperación no se envían generalmente. Únete a la vista previa privada si este límite modelo llamada versus resultado coincide con el problema operativo que necesita resolver. Fuentes primarias OpenTelemetry GenAI métricas convenciones semánticas Nombres métricos de estado de desarrollo para operaciones de cliente, flujo de trabajo, agente y herramienta. Guía de seguimiento de SDK de OpenAI Agents tipos de eventos rastreados, comportamiento de exportación y controles de datos sensibles. Langfuse: ¿Qué es la observabilidad y el monitoreo de LLM? un indicador de referencia de la misma intención para la latencia, el rendimiento, los errores, el seguimiento y la evaluación.