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 上查看更多讨论
两周后的下次会议