Consigna y contexto aplicable
Usted es el responsable de una aplicación de GenAI que recupera documentos, invoca modelos y ejecuta herramientas. El equipo necesita saber qué versión de modelo incrementó el tiempo hasta el primer token, si una herramienta aumentó las fallas, si el costo se concentra en unos pocos inquilinos (tenants) y si es posible reproducir una regresión de calidad sin exponer datos personales en los prompts. Diseñe trazas, métricas, eventos y controles de calidad de datos utilizando las convenciones semánticas de OpenTelemetry.
Este es un problema de validación y modelado de datos de telemetría, no un ejercicio de selección de proveedores. OpenTelemetry define las convenciones semánticas como nombres de atributos y significados compartidos entre bases de código, bibliotecas y plataformas. Las convenciones para GenAI cubren modelos, conversaciones, llamadas a herramientas, uso de tokens y evaluaciones; sin embargo, algunas partes aún se encuentran en evolución, por lo que no todos los atributos deben tratarse como un contrato estable.
Qué evalúa el entrevistador
El entrevistador busca señales derivadas de preguntas de negocio, no un registro repleto de parámetros del modelo. Una respuesta sólida correlaciona una solicitud de usuario individual con el trabajo de recuperación, modelo, herramientas y resultado final, reteniendo al mismo tiempo suficientes dimensiones de versión y de inquilino para explicar una regresión.
Debe definir los límites de los datos. Los prompts, las respuestas, los argumentos de herramientas y los documentos recuperados pueden contener información confidencial; los identificadores de sesión de alta cardinalidad, los identificadores de usuario o el contenido completo no deben convertirse en etiquetas de métricas sin límite. La recolección debe equilibrar la privacidad, el costo de almacenamiento, el muestreo y la retención.
Por último, especifique controles de calidad. Si falta un span padre, una versión del modelo, un motivo de finalización o un conteo de tokens, marque el registro como incompleto y monitoréelo en lugar de presentar un panel que solo aparente ser preciso.
Preguntas para clarificar
Primero pregunte qué resultado es el que importa: tiempo hasta el primer token, latencia total, costo por solicitud, éxito de herramientas, exhaustividad (recall) de recuperación o calidad de la respuesta. Esa elección determina qué trazas, métricas y eventos de evaluación son esenciales.
Luego pregunte sobre la sensibilidad y la jurisdicción. ¿Está permitido almacenar los prompts y las respuestas? ¿Se requiere aislamiento regional o eliminación a nivel de inquilino? Si el contenido sin procesar está prohibido, utilice hashes, resúmenes anonimizados, identificadores de referencia y reproducción segura fuera de línea.
Por último, pregunte sobre el volumen y la retención. La tasa de solicitudes, la cantidad de llamadas a modelos, la profundidad de herramientas, la tasa de muestreo y el período de retención determinan los recolectores, las colas, la partición del almacenamiento y el presupuesto de costos.
Marco de respuesta en 30 segundos
Puede decir:
“Modelaría cada solicitud de usuario como una sola traza, donde la recuperación, la generación, las llamadas a herramientas y la evaluación sean spans o eventos secundarios versionados. Las métricas utilizan dimensiones de baja cardinalidad como modelo, proveedor, flujo de trabajo y estado de resultado. Los prompts, las respuestas y los argumentos de herramientas se envían a un flujo de eventos controlado con anonimización, muestreo y acceso auditado. Cada registro se verifica para comprobar la correlación de trazas, el orden, la versión del modelo y los conteos de tokens; los campos faltantes se convierten en fallas de calidad de datos. Los paneles conectan latencia, costo, errores y puntajes de calidad, mientras que una muestra fija de solicitudes permanece disponible para reproducción segura.”
Respuesta detallada paso a paso
Dibujar el grafo de señales de extremo a extremo
El span de entrada registra el ID de la solicitud, un resumen del inquilino y la versión del flujo de trabajo. Un span de recuperación registra el ID de origen, el resumen de la consulta y el conteo de resultados. Un span de modelo registra el proveedor, el modelo solicitado, el modelo de respuesta, el indicador de transmisión (streaming), el tiempo hasta el primer token y el uso de tokens. Un span de herramienta registra el tipo de herramienta, el ID de llamada y el estado del resultado. Un evento de evaluación registra el nombre del evaluador, el puntaje y una referencia a la explicación.
Utilizar dimensiones métricas de baja cardinalidad
Agregue latencia, tokens, costo y éxito por modelo, proveedor, flujo de trabajo, región, estado de resultado y clase de error. Mantenga los ID de sesión, ID de usuario, ID de documento y el texto completo de errores en trazas o eventos en lugar de etiquetas métricas para evitar una explosión de series temporales.
Separar eventos de contenido de métricas de tiempo de ejecución
La guía de GenAI de OpenTelemetry describe trazas, métricas y eventos como tres señales distintas. Los prompts y las respuestas se adaptan a un flujo de eventos porque son voluminosos, confidenciales y están sujetos a una retención diferente. Las métricas de tiempo de ejecución mantienen conteos, latencia y costo; los eventos de contenido emplean almacenamiento controlado, cifrado y una retención más corta.
Registrar versiones y causalidad
Cada span registra versiones de modelo, plantilla de prompt, recuperador, definición de herramienta y evaluador. La investigación de una regresión debe conectar un puntaje con la solicitud exacta del modelo y la versión de los datos de entrada; un simple nombre de modelo no puede distinguir desviaciones de alias, cambios de enrutamiento ni modificaciones en los prompts.
Controlar el muestreo y el costo
Conserve trazas completas a una tasa fija y luego aumente el muestreo para errores, latencias extremas, puntajes bajos y versiones nuevas. Agregue los conteos de tokens y de llamadas a herramientas en tiempo real; aplique un límite presupuestario por inquilino mediante limitación de tasa (throttling) o degradación de servicio. Las reglas de muestreo pertenecen a los metadatos de calidad para que las comparaciones entre versiones sigan siendo válidas.
Aplicar controles de privacidad y acceso
Anonimice campos en el SDK o en el recolector para que contraseñas, datos personales y claves nunca ingresen a los atributos. Autorice los eventos de contenido por separado de las métricas de tiempo de ejecución, utilizando alcance por inquilino, referencias cifradas e índices de eliminación. El argumento de «solo para uso interno» no es una justificación para retener contenido confidencial.
Validar completitud y orden
Compruebe relaciones padre-hijo, marcas de tiempo monotónicas, estado de finalización, versión del modelo e ID de llamadas a herramientas para cada traza. En cuanto a las métricas, verifique unidades, límites de intervalos (buckets), contadores monotónicos y reportes duplicados. Para los eventos, valide la versión del esquema, el estado de anonimización y los límites de tamaño. Envíe las fallas a una cola de datos erróneos con un código de motivo.
Conectar la calidad a través de eventos de evaluación
Un evento de evaluación contiene el nombre del evaluador, el puntaje, etiquetas y una referencia a la explicación. No trate un puntaje automatizado como la verdad absoluta; registre las versiones del evaluador y del conjunto de datos, además de muestras humanas. Una regresión de calidad debe revisarse junto con la latencia, el costo y los errores, en lugar de optimizar una sola señal de forma aislada.
Respuesta de ejemplo de alta calidad
“Representaría cada solicitud como una traza correlacionada: entrada, recuperación, modelo, herramientas y evaluación son spans o eventos versionados. Las métricas utilizan dimensiones de baja cardinalidad de modelo, proveedor, flujo de trabajo y resultado para agregar el tiempo hasta el primer token, la latencia total, los tokens, el costo y los errores. Los prompts, las respuestas y los argumentos de herramientas van a un flujo de contenido anonimizado y con auditoría de acceso en lugar de etiquetas métricas. La capa de recolección comprueba enlaces padre-hijo, orden, esquemas, versiones de modelo y conteos de tokens; los registros no válidos ingresan a una cola de datos erróneos. Las trazas completas se muestrean a una tasa fija, mientras que los errores, las solicitudes lentas y las regresiones de calidad reciben mayor muestreo. Los paneles combinan métricas de tiempo de ejecución con puntajes de evaluación y datos de reproducción utilizando versiones del conjunto de datos y del evaluador.”
Errores comunes
Colocar todo el contenido en etiquetas de métricas
Patrón de falla: usar ID de usuario, ID de sesión o prompts completos como etiquetas. Por qué falla: la alta cardinalidad puede saturar el almacenamiento y las consultas mientras incrementa la exposición de privacidad. Corrección: mantenga las métricas con baja cardinalidad y coloque el contenido en eventos controlados.
Registrar únicamente el nombre del modelo
Patrón de falla: comparar cada resultado mediante un único campo de nombre de modelo. Por qué falla: el enrutamiento de alias, las plantillas de prompts, los recuperadores y las versiones de herramientas se vuelven indistinguibles. Corrección: registre el modelo solicitado, el modelo de respuesta, el flujo de trabajo y las versiones de dependencias.
Optimizar únicamente el costo de tokens
Patrón de falla: declarar el éxito cuando el costo disminuye. Por qué falla: el tiempo hasta el primer token, el éxito de las herramientas o la calidad de la respuesta pueden degradarse. Corrección: monitorice costo, latencia, errores, recuperación y evaluación de forma conjunta.
Almacenar prompts y respuestas sin procesar
Patrón de falla: retener texto sin procesar indefinidamente para reproducción. Por qué falla: el contenido puede incluir datos personales, claves o información compartida entre inquilinos. Corrección: anonimice campos, use retención corta, referencias cifradas, acceso a nivel de inquilino e índices de eliminación.
Ignorar datos erróneos
Patrón de falla: incluir registros con padres faltantes o conteos de tokens incompletos en el denominador. Por qué falla: el panel aparenta estar completo pero no puede explicar sus cifras. Corrección: defina filtros de completitud, una cola de datos erróneos y un panel de calidad que distinga los datos faltantes de un cero real.
Preguntas de seguimiento y respuestas
¿Qué ocurre si el equipo solicita registrar el proceso completo de razonamiento?
Clarifique si el negocio necesita evidencia auditable, trazas de herramientas o el razonamiento interno del modelo. Dé preferencia a referencias de entrada, llamadas a herramientas, versiones, evidencia de evaluación y resúmenes de resultados; no retenga contenido confidencial innecesario ni texto de razonamiento interno.
¿Qué sucede si las convenciones de GenAI migran?
Almacene las versiones de esquema en recolectores y almacenes de datos, mapee los campos antiguos a los nuevos y utilice escrituras duales o vistas de compatibilidad durante la migración. Agrupe los paneles por versión de convención en lugar de mezclar significados.
¿Qué pasa si el tráfico en horas pico hace que las trazas completas sean demasiado costosas?
Conserve trazas completas para errores y latencia extrema, tome muestras del tráfico normal a una tasa fija y retenga métricas agregadas junto con resúmenes de eventos. Registre la tasa de muestreo, las reglas de activación y los motivos de descarte como metadatos de calidad.
¿Qué sucede si los puntajes de evaluación caen mientras la latencia mejora?
Segmente por modelo, plantilla de prompt, conjunto de datos de recuperación, versión de herramienta e inquilino, y verifique que el conjunto de datos y el evaluador no hayan cambiado. Permita que el criterio de aprobación del lanzamiento sopese la regresión de calidad frente a las mejoras de rendimiento en lugar de aceptar una sola métrica.
¿Cómo demuestra que las trazas no cruzan los límites entre inquilinos?
Ejecute pruebas de límites de inquilinos en las capas de recolección, transporte, almacenamiento y consulta. Los datos sintéticos deben verificar el alcance de inquilino en atributos, eventos y referencias; las consultas anómalas emiten alertas de auditoría. Las solicitudes de eliminación deben ser capaces de localizar cada evento derivado mediante un índice.