亿级容量下的用户表征学习：Densing Law 与自适应分词 ALGN

  • 关联论文：2608.23392
  • 作者：flyP
  • 更新：2026-08-26

一句话结论

支付宝团队在亿级用户行为序列上首次刻画出"最小充分分词容量"与"数据规模"之间的对数线性 Densing Law，并据此提出自适应变长分词器 ALGN，把 tokenization 从工程黑箱变成了可定量预算的步骤。

解决什么真问题

工业级用户表征学习（User Representation Learning）长期靠三把"尺子"放大：用户量、行为序列长度、模型参数。但在十亿级容量下，作者观察到两件怪事——

  1. 原始行为文本直接堆量的收益急剧递减。更长序列并不稳定带来 AUC 提升，存在明显的"原始数据扩展瓶颈"。
  2. 分词粒度没有定量选择依据。工程上凭经验拍脑袋：太粗丢失语义、太细消耗 embedding 表与计算，究竟"够用"的分词容量是多少、随数据规模如何增长，缺少可推导的规律。

换句话说，过去的研究告诉你"模型越大越好"，但没有回答"在数据规模 X 下，分词容量配到 Y 才不浪费"。本文的核心贡献是把这个经验空白补上。

核心方法

1. User Behavioral Densing Law

论文在十亿级支付宝行为数据上做了 pilot 对照：raw text scaling vs tokenized scaling，并做了理论与系统实验联合推导。最终得到一个关键经验规律：

最小充分分词容量（记为 V_min）与输入数据规模（以 token 计，记为 D）之间近似满足：

log(V_min) ≈ α · log(D) + β

即两者对数线性关系；斜率 α 受分词方法与数据源影响，反映不同表征空间的冗余度与源内唯一性差异。

这与 LLM 领域的 Chinchilla / Scaling Law 同构，但作用对象换成了"分词容量"而非"参数 / 数据"。本质上，Densing Law 告诉团队：数据规模涨 10×，最小够用的词表规模 / 行为 token 数大约涨 10^α×，α 是从你的 tokenization 和数据源上测出来的一个可调常量。

2. ALGN：自适应变长分词

有了 Law，下一步是工程兑现。ALGN 把"固定粒度"换成"按内容自适应"——根据原始行为的密度分布动态切分 token，使高频模式被压紧、低频长尾保留足够区分度。它服从 Densing Law 预算：

def algn_tokenize(seq, V_min, alpha, beta):
    # V_min 由 Densing Law 在当前 D 上预算出来
    cap = V_min * len(seq)
    if cap < MIN_FLOOR:
        return coarse_tokenize(seq)      # 粗粒度兜底
    if seq.entropy > HIGH:
        return fine_tokenize(seq)        # 高熵段细切
    return adaptive_split(seq, cap)      # 按预算自适应切

要点是：ALGN 不是"切得更细"那么简单，它的目标函数是"在 Densing Law 划定的 V_min 预算内，把 token 的语义信息密度做到最高"。

3. 验证协议

为证明 Law 的可推广性，作者做了三轴实验： - 数据源轴：跨多种业务来源对比 α 斜率； - 分词方法轴：对比 BPE / unigram / 行为专用切分器； - 下游任务轴：覆盖排序、召回、CTR 预估等多种典型工业任务。

关键实验与数据

  • Pilot：在十亿级支付宝数据集上，raw text 行为序列的 AUC 增长在容量扩张后期趋于平缓；同等 token 量下，先 tokenize 再训练能持续拿到收益。
  • Densing Law 拟合：log(V_min) 与 log(D) 的线性回归在多种 tokenization / data source 组合下残差小，斜率 α 随组合系统性变化（与"表征空间冗余度 / 源内唯一性"定性解释一致）。
  • ALGN 收益：在多种数据源、分词方法、下游任务组合下，ALGN 均优于固定粒度 baseline（具体数值表见原文 PDF §5；本文作者在 abstract 中只给了"ALGN outperforms existing baselines"的定性表述，精确百分点原文未公开）。
  • 规模：报告 28 页 / 13 图，是技术报告而非顶会正文格式（投稿去向未在 arXiv 注释中标注，录取状态原文未明确）。

亮点与局限

亮点

  • 首次把"分词容量"纳入 Scaling Law 框架。过去 LLM 圈讨论参数 / 数据 / FLOPs 的 Chinchilla 关系，本文把它平移到了工业推荐里的 tokenization 维度，方法论迁移价值大于单一数值结果。
  • 亿级真实数据 + 理论推导 + 多轴验证。这不是 toy 数据上的 fitting，而是带理论分析与系统实验联合的工程报告。
  • ALGN 提供可落地的范式。"自适应变长分词服从 Densing Law 预算"这一思路可推广到搜索、推荐、内容理解的多个序列建模场景。

