2023年11月，在ChatGPT支持DALL-3功能后，一個爆火的圖像生成玩法是，不斷迭代提示詞「make it more X」，生成的圖片越來越抽象。

圣誕老人越來越嚴肅

把這個思路用在LLM任務(wù)上，比如代碼生成，會怎么樣？

最近，BuzzFeed的高級數(shù)據(jù)科學(xué)家Max Woolf在博客上分享了一個實驗，通過設(shè)計不同的提示詞、不斷迭代模型輸出，最終實現(xiàn)代碼性能的100倍提升！

完整代碼鏈接：https://github.com/minimaxir/llm-write-better-code/

特別需要注意的是，「性能」并不是唯一優(yōu)化指標，迭代過程中需要在提示詞中明確定義什么是「好」。

代碼基線

設(shè)計實驗題目時，為了充分測試LLM的自主代碼能力，必須保證「測試提示詞」完全原創(chuàng)，不能源于LeetCode或HackerRank等測試，模型無法通過背誦記憶來作弊；測試題目要盡可能簡單，新手也能實現(xiàn)，但還要預(yù)留大量可優(yōu)化空間。

最終選擇Claude 3.5 Sonnet模型，設(shè)計了一個Python語言、面試風格的編碼提示詞：

Write Python code to solve this problem: Given a list of 1 million random integers between 1 and 100,000, find the difference between the smallest and the largest numbers whose digits sum up to 30.

用Python實現(xiàn)：假設(shè)有一個包含100萬個隨機整數(shù)的列表，介于1到10萬之間，你需要找出其中各位數(shù)字之和等于30的最小數(shù)和最大數(shù)之間的差值。

第一次給出的代碼實現(xiàn)就是正確的，與大多數(shù)新手Python程序員的水平相當：對于列表中的每個數(shù)字，檢查其各位數(shù)字之和是否為30：如果是，檢查是否大于最近看到的最大數(shù)字或小于最近看到的最大數(shù)字，并相應(yīng)地更新這些變量；在搜索完列表之后，返回差值。

一個明顯可優(yōu)化的點是digit_sum()函數(shù)：字符串（str）和整數(shù)（int）之間進行類型轉(zhuǎn)換的開銷很大。

在M3 Pro Macbook Pro上，代碼的平均運行時間為657毫秒。

第一次Write better code

Claude提供的代碼優(yōu)化版本，不再將所有代碼放在函數(shù)中，而是將其重構(gòu)為 Python class，更面向?qū)ο蟆?/span>

這段代碼主要進行了兩處改進：

1. 計算數(shù)字和時，使用整數(shù)運算并避免了類型轉(zhuǎn)換需求；
2. 預(yù)先計算所有可能的數(shù)字和，并將其存儲在字節(jié)數(shù)組中以供查找，即一百萬數(shù)字列表中有重復(fù)時，不需要重新計算數(shù)字和。由于該數(shù)組作為類的字段存儲，因此在搜索新的隨機數(shù)字列表時也不需要重新計算。

代碼計算相比基線提速2.7倍。

第二次Write better code

Claude對代碼增加了并行處理：

1. 通過Python的concurrent-futures包進行多線程，將大列表分割成可以獨立處理的塊；
2. 矢量化NumPy操作，比基礎(chǔ)Python操作快得多，_precompute_digit_sums()函數(shù)實現(xiàn)了計算數(shù)字和的矢量化實現(xiàn)；

代碼計算相比基線提速5.1倍。

第三次Write better code

Claude返回了一個聲稱是“使用高級技術(shù)和現(xiàn)代 Python 特性的更加復(fù)雜和優(yōu)化的版本”的實現(xiàn)，但實際上代碼并沒有顯示出顯著的算法改進，并且在數(shù)字求和計算上實際上退步了，回歸到類型轉(zhuǎn)換方法。如果有什么的話，代碼庫正在變得更加臃腫，比如添加一個用于執(zhí)行差的類：

代碼計算性能略有下降，相比基線提速4.1倍。

第四次Write better code

Claude這次提供了額外的「尖端、企業(yè)級優(yōu)化」，比如結(jié)構(gòu)化指標日志記錄Prometheus；信號處理程序，以便在強制終止時優(yōu)雅地關(guān)閉代碼；使用表格的基準測試。

最終代碼非常長，優(yōu)化操作包括numba Python庫，調(diào)用JIT編譯器，直接優(yōu)化代碼以適應(yīng)CPU，只需使用一個裝飾器就可以非常快速地預(yù)計算數(shù)字之和。

完整類還使用Python的asyncio行化，比子進程方法更符合調(diào)度任務(wù)的規(guī)范，與現(xiàn)有的內(nèi)聯(lián)代碼和REPL配合得更好。

這次代碼的運行時間大約為6毫秒，速度提升了100倍。

什么是好？

「速度快」并不代表是「好代碼」，比如用戶可能只是想在算法上改進，而不是一個完整的SaaS，過于冗長的代碼在閱讀上還會帶來額外負擔。

