基于代理的演化搜索框架AgentLTV：破解LTV预测与用户分层难题

聊一个做用户增长的同学这两年都绕不开的问题：LTV预测。LTV，Lifetime Value，说白了就是估算一个用户从进来那天到他流失为止，到底能贡献多少价值。听着简单，可真要亲手训练一个能上线的模型，你会发现它比一般回归任务难得多。我前阵子在某电商项目里负责用户价值分层，被旧模型的预测误差按在地上摩擦：180天LTV预测误差长期在30%以上，每次接入一个新渠道，特征工程就要重做一轮，团队已经有点想打人了。后来我把思路整个换掉，做了一个基于代理的框架，把统一搜索和演化自动化装进去，最后在保持业务可解释的前提下把误差压下来一截。这个框架就是AgentLTV。这篇文章我会把它的设计动机、核心机制、工程实现、评测链路和踩坑点完整讲一遍。如果你也在做用户增长、电商数据分析、推荐策略或者生命周期管理，这篇应该能给你一些参考。

1. 传统LTV模型为什么让人头疼：从“离线好、线上差”说起

我见过太多团队说“我们的LTV模型挺好的”，但一问离线指标多少、线上业务提升多少，就开始岔开话题。其实LTV模型难不在算法，难在数据本身和业务定义。

1.1 “终身”到底多长？窗口定义里的学问

先聊第一个坑。LTV里的“终身”不是一个客观概念。有人说预测180天，有人说365天，还有人说“到用户自然流失为止”。不同业务必须选不同窗口，但窗口一旦选错，后面模型做得再花也没用。比如你做一个短周期、高频消费的业务，硬套365天窗口，观察期30天后大量用户其实早就流失了，预测的“终身价值”里绝大部分是噪声。反过来，如果业务天然低频，比如装修、婚纱这类用户一辈子就消费一两次，你却用180天窗口，模型学到的只是瞬时价值，不是真正的终身价值。

实操中比较稳的做法是分两步：先用生存分析把用户群体的生命周期分位数摸清，比如P50、P80、P90大概多少天，再选择预测窗口。一般取P80到P90之间的天数，保证覆盖到大部分有价值用户。我这边最后用的是180天窗口，因为业务数据显示，有付费行为的用户里P80的活跃期在170天附近。窗口定了，还要处理“右删失”问题：训练集里很多用户在第180天还活着，他的真实终身价值还没完全发生，我们用截尾数据学回归，天然会把高价值用户往低处拉。常见做法是给右删失样本降低权重，或者用带生存概率加权的回归损失，而不是简单删掉这些样本。这个窗口问题很少有人在论文里讲透，但在实际项目里它决定了模型的天花板。AgentLTV把窗口选择也作为搜索空间里的一个参数，让演化算法自己去权衡，而不是拍脑袋定死，这一点后面还会提到。

1.2 手工特征工程：最笨也最耗人的环节

第二个坑是特征工程。经典LTV模型输入一般是：注册时间、渠道来源、累计消费金额、消费次数、最近一次消费距今时间、品类数、优惠券使用率……听起来头头是道，可一旦业务迭代，这些特征就得跟着改。我就在项目里经历过：某个渠道改版后，用户首单金额分布整体右移，导致旧特征全部失真，重新定义特征又花了两周。

本质原因是什么？特征工程本身就是搜索。人在手工拼接特征时，做的是在“操作空间”里寻找能够分离高价值用户和低价值用户的组合。但人的搜索速度上限很低，而且容易被业务直觉限制。比如“消费金额除以活跃天数”这种简单比率，一个有经验的数分可能两三天才能试完几个变体，但演化算法一个晚上就能试几百种操作组合。所以我的想法是：能不能把特征工程抽象成统一搜索空间，让机器来自动探索，我只负责定义算子和约束。

1.3 模型选择与分布假设：LTV不是普通回归

第三个坑更隐蔽。LTV的分布通常是极度右偏且零膨胀的：很大比例用户价值为0，剩下用户里少数头部贡献绝大部分收入。拿普通回归（包括普通XGBoost回归）去拟合这种分布，大概率学出一个“平均主义”模型，预测值被压向均值，高价值用户基本预测不出来。这也是离线MAE看起来还行、线上做分层却没法用的原因之一。

要处理这种分布，常见路子有三条：一是用Tweedie回归，或者在目标函数里用Tweedie损失；二是拆成两阶段，先分类（是否产生价值），再对正样本回归；三是用分位数回归，预测分位点而不是均值，供业务按不同分位做策略。这三种并不互斥。在AgentLTV的搜索空间里，它们都被建模成可选模块，而不是模型外手工决定的。

