先说结论
很多人第一次接触 Odoo CRM 的 automated_probability，会以为它就是“按阶段给一个默认概率”。
这只对了一小半。
真正的实现里，Odoo 用的是一套更完整的 Predictive Lead Scoring（PLS）机制：
- 从历史赢单 / 丢单结果里累计频次
- 按字段值统计 won / lost 分布
- 再用 Naive Bayes 方式估算当前商机赢单概率
- 并按 team 样本优先、全局样本兜底的逻辑去取数
所以自动概率有时显得很聪明， 有时又会让人觉得“这个数字怎么怪怪的”， 根本原因通常不在 UI， 而在样本和统计边界。
一、自动概率不是手写规则，而是统计推断
_pls_get_naive_bayes_probabilities() 的注释写得非常坦白：
- 它用的是 Naive Bayes 思路
- 通过“某些条件下赢单 / 丢单出现的频率”来估算当前 lead 的赢单概率
这说明官方并不是写了一堆硬编码规则：
- 阶段 A = 20%
- 阶段 B = 50%
- 阶段 C = 80%
而是在做更接近统计学习的事情：
- 阶段是什么
- 某些字段当前取值是什么
- 历史上这些取值组合在赢 / 输样本里各自有多常见
最后再拼成一个概率。
这就是为什么 automated probability 本质上不是“写死的经验值”，而是“被历史样本不断修正的建议值”。
二、样本不是直接从当前 lead 算出来，而是先进入频次表
Odoo 不会每次现算全库明细。
它会把统计结果沉淀到 crm.lead.scoring.frequency 这类频次表里。
_pls_increment_frequencies()、_rebuild_pls_frequency_table()、_cron_update_automated_probabilities() 这几段连起来看，
你会发现它的工作方式是：
- lead 进入 won / lost 等状态变化时，增量更新频次
- 或者通过 cron 一次性重建频次表
- 再用频次表去算所有活跃机会的自动概率
这比“每次打开记录临时扫全库”稳得多。
也意味着一个重要现实：
自动概率的质量，取决于频次表里到底积累了多少有效历史，而不是取决于当前页面算得多花哨。
三、团队样本优先，是自动概率最容易被忽略的偏差来源
在 _pls_get_naive_bayes_probabilities() 里，Odoo 会优先看 team 级频次；
如果当前 lead 的 team_id 在频次结果里没有足够对应项，才会退回全局样本。
这个设计非常合理，但也非常容易让人误解。
合理在于：
- 不同 team 的销售节奏、客群和成交模式确实不同
- 同一个阶段，在不同 team 的赢单含义可能不一样
但风险也正来自这里：
- 某个 team 样本很少
- 或者样本结构严重偏
- 自动概率就会比你预期更飘
所以很多人觉得“同样阶段，A 团队自动概率挺准，B 团队就很怪”， 并不是错觉。
这可能正是 team 级样本质量不同造成的。
四、0.1 平滑不是数学细节，而是在避免小样本把概率打爆
官方在注释里直接解释了 0.1 的存在：
- 某些事件如果从未出现过
- 朴素贝叶斯会碰到 zero frequency 问题
- 为了避免乘法链路直接归零，系统给频次加了
0.1
这件事很重要。
因为它说明 Odoo 完全知道：
- 小样本时，概率并不“真实”
- 它只是为了让模型可计算、别因为一个未出现值就直接崩掉
换句话说：
自动概率在样本不足时，首先追求的是“能算且别太离谱”，而不是“已经高度可信”。
所以如果你在新 team、新业务线、或分类字段刚上线不久时看到概率很奇怪， 先别急着怀疑 UI， 很可能只是统计底座还没养成熟。
五、并不是所有字段都会无限增强预测力
在这套算法里，每个字段值都会贡献一段 won / lost score。
但源码也加了保护。
最典型的是 tag_id：
- 如果某个 tag 相关样本太少
- 它的频次会被忽略
这说明官方对一个问题非常清醒：
- 局部小样本字段很容易制造“看起来特别准”的幻觉
- 但实际上只是偶然性太强
所以 Odoo 宁可在样本不足时弱化某些信号， 也不急着让它们主导自动概率。
这和很多自定义 CRM 项目里“加个字段就想让模型更聪明”的冲动，恰好相反。
六、stage 之所以重要，不是因为它被写死，而是因为它天然承载状态信息
在自动概率计算里，stage_id 的角色会特别重。
不是因为 Odoo 偷偷把“阶段 = 概率”硬编码死， 而是因为历史样本里，阶段本来就最能表达机会推进程度。
源码甚至单独对 stage 的 score 解释做了特殊处理。
这意味着：
- 自动概率不是被 stage 单独决定
- 但 stage 往往是最强解释变量之一
所以如果你的 pipeline 设计混乱：
- 不同 team 的 stage 语义不一致
- 销售随手拖阶段
- won stage / standard stage 边界不清
自动概率自然会变差。
不是算法忽然失灵， 而是输入语义已经脏了。
七、为什么有些记录自动概率更新了，但界面显示概率没跟着变
这也是一个经典误会。
_compute_probabilities() 会一直更新 automated_probability，
但只有在当前记录仍处于“自动模式”时，probability 才会同步跟着走。
所谓自动模式，简单说就是：
- 你实际采用的
probability - 仍然等于系统建议的
automated_probability
一旦销售手工改过，让二者脱离一致， Odoo 就会理解为：
- 系统继续给建议
- 但业务上已经人工接管
所以你会看到一种很正常的现象：
- 建议概率在变化
- 但当前采用概率没再自动跳
这不是同步失败， 而是官方特意保留的“建议值 / 采用值”双轨机制。
八、什么时候自动概率最不该被迷信
下面几种场景，应该天然降低对 automated probability 的信任：
1. 新团队刚建，样本极少
team 频次不足时，结果很容易飘。
2. pipeline 阶段语义不稳定
阶段被乱拖，stage 就失去统计意义。
3. 丢单 / 赢单动作执行不规范
频次表建立在结果语义之上，结果脏了，模型也会脏。
4. 新字段、新标签刚上线
相关样本可能还没累够。
5. 销售大量手工覆写概率
那你看的可能已经不是模型输出，而是人工判断口径。
最后一句
Odoo CRM 的 Predictive Lead Scoring 最值得尊重的地方，不是它“会自动给概率”， 而是它非常诚实地把统计边界都暴露出来了：
样本不足会漂，team 差异会偏，zero frequency 要平滑，人工接管后建议值和采用值会分开。
只要把这几层想明白，你就不会再把 automated probability 当成神谕， 而会把它当成一个需要好样本、好阶段语义和好执行纪律才能逐渐变准的建议系统。
DISCUSSION
评论区