企业官网建设流程全解析

做机器学习项目的人，迟早会在一个场景上被卡住：手里只有一批确定的正例，剩下的全是没打标签的数据，负例一条都没有。这就是正例-无标签学习（Positive-Unlabelled Learning，简称PU学习）。而《Automated machine learning for positive-unlabelled learning》这篇论文，恰恰是把自动化机器学习（AutoML）那套东西搬进来，让模型在正例稀少、负例缺失的情况下，还能自动搜出合适的学习路线和超参数组合。这篇精读笔记，我会把论文的问题背景、方法框架、实验设计，以及我自己在类似任务上的实操体会都过一遍，适合正在做推荐、风控、医疗筛查、异常检测这类场景的算法同学。先把结论放这里：这论文不是教你怎么多调几个参数，而是把PU学习从“手工作坊”升级成“自动流水线”。

1. 这篇论文到底在解决什么问题

1.1 先说清楚PU学习是个什么设定

很多同学第一次接触PU学习时都会有个疑问：没有负例，那还训练什么二分类？这里的关键在于，无标签样本里其实混杂着正例和负例，只是我们不知道哪些是正例。比如电商复购预测，你只能拿到“已经复购的人”作为正例，剩下没复购的人里，有一部分是以后还会买的；保险反欺诈场景中，能确认是欺诈的只有一小撮，没被标记的保单不代表就没有问题。所以PU学习要回答的问题是：只给定一个相对干净的正例集合P，和一个大概率混杂的未标注集合U，怎么训练出一个能区分正负的模型。

从形式上看，它介乎有监督学习和半监督学习之间。传统有监督二分类要求P和N都有标签；半监督学习要求少量正负标签加上大量无标签；PU学习更狠，负例标签一个都不给。数学上通常建模为：正例集合P是从真实正例分布中通过某个机制采样出来的，而无标签集合U是按照某个采样率混合了正例和负例。这里有一个几乎贯穿所有方法的核心假设，叫SCAR假设：正例被采样并打上标签的概率与特征无关，也就是说，一个正例是否进入P集合，不取决于它的特征长什么样。这个假设是很多后续推导的地基，也是实战中最容易被忽略、最容易翻车的地方。

PU学习在工业界比我们想象中更常见。推荐系统里的点击样本是正例，但曝光未点击不代表用户不喜欢；风控里的已知欺诈是正例，但未报案未发现的欺诈依然存在；医疗场景更明显，确诊标签往往滞后且样本量小。你会发现，这些场景的共同点是：正例容易标注、负例没有明确边界，硬要标负例反而会引入大量噪声。传统做法是拍脑袋把U全部当负例塞进去训练，这在正例比例极低的时候模型会被严重带偏，于是才有了一堆专门处理PU问题的方法。

1.2 为什么普通AutoML解决不了PU问题

那这篇文章为什么不直接说“我们用了AutoML调参，效果不错”，而要专门造一个框架？因为PU场景下，AutoML常用的那把尺子失灵了。

标准AutoML的搜索过程依赖交叉验证，交叉验证又依赖有标签的验证集。在PU设定下，你的验证集里负例是缺失的，只有正例P和无标签U。你没法直接算验证集上的准确率、F1这些指标，因为U里你不知道哪些是负例。退一步讲，即使你硬把U当负例去算损失和指标，这个指标本身就是有偏的——它会把U里隐含的正例全部当作负例来惩罚模型，那AutoML再怎么优化，选出来的也只是“在有偏指标上好看”的模型，而不是真正区分正负的好模型。

所以这篇论文做的事情，并不仅仅是“拿AutoML去搜PU方法的超参数”，而是把PU学习里的偏差修正逻辑和AutoML的搜索框架耦合在一起。搜索空间里包含PU特有的模块，比如正例先验估计方式、风险修正策略、可靠负例筛选阈值；搜索目标也不能是朴素的有监督指标，而是一套在PU设定下可以估算的代理指标。这个耦合关系是全文的核心，理解了这一点，后面所有模块的展开就顺了。

2. 论文方法的核心拆解：从先验估计到风险修正再到搜索

2.1 整体框架：一条PU感知的自动化流水线

