技術不是萬能的，但沒有技術卻可能是萬萬不能的，對於大模型可能也是如此。基於大模型的應用設計需要聚焦在所解決的問題，在自然語言處理領域，大模型本身在某種程度上只是將各種NLP任務統一變成了sequence 到 sequence 的模式。利用大模型， 我們是在解決具體的生產和生活中的問題，產品和技術上的設計仍然不可或缺。
那麼，如果大模型正在重新建構軟體工程的未來，我們是否應該遵循一些基本原則呢？
如果模型能夠完成任務，就沒必要寫程式碼；模型會不斷進化，但程式碼卻不會
在當今時代，模型的價值越來越凸顯。與傳統的程式設計方法不同，現在的開發思路更傾向於"模型優先"。這意味著，當我們面臨一個問題或任務時，我們首先要考慮是否可以利用現有的模型來解決它，而不是立即著手編寫程式碼。因為程式碼是固定的，而模型具有巨大的發展空間。隨著時間的推移，模型具有強大的學習和適應能力，能夠透過不斷迭代自我優化和進步。因此，我們的首要任務是挖掘模型的潛力，讓它成為我們解決問題的利器
整個系統的目標是利用LLM的規劃和理解意圖的能力，以建立高效的專案。在這個過程中，我們可能會受到誘惑，想要回到那種命令式的思考模式，為程式的每個細節編寫程式碼。但是，我們必須抵抗這種誘惑，在某種程度上，現在可以讓模型可靠地做一些事情，隨著模型的發展，它會變得更好、更健壯
利用權衡槓桿換取精準，使用互動來緩解模糊。使用LLM進行編碼時的正確心態不是“讓我們看看我們能讓跳舞的熊做什麼”，而是從系統中獲得盡可能多的槓桿作用。例如，可以建立非常通用的模式，如“從資料庫建立報告”或“教授一年的科目”，這些模式可以透過純文字提示進行參數化，從而輕鬆產生非常有價值和差異化的結果。
在維持高準確度的追求中，我們需要權衡其與其他因素之間的關係。為了達到這種平衡，我們可以採用互動的方式，以消除可能出現的歧義和誤解。這項策略不僅提高了準確性，還增加了操作的靈活性和效率
在使用LLM進行編碼的過程中，關鍵的心態應該是思考如何從系統中獲得最大的槓桿效應，而不是「試試看能做什麼」。這意味著，我們不應該僅僅滿足於簡單的功能實現，而是要深入挖掘系統的潛力，讓其為我們創造更大的價值
實際應用中，我們可以建立一些通用的模式。例如，「從資料庫產生報告」這樣的模式，它具有很強的適應性，可以透過簡單的文字提示進行參數調整，從而應對各種需求。再例如，「教導一年的深度學習課程」這樣的模式，它整合了豐富的教育資源，同樣可以透過互動方式輕鬆調整，滿足個人化的教學需求。
透過這些通用模式的應用，不僅提高了工作效率，還能輕鬆產生有價值、與眾不同的結果。這種權衡精準性與互動消歧的策略，無疑是基於大模型應用設計中的重要思考方式。
在現代程式設計領域，程式碼和模型之間的分工變得越來越明確。簡單來說，程式碼主要負責實作語法和過程，而模型則專注於產生和解讀語意和意圖。在實際應用中，這種分工有多種表達方式，但核心思想是一致的：程式碼用於執行特定指令和流程，而模型用於推理、生成和理解語言的深層含義和目標
#從根本上說，模型在推理語言的意義和目標時表現出色，相形之下，當它們被要求執行特定的計算和過程時，往往表現得不如代碼。例如，一個高階模型可能很容易為求解數獨編寫程式碼，但如果讓它自己親自去解數獨，可能就會變得相對困難。
每個程式碼都有其獨特的優勢，關鍵在於選擇最適合特定問題的工具。語法和語意之間的界限，正是大型模型應用設計面臨的主要挑戰。在這種背景下，我們需要更深入地了解程式碼和模型各自的優缺點，以便更有效地利用它們來解決問題
在建構任何系統時，一個不可忽視的事實是，系統的整體強度往往由其最脆弱的部分決定。這個觀點不僅適用於傳統的軟體系統，對基於大模型的應用同樣適用
在追求系統的靈活性和高效性時，應該盡量避免硬編碼的方式。硬編碼指的是直接在程式碼中寫入特定的數值或邏輯，而不考慮未來可能的變化或擴展。雖然這種做法可能在短期內帶來方便，但從長遠來看，會導致程式碼僵化，難以維護。因此，我們應該在編寫程式碼和演算法時注重推理和靈活性的加入
當設計提示語和互動時，應該盡量讓其包含足夠的資訊和邏輯，以便系統能夠自主地進行決策和推理，而不是簡單地執行預先定義的命令。透過這種方式，不僅可以減少硬編碼的使用，還能更好地利用LLM的能力，讓系統更聰明、更有彈性。
大型模型確實展現出了非凡的能力，就像「受過良好教育的」個體一樣，但在實際應用中，它們仍然缺乏一些背景和主動性
簡單來說，如果你向這些模型提出一個簡單或開放式的問題，它們會給你一個簡單或通用的答案。這種答案可能缺乏深度或細節，無法滿足所有需求。如果希望得到更詳盡和深入的答案，那麼提問的方式和策略就需要更明智。
這其實是「Garbage in，Garbage out」原則在人工智慧時代的一種體現。無論技術有多先進，輸入的數據品質仍然至關重要。如果輸入的資料是模糊、不準確或不完整的，那麼模型輸出的答案也可能同樣如此。
為了確保LLM模型能夠給出高品質、有深度的答案，需要確保輸入的資料準確、詳盡且上下文豐富。這也意味著數據品質仍然是最重要的。只有重視並確保資料的質量，才能期望從這些先進的模型中獲得真正有價值、有深度的資訊
每當模型遇到不確定的情況，我們不能簡單地忽略它或給出一個模糊的答案。相反，我們應該依賴與使用者的互動意圖來澄清這種不確定性。
在程式設計中，當一組嵌套的提示中存在不確定性時－例如一個提示的結果可能有多種解讀，我們應採取一種類似於「異常拋出」的策略。這意味著，應該將這種不確定性傳遞到堆疊中的更高級別，直到到達一個可以與使用者互動或澄清不確定性的層級。
透過這樣的設計策略，程式可以在面對不確定性時做出適當的回應，從而提供更準確和可靠的結果
文本已經成為一種普遍的協議，這主要歸功於LLM在解析自然語言、意圖和語義方面的出色能力。因此，文字成為了在提示語、模組和基於LLM的服務之間傳遞指令的首選格式
儘管自然語言在某些應用場景下可能略顯不精確，但相較於其他結構化語言（如XML），其優點在於簡潔、直覺且易於人類理解。當然，對於那些需要高度精確和結構化的任務，仍然可以少量地採用結構化語言進行輔助。但在多數場景下，自然語言在傳遞指令和意圖方面表現得相當出色。
值得一提的是，隨著這些基於LLM的技術的普及和進步，文本作為一種「未來證明」的自然互動方式，將進一步促進不同系統、不同提示之間的互通與理解。如果兩個完全不同的LLM服務都能夠理解和回應相同的文字指令，那麼它們之間的協作和互動將變得如同人類之間的溝通一樣自然、流暢
將內容進行改寫的目的是為了不改變原始意思，而將語言改寫為中文
當面對一個複雜問題時，不僅對人來說是一個挑戰，對大模型也是如此。在實際應用中，如果我們直接將複雜問題的提示語作為程式的一部分，可能會遇到問題，因為我們真正需要的只是推理的結果
為了解決這個問題，一種有效的方法是使用“元”提示。這種提示不僅可以給出問題，還能提供詳細的答案，然後要求模型從中提取關鍵資訊。這種方法的效果會很好，因為它實際上是將一個複雜的認知任務轉化為了一個相對簡單的任務。想像一下，如果給一個人一個「閱讀這篇文章並找出答案」的任務，即使該用戶沒有相關領域的專業知識，他也很有可能完成這個任務，因為自然語言的力量是巨大的。
在設計基於大模型的應用時，有一些需要注意的事項。一般人覺得困難的事情，在模型上也可能同樣困難。面對這種情況，最好的策略是將複雜的問題或任務分解成更簡單的步驟。這樣可以降低處理的難度，同時提高答案的穩定性與準確度
#模型不僅是一種工具，它也可以成為我們對抗自身錯誤的利器。很多時候，我們容易將LLM（大語言模型）的運作想像成一個「頭腦」的內在過程。然而，必須認識到，儘管模型與人類思維在某些方面有相似之處，但二者之間仍存在許多有意義的差異。
這其中有一個特點特別重要：模型在短時間的互動中往往缺乏持久記憶。這意味著，模型在從一分鐘到下一分鐘的交互作用中，不太可能記住所有的細節。這項特點為我們提供了某種控制的可能性。
這種控制不僅限於程式碼審查。實際上，模型還可以充當程式碼的安全監視器，確保程式碼的安全運行；它還可以作為測試策略的一個組成部分，幫助我們制定更有效的測試方案；甚至可以充當內容過濾器，協助我們產生高品質的內容
因此，只要我們對模型進行適當的控制和引導，它就能成為我們工作中得力的「助手」。而這種控制的基礎，就是我們對模型內部機制和特性的深入了解與掌握。
大語言模型的能力確實令人驚嘆，它們可以處理和解析大量的文本數據，產生有邏輯和連貫性的文本，甚至在某些任務上超越了人類的表現。然而，這並不意味著我們應該盲目崇拜這些大模型，認為它們無所不能。
大型模型實際上仍然存在許多限制和限制。儘管它們能夠處理大量的文字數據，但它們並不能像人類一樣真正理解語言和脈絡的微妙差異。此外，它們的表現也受訓練資料和演算法選擇的限制，可能會出現一些偏見和錯誤
因此，我們在使用大模型時，應該保持理性和謹慎的態度，既要欣賞它們所帶來的便利和進步，也要警惕它們的限制和潛在風險。這樣，才能更好地利用這些模型，推動基於大模型應用的健康發展。
#以上是大模型應用設計的十個思考的詳細內容。更多資訊請關注PHP中文網其他相關文章！
