谷歌科學家萬字長文：【改變你職業生涯的一篇文章，我如何運用人工智能完成工作】建議每個人都要讀一遍

全文約13,000 字，閱讀約需 20分鐘

在當今科技界，關於人工智能是否被過度炒作的爭論從未停息。然而，很少有像谷歌 DeepMind 的安全研究專家和機器學習科學家 Nicholas Carlini 這樣的專家，用親身經歷為我們提供了一個獨特的視角。透過他的文章，我們看到了大型語言模型(LLM)在實際套用中的強大能力和多樣性。這些並非空洞的行銷宣傳，而是切實可以改變工作方式、提高生產效率、激發創意的工具。

最近，Carlini 本人親自撰寫了一篇長達萬字的文章，詳細介紹了他如何在日常生活和工作中使用 AI。這篇洞察力十足的文章不僅展示了 AI 技術的廣泛套用，更讓我們得以一窺未來科技將如何重塑我們的生活方式。

Carlini 在文章中列舉了 50 個他親身使用 AI 的例項,涵蓋了工作效率、創意寫作、編程輔助等多個方面。然而，令人驚訝的是，這 50 個例子僅僅是他所有 AI 套用場景的冰山一角—— 據他估計，不到他實際使用情況的 2%。這一變革令人震撼，它不僅體現了 AI 技術的深度和廣度，更凸顯了我們可能還未充分認識到 AI 的潛力。

事實上，Carlini 的經歷可能預示著一個更廣泛的趨勢：隨著 AI 技術的不斷進步和普及，我們可能正站在一個技術革命的風口浪尖。就像個人電腦和互聯網徹底改變了我們的生活和工作方式一樣，AI 可能會成為下一個推動社會變革的關鍵力量。

那麽，面對這樣的前景，我們應該如何看待 AI 技術的發展呢?是抱有審慎的態度，還是積極擁抱變革?

原文如下：

作者：DeepMind 安全研究專家和機器學習科學家Nicholas Carlini

我不認為「人工智能」模型（我指的是大型語言模型）被過度炒作了。

確實，任何新技術都會吸引騙子。許多公司喜歡說他們在「使用人工智能」，就像他們以前聲稱自己依靠「區塊鏈」一樣。（正如我們一次又一次看到的那樣）同樣，我們可能正處於一個泡沫中。互聯網在2000年泡沫破裂，但我們現在擁有的互聯網套用，曾是科幻小說中的東西。

但我認為最近我們取得的進展不僅僅是炒作的原因是，過去一年中，我每周至少花幾個小時與各種大型語言模型互動，並且對它們解決我給出的越來越困難的任務的能力印象深刻。因此，我可以說，這些模型使我在編寫程式碼方面的速度提高了至少50%，無論是研究專案還是個人的編程副業。

我在網上找到的大多數談論LLM實用性的人要麽過於樂觀，聲稱所有工作將在三年內自動化，要麽極度悲觀，認為它們沒有任何貢獻，永遠也不會有。

所以在這篇文章中，我只是想讓討論更加實際。我不會對未來進行任何論斷。我只想列出一個列表，這是我（一名研究機器學習的程式設計師和研究科學家）與不同的大型語言模型進行的50次對話，這些對話顯著提高了我進行研究的能力，並幫助我從事隨機的編程副專案。其中包括：

如果對這些套用例項進行分類， 它們大致可以分為「輔助學習」和「自動化日常瑣事」兩類。前者對我來說至關重要，因為它讓我能夠輕松應對之前覺得有難度的任務；後者同樣重要，因為它使我能集中精力去做我最擅長的事，解決真正的難題。

關鍵是，這些例子展示的是我如何實際利用大型語言模型（LLMs）的。它們並不旨在炫耀技術的驚人能力，而是基於我解決工作需求的實際情況。這意味著，這些例子或許看起來不夠引人註目，但實際上，我日常工作的很大一部份也都是平凡無奇的，而現今可用的LLMs幾乎幫我自動化了所有這些工作。

透過這篇文章，我的目的是用一個接一個的例項，向你展示我在過去一年如何有效利用LLMs提升工作效率，直到你感到有些疲憊為止。要知道，盡管你可能已經看過不少例子，但實際上我所展示的，還不到我利用LLMs的總數的2%。

細微差別

如果說互聯網處理得不盡如人意的是什麽，那一定是對細節的把握。我絕不認為現今的大型語言模型（LLMs）能夠主宰世界，也不打算討論未來的模型能做什麽，不能做什麽。我只想探討，現階段的模型對我是否真的有用。