从框架层面看，论文把PU学习拆成了几个可以自由组合的环节，然后让AutoML去决定每个环节用哪种实现、参数取多少。整个流水线大致包括四个模块：数据预处理、正例先验估计、风险修正策略、基分类器。这四个模块不是简单串联，前两个模块的结果会直接改变后两个模块的计算方式。

举个例子你就明白了。同样是基分类器选逻辑回归，如果先验估计环节认为正例占比是0.1，损失函数里负例项的加权系数是一种值；如果先验估计为0.5，整个风险函数的结构就完全不同了。更微妙的是，选“两步法”还是“风险修正法”这种路线级决策，也应该是搜索的一部分。两步法的逻辑是先想办法从U里挖出一些相对可靠的负例，然后退化成普通监督学习；风险修正法的逻辑是保留U但给损失函数做补偿。这两种路线各有千秋，在不同数据分布下表现差异很大，AutoML的价值恰恰在于：替你试出在当前数据上哪条路线更香。

论文里对这种自适应有一个非常直观的动机：PU学习方法之间不存在绝对优劣。有的方法在正例比例高时好，有的方法在正例比例低时好，有的方法对先验估计错误不敏感，有的方法一错全错。与其由人来猜，不如让自动化机制在同一个内部分布上做公平的比较和选择。

2.2 最要命的模块：正例先验估计

这个模块是整个框架里最值得展开讲的部分。所谓正例先验，就是指在所有数据中，真正正例所占的比例，记作α。在普通分类里你不需要这个值，但在PU学习里，它是所有偏差修正的前提。α一旦估错，后面所有补偿都是错的，而且这种错误不会在训练损失上明显暴露，只会在最终线上评估时让你看到惨状。

论文中提到的先验估计大体有几条技术路线。一是基于特征空间的密度比估计：某区域里P的密度比U的密度高，意味着这个区域里U大概率也是正例，反过来可以通过密度差异反推α。二是基于分类器输出的技巧：先训练一个区分P和U的分类器，再利用它在某个理想条件下的概率输出和α之间的数学关系反解出α。三是一些更老的启发式方法，比如逐步剥离（peeling）和最大似然估计。论文把这些方式都纳入了候选集合，让搜索过程自己挑。

实操中我得提醒一句：先验估计的误差往往比模型选择误差更致命。如果你手里的U集合很小，密度比估计的方差会非常大；如果P集合本身不干净、混了噪声，估计出来的α会偏高。有时候你会发现模型输出概率偏高、把一堆负例也当正例，八成不是分类器的问题，而是先验估计的偏差一路上传到了损失计算里。

2.3 风险修正策略：biased与非负两种路线

先验估计之后的环节是风险修正。这里我用最朴素的语言解释。正常情况下监督学习的经验风险是在有标签的正负样本上算平均损失，但PU场景下你只有P和U。最简单粗暴的做法是把U全部当成负例来算损失，这就是有偏经验风险（biased risk）。这种做法在α很小的时候，U里绝大部分确实是负例，偏差不大；但在α不低的时候，U里隐藏的正例就会不断给模型制造错误的梯度信号。

于是就有了第二个路线：非负风险修正。它的核心思想是在有偏风险的基础上，把U里那部分“可能由正例贡献的损失”先减掉，剩下的一定是负例贡献的损失，再取一个非负的下界防止过拟合。用大白话说：U的平均损失减去正例P的平均损失，剩下的才是负例部分；如果减出来的结果是负的，说明你估计的先验或模型有问题，那就把这项截断成0。论文做得好的一点，是把这个风险修正策略也变成搜索维度，而不是固定选某一个，因为不同数据下方差控制要求不同，非负修正虽稳，但不是在所有场景都最优。

这个模块还牵涉到一个指标计算的问题：既然损失都是修正过的，那验证集的评估指标也得配套修正。论文在搜索过程中采用的代理指标，本质上是在PU设定下对真实风险的近似估计，而不是直接算标准准确率。这个设计上的严谨性，恰恰是这篇论文和其他“调参类”论文拉开差距的地方。

2.4 搜索策略与目标函数怎么设计