有了这三个基础认识，你应该能理解我为什么偏要做一个“框架”而不是接着调参数：LTV预测的问题根本不是单个模型不够强，而是业务定义、特征工程、分布假设、模型选择、评估方式一个串一个地耦合在一起，每换一个渠道就要重来一遍。这种场景很适合用自动化搜索的方式去解决。

2. 基于代理的框架分工：AgentLTV怎么把难题切成几块

2.1 四个代理各自管什么

“基于代理”这个名字第一次听可能有点唬人。我这里的代理不是那种闲聊型AI Agent，而是更朴素的软件代理：每个代理是一个独立的模块，负责一个子问题，通过统一的消息接口协作。AgentLTV里我设计了四个代理：

• 调度代理：整个演化流程的总控，决定当前该让哪个代理干活、何时迭代下一代；
• 特征代理：负责生成和变异特征表达式，也就是在搜索空间里生产候选特征；
• 模型代理：负责选择模型结构和超参，包括回归头类型、正则强度、是否两阶段等；
• 质量代理：负责评估一组特征+模型组成的管道，计算多目标适应度，并维护一个历史结果缓存，避免重复评估相同管道。

这四个代理之间不直接调函数，而是通过一个上下文对象交换数据。调度代理发出“生成一批新个体”的命令，特征代理和模型代理分别返回值，质量代理拿到这批个体后做评估，再把结果回传给调度代理。这样做的最大好处是可替换：想换评估策略，不需要动其他代理。

为什么这么切？因为LTV预测链路天然分几个阶段：特征建设、模型训练、效果评估、迭代决策。每个阶段面对的约束不一样：特征代理关心操作性，模型代理关心泛化能力，质量代理关心业务指标。如果都混在一个大循环里写，代码会乱到没法维护。分代理之后，每个模块可以单独测试，也可以在线上单独灰度替换。

2.2 统一搜索空间：让特征、模型、评估说同一种语言

“统一搜索”这四个字其实是这个框架的灵魂。大多数自动化机器学习方案是分层做的：先自动特征工程，固定特征后再调模型参数。听起来没毛病，但问题是特征好不好取决于最终模型怎么用它，模型偏好又取决于输入特征长什么样，这是一个典型的循环依赖。分层做法会限制最终效果。

AgentLTV的做法是定义一棵“管道树”：树的浅层是特征变换节点，树的末端是模型节点，整棵树作为一个个体参与演化。举个例子，一个管道可以长这样：

• 原始字段：用户累计消费金额、累计消费次数、注册时长；
• 特征节点A：对累计消费金额做log1p；
• 特征节点B：计算“累计消费金额除以消费次数”，得到客单价；
• 特征节点C：对注册时长做负指数衰减，得到一个近30天活跃衰减分；
• 模型节点：输入以上特征，选择LightGBM回归器，损失函数用Tweedie。

这个管道用一个嵌套的Python对象表示，可以被序列化成字符串，也可以被演化算子随意增删节点。所有节点都从同一个算子库取，所以叫“统一搜索”，因为特征和模型都在同一个空间里被搜索。

算子库长什么样？我列一个简化版：

有了这个统一搜索空间，演化算法才能同时动特征节点和模型节点，而不是像传统流程那样“先特征后模型”。

2.3 为什么选演化搜索，而不是网格搜索或神经架构搜索

有人会问：你这不是也能用Optuna做吗？Optuna适合连续超参调优，它对“结构”的搜索能力很弱。LTV特征组合是典型的离散结构问题，比如“要不要套log”“要不要除以活跃天数”“要不要加滚动窗口统计值”，这些是组合爆炸的，不是一组连续参数。演化算法对这种树形结构的改动（把子树替换成另一棵子树）很自然。

神经架构搜索当然也可以做，但它需要大量GPU资源和超长的训练时间，我们做业务项目的时候根本等不起，而且NAS搜出来的网络结构可解释性几乎为零，业务方不会接受。而演化搜索用几十个个体的种群，迭代十几代，在中等规模数据上就能搜出和人工特征工程相当或更好的结果，成本可控得多。后面我会细说实际的耗时和效果。

3. 演化自动化的工程实现：编码、适应度与算子设计

3.1 管道编码：一棵算子树 + 一个模型头

演化算法的第一步是设计“基因型”。我这里直接用树结构：特征节点是内部节点，模型节点是根节点。每个节点存一个算子ID和参数字典。整棵树可以用嵌套对象表示，方便做交叉变异。代码示意如下：

from dataclasses import dataclass, field from typing import Dict, List @dataclass class PipeNode: op: str # 算子名称，例如 'log1p', 'rolling_mean', 'lgbm' params: Dict = field(default_factory=dict) children: List['PipeNode'] = field(default_factory=list) # 一个完整管道示例 pipe = PipeNode( op='lgbm_regressor', params={'loss': 'tweedie', 'n_estimators': 200}, children=[ PipeNode(op='div', children=[ PipeNode(op='field', params={'name': 'total_amount'}), PipeNode(op='add', params={'bias': 1.0}, children=[ PipeNode(op='field', params={'name': 'order_count'}) ]) ]), PipeNode(op='log1p', children=[ PipeNode(op='field', params={'name': 'age_days'}) ]) ] )

