2022 年 7 月 28 日 TFF 协作者会议笔记

  • 新人员
  • 让我们在 Discord 服务器上以互动方式促进对话
    • Ping Krzys 需要成为贡献者才能发帖
  • SIG Federated
  • 关于跨孤岛中的搭便车和数据中毒的讨论，由 LinkedIn 引领的讨论（来自 LinkedIn 确定的用例的上下文，除非另有说明）：
    • 搭便车 - 某些租户没有为团体做出贡献，因此会稀释收益
      • 可能是有意或无意
      • 在此刻专注于无意的情况 - 这是我们在 LinkedIn 上最感兴趣的用例
      • 可能很简单，因为参与者的数据不足，或者数据在训练中未起作用
        • 目前正考虑将此建模为异常检测问题
        • 如果少数数据适合，则与多数贡献进行比较
        • 另一种方式：多个联合模型，在有或没有给定参与者贡献的情况下构建；观察哪些取得了进展，并据此排除参与者
      • 一些搭便车者可能会贡献垃圾数据
        • 难以建模为异常检测
        • 与上述方式相同
    • 中毒
      • 同样，可能是有意或无意
      • 专注于无意的情况 - 较大的租户可能会掌控小组并使模型偏向于他们的贡献
      • 对于感兴趣的场景，这与搭便车问题有相似之处
      • 分布式拜占庭训练中的相关技术
        • 例如，替代平均值，可以采用中位数来增加一些抗中毒的可靠性
    • 我们是否看到这些问题在其他地方发生，是否值得为生态系统贡献这样的逻辑？
      • 是的！在对抗设置中看到的常见问题，其中孤岛利益可能不一致（贡献会产生计算成本并需要资源）
    • 我们如何衡量空载或中毒的影响？
      • 按贡献与聚合 - 上述想法指向后者
    • 观察：TFF 的特性之一是可参数化和有状态聚合，可以维护自己的内部状态并在聚合时更新该状态。
    • 关于权衡以及与其他目标（例如 DP）的协同作用的思考
      • DP 绝对有助于中毒
      • 关于 DP 在空载上下文中的问题 – 仍然是一个未决问题
    • 我们发现数据中毒攻击的影响可忽略不计
  • 写出有关上述更多详细信息的想法，以及尽快将组件从 LinkedIn 添加到 TFF 生态系统的提议
  • 在 Discord 上查看更多讨论
  • 两周后的下次会议