Redis之父：AI 水平不錯，但遠落后人類智能，開發者跟評：業界存在大量能力較弱的開發者，許多情況下，AI可以超越他們
Redis 之父 Salvatore Sanfilippo 近日分享了自己的一次研發經歷并直接表達了自己的觀點：人類程序員仍比大模型更出色。
“因為我們能夠真正打破常規、設想出一些奇特且并不精確、但就是更有成效的解法，而這對大模型來說則極其困難。”
Antirez 的分享迅速引發廣大開發者的激烈討論，博客地址：https://antirez.com/news/153
Antirez：AI 水平不錯，但遠落后人類智能
“今天我要分享一個人類為何仍比大語言模型更有優勢的小故事。
我并不反對 AI 或者類似的技術成果，持續關注我的朋友都知道。我經常用大模型，現在也一樣。
之所以會有這段故事，是因為我想測試自己的想法、進行代碼審查、看看 AI 會不會有比我更好的靈感、探索點專業范圍內的更多可能性之類。”
Antirez 在開篇寫道，并直接拋出了結論：
總之，我得出的結論是：雖然目前的 AI 水平不錯、頗具實用性，但仍然遠遠落后于人類智能。我知道這是個很有爭議的結論，容易在網上挨噴，但……我的感受就是如此。
但即便如此：當前 AI 水平雖然實用且出色，卻仍與人類智能有著驚人差距。鑒于近來已無法進行理性討論，我認為有必要強調這一點。
并且他還給出自己使用 AI 的經歷……
最近 Antirez 正在為 Redis 開發 Vector Sets，打算修復一個復雜的 bug：在離開 Redis 期間，Antirez 的同事們引入了防止數據校驗通過但 RDB 和 RESTORE 負載損壞的功能。
此功能會默認關閉，只是為需要的人多提供一層更強的安全保障。
但有一個比較大的問題：為了讓 HNSW 能夠快速保存到 Redis RDB 并加載回來，Antirez 序列化了 graph 表示，而非元素—向量對，否則就得把數據重新插入 HNSW，這會把速度拖慢 100 倍！總之，Antirez 將各節點與其他節點間的所有鏈接存儲成整數，然后把它們解析成指針。
這是個很實用的技巧，效果也不錯。然而，在將這種處理方法跟表示的隨機損壞、還有 Antirez 對于 HNSW 的改進結合起來，強制各節點間建立互換鏈接（Antirez 自己編寫了 HSNW 實現，其中包含許多有用的功能，但不少功能的實現都離不開互換鏈接）時，則可能發生以下情況：
- 加載損壞的數據，該數據表明 A 鏈接到 B，但 B 不再鏈接到 A（節點 ID 損壞）。
- 刪除掉節點 B：由于互換性發生違反，Antirez 和同事們不會清除從 A 到 B 的鏈接。
- 之后在掃描該 graph 時，一旦到達 B 時就會遇到 A：釋放后重用……
因此在加載數據之后，Antirez 需要檢查每個鏈接是否互換。在一般情況下，結果應該是 O(N^2)，代表著對于每個節點，開發人員需要掃描所有層級、在每個層級上掃描該節點的全部鄰居，再通過掃描該層級的鏈接來檢查其是否同樣鏈接至該節點。
“這顯然不好。盡管如此，在驗證自己思路的可行性過程中，Gemini 仍然發揮了重大作用。所以……我或許應該把它當成一位‘足夠聰明的副手’看待，在討論中逐步摸索出更好的答案。”
開發者：盲目自信的“AI 橡皮鴨”
“這與我的體驗相符。實際上，我覺得大模型助手對我來說很大一部分價值在于，它像一個有一定智能的‘橡皮鴨’一樣可以與我交流。
現在這個‘鴨子’偶爾還會提出異議，甚至有時還能幫我完善思路。”
小黃鴨調試（rubberducking）是一種通過用口頭或書面自然語言清晰描述問題來調試代碼的方法。
其名稱來源于《程序員修煉之道》中的一個故事，故事中程序員會隨身攜帶一只小黃鴨，強迫自己逐行向鴨子解釋代碼，以此來調試代碼。
“我也有過類似的想法”有其他開發者贊同道，“在結對編程時，有一個 AI 橡皮鴨可以讓你傾訴和交流想法會很棒（這樣你就不會在同事面前顯得很笨，也不會浪費他們的時間）。
”這個開發者做了一個支持自帶 API key 的 VSCode 插件，它使用了 OpenAI 的實時 API，可以和一個橡皮鴨進行互動式語音對話。
可以看出，一些開發者已經可以把大模型當編程助手看待，但這個助手仍然讓人“鬧心”。
“這是一只極其自信的鴨子，其自信程度與它的能力完全不成比例。
我已經看到太多的人因為與它交談而誤入歧途。”開發者 marcosdumay 指出。
有人跟貼贊同道，“這正是我很快關掉 JetBrains AI 助手的原因：多行補全功能嚴重干擾了我的思路，尤其是當它提供看起來正確、實際錯誤的建議時。
為了判斷這些建議是否正確而停下來分析，會徹底打斷我的思路。”
還有開發者表示，大模型對其來說不是“橡皮鴨”，而是“錯誤答案”。
“我讓大模型做一些簡單但繁瑣的事，它卻錯得離譜。然后我被氣得不行，都有勁兒自己動手干了。”
如下是一些開發者對博客的評論：
在這里，碼哥也分享一個同事使用 AI 學習 Redis 的經歷。
張無劍居安思危，想系統化的學習 Redis 技術，提高自己的競爭力。網絡上鋪天蓋地的宣傳 ChatGPT 強大，就計劃用 ChatGPT 來梭哈一把。
在詢問之前，張無劍花了很多時間研究如何更好的給出提示語，因為沒有好的提示語，ChatGPT 給出的答案可能有點智障。
張無劍再次絞盡腦汁想了一個提示語喂給 ChatGPT。
假如你是一個資深 Redis 7.0 技術培訓老師，我是你的學生。我根據上文你列出的學習目標 “Redis 基礎入門”，學習內容為“Redis 數據類型 List 底層實現原理和實戰技巧” ，我的目標是掌握這些數據類型的底層實現原理和實戰技巧，原理講解要深入一些，我的目標是成為 Redis 高手。
張無劍內心嘀咕道：這也太簡單了，看起來好像說明了底層原理，但就總覺得好像還不夠深入，只能大概了解 Redis 的 List 數據類型，根本成不了 Redis 高手，花了這么多時間，就這？？？
不要過度依賴 AI
張無劍遇到的問題在于以下幾點。
- 無圖無真相，無法理解 List 底層有兩種數據結構（Linkedlist、Ziplist）到底是啥樣的。
- 無法理解為什么 List 要用兩種數據結構（Linkedlist、Ziplist）保存數據。
- 語言生硬，也就是從我們說的 AI 味太沖，學習本就是件痛苦的事情，在這樣的枯燥文字中還如何學得下去。
- 最大的問題在于不知 ChatGPT 的回復到底是不是對的。
- 還要花費大量時間來調教 ChatGPT 糾正錯誤，可本身自己是來學習的，如何做到糾正呢……
看到張無劍使用 ChatGPT 來學習 Redis，快急死了。因為 ChatGPT 回復的內容存在錯誤！再繼續學習下去的話怕是容易走火入魔！