AutoML的另一半是搜索算法和目标函数。搜索空间我们上面已经拆了，再看搜索策略。论文采用的并非暴力网格搜索，而是带早停机制的序列化优化方案：先用少量配置快速摸底，再逐步把预算分配给表现好的候选管线上。这个思路和主流AutoML工具里常用的贝叶斯优化、基于TPE的序列模型优化是一脉相承的。

但PU场景给搜索带来了额外约束。因为验证集上没法算标准有监督指标，论文设计了“PU容量下的代理指标”，核心思想是：把正例部分单独切出来算召回和损失，把U部分通过先验修正后再估算分类性能。这样搜索过程每一步的评价都是有意义且可比较的。另外，考虑到PU数据的随机性，搜索过程中可能同一个配置在多次采样下得分波动很大，论文在评价候选时会做重复评估取中位数，这一点值得你们在自己复现时也照做。

时间预算也是搜索设计里不可忽视的一环。AutoML本质是用算力换人力，但论文实验里也明确展示了：预算太小的时候，自动搜索出来的管线可能还不如一个经验丰富的工程师手调的成熟PU管线；预算给到足够量级后，自动搜索的优势才稳定显现。这提醒我们，落地时要提前评估自己能接受多少计算量，不能既想要自动化又不给搜索时间。

3. 实验设计里藏着的门道

3.1 怎么在没有负例的情况下做验证

这是论文里我个人觉得最有借鉴价值的一部分，因为它解决了一个很现实的工程问题：没负例，你怎么证明模型有用？

论文采取的是多层验证体系。第一层是模拟PU数据：从一份有完整正负标签的公开数据里，人为把部分负例标签隐藏，让它们混入无标签集合，同时控制正例比例α在0.01到0.5之间变化。因为真实标签还在，所以可以在隐藏的负例上算出真实AUC和F1，用来客观比较不同方法。第二层是真实PU数据，这类数据天然只有正例标注，论文会额外通过领域知识构建一小部分可靠的负例验证子集，只用来评估，不参与训练。这个“验证用真负例、训练靠PU结构”的做法，我在自己项目里也一直沿用。

评估指标的选择也很有讲究。AUC不太受分类阈值影响，适合看整体排序能力，但在正例极不平衡时容易过于乐观。F1和PR-AUC更贴近业务，却对阈值敏感。论文的做法是同时报告多个指标，并且明确区分“搜索阶段使用的代理指标”和“最终评估阶段使用的真实指标”。这两个阶段指标不一致的情况在AutoML系统里非常多见，关键在于确保代理指标与最终指标在排序趋势上一致，而不是数值上接近。

3.2 基线和消融是怎么对照的

再来看对照设计。论文的基线分成三个层次：第一层是把U直接当负例、不加任何PU修正的普通监督分类器；第二层是不加AutoML、手工选定的经典PU方法；第三层是不加先验估计模块、固定一个拍脑袋先验值的AutoML管线。这三个层次对照非常有层次感，分别回答：PU修正有没有用、AutoML搜索有没有用、先验估计有没有用。

第一层对照是很多论文容易漏掉的，但它极其重要。工业界很多人其实心里知道U不是纯负例，但嫌麻烦就直接当负例训练。这篇论文用实验反复说明：AutoML再强，在错误的有监督设定下也只是把有偏模型调到最优，天花板摆在那里。所以做类似工作的人，请务必把“朴素有监督基线”放进去，否则你无法向业务方证明PU方法的增量价值。

消融实验里还有一个容易被忽略的细节：论文会固定不同模块后看性能退化幅度。比如把先验估计模块从“自动估计”改成“固定真实值”，对比差异；或者把风险修正策略从搜索维度里移除，看是否需要PU专用模块。这种逐层解剖的方式比笼统报一个最终结果更有说服力，也方便读者判断到底哪个环节最值得投入。

3.3 几个值得记住的结论

论文的结论用大白话翻译过来有三条。

第一条，自适应配置在低正例比例场景下增益最大。当α只有0.01甚至更低时，U里几乎全是负例，普通监督模型看起来够用，但实际上那1%的隐藏正例足够让决策边界偏移一大截，这时候PU修正和AutoML搜索带来的提升最明显。当α上升到0.2、0.3时，大家差距缩小，但自动搜索仍然没有显著变差——这意味着引入自动化基本不会带来额外风险。