你可能會問，為什麽還需要一篇文章來證明語言模型的用途呢？這難道不是顯而易見的事實嗎？但事實上，無論是在學術界、軟件工程領域還是媒體行業，都有不少人聲稱LLMs毫無用處，只是一時的炒作，幾年後將默默無聞，對世界沒有任何影響。我要反駁這些觀點，因為目前的LLMs已經證明了它們的實用性。

但同時，我也需要說明，另有一批聲音同樣強烈的人士持相反觀點，他們認為現有模型能夠取代所有程式設計師，人們不應再學習編程，因為不久後大家都將面臨失業。雖然反駁這些觀點不是本文的主旨，但我必須明確，我並不支持這種極端的看法。

此外，我也不會主張「目的正當化手段」，即便這些模型的訓練確實存在諸多負面影響，我不認為應當因此而推廣使用。

我充分意識到這些模型可能帶來的負面後果，這些後果可能非常嚴重，包括但不限於散布錯誤資訊、濫用、監控以及取代工作崗位（甚至有人擔憂到人類滅絕的地步）。我將在不久的將來撰寫一篇文章，深入探討LLMs可能引發的危害，屆時會在此放上連結。然而，這與語言模型是否有用的討論是兩碼事——這正是我此處想要探討的問題。

我也清楚你可能因為語言模型偏向於生成不準確的資訊、重復已知事實、在面對復雜情況時可能徹底失敗的傾向而不願使用它們——可能我對這些局限性的了解比你更深。但本文不會討論這些。因為我認為，盡管有這些不足，模型仍然是有用的。

此外，我也深知培訓這些模型所涉及的倫理問題極具爭議。你可能不贊成在未經特許的情況下使用人們的數據來訓練它們（我對此的理解可能比你更深刻）。或許你關註的是那些為直接訓練這些模型而獲得微薄報酬的人。我承認這些都是問題，但本文也不打算討論這些。

正如我已經多次強調的：我在這裏討論的，僅僅是這些模型在當前狀態下是否實際有用。

我的背景簡介

通常，我不是那種輕易相信任何事物的人。比如，盡管我經歷了十年前資訊保安界的加密貨幣熱潮，我卻從未參與撰寫任何關於區塊鏈的研究論文。我也從未擁有過任何比特幣，因為在我看來，它們除了用於賭博和欺詐之外，沒有任何實際價值。我一直持懷疑態度，每當有人向我宣稱「某項新技術將改變世界」，我的反應總是冷漠。

因此，當第一次有人告訴我人工智能將極大地提升我的工作效率並改變我的日常工作方式時，我同樣持保留態度，我的回應是：「見到實際效果我才會信。」

此外，我是一名安全研究員。在過去近十年的工作中，我專註於展示人工智能模型在面對未曾訓練過的各種環境時如何徹底失敗。我證明了只需對機器學習模型的輸入進行輕微擾動，就能使其輸出完全錯誤的結果；或者這些模型往往只是記住了它們訓練數據中的特定案例，並在實際套用時簡單重復。我深知這些系統的種種局限。

然而，現在我卻在這裏說，我認為當前的大型語言模型是自互聯網問世以來，給我的生產力帶來的最大提升。坦白說，如果今天要我在使用互聯網和一個最先進的語言模型之間選擇一種工具來解決工作中隨機一個編程任務，我可能會選擇使用語言模型的次數超過一半。

如何利用語言模型

以下是我如何利用大型語言模型（LLMs）來提升工作效率。

你可能對我所述的使用案例不感興趣，甚至認為它們有些荒謬。也可能這些案例與你的需求不相關，這一點我也能理解。但我只能從個人角度出發。這些使用例項都是我在過去一年裏與LLMs的交流記錄中直接摘錄的。

1、為我開發完整套用

去年，我建立了一個測驗，讓人們評估GPT-4在處理幾個特定任務上的表現。這個測驗非常受歡迎，獲得了超過一千萬的頁面瀏覽量。你可能想不到，我幾乎是讓GPT-4為我編寫了這個套用的全部初始版本。這一過程是透過一連串的問題進行的，我從詢問套用的基本架構開始，然後逐步擴充套件其功能。整個對話長達30,000字，極大地測試了當時的GPT-4模型的能力極限。如果你翻看這些對話，會發現從我描述需求並請求模型完成全部實作的資訊，到我請求做出具體修改的資訊（如「不要比較平均分數，而是用核密度估計表示它是哪個百分位」），以及我提出一些完全不明確的問題時復制貼上的錯誤資訊（例如，「繪圖錯誤：numpy.linalg.LinAlgError: singular matrix」），還有我僅僅詢問簡單單次問題的情況（比如「如何用JavaScript在頁面上添加一個iframe，內容是從字串載入的？」）。

