@jim9606

根据 Apple 的架构，CSMA 的数据要不然以图像的形式去给 Apple，要不然需要对方按照 Apple 的算法，不修改任何参数，生成 NeuralHash 。但这样的话，如果 Apple 更新了 NeuralHash 的计算方法，对方还是需要重算一次，比较麻烦。因此我觉得大概率 Apple 会直接要求图片，在此基础上应该还是会人工审查一遍图片的。特别是，你这个担忧也是一个非常主流且有意义的担忧，所以我觉得 Apple 大概率会更加小心。

当然，如果我们从心里就不信 Apple，那就像我说的一样，没啥好说的了。

关于 false positive，我觉得这里非常巧妙的一点就是 Apple 用了 threshold secret sharing 来控制概率。如果 threshold 设置的相对比较高，那么只要 NeuralHash 这个组件没有出大 bug，那么当某个账户被 flag 的时候，非常大概率这个账户确实是有问题的。误伤一次也就算了，误伤十次……

这里还有一个问题就是 false positive 的定义。可能 Apple 认为就算系统 flag 了，只要人工审查拦住了，没有直接把用户的 iCloud 封掉，就没什么问题。但是对于 Apple 这种公司，只要有人工介入，确实算是有点失败，换我做用户我心里也不舒服。

@Xs0ul

它之所以说是 hash，是因为它通过 locality-sensitive hashing，把提取出来的特征向量做了进一步处理。LSH 的性质就是，如果输入的值近似，那么输出的值相同。LSH 的数学我没接触过，完全不懂的，抽空我想去学习一下，但是维基百科上的 LSH 条目就是这么介绍的。

因此，Apple 训练这个网络的 objective 其实很简单：

- 近似的图片，输出的向量近似，minimize loss ； Apple 通过生成扰动的图像来做了 data augmentation 。
- 不同的图片，输出的向量尽可能不同，maximize loss 。

其实这个网络本身没什么「技术」含量，很标准的思路。

@lovestudykid

此处确实就只是用来匹配，神经网络是用来消除对图片的篡改的。

@jjxtrotter 根据 Apple 的描述，第三方直接给的图片，所以 Apple 应该是可以手工审查的，而且即使有漏网之鱼，人工审查匹配的用户的时候也是可以查出来的。但如果给图片是全自动加入系统、人工审查也是直接外包，那就难说了。但我觉得这两者若是能同时成立，那问题就海了去了，比如骗外包的团队拿到 Apple ID 权限？这种情况下，CSAM 反而不足为虑。

@oIMOo 如果能做到几十字节那几十万张图的话应该不到 100M ？ CNN 特征向量假设 512 字节，压缩个十倍也许还是可以做到的。

我之前看有人分析 iOS 系统大小，里面关于神经网络的越来越大了，还好存储空间长得也快。

我比较好奇的有两点，一个是如何动态的增加这个图库。现有的照片是不是还要再扫描一遍？二就是对 NeuralHash 的 hash 要如何设计，才能保证图片之间没有碰撞且尽可能稠密分布？或许 CSAM 本身可以分成几十份，但这样的话匹配的加密操作就要跑几十次了……

@felixcode 是的，所以说如果我是恐怖分子，我肯定不会用 iMessage 。

我个人的看法：我更关心商业公司会不会拿我的数据压榨我，以及黑客会不会拿我的数据敲诈勒索。

Apple 很好的处理了前者。而对于后者，Apple 作为一个把隐私挂在嘴边的公司，它有数据保护的意识，因此它的系统设计应该会让商业公司无意泄漏用户数据的情况变少。

同时，作为对立的一面，Apple 软件质量不好，比如说可能不如谷歌，会增加使用 Apple 系统泄露隐私的风险。

权衡利弊之下，我依然相信 Apple 能满足我对隐私的需求，并选择它的产品。至于每个人，都需要想清楚自己的需求。有必要的话，就学 Richard Stallman 好了。

