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