第二条，对先验估计的纠错能力比想象中关键。消融里一旦固定错误先验值，哪怕是固定成离真实值只有0.05的差别，最终AUC都会掉一到两个百分点。这个结果给我们的启示是：如果业务上能通过抽检标注等方式得到相对可靠的α估算，那比花大力气调分类器参数划算得多。

第三条，非负风险修正方法通常更稳，但不总是最优。在部分高α数据上，非负修正会因为方差控制过于保守而略逊于有偏风险。所以论文把选择权交给AutoML，而不是替用户做决定。这种“不替你二选一，而是让你自动选”的思路，也是自动化机器学习系统的正确打开方式。

4. 落地实操：把你的任务改造成PU+AutoML

4.1 动手前先做三个诊断

读完论文别急着套代码，先拿三个问题给自己的任务做体检。

第一个问题：你的正例标注机制是不是近似随机？如果业务方只给大客户打标、只标记特定渠道进来的样本，那SCAR假设就破了，先验估计会系统性偏高。这种情况你可以尝试对标注概率建模，或者干脆重新设计标签采集流程，否则后续做再多修正都是空中楼阁。

第二个问题：你的U集合够不够大、够不够代表真实分布？PU方法在U集太小的时候方差爆炸，估计出的先验也不可信。我见过一个项目只有几百个U样本，那还不如老老实实人工标注一批负例，换到监督学习框架里去。

第三个问题：你业务上评估的是排序还是分类？PU学习里分类阈值的选择本身就带有不确定性，如果你的业务只需要Top-K推荐或者风险排序，那AUC、PR-AUC这些排序类指标会更可靠，也更能发挥PU方法的优势；如果业务一定要一个明确的“是/否”判断，你得额外设计阈值确定流程。

4.2 数据准备阶段最容易踩的四个坑

第一个坑是正例集里掺了假正例。PU学习假设P集合是干净的正例，但现实里业务方给的“正例”往往也是别人手工标的、有噪声的。少量噪声可能还能容忍，但噪声比例超过一定阈值后，先验估计会整体失真，建议在接入前做一轮“正例质量审计”。

第二个坑是正例和无标签集合的时间窗口不一致。比如正例是最近三个月的订单，U是最近一个月的流量，这会导致模型学到的是时间漂移而不是真实正负差异。让P和U来自同一个时间窗口、同一个渠道分桶，是数据准备阶段最容易被忽略但最影响结果的细节。

第三个坑是特征里包含标签泄露。PU场景下这个问题更隐蔽，因为你的“标签”本身就是不完整的正例标注。如果特征里带有“是否被运营手动标记过”这类字段，模型学到的可能不是正例本质，而是标注流程的痕迹。

第四个坑是重复样本。在U集合里如果同一个用户出现多次，会无形中改变U的内部正例比例，进而影响先验估计。建议在构造数据集时对实体粒度做去重，或者至少知道你的数据里重复比例是多少。

4.3 验证与评估的正确姿势

前面说了学术上的验证设计，落地时我也给你一套可执行的评估方案。

首先是训练期验证。把正例P随机切成两份，一份训练模型，另一份当验证正例，固定U不动。验证阶段计算两个数字：一是模型在验证正例上的召回，二是模型对U整体预测的分布距离。一个合理模型的特征是：验证正例的平均得分明显高于U的平均得分，且U内部得分分布存在一个可解释的尾部，而不是所有样本得分挤在一起。

其次是离线终评。如果有条件，请业务方协助人工标注一批不确定的U样本，最好分层抽样：分数最高的、分数中等的、分数最低的都要有。有了这批标注，就可以在不上线的情况下算出相对靠谱的F1和PR-AUC。这个方法虽然笨，但比任何花里胡哨的PU指标都更能说服业务方。

最后是线上AB验证。PU模型的收益往往体现在长期价值上，比如复购率提升、欺诈金额下降，这些指标比线下的AUC更能说明问题。别把线下小指标的提升当作全部，上线后观察真实业务指标才是最终裁判。

4.4 管线搭建和搜索配置的参考模板

