不必盲從：大模型應用設計的10條大實話

技術不是萬能的，但沒有技術卻可能是萬萬不能的，對于大模型可能也是如此。基于大模型的應用設計需要聚焦于所解決的問題，在自然語言處理領域，大模型本身在一定程度上隻是将各種NLP任務統一成了sequence到sequence的模型。利用大模型， 我們是在解決具體的生産和生活中的問題，産品和技術上的設計仍然不可或缺。

那麼，如果大模型正在重新建構軟體工程的未來，我們是否應該遵循一些基本原則呢？

1. 模型優先，持續疊代

如果模型能做到的是事情，就不要寫代碼；模型會變得更好，但代碼不會。

在當今的時代，模型的價值日益凸顯。與傳統的程式設計方法不同，現在的開發思路更傾向于“模型優先”。這意味着，當我們面臨一個問題或任務時，我們首先應思考是否可以利用現有的模型來解決它，而不是立刻着手編寫代碼。因為代碼是固定的，而模型有着巨大的發展空間。随着時間的推移，模型強大的學習和适應能力能夠在不斷疊代中自我優化和進步。是以，我們的首要任務是發掘模型的潛力，讓它成為我們解決問題的利器。

對于整個系統而言，目标是利用LLM的規劃和了解意圖的能力，以此來建構高效的項目。在這個過程中，我們可能會受到誘惑，想要回到那種指令式的思維模式，為程式的每個細節編寫代碼。但是，我們必須抵制這種誘惑，在一定程度上，現在可以讓模型可靠地做一些事情，随着模型的發展，它會變得更好、更健壯。

2. 權衡精準性，采用互動進行消歧

利用權衡杠杆換取精準，使用互動來緩解模糊。使用LLM進行編碼時的正确心态不是“讓我們看看我們能讓跳舞的熊做什麼”，而是從系統中獲得盡可能多的杠杆作用。例如，可以建構非常通用的模式，如“從資料庫建構報告”或“教授一年的科目”，這些模式可以通過純文字提示進行參數化，進而輕松産生非常有價值和差異化的結果。

在追求高精準度的同時，我們必須權衡其與其他因素之間的關系。為了達到這種平衡，我們可以引入互動的方式，來消除可能出現的歧義和誤解。這種政策不僅提高了精準性，還增加了操作的靈活性和效率。

在使用LLM進行編碼的過程中，關鍵的心态不應該是“試試看能做什麼”，而應該思考如何從系統中獲得最大的杠杆效應。這意味着，我們不應僅僅滿足于簡單的功能實作，而是要深入挖掘系統的潛力，讓其為我們創造更大的價值。

實際應用中，我們可以建構一些通用的模式。比如，“從資料庫生成報告”這樣的模式，它具有很強的适應性，可以通過簡單的文本提示進行參數調整，進而應對各種需求。再例如，“教一年的深度學習課程”這樣的模式，它整合了豐富的教育資源，同樣可以通過互動方式輕松調整，滿足個性化的教學需求。

通過這些通用模式的應用，不僅提高了工作效率，還能輕松産生有價值、與衆不同的結果。這種權衡精準性與互動消歧的政策，無疑是基于大模型應用設計中的重要思維方式。

3. 代碼用于文法和過程，模型用于語義和意圖

在現代程式設計領域，代碼和模型之間的分工變得越來越明确。簡而言之，代碼主要負責文法和過程的實作，而模型則專注于語義和意圖的生成與解讀。這種分工在實際應用中有多種表達方式，但核心思想是一緻的：代碼是用來執行特定指令和流程的工具，而模型則用來解讀、生成和推理語言的深層含義和目标。

從根本上說，模型在推理語言的意義和目标時表現出色，相形之下，當它們被要求執行特定的計算和過程時，往往表現得不如代碼。例如，一個進階模型可能很容易為求解數獨編寫代碼，但如果讓它自己親自去解數獨，可能就會變得相對困難。

每種代碼都有其獨特的優勢，關鍵在于針對特定的問題選擇最适合的工具。文法和語義之間的界限，正是大模型應用設計的主要挑戰。在這個背景下，我們需要更深入地了解代碼與模型各自的優缺點，以便更為有效地利用它們解決問題。

4. 避免脆弱性，摒棄寫死

在建構任何系統時，一個不可忽視的事實是，系統的整體強度往往由其最脆弱的部分決定。這一觀點不僅适用于傳統的軟體系統，對基于大模型的應用同樣适用。

在追求系統靈活性和高效性的過程中，特别要避免寫死。寫死指的是将特定的值或邏輯直接寫入代碼，而不考慮未來的變化或擴充。這種做法在短期内可能帶來便利，但長期來看，會導緻代碼僵化，難以維護。是以，我們應該在代碼和算法中加入更多的推理和靈活性。

當設計提示語和互動時，應該盡量讓其包含足夠的資訊和邏輯，以便系統能夠自主地進行決策和推理，而不是簡單地執行預定義的指令。通過這種方式，不僅可以減少寫死的使用，還能更好地利用LLM的能力，讓系統更加智能、更加靈活。

5. 資料品質至上，LLM的應用與高品質資料息息相關

大模型确實展現出了非凡的能力，如同“受過良好教育的”個體，但在實際應用中，它們仍然缺乏某些背景和主動性。

簡單來說，如果你向這些模型提出一個簡單或開放式的問題，它們會給你一個簡單或通用的答案。這種答案可能缺乏深度或細節，無法滿足所有需求。如果希望得到更為詳盡和深入的答案，那麼提問的方式和政策就需要更為明智。