局限与 ⚠️ 标注

  • 精确数值未在 abstract 公开。abstract 只说"outperforms"，未给具体 AUC 提升幅度；读者必须读 PDF 主表才能对比基线。v1 摘要口径 / 待 A1 核 PDF §5 主表。
  • 结论偏支付宝单源。Pilot 与 α 拟合在"支付宝十亿级行为"上完成，是否完全可迁移到海外 / 短视频 / 电商之外的场景，需要外部团队复现。
  • 报告文体而非顶会正文。28 页技术报告格式，录取状态 / 同行评审结果原文未明确——本文据 abstract 引用应作为 pre-print 看待。
  • 未公开训练成本与延迟。ALGN 的"自适应切分"在 serving 时是否引入额外推理成本，原文 abstract 未提及。
  • Densing Law 的"对数线性"是经验规律。在小数据 / 极长尾分布上是否仍然成立、是否需要分段线性修正，原文未明确。

对工程落地的启发

  1. 给"分词预算"立项。任何做行为序列建模的团队都可以复现这套 pilot：在自家数据上画出 log(V_min) ~ log(D) 关系，得到自己的 α。先看 α 是 0.5 还是 0.8，就知道扩容方向是往词表走还是往数据走。
  2. 把 tokenization 纳入容量规划评审。以前容量评审只看模型大小与序列长度；以后把"最小充分分词容量"列为第三轴，并写进容量预算表。
  3. ALGN 类自适应切分可作为中间件组件。即使不直接采用支付宝的 ALGN，"按数据密度自适应切 + 服从预算上限"这一范式可以做成通用 tokenization SDK，对接多种序列任务。
  4. 跨业务线 α 漂移监控。同一公司内不同业务线 α 可能差异显著（短视频 vs 电商），应建立 α 漂移看板，避免一套 tokenization 配置吃所有业务。

与同方向工作的关系

  • LLM Scaling Law（Chinchilla / Scaling Laws for Neural LM）：本文是其方法论在"分词容量"维度的自然延伸，把"参数 ↔ 数据"换成"分词容量 ↔ 行为数据规模"。
  • 工业推荐中的序列建模（DIN / DIEN / SIM / TWIN / ETA）：这些是"行为序列 → 表征"的网络结构主线，本文不与它们竞争，而是给上游的 tokenization 步骤提供量化预算。
  • 自适应 / 学习型分词（SentencePiece / Byte-Pair Encoding 变体）：ALGN 与这一脉的工程探索同向，但核心差异是"服从 Densing Law 预算"而非纯凭 perplexity 优化。
  • Hash / QuEra 等行为压缩方法：与"减少 token 数"的目标一致，但 Densing Law 给的是"减到多少才够用"的标尺。

适合谁读

  • 工业推荐 / 搜索 / 广告团队做行为序列建模的算法工程师——直接相关，可以照搬 pilot 流程拿到自己业务线的 α。
  • LLM 预训练 / tokenizer 设计研究者——从 Scaling Law 视角读会很有共鸣，方法论可逆向迁移回 NLP 通用领域。
  • 平台架构师——把"分词容量预算"纳入容量规划体系，比纯拍脑袋稳一档。
  • 学术读者——可以作为"工业 Scaling Law"专题的一篇标杆 pre-print 阅读，但要留意报告文体与录取状态未明两点。

工程落地与核查（Jay）

事实核查摘要

核查项 原稿声明 核查结果 风险
Densing Law 对数线性关系 "log(V_min) ≈ α · log(D) + β" ✅ abstract: "approximately linear relationship between the logarithms of minimum sufficient tokenization capacity and input data size" 低
亿级支付宝数据 "十亿级支付宝行为数据" ✅ abstract: "billion-scale Alipay dataset" 低
ALGN 优于 baseline "ALGN 均优于固定粒度 baseline" ✅ abstract: "ALGN outperforms existing baselines" 低（⚠️ 无具体数字）
28 页技术报告格式 "28 页 / 13 图，技术报告" ✅ abstract comments: "28 pages, 13 figures, technical report" 低
精确 AUC 百分点未公开 "精确百分点原文未公开" ✅ abstract 确实只说 outperforms，无具体数字 低（已注明）
录取状态未明确 "投稿去向未标注，录取状态原文未明确" ✅ abstract 无任何 conference 引用，标注正确 低
多数据源 / 多 tokenization 方法验证 "跨多种业务来源 / BPE / unigram / 下游任务" ✅ abstract 确认 "diverse data sources, tokenization methods, and downstream tasks" 低
Densing Law α 斜率系统性变化 "α 随 tokenization 方法和数据源系统性变化" ✅ abstract: "scaling slope varies systematically with the tokenization method and data source" 低
报告无 serving 延迟数据 "未公开训练成本与延迟" ✅ abstract 确实无任何 latency / throughput 数据 低（已注明）

工程落地核查

1. 复现路径与依赖清单