這種方法之所以有效，主要是因為語言模型擅長處理人們已經解決的問題，而這個測驗的99%內容只不過是一些基礎的HTML和Python後端伺服器，這是任何人都可以編寫的。這個測驗之所以引人關註並受到喜愛，並非因為其背後的技術，而是因為測驗內容本身。透過自動化所有重復性的部份，我能輕松地完成這個專案。

實際上，如果沒有語言模型的幫助，我可能根本就不會去建立這個測驗，因為我不願意花時間從頭編寫整個網頁套用。盡管我擅長編程！我相信，即使是現有的模型，也足以讓大多數人僅憑提問就能解決他們以前無法解決的重要任務。

我還有一些類似的例子以後介紹，其中我讓模型為我編寫了整個套用，當這些套用釋出時，我會明確指出它們是在語言模型的協助下完成的。

2、作為新技術的精靈

我曾經總能趕上各種新興框架的步伐。但是一個人的時間畢竟有限，因為我的職業特性，我大多數時間都在跟進最新的研究進展，而不是最新的JavaScript框架。

這意味著當我開始一個不屬於我研究領域的新專案時，我通常有兩個選擇：一是利用我已知的技術，雖然這些技術可能已經過時十年或二十年，但對於小專案來說通常足夠了；二是嘗試學習新的（通常也是更好的）方法。

這就是語言模型派上用場的時候。對我而言較新的框架或工具，比如Docker、Flexbox或React，對其他人來說可能已經相當熟悉了。世界上可能有成千上萬的人已經非常了解這些技術。當前的語言模型也能做到這一點。

這意味著，我可以透過與語言模型的互動式學習，來掌握解決任務所需的任何知識，而不必依賴那些假設讀者具備特定知識、目標明確的靜態教程。

比如，今年早些時候，我在構建一個LLM評估框架時，希望能在一個受限環境中執行由LLM生成的程式碼，以避免它刪除我的電腦上的隨機檔等問題。Docker是完成這一任務的理想工具，但我之前從未使用過。

重要的是，這個專案的目標並非是要學會使用Docker，Docker只是我實作目標所需的工具。我只需要掌握Docker的10%，確保我能以最基本的方式安全使用它。

如果是在90年代，我可能需要購買一本關於Docker的書籍，從頭開始學習，閱讀前幾章，然後試圖跳讀以找出如何實作我想要的功能。過去十年情況有所改善，我可能會線上搜尋如何使用Docker的教程，跟著操作，然後搜尋遇到的錯誤資訊，看是否有人遇到相同的問題。

但在今天，我只需要請一個語言模型教我使用Docker。

3、開始新專案

回想起來，我最初接觸的程式語言是Java。我非常喜歡編程，但有一件事我絕對討厭：面對新專案的空白螢幕。特別是在使用Java時！甚至僅僅是讓程式編譯一個hello world程式——這個「public static void main string args」到底是做什麽的？括弧應該怎麽放？哪些字母應該大寫？為什麽這裏用花括弧，那裏用方括弧？

所以我做了任何孩子都會做的事——我讓我父親幫我做了。

二十年過去了，我仍然不喜歡使用我不熟悉的框架開始新專案。僅僅是為了搞定樣板程式碼就需要花費大量時間，而且我對我在做的事情毫無頭緒。

例如，我最近想嘗試編寫一些CUDA程式碼，來評估一種簡單的貪婪搜尋在GPU上的效能與某人的高效最佳化的CPU實作相比。

但我不懂CUDA編程。我會寫C語言，了解GPU的工作原理、內核的功能以及記憶體布局等，但實際編寫向GPU發送任務的程式碼？我不知道該從哪裏開始。因此，我直接請求模型為我編寫CUDA程式的初稿。完美嗎？當然不是！但這是一個起點。這正是我需要的。你會註意到這裏的程式碼有很多錯誤！實際上，我完全可以接受。我不是在尋找完美的解決方案，而是一個起點，我可以從那裏繼續。如果未來的模型能做得更好，那將是驚人的。但我現在擁有的已經大有幫助了。

另一方面，對於我在家進行的一些其他個人專案，我正在使用一個樹莓派Pico W。這是我第一次使用它。我希望它能為我做一些事情，特別是一些網絡相關的事情。再次，我確信我可以在網上找到有人描述如何做我想做的事情的好教程。但你最近看過互聯網嗎？前5個結果通常只是一些垃圾內容農場，它們有2008年的有缺陷的程式碼，僅為了搜尋引擎最佳化而更新，但仍然不起作用。

