PostHog LLM Observabilidad: Prueba de la llave de unión

La observabilidad PostHog LLM necesita una clave de unión deliberada una vez que el trabajo del agente pueda volver a intentar, dejar una sesión de navegador o compartir una sesión con otra tarea. $session id , $ai session id y $ai trace id son útiles, pero ninguno es automáticamente la identidad del trabajo aceptado. En un experimento de 14 eventos, el agrupamiento por la sesión frontal creó dos grupos combinados y dos emparejamientos equivocados de generación a resultado. El agrupamiento por la sesión AI dividió una tarea repetida en dos sesiones y aún produjo un emparejamiento incorrecto. Un work id duradero unió los tres resultados verificados esperados, conservó el retiro como una tarea y aisló un recibo de trabajo incorrecto como huérfano en lugar de adjuntarlo a un rastro saludable. La regla de funcionamiento es específica: utilizar sesiones PostHog para la navegación y la agregación, rastros para la actividad del modelo causal, y un work id seguro de la privacidad para la unidad que eventualmente debe producir un resultado. Entonces consulta esos campos juntos. Así es como los rastros, costos y análisis de productos se convierten en un contrato de evidencia en lugar de una colección suelta de tablas de control. Cuatro identificadores responden a cuatro preguntas diferentes El Modelo de rastreo AI de PostHog requiere $ai trace id para eventos de observabilidad AI. Un grupo de rastro relacionado generaciones y períodos. Responde: ¿qué modelo y qué herramienta pertenecían a esta interacción? El Guía de sesiones AI define a $ai session id como un agrupamiento opcional elegido por aplicación a través de rastros. Puede representar un flujo de trabajo, un hilo, una conversación u otro límite lógico. La misma guía lo distingue del frontend estándar $session id , que generalmente se captura en el navegador. PostHog también utiliza distinct id para asociar eventos con una persona o identidad de servicio. Eso responde a quién o qué emitió el evento; no debe sobrecargarse con un identificador de tarea. Una unidad aceptada de trabajo de agente necesita una cuarta identidad: Identificador Un buen límite Fallo cuando se utiliza como llave de trabajo distinct id Persona, cuenta o servicio Un actor puede poseer muchas tareas simultáneas $session id Visita de primera línea El trabajo de fondo puede sobrevivir; una visita puede comenzar varias tareas $ai session id Sesión AI definida por aplicación Una nueva prueba o reinicio puede crear otra sesión $ai trace id Un rastro causal Fragmentos de trabajo con múltiples rastros en retrasos y entregas work id Una tarea aceptada y su resultado Debe ser creado y propagado por la aplicación Crear work id cuando el sistema acepte la tarea, antes de la primera llamada de modelo. Haga que sea opaco y estable. Debería sobrevivir a un nuevo intento, reiniciar el trabajo, esperar la aprobación, cerrar el navegador y cambiar el modelo. No lo obtenga de una dirección de correo electrónico, un aviso, un camino o un nombre de destino. El documentación de generación de PostHog define el modelo de eventos de generación. Su Documentación sobre las propiedades aduaneras muestra ejemplos de envase de JavaScript utilizando posthogProperties y posthogDistinctId , mientras que la guía de sesión documenta $ai session id como una agrupación elegida por la aplicación. La versión del paquete observada a través de la etiqueta npm latest fue @posthog/ai 8.4.0 el 27 de julio de 2026; trate eso como una instantánea fechada y compruebe la documentación actual para su proveedor y la versión instalada. Reproduzca el experimento de 14 eventos con la clave conjunta El dispositivo contiene cinco identificaciones de trabajo aceptadas y una identificación de resultado deliberadamente incorrecta. Modela tres formas de fallas que los paneles de solo sesión a menudo ocultan: 1. work 102 comienza en la sesión del navegador browser b , vuelve a intentarlo después de que el contexto de frontend haya desaparecido, y continúa bajo una nueva sesión AI. Su resultado verificado llega con work id pero sin ID de sesión. 2. work 103 y work 104 comienzan dentro de la misma sesión del navegador. Sólo work 103 tiene un resultado verificado, mientras que work 104 tiene un evento de producto pero ningún resultado. 3. work 105 completa bajo la sesión AI ai run d , pero un evento de resultado posterior lleva work 999 manteniendo los mismos valores de la sesión frontend y AI. Esos no son trucos de nombres sintéticos. Representan cambios comunes en la topología: una nueva prueba de fondo, tareas simultáneas de una visita y un evento cuya correlación con los metadatos no está de acuerdo. Cargué los eventos en forma de PostHog en una tabla SQL en memoria y evalué tres estrategias. Una estrategia sólo recibe crédito cuando un grupo contiene tanto una generación como el resultado esperado para el mismo trabajo. Graba un par equivocado cuando una generación para una identificación de trabajo comparte un grupo con un resultado para otro. El resultado medido fue: Estrategia de correlación Trabajo verificado correcto Trabajo esperado perdido Grupos confluidos Parejas equivocadas Los ensayos en fragmentos : : : : : Frente $session id 2 de 3 1 2 2 0 $ai session id 2 de 3 1 1 1 1 work id resistente 3 de 3 0 0 0 0 La sesión frontend se unió work 103 con work 104 y se unió work 105 con el resultado work 999 equivocado. La unión de la sesión AI evitó la colisión simultánea del navegador, pero dividió work 102 a través de ai run b1 y ai run b2 ; su resultado no tenía sesión AI para adjuntar. También se unió a work 105 a work 999 porque ambos llevaban ai run d . La consulta work id produjo seis filas: cinco unidades de trabajo aceptadas más work 999 . Esa sexta fila tuvo un resultado y cero generaciones. En lugar de convertir a work 105 en verde, la consulta expuso un evento de resultado huérfano. Construir la matriz de trabajo en HogQL PostHog documenta el acceso a SQL como HogQL, un envase alrededor de ClickHouse SQL con acceso simplificado a propiedades de eventos. Las propiedades de eventos utilizan notación de puntos, incluidas las propiedades PostHog prefijadas en dólares. Los agregados apoyados incluyen countIf , uniqExactIf y groupUniqArray . Esta consulta crea una fila por clave de trabajo duradera: El Guía de SQL de PostHog muestra la tabla events , el acceso a las propiedades, las perspectivas SQL y la forma de API HogQLQuery . El referencia de agregación enumera las funciones de singularidad condicional y exacta utilizadas aquí. Interpretar la forma de la fila antes de calcular una puntuación: generation count = 0 y outcome count 0 es un resultado huérfano, no un trabajo verificado. ai session count 1 puede ser un intento legítimo o una entrega; inspeccione retry count antes de llamarlo un duplicado. frontend session count = 0 es normal para el trabajo de fondo. product event count 0 muestra el comportamiento del producto, no la verificación de destino. trace count 1 se puede esperar cuando una tarea aceptada se extiende de nuevo. Para work 102 , la matriz informa dos rastros, dos sesiones AI, una nueva prueba y un resultado. La fila se mantiene intacta porque la clave de trabajo sobrevivió a ambos cambios de sesión. Ese es el resultado central del experimento. Controlar las colisiones antes de confiar en un panel de control Una matriz de trabajo muestra lo agrupado con éxito. Una auditoría de colisión pregunta si las claves alternativas habrían agrupado trabajos no relacionados. Ejecutar esto contra las sesiones de frontend: Repita con $ai session id . En la fijación, la auditoría frontend devuelve browser c con work 103 y work 104 , más browser d con work 105 y work 999 . La auditoría de la sesión AI devuelve ai run d con work 105 y work 999 . Esto no demuestra cuál evento está mal. Identifica un límite en el que la atribución basada en la sesión no es segura y proporciona al operador un pequeño conjunto de investigaciones. Añadir una segunda comprobación en la otra dirección: contar el número de valores de sesión distintos por work id . Una clave de trabajo con dos sesiones AI y un evento de retoma es probablemente la continuidad entre los intentos. Una llave de trabajo que aparece en muchas sesiones sin volver a intentarlo, entregarla o registrar su currículum puede indicar que la llave se reutiliza. La fijación y el corredor son deliberadamente inspectables. El ejecutor local ejecuta una matriz de trabajo SQL en todos los 14 eventos, luego evalúa las tres estrategias de unión y afirma cinco hallazgos: No es un punto de referencia de PostHog en vivo. No mide la latencia de ingesta, los permisos de API de consulta, la retención o los tipos de propiedades específicos del inquilino. Prueba la afirmación relacional detrás del tablero. Antes de usar la consulta en producción, ejecutarla como una visión SQL en un conjunto canario inofensivo y comparar las columnas devueltas con su fijación. Instrumentar la llave sin filtración de contenido de la tarea Anexar la misma clave de trabajo opaca a cada evento relevante. En los ejemplos de envoltura de JavaScript soportados, la página de propiedades personalizadas documenta posthogProperties y posthogDistinctId , la página de sesiones coloca $ai session id dentro de posthogProperties , y la página de privacidad documenta posthogPrivacyMode . Combinando esas opciones documentadas, la forma de solicitud se parece a: Utilice las opciones exactas compatibles con la integración de su proveedor y la versión instalada. El modo de privacidad de PostHog excluye a $ai input y $ai output choices ; no desinfecta propiedades personalizadas arbitrarias. Mantenga una lista de permisos. Los buenos campos son ID opacos, números de intento, versiones de flujo de trabajo, estados de baja cardinalidad, sellos de tiempo y hashes. Los campos malos son las instrucciones, completos, secretos, correos electrónicos, caminos de archivos crudos y cargas útiles del proveedor. Emite eventos de solicitud con el mismo work id sólo después de que exista su hecho subyacente. Un evento report view opened pertenece al análisis de productos. Un evento agent outcome verified debe seguir una lectura de nuevo autorizada e incluir una referencia de destino hashada más el contenido verificado o el hash de versión. Los dos eventos pueden compartir una pregunta sin pretender que significan lo mismo. Mantenga estable distinct id para el actor que desea analizar. Mantenga $session id y $ai session id para sus límites de navegación documentados. El modelo se vuelve más fácil de depurar porque ningún campo está haciendo tres trabajos. Usar el experimento como prueba de funcionamiento Comience con tres canarios en lugar de un tablero grande: una tarea que comienza y termina en un navegador y en una sesión AI; una tarea que vuelva a intentarse en una nueva sesión AI después de que la sesión del navegador haya terminado; dos tareas iniciadas desde la misma sesión del navegador, con un resultado para una sola. Añadir un evento de resultado deliberadamente incompatible en un entorno de ensayo. Su matriz de trabajo debería aparecer como un huérfano. Las consultas de colisión de sesión deben marcar los grupos compartidos. Si un panel hace que la tarea incomparable parezca verificada, la clave de unión sigue siendo incorrecta. Supervisa el contrato mismo: contar los eventos AI que faltan en work id ; contar los eventos de resultado sin fila de generación; contar las identificaciones de trabajo aceptadas divididas entre sesiones sin pruebas de retoma o entrega; medir el retraso en la ingestión del evento antes de tratar una ausencia reciente como un fracaso; alerta sobre aumentos repentinos de colisiones de sesión o claves de trabajo reutilizadas. Los costos se vuelven más seguros de interpretar. El costo de generación de sumas por work id , no simplemente por sesión, y dividir sólo por trabajo con el estado de resultado que su empresa acepta. El resultado es el costo por unidad de trabajo verificada en retrasos, no el costo por rastreo o visita al navegador. Donde encaja Sidewisp PostHog es muy adecuado para la captura de eventos, análisis de productos, conocimientos SQL e investigación. El experimento aquí mantiene esas fortalezas al tiempo que hace explícita la unidad de juicio operativo. El Sidewisp está destinado a convertirse en una capa de salud alrededor de los tiempos de funcionamiento de los agentes existentes, utilizando pruebas, frescura, incertidumbre, límites de aprobación y verificación. No es un tiempo de ejecución de reemplazo, una puerta de entrada de modelo obligatoria o un sustituto de PostHog. Los adaptadores de monitoreo de producción y recuperación no se envían hoy. Sidewisp se encuentra actualmente en versión preliminar privada. Si este problema de la clave conjunta coincide con su entorno, únete a la lista de espera de la vista previa privada y describa qué horarios de ejecución, límites de sesión y resultados cruzan su trabajo. Hasta entonces, mantenga honestos los identificadores de PostHog: las sesiones navegan, los rastros explican la actividad, y la clave de trabajo duradero lleva el resultado operativo.