这段代码只是示意，实际工程里会有一层“表达式编译”：把PipeNode翻译成可执行的pandas/numpy变换函数。这也是整个框架最核心的部分，算子库必须全部是纯函数，输入输出维度明确，才能安全地放进演化流程里反复试错。

3.2 多目标适应度：预测误差、复杂度和业务可解释性的平衡

适应度函数如果只写一行MAE，那演化出来的东西很可能不可用。我在项目里用三个子目标：

• 预测精度：180天LTV的加权MAE，权重按用户价值分位提升。如果只按平均MAE选，模型会牺牲高价值用户去换取中低价值用户的精度，这对做增长策略完全没用。
• 特征复杂度：管道叶子数、深度和特征字段数的加权和。太深的复杂表达式虽然可能在验证集上好看，但上线时容易过拟合，而且排错难。
• 业务约束：比如是否包含特定必选字段、是否超过最大特征数、是否违规用了未来信息（比如预测时不该出现的后视特征）。

最后合成一个总体适应度：fitness = w1 * 加权MAE + w2 * 复杂度惩罚 + w3 * 约束违规惩罚。权重w2、w3要设得保守一点，因为搜索过程中偶尔会出现复杂度过高但效果极好的个体，后期需要靠种群多样性把这一类压下去。

3.3 遗传算子、并行评估与计算预算控制

演化循环本身不复杂：初始化一批随机管道，评估，选优，交叉，变异，再评估。关键在两个地方：

一个遗传算子要符合树结构。我是这样做的：

• 交叉：随机选择两个父代，分别选一个子树，交换。因为两个父代可能模型头不同，交换时我限制只交换特征区域，模型头单独保留，避免生成没有根的畸形个体。
• 变异：随机替换某个特征节点为另一个同类算子；或者对模型节点的超参数做一次小幅随机扰动；有概率向叶子节点插入一个新的变换节点。
• 种群大小：我这边数据量不算大，设了40个个体，迭代12代。每一代里每个个体都要训练一次LightGBM，单机8核并行评估，一整套搜索大约2到3小时。如果一开始就想搜大空间，建议先用10个个体的种群跑两代，估算下单次训练耗时再说。

计算预算控制也很重要。演化算法很容易让人上头，在项目里我们设了全局最大评估次数（比如500次）和单个体最大训练时长（比如3分钟），超时直接丢掉。同时在质量代理里维护一个历史结果缓存，完全相同的管道不会重复训练，这个缓存加上后实测省了将近三成时间。

4. 实测复盘：离线评测与上线的完整链路

4.1 时间序列交叉验证怎么做才不“作弊”

很多人在离线评测LTV模型时直接用普通K折交叉验证，这是很危险的。LTV数据是严格时间序列：用户行为会随活动、季节、渠道策略漂移，随机打乱K折会引入未来信息，导致离线MAE虚低。项目里我用了滚动扩窗验证（expanding window），类似这样：

• 训练窗口1：第1天至第180天注册的用户，观察前30天行为，预测第180天LTV；
• 验证窗口1：第181天至第270天注册的用户；
• 训练窗口2：第1天至第270天注册的用户，观察前30天行为，预测第270天LTV；
• 验证窗口2：第271天至第360天注册的用户。

这样每个验证集和训练集在时间上严格错开，每轮都用历史全部数据训练，稳定度更高，代价是训练成本成倍增加。实测下来，虽然麻烦，但离线结果和线上A/B结果的相关性明显比单次切分要好，这是最值得坚持的一步。

4.2 关键指标：高价值用户误差、提升度和校准度

离线评估我同时看几个指标，不只看MAE。首先是整体加权MAE，权重按用户历史付费金额分位定义，头部权重高。其次是Top20%高价值用户的加权误差，这个指标直接关系到大R策略是否有用。第三是提升度（Lift），把预测值从高到低分成10组，看每组实际LTV均值是否单调递减，有序性越好说明模型排序能力越强。AUC和Gini系数也可以参考。

我拿旧模型和AgentLTV跑了一组实际数据，结果大概这样：

Gini系数提升0.09，在用户分层场景里已经能给运营带来可感知的分群差异。特征数从86降到27，意味着数据服务层只要维护27个特征，开发和排错的成本低了不少，这才是框架带来的工程红利。

4.3 上线部署与监控：几个容易忽略的细节

AgentLTV搜出来的管道不能直接丢到线上，有几个工程细节必须处理。

