正文
人类对大模型
Antirez 首先采用了最常规的办法，看看模糊测试器能不能找到 bug。结果确实有效，但加载一个包含 2000 万向量的大型向量集的时间从 45 秒变成了 90 秒左右。这当然不能接受，于是 Antirez 打开了 Gemini 2.5 PRO 的聊天窗口，问大模型：“我该怎么办？有没有速度更快的办法？”
Gemini 给出的最佳方案是：对相邻链接的指针进行排序，这样就能使用二分查找。
Antirez 认为这也有点道理……他知道可以这样，但不确定在拥有 16/32 个指针的数组中，这种方法是不是真的更快。所以 Antirez 问：“还有其他办法吗？”
很遗憾，Gemini 给不出更好的方案。所以，Antirez 告诉它：那咱们这样想，当我们在 X 层级上看到 A 链接到 B 时，会将其以 A:B:X 的形式将其存储在一个哈希表中（我们会始终对 A 和 B 进行排序，使得 A>B，因此无论方向如何链接均相同），而在再次看到该链接时就将其清除。这样我们只需要扫描整个表，类似于我们在将 ID 解析为链接中指针时所做的那样。如果最后该哈希表不为空，我们就能确定肯定存在着某个非互换链接。
Gemini 表示这确实是个好主意，虽然这需要使用 snprintf() 来创建键，而且哈希运算也需要时间等待……但已经比 Antirez 的方法（甚至包括对指针进行排序）要好。Antirez 则提醒 Gemini：其实这里不需要 snprintf()，可以直接 memcpy() 固定大小的键中的指针。Gemini 再次被说服。
之后，Antirez 告诉 Gemini：要不要对 A:B:X 使用一个固定大小的累加器？这甚至连哈希表都不需要。每当我们看到一条链接（A:B:X，也就是 8+8+4 个字节）时，我们就把它跟当前的 12 字节累加器进行异或运算，而如果存储两次，则结果抵消，因此最后如果寄存器非零，我们就可以判断是否出了问题！
Antirez 还预料到了 Gemini 可能提出的异议，并提前做好了回应——尽管 Redis 会默认关闭此功能，但一部分用户确实会需要启用这项额外检查来获得更强的保护，以防攻击者故意创建恶意负载。
Gemini 对这个想法印象深刻，但仍固执地提醒 Antirez：指针也拥有类似的结构、只是改变了几个 bit。所以如果有三条伪链接 L1、L2 和 L3，L1 和 L2 之间的异或运算结果有可能跟 L3 的 bit 相同，这样我们就会遇到漏报的问题（寄存器仍然为零）。Antirez 还想到，分配器往往非常容易预测，而且很可能被外部人士猜到。
Antirez 询问 Gemini 该如何改进这个问题，它还是没什么好主意。后来 Antirez 想，其实可以用一条质量够好且速度够快的哈希函数来做哈希处理，比如 murmur-128 之类（在这项任务中，不需要它具有加密属性），于是向 Gemini 提出了以下方案：
-
获取链接 A:B:X，但使用通过 /dev/urandom 获取的种子作为所有密钥的前缀，这样我们实际上就得到了 S:A:B:X。
-
只需将 murmur-128（S:A:B:X）的输出进行异或运算，放入 128 位寄存器即可。
-
最后，我们检查寄存器是否为 0（所有链接均互换）。
Antirez 要求 Gemini 对此进行分析，而它最终给出了极高的评价，认为这样大大降低了随机碰上异或恰好为 0 的孤立链接的可能性，而且外部攻击者也无法抓住这点乘虚而入——毕竟“S”未知，指针也需要控制，所有这些偶然因素很难都碰在一起。另外，这项功能只是一种锦上添花式的额外保护措施，默认关闭、需要用户主动开启，因此从实践角度看应该不会造成太大的性能损失。
Antirez 刚完成整个分析，就坐下来写了文章分享。
“我不确定自己会不会用上这套系统（很有可能会），但事实证明人类的创造力相较大模型仍有优势，因为我们能够真正打破常规、设想出一些奇特且并不精确、但就是更有成效的解法，而这对大模型来说则极其困难。”Antirez 说道。
