這是一篇來自 Antirez（Redis 之父Salvatore Sanfilippo）的博文，分享給大家

人類程序員依然技高一籌：為什么說 AI 目前還差點(diǎn)火候

這篇短文，是想聊聊為什么我覺得咱們?nèi)祟惓绦騿T，比起現(xiàn)在大火的 LLM（大語言模型）還是要強(qiáng)太多。先聲明，我可不是什么 AI 反對(duì)者，了解我或者關(guān)注我動(dòng)態(tài)的朋友應(yīng)該都清楚。LLM 我經(jīng)常用，就像今天，我會(huì)用它來碰撞靈感、做代碼評(píng)審、看看有沒有比我最初構(gòu)想更好的方案、探索那些快要超出我知識(shí)邊界的領(lǐng)域，諸如此類吧。（大約兩年前，LLM 還沒那么流行的時(shí)候，我就寫過一篇關(guān)于用 LLM 輔助編程的博客：那時(shí)候我就已經(jīng)在用 LLM 寫代碼了，并且一直沒停過。這事兒我得抽空再寫篇更新，但今天的主題不是這個(gè)。）

但是，話說回來：眼下 AI 的水平，確實(shí)有用，也相當(dāng)不錯(cuò)，可要跟人類智能相比，那還差得遠(yuǎn)呢。我特別想強(qiáng)調(diào)這一點(diǎn)，因?yàn)榻鼇硐刖瓦@個(gè)問題進(jìn)行平衡的討論都很難，輿論往往一邊倒。

話說今天，我正在為 Redis 的向量集（Vector Sets）功能修復(fù)一個(gè)特別復(fù)雜的缺陷：在我離開 Redis 開發(fā)的那段時(shí)間里，我的同事們?yōu)?RDB 和 RESTORE 的數(shù)據(jù)引入了一種防損壞機(jī)制，即便數(shù)據(jù)的校驗(yàn)和通過了，這個(gè)機(jī)制也會(huì)生效。這個(gè)功能默認(rèn)是關(guān)閉的，但為有需求的用戶提供了一個(gè)增強(qiáng)的安全層。

但……這里有個(gè)巨大的隱患：為了讓 HNSW（分層可導(dǎo)航小世界圖）能夠快速地存入 Redis RDB 并加載回來，我序列化的是整個(gè)圖結(jié)構(gòu)本身，而不是單個(gè)的“元素-向量”對(duì)。否則的話，我得把數(shù)據(jù)重新插入到 HNSW 中，那樣速度會(huì)慢上大概 100 倍（沒錯(cuò)，就是這么多！）。所以我把節(jié)點(diǎn)之間所有的連接關(guān)系都以整數(shù)形式存儲(chǔ)，然后在加載時(shí)再將它們解析成指針。這個(gè)技巧很巧妙，效果也非常好。可如果你把這套機(jī)制，跟數(shù)據(jù)表示層面可能出現(xiàn)的隨機(jī)損壞，再加上我自己對(duì) HNSW 的一點(diǎn)改進(jìn)——強(qiáng)制節(jié)點(diǎn)間的連接必須是雙向的（我自己實(shí)現(xiàn)了一套 HNSW，加入了不少實(shí)用特性，而雙向連接是啟用其中許多特性的基礎(chǔ)）——這些因素結(jié)合起來，就可能出現(xiàn)以下情況：

1. 我們加載了一份已損壞的數(shù)據(jù)，數(shù)據(jù)顯示 A 鏈接到 B，但 B 已經(jīng)不再鏈接回 A（因?yàn)楣?jié)點(diǎn) ID 損壞了）。
2. 我們刪除了節(jié)點(diǎn) B：由于雙向性被破壞，從 A 到 B 的鏈接并沒有被清除。
3. 然后當(dāng)我們掃描圖結(jié)構(gòu)，訪問到 B 時(shí)，試圖去訪問 A：好了，use-after-free（懸垂指針訪問）發(fā)生了！:-D :-) :-|

所以，數(shù)據(jù)加載完成后，我需要檢查每一個(gè)鏈接是否都是雙向的。如果用最直接的方法，復(fù)雜度會(huì)是 O(N^2)——對(duì)于每個(gè)節(jié)點(diǎn)，都需要遍歷其所有層級(jí)，在每個(gè)層級(jí)遍歷其所有鄰居節(jié)點(diǎn)，并且還要反過來檢查該鄰居節(jié)點(diǎn)在這一層級(jí)是否也鏈接回當(dāng)前節(jié)點(diǎn)。這效率太低了，行不通。

人類 vs LLM

起初，我按照常規(guī)方法實(shí)現(xiàn)了這個(gè)檢查，想看看模糊測(cè)試工具（fuzzer）是否還會(huì)發(fā)現(xiàn)那個(gè)缺陷。結(jié)果確實(shí)沒再出現(xiàn)，但是，一個(gè)包含 2000 萬個(gè)向量的大型向量集，加載時(shí)間從 45 秒一下子增加到了 90 秒左右。太坑了！于是我趕緊打開一個(gè) Gemini 2.5 PRO 的聊天窗口，問它：“老兄，這情況有什么好辦法嗎？有沒有什么超快的解決方案？”

Gemini 能給出的最佳方案是：對(duì)鄰居鏈接的指針進(jìn)行排序，這樣就可以使用二分查找了。嗯，好吧，這個(gè)方法我懂，但我不太確定在一個(gè)只有 16 或 32 個(gè)指針的數(shù)組里，這樣做到底是更快還是更慢。我又追問：“還有其他方案嗎？” 回答：“沒有更好的了。”

