【CSDN 編者按】新年伊始，在各位大佬進(jìn)行年終總結(jié)之時(shí)，近日 Redis 之父 antirez 也發(fā)布了他今年的第一篇博文：“2024 年初，聊聊 LLM 和編程”。不同于預(yù)想之中的盤點(diǎn)和回顧，這篇文章 antirez 以一位獨(dú)立開發(fā)者的角度，分享了他這一年來對(duì)于 AI 的使用感受，并表示：“就我個(gè)人而言，我將繼續(xù)廣泛使用LLM。”
作
者 | antirez，
Redis 作者
翻譯 | ChatGPT責(zé)編| 鄭麗媛
出品 | CSDN（ID：CSDNnews）
2023 年對(duì) AI 而言是特殊的一年，這毫無疑問。首先我聲明一下，本文并非是對(duì) LLM（大型語言模型）過去一年的回顧，而是以一位獨(dú)立程序員的身份聊聊我對(duì) AI 的見證。自 ChatGPT 問世以來，以及后來使用在本地運(yùn)行的 LLM，我已將這項(xiàng)新技術(shù)廣泛應(yīng)用。從個(gè)人角度來說，我使用大模型一方面是為了提升編程速度，另一方面也是希望不再浪費(fèi)精力在不值得努力的編程方面。
例如，我曾花了無數(shù)個(gè)小時(shí)搜索那些奇特卻無趣的技術(shù)文檔、曾被迫學(xué)習(xí)過于復(fù)雜的 API、曾編寫過一些幾個(gè)小時(shí)后就被丟棄的程序……這些都是我不想做的事情，尤其現(xiàn)在谷歌搜索引擎也已淪為垃圾信息的海洋，我得費(fèi)心篩選才能找到一些有用的東西。
與此同時(shí)，我在編程方面當(dāng)然不是新手。我可以在沒有任何輔助工具的情況下編寫代碼，并且也經(jīng)常這么做。但隨著時(shí)間的推移，我開始越來越多地用 LLM 來編寫高級(jí)代碼，尤其是在 Python 中，在 C 語言中則較少。在對(duì) LLM 頻繁使用的過程中，我逐漸知道了什么情況該使用它們、什么情況使用它們只會(huì)拖慢速度。
除此之外，我還了解到，LLM 其實(shí)有點(diǎn)像維基百科和 YouTube 上的各種視頻課程：對(duì)于本身就有意愿、有能力和有紀(jì)律的人，有了 LLM 的幫助幾乎如虎添翼；而對(duì)于那些本就不太上進(jìn)、拖后腿的人，強(qiáng)大如 LLM 也幫不了他們。因此我擔(dān)心，至少就現(xiàn)階段而言，LLM 只會(huì)讓本就優(yōu)秀的人變得更優(yōu)秀。
但是，讓我們一步一步來。
全知全能還是鸚鵡學(xué)舌？
在這波機(jī)器學(xué)習(xí)的新潮中，最令人擔(dān)憂的現(xiàn)象之一是 AI 專家對(duì)于 LLM 的認(rèn)知也較為有限。偉人發(fā)明了神經(jīng)網(wǎng)絡(luò)，甚至還發(fā)明了自動(dòng)優(yōu)化神經(jīng)網(wǎng)絡(luò)參數(shù)的算法，而硬件能訓(xùn)練越來越大的模型，利用對(duì)要處理數(shù)據(jù)的統(tǒng)計(jì)知識(shí)（先驗(yàn)）以及大量試錯(cuò)來逼近最佳結(jié)果，人們發(fā)現(xiàn)了比其他方法更有效的架構(gòu)。但總體而言，神經(jīng)網(wǎng)絡(luò)仍然相當(dāng)不透明。
由于無法解釋 LLM 為何會(huì)出現(xiàn)某些新功能，許多人推測(cè)科學(xué)家們會(huì)更加謹(jǐn)慎。但另一方面，還有部分人嚴(yán)重低估 LLM，認(rèn)為它們充其量只是略為先進(jìn)的馬爾可夫鏈，最多只能重復(fù)在訓(xùn)練集中看到的極其有限的變化。不過后來在面對(duì)證據(jù)時(shí)，這種“鸚鵡學(xué)舌”的說法幾乎被推翻。
與此同時(shí)，還有許多熱心群眾將現(xiàn)實(shí)中并不存在的超自然力量也歸因于 LLM而實(shí)際情況是，LLM 最多只能對(duì)自己在訓(xùn)練期間接觸過的數(shù)據(jù)表示空間中進(jìn)行插值，這早已不是什么新鮮事。另外值得一提的是，LLM 的插值能力也很有限，如果某個(gè) LLM 能夠在其接觸過的所有代碼所限定的空間內(nèi)連續(xù)插值，即使它做不到真正的創(chuàng)新，也能夠取代 99% 的程序員了。
好在實(shí)際情況并非如此。LLM 確實(shí)能編寫出自己從未見過的程序，并以一定頻率將訓(xùn)練集中出現(xiàn)的不同想法巧妙融合，但這種能力的局限性也很大：每當(dāng)需要微妙的推理時(shí)，LLM 就會(huì)慘遭失敗。不過話說回來，LLM 仍代表了 AI 誕生至今的最大成就，這沒什么好否認(rèn)的。
愚蠢，但無所不知
有個(gè)事實(shí)我們需要明確：LLM 最多只能進(jìn)行最基本的推理，且往往不準(zhǔn)確，還經(jīng)常夾雜著一些不存在事實(shí)的幻覺，但它們確實(shí)知識(shí)淵博。在編程領(lǐng)域以及其他有高質(zhì)量數(shù)據(jù)的領(lǐng)域，LLM 就像愚蠢的天才，知道很多事情。
與這樣的搭檔進(jìn)行結(jié)對(duì)編程非常麻煩（對(duì)我而言，結(jié)對(duì)編程這件事本身就很麻煩）：它們會(huì)有一些荒謬的想法，我們則必須不斷地將自己的想法強(qiáng)加于它。當(dāng)然，如果這個(gè)博學(xué)的“傻瓜”可以為我們所用，回答我們向它提出的所有問題，那情況就大不相同了�，F(xiàn)有的 LLM 可能還無法跨越知識(shí)的鴻溝，但如果我們想處理一個(gè)不太了解的主題，那 LLM 可以讓我們從絕對(duì)無知的狀態(tài)中解脫出來，讓我們了解到足夠的知識(shí)從而獨(dú)立前行。
在編程領(lǐng)域，也許是二三十年前，人們對(duì) LLM 的能力興趣并不大。那時(shí)，你必須掌握幾種編程語言、經(jīng)典算法和十個(gè)基本庫。剩下的就得靠自己了，靠自己的智慧、專業(yè)知識(shí)和設(shè)計(jì)技能。如果你具備了這些要素，你就是一個(gè)熟練的程序員，幾乎能做所有的事情。隨著時(shí)間的推移，我們目睹了框架、編程語言和各類庫的爆炸式增長，雖然這種復(fù)雜性的爆炸增長往往是完全不必要和不合理的，但事實(shí)就是事實(shí)。在這種情況下，一個(gè)博學(xué)的“傻瓜”就是一位寶貴盟友。
我舉個(gè)例子：我對(duì)機(jī)器學(xué)習(xí)的實(shí)驗(yàn)至少進(jìn)行了一年，一直在使用 Keras，后來出于各種原因，我轉(zhuǎn)到了 PyTorch。我已經(jīng)知道嵌入或殘差網(wǎng)絡(luò)是什么，但我不想一步一步地學(xué)習(xí) PyTorch 文檔（就像我學(xué)習(xí) Keras 時(shí)那樣，當(dāng)時(shí)還沒有 ChatGPT）。而有了 LLM 后，編寫使用 Torch 的 Python 代碼就變得非常容易了，我只需對(duì)我想要組合的模型有清晰的想法，并提出正確的問題即可。
舉例說明
我不是在談?wù)撓?ldquo;嘿，X 類中執(zhí)行 Y 的方法是什么？”這樣的簡單問題，這樣我可能會(huì)同意那些對(duì) LLM 持懷疑態(tài)度的人的觀點(diǎn)。事實(shí)證明，更復(fù)雜的模型所能做的事情要精細(xì)得多。我可以告訴 GPT4：看，這是我在 PyTorch 中實(shí)現(xiàn)的神經(jīng)網(wǎng)絡(luò)模型，這是我的批處理數(shù)據(jù)，我想調(diào)整張量的大小，使輸出批次的函數(shù)與神經(jīng)網(wǎng)絡(luò)的輸入相匹配，我想用這種特殊的方式來表示事物。你能給我展示進(jìn)行重塑所需的代碼嗎？然后，GPT4 編寫了代碼，而我只需要在 Python CLI 中測(cè)試張量是否真的具有我需要的維度，以及數(shù)據(jù)布局是否正確。
還有一個(gè)例子。前段時(shí)間，我不得不為某些基于 ESP32 的設(shè)備實(shí)現(xiàn)一個(gè) BLE 客戶端。經(jīng)過研究后，我發(fā)現(xiàn)多平臺(tái)藍(lán)牙編程綁定或多或少都無法使用。解決方案很簡單，使用 MacOS 的本地 API 用 Objective C 編寫代碼。于是，我不得不同時(shí)處理兩個(gè)問題：學(xué)習(xí) Objective C 繁瑣的 BLE API，同時(shí)還要記起如何在 Objective C 中編程我上一次用 Objective C 寫程序是十年前，根本不記得事件循環(huán)、內(nèi)存管理等許多細(xì)節(jié)。
然而在 LLM 的幫助下，我用極短的時(shí)間就寫完了代碼。最終的代碼是這樣的，雖然不算美觀，但至少能完成任務(wù)：
https://github.com/antirez/freakwan/blob/main/osx-bte-cli/SerialBTE.m
代碼主要是通過在 ChatGPT 上剪切粘貼我想要做的事情來編寫的，由于剛開始我不太了解如何做，最初生成的代碼沒法正常運(yùn)行，但我可以讓 LLM 向我解釋問題所在以及如何解決它。如果沒有 ChatGPT，我能做得到嗎？當(dāng)然可以，但這不僅浪費(fèi)了我的時(shí)間，我可能根本也不會(huì)去嘗試，因?yàn)檫@不值得：編寫這樣一個(gè)對(duì)我的項(xiàng)目來說次要的程序，其付出和收益之間的比例并不可觀。
最后還有一個(gè)例子，與代碼編寫無關(guān)，而是與數(shù)據(jù)解釋有關(guān)。當(dāng)時(shí)，我想建立一個(gè)用我在網(wǎng)上找到的卷積神經(jīng)網(wǎng)絡(luò)的 Python 腳本，但文檔相當(dāng)缺乏。這個(gè)網(wǎng)絡(luò)的優(yōu)勢(shì)在于它采用 ONNX 格式，因此我可以輕松提取輸入和輸出列表以及它們分配名稱的列表。我只知道這個(gè)卷積神經(jīng)網(wǎng)絡(luò)能檢測(cè)圖像中的某些特征，但輸入圖像的格式和大小及輸出的復(fù)雜度我都不太了解。
我首先將 ONNX 網(wǎng)絡(luò)元數(shù)據(jù)的輸出復(fù)制粘貼到 ChatGPT 中，并同步了我對(duì)該網(wǎng)絡(luò)的一點(diǎn)了解。然后，ChatGPT 假設(shè)輸入的組織方式，輸出可能是表示圖像中與潛在缺陷相對(duì)應(yīng)部分的歸一化方框等。經(jīng)過幾分鐘的來回討論后，我得到了一個(gè)能進(jìn)行網(wǎng)絡(luò)推理的 Python 腳本以及將起始圖像轉(zhuǎn)換為適合輸入的張量所需的代碼等等。
一次性程序
上述類似的例子還有很多，我在這里就不一一贅述了，基本上都是同樣的情況和結(jié)果。除此之外，我還經(jīng)常遇到另一類情況：想迅速了解某些可以快速驗(yàn)證的東西。在這種情況下，我就會(huì)用 LLM 來加快我對(duì)知識(shí)的需求。
不過，在不同的情況下，我也會(huì)讓 LLM 編寫所有代碼。例如，當(dāng)我需要編寫一個(gè)一次性的程序時(shí)，比如這個(gè)：
https://github.com/antirez/simple-language-model/blob/main/plot.py
我需要可視化一個(gè)小型神經(jīng)網(wǎng)絡(luò)學(xué)習(xí)過程中的損失曲線。我向 GPT4 展示了 PyTorch 程序在學(xué)習(xí)過程中生成的 CSV 文件格式，然后我要求，如果我在命令行中指定了多個(gè) CSV 文件，我就不再需要相同實(shí)驗(yàn)的訓(xùn)練和驗(yàn)證損失曲線，而是要比較不同實(shí)驗(yàn)的驗(yàn)證損失曲線。以上結(jié)果就是 GPT4 生成的結(jié)果，總共耗時(shí) 30 秒。
同樣，我需要一個(gè)程序來讀取 AirBnB 的 CSV 報(bào)告，并按月份和年份進(jìn)行分組。然后，考慮清潔費(fèi)用和每次預(yù)訂的住宿天數(shù)，它將統(tǒng)計(jì)出一年中不同月份的平均租金價(jià)格。這個(gè)程序?qū)ξ襾碚f非常有用，但編寫它也非常無聊：沒有任何有趣的東西。因此，我從 CSV 文件中截取了一小部分，并在 GPT4 上進(jìn)行了剪切粘貼，然后給 LLM 寫了要解決的問題，其生成的程序一次就成功了，以下，我將展示完整代碼：
python
import pandas as pd
pd.set_option('display.max_rows', None)
df = pd.read_csv('listings.csv')
reservations = df[df['Type'] == 'Reservation']
reservations['
Start
Date
'] = pd.to_datetime(reservations['
Start
Date
'])
reservations['
Year
'] = reservations['
Start
Date
'].dt.year
reservations['
Month
'] = reservations['
Start
Date
'].dt.month
reservations['Nightly Rate
'] = (reservations['Amount
'] - reservations['Cleaning Fee
']) / reservations['Nights
']
all_listings = reservations['Listing
'].unique()
all_years = reservations['
Year
'].unique()
all_months = range(1, 13)
index = pd.MultiIndex.from_product([all_listings, all_years, all_months], names=['Listing
', '
Year
', '
Month
'])
all_data = pd.DataFrame(index=index).reset_index()
merged_data = pd.merge(all_data, reservations, on=['Listing
', '
Year
', '
Month
'], how='
left
')
average_nightly_rates = merged_data.groupby(['Listing
', '
Year
', '
Month
'])['Nightly Rate
'].mean().fillna(0)
print(average_nightly_rates)
要準(zhǔn)確理解如何對(duì)數(shù)據(jù)進(jìn)行分組，且這些數(shù)據(jù)本來就相當(dāng)分散和無序，需要一些簡單的推理：這不是一個(gè) LLM 簡單地重復(fù)一些它所見過的語言可以解決的問題。GPT4 在訓(xùn)練過程中可能接觸過類似程序，但與我所要求的提示條件必定有所不同，但它依舊能寫出符合的程序代碼。在我看來，這表明 LLM 能在一定程度上對(duì)訓(xùn)練集中各種程序描繪的空間內(nèi)進(jìn)行插值。
在我看來，編寫這種程序只會(huì)浪費(fèi)我的時(shí)間，而 LLM 可以為我代勞，這無疑直接加速了我編寫代碼的能力：我可以專注于真正重要的事情。
當(dāng)LLM不盡如人意時(shí)：系統(tǒng)編程
盡管我在使用 LLM 和編程方面取得了成功，但當(dāng)我編寫 C 語言程序時(shí)，我?guī)缀蹩偸前?LLM 僅用作一種更方便的文檔形式。我是系統(tǒng)編程專家，在這種情況下，只有當(dāng) LLM 能夠進(jìn)行復(fù)雜推理時(shí)才會(huì)對(duì)我有用：然而在這種場景中，它們幾乎總是失敗的。
讓我們從這個(gè)實(shí)驗(yàn)的提示開始：
概述一個(gè)漂亮、小巧但可行的 C 語言實(shí)現(xiàn)的 Bloom 過濾器的要求。重點(diǎn)考慮哈希函數(shù)的重要方面，然后用高質(zhì)量的 C 語言編寫出來。同時(shí)考慮到你的示例實(shí)現(xiàn)應(yīng)能存儲(chǔ) 100,000 個(gè)元素，誤報(bào)率不超過 5%，添加的元素是以空字符結(jié)尾的字符串。
以下是輸出：
c
#
include
#
include
#
include
#
include
#
define N 100000
// Number of elements
#
define P 0.05
// False positive probability
#
define M (int)(-(N * log(P)) / (log(2) * log(2)))
// Size of bit array
#
define K (int)(M / N * log(2))
// Number of hash functions
unsigned
char bitArray[M /
8 +
1];
void
setBit
(
int n){
bitArray[n /
8] |=
1 << (n %
8);
}
int
getBit
(
int n){
return bitArray[n /
8] & (
1 << (n %
8));
}
// Basic hash functions (for demonstration purposes)
int
hash1
(
char *str){
int hash =
5381;
int c;
while ((c = *str++))
hash = ((hash <<
5) + hash) + c;
return
abs(hash % M);
}
int
hash2
(
char *str){
unsigned
long hash =
0;
int c;
while ((c = *str++))
hash = c + (hash <<
6) + (hash <<
16) - hash;
return
abs(hash % M);
}
void
add
(
char *str){
setBit(hash1(str));
setBit(hash2(str));
// Add more hash functions if needed
}
int
is_in
(
char *str){
return getBit(hash1(str)) && getBit(hash2(str));
// Check more hash functions if used
}
int
main
(){
char *testStr =
"testString";
add(testStr);
if (is_in(testStr)) {
printf(
"%s is probably in the set.\n", testStr);
}
else {
printf(
"%s is definitely not in the set.\n", testStr);
}
return
0;
}
從生成代碼來看，GPT4 的表現(xiàn)不太出色。Bloom 過濾器的應(yīng)用相當(dāng)廣泛，不是一種太過奇異的數(shù)據(jù)結(jié)構(gòu)。不過要編寫一個(gè)像樣的 Bloom 過濾器，顯然需要更強(qiáng)的抽象能力，例如找到一種有效方法，對(duì)同一字符串進(jìn)行 N 次哈希處理，并確保各哈希值充分不相關(guān)。
然而，如果你明確要求 GPT4 修改哈希函數(shù)，使其產(chǎn)生 N 個(gè)不相關(guān)的輸出，它提出的解決方案要好得多：
c
unsigned
int
hash
(
const
char* str,
unsigned
int hash_id){
unsigned
int hash =
5381;
int c;
while ((c = *str++)) {
hash = ((hash <<
5) + hash) + c + hash_id;
}
return hash % BF_SIZE;
}
如果是 GPT4 自己提出了這個(gè)想法，它可能會(huì)以不同的方式編寫 Bloom 過濾器，使用單個(gè)哈希函數(shù)一次設(shè)置 K 個(gè) bits。
也就是說，GPT4 能獨(dú)立完成編寫一個(gè)合適且更通用的哈希函數(shù)的任務(wù)，但在編寫 Bloom 過濾器這一更大的項(xiàng)目中，它卻未能表現(xiàn)出足夠的推理能力，而是輸出了兩個(gè)不同但相似的哈希函數(shù)這與網(wǎng)絡(luò)上一篇關(guān)于 Bloom 過濾器實(shí)現(xiàn)不佳的示例文章相符。
目前，LLM 的推理能力較弱，如果關(guān)于提問的信息來源稀缺，加上還摻雜著許多質(zhì)量低劣的信息來源，輸出結(jié)果就很容易不盡如人意。然而，這并非個(gè)案，我曾多次嘗試在算法或系統(tǒng)編程領(lǐng)域使用 LLM，結(jié)果都非常糟糕
與此同時(shí)，GPT4 能夠反匯編它生成的函數(shù)（在單獨(dú)的會(huì)話中），并準(zhǔn)確理解其目的：
https://chat.openai.com/share/f54b64d7-d19a-4be4-8f10-08553aa812f1
因此，斷言 LLM 在系統(tǒng)編程上沒有用途肯定是不準(zhǔn)確的。
一個(gè)有趣且基本在意料之中的現(xiàn)象是，在這些情況下，較小模型和較大模型之間的差異確實(shí)很大。下面讓我們看看兩個(gè)本地模型的表現(xiàn)。
例如，Mistral 的 MoE 模型 Mixtral 對(duì)同樣的問題的回答如下：
c
unsigned
int
hash
(
const
char* str,
unsigned
int hash_id){
unsigned
int hash =
5381;
int c;
while ((c = *str++)) {
hash = ((hash <<
5) + hash) + c;
}
return hash + hash_id;
}
顯然，僅在最后添加 hash_id 是一個(gè)極其糟糕的解決方案。Mixtral 在很多方面都是一個(gè)很好的模型，但對(duì)于推理能力本就薄弱的 LLM 而言，目前的規(guī)則無疑是：越大越好。
這是我與本地 LLM deepseek 編碼器的聊天，由于我沒有足夠的 RAM 以更高的精度使用該模型，所以量化到了 4 位。然而，由于它有 340 億個(gè)參數(shù)，因此在這個(gè)問題上的推理能力似乎相當(dāng)先進(jìn)：直說將 hash_id 添加到末尾可能會(huì)導(dǎo)致分布不均，尤其是當(dāng) hash_id 過大或分布不均時(shí)，同時(shí)建議用位運(yùn)算將 hash_id 混合進(jìn)去。
c
unsigned
int
hash
(
const
char* str,
unsigned
int hash_id){
unsigned
int hash =
5381;
int c;
while ((c = *str++)) {
hash = ((hash <<
5) + hash) ^ c + hash_id;
// Using XOR to mix in the hash_id
}
return (hash ^ hash_id);
// Mixing the hash_id one more time at the end
}
這個(gè)結(jié)果，至少在我的 MacBook M1 Max 上運(yùn)行得還不錯(cuò)，它還使用了異或來混合求和結(jié)果。在這種情況下，我提供了解決問題的線索肯定對(duì)模型有所幫助，但是模型確定了問題的真正源頭，并提出有效的解決方案上述情況，是任何書籍、文檔或谷歌搜索都無法實(shí)現(xiàn)的。
不論這是一種插值的原始結(jié)果，還是從其他角度來看，不可否認(rèn)模型確實(shí)進(jìn)行了某種形式的推理，我們找到問題起源和解決方案也正得益于此。所以，無論人們?nèi)绾慰创?LLM，斷言它們對(duì)程序員沒有幫助是一種極為草率的行為。
但與此同時(shí)，憑我在過去幾個(gè)月的經(jīng)驗(yàn)表明，對(duì)于系統(tǒng)編程而言，如果你已經(jīng)是一名經(jīng)驗(yàn)豐富的程序員，LLM 幾乎永遠(yuǎn)也提供不了有效的解決方案。舉個(gè)例子，我目前的項(xiàng)目是 ggufflib，涉及編寫一個(gè)讀寫 GGUF 格式文件的庫，這是 llama.cpp 加載量化模型的格式。最初，為了了解量化編碼是如何工作的，我嘗試用 ChatGPT，但后來我決定對(duì) llama.cpp 的代碼進(jìn)行逆向工程：這樣更快。
如果 LLM 能為系統(tǒng)程序員提供適當(dāng)?shù)膸椭�，那么看到�?shù)據(jù)編碼“struct”聲明和解碼函數(shù)時(shí)，就應(yīng)該能重建數(shù)據(jù)格式文檔。llama.cpp的函數(shù)很小，完全符合 GPT4 的要求，但輸出結(jié)果卻完全沒用。在這種情況下，我們就只能像過去一樣：掏出紙和筆，閱讀代碼，看看解碼器提取的 bits 在哪里注冊(cè)。
透過外在看本質(zhì)
我這么說可能很直接，但事實(shí)確實(shí)如此：當(dāng)今的大多數(shù)編程工作，都是以略有不同的形式重復(fù)同樣的內(nèi)容而這，并不需要高水平的推理能力。盡管 LLM 會(huì)受到上下文的嚴(yán)重限制，但它們?cè)谧鲞@方面確實(shí)相當(dāng)擅長。
這應(yīng)該引起程序員的思考：編寫這類程序是否值得？當(dāng)然，你會(huì)得到報(bào)酬，還可能是相當(dāng)豐厚的報(bào)酬，但如果用一個(gè) LLM 就可以完成其中一部分，那么也許五年或十年后，這份工作并不是你的最好歸宿。
其次，LLM 到底是真的具備某種推理能力，還只是“鸚鵡學(xué)舌”？也許有時(shí)候它們看起來會(huì)推理，符合符號(hào)學(xué)家所說的“能指”概念，但實(shí)際上這是一種并不存在的意義。那些長期與 LLM 打交道、并深知其限制的人們，對(duì)此應(yīng)該深有感觸：它們對(duì)以往接觸過的內(nèi)容的融合能力，遠(yuǎn)遠(yuǎn)超出了其隨機(jī)輸出單詞的能力。盡管 LLM 的大部分訓(xùn)練主要是在預(yù)訓(xùn)練期間進(jìn)行的，但在預(yù)測(cè)下一個(gè) token 時(shí)，大模型還是會(huì)根據(jù)目標(biāo)創(chuàng)建某種形式的抽象模型。這個(gè)模型可能很脆弱、零散且不完美，但通過實(shí)際觀察，我們會(huì)發(fā)現(xiàn)這種能力一定存在。如果我們的數(shù)學(xué)定理令人懷疑，而最偉大的專家們經(jīng)常持相反意見，那么對(duì)我們來說，“眼見為實(shí)”似乎是一種明智的做法。
最后，我想說：事已至此，不使用 LLM 進(jìn)行編程還有什么意義呢？向 LLM 提出正確的問題已是一項(xiàng)基本技能，這種技能練得越少，AI 對(duì)工作的幫助就越校此外，培養(yǎng)對(duì)問題的描述能力在與其他人交談時(shí)也很有用，有時(shí)并非只有 LLM 不理解我們想說什么。溝通不暢是一個(gè)很大的局限，很多程序員盡管在自己的特定領(lǐng)域能力很強(qiáng)，但溝通能力卻很差。
目前，谷歌搜索已經(jīng)亂得不能用了：使用 LLM，哪怕只是把它作為一種壓縮的文檔形式，也是一個(gè)不錯(cuò)的選擇。就我個(gè)人而言，我將繼續(xù)廣泛使用 LLM，我從來都不喜歡學(xué)習(xí)晦澀難懂的通信協(xié)議細(xì)節(jié)，也很討厭那些想展示自己有多么優(yōu)秀的人編寫的庫的復(fù)雜方法對(duì)我來說，這些似乎都是“知識(shí)垃圾”，感謝 LLM 每天都在把我從這一切中解救出來。