第一是特征一致性。演化搜出来的特征表达式如果用了“用户累计消费金额”，线上特征计算必须和离线用完全一致的窗口口径。我这边统一封装了一个特征服务，离线训练和线上打点共用同一份表达式编译结果，避免“离线用pandas、线上用Java重写”导致的口径漂移。

第二是预测值校准。LightGBM的Tweedie输出在极端长尾下可能偏高或偏低，上线前我用Isotonic回归对预测分位做了一层校准，保证预测均值接近实际均值。

第三是监控。上线后我每天看预测值分布的PSI（稳定性指数），一旦发生漂移，先查渠道结构是否变化，再查特征源数据是否出问题；同时把新客和老客的监控分开，因为两者的预测量级差异很大，混在一起会掩盖问题。这几件事做完，线上效果才算真正稳住。

5. 踩坑记录：演化搜索不是银弹，但这些坑可以避开

5.1 验证集被“演化了”怎么办

演化搜索最隐蔽的坑是过拟合验证集。因为反复用同一个验证集评估每一代个体，遗传算法本质上就在做优化，几十代以后个体很可能会记住验证集的噪声，而不是学泛化规律。第一次跑AgentLTV时，我们在验证窗口2上表现涨了一截，但换到下一个自然月的数据直接掉回去。

后来我在流程里加了一道“终选验证集”：把最近30天注册的用户数据完全锁住，不参与任何演化迭代，只有最终敲定管道时才用一次。这个集被我们内部叫“考卷”，演化过程不许碰，碰一次就废了。如果你也打算跑类似框架，这个步骤一定要加。

5.2 零膨胀与极端长尾的应对

前面说过LTV分布零膨胀，但真正把它放进搜索空间后才发现更麻烦。演化初期很多个体倾向于输出接近0的常数，因为数据里大量0让这个“预测”的均值误差很低。质量代理光看加权MAE根本分不出好坏。

后来我在模型节点里强制加入“两阶段开关”：搜索出来的模型要么是纯回归，要么是“分类器（是否产生价值）加回归器（价值金额）”，质量代理对两阶段模型额外给一点结构奖励。实测下来，两阶段模型的Top20%误差普遍比单阶段低，这个经验值得记下来。

5.3 特征可解释性约束带来的取舍

演化搜出来的特征里，有些表达式非常怪，比如“sqrt(金额) / (exp(-注册天数/90) + 0.1)”，数值上可能合理，但你没法跟业务解释。业务方看到这种特征第一反应是拒收。

我在项目里加了一层“可解释性过滤器”：每个特征节点最多嵌套两层变换，禁止对时间字段做平方或除法以外的复杂运算。加了约束后精度掉了大概3%，但换来的是业务同学愿意签收模型，这个交换我认为很值。演化自动化不是一个单纯的拟合工具，业务约束本来就是搜索空间的一部分，早点把这些约束写进代码，后面能少吵很多架。

6. 给想复刻AgentLTV的人几句大实话

6.1 从“花架子”到能上线的落地路径

如果你也想在团队里做一套类似的框架，我的建议是别一开始就追求全自动、大框架。先把现有手工特征管线重构成“算子化”的，也就是每个特征变换都变成可配置的纯函数，然后跑一个只演化特征工程、模型固定为LightGBM的简化版。这个简化版能让团队先看到效果，再逐步把模型选择、损失函数、窗口参数加进搜索空间。

工具方面，不要自己造轮子。Python生态里演化算法可以基于DEAP来写，超参调优可以配合Optuna做局部精调；特征工程演化也可以用gplearn这类现成库先跑通，再替换成自己的算子库。AgentLTV这个名字听着唬人，拆开看核心就是一个树形搜索空间加一个调度循环，关键是把业务约束写进适应度函数，以及把评测协议设计对。

6.2 这套框架能迁移到哪些场景

做完AgentLTV之后，我发现这套思路不只适用于LTV预测。只要是“目标变量定义清晰、特征组合空间大、业务上频繁换渠道或换品类”的场景，都可以套用。比如：预测用户流失概率、预测客单区间、新品类冷启动时预测早期销售表现，甚至做风控里的违约概率预测，只要把搜索空间里的业务算子换一批，演化循环和代理框架基本不用动。

最后说一句实际的：LTV预测这个事，模型的绝对精度提升永远有限，我这次做完后180天预测MAE下降了不到20%，但对用户分层排序能力的提升才是真正影响业务的东西。演化搜索最大的价值不是替你做决定，而是把那些“试过才知道行不行”的特征组合和模型选择，变成系统化的自动实验。拿到这套框架之后，后续接新渠道、新业务时，不用再像以前那样从头做特征工程了，这大概是我觉得这个项目最值的地方。