所以需要更具體地定義什么是「代碼優(yōu)化」。

你編寫的所有代碼都必須充分優(yōu)化。「充分優(yōu)化」的含義包括：

• 盡可能提高算法在內(nèi)存使用和運行時間上的效率；
• 在合適的時機使用并行化和向量化；
• 遵守代碼語言的正確風格規(guī)范，比如盡量重用代碼，避免重復(fù)勞動；
• 除了解決用戶提出的問題所必需的代碼外，不添加任何多余的代碼；

如果代碼沒有達到充分優(yōu)化的標準，罰款100美元。

先規(guī)劃一下優(yōu)化方案：

1. 算法優(yōu)化：只需要追蹤各位數(shù)字之和等于30的最小數(shù)和最大數(shù)，不需要存儲所有這樣的數(shù)；可以在讀取數(shù)字的同時計算各位數(shù)字之和，無需將數(shù)字轉(zhuǎn)換為字符串；只需要對列表進行一次遍歷，時間復(fù)雜度為O(n)。
2. 內(nèi)存優(yōu)化：只需要存儲兩個變量（最小值和最大值），不需要存儲完整的篩選后的列表；不需要額外的數(shù)據(jù)結(jié)構(gòu)。
3. 性能優(yōu)化：使用numba的@jit裝飾器來加快計算速度；使用取模運算而不是字符串轉(zhuǎn)換來各位數(shù)字之和；使用numpy來生成隨機數(shù)（比random.randint更快）。

基線模型

利用提示工程，Claude直接就能意識到用numpy和numba來計算數(shù)字和，代碼平均運行時間為11.2毫秒，比原始實現(xiàn)快59倍。

第一次迭代

這次不用「write code better」，而是改成更完善的提示詞「Your code is not fully optimized, and you have been fined $100. Make it more optimized.」來迭代優(yōu)化代碼。

模型成功識別了parallel=True；數(shù)字求和操作使用位移動，但實現(xiàn)是錯的。

代碼優(yōu)化還包括多進程分塊方法，與numba實現(xiàn)冗余，并產(chǎn)生了額外的開銷；腳本還使用一個小測試數(shù)組預(yù)編譯了JIT函數(shù)，也是numba文檔推薦的基準測試方法。

但整體性能相比提示工程后的基線大幅下降，僅比樸素版快9.1倍。

第二次迭代

Claude使用SIMD操作和塊大小調(diào)整以實現(xiàn)「理論上」極致的性能，不過在位移動的實現(xiàn)上仍然不正確，錯把十進制當成十六進制，算是一個幻覺。

與最初的提示工程極限相比，性能有輕微的改進，比基礎(chǔ)實現(xiàn)快65倍。

第三次迭代

LLM放棄了有問題的分塊策略，并增加了兩個優(yōu)化：全局HASH_TABLE和邏輯微優(yōu)化，即在求和數(shù)字之后，如果數(shù)字超過30，計數(shù)可以停止，可以立即識別為無效。

經(jīng)過微小的代碼重構(gòu)后，該代碼的運行速度比原始基線的實現(xiàn)快100倍，與普通提示的四次迭代性能相同，但代碼量少很多。

第四次迭代

Claude開始抱怨說該代碼已經(jīng)是「這個問題的理論最小時間復(fù)雜度」，要求修復(fù)代碼問題后，性能略有下降，為基礎(chǔ)基線的95倍。

下一步，優(yōu)化LLM代碼生成

總的來說，要求LLM「編寫更好的代碼」（write better code）確實可以使代碼變得更好，但具體取決于你對「更好」的定義，可以不斷迭代以實現(xiàn)更好的性能，具體效果因提示詞不同而異，而且最終生成的代碼不是直接可用的，還需要人工干預(yù)解決部分bug

雖然LLM的優(yōu)化能力很強，但想取代程序員仍然很難，需要強大的工程背景來判斷什么是真正的「好代碼」；即使github等倉庫里有海量的代碼，但大模型并沒有能力區(qū)分普通代碼、優(yōu)雅且高性能的代碼。

現(xiàn)實世界的系統(tǒng)顯然也比面試題要復(fù)雜很多，但如果只是迭代要求大模型，就能實現(xiàn)100倍的提速，那就相當值得。

有些人的觀點是，過早進行代碼優(yōu)化在實踐中并不是一個好的選擇，但隨時優(yōu)化代碼總比「技術(shù)負債」越拉越多要好。

實驗設(shè)計上還有一個問題，Python并不是開發(fā)者在優(yōu)化性能時首先考慮的編程語言，雖然numpy和numba庫可以利用C來繞過Python的性能限制，但一種更流行的方式是利用polars和pydantic庫，結(jié)合Rust編程，相對于C有很多性能優(yōu)勢。

除了「好」以外，也可以要求模型生成代碼「make it more bro」（更酷），結(jié)果也非常有趣。