后Hog LLM可观察性:测试连接键

一旦代理工作可以重新尝试,离开浏览器会话或与另一个任务共享会话后, PostHog LLM可观测性需要一个故意的加入键. $session id , $ai session id 和 $ai trace id 是有用的,但没有一个是被接受的作品的自动身份. 在14次实验中,通过前端会议进行组合,产生了两个组合组和两个错误的生成到结果对配. 按AI会议进行组分,将一次重试任务分为两次会议,但仍然产生了一个错误的配对. 一个持久的 work id 将所有三个预期的验证结果联系在一起, 保存了重试作为一个任务, 并将错误工作的收据作为孤儿隔离, 操作规则是具体的:使用 PostHog 会议进行导航和集成,用于因果模型活动的痕迹,以及为最终产生结果的单元使用隐私安全的 work id . 然后一起查询这些字段. 这样,跟踪,成本和产品分析成为一个证据合同,而不是一个松散的仪表板. 四个标识符回答四个不同的问题 对于AI可观测事件,PostHog的AI 痕迹模型需要 $ai trace id . 一个跟踪组,涉及到几代和跨度. 答案是:哪些模型和工具活动属于这种互动? AI会议指南定义了 $ai session id 为一个可选的,根据应用选择的跨痕迹组合. 它可以代表工作流程,线程,对话或其他逻辑界限. 同样的指南将其区别于标准前端 $session id ,通常在浏览器中捕获. PostHog还使用 distinct id 将事件与个人或服务身份联系起来. 这说明了谁或什么发射事件;它不应该被任务识别符加载过度. 一个被接受的代理工作单位需要第四个身份: 标识符 良好的边界 使用作工作键时故障 distinct id 人,账户或服务 一个演员可以同时完成许多任务 $session id 前端访问 一次访问可以开始多项任务 $ai session id 应用定义的AI会议 再试或重新启动可以创建另一个会话 $ai trace id 一个因果痕迹 复试和交付的多痕迹作品碎片 work id 一个被接受的任务及其结果 必须由应用程序创建和传播 在第一次模型调用之前,系统接受任务时创建 work id . 让它变得不透明,稳定. 它应该能经历一次重试,工作者重新启动,等待批准,浏览器关闭和模型更改. 不要从电子邮件地址,提示,路径或目的地名称中获取它. 邮箱的生产文件定义了生成事件模型. 它的定制性文件显示使用 posthogProperties 和 posthogDistinctId 的JavaScript包装示例,而会议指南则记录 $ai session id 作为应用程序选择的组合. 通过 npm latest 标签观察到的包装版本是2026年7月27日的 @posthog/ai 8.4.0 ;将此视为已有日期的快照,并检查您的提供商和安装版本的当前文档. 复制了14场事件的合钥匙实验 设备包含了5个被接受的工作身份证和一个故意错误的结果身份证. 它模拟了三个失败形状, 只有会议仪表板经常隐藏: 1. work 102 在浏览器会话中启动 browser b 在前端文本消失后,重新尝试,并继续在新的 AI 会议. 它的验证结果带着 work id ,但没有会议身份证. 2. 在同一浏览器会话中启动 work 103 和 work 104 . 只有 work 103 具有验证结果,而 work 104 具有产品事件,但没有结果. 3. 在 work 105 下完成AI会话 ai run d ,但以后的结果事件携带 work 999 ,同时保持相同的前端和AI会话值. 这些不是合成命名技巧. 它们代表了常见的拓学变化:背景重试,一次访问的同步任务,以及与相关的元数据不一致的事件. 我将 PostHog 形状的事件加载到内存SQL表中,并评估了三个策略. 一个策略只有当一个群体包含一代和同一个工作的预期结果时才获得信誉. 当一个一代人对一个工作的ID分享一个组与另一个结果时,它会记录一个错误的对. 测量结果是: 相关战略 正确的验证工作 错过预期的工作 混合组 错误的对 碎片复试 : : : : : 前端 $session id 3中的2 1 2 2 0 $ai session id 3中的2 1 1 1 1 耐用 work id 排名第 3 0 0 0 0 前端会议合并将 work 103 与 work 104 并将 work 105 与错误的 work 999 结果合并. AI 会议连接避免了同时浏览器碰撞,但将 work 102 分为 ai run b1 和 ai run b2 ;结果没有AI会议连接. 它也加入了 work 105 到 work 999 ,因为它们都携带了 ai run d . 其他国家 work id 查询产生了6行:5个被接受的工作单位加上 work 999 . 这六行只有一个结果,零代. 而不是将 work 105 变为绿色,查询揭示了一个孤儿结果事件. 在 HogQL 中构建工作矩阵 PostHog 文档 SQL 访问为 HogQL,一个围绕 ClickHouse SQL 的包装,简化的事件属性访问. 事件属性使用点符号,包括美元前的 PostHog属性. 支持的聚合物包括 countIf , uniqExactIf 和 groupUniqArray . 这个查询创建每一个持久工作键一个行: 后Hog SQL 指南显示 events 表,属性访问,SQL洞察,以及 HogQLQuery API形状. 在集成参考中列出了在这里使用的条件和精确独特性函数. 在计算分数之前解释排列形状: generation count = 0 和 outcome count 0 是孤儿结果,并非经过验证的工作. ai session count 1 可以是合法的重试或转让;在称之为复制品之前检查 retry count . 在背景工作中, frontend session count = 0 是正常的. product event count 0 显示产品行为,而不是目的地验证. 当一个被接受的任务跨度再次尝试时,可以预期 trace count 1 . 对于 work 102 ,矩阵报告了两个痕迹,两个AI会议,一个重试,一个结果. 排列保持完整,因为工作键存活了两个会议变化. 这就是实验的核心结果. 在信任仪表板之前,检查碰撞 一个工作矩阵显示了成功组合的东西. 碰撞审计询问其他关键是否将无关的工作组合在一起. 在前端会议中, 用 $ai session id 来重复. 在固定中,前端审计报告 browser c 与 work 103 和 work 104 ,加上 browser d 与 work 105 和 work 999 . 其他国家 AI 会议审计报告 ai run d 随着 work 105 并且 work 999 . 这并不证明哪个事件是错误的. 它确定了一个基于会议的归因不安全的边界,并为运营商提供了一个小的调查集. 另一个方向进行第二次检查:计算每个 work id 的分别会议值. 一个工作键,包括两个AI会议和一次重试事件,可能是尝试中连续性. 在许多会议中出现的工作钥匙,但没有再尝试,转移或重复记录,可能表明重复使用钥匙. 机器和运行器是可以故意检查的. 当地运行者将在所有14个事件中执行SQL工作矩阵,然后评估三个合并策略并确认五项发现: 这不是一个现场 PostHog 基准. 它不测量摄入延迟,查询API权限,保留或租户特定的属性类型. 它测试了仪表板背后的关系要求. 在生产中使用查询之前,将其运行为一个无害的类集合上的SQL洞察,并将返回的列与您的固定进行比较. 工具键没有泄漏任务内容 在每个相关事件中将相同的不透明工作键附加. 在支持的JavaScript包装示例中,自定义属性页文档 posthogProperties 和 posthogDistinctId ,会议页面将 $ai session id 放置在 posthogProperties 内,隐私页面文档 posthogPrivacyMode . 结合这些记录的选项,请求形状看起来像: 使用您的提供商集成和安装版本支持的精确选项. 包邮公司的隐私模式不包括 $ai input 和 $ai output choices ;它不清除任意的定制属性. 保持一个排放名单. 良好的字段是不透明的ID,试验号码,工作流版本,低卡丁度状态,时间标签和哈希. 坏的字段是提示,完成,秘密,电子邮件,原始文件路径和供应商的有效载荷. 仅在其底层事实存在后,发出相同的 work id 的申请事件. 一个 report view opened 事件属于产品分析. 一个 agent outcome verified 事件应遵循一个权威的反读,并包括一个哈希的目的地引用以及验证的内容或版本哈希. 两个事件可以分享一个查询,而不假装它们意味着同一个东西. 保持 distinct id 稳定,为你想分析的演员. 保持 $session id 和 $ai session id 为它们的文档导航边界. 模型变得更容易调试,因为没有一个领域做了三项工作. 用实验作为操作测试 开始用三个鱼而不是一个大仪表板: 一项任务在一个浏览器和AI会话中开始和完成; 在浏览器会话结束后,在新的AI会话中重新尝试的一个任务; 两个任务从同一浏览器会话开始,结果只有一个. 在测试环境中添加一个故意不匹配的结果事件. 你的工作矩阵应该被视为孤儿. 会议碰撞查询应该标记共享组. 如果一个仪表板让无与伦比的任务看起来是验证的,则连接键仍然是错误的. 监控合同本身: 计数 AI 缺失事件 work id ; 计算结果事件,没有生成行; 计算被接受的工作身份证,分为会议,没有再试验或转让证据; 在将最近的缺席视为失败之前,测量事件吞延迟; 警报会出现一次性碰撞或重复使用工作钥匙的突然增加. 费用就会更安全地解释. 总量生成成本按 work id ,而不仅仅是按会议,并且只按您的业务接受的结果状况进行分工. 结果是每次重复试验的验证工作单位的成本,而不是每次追踪或浏览器访问的成本. 适合Sidewisp的地方 邮箱非常适合捕捉事件,产品分析,SQL洞察和调查. 实验保留了这些优势,同时使操作判断单元明确. Sidewisp旨在在使用证据,新鲜度,不确定性,批准界限和验证,围绕现有剂运行时间成为健康层. 它不是替代运行时间,强制模型门户或 PostHog替代. 今天还没有发送生产监测器和恢复器. Sidewisp 目前处于私密预览阶段。 如果这个连接密钥问题符合您的环境,请加入私人预览等待列表,并描述您的工作时间,会议界限和结果. 在此之前,请保持PostHog的识别器诚实: 会议导航, 痕迹解释活动, 持久的工作键带来了操作结果.