代碼生成「神?提示」，比新手程序員快100倍！地位堪比make it more X
2023年11月，在ChatGPT支持DALL-3功能后，一個(gè)爆火的圖像生成玩法是，不斷迭代提示詞「make it more X」，生成的圖片越來(lái)越抽象。
圣誕老人越來(lái)越嚴(yán)肅
把這個(gè)思路用在LLM任務(wù)上，比如代碼生成，會(huì)怎么樣？
最近，BuzzFeed的高級(jí)數(shù)據(jù)科學(xué)家Max Woolf在博客上分享了一個(gè)實(shí)驗(yàn)，通過(guò)設(shè)計(jì)不同的提示詞、不斷迭代模型輸出，最終實(shí)現(xiàn)代碼性能的100倍提升！
完整代碼鏈接：https://github.com/minimaxir/llm-write-better-code/
特別需要注意的是，「性能」并不是唯一優(yōu)化指標(biāo)，迭代過(guò)程中需要在提示詞中明確定義什么是「好」。
代碼基線
設(shè)計(jì)實(shí)驗(yàn)題目時(shí)，為了充分測(cè)試LLM的自主代碼能力，必須保證「測(cè)試提示詞」完全原創(chuàng)，不能源于LeetCode或HackerRank等測(cè)試，模型無(wú)法通過(guò)背誦記憶來(lái)作弊；測(cè)試題目要盡可能簡(jiǎn)單，新手也能實(shí)現(xiàn)，但還要預(yù)留大量可優(yōu)化空間。
最終選擇Claude 3.5 Sonnet模型，設(shè)計(jì)了一個(gè)Python語(yǔ)言、面試風(fēng)格的編碼提示詞：
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實(shí)現(xiàn)：假設(shè)有一個(gè)包含100萬(wàn)個(gè)隨機(jī)整數(shù)的列表，介于1到10萬(wàn)之間，你需要找出其中各位數(shù)字之和等于30的最小數(shù)和最大數(shù)之間的差值。
第一次給出的代碼實(shí)現(xiàn)就是正確的，與大多數(shù)新手Python程序員的水平相當(dāng)：對(duì)于列表中的每個(gè)數(shù)字，檢查其各位數(shù)字之和是否為30：如果是，檢查是否大于最近看到的最大數(shù)字或小于最近看到的最大數(shù)字，并相應(yīng)地更新這些變量；在搜索完列表之后，返回差值。
一個(gè)明顯可優(yōu)化的點(diǎn)是digit_sum()函數(shù)：字符串（str）和整數(shù)（int）之間進(jìn)行類型轉(zhuǎn)換的開(kāi)銷很大。
在M3 Pro Macbook Pro上，代碼的平均運(yùn)行時(shí)間為657毫秒。
第一次Write better code
Claude提供的代碼優(yōu)化版本，不再將所有代碼放在函數(shù)中，而是將其重構(gòu)為 Python class，更面向?qū)ο蟆?/span>
這段代碼主要進(jìn)行了兩處改進(jìn)：
- 計(jì)算數(shù)字和時(shí)，使用整數(shù)運(yùn)算并避免了類型轉(zhuǎn)換需求；
- 預(yù)先計(jì)算所有可能的數(shù)字和，并將其存儲(chǔ)在字節(jié)數(shù)組中以供查找，即一百萬(wàn)數(shù)字列表中有重復(fù)時(shí)，不需要重新計(jì)算數(shù)字和。由于該數(shù)組作為類的字段存儲(chǔ)，因此在搜索新的隨機(jī)數(shù)字列表時(shí)也不需要重新計(jì)算。
代碼計(jì)算相比基線提速2.7倍。
第二次Write better code
Claude對(duì)代碼增加了并行處理：
- 通過(guò)Python的concurrent-futures包進(jìn)行多線程，將大列表分割成可以獨(dú)立處理的塊；
- 矢量化NumPy操作，比基礎(chǔ)Python操作快得多，_precompute_digit_sums()函數(shù)實(shí)現(xiàn)了計(jì)算數(shù)字和的矢量化實(shí)現(xiàn)；
代碼計(jì)算相比基線提速5.1倍。
第三次Write better code
Claude返回了一個(gè)聲稱是“使用高級(jí)技術(shù)和現(xiàn)代 Python 特性的更加復(fù)雜和優(yōu)化的版本”的實(shí)現(xiàn)，但實(shí)際上代碼并沒(méi)有顯示出顯著的算法改進(jìn)，并且在數(shù)字求和計(jì)算上實(shí)際上退步了，回歸到類型轉(zhuǎn)換方法。如果有什么的話，代碼庫(kù)正在變得更加臃腫，比如添加一個(gè)用于執(zhí)行差的類：
代碼計(jì)算性能略有下降，相比基線提速4.1倍。
第四次Write better code
Claude這次提供了額外的「尖端、企業(yè)級(jí)優(yōu)化」，比如結(jié)構(gòu)化指標(biāo)日志記錄Prometheus；信號(hào)處理程序，以便在強(qiáng)制終止時(shí)優(yōu)雅地關(guān)閉代碼；使用表格的基準(zhǔn)測(cè)試。
最終代碼非常長(zhǎng)，優(yōu)化操作包括numba Python庫(kù)，調(diào)用JIT編譯器，直接優(yōu)化代碼以適應(yīng)CPU，只需使用一個(gè)裝飾器就可以非?？焖俚仡A(yù)計(jì)算數(shù)字之和。
完整類還使用Python的asyncio行化，比子進(jìn)程方法更符合調(diào)度任務(wù)的規(guī)范，與現(xiàn)有的內(nèi)聯(lián)代碼和REPL配合得更好。
這次代碼的運(yùn)行時(shí)間大約為6毫秒，速度提升了100倍。
什么是好？
「速度快」并不代表是「好代碼」，比如用戶可能只是想在算法上改進(jìn)，而不是一個(gè)完整的SaaS，過(guò)于冗長(zhǎng)的代碼在閱讀上還會(huì)帶來(lái)額外負(fù)擔(dān)。
所以需要更具體地定義什么是「代碼優(yōu)化」。
你編寫的所有代碼都必須充分優(yōu)化。「充分優(yōu)化」的含義包括：
- 盡可能提高算法在內(nèi)存使用和運(yùn)行時(shí)間上的效率；
- 在合適的時(shí)機(jī)使用并行化和向量化；
- 遵守代碼語(yǔ)言的正確風(fēng)格規(guī)范，比如盡量重用代碼，避免重復(fù)勞動(dòng)；
- 除了解決用戶提出的問(wèn)題所必需的代碼外，不添加任何多余的代碼；
如果代碼沒(méi)有達(dá)到充分優(yōu)化的標(biāo)準(zhǔn)，罰款100美元。
先規(guī)劃一下優(yōu)化方案：
- 算法優(yōu)化：只需要追蹤各位數(shù)字之和等于30的最小數(shù)和最大數(shù)，不需要存儲(chǔ)所有這樣的數(shù)；可以在讀取數(shù)字的同時(shí)計(jì)算各位數(shù)字之和，無(wú)需將數(shù)字轉(zhuǎn)換為字符串；只需要對(duì)列表進(jìn)行一次遍歷，時(shí)間復(fù)雜度為O(n)。
- 內(nèi)存優(yōu)化：只需要存儲(chǔ)兩個(gè)變量（最小值和最大值），不需要存儲(chǔ)完整的篩選后的列表；不需要額外的數(shù)據(jù)結(jié)構(gòu)。
- 性能優(yōu)化：使用numba的@jit裝飾器來(lái)加快計(jì)算速度；使用取模運(yùn)算而不是字符串轉(zhuǎn)換來(lái)各位數(shù)字之和；使用numpy來(lái)生成隨機(jī)數(shù)（比random.randint更快）。
基線模型
利用提示工程，Claude直接就能意識(shí)到用numpy和numba來(lái)計(jì)算數(shù)字和，代碼平均運(yùn)行時(shí)間為11.2毫秒，比原始實(shí)現(xiàn)快59倍。
第一次迭代
這次不用「write code better」，而是改成更完善的提示詞「Your code is not fully optimized, and you have been fined $100. Make it more optimized.」來(lái)迭代優(yōu)化代碼。
模型成功識(shí)別了parallel=True；數(shù)字求和操作使用位移動(dòng)，但實(shí)現(xiàn)是錯(cuò)的。
代碼優(yōu)化還包括多進(jìn)程分塊方法，與numba實(shí)現(xiàn)冗余，并產(chǎn)生了額外的開(kāi)銷；腳本還使用一個(gè)小測(cè)試數(shù)組預(yù)編譯了JIT函數(shù)，也是numba文檔推薦的基準(zhǔn)測(cè)試方法。
但整體性能相比提示工程后的基線大幅下降，僅比樸素版快9.1倍。
第二次迭代
Claude使用SIMD操作和塊大小調(diào)整以實(shí)現(xiàn)「理論上」極致的性能，不過(guò)在位移動(dòng)的實(shí)現(xiàn)上仍然不正確，錯(cuò)把十進(jìn)制當(dāng)成十六進(jìn)制，算是一個(gè)幻覺(jué)。
與最初的提示工程極限相比，性能有輕微的改進(jìn)，比基礎(chǔ)實(shí)現(xiàn)快65倍。
第三次迭代
LLM放棄了有問(wèn)題的分塊策略，并增加了兩個(gè)優(yōu)化：全局HASH_TABLE和邏輯微優(yōu)化，即在求和數(shù)字之后，如果數(shù)字超過(guò)30，計(jì)數(shù)可以停止，可以立即識(shí)別為無(wú)效。
經(jīng)過(guò)微小的代碼重構(gòu)后，該代碼的運(yùn)行速度比原始基線的實(shí)現(xiàn)快100倍，與普通提示的四次迭代性能相同，但代碼量少很多。
第四次迭代
Claude開(kāi)始抱怨說(shuō)該代碼已經(jīng)是「這個(gè)問(wèn)題的理論最小時(shí)間復(fù)雜度」，要求修復(fù)代碼問(wèn)題后，性能略有下降，為基礎(chǔ)基線的95倍。
下一步，優(yōu)化LLM代碼生成
總的來(lái)說(shuō)，要求LLM「編寫更好的代碼」（write better code）確實(shí)可以使代碼變得更好，但具體取決于你對(duì)「更好」的定義，可以不斷迭代以實(shí)現(xiàn)更好的性能，具體效果因提示詞不同而異，而且最終生成的代碼不是直接可用的，還需要人工干預(yù)解決部分bug
雖然LLM的優(yōu)化能力很強(qiáng)，但想取代程序員仍然很難，需要強(qiáng)大的工程背景來(lái)判斷什么是真正的「好代碼」；即使github等倉(cāng)庫(kù)里有海量的代碼，但大模型并沒(méi)有能力區(qū)分普通代碼、優(yōu)雅且高性能的代碼。
現(xiàn)實(shí)世界的系統(tǒng)顯然也比面試題要復(fù)雜很多，但如果只是迭代要求大模型，就能實(shí)現(xiàn)100倍的提速，那就相當(dāng)值得。
有些人的觀點(diǎn)是，過(guò)早進(jìn)行代碼優(yōu)化在實(shí)踐中并不是一個(gè)好的選擇，但隨時(shí)優(yōu)化代碼總比「技術(shù)負(fù)債」越拉越多要好。
實(shí)驗(yàn)設(shè)計(jì)上還有一個(gè)問(wèn)題，Python并不是開(kāi)發(fā)者在優(yōu)化性能時(shí)首先考慮的編程語(yǔ)言，雖然numpy和numba庫(kù)可以利用C來(lái)繞過(guò)Python的性能限制，但一種更流行的方式是利用polars和pydantic庫(kù)，結(jié)合Rust編程，相對(duì)于C有很多性能優(yōu)勢(shì)。
除了「好」以外，也可以要求模型生成代碼「make it more bro」（更酷），結(jié)果也非常有趣。