于是我跟它說：你看這樣如何？當(dāng)我們發(fā)現(xiàn) A 在 X 層鏈接到 B 時(shí)，我們把 A:B:X 存入一個(gè)哈希表（但我們總是對(duì) A 和 B 進(jìn)行排序，使得 A>B，這樣無論鏈接方向如何，其表示都是一致的）。當(dāng)我們?cè)俅斡龅竭@個(gè)鏈接時(shí)，就把它從哈希表中移除。這一次，我們就像之前解析 ID 到指針的鏈接時(shí)那樣，完整地掃描整個(gè)圖結(jié)構(gòu)。如果最后哈希表不為空，那就說明肯定存在非雙向的鏈接，對(duì)吧？

Gemini 表示這是個(gè)不錯(cuò)的主意，但指出使用 snprintf() 生成鍵以及哈希運(yùn)算本身會(huì)耗費(fèi)時(shí)間，不過，它也承認(rèn)這確實(shí)比我最初的方法（即使是排序指針的版本）要好。我提醒它，snprintf() 并非必需。我們可以直接用 memcpy() 將指針復(fù)制到一個(gè)固定大小的鍵中。它認(rèn)可了這種做法的可行性，然后，我突然有了個(gè)新想法……

我跟 Gemini 說，我們能不能用一個(gè)固定大小的累加器來處理 A:B:X 呢？完全不需要哈希表。每次我們遇到一個(gè)鏈接（A:B:X，也就是 8+8+4 字節(jié)），就把它與當(dāng)前一個(gè) 12 字節(jié)的累加器進(jìn)行異或（XOR）運(yùn)算。如果一個(gè)鏈接出現(xiàn)兩次，兩次異或操作就會(huì)相互抵消。所以，最后如果累加器的值不為零，我們就知道數(shù)據(jù)有問題了！不過，我預(yù)先跟 Gemini 指出，這個(gè)系統(tǒng)可能存在沖突（collision）的風(fēng)險(xiǎn)，需要進(jìn)行評(píng)估。即使這個(gè)功能在 Redis 中通常是關(guān)閉的，但當(dāng)用戶啟用這種額外的檢查時(shí)，他們通常也期望能獲得更多保護(hù)，以防止攻擊者故意構(gòu)造惡意的負(fù)載。

Gemini 對(duì)這個(gè)想法印象相當(dāng)深刻，但仍然指出，指針這種東西……你知道，它們的結(jié)構(gòu)都很相似，只在少數(shù)幾個(gè)比特位上有差異。所以，如果恰好出現(xiàn)了三個(gè)偽造的鏈接 L1、L2、L3，有可能 L1 和 L2 異或的結(jié)果正好與 L3 的比特位相同，這樣我們就可能得到一個(gè)假陰性（即累加器為零，但實(shí)際上存在問題）。我還注意到，內(nèi)存分配器的行為往往非常具有可預(yù)測(cè)性，并且容易被外部猜測(cè)到。

我讓 Gemini 幫忙想辦法改進(jìn)這個(gè)方案：它沒能提出什么特別好的主意。然后我想，等等，我們實(shí)際上可以用一個(gè)足夠好并且速度仍然很快的哈希函數(shù)來處理它，比如 murmur-128 或類似的算法（這個(gè)任務(wù)并不要求它具備密碼學(xué)級(jí)別的安全性），然后我向 Gemini 提出了以下方案：

1. 取鏈接 A:B:X，但使用一個(gè)通過 /dev/urandom 獲取的種子 S 作為所有鍵的前綴，所以我們實(shí)際處理的是 S:A:B:X。
2. 我們將 murmur-128(S:A:B:X) 的輸出與一個(gè) 128 位的寄存器進(jìn)行異或操作。
3. 最后，檢查該寄存器是否為 0（如果為 0，則表示所有鏈接都是雙向的）。

我讓 Gemini 對(duì)這個(gè)方案進(jìn)行分析，它最終表示滿意，說這樣做會(huì)使得無論是偶然發(fā)現(xiàn)幾個(gè)恰好異或結(jié)果為 0 的孤立鏈接，還是外部攻擊者想利用這一點(diǎn)進(jìn)行有效攻擊，都變得困難得多。因?yàn)椤癝”是未知的，攻擊者還需要同時(shí)控制指針，所有這些因素組合起來非常難以實(shí)現(xiàn)。此外，這個(gè)功能本身就是一種盡力而為的額外保護(hù)措施，需要用戶手動(dòng)啟用，它通常是關(guān)閉狀態(tài)，并且為了保證實(shí)用性，它不應(yīng)該帶來過大的性能開銷。

代價(jià)

嗯，說了這么多，其實(shí)就是想表達(dá)：我剛剛完成了分析，就停下來寫這篇博客了。我不確定最終是否會(huì)采用這個(gè)系統(tǒng)（但可能性很大），但是，人類的創(chuàng)造力依然占據(jù)著優(yōu)勢(shì)。我們能夠真正地跳出固有思維模式，構(gòu)想出那些看似奇特和不那么精確，但實(shí)際上卻能比其他方案更好地解決問題的辦法。這種能力，對(duì)于 LLM 來說是極其困難的。當(dāng)然，在驗(yàn)證我所有想法的過程中，Gemini 還是非常有用的，或許我之所以能從這些角度思考問題，也是因?yàn)槲矣幸粋€(gè)“聰明的橡皮鴨”（指可以與之對(duì)話并梳理思路的對(duì)象）可以交流吧。

source：

https://www.antirez.com/news/153