AI News HubLIVE
站內改寫2 分鐘閱讀

AI軟體開發——資料說明了什麼?

作者基於多項近期研究、行業資料和實驗,指出LLM用於軟體開發時存在根本侷限:有效上下文遠低於宣傳、無法處理長程依賴與否定、倉庫級文件反而有害;大型行業研究顯示產出增加但結果惡化。AI編碼是放大器而非解決方案,近期可靠性提升只能依靠上下文工程與質量門。

來源Hacker News AI作者: jesterpm

作者正在整理一批關於大語言模型(LLM)在軟體開發中應用的近期資料,來源包括同行評審研究、未經同行評審的行業研究、統計物理學論文,以及一篇關於上下文大小影響的部落格文章。這些結論大多與作者的個人實驗和團隊觀察相互印證。隨著新資料不斷出現,作者對這一領域的認識也日益清晰。

對於時間有限的決策者,作者給出一個核心結論:依靠LLM實現真正自主、可靠的長週期代理式軟體開發,可能性極低,基本上屬於科幻範疇。LLM的最大有效上下文視窗比廠商宣傳的數值要小若干個數量級;超出該範圍,模型輸出就會變得不可靠。廠商常說的“壓縮”機制,實際上是讓模型對部分上下文進行摘要,而摘要本身是有損且不可靠的過程。LLM無法區分上下文中的新舊資訊,也無法區分訓練時學到的“主導先驗”與使用者提供的資訊;對模型而言一切都只是令牌、權重和機率。更大的上下文還會引發“注意力稀釋”,使上下文中的機率難以與模型內機率競爭,進一步加劇錯誤。

倉庫級別的Markdown檔案往往會讓模型表現更差,可能是因為在具體任務中它們帶來的是噪音而非訊號;模型生成的Markdown檔案問題尤為嚴重。這可能意味著,把團隊編碼標準和架構摘要放入每個任務反而適得其反。LLM還在處理否定語義時存在困難,告訴模型“不要做某件事”有時等於告訴它去做那件事,這也解釋了為什麼某些防護措施的效果如同拋硬幣。相比之下,給模型提供示例(demonstration)比純文字描述更有效——它們是模式匹配器,應該多給“像這樣”的樣例,少用“這樣做”,更不要用“別這樣做”。

大型行業研究呈現出清晰趨勢:程式碼產量上升,提交數和差異變大,但結果並未改善,甚至平均而言團隊交付更慢、軟體質量更差。這再次證明軟體開發不是流水線生產。少數團隊在結果上獲得溫和提升,而這些團隊原本就具備較強的開發能力。AI程式設計更像是開發強項與弱項的放大器,而不是修復手段。心理學和認知研究還發現,對AI輸出的信心與超自然信念之間存在顯著相關;多項研究顯示,越多依賴LLM,學習、認知和批判性思維受到的負面影響越大;開發者在大量使用AI後感到動力下降和倦怠,也並非空穴來風。

從深度學習的基礎來看,包括LLM在內的深度神經網路在學習長程依賴模式上存在困難,無論模型規模多大。它們始終像是在霧中行車,區域性、短程機率會擠掉長程機率,因此在處理“大局”時表現得模糊。要讓LLM的可靠性提高一個數量級——比如從30%的錯誤率降到3%——所需能源和算力大約是當前前沿模型的10^20倍。因此,短期內不要指望模型顯著更可靠。未來的可靠性提升主要來自兩方面:更好的上下文工程(決定在輸入中包含什麼)以及更有效的質量門(決定如何處理輸出)。我們看到AI公司目前也正在這些方向發力。模型會變得更強,但不會顯著更可靠。

面對“模型基準在不斷提升”的質疑,作者指出有研究認為應更加懷疑基準測試的有效性:許多流行基準測量的是易於用演算法衡量的東西,與雜亂、不可預測的真實問題不同;而且越來越明顯的是,模型可能在針對公開測試集“訓練”,即如果基準資料出現在訓練語料中,模型的表現自然會虛高。

最後,作者提到他將在10月6日18:45(英國夏令時)舉辦一場活動,討論為什麼敏捷軟體開發的技術實踐與AI輔助和代理式軟體工程高度契合,並提供了一種無炒作、基於證據的視角。感興趣的讀者可透過文末連結報名。