這其實是“Garbage in，Garbage out”原則在人工智能時代的一種展現。無論技術有多麼先進，輸入的資料品質仍然至關重要。如果輸入的資料是模糊、不準确或不完整的，那麼模型輸出的答案也可能同樣如此。

是以，為了確定LLM模型能夠給出高品質、有深度的答案，需要確定輸入的資料是準确、詳盡且上下文豐富的。這也意味着，資料品質仍然至上。隻有重視并確定資料的品質，才能期望從這些先進的模型中獲得真正有價值、有深度的資訊。

6. 把不确定性視為異常

每當模型遇到不确定的情況，我們不能簡單地忽略它或給出一個模糊的答案。相反，我們應該依賴于與使用者的互動意圖來澄清這種不确定性。

在程式設計中，當一組嵌套的提示中存在不确定性時——比如一個提示的結果可能有多種解讀，我們應采取一種類似于“異常抛出”的政策。這意味着，應該将這種不确定性傳遞到堆棧中的更進階别，直到到達一個可以與使用者互動或澄清不确定性的層級。

這樣的設計政策可以確定了程式在面對不确定性時能夠做出适當的回應，進而提供更為準确和可靠的結果。

7. 文本作為通用協定

文本已然成為了一種通用協定，這主要歸功于LLM對于自然語言、意圖和語義的出色解析能力。是以，文本成為了在提示語、子產品以及基于LLM的服務之間傳遞指令的首選格式。

盡管自然語言在某些應用場景下可能略顯不精确，但相較于其他結構化語言（如XML），其優點在于簡潔、直覺且易于人類了解。當然，對于那些需要高度精确和結構化的任務，仍然可以少量地采用結構化語言進行輔助。但多數場景下，自然語言在傳遞指令和意圖方面表現得相當出色。

更為值得一提的是，随着這些基于LLM的普及和進步，文本作為一種“未來證明”的自然互動方式，将進一步促進不同系統、不同提示之間的互通與了解。如果兩個完全不同的LLM服務都能夠了解和響應相同的文本指令，那麼它們之間的協作和互動将變得如同人類之間的溝通一樣自然、流暢。

将文本視為通用協定，不僅有助于我們更好地利用LLM的能力，也為建構一個更加智能、更加互通的應用程式打下了堅實的基礎。

8. 複雜問題，分解操作

當面對一個複雜問題時，不僅對人來說是一個挑戰，對大模型而言也同樣如此。在實際應用中，如果我們直接将複雜問題的提示語作為程式的一部分，可能會遇到問題，因為我們真正需要的隻是推理的結果。

為了解決這個問題，一種有效的方法是使用“元”提示。這種提示不僅可以給出問題，還能提供詳細的答案，然後要求模型從中提取關鍵資訊。這種方法的效果會很好，因為它實際上是将一個複雜的認知任務轉化為了一個相對簡單的任務。想象一下，如果給一個人一個“閱讀這篇文章并找出答案”的任務，即使該使用者沒有相關領域的專業知識，他也很有可能完成這個任務，因為自然語言的力量是巨大的。

是以，在設計基于大模型的應用時，需要注意：對一個普通人來說很難的事情，對模型來說也可能同樣困難。面對這種情況，最好的政策往往是将複雜的問題或任務分解為更簡單的步驟。這樣不僅可以降低處理的難度，還能提高答案的穩定性和準确性。

9. 凡有控制，皆有模型

模型不僅是一種工具，它也可以成為我們對抗自身錯誤的利器。很多時候，我們容易将LLM（大語言模型）的運作想象成一個“頭腦”的内部過程。然而，必須認識到，盡管模型與人類思維在某些方面有相似之處，但二者之間仍存在許多有意義的差異。

這其中有一個特點尤為重要：模型在短時間的互動中往往缺乏持久記憶。這意味着，模型在從一分鐘到下一分鐘的互動中，不太可能記住所有的細節。這一特點為我們提供了某種控制的可能性。

這種控制不僅限于代碼審查。事實上，模型還可以作為代碼的安全螢幕，確定代碼的運作安全；它也可以作為測試政策的一個元件，幫助我們制定更為有效的測試方案；甚至可以作為内容過濾器，協助我們生成高品質的内容。

是以，隻要我們對模型進行适當的控制和引導，它就能成為我們工作中得力的“助手”。而這種控制的基礎，就是我們對模型内部機制和特點的深入了解和掌握。

10. 識别邊界，不要認為大模型無所不能

大語言模型的能力确實令人驚歎，它們可以處理和解析大量的文本資料，生成有邏輯和連貫性的文本，甚至在某些任務上超越了人類的表現。然而，這并不意味着我們應該盲目崇拜這些大模型，認為它們無所不能。

事實上，大模型仍然存在着許多局限性和邊界。盡管它們可以處理大量的文本資料，但它們并不能像人類一樣真正了解語言和語境的細微差别。此外，它們的表現也受到訓練資料和算法選擇的限制，可能會出現一些偏見和錯誤。

是以，我們在使用大模型時，應該保持理性和謹慎的态度，既要欣賞它們所帶來的便利和進步，也要警惕它們的局限性和潛在風險。這樣，才能更好地利用這些模型，推動基于大模型應用的健康發展。

作者丨半吊子全棧工匠

來源丨公衆号：喔家ArchiSelf（ID：wireless_com）

dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]