@hello2066 这种思路就很迷。当然人可以选择不听，代码是苹果写的，苹果编译的，苹果发布的。理论上说苹果想推什么代码都行，iMessage 完全可以偷偷上传私钥，FBI 完全可能一边连根网线进苹果数据中心，一边和苹果演苦肉计。这都是有可能的，而且这一切不管苹果有没有做这套 CSAM 系统都有可能发生。

如果真的担心，且有必要担心，自然可以做出相应的决策，比如说云上贵州（美国法律可不保护中国公民不受 CIA 大规模筛查）。大家自行根据自己的屁股决定用不用 iPhone 、怎么用 iPhone 就好。

@kop1989 苹果并没有训练一个图片识别模型，这是一个非常单纯的图片匹配系统。

原来 V2EX 居然还有内容审查系统，本来加了几段评论不得不删除了……

@charlie21 那是你性能还不够高。Intel 单核要是跑到 20W （才叫性能释放）的话，40 核就要飞到 800W 了，而 Mac Pro 配超大杯 M1X 可能只需要 200W 。功耗能做下去，规模就能堆上来，对性能总归是好的。

@YsHaNg 我不懂 CPU，但我想如果多了一倍的 NEON 处理单元，会不会可以乱序执行达到类似的性能？

当然了，Apple 主要面向自己平台做优化，让所有人都用 Accelerate，把 BLAS 改出花，所以可能做自己的私有 ARM 扩展更划算。

@gemepio 是的，我之前测了编译公司的 iOS 项目，情况差不多

@GeruzoniAnsasu 其实你要看新的 iPad Pro 和 iMac 的宣传文案里面，跟各自上一代的提升，你就会发现卧槽原来库克之前说的 iPad 比 90%的电脑快不是在骗人

@linhongye 其实我觉得现在这个结果就已经很惊艳了，几乎是 1/2 的核心数还能勉强战平。只是这段时间刚好刷到一些知乎，看到很多人都在说 M1 只是靠专用电路，而且感觉很多测评确实只测硬编码，于是就想跑来自己看看，感受一下。

其实搜 V2，之前好像有人做过类似的测验，去年十一月。我同时也好奇这么久过去了，上游的库有没有对 M1 做更好的优化。

不是专业测试，甚至没怎么手压过片，随便测测玩玩。

@yzwduck 因为 Intel i9 是 8 核心 16 线程。16 线程的 usr time 加起来，比 8 线程的 usr time 加起来多是正常的，即使前者的 wall time 要少。

感谢。那是不是因为在这个工况下，实际计算电路负载高，超线程很难发挥作用，所以 usr time 就相对很少，远远没到两倍的差距？

@mikeven 我不是果黑，我只是想提前幻想一下 M1X 对我的老 i9 的巨大提升……

@zhs227
@longbye0 我是特意想看看软编码能力，想看看 M1X 能否有希望吊打 i9 。感觉硬编码质量实在很难接受。

@xgfan 测的时候女朋友在做饭还真没听到……不过抽烟机一关瞬间整个人就不好了。

@icyalala 用的是 x265 软编码，Intel 用的是 Homebrew 版本，M1 用的是 https://github.com/Vargol/ffmpeg-apple-arm64-build 。编码选项用的是 constant RF = 25 。

> 如果只用 CPU 编码的话，Intel 上能用到 AVX2 之类的 SIMD 加速，ARM 的 NEON 是比不上的。

我好奇的就是能不能比得上，我感觉好像已经很接近了。

插一句，有公网 IP 的话推荐直接在路由器上开个 Shadowsocks 。配合 Surge 这种可以自定义路由的工具，就可以实现在外面同时翻出去和翻回家，也不用担心不小心暴露 Web 服务器

@learningman iPhone 用户不懂提问一下：安卓就没有类似 iPhone 的那种信任此电脑的选项吗？还是说不信任就不给充电？