雖然“Does current AI represent a dead end?”這篇文章意在引發(fā)討論，但其中的某些觀點對軟件開發(fā)人員來說特別具有相關(guān)性：
“當(dāng)前的AI系統(tǒng)缺乏與其功能緊密相關(guān)的內(nèi)部結(jié)構(gòu)，無法作為組件進行開發(fā)或重用，也無法進行關(guān)注點分離或分階段開發(fā)?！?/p>
本文僅討論如何將大語言模型（LLM）作為產(chǎn)品解決方案的一部分，而非探討如何在開發(fā)過程中使用AI工具（例如，Cursor和Zed AI這樣的AI編碼工具）。盡管借助LLM進行特定的軟件開發(fā)生命周期活動（SDLA）確實面臨著一些挑戰(zhàn)，但我們開發(fā)產(chǎn)品的方式與最終賣給客戶的產(chǎn)品通常是有所區(qū)別的。因此，在下面的圖表中，我們關(guān)注的是上面兩個部分：
來自卡內(nèi)基梅隆大學(xué)軟件工程研究所的圖片
當(dāng)前LLM面臨的問題在于它們像汽車一樣被出售——用戶需要為整個產(chǎn)品付費，而不能指望將它們作為可組合模塊的一部分。汽車的不可分解性不是問題，因為駕駛是一項受到嚴格控制的活動。即便你能夠像樂高積木一樣將汽車組裝起來，它也不會被允許上路。
這大概正是大型科技公司所期望的——他們希望賣給你一個完整的產(chǎn)品或服務(wù)，而不是一系列可以輕松被他人進行構(gòu)建的可組合部件。保持LLM的神秘感有助于維持其高價值地位。
LLM的運作模式違背了計算領(lǐng)域的一個基本原則，即任務(wù)應(yīng)當(dāng)可以被分解。
這違背了計算領(lǐng)域的一個基本原則，即任務(wù)應(yīng)當(dāng)可以被分解。一個高效的軟件組件，無論是自行開發(fā)還是外部采購，都應(yīng)由可進行單元測試的代碼構(gòu)成。這些組件必須能夠與其他組件可靠地協(xié)同工作。
即便某個產(chǎn)品采用了Oracle數(shù)據(jù)庫，我們依然能夠明白在概念設(shè)計層面上是存在數(shù)據(jù)持久化的。在決定使用哪種類型的存儲技術(shù)時，測試機制已經(jīng)準備就緒了。同時，數(shù)據(jù)庫技術(shù)在不斷創(chuàng)新，但客戶永遠不會認為存儲廠商在某種程度上控制了軟件。
在學(xué)術(shù)界，可分解性的缺失往往與可解釋性的缺失相伴而生。我們可以歸納出其他與LLM在交付軟件中的商業(yè)問題相關(guān)的因素。
我們無法將LLM的行為與訓(xùn)練數(shù)據(jù)分離。
目前，我們無法將LLM的行為與訓(xùn)練數(shù)據(jù)分離。我們知道LLM是經(jīng)過訓(xùn)練的，但訓(xùn)練過程通常是不公開的，而結(jié)果卻被期望能夠被“原封不動”地接受。這種對組件“腌制”的期望在烹飪中或許可行，但在軟件組件開發(fā)中卻并不適用。
安全和隱私問題成為關(guān)注點，因為我們?nèi)狈煽康耐緩交蚍椒▉矸乐筁LM泄露某些敏感信息。我們無法從外部干預(yù)神經(jīng)網(wǎng)絡(luò)，向它解釋哪些信息是私密的，哪些不應(yīng)該被泄露。
法律所有權(quán)問題依然很棘手。我們可以證明冷計算的操作結(jié)果是可重復(fù)的，在輸入相同的情況下會得出相同的答案。然而，由于LLM攜帶著無法擺脫的訓(xùn)練“包袱”，我們根本無法證明它們沒有侵犯現(xiàn)有的知識產(chǎn)權(quán)——而實際上，它們很可能已經(jīng)侵犯了。
那些致力于減少碳足跡的公司正朝著與LLM廠商相反的方向前進，而LLM廠商需要驚人的計算資源來獲得遞減的性能改進。
本文并不是要討論如何使用LLM來輔助開發(fā)，也不是關(guān)于向終端用戶提供LLM工具。我使用的文本編輯器內(nèi)置了某些形式的AI功能，但這些操作沒有任何保障。我們都知道這些通常是走過場的功能——某些必須出現(xiàn)在產(chǎn)品中的“噱頭”，而并非核心組成部分。
我認為LLM作為服務(wù)被引入產(chǎn)品的前景不大，除非LLM本身就是產(chǎn)品。
鑒于前面提到的原因，我認為LLM作為服務(wù)被引入產(chǎn)品的前景不大，除非它本身就是產(chǎn)品。但即便如此，這對任何企業(yè)來說都是一個巨大的陷阱。當(dāng)Zoom創(chuàng)始人Eric Yuan提出在Zoom中引入AI替身代替與會者參加會議的想法時，理所當(dāng)然地遭到了嘲笑，他認為這種能力會在“技術(shù)棧的底層”自然而然地出現(xiàn)。將重大創(chuàng)新外包給了LLM廠商，實際上是將自己的產(chǎn)品路線圖交給了另一家公司掌控。
軟件開發(fā)人員應(yīng)該如何應(yīng)對
那么，軟件開發(fā)人員應(yīng)該如何應(yīng)對？我們都明白，一個組件應(yīng)該有明確的職責(zé)，應(yīng)該能夠被替換，并且能夠與其他組件一起被測試。如果是外部組件，也應(yīng)當(dāng)遵循相同的計算標準——而且我們應(yīng)該能夠依據(jù)這些標準來重新構(gòu)建它們。
我們不應(yīng)因追求短期的熱度而輕易改變游戲規(guī)則。關(guān)鍵在于要設(shè)計一個能夠為企業(yè)提供所需功能的流程，然后開發(fā)一個平臺，以可持續(xù)的方式讓開發(fā)人員進行構(gòu)建。
作為開發(fā)人員，我們應(yīng)當(dāng)保持開放的態(tài)度，擁抱真正可解釋、可測試的AI。
作為開發(fā)人員，我們應(yīng)當(dāng)保持開放的態(tài)度，擁抱真正可解釋、可測試的AI。如果涉及訓(xùn)練過程，這個過程應(yīng)當(dāng)是可監(jiān)控、可報告、可重復(fù)、可解釋且可逆的。如果我們發(fā)現(xiàn)LLM認為某件事是真實的，而實際并非如此，那么必須能夠通過一系列明確的步驟迅速進行修正。如果這樣的描述沒有意義，那么目前基于LLM的計算也同樣沒有意義。但理論上，我看不出為什么未來不能改變這一現(xiàn)狀。
我擔(dān)心的是，這種差異就像是科學(xué)與圣物信仰之間的對比。我們可以進行一系列不可行的實驗（如果將圣物切成幾塊，這些碎片是否依然保持其神圣性？），但不應(yīng)該期望這兩個領(lǐng)域會有任何融合的可能性。
本文來源：博客園
文章轉(zhuǎn)載于其他網(wǎng)絡(luò)，如有侵權(quán)請聯(lián)系我們及時刪除！
