日志不是垃圾，是金矿：聊聊基于日志的大规模用户行为建模如何撑起推荐系统

大家好，我是 Echo_Wish。

很多做推荐系统的同学，一上来就聊模型：DeepFM、DIN、Transformer……仿佛模型越“深”，推荐就越准。

但我这些年做大数据和推荐落地，反而越来越笃定一件事：

推荐系统真正的“灵魂”，不在模型，而在日志。

没有高质量行为日志，再牛的模型都是空中楼阁。今天我们就聊聊——基于日志的大规模用户行为建模在推荐中的应用，以及它背后那些容易被忽视的关键问题。

一、日志是什么？不是埋点，是用户的“时间线”

在推荐系统里，日志通常包括：

• 曝光日志（exposure）
• 点击日志（click）
• 加购日志（cart）
• 收藏日志（favorite）
• 下单日志（purchase）
• 停留时长（dwell time）

本质上，这些是用户和系统交互的时间序列。

举个简单例子：

user_id | item_id | action   | timestamp
----------------------------------------
1001    | A       | exposure | 10:01
1001    | A       | click    | 10:02
1001    | B       | exposure | 10:03
1001    | B       | exposure | 10:04
1001    | C       | click    | 10:05

这不是冷冰冰的数据，这是用户真实的“注意力轨迹”。

而推荐系统要做的，就是在这个轨迹里，预测“下一步”。

二、行为建模第一步：把“日志”变成“特征”

1️⃣ 基础行为统计特征

比如我们想构造一个用户对某类商品的偏好程度：

from pyspark.sql import functions as F

# 假设 logs 是用户行为日志表
user_item_stat = logs.groupBy("user_id", "item_category") \
    .agg(
        F.sum(F.when(F.col("action") == "click", 1).otherwise(0)).alias("click_cnt"),
        F.sum(F.when(F.col("action") == "purchase", 1).otherwise(0)).alias("buy_cnt")
    )

# 加一个简单的偏好分
user_item_stat = user_item_stat.withColumn(
    "preference_score",
    F.col("click_cnt") * 0.3 + F.col("buy_cnt") * 0.7
)

这类统计特征是推荐系统的基石。

但问题来了：

静态统计 ≠ 行为趋势

2️⃣ 引入时间衰减：行为有“保质期”

用户三个月前点过篮球鞋，不代表现在还想买。

我们可以引入时间衰减：

from pyspark.sql.functions import unix_timestamp, current_timestamp, exp

logs = logs.withColumn(
    "time_diff",
    unix_timestamp(current_timestamp()) - unix_timestamp("timestamp")
)

# 半衰期为7天
half_life = 7 * 24 * 3600

logs = logs.withColumn(
    "decay_weight",
    exp(-F.col("time_diff") / half_life)
)

weighted_score = logs.groupBy("user_id", "item_category") \
    .agg(
        F.sum(
            F.when(F.col("action") == "click", 1)
            .otherwise(0) * F.col("decay_weight")
        ).alias("decayed_click_score")
    )

这一步，是很多推荐系统从“能用”到“好用”的关键。

三、从“统计特征”到“序列建模”

当用户行为规模上亿条，光靠统计特征就不够了。

这时候就需要：

• 序列特征
• session 切分
• 行为 embedding
• Transformer / RNN 等建模

我们来看一个简化的用户行为序列构造方式：

# 按时间排序，构造行为序列
from pyspark.sql.window import Window

w = Window.partitionBy("user_id").orderBy("timestamp")

sequence_df = logs.withColumn(
    "rank", F.row_number().over(w)
).groupBy("user_id").agg(
    F.collect_list("item_id").alias("item_seq")
)

输出可能是：

user_id | item_seq
1001    | [A, B, C, D, E]

接下来我们就可以喂给深度模型：

# 伪代码
user_embedding = Transformer(item_seq)
score = dot(user_embedding, item_embedding)

这里的核心思想是：

用户不是“标签集合”，而是“行为序列”。

这是推荐系统思维方式的升级。

四、大规模日志的工程挑战

很多人只看到模型，却忽视数据工程。

但真实世界里，你会遇到：

1️⃣ 日志延迟与乱序

实时日志可能晚到几分钟甚至几小时。

解决方案：

• 使用 watermark
• 做窗口容错
• 延迟特征生成

2️⃣ 日志噪音

用户误点、爬虫流量、刷点击行为。

如果不做清洗，模型会学到垃圾模式。

比如：

# 过滤异常高频点击
abnormal_users = logs.groupBy("user_id") \
    .count() \
    .filter("count > 10000")

logs = logs.join(abnormal_users, "user_id", "left_anti")

日志清洗，往往比模型调参更重要。

五、我的一点真实感受

我见过太多团队：

• 模型调到天花乱坠
• embedding 维度拉到 512
• GPU 集群轰鸣

结果上线效果不涨。

最后发现：

• 曝光日志丢了
• 点击埋点漏 30%
• 时间戳错时区

推荐系统的本质不是“算法秀肌肉”，而是：

谁能更真实地还原用户行为。

大规模日志建模的核心，不是堆算力，而是三件事：

1. 行为定义清晰
2. 特征构造合理
3. 数据链路稳定

模型只是放大器。

六、推荐系统的终极问题

当我们基于日志建模时，有个值得思考的问题：

我们是在“预测兴趣”，还是在“放大行为”？

如果用户偶然点了一次某类内容，我们持续推荐——
那是个性化，还是信息茧房？

日志是历史，但推荐决定未来。

作为工程师，我们不能只关心 AUC。

我们要问：

• 是否引导用户探索？
• 是否给新内容机会？
• 是否平衡多样性？

这也是我越来越关注“探索机制”和“多样性建模”的原因。

七、总结

基于日志的大规模用户行为建模，本质上是一件三层结构的事：

第一层：数据层 —— 日志清洗、去重、时间对齐
第二层：特征层 —— 统计特征 + 时间衰减 + 序列构造
第三层：模型层 —— 深度建模、embedding、注意力机制

但真正决定推荐质量的，不是最底层，而是最顶层对“用户行为”的理解。