因此，我直接請求一個語言模型教我如何做我想做的事情。我之前已經和微控制器打過交道，所以我或多或少了解它們的工作方式。但我之前從未使用過Pico W。我只需要一些幫助來開始處理所有的依賴關系，然後我可以弄清楚剩下的部份。

我為新的微控制器編寫的第一個「hello world」程式總是讓一個LED閃爍。這可以讓我測試我是否能夠編譯並上傳程式碼到器材，是否正確設定了所有的引腳，並且基本上知道我在做什麽。所以，讓我們只是請求一個閃爍程式。（再次：這在互聯網上存在嗎？幾乎可以肯定。但那樣我就得去搜尋它了。）一旦我有了這段程式碼並且執行起來，從這裏我就知道該怎麽做了。我知道python是如何工作的（信不信由你！）。因此，我可以從那裏直接繼續編輯東西，把特殊的Micro Python的東西處理掉。

當我遇到另一個需要我特別處理的問題時，我可以再次請求模型幫助我。例如，我接著只是讓模型為我編寫一個連線到wifi的指令碼。

4、程式碼簡化

作為安全研究員，我經常需要處理別人的研究專案，這些專案包含數千行程式碼，我必須弄懂它們的工作原理以便進行攻擊。這聽起來並不困難，如果每個人都編寫清晰的程式碼，實際上也確實不該困難，但現實世界並非如此。研究人員通常沒有動力釋出整潔的程式碼。所以，人們往往會釋出他們能用的任何雜亂程式碼。（我自己也不例外。）

我無法分享與研究相關的例子，但我可以分享我正在進行的一個個人專案的例子。據說我對康威的生命遊戲有種不健康的癡迷。最近，我試圖找到一種快速的方法，透過Python評估一些生命遊戲模式。有一個很好的C++工具叫golly可以做這個，但我不想將我的Python程式碼重寫為C++。

golly有一個CLI工具正好滿足我的需求——我所需要的只是一種正確呼叫它的方法。這的第一步是簡化支持約50種不同命令列選項的C++程式碼，讓它只執行我想要的操作。所以我將所有500行的C++程式碼輸入到LLM中，請求一個更簡短的檔來完成相同的任務。

你知道嗎？這完美地奏效了。然後，我請求一個圍繞C++程式碼的Python封裝器。這同樣有效。這是那些令人煩惱的任務之一，如果由我來做，我可能永遠不會完成。但現在我可以請求別人幫我完成，我得到的東西比我原來的Python程式碼快了100倍。

我發現自己經常這樣做。這裏還有一個例子，我在用Python做同樣的事情。

再說一次，這些任務並不復雜。但每次這樣做，我都能節省大量時間。這就是我認為大型語言模型如今驚人的原因之一：它們的用途可能不夠光鮮，也不會因為說「這是我用大型語言模型簡化日常工作的平凡方式」而贏得網絡贊譽，但這是實實在在的幫助。

5、處理單調任務

我必須完成的許多工都是單調無聊的，不需要太多思考，但卻必須做。

事實上，我發現自己之所以會拖延任務，往往是因為我知道完成這些任務會感到無聊和痛苦。LLMs極大地減輕了這種痛苦，讓我在開始任務時就知道自己只需要解決有趣的問題。因此，我想逐一介紹一些透過請求LLMs幫忙而解決的非常普通的問題。

例如，最近我需要拆解一個用Python 3.9編寫的程式。大多數Python反編譯器只支持到Python 3.7，但無法在我處理的3.9版本上執行。

反編譯實際上並不難，主要是在重建控制流程時避免出錯。因此，我沒有親自花時間為幾千個操作碼和幾百行程式碼進行這種轉換，而是讓LLM幫我做了。它做得非常好！效果遠超我的預期。這裏有三個不同的對話，在這些對話中我讓模型幫我完成了這項工作。另一個例子是，當我需要將一些非結構化數據轉換成結構化格式時。比如，我在做一個專案，需要列出一些書名和作者名。我在網上找到了一些非結構化格式的數據，然後讓LLM幫我格式化。最近，我在寫一篇關於如何破解某個防護的網誌文章，想展示我不得不修改的程式碼完整差異。於是我貼上了差異和之前如何將差異轉換為HTML的範例，並讓LLM按照之前的格式為我生成差異。此外，作為我的工作的一部份，我經常需要為我使用的資源生成參照。谷歌學術很容易參照論文，我可以直接復制貼上。但參照網頁稍顯麻煩；我最近開始請求LLM幫我生成參照。（確保這是正確的！）我可以繼續舉出至少一百個類似的例子。但我想你已經明白了我的意思。

