xkcd 有多随机？（2015）

原文 ↗ Hacker News 讨论 ↗

对 xkcd“随机漫画”按钮的抱怨，凸显了数学上正确的随机性与用户在按下“random”或“shuffle”时所期待的行为之间的广泛差距。评论者将独立随机抽样（自然会产生连串和重复）与像牌堆一样的洗牌（每个项目只循环一次）作对比，并分享了来自音乐播放器、电子游戏和应用程序的类似经历：这些产品会悄悄偏置算法，让它们“感觉”更公平或更新鲜。另一些人则深入讨论统计检验套件、RNG 质量，以及 NIST STS 和 TestU01 等众所周知的系统，指出人类直觉和有缺陷的工具都会让判断真正的随机性变得出人意料地棘手。

随机性 vs 感知到的公平性

  • 许多评论者指出，抱怨 XKCD “随机”按钮的用户其实想要的是新鲜感，而不是数学意义上的随机。
  • 人们在非正式情况下期待的是“有放回的随机”之外的“无放回随机”：在看到所有项目之前不要重复，或者至少明显偏向尚未见过的项目。
  • 人类对模式的寻找会让真正的随机在出现连串或重复时显得“不对劲”；这被拿来与赌徒谬误和其他众所周知的直觉作比较。
  • 一些人认为设计者应该优化用户期望，而不是概率论的纯粹性；另一些人则主张即使用户误解，也应保持技术上的正确性。

媒体和 UX 中的随机 vs 洗牌

  • 讨论中有一条很强的主线是“随机抽样”与“随机洗牌”的区别：
    • 抽样：每次都从全集中均匀选择，允许重复。
    • 洗牌：生成一个随机排列，然后完整播放一遍。
  • 音乐播放器（Spotify、iPod、CD/MP3 播放器）的用户报告频繁重复和“总是卡在喜欢的歌上”，认为这属于故障。
  • 建议包括：
    • 跟踪每个用户的历史，并排除或降低最近见过的项目权重。
    • 使用加权或结构化算法（分块、艺术家/节奏间距、保持格式的加密技巧）。
  • 有些人坚持“洗牌应该像一副扑克牌”，另一些人则希望偏向“很久没听过的歌”。

游戏设计与有偏随机性

  • 讨论提到会调整随机性以“感觉公平”的策略和 RPG 游戏，例如：
    • 使用基于袋子的随机器来限制 Tetris 中的洪泛/干旱。
    • 用“Karmic dice”来补偿最近的连串结果。
  • 关于玩家是否“非理性”，还是过于简单的概率模型忽略了相关上下文（大规模战斗、多次命中等）的争论。

统计讨论与测试

  • 对“几乎和 0 一样多的 1”这句话的澄清：
    • 比例会趋近于 50/50；绝对差通常按 √n 增长。
  • 提到生日悖论和优惠券收集者问题，以解释随机情况下重复漫画以及看全所有漫画的困难。
  • 一些评论者进行了实验：
    • 将 /dev/urandom 映射到 XKCD 索引范围：计数聚集在期望频率附近。
    • 将 XKCD 的随机 ID 输入 NIST STS：出现 segfault，且至少一个测试（FFT）失败，凸显了工具本身的脆弱性以及比特流中的非平凡结构。
  • 提到 NIST STS 和 DIEHARD 被认为较旧；TESTU01 被引为更现代的工具。

XKCD 的具体实现说明

  • XKCD 的随机功能按设计不能返回第 404 号漫画。
  • 多位评论者建议为每个用户维护一副洗牌后的漫画 ID 牌堆（用 cookies 或本地存储），作为一种折中方案，不过也提到了跟踪隐私方面的担忧。
  • 也有人开玩笑提到 XKCD 自己关于“4”的随机数笑话，以及针对某些 referrer 故意表现出非随机行为。