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)的更多可能性之類?！?/span>

Antirez 在開篇寫道，并直接拋出了結(jié)論：

總之，我得出的結(jié)論是：雖然目前的 AI 水平不錯、頗具實用性，但仍然遠遠落后于人類智能。我知道這是個很有爭議的結(jié)論，容易在網(wǎng)上挨噴，但……我的感受就是如此。

但即便如此：當前 AI 水平雖然實用且出色，卻仍與人類智能有著驚人差距。鑒于近來已無法進行理性討論，我認為有必要強調(diào)這一點。

并且他還給出自己使用 AI 的經(jīng)歷……

最近 Antirez 正在為 Redis 開發(fā) Vector Sets，打算修復(fù)一個復(fù)雜的 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ā)生以下情況：

1. 加載損壞的數(shù)據(jù)，該數(shù)據(jù)表明 A 鏈接到 B，但 B 不再鏈接到 A（節(jié)點 ID 損壞）。
2. 刪除掉節(jié)點 B：由于互換性發(fā)生違反，Antirez 和同事們不會清除從 A 到 B 的鏈接。
3. 之后在掃描該 graph 時，一旦到達 B 時就會遇到 A：釋放后重用……

因此在加載數(shù)據(jù)之后，Antirez 需要檢查每個鏈接是否互換。在一般情況下，結(jié)果應(yīng)該是 O(N^2)，代表著對于每個節(jié)點，開發(fā)人員需要掃描所有層級、在每個層級上掃描該節(jié)點的全部鄰居，再通過掃描該層級的鏈接來檢查其是否同樣鏈接至該節(jié)點。

“這顯然不好。盡管如此，在驗證自己思路的可行性過程中，Gemini 仍然發(fā)揮了重大作用。所以……我或許應(yīng)該把它當成一位‘足夠聰明的副手’看待，在討論中逐步摸索出更好的答案?！?/span>

開發(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 助手的原因：多行補全功能嚴重干擾了我的思路，尤其是當它提供看起來正確、實際錯誤的建議時。

為了判斷這些建議是否正確而停下來分析，會徹底打斷我的思路?！?/span>

還有開發(fā)者表示，大模型對其來說不是“橡皮鴨”，而是“錯誤答案”。

“我讓大模型做一些簡單但繁瑣的事，它卻錯得離譜。然后我被氣得不行，都有勁兒自己動手干了?！?/span>

如下是一些開發(fā)者對博客的評論：

在這里，碼哥也分享一個同事使用 AI 學(xué)習(xí) Redis 的經(jīng)歷。

張無劍居安思危，想系統(tǒng)化的學(xué)習(xí) Redis 技術(shù)，提高自己的競爭力。網(wǎng)絡(luò)上鋪天蓋地的宣傳 ChatGPT 強大，就計劃用 ChatGPT 來梭哈一把。

在詢問之前，張無劍花了很多時間研究如何更好的給出提示語，因為沒有好的提示語，ChatGPT 給出的答案可能有點智障。

張無劍再次絞盡腦汁想了一個提示語喂給 ChatGPT。

假如你是一個資深 Redis 7.0 技術(shù)培訓(xùn)老師，我是你的學(xué)生。我根據(jù)上文你列出的學(xué)習(xí)目標 “Redis 基礎(chǔ)入門”，學(xué)習(xí)內(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

張無劍遇到的問題在于以下幾點。

1. 無圖無真相，無法理解 List 底層有兩種數(shù)據(jù)結(jié)構(gòu)（Linkedlist、Ziplist）到底是啥樣的。
2. 無法理解為什么 List 要用兩種數(shù)據(jù)結(jié)構(gòu)（Linkedlist、Ziplist）保存數(shù)據(jù)。
3. 語言生硬，也就是從我們說的 AI 味太沖，學(xué)習(xí)本就是件痛苦的事情，在這樣的枯燥文字中還如何學(xué)得下去。
4. 最大的問題在于不知 ChatGPT 的回復(fù)到底是不是對的。
5. 還要花費大量時間來調(diào)教 ChatGPT 糾正錯誤，可本身自己是來學(xué)習(xí)的，如何做到糾正呢……

看到張無劍使用 ChatGPT 來學(xué)習(xí) Redis，快急死了。因為 ChatGPT 回復(fù)的內(nèi)容存在錯誤！再繼續(xù)學(xué)習(xí)下去的話怕是容易走火入魔！