我完全明白這種任務可能會讓人覺得「就這？」但我們要記住，五年前這些模型幾乎不能連貫地寫出一個段落，更別說為你解決整個問題了。

6、使每個使用者都成為「高級使用者」

如果你曾經看過比你不那麽熟練的人使用某個工具，這可能會有點讓人難受。他們可能會花費幾分鐘甚至幾小時的時間去完成一個本可以透過某種宏或在處理特定任務時巧妙使用並列應用程式來自動化的任務。

然而，學習執行這些操作所需的技巧需要時間，並且具有挑戰性。

例如，我最近試圖編寫一個Python程式來處理來自Apple Lisa鍵盤的輸入。我線上找到了一個人用C語言編寫的相關程式碼，其中包含許多像#define KEYNAME key_code這樣的語句，我想將它們轉換為一個Python字典，將整數程式碼對映到對應的字串。

我是一個Emacs使用者。我知道如何在Emacs中解決這個問題，這甚至並不難。這是我剛記錄的一些關鍵操作，可以達到這個效果：

C-h C-s #def [enter] M-f [delete] C-d M-f C-[space] M-f C-w C-a C-y : " M-f ", C-g C-] } C-[ {

盡管這對我幾乎是自然的，但到目前為止，我已經花了超過一半的生活時間在Emacs上變得足夠熟練，以至於這成為了自然反應。但你知道現在我連線了LLM到我的編輯器，我會怎麽做嗎？C-h C-h 請將這些#define重寫為{keycode: string, ...}的字典格式。

然後，文本就在我眼前被重寫了！

正是在這樣的情況下，我認為LLMs對非專家的潛在效用甚至高於專家。這個模型為每個人提高了起點，如果你之前完全不會做，現在突然能做很多事情。

7、作為API參考

真正的程式設計師想要理解某個工具的工作原理時會閱讀參考手冊。但我是個懶惰的程式設計師；我更願意直接得到答案。因此，現在我向語言模型提問。

當我向人們展示這些例子時，有些人會變得有些防禦性，他們說：「LLM沒有做任何你不能用已有工具完成的事情！」你知道嗎？他們說得對。但是，用搜尋引擎能做的事，用一本關於該主題的實體書也能做；用一本實體書能做的事，透過閱讀原始碼也能做。

然而，每一種方式比前一種都簡單。當事情變得更簡單時，你會更頻繁地做，而且方式上也會有所不同。

這就是我問「哪個$命令可以傳遞所有剩余參數」並獲得答案的例子。（緊接著是另一個「我該如何使用這個東西」的問題！）這實際上是我最常用LLMs的方法之一。我之所以不能給你展示更多這樣的例子，是因為我在Emacs和我的shell中都內建了查詢LLMs的工具。因此，當我想要做這些事情的90%的時間，我甚至不需要離開我的編輯器。

8、搜尋難以找到的內容

在互聯網上搜尋內容曾經是一項需要學習的技能。你想在查詢中包含哪些特定的詞匯？它們應該是復數還是單數？過去時？你希望避免在頁面上出現哪些詞匯？我是想要X和Y，還是X或Y？

現在情況已經不同了。我想不起上次我在Google中使用OR的時間。我也想不起上次我使用減號(-)來移除結果子集的時間。在大多數情況下，今天你只需要寫下你想要找的內容，搜尋引擎就會為你找到。

但搜尋引擎仍然不是100%的自然語言查詢。它仍然有點像你在玩反向危險邊緣遊戲，試圖使用答案中會有的關鍵詞而不是問題。這是一項我認為我們幾乎都忘記了我們學過的技能。

對於今天的一些簡單任務（隨著時間的推移會越來越多），語言模型只是更好。我可以直接輸入「所以我知道+對應於__add__，但是是什麽」，它會告訴我答案是__inv__。這是用標準搜尋引擎很難搜尋到的東西。是的，我知道有方法可以問，這樣我就能找到答案。可能如果我輸入「python文件元類"add"」，我可以搜尋頁面上的並得到答案。但你知道還有什麽有效嗎？只要問LLM你的問題。

這樣做任何一次只節省幾十秒的時間，但當你在解決某個編碼任務的過程中，已經試圖同時記住一百萬件事時，能夠將你試圖解決的問題傾倒出來並得到一個連貫的答案是令人驚訝的。

這並不是說他們今天在這方面已經完美。語言模型只有線上上被足夠頻繁地重復時才知道事情。"足夠頻繁"是什麽意思取決於模型，所以我確實需要花一些精力思考我是應該詢問模型還是詢問互聯網。但模型只會變得更好。

