套餐实验室Bundle Lab
Validation

怎么知道它挖出来的不是噪声

合成数据里预先埋了 5 个组合(答案写在 data/GENERATION.md)。工具挖出来的组合能不能对上答案, 是判断算法有没有用的唯一办法。这一页的数字全部来自仓库 results/ 目录里真跑出来的产物。

一、公式对不对:10 条手工订单对照笔算

断言数
21
覆盖 supp / conf / lift / 口径
通过
21/21
全部通过
为什么是手算
三个指标很容易写错
写错了结果依然「看起来合理」,只能靠笔算对数
fixture 里故意留的
lift = 0.8 的负相关组合
固定住「共现 ≠ 该推套餐」这个判断
写这个测试时手算 supp(C) 数漏了一单(把 5 次数成 4 次),被断言抓出来。 这正好说明为什么要手算 —— 代码没错,是我的直觉错了,而直觉错了在别处看不出来。

二、挖得准不准:植入组合召回

召回率
5/5
埋进去的组合找回来几个
候选组合总数
58
lift ≥ 1.2、支持度 ≥ 1%
前 10 名里的误报
2
非植入组合挤进前 10 的个数
数据集
4,000
订单,12,054 行明细
植入组合生成概率排名lift支持度置信度命中订单主时段
牛肉面 + 卤蛋
P1 · 经典搭配,全时段
55%#24.187.80%59.1%312lunch 50%
麻辣香锅(单人) + 酸梅汤
P2 · 辣配解辣,单人为主
50%#73.667.45%53.5%298lunch 50%
烤鱼(双人) + 啤酒
P3 · 多人 + 晚餐倾向
60%#64.164.55%50.4%182dinner 53%
酸菜鱼(双人) + 大瓶可乐(1.25L)
P4 · 多人分享装饮料
50%#34.185.80%58.9%232lunch 47%
鸡腿饭 + 薯条 + 可乐
P5 · 三元组,快餐式套餐
40%#18.715.08%91.4%203lunch 49%
前 10 里的两个误报不是 bug,是 lift 的固有弱点。 它们是两个植入组合的拼接 (卤蛋+大瓶可乐+牛肉面、啤酒+大瓶可乐+烤鱼),命中单量只有 40 多单, 但 lift 高达 4.7。support 低的组合容易刷出虚高的 lift —— 所以页面上一律同时显示命中订单数,不能只看 lift 就下结论。

三、多少订单量才够用

两个指标要分开看。进候选只说明被挖出来了,哪怕排在第 69 名;进前 10 才是可用线 —— 运营不会翻到第 69 名。

订单数候选数进候选进前 10最差排名沉在 10 名外
2002005/51/5#69P1(#15) P2(#13) P3(#69) P4(#14)
5001175/54/5#17P3(#17)
1000795/53/5#12P2(#12) P3(#11)
2000655/55/5#8
3000605/55/5#7
4000585/55/5#7
结论:200 单基本不可用(只有 1 个进前 10),500-1000 单不稳定(4/5 和 3/5,小样本排名抖动),2000 单起 5 个植入组合全部进前 10,这是可用线。 如果只有两三百单就上这个工具,产出的排序基本是噪声。

阈值调松调紧会怎样(固定 4000 单)

阈值候选数进候选进前 10漏掉
宽松 lift≥1.0 supp≥0.5%2005/53/5
默认 lift≥1.2 supp≥1%585/55/5
偏严 lift≥1.5 supp≥2%115/55/5
严格 lift≥2.0 supp≥3%85/55/5
极严 lift≥3.0 supp≥5%74/54/5P3
阈值放太松反而更差:候选数涨到 200 个,噪声把植入组合挤出前 10。 默认的 lift ≥ 1.2 / 支持度 ≥ 1% 到偏严区间表现一致且稳定 —— 这是选它当默认值的依据,不是拍脑袋定的。

这份数据本身的画像

合成数据里多人订单占 39.1%,但人均商品数只有单人订单的 52% —— 这个错位是刻意植入的,用来验证工具能不能自己发现「用户想多买却凑不成套」。 答案是能:订单画像页顶部那句话就是它自己判断出来的。
全部数据是合成的。生成规则、参数、随机种子写在 data/GENERATION.md。 这里没有任何真实业务数据 —— 项目动机来自一段实习经历,但测试数据与那家公司无关。