有几个问题：

• 在服务器端投放广告的问题在于它们会处理有关用户的信息，因此可能会干扰他们的隐私，甚至在某些情况下会违反某些隐私法。

  将算法移动到客户端（例如移动应用程序）的建议解决了这个问题，但产生了相反的问题：现在您需要将有关添加的所有数据上传到客户端应用程序。这可能是有问题的，因为这可能会暴露您公司的公司机密（您的客户是谁，他们想向用户展示什么样的添加，广告的目标群体）。为广告付费的客户可能不喜欢它。您的竞争对手可能会滥用这一点来获得优于您的优势。

• 另一个问题是投放广告是为了将用户与广告相匹配。在客户端，您只能将广告与用户匹配。想象一下，您的客户向您支付了向用户展示 10K 广告的费用，如果您在用户端分配广告，您将无法直接控制展示 10K 广告，因此您可以通过展示未付费的广告来损失资金。当然，有一些方法可以解决这个问题，但这是一个需要考虑的问题。

  在现实生活中，这变得更加复杂，因为广告通常以投注的形式提供（谁支付更多，他们的广告就会被展示），不同的客户下注来制作广告，算法决定最佳份额，使其最大化展示广告的收益。在这种情况下，您不仅无法控制全局收益，因为您只做出本地优化决策，而且您需要将赌注发送到客户端应用程序，因此再次共享有关您的客户的敏感信息（多少他们是否为广告付费）。

• 第三件事是，即使客户端应用程序做出了决定，它可能仍然需要查询广告数据库来下载用户匹配的广告。我想，您可以对其进行反向工程，以了解算法分配给用户的广告的用户特征，因此最终，这可能无法保护隐私。

  作为替代方案，您可以将所有广告发送给用户并将它们存储在应用程序数据库中，但是您可能需要用户存储大量数据，以便您可以向他们展示您的广告。我怀疑用户会喜欢这个。

• 最后，我不确定广告销售企业是否最关心用户隐私，即他们是否会关心。

是的，这是可以做到的。

尽管如此，还是有一些方面需要考虑：

• 信息隔离：敏感信息应尽可能靠近其来源进行隔离，无论是对用户还是对广告提供商公司。因此，您不应将原始用户数据发送到服务器端，也不应将广告公司信息发送到客户端（请注意，此问题的其他答案似乎假设将隐私敏感计算移至设备意味着所有处理是在设备上完成的，但这不一定是真的）。您可以计算设备上的用户敏感部分，例如计算“用户表示”，然后将结果发送到服务器端，以完成其余的计算和广告分配。“用户代表”。

• 设备能耗：在设备上运行大量计算可能会导致电池消耗增加，这可能导致用户感知不佳，从而导致广告收入下降。

最后，可以更新 TFLite 模型。根据您使用 TFLite 的方式，您可以将模型托管在您的服务器上，如果设备上版本的时间戳比最后一个可用版本旧，您可以从客户端下载它，然后像往常一样加载模型文件。如果您使用 Firebase MLkit，它同样支持托管模型。