或者，每當我遇到隨機崩潰時，我會將模型轉儲我所看到的並要求解釋，就像我在這裏做的那樣，當我只是輸入zsh沒有找到匹配的「遠端通配符傳輸問題」。或者，作為一個完全獨立的例子，我去年在寫一篇網誌文章時，想要第一個字母大寫，讓其余的文字環繞它，就像我在這句話中所做的那樣。現在這被稱為下沈式大寫字母。但我不知道這個。我只知道我想要的效果，所以問語言模型「我想讓它看起來像一本華麗的書，文字圍繞O」，它給了我我想要的東西：這個任務是另一個屬於「我只是因為LLMs才做的」類別——我不會認為花大量時間弄清楚如何做是值得的。但因為我可以直接問模型，我就這樣做了，它讓我的貼文看起來更好一些。

9、解決一次性任務

有兩種類別的程式。首先，你有一些你想要正確完成的程式；它們將會存在一段時間，因為你需要維護它們好幾年，所以程式碼的清晰性很重要。然後，你有那些只存在大約25秒的程式；它們將幫助你完成某些任務，然後立即被丟棄。

在這些情況下，我根本不關心程式碼的質素，而且程式是完全獨立的，我現在幾乎專門使用LLMs來為我編寫這些程式。

請註意：大多數這些情況再次出現，你會看著它們說「就這？」。但就像我之前說的，我每天只有那麽多小時來處理一個專案。如果我能節省編寫一次性使用的程式的時間和精力，我會選擇這樣做。

可能最常見的例子是幫助我生成一些圖表，以視覺化我作為某些研究實驗結果生成的一些數據。我有幾十個這樣的例子。可能接近一百而不是零。它們看起來基本上都一樣，這裏只是一個例子：或者，另一個類似的例子，當我有一種格式的數據並想將其轉換為另一種格式的數據時。通常這是我只需要做一次的事情，一旦完成，我就會扔掉生成的指令碼。但我還可以給你舉出一千個其他例子。通常情況下，當我有一個足夠簡單的指令碼想要編寫時，我會直接請求LLM整體編寫。例如，這裏我請求LLM為我編寫一個指令碼，讓它大聲讀出我的論文，這樣我可以確保它們沒有愚蠢的語法問題。在許多情況下，當我不太清楚我想要什麽時，我也會從請求模型提供一些初始程式碼開始，然後從那裏進行叠代。例如，這裏有一個一次性任務，我只是需要快速處理一些數據。在2022年，我會花兩分鐘用python編寫這個，然後等待幾個小時因為它只執行一次——最佳化它所需的時間會比python程式執行的時間還要長。但現在呢？你敢打賭我會花同樣的兩分鐘請求用Rust程式碼為我處理數據。或者這裏是另一個例子，我請求模型為我下載一個數據集，並對其進行一些初始處理。這對我來說容易做嗎？可能是。但這不是我想要考慮的任務；我想要考慮的是我將要用數據集做的研究。消除分心非常有價值，不僅僅是節省幾分鐘的時間。

另一次，我編寫了一個程式，這樣我就可以用小立方體3D打印一些像素化的影像。為此，我想將PNG轉換為STL檔；但這不是專案的重點。這只是沿途必須發生的事情。所以我請求LLM為我解決這個問題。或者，作為另一個例子，我最近想使用Docker Compose來設定一個新專案。我遇到了一些問題，只想讓它執行起來，然後我會弄清楚出了什麽問題。所以我只是來回幾次，我所做的就是復制一個又一個錯誤訊息，直到它最終給我一個有效的解決方案。我還會發現自己在很多情況下首先請求一個完整的解決方案，然後請求如何修改它的提示。在這次對話中，我首先請求一個解析HTML的程式，然後請求API參考或其他改進方式的提示。最近我一直在嘗試做一些電子產品相關的事情，我有一個在Arduino上執行的C程式，但我希望它在樹莓派Pico上以MicroPython執行。這個轉換過程沒有什麽有趣的；它只需要完成。所以我沒有親自完成工作，只是請語言模型為我做。對於另一個專案，我需要用一些花哨的ML模型在一些互動迴圈中分類一些影像。我本可以自己編寫，或者我可以直接請求模型為我做。

10、解釋事物給我聽

我最近開始對電子學產生了興趣。我年輕的時候做過一些電子專案，並在大學期間上過幾門相關課程。但現在我想進行實際的電子專案，我發現有許多我不了解的細節，這讓開始任何專案都變得困難。