# 关键依赖（原文未开源代码，以下为推断路径）
# 数据: 支付宝用户行为序列（私有数据，无法直接获取）
# tokenization 方法: BPE / unigram / 行为专用切分器（标准工具链可复现）
# 下游任务: 排序 / 召回 / CTR 预估（工业标准评估）

# 工程实现检查清单
- [ ] 私有数据获取: 支付宝数据不对外，外部团队无法直接复现 pilot
- [ ] V_min 测量协议: 如何定义"最小充分分词容量"——原文未给出可操作的测量流程
- [ ] alpha 拟合的数据量门槛: 需要多少数据点才能可靠拟合 log(V_min) ~ log(D) 线性关系
- [ ] ALGN 自适应切分的 serving 延迟: 高熵段细切 / 低熵段粗切带来的变长推理如何工程化

2. 已知工程坑点

坑 1：支付宝数据不可获取，外部无法独立复现 ⚠️ 这是技术报告落地最难逾越的障碍。原文 pilot 完全基于支付宝内部数据，外部团队无法获取同等规模、同等分布的行为序列。方法论可参考，但 α 数值和 ALGN 参数无法直接迁移，需要在自己数据上重新拟合。

坑 2："最小充分分词容量"V_min 的定义不明确 原文说 V_min 是"最小充分分词容量"，但未给出可操作化的测量标准——是用 perplexity 收敛点？还是用下游任务 AUC 拐点？抑或 embedding 表利用率？V_min 的测量协议不清晰，限制了工程团队复现 Densing Law 的可操作性。

坑 3：ALGN 变长切分的 serving 工程复杂度 自适应变长 tokenization 在 serving 时比固定长度 tokenization 更难工程化： - 不同 batch 的序列长度分布差异导致 GPU 利用率不稳定 - V_min 预算需要在线计算，增加了 serving 路径的复杂度 - 行为序列通常需要在线实时切分（streaming inference），而非离线批处理

坑 4：Densing Law 跨分布泛化性未验证 α 是从支付宝数据上拟合出来的——不同业务线（短视频 / 电商 / 金融）的用户行为分布差异可能使 α 漂移。原文说"斜率随数据源系统性变化"，但未给出跨业务线的迁移条件。工程团队需要为每个新业务线重新测 α，成本不低。

坑 5：技术报告无同行评审，结论可靠性偏低 28 页技术报告格式，录取状态未明，无同行评审意见可供评估方法学质量。LLM 界的 Scaling Law paper（如 Chinchilla）经过 GPT-3 / PaLM 等多团队多轮复现才被广泛接受；Densing Law 目前只有支付宝单团队单数据源验证，工程引用需谨慎。

3. 快速验证建议

# 验证 1：在自有数据上测 Densing Law 的最小数据量门槛
# 从 1M / 10M / 100M / 1B token 四个数据规模测 V_min 拟合
# 确认 log-log 线性关系在哪个规模开始成立（避免在小数据上错误拟合）

# 验证 2：ALGN 变长切分的 serving latency 开销
# 与固定 BPE 对比：P50 / P99 推理延迟 + GPU 利用率
# 预算 V_min 在线计算的额外开销（通常 < 1ms，但需实测）

# 验证 3：α 漂移监控
# 定期（如每月）在当前数据规模上重新拟合 α
# 若 α 变化 > 0.1，说明业务分布发生了显著漂移，需要重新校准 tokenization 预算

4. 方法论迁移价值评估

维度 Densing Law LLM Scaling Law (Chinchilla) 类比
核心变量 分词容量 V_min vs 数据规模 D 参数 N vs 数据 D ✅ 同构
斜率 α 反映表征空间冗余度/源内唯一性 反映任务复杂度 ✅ 同构
验证难度 需要私有工业数据 顶会/开源模型数据 ❌ 更难
跨领域迁移 未验证（本文单数据源） 多次跨团队验证 ❌ 差距大
工程可用性 中（方法论清晰，参数私有） 高（开源模型可直接套用） ❌ 差距大

结论：Densing Law 的方法论价值高于工程直接复用价值——"把分词容量纳入 scaling law 框架"这个思想可以借鉴到任何行为序列建模场景，但具体 α 数值和 ALGN 参数因数据私有而无法直接迁移。工程团队应把本文当作"提出了一个值得在自己数据上验证的假设"，而非"可直接部署的方案"。

⚠️ 精修注记

  1. 原稿"28 页 / 13 图 / 技术报告"与 abstract comments 完全吻合，标注 ✅。
  2. 原稿"对数线性关系"与 abstract "approximately linear relationship between the logarithms"完全吻合，标注 ✅。
  3. 原稿"ALGN 优于 baseline（无具体数字）"与 abstract 吻合，⚠️ 标注保留。
  4. 原稿"录取状态未明确"与 abstract 吻合（无 conference 引用），标注 ✅。
  5. 工程落地核查中补充了 V_min 测量协议不清晰这一重要工程坑点（原文未给出可操作化定义）。