读完论文之后，我自己在项目里整理的搜索管线和参考配置长这样：

搜索空间： - 预处理模块：[标准化, 分位数变换, 不处理] - 基分类器：[线性模型, 树集成模型, 近邻模型] - PU风险策略：[有偏风险, 非负风险修正, 两步法] - 先验估计：[密度比估计, 概率反推法, 固定经验值] - 可靠负例筛选阈值（两步法专用）：[0.1, 0.2, 0.3] - 分类阈值调节：[0.2, 0.3, 0.5]

搜索配置上，我先用一小组随机配置做摸底，选出几个表现稳定的方向，再用序列优化算法做精调。每轮候选会重复3次取中位数，防止单次采样把结果带偏。总预算方面，小数据控制在200次评估左右，大数据会放宽到500次以上，同时加上早停机制：连续若干轮没有超过当前最优就提前结束。

管道实现上我习惯封装成统一的Pipeline接口，把预处理、先验估计、风险修正、基分类器都串进去。这样做的好处是，搜索算法眼里只有Pipeline输入输出，不需要关心内部是两步法还是风险修正法，扩展新模块时也只需要注册新类。

4.5 跑起来之后的常见问题速查

这些坑我自己踩过不止一次，尤其是先验估计偏高导致的高分问题，几乎每个PU任务都躲不开。先别急着调模型，先把α和U的成分查明白，能省下大量时间。

5. 我的思考：边界、坑和真正值得借鉴的东西

5.1 什么场景适合用这套打法

不是所有PU问题都需要AutoML。如果你的数据量极大，比如几千万样本且U里正例比例极低，一个把U当负例的逻辑回归可能已经够用，因为它学出来的是近似最优决策边界，再折腾PU修正性价比不高。相反，如果数据量中等、正例标注成本高、需要稳定的排序能力，那这套方法就是最合适的。

另外要提醒的是，论文这套框架对代码工程能力有一定要求。你需要能封装Pipeline、能管理搜索预算、能处理候选管线的序列化与恢复。如果团队只是临时处理一个分析任务，手工选择一个经过检验的PU方法配上网格搜索调参，可能比搭建一整套自动化框架更务实。自动化的价值需要“多次使用”才能兑现，单次任务算总账不划算。

5.2 论文里最让我眼前一亮的三个细节

第一，它对“无标签集”的态度。很多资料把U简单看成“待标注数据”，但论文始终把U当作一个分布信息源，不做人工标注假设，这是PU学习方法论上最本质的视角。

第二，代理指标的设计。在PU设定下能构造出与真实风险排序一致的验证指标，这件事本身很有技术含量。我在自己做AutoML评估时借鉴了它的思路，在目标函数里同时保留正例召回和修正过的U分布损失，搜索出来的模型比单纯用有偏准确率稳定很多。

第三，风险修正与搜索空间的解耦。论文没有把非负风险修正写死，而是作为可选模块进搜索空间。这种设计体现了一种工程智慧：不要替方法做主观取舍，而是提供机制让数据自己表达偏好。

5.3 后续可以怎么扩展

这篇论文打开的方向其实不少。比如把PU学习和主动学习结合：AutoML搜索出的管线在哪些U样本上最不确定，就让业务优先标注哪些，这样能把每一份标注预算花在刀刃上。再比如扩展到多分类PU问题，现实里经常不只有正例和无标签，还有若干类互相冲突的标签，如何自动化设计多类别风险修正，是个有意思的开放问题。

分布漂移下的PU学习也值得关注。线上系统的标签采集机制会随业务策略变化，比如运营不再给某些渠道打标了，那你的正例先验就在变，模型需要在线自适应。除了静态搜索Pipeline，未来还应该考虑“带漂移检测的自动重训练机制”，让Pipeline整体具备生命周期管理能力。

最后说句掏心窝的话：这篇论文最值得学的不是某个具体模块，而是它把PU学习做成了可以在不同场景里复用的自动化系统。我个人读完最大的感触是，PU学习里最反直觉、也最影响效果的地方，从来不是分类器选哪种，而是对标签采集机制的审计和对先验比例的敬畏。把这些底层问题搞明白，再让AutoML去搜管线，才算真正踩在点子上。