我可以去讀一本關於實用電子學的書。我可能真的會在某個時候這麽做，以便徹底理解這個主題。但我並不想把我的時間花在感覺自己在學習上。我從事電子學的部份原因是想從整天的閱讀和寫作中抽身而出。

這就是LLMs發揮出色的地方。它們可能不如世界上最出色的專家那樣知識淵博，但成千上萬的人可能知道我可能會提出的任何電子問題的答案。這意味著語言模型很可能也知道答案。它樂於為我提供所有問題的答案，使我可以享受樂趣而不必糾結於細節。雖然我完全可以透過在互聯網上搜尋來找到答案，但在忙碌一整天後，簡單地讓模型為我完成這些工作的便利性使我感到非常放松。

這裏是一些例子，展示了我如何詢問語言模型有關電子學中事物工作原理的基本問題。這些答案完美嗎？誰知道呢。但你知道它們比什麽更好嗎？比我什麽都不知道要好。

11、解決具有已知解決方案的任務

幾乎所有事情都已經有人做過了。你想做的事情幾乎沒有什麽是真正新穎的。語言模型特別擅長提供它們之前見過的事物的解決方案。

在最近的一個專案中，我需要提升一些Python程式碼的效能。因此，我（1）請求LLM將其重寫為C語言，然後（2）請求它構建一個介面，以便我能從Python呼叫C程式碼。

這些任務都不是「難」的。將Python轉換為C是我確信自己能在一兩小時內完成的。盡管我不完全知道Python到C的API如何工作，但我相信我可以透過閱讀文件來了解。但如果需要我自己來做，我永遠不會去做。它不是關鍵路徑上的一部份，我寧願等待電腦解決問題，也不願花時間加速那些我不經常需要執行的任務。

但是，將Python轉換為C主要是簡單程式的技術過程，而且有一個標準的Python到C的呼叫約定。所以，我直接請求LLM來幫我完成。

從那以後，我開始期待這是我可以做到的事情，幾乎在任何時候，當我需要一些高速的程式碼時，我會用Python描述我想要的內容，並請求生成最佳化的C程式碼。其他時候，我做同樣的事情，但如果我認為比較Rust輸出和C輸出的正確性更容易的話，我會請求Rust輸出。或者，作為另一個例子，用multiprocessing庫並列化Python函數並不困難。你需要編寫一些樣板程式碼，基本上它就會為你完成。但編寫程式碼有點痛苦，會妨礙你想要完成的實際工作。現在，每當我需要做這個時，我只會請求一個LLM來幫我。還有很多時候，當我嘗試測試某個API時，我最初會編寫一個curl請求來開始。一旦它開始工作，我想以編程方式重復任務，我就會將它轉換為Python。以前，我通常會做些非常醜陋的事情，直接呼叫os.popen()執行curl命令，但這並不理想。更好的方法是將其轉換為Python的requests庫；但這需要時間，所以我不會這麽做。但現在我可以簡單地請求一個LLM幫我完成，並在更短的時間內獲得一個更幹凈的程式。對於即將到來的一個專案，我可能會在這裏討論，我需要了解人們通常用作簡單無線電發射器的是哪些東西。因為我真正想要的是大多數人的答案，LLM是一個完美的選擇！

12、修復常見錯誤

在2022年之前，當我遇到某些流行工具或庫的錯誤資訊時，我通常會采取以下步驟：

1. 復制錯誤資訊。

2. 將其貼上到Google搜尋。

3. 點選最頂部的Stack Overflow連結。

4. 確認問題是否與我遇到的一致；如果不是，返回第2步。

5. 如果無效，返回第2步，更換搜尋詞，祈禱等。

因為，坦白說，通常出問題的工具與我最終想要解決的任務差距很大，我其實並不太關心如何使其工作，我只需要它能工作。2024年現在這個流程是怎樣的？

1. 復制錯誤資訊。

2. 向LLM詢問：「我該如何修復這個錯誤？（錯誤）」

3. 如果無效，反饋「那不起作用」。

我沒有任何對話記錄來展示這些例子。（或者說，我找了一個小時也沒有找到。）但這實際上有一個很好的原因：我已經將它整合進我的工作流程中了。

我是一個Emacs使用者。我設定了我的環境，每當我執行一個程式並且它以非零狀態碼結束時（意味著有錯誤發生），它會自動呼叫最新最快的LLM，並要求它解釋答案，同時請求一個可以直接套用來修復程式碼中bug的修補程式。

