产品经理的AI基本功：机器学习三要素

说实话，我刚转行做AI产品经理那会儿，最头疼的就是听不懂算法工程师在说什么。他们张口闭口「数据、特征、模型」，我表面上点头，心里其实在问：这仨到底啥关系？

后来我自己动手跑了几次模型，才真正搞明白。说白了，机器学习就是个「喂数据、提特征、训模型」的过程。我习惯用一个做饭的比喻来解释：

• 数据 = 食材。没有食材，再好的厨师也白搭。
• 特征 = 切菜、腌肉、配料的处理方式。同样的土豆，切丝和切块，做出来的菜完全不同。
• 模型 = 菜谱和火候。同样的食材和处理方式，不同厨师炒出来的味道天差地别。

嗯，这个比喻虽然糙了点，但道理不糙。我见过太多产品经理，一上来就催算法同学「快调模型」，结果发现数据质量一塌糊涂——那模型再牛也救不回来。

数据：推荐系统的命根子

数据是机器学习的起点。没有数据，后面全是空谈。

我在项目中遇到过最典型的问题：业务方说「我们有海量用户行为数据」，结果一拉出来，80%都是空值、重复、或者时间戳对不上的脏数据。你想想看，拿这种数据去训练模型，出来的结果能靠谱吗？

数据通常分三类：

数据类型	举例	常见问题
用户数据	年龄、性别、注册时间	缺失、过时、隐私合规
行为数据	点击、收藏、购买、停留时长	稀疏、噪声、冷启动
物品数据	商品标题、价格、类目	文本不规范、类目层级混乱

特征：让数据说话的艺术

数据是原材料，特征才是模型真正「吃」进去的东西。特征工程，说白了就是怎么把原始数据变成模型能理解的语言。

我个人习惯把特征分成几个层次：

• 原始特征：直接拿过来用，比如用户年龄、商品价格。简单，但信息量有限。
• 统计特征：对原始数据做聚合，比如「用户过去7天点击次数」「商品近30天销量」。这类特征在推荐系统里特别常用。
• 交叉特征：把两个或多个特征组合起来，比如「男性+数码类目」「18-25岁+晚上10点」。交叉特征能捕捉到单一特征看不到的模式。
• 序列特征：用户最近浏览的10个商品ID，按时间顺序排列。这类特征对捕捉用户兴趣变化特别有用。

举个例子。用户A和用户B都买了同一款手机，单看「购买商品」这个特征，他俩没区别。但如果你加上「购买前浏览了哪些商品」这个序列特征，就会发现：用户A是直接搜品牌名买的，用户B是看了3篇评测文章才下单的。这两个用户的决策路径完全不同，推荐策略也应该不一样。

模型：算法的核心引擎

模型就是那个「学习」的机器。它从数据中找规律，然后用这些规律来做预测。

我刚开始接触推荐系统时，总觉得模型越复杂越好。后来被现实教育了——简单模型往往更稳定、更容易解释、上线成本更低。你想想看，一个深度学习模型跑一次要3小时，而一个逻辑回归模型只要3分钟，效果还差不多，你选哪个？

常见的推荐模型包括：

• 协同过滤：找相似用户或相似物品。经典但容易遇到冷启动问题。
• 矩阵分解：把用户和物品映射到低维空间。我当年做视频推荐时，这个模型帮了大忙。
• 树模型：XGBoost、LightGBM这类。在特征工程做好的情况下，效果往往不输深度学习。
• 深度学习模型：DIN、DIEN、MMOE等。适合大规模、高维度的场景，但调参是个体力活。

监督学习与无监督学习

这两个概念，我建议产品经理一定要搞明白。因为很多业务问题，选错了学习方式，结果就是白忙活。

监督学习：有老师带着学

监督学习，说白了就是「有标准答案」的学习。训练数据里既有输入（特征），也有输出（标签）。模型的任务是学会从输入到输出的映射关系。

推荐系统里最常见的监督学习场景：

• 点击率预估：输入是用户特征+物品特征，输出是「用户会不会点击」（0或1）。
• 转化率预估：输入同上，输出是「用户会不会购买」。
• 评分预测：输入是用户+物品，输出是用户会给这个物品打几分。

我在项目中遇到过一个问题：业务方想要一个「猜用户喜欢什么」的功能，但他们只给了用户行为数据，没有给「喜欢/不喜欢」的标签。这就没法直接用监督学习，得先想办法打标签。

无监督学习：自己找规律

无监督学习没有标准答案。模型自己从数据里找结构、找模式。

推荐系统里常见的无监督学习应用：

• 用户聚类：把行为相似的用户分到一组，然后对同一组用户做统一推荐。
• 物品聚类：把相似的商品归为一类，方便做关联推荐。
• 降维：把高维特征压缩到低维，方便可视化或加速计算。

举个例子。有一回我们做新用户冷启动，没有用户历史行为数据，监督学习根本没法用。后来我们用无监督学习，把所有商品按类目、价格、风格做了聚类，然后根据新用户注册时填的偏好，直接推荐对应聚类里的商品。效果还不错。

过拟合与欠拟合

这两个概念，我建议产品经理至少要知道它们长什么样。因为模型上线后出问题，十有八九跟这两个东西有关。

欠拟合：模型太笨了

欠拟合，就是模型没学到数据里的规律。训练集上效果就差，测试集上效果更差。

为什么会欠拟合？说白了就是模型太简单，或者训练不够。比如你用线性模型去拟合一个明显是曲线分布的数据，那肯定欠拟合。

怎么判断？看训练集上的loss。如果loss一直降不下去，或者降得很慢，大概率是欠拟合了。

解决办法：

• 增加模型复杂度（换更复杂的模型）
• 增加特征（让模型有更多信息可用）
• 减少正则化（别限制得太死）
• 增加训练轮数（让模型多学一会儿）

过拟合：模型太聪明了

过拟合正好相反——模型把训练数据里的噪声和异常点都记住了，反而学不到真正的规律。表现是：训练集上效果特别好，但一到测试集就崩。

我遇到过最典型的过拟合案例：有一回我们做商品推荐，模型在训练集上的准确率高达98%，业务方高兴坏了。结果一上线，点击率比旧模型还低了5个百分点。后来一查，模型把训练数据里的一些偶然模式当成了规律，比如「某个用户在特定时间点点击了某个商品」，这种模式在真实场景里根本不会重复出现。

怎么判断过拟合？看训练集和测试集的效果差距。如果训练集准确率95%，测试集只有60%，那基本可以断定是过拟合了。

解决办法：

• 增加训练数据量（让模型看到更多样本）
• 降低模型复杂度（别用太深的网络）
• 增加正则化（L1、L2正则化，dropout等）
• 早停法（验证集效果不再提升时就停止训练）
• 数据增强（对现有数据做变换，生成更多样本）

怎么平衡？

欠拟合和过拟合，就像跷跷板的两头。模型太简单会欠拟合，太复杂会过拟合。产品经理要做的，就是帮算法同学找到那个「刚刚好」的点。

我个人习惯用验证集来监控。把数据分成三份：训练集（用来训练模型）、验证集（用来调参）、测试集（用来最终评估）。如果训练集和验证集的效果差距越来越大，说明开始过拟合了，该停就停。

嗯，说到这儿，我想起一个经验：很多时候，产品经理觉得「模型效果不好」，其实不是模型的问题，而是数据或特征的问题。先检查数据质量，再优化特征工程，最后才动模型。这个顺序，我建议你记下来。