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

• 新人员

• 让我们在 Discord 服务器上以互动方式促进对话

  • Ping Krzys 需要成为贡献者才能发帖

• SIG Federated

• 关于跨孤岛中的搭便车和数据中毒的讨论，由 LinkedIn 引领的讨论（来自 LinkedIn 确定的用例的上下文，除非另有说明）：

  • 搭便车 - 某些租户没有为团体做出贡献，因此会稀释收益

    • 可能是有意或无意

    • 在此刻专注于无意的情况 - 这是我们在 LinkedIn 上最感兴趣的用例

    • 可能很简单，因为参与者的数据不足，或者数据在训练中未起作用

      • 目前正考虑将此建模为异常检测问题

      • 如果少数数据适合，则与多数贡献进行比较

      • 另一种方式：多个联合模型，在有或没有给定参与者贡献的情况下构建；观察哪些取得了进展，并据此排除参与者

    • 一些搭便车者可能会贡献垃圾数据

      • 难以建模为异常检测

      • 与上述方式相同

  • 中毒

    • 同样，可能是有意或无意

    • 专注于无意的情况 - 较大的租户可能会掌控小组并使模型偏向于他们的贡献

    • 对于感兴趣的场景，这与搭便车问题有相似之处

    • 分布式拜占庭训练中的相关技术

      • 例如，替代平均值，可以采用中位数来增加一些抗中毒的可靠性

  • 我们是否看到这些问题在其他地方发生，是否值得为生态系统贡献这样的逻辑？

    • 是的！在对抗设置中看到的常见问题，其中孤岛利益可能不一致（贡献会产生计算成本并需要资源）

  • 我们如何衡量空载或中毒的影响？

    • 按贡献与聚合 - 上述想法指向后者

  • 观察：TFF 的特性之一是可参数化和有状态聚合，可以维护自己的内部状态并在聚合时更新该状态。

    • 例如 federated_aggregate

  • 关于权衡以及与其他目标（例如 DP）的协同作用的思考

    • DP 绝对有助于中毒

    • 关于 DP 在空载上下文中的问题 – 仍然是一个未决问题

  • 我们发现数据中毒攻击的影响可忽略不计

    • 有关示例，请参阅 https://arxiv.org/pdf/2108.10241.pdf

    • 无论影响大小如何，务必提供这样的功能作为跨孤岛 FL 平台的一部分

• 写出有关上述更多详细信息的想法，以及尽快将组件从 LinkedIn 添加到 TFF 生态系统的提议

• 在 Discord 上查看更多讨论

• 两周后的下次会议