現今的模型大多數情況下還不足以在這項任務上勝過我，但它們正在逐漸進步。偶爾，當LLM修復了一個我知道如果自己追蹤可能非常困難的錯誤時，我會感到非常驚喜，尤其是當錯誤只是因為某處的小筆誤。

13、以及無數其他事情

我上面提到的所有對話只占我過去一年與LLMs互動總數的不到2%。我沒有提供其他連結的原因並不是因為這些是模型失敗的案例（盡管有很多這樣的案例），而是因為：（1）許多互動重復了我已經提到的那些模式，或（2）它們不容易解釋清楚發生了什麽，也不容易讓你自己看到它們為何對我有用。

我完全預期未來我使用這些模型的頻率會持續增長。作為一個參考，我在2024年透過網頁界面進行的LLM查詢比2023年增加了30%——而且我甚至無法計算API查詢的增加，但我猜測至少增加了2到3倍。

評價LLMs的能力，而非它們的局限

我在面試求職者時獲得的最佳建議之一是，根據他們能做什麽而不是不能做什麽來評價他們。

我懷疑我可以問你一些簡單的問題，這可能會讓你顯得不夠稱職。比如極端的例子：世界上有十億人講普通話；我連數到十都做不到。如果有人給我一份小學水平的普通話考試，我肯定會考得很糟糕。

即便在電腦科學領域內，也有我完全不了解的領域。我關於如何構建SQL的知識僅限於如何編寫有效的SELECT語句。這——字面上——是我唯一知道如何編寫的語句。

因此，當我看到人們在網絡上爭論說LLMs只是炒作，因為「它們甚至不能做XXX」時，我真的感到困惑。這裏的XX可能是：

因為你上次真正需要做這些事情，並且真誠地認為LLM是合適的工具是什麽時候？

我不會因為我們不能在頭腦中分割64位元整數而認為人類完全無用——這對電腦來說是極其簡單的任務——我也不認為因為你可以構造出LLMs無法解決的任務就應該拋棄LLMs。顯然這很容易——關鍵是你能找到它們能夠提供價值的任務嗎？

程式設計師已經很清楚，某些事物對不同的目的可能有用。想要編寫作業系統？也許你應該使用C而不是Python。沒有人會說「看Python多麽愚蠢，你甚至不能強制變量對齊到32字節邊界！」這只是在錯誤的抽象級別上。語言模型也是一樣。它們在非常高的抽象級別上操作；你不能期待它們解決甚至最簡單的程式都能解決的任務。但你可以期望它們解決不同種類的任務。

結論

撰寫這篇文章的初衷有兩個。首先，正如我在文章開頭所述，我想證明LLMs已經為我提供了大量的價值。此外，我註意到很多人表示喜歡使用LLMs的想法，但不知道它們能如何幫助自己。因此，如果你是這些人之一，希望透過我的使用案例能看到一些範例。

因為至少對我來說，LLMs能做很多事。它們不能做所有事情，甚至不能做大多數事情。但當前的模型，正如它們現在存在的樣子，為我提供了可觀的價值。

在展示這些範例後，我經常收到的一種反駁是：「但這些任務很簡單！任何電腦科學的本科生都能學會如何做到！」確實，本科生可以透過幾小時的搜尋來告訴我如何正確地診斷CUDA錯誤以及可以重新安裝哪些包。本科生可以透過幾小時的工作重寫那個程式為C語言。本科生可以透過幾小時的學習相關教科書來教我任何我想知道的關於那個主題的內容。不幸的是，我沒有一個隨時可以回答我任何問題的神奇本科生。但我有語言模型。所以，雖然語言模型還不夠好，不能解決我作為程式設計師工作中的有趣部份，而且當前模型只能解決簡單的任務。

但五年前，LLM最好的能做的就是寫出看起來像英語的段落。當它們能從一個句子到下一個形成連貫的思想時，我們都感到驚訝。它們的實際用途幾乎為零。然而，今天，它們已經提高了我在專案中編程方面的生產力至少50%，並消除了足夠多的繁瑣工作，讓我能夠建立一些我否則永遠不會嘗試的東西。

因此，當人們說「LLMs只是炒作」和「所有LLM都沒有為任何人提供實際價值」時，很明顯他們是錯誤的，因為它們為我提供了價值。現在，也許我是個例外。也許我是唯一找到了讓這些模型有用的方法的人。

我只能代表我自己。

但考慮到LLMs顯著提高了我的生產力——一個在使用LLM之前已經有20年編程經驗的人——我相信還有其他人也能從使用AI中受益。

原文連結：https://nicholas.carlini.com/writing/2024/how-i-use-ai.html#intro

素材來源官方媒體/網絡新聞

本文轉自 | AI深度研究員