PostHog Signals 分组管线离线评估解析从 2026-03-16 报告读懂 ARI、匹配失败模式与裁判指标【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog导读本文以 products/signals/eval/reports/2026-03-16.md 这份评估报告为骨架深入解读 PostHog Signals 产品中**信号分组管线signal grouping pipeline**的一次离线offline端到端评估结果。报告中记录了 91 个合成信号、41 个 ground-truth 分组、54 份产出报告的聚类质量ARI、同质性、完整性、纯度、组召回、匹配失败模式分布、按来源划分的 pre-emit 可操作性检查以及 Safety/Actionability 两个报告级裁判的准确率。读完本文你将理解报告中每个指标的业务含义与计算口径、失败模式尤其是 SPECIFICITY_SPLIT背后对应的管线阶段以及如何在本地复现这次评估并用 HogQL 查询同样的指标。一、这份报告是什么Signals 分组管线的离线评估PostHog Signals 是一个将 Zendesk、GitHub、Linear 等外部工单/Issue 信号聚合为报告report的功能多个信号如果描述同一个问题应被聚类到同一份报告中从而让用户一次看到问题的全貌。为了保证聚类质量仓库在 products/signals/eval/ 下维护了一套端到端评估end-to-end eval其目标定义在 AGENTS.md 中将合成信号送入真实管线LLM 查询生成 → 嵌入检索 → LLM 匹配 → 特异性校验 → 摘要 → 安全裁判 → 可操作性裁判与人工标注的 ground-truth 分组对比衡量管线把信号聚成报告的效果。关键设计是管线真实、基础设施打桩用内存版EmbeddingStore替代 ClickHouse Kafka、用ReportStore替代 Postgres实现见 mock.py从而在纯 Python 测试环境中跑完整链路。2026-03-16.md正是某一次离线评估产出的结果快照包含聚合指标、匹配质量、裁判准确率等若干层面供开发者在迭代分组逻辑时对比基线。从文件命名看reports/目录下还保存着 2026-03-17.md、2026-08-18.md、2026-09-03.md 等后续报告说明这套评估是持续迭代、逐次对比的机制本文的 03-16 报告是其中的基线记录之一。二、本次运行的测试集与执行规模报告开头给出了本次评估的规模信息91 个信号signals由合成数据生成来自 Zendesk、GitHub、Linear、error tracking 等来源信号内容格式在 data_spec.py 中定义如 Zendesk 使用subject/description字段、GitHub 使用title/body、error tracking 按 cymbal 格式渲染描述。41 个 ground-truth 分组groups人工标注的正确答案——这些信号真实归属于哪 41 个主题分组。54 份报告reports produced管线最终产出 54 份报告数量多于 ground-truth 的 41 组说明存在过度拆分现象下文失败模式会量化这一点。信号到达顺序并非按组排列而是由 common.py 中的get_signals_stream()用固定随机种子RNG_SEED 1337将各组信号交错打乱模拟真实世界的乱序到达同时保持组内顺序。这意味着管线必须在信号不按主题排队的情况下完成在线聚类难度更接近生产环境。每个信号经历的管线阶段从 AGENTS.md 与 eval_grouping_e2e.py 的编排逻辑看本次评估中每个信号依次经过以下阶段Pre-emit摘要长描述、做可操作性检查actionability check经由内部 LLM 网关调用 Claude Haiku。不满足可操作性的信号在此被丢弃。MatchLLM 生成检索查询 → OpenAI 嵌入text-embedding-3-small→ 对已存信号做余弦相似度检索 → LLM 判断并入已有报告还是新建报告 → 特异性校验specificity judge确认匹配是否过于宽泛。Persist存储信号与嵌入更新报告元数据。Judge全部信号处理完后对每份报告做摘要、安全裁判提示注入检测与可操作性裁判。所有 LLM 调用统一走内部 LLM 网关LLM_GATEWAY_URL信号并发执行但 match persist 阶段由asyncio.Lock串行化以保证嵌入库与报告库在做并入/新建决策时看到一致视图并发上限MAX_CONCURRENT_RUNS 70定义在 common.py。三、聚合指标Aggregate metrics聚类的四个体检项报告的第一张核心表是聚合指标MetricScoreARI0.7059Homogeneity0.9923Completeness0.9065Mean purity0.9954Mean group recall0.6790Malicious leaked rate0.2083 (5/24)这些指标由 sklearn 的adjusted_rand_score、homogeneity_completeness_v_measure等函数计算见 eval_grouping_e2e.py 的导入并结合报告里的定义逐项解读ARI调整兰德指数Adjusted Rand Index衡量管线聚类结果与ground-truth 分组的相似度经随机机会校正取值 -111 为完全一致。本次 0.7059说明聚类与人工标注的一致性处于中上水平。Homogeneity同质性 0.9923每份报告里只包含来自同一个真实组的信号。越接近 1.0说明越没有过度聚合overgrouping。本次表现优秀。Completeness完整性 0.9065某个真实组的所有信号是否都落在同一份报告里。越接近 1.0说明越没有欠聚合undergrouping。本次略低于同质性提示存在一定程度的组被拆分。Mean purity平均纯度 0.9954每份报告中主导组信号所占的平均比例即报告内容有多纯粹。Mean group recall平均组召回 0.6790一个真实组的信号被其最佳匹配报告捕获的比例的平均值。0.679 意味着平均约 32% 的信号没有与同组信号聚在一起——这是本次运行最薄弱的环节。Malicious leaked rate恶意信号泄漏率 0.2083 (5/24)24 个不安全的恶意/提示注入信号中有 5 个未被安全裁判拦截而通过了管线泄漏率 20.83%。这是安全维度的关键红线指标后续 03-17 报告将其降到 0/24见下文的演进对比。从源码角度这些指标在 AGENTS.md 中有同样的定义清单并被作为$ai_evaluation事件中的grouping-aggregate实验捕获用于在 PostHog 内做长期趋势监控。四、匹配质量失败模式的分布与 SPECIFICITY_SPLIT 的来源报告的第二张核心表关注每个信号的匹配决策质量本次共覆盖 104 个匹配决策Failure modeCount% of totalCORRECT7976.0%SPECIFICITY_SPLIT1312.5%UNDERGROUP65.8%OVERGROUP65.8%失败模式的定义在 common.py 中定义了三个基础匹配结果枚举NONE匹配正确对应报告中的 CORRECTUNDERGROUP应该并入已有报告却新建了一份欠聚合OVERGROUP加入了属于其他 ground-truth 组的报告过度聚合。而报告中的SPECIFICITY_SPLIT是特异性校验阶段specificity judge引入的第四种状态matcher 原本给出的匹配被特异性判断器判定为过于宽泛而否决/拆分导致本应属于同一报告的信号被拆开。报告用一行专门给出了它的体量Total undergrouping (UNDERGROUP SPECIFICITY_SPLIT): 19/104 (18.3%). Specificity split share of undergrouping: 13/19 (68.4%).也就是说本次 18.3% 的欠聚合错误中68.4%13/19是由特异性判断器过度拆分造成的而不是 matcher 本身没有识别出关联。这直接点出了本次运行的一个优化方向——特异性判断器的阈值/行为需要校准。与后续报告的印证这种特异性判断器引入拆分的现象并非孤例2026-03-17.md 明确记录特异性判断器把 14 个 overgroup 转为正确匹配但同时引入了 5 个新的 undergroup净 92026-08-18.md 则在模型对比中发现在 sonnet-5 上特异性判断器是净损失84.9% → 83.7%因为该模型本身已很少过度聚合判断器剩余的作用只是拆分本应合并的组。这解释了 03-16 报告中 SPECIFICITY_SPLIT 占比高、而后续迭代不断调整该阶段的原因。检索多样性供理解匹配质量辅助信息虽然 03-16 报告未列出检索多样性表但match-quality实验本身就包含query_diversity查询间平均余弦距离与candidate_diversity1 − Jaccard两个数值指标用于诊断检索召回是否足够多样化。后续报告如 03-17 的 query_diversity 均值 0.465、candidate_diversity 均值 0.445展示了它们的典型量级查询中等程度多样化不同查询召回的候选集部分重叠。五、Pre-emit 可操作性检查按来源的过滤质量报告第三张表评估信号进入分组之前的可操作性过滤器{source}-actionability-check实验SourceTotalCorrectFailure rateFPFNZendesk886427.3%120GitHub583834.5%100Linear362433.3%60解读要点全部失败都是假阳性FP即本应被过滤掉的不可操作信号被放行了三个来源的 FN 均为 0——没有把真正可操作的信号误杀这是产品体验上最要紧的底线。三个来源的失败率集中在 27%35% 区间说明 pre-emit 的可操作性判断对来源不敏感瓶颈在 LLM 判断本身而非数据格式。Zendesk工单描述相对表现最好GitHub Issue34.5%最差。从实现看这一步对应 eval_grouping_e2e.py 中导入的check_actionability来自 products/signals/backend/emission/pipeline.py属于 emission 阶段的预处理未通过即被丢弃不会进入后续匹配。该实验按来源拆分命名zendesk-actionability-check、github-actionability-check、linear-actionability-check指标为二值correct_classification与 ground-truth 的可操作性标签对比。六、报告级裁判Safety 与 Actionability所有信号分组完成后管线对每份报告运行两个裁判对应report-safety-check与report-actionability-check实验JudgeTotalCorrectAccuracyFPFNSafety544990.7%50Actionability543564.8%190Safety90.7%54 份报告中有 49 份被正确分类5 个假阳性——即 5 份安全报告被误判为不安全。结合聚合指标中的恶意泄漏率 5/24本次运行的安全护栏有漏也有误报后续 03-17 通过调整达到 Safety 100.0%。Actionability64.8%54 份报告中仅 35 份被正确判定可操作性19 个假阳性。这是本次运行准确率最低的环节也是报告该不该推送/展示给用户的核心决策点是明显的迭代目标。两个裁判的 FN 均为 0说明没有不安全/不可操作的报告被漏判放行——错误都集中在过于保守方向与 pre-emit 阶段的 FP-only 特征一致。从实现看报告级裁判分别对应 products/signals/backend/temporal/report_safety_judge.pyjudge_report_safety提示注入检测与 actionability 判断二者在 eval_grouping_e2e.py 中被逐一调用。七、逐报告分组质量Per-report grouping quality最后一张表从单份报告粒度给出分组质量的分布MetricnMeanMinMaxPurity540.9950.7501.000Is pure5453/54 (98.1%)--Group recall540.6790.3331.000Purity 均值 0.995、最小值 0.750绝大多数报告内容非常纯粹但存在纯度低至 0.75 的报告混入了 25% 的其他组信号对应上文 OVERGROUP 错误。Is pure 53/5498.1%仅 1 份报告混入了不同组的信号。Group recall 均值 0.679、最小值 0.333与聚合指标中的 mean group recall 一致是本次运行的主要短板最差情况下一个组的信号只有 1/3 被召回说明存在明显的欠聚合UNDERGROUP SPECIFICITY_SPLIT。综合看本次评估的结论画像可以概括为报告内容足够纯同质性/纯度都很高但全不够完整性/组召回偏低根因主要是特异性判断器过度拆分其次是 matcher 自身的欠聚合。八、如何复现与继续观测运行评估与查询指标复现本次评估评估入口是 eval_grouping_e2e.py通过 pytest 运行# 完整运行——评估结果上报到 PostHog pytest products/signals/eval/eval_grouping_e2e.py -xvs # 快速试跑——只处理前 10 个信号不上报 pytest products/signals/eval/eval_grouping_e2e.py -xvs --limit 10 --no-capture # 在线评估模式结果标记为 online 而非 offline pytest products/signals/eval/eval_grouping_e2e.py -xvs --online需要的环境变量配置在仓库根目录.env自动加载见 AGENTS.mdVariablePurposeOPENAI_API_KEY嵌入text-embedding-3-smallLLM_GATEWAY_URL内部 LLM 网关地址匹配/特异性/摘要/可操作性/安全等全部 LLM 调用LLM_GATEWAY_PERSONAL_API_KEYLLM 网关的 Bearer tokenPostHog 个人 API keySIGNALS_EVAL_TEAM_IDLLM 成本归属头使用的 team id默认 1POSTHOG_PROJECT_API_KEY上报评估结果用可用--no-capture跳过POSTHOG_HOSTPostHog 实例地址默认http://localhost:8010支持的命令行选项FlagEffect--limit N只处理信号流中的前 N 个信号--no-capture不向 PostHog 发送$ai_evaluation事件--online将上报结果标记为 online 评估默认 offline运行过程中 stderr 会输出两条 tqdm 进度条Matching 与 Judging随后是聚合结果汇总表与 03-16 报告的数据结构一一对应。用 HogQL 复现报告中的指标评估结果以$ai_evaluation事件$ai_eval_source signals-grouping、$ai_evaluation_type offline落库AGENTS.md 提供了多段可直接在 PostHog SQL 编辑器中执行的查询。例如聚合指标SELECT properties.$ai_metric_name AS metric, properties.$ai_score AS score, properties.$ai_metric_description AS description, properties.$ai_reasoning AS reasoning, properties.$ai_input AS input, properties.$ai_output AS output, properties.$ai_expected AS expected FROM events WHERE event $ai_evaluation AND properties.$ai_eval_source signals-grouping AND properties.$ai_evaluation_type offline AND properties.$ai_experiment_name signals-grouping/grouping-aggregate ORDER BY metric匹配失败模式分布SELECT multiIf( properties.$ai_score 1.0, CORRECT, properties.$ai_reasoning LIKE %UNDERGROUP%, UNDERGROUP, properties.$ai_reasoning LIKE %OVERGROUP%, OVERGROUP, UNKNOWN ) AS failure_mode, count() AS cnt, round(count() * 100.0 / (SELECT count() FROM events WHERE event $ai_evaluation AND properties.$ai_eval_source signals-grouping AND properties.$ai_evaluation_type offline AND properties.$ai_experiment_name signals-grouping/match-quality), 1) AS pct FROM events WHERE event $ai_evaluation AND properties.$ai_eval_source signals-grouping AND properties.$ai_evaluation_type offline AND properties.$ai_experiment_name signals-grouping/match-quality AND properties.$ai_metric_name correct_match GROUP BY failure_mode ORDER BY cnt DESC按来源统计 pre-emit 可操作性对应报告第五张表SELECT replaceOne(properties.$ai_experiment_name, signals-grouping/, ) AS check_name, count() AS total, countIf(properties.$ai_score 1.0) AS correct, countIf(properties.$ai_score ! 1.0) AS failures, round(countIf(properties.$ai_score ! 1.0) * 100.0 / count(), 1) AS failure_pct, countIf(properties.$ai_score ! 1.0 AND properties.$ai_output ACTIONABLE) AS false_positives, countIf(properties.$ai_score ! 1.0 AND properties.$ai_output NOT_ACTIONABLE) AS false_negatives FROM events WHERE event $ai_evaluation AND properties.$ai_eval_source signals-grouping AND properties.$ai_evaluation_type offline AND properties.$ai_experiment_name IN ( signals-grouping/zendesk-actionability-check, signals-grouping/github-actionability-check, signals-grouping/linear-actionability-check ) AND properties.$ai_metric_name correct_classification GROUP BY check_name ORDER BY check_name此外还有报告级裁判、逐报告分组质量、特异性判断器影响对比correct_match_pre_specificity与correct_match以及详细失败样本等查询完整清单见 AGENTS.md 的 HogQL queries 一节——这正是把 03-16 这种快照报告转化为可持续监控手段的桥梁。九、基线定位本次运行在迭代脉络中的位置将 03-16 报告与仓库中后续报告对比可以更准确地定位这次运行的水平以下数字均来自对应报告文件本身维度2026-03-162026-03-17说明ARI0.7060.7540.048Completeness0.9070.9320.025Mean group recall0.6790.7750.096Malicious leaked5/240/24泄漏清零Match accuracy76.0%82.1%6.1ppSafety accuracy90.7%100%9.3ppActionability acc64.8%81.1%16.3pp其中 03-17 报告特别注明Safety judge 从 90.7% 提升到 100.0%对照 03-16且其match-quality表中不再出现 SPECIFICITY_SPLIT 单独列合并进了 UNDERGROUP说明特异性判断器行为在两次运行之间发生了调整。这正好印证了 03-16 报告最大的诊断价值它通过 SPECIFICITY_SPLIT 的 13/19 占比把特异性校验过度拆分这一根因显式暴露出来为后续迭代提供了明确靶点。十、总结2026-03-16 报告是 PostHog Signals 分组管线一次信息密度很高的离线评估快照其价值体现在三个层面量化了管线的当前水位ARI 0.7059、同质性 0.9923、完整性 0.9065、恶意泄漏率 5/24以及仅 64.8% 的 Actionability 裁判准确率构成了清晰的改进基线。定位了主要失败模式18.3% 的欠聚合中 68.4% 来自特异性判断器拆分SPECIFICITY_SPLIT而非 matcher 本身全部可操作性错误均为假阳性、无假阴性。沉淀了可复现、可持续的观测方式通过 eval_grouping_e2e.py 可复跑通过 AGENTS.md 中的 HogQL 查询可持续监控每一轮迭代。对于任何从事LLM 驱动的在线聚类/工单归并类系统的工程师这份报告连同其评估框架真实管线 mock 基础设施 固定种子信号流 分级指标体系都是一个值得参考的离线评估范式。【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
PostHog Signals 分组管线离线评估解析：从 2026-03-16 报告读懂 ARI、匹配失败模式与裁判指标
PostHog Signals 分组管线离线评估解析从 2026-03-16 报告读懂 ARI、匹配失败模式与裁判指标【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog导读本文以 products/signals/eval/reports/2026-03-16.md 这份评估报告为骨架深入解读 PostHog Signals 产品中**信号分组管线signal grouping pipeline**的一次离线offline端到端评估结果。报告中记录了 91 个合成信号、41 个 ground-truth 分组、54 份产出报告的聚类质量ARI、同质性、完整性、纯度、组召回、匹配失败模式分布、按来源划分的 pre-emit 可操作性检查以及 Safety/Actionability 两个报告级裁判的准确率。读完本文你将理解报告中每个指标的业务含义与计算口径、失败模式尤其是 SPECIFICITY_SPLIT背后对应的管线阶段以及如何在本地复现这次评估并用 HogQL 查询同样的指标。一、这份报告是什么Signals 分组管线的离线评估PostHog Signals 是一个将 Zendesk、GitHub、Linear 等外部工单/Issue 信号聚合为报告report的功能多个信号如果描述同一个问题应被聚类到同一份报告中从而让用户一次看到问题的全貌。为了保证聚类质量仓库在 products/signals/eval/ 下维护了一套端到端评估end-to-end eval其目标定义在 AGENTS.md 中将合成信号送入真实管线LLM 查询生成 → 嵌入检索 → LLM 匹配 → 特异性校验 → 摘要 → 安全裁判 → 可操作性裁判与人工标注的 ground-truth 分组对比衡量管线把信号聚成报告的效果。关键设计是管线真实、基础设施打桩用内存版EmbeddingStore替代 ClickHouse Kafka、用ReportStore替代 Postgres实现见 mock.py从而在纯 Python 测试环境中跑完整链路。2026-03-16.md正是某一次离线评估产出的结果快照包含聚合指标、匹配质量、裁判准确率等若干层面供开发者在迭代分组逻辑时对比基线。从文件命名看reports/目录下还保存着 2026-03-17.md、2026-08-18.md、2026-09-03.md 等后续报告说明这套评估是持续迭代、逐次对比的机制本文的 03-16 报告是其中的基线记录之一。二、本次运行的测试集与执行规模报告开头给出了本次评估的规模信息91 个信号signals由合成数据生成来自 Zendesk、GitHub、Linear、error tracking 等来源信号内容格式在 data_spec.py 中定义如 Zendesk 使用subject/description字段、GitHub 使用title/body、error tracking 按 cymbal 格式渲染描述。41 个 ground-truth 分组groups人工标注的正确答案——这些信号真实归属于哪 41 个主题分组。54 份报告reports produced管线最终产出 54 份报告数量多于 ground-truth 的 41 组说明存在过度拆分现象下文失败模式会量化这一点。信号到达顺序并非按组排列而是由 common.py 中的get_signals_stream()用固定随机种子RNG_SEED 1337将各组信号交错打乱模拟真实世界的乱序到达同时保持组内顺序。这意味着管线必须在信号不按主题排队的情况下完成在线聚类难度更接近生产环境。每个信号经历的管线阶段从 AGENTS.md 与 eval_grouping_e2e.py 的编排逻辑看本次评估中每个信号依次经过以下阶段Pre-emit摘要长描述、做可操作性检查actionability check经由内部 LLM 网关调用 Claude Haiku。不满足可操作性的信号在此被丢弃。MatchLLM 生成检索查询 → OpenAI 嵌入text-embedding-3-small→ 对已存信号做余弦相似度检索 → LLM 判断并入已有报告还是新建报告 → 特异性校验specificity judge确认匹配是否过于宽泛。Persist存储信号与嵌入更新报告元数据。Judge全部信号处理完后对每份报告做摘要、安全裁判提示注入检测与可操作性裁判。所有 LLM 调用统一走内部 LLM 网关LLM_GATEWAY_URL信号并发执行但 match persist 阶段由asyncio.Lock串行化以保证嵌入库与报告库在做并入/新建决策时看到一致视图并发上限MAX_CONCURRENT_RUNS 70定义在 common.py。三、聚合指标Aggregate metrics聚类的四个体检项报告的第一张核心表是聚合指标MetricScoreARI0.7059Homogeneity0.9923Completeness0.9065Mean purity0.9954Mean group recall0.6790Malicious leaked rate0.2083 (5/24)这些指标由 sklearn 的adjusted_rand_score、homogeneity_completeness_v_measure等函数计算见 eval_grouping_e2e.py 的导入并结合报告里的定义逐项解读ARI调整兰德指数Adjusted Rand Index衡量管线聚类结果与ground-truth 分组的相似度经随机机会校正取值 -111 为完全一致。本次 0.7059说明聚类与人工标注的一致性处于中上水平。Homogeneity同质性 0.9923每份报告里只包含来自同一个真实组的信号。越接近 1.0说明越没有过度聚合overgrouping。本次表现优秀。Completeness完整性 0.9065某个真实组的所有信号是否都落在同一份报告里。越接近 1.0说明越没有欠聚合undergrouping。本次略低于同质性提示存在一定程度的组被拆分。Mean purity平均纯度 0.9954每份报告中主导组信号所占的平均比例即报告内容有多纯粹。Mean group recall平均组召回 0.6790一个真实组的信号被其最佳匹配报告捕获的比例的平均值。0.679 意味着平均约 32% 的信号没有与同组信号聚在一起——这是本次运行最薄弱的环节。Malicious leaked rate恶意信号泄漏率 0.2083 (5/24)24 个不安全的恶意/提示注入信号中有 5 个未被安全裁判拦截而通过了管线泄漏率 20.83%。这是安全维度的关键红线指标后续 03-17 报告将其降到 0/24见下文的演进对比。从源码角度这些指标在 AGENTS.md 中有同样的定义清单并被作为$ai_evaluation事件中的grouping-aggregate实验捕获用于在 PostHog 内做长期趋势监控。四、匹配质量失败模式的分布与 SPECIFICITY_SPLIT 的来源报告的第二张核心表关注每个信号的匹配决策质量本次共覆盖 104 个匹配决策Failure modeCount% of totalCORRECT7976.0%SPECIFICITY_SPLIT1312.5%UNDERGROUP65.8%OVERGROUP65.8%失败模式的定义在 common.py 中定义了三个基础匹配结果枚举NONE匹配正确对应报告中的 CORRECTUNDERGROUP应该并入已有报告却新建了一份欠聚合OVERGROUP加入了属于其他 ground-truth 组的报告过度聚合。而报告中的SPECIFICITY_SPLIT是特异性校验阶段specificity judge引入的第四种状态matcher 原本给出的匹配被特异性判断器判定为过于宽泛而否决/拆分导致本应属于同一报告的信号被拆开。报告用一行专门给出了它的体量Total undergrouping (UNDERGROUP SPECIFICITY_SPLIT): 19/104 (18.3%). Specificity split share of undergrouping: 13/19 (68.4%).也就是说本次 18.3% 的欠聚合错误中68.4%13/19是由特异性判断器过度拆分造成的而不是 matcher 本身没有识别出关联。这直接点出了本次运行的一个优化方向——特异性判断器的阈值/行为需要校准。与后续报告的印证这种特异性判断器引入拆分的现象并非孤例2026-03-17.md 明确记录特异性判断器把 14 个 overgroup 转为正确匹配但同时引入了 5 个新的 undergroup净 92026-08-18.md 则在模型对比中发现在 sonnet-5 上特异性判断器是净损失84.9% → 83.7%因为该模型本身已很少过度聚合判断器剩余的作用只是拆分本应合并的组。这解释了 03-16 报告中 SPECIFICITY_SPLIT 占比高、而后续迭代不断调整该阶段的原因。检索多样性供理解匹配质量辅助信息虽然 03-16 报告未列出检索多样性表但match-quality实验本身就包含query_diversity查询间平均余弦距离与candidate_diversity1 − Jaccard两个数值指标用于诊断检索召回是否足够多样化。后续报告如 03-17 的 query_diversity 均值 0.465、candidate_diversity 均值 0.445展示了它们的典型量级查询中等程度多样化不同查询召回的候选集部分重叠。五、Pre-emit 可操作性检查按来源的过滤质量报告第三张表评估信号进入分组之前的可操作性过滤器{source}-actionability-check实验SourceTotalCorrectFailure rateFPFNZendesk886427.3%120GitHub583834.5%100Linear362433.3%60解读要点全部失败都是假阳性FP即本应被过滤掉的不可操作信号被放行了三个来源的 FN 均为 0——没有把真正可操作的信号误杀这是产品体验上最要紧的底线。三个来源的失败率集中在 27%35% 区间说明 pre-emit 的可操作性判断对来源不敏感瓶颈在 LLM 判断本身而非数据格式。Zendesk工单描述相对表现最好GitHub Issue34.5%最差。从实现看这一步对应 eval_grouping_e2e.py 中导入的check_actionability来自 products/signals/backend/emission/pipeline.py属于 emission 阶段的预处理未通过即被丢弃不会进入后续匹配。该实验按来源拆分命名zendesk-actionability-check、github-actionability-check、linear-actionability-check指标为二值correct_classification与 ground-truth 的可操作性标签对比。六、报告级裁判Safety 与 Actionability所有信号分组完成后管线对每份报告运行两个裁判对应report-safety-check与report-actionability-check实验JudgeTotalCorrectAccuracyFPFNSafety544990.7%50Actionability543564.8%190Safety90.7%54 份报告中有 49 份被正确分类5 个假阳性——即 5 份安全报告被误判为不安全。结合聚合指标中的恶意泄漏率 5/24本次运行的安全护栏有漏也有误报后续 03-17 通过调整达到 Safety 100.0%。Actionability64.8%54 份报告中仅 35 份被正确判定可操作性19 个假阳性。这是本次运行准确率最低的环节也是报告该不该推送/展示给用户的核心决策点是明显的迭代目标。两个裁判的 FN 均为 0说明没有不安全/不可操作的报告被漏判放行——错误都集中在过于保守方向与 pre-emit 阶段的 FP-only 特征一致。从实现看报告级裁判分别对应 products/signals/backend/temporal/report_safety_judge.pyjudge_report_safety提示注入检测与 actionability 判断二者在 eval_grouping_e2e.py 中被逐一调用。七、逐报告分组质量Per-report grouping quality最后一张表从单份报告粒度给出分组质量的分布MetricnMeanMinMaxPurity540.9950.7501.000Is pure5453/54 (98.1%)--Group recall540.6790.3331.000Purity 均值 0.995、最小值 0.750绝大多数报告内容非常纯粹但存在纯度低至 0.75 的报告混入了 25% 的其他组信号对应上文 OVERGROUP 错误。Is pure 53/5498.1%仅 1 份报告混入了不同组的信号。Group recall 均值 0.679、最小值 0.333与聚合指标中的 mean group recall 一致是本次运行的主要短板最差情况下一个组的信号只有 1/3 被召回说明存在明显的欠聚合UNDERGROUP SPECIFICITY_SPLIT。综合看本次评估的结论画像可以概括为报告内容足够纯同质性/纯度都很高但全不够完整性/组召回偏低根因主要是特异性判断器过度拆分其次是 matcher 自身的欠聚合。八、如何复现与继续观测运行评估与查询指标复现本次评估评估入口是 eval_grouping_e2e.py通过 pytest 运行# 完整运行——评估结果上报到 PostHog pytest products/signals/eval/eval_grouping_e2e.py -xvs # 快速试跑——只处理前 10 个信号不上报 pytest products/signals/eval/eval_grouping_e2e.py -xvs --limit 10 --no-capture # 在线评估模式结果标记为 online 而非 offline pytest products/signals/eval/eval_grouping_e2e.py -xvs --online需要的环境变量配置在仓库根目录.env自动加载见 AGENTS.mdVariablePurposeOPENAI_API_KEY嵌入text-embedding-3-smallLLM_GATEWAY_URL内部 LLM 网关地址匹配/特异性/摘要/可操作性/安全等全部 LLM 调用LLM_GATEWAY_PERSONAL_API_KEYLLM 网关的 Bearer tokenPostHog 个人 API keySIGNALS_EVAL_TEAM_IDLLM 成本归属头使用的 team id默认 1POSTHOG_PROJECT_API_KEY上报评估结果用可用--no-capture跳过POSTHOG_HOSTPostHog 实例地址默认http://localhost:8010支持的命令行选项FlagEffect--limit N只处理信号流中的前 N 个信号--no-capture不向 PostHog 发送$ai_evaluation事件--online将上报结果标记为 online 评估默认 offline运行过程中 stderr 会输出两条 tqdm 进度条Matching 与 Judging随后是聚合结果汇总表与 03-16 报告的数据结构一一对应。用 HogQL 复现报告中的指标评估结果以$ai_evaluation事件$ai_eval_source signals-grouping、$ai_evaluation_type offline落库AGENTS.md 提供了多段可直接在 PostHog SQL 编辑器中执行的查询。例如聚合指标SELECT properties.$ai_metric_name AS metric, properties.$ai_score AS score, properties.$ai_metric_description AS description, properties.$ai_reasoning AS reasoning, properties.$ai_input AS input, properties.$ai_output AS output, properties.$ai_expected AS expected FROM events WHERE event $ai_evaluation AND properties.$ai_eval_source signals-grouping AND properties.$ai_evaluation_type offline AND properties.$ai_experiment_name signals-grouping/grouping-aggregate ORDER BY metric匹配失败模式分布SELECT multiIf( properties.$ai_score 1.0, CORRECT, properties.$ai_reasoning LIKE %UNDERGROUP%, UNDERGROUP, properties.$ai_reasoning LIKE %OVERGROUP%, OVERGROUP, UNKNOWN ) AS failure_mode, count() AS cnt, round(count() * 100.0 / (SELECT count() FROM events WHERE event $ai_evaluation AND properties.$ai_eval_source signals-grouping AND properties.$ai_evaluation_type offline AND properties.$ai_experiment_name signals-grouping/match-quality), 1) AS pct FROM events WHERE event $ai_evaluation AND properties.$ai_eval_source signals-grouping AND properties.$ai_evaluation_type offline AND properties.$ai_experiment_name signals-grouping/match-quality AND properties.$ai_metric_name correct_match GROUP BY failure_mode ORDER BY cnt DESC按来源统计 pre-emit 可操作性对应报告第五张表SELECT replaceOne(properties.$ai_experiment_name, signals-grouping/, ) AS check_name, count() AS total, countIf(properties.$ai_score 1.0) AS correct, countIf(properties.$ai_score ! 1.0) AS failures, round(countIf(properties.$ai_score ! 1.0) * 100.0 / count(), 1) AS failure_pct, countIf(properties.$ai_score ! 1.0 AND properties.$ai_output ACTIONABLE) AS false_positives, countIf(properties.$ai_score ! 1.0 AND properties.$ai_output NOT_ACTIONABLE) AS false_negatives FROM events WHERE event $ai_evaluation AND properties.$ai_eval_source signals-grouping AND properties.$ai_evaluation_type offline AND properties.$ai_experiment_name IN ( signals-grouping/zendesk-actionability-check, signals-grouping/github-actionability-check, signals-grouping/linear-actionability-check ) AND properties.$ai_metric_name correct_classification GROUP BY check_name ORDER BY check_name此外还有报告级裁判、逐报告分组质量、特异性判断器影响对比correct_match_pre_specificity与correct_match以及详细失败样本等查询完整清单见 AGENTS.md 的 HogQL queries 一节——这正是把 03-16 这种快照报告转化为可持续监控手段的桥梁。九、基线定位本次运行在迭代脉络中的位置将 03-16 报告与仓库中后续报告对比可以更准确地定位这次运行的水平以下数字均来自对应报告文件本身维度2026-03-162026-03-17说明ARI0.7060.7540.048Completeness0.9070.9320.025Mean group recall0.6790.7750.096Malicious leaked5/240/24泄漏清零Match accuracy76.0%82.1%6.1ppSafety accuracy90.7%100%9.3ppActionability acc64.8%81.1%16.3pp其中 03-17 报告特别注明Safety judge 从 90.7% 提升到 100.0%对照 03-16且其match-quality表中不再出现 SPECIFICITY_SPLIT 单独列合并进了 UNDERGROUP说明特异性判断器行为在两次运行之间发生了调整。这正好印证了 03-16 报告最大的诊断价值它通过 SPECIFICITY_SPLIT 的 13/19 占比把特异性校验过度拆分这一根因显式暴露出来为后续迭代提供了明确靶点。十、总结2026-03-16 报告是 PostHog Signals 分组管线一次信息密度很高的离线评估快照其价值体现在三个层面量化了管线的当前水位ARI 0.7059、同质性 0.9923、完整性 0.9065、恶意泄漏率 5/24以及仅 64.8% 的 Actionability 裁判准确率构成了清晰的改进基线。定位了主要失败模式18.3% 的欠聚合中 68.4% 来自特异性判断器拆分SPECIFICITY_SPLIT而非 matcher 本身全部可操作性错误均为假阳性、无假阴性。沉淀了可复现、可持续的观测方式通过 eval_grouping_e2e.py 可复跑通过 AGENTS.md 中的 HogQL 查询可持续监控每一轮迭代。对于任何从事LLM 驱动的在线聚类/工单归并类系统的工程师这份报告连同其评估框架真实管线 mock 基础设施 固定种子信号流 分级指标体系都是一个值得参考的离线评估范式。【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
报错根源：CUDA三重版本冲突解析)
