2022 年 2 月 16 日 TFF 协作者会议笔记

  • 参与者：

    • Krzysztof Ostrowski (Google)
    • Alex Ingerman (Google)
    • DeWitt Clinton (Google)
    • Boyi Chen (LinkedIn)
    • Souvik Ghosh (LinkedIn)
    • Zheng Li (LinkedIn)

  • [chen] 我们目前的用法，贡献的兴趣领域，如何贡献的过程；未来开发计划

  • [boyi] 我们如今使用 FL 的方式

    • 两个部分 - 一个是跨数据孤岛
      • 我们用户的数据
      • 法律要求限制对数据的访问
      • FL 使用第三方数据非常方便
      • 可以在保持合规性的同时利用数据
    • 设备端 FL - 有趣，但主要以跨数据孤岛方式工作
    • 我们可以进行的一些项目
      • 一直在构建原型
      • TFF 能派上用场
      • 基准 FL 与个性化迁移学习
        • 使用客户端的数据为每个客户端训练个性化模型与迁移学习，比较
        • FL 工作方式的挑战
          • 一些客户端比其他客户端大 -> 偏差
          • 贡献最大的客户端担心搭便车的人；数据最少的客户端担心对模式的影响不足
        • 扩缩性挑战
          • 目前用于推断（数百 M）
          • 目前训练数据不是很大（10s-100sK/数据孤岛）
          • 在 O（数百 M）个客户端上批量运行推断
          • 总数据量为主要挑战
            • 所有客户端的记录
          • 集群大小现在受到限制，限制了推断速度
        • 客户端 = 不需要将数据与其他孤岛混合的孤岛。基数是什么？
          • 目前在进行实验，希望将来扩展到数百数千个数据孤岛
        • 您看到的 TFF 客户端的数量是多少？
          • 设备端：大量小型数据孤岛；x-silo 是少量的大型数据集
        • 数据孤岛的相似度如何？
          • 架构相同，但数据的分布在各个孤岛之间有很大不同。不平等参与
      • [K] 是否考虑将 TFF 用于推断和训练？
        • [B] 目前，用 TFF 进行训练；更愿意在同一框架上进行训练和推断。
        • [K] 相同的基础架构或相同的模型？
        • [b} 目前是相同的模型和相同的集群
      • [B] 想了解如何训练模型并部署到设备。
      • [S] 在一个环境中训练模型，在另一个环境中取出并使用的需求很重要。只是不适用于第一次应用。

  • [B] 我们要构建的内容：

    • 贡献的一个想法，我们对公平性进行基准测试后，就可以将工具和基准添加到 TFF
      • 模型如何跨数据孤岛（不平等的性能和偏差）
    • [K] 你认为这在实践中是个问题吗？ [B] 我们认为这在实践中会成为一个问题。
    • [B] 从对抗的角度考虑这个问题。人们会担心将数据放入盒中。这是一个普遍的问题，但我们没有特定的指标。
    • [K] 我们要解决什么问题？你说的是不是数据孤岛 + 关于如何处理它的规则的问题 - 但它不是对抗性的，只是不想创造偏差。另一种情况是有多个机构，各方互不信任。我们是在考虑其中之一还是两者都考虑？
    • [B] 两者都考虑；目前只考虑后者。
    • [D] 例如这里的数据孤岛是各个公司，数据集是每个公司上传的数据
    • [K] 你强调的是对不劳而获的担忧。但也有相互不信任的各方。各方是否希望阻止其他人/你查看数据？这些担忧处于紧张状态。一方面想验证贡献以防止攻击，另一方面出于隐私考虑不想让人看到内容
    • [B] 可以从两个方面来看。一个是隐私保护 - 通过 DP 等。另一方面，从模型性能的角度来看，当使用来自许多孤岛的数据进行训练时，人们会担心不同的孤岛受益不同。我们认为有一个标准的方法来处理前者；后者处理起来更加棘手。
    • [K] 模型性能良好方面的公平；另一个可能会不劳而获。后者与隐私关系更密切。你担心这个问题吗？
    • [B] 两者同等重要。既要保护数据隐私，又要以公平的方式分配利益。
    • [S] 我们还没有好的答案。[K] 一样。
    • [D] 这些公司在多大程度上信任 LinkedIn 来运营这个项目？
    • [S] 到目前为止，信任还不是问题，至少在我知道的例子中是这样。我们已经收到了一些约束请求，但没有直接拒绝。人们愿意为我们分享数据以构建共同价值。
    • [A] 只担心孤岛的隐私，还是孤岛中个人的隐私？
    • [S] 后者

  • [D] 这是在 Azure 上构建的吗？有没有需要考虑的其他部署事项？

    • [S] 最终会用到 GPU；初始模型将更小，需求更少。最终，这将涉及大量的成员和企业 → 模型将变得相当大。
    • [D] 这是否与公开可用的 Azure 相同？或者作为目标的一些内部基础架构，对外不可见。
    • [S] 相当标准的东西。
    • [D] 使协作更容易，使 OSS 代码更有价值，因为每个人都可以在公共 Azure 上运行。

  • [K] 让我们做事吧！这些应该是什么？我们提到了基准套件和跨数据孤岛平台。你对公开充实 PRD，谈论功能和用例怎么看？

    • [Z] 产品规格是什么样的？ TFF 中的小组件？
    • [k] 我们可以谈谈组件，或者可以构建以 TFF 为基础并可供其他人使用的产品。
    • [Z] 我想了解 - 这就是贡献过程吗？从产品开始？
    • [k] 我们正在这里制定流程。取决于你们觉得怎样舒服。
    • [Z] 您是否有此类产品的示例，可能在 TFF 之外但在 TF 中。
    • [K] TF 有一个设计文档的流程。我们可以开始将这些笔记转换成类似的东西。例如孤岛，相互不信任，想使用像 DP 这样的技术，需要在 Azure 上工作
    • [D] 有一个用例目录很有帮助，不会泄露信息
    • [K] 我们想开发一个路线图、文档和 TFF 中存在的用例示例，我们可以一起开始。如果从小处着手更容易，那么请务必这样做。
    • [B] 我看到很多关于 FL 挑战的研究。也许我们可以采用一些工具来解决这些挑战并以此为起点。例如，类似于搭便车、数据异质性 - 似乎是联合背景下的常见挑战。工具将普遍有用。
      • [K] 用于评估挑战的工具？或系统组件。
      • [B] TFF 可以提供的功能
      • [K] +1。从 PRD 开始为讨论功能提供了上下文，但我们也可以单独讨论功能。也许我们可以从描述不劳而获挑战并致力于开发处理工具。
      • [D] 我们还与研究人员合作。除了产品之外，LinkedIn 的目标是产出研究成果吗？
      • [Z] 短期内，还不以研究为目的。

  • [K] 听起来我们可以从一些共享文档开始，开始描述一些功能或组件？任何一方都可以发起。我们可以使用 Google Docs 和电子邮件。让其默认为公开。

  • [ostrowski] 我们想要构建什么，以及我们可以进行的具体的第一步是什么

    • 目标不只是另一次会议 - 面向我们自己的 AI？
    • 我们已经开始描述一些具体的产品/项目
      • 基准套件
      • 具有 DP、公平性、不劳而获保护的跨数据孤岛平台
    • 可能的后续步骤
      • 开始一个产品需求文档并针对上述每个内容公开对其进行充实？
      • 开始交流设计层面的想法？
      • 实际开发贡献的潜在计划？
        • 想要开发的特定组件/功能？
    • 要创建的特定工件：
      • 描述不劳而获问题的共享文档以及 TFF 中可以解决该问题的工具或功能的要求
      • 描述具有不相等数据量的孤岛的偏差基准的共享文档，我们希望基准衡量什么
      • 定义了一个新组件的共享文档，该组件将使 TFF 能够在基于 Azure 的环境中运行（需要与哪个层集成待定）

  • [ostrowski] 公开交流

    • （在 GitHub 登录页面上）公开哪些内容
    • 本次会议和后续会议的讨论和决定的摘要将在每次会议后的几天内发布在 GitHub 页面上
    • 指向工件的链接（任何要创建的计划、路线图、设计文档等）也将发布在 GitHub 上
    • 对话（聊天？）
      • Slack
    • 共同目标：
      • 范围内的特定产品/组件？
      • 建立一个更具体/范围更窄的工作组来支持这些工作的发展？

  • [B] 如何处理小的操作上的问题？

    • [K] Slack 或 GitHub 问题可以解决。哪个你用起来更高效？

  • [ostrowski] 我们可以共同保障的定期会议安排？

    • 每月