序言
在當下生成式模型的AI時代，瞭解和使用AI相關技術是前後端研發同學遲早要面對的事。
所有產品都值得用AI去重新做一遍。其根本原因在於當下AI的形態即生成式模型是通過AI輔助來改變和創造新的產品形態，而不是像以往的技術一樣只是對現有產品形態的補充。
簡單來說，產品研發同學可以做的事情更多了。
一、當代AI的特點
當代AI來勢洶洶，具備了通用的面向不同領域甚至全模式的強大推理能力，各類理論實踐也在這兩年爆炸式增長一時洛陽紙貴，大家對當代AI的瞭解基本在一個起跑線上，這也是當代AI魅力十足的重要原因之一。
對於AI，已有大量的研究表明，人的意識是非算法的，從哥德爾不完備定理到圖靈不可計算問題都已經證實了基於圖靈機的人工智能，也就是當代基於語言模型的預訓練大模型 AI，是無法建立“自我”這個概念的。
因此當代AI仍然是以圖靈理論架構爲支撐，解決的仍然是圖靈可計算問題，因此仍然需要一個良好可持續的應用架構去約束、引導並管理他。
二、對研發的挑戰
回到現實，前端、後端等研發同學現有的經驗和知識在短時間內還無法跨越這個門檻。而且如大模型算法、訓練推理加速、異構計算等等也不是前後端研發同學的領域和優勢。
但從最近大量湧現的AIGC相關實踐文章，可以看到很多實踐者也並非算法同學，這也說明前後端研發同學完全是可以做到的。也就是說只是基於現有大模型去做應用的門檻還是可以跨越的。
三、AI應用工程
當前所謂面向AI開發是向大模型不斷輸入Prompts，在對上下文 / 語境的控制下推理並得到我們期望結果的過程。
整個推理過程的效率以及結果的質量，除了大模型穩定性這個大前提外，最大的因素還在於我們的實踐經驗，也就是向AI提問或引導AI的技術。
想象下我們面前的是人而不是AI，那應該如何通過對話去建立語境產生引導，使對方滿足我們的需求，即便這個需求是不合理的。有一本書《The Art of Deception》專門爲這種場景提出了所謂社工學（Social Engineering）概念。
同樣的，與之對應的適用於AI的則是當下熱門的提示詞工程（Prompts Engineering），之前就有人試過讓ChatGPT扮演奶奶給孫子講關於Windows激活碼的故事得到了真正可用的MAK KEY。而這種類似人類社工學（Social Engineering）的提示詞工程（Prompts Engineering）讓AI解決需求的過程完全顛覆了傳統編程常識。
四、AI場景分化
區別於AIGC內容生成這樣籠統的概念，AI需要在不同場景分化爲不同的特性，以下是比較典型的三類智能化場景：
4.1 知識密集型
與傳統知識類場景不同，在AI時代我們還可以有知識摘要、提取、總結、分類，以及內容加工轉換等等場景[12]。
比如，將知識結構化，轉化爲圖譜（如腦圖、流程圖、架構圖等等），細節內容補充（如增加示例、註釋）等等。
4.2 交互密集型
如：角色扮演、社交輔助、場景顧問、輔助決策、辦公辦文綜合協調等等強調大模型扮演不同角色的人機交互類輔助場景[15]。
4.3 文本/代碼型
除了大段非結構文本生成，還有在低代碼、無代碼、混合研發場景中，與代碼生成、代碼測試，代碼轉譯、代碼評審等與編碼相關的專業領域[15]。
可見我們面臨的智能化場景問題是比較複雜的，很難通過人類預先思考固化去解決這種千變萬化的需求，因爲這些場景的自由度太大了。與一般編程語言的區區十幾個關鍵詞相比，人類思維是自由的難以約束的，這種情況下的將口語化的Prompts用在AI應用上想要解決複雜問題，這近乎是不可控的。
因此，如何將AI應用工程化爲可控的，解決當下的大模型幻覺、漂移等問題，這是非常值得推敲也是我們討論的核心問題。我們有必要引入新的理論指導產生新的架構去解決這些問題。
五、推理能力
下面將以業界對大模型的典型算法以及實踐架構進行說明：
5.1 基礎推理
我們使用大模型的核心能力就是推理，下面介紹幾種業界知名的AI推理方案。
5.1.1 Standard IO
當沒有推理過程時，我們向大模型發問他會直接給出答案，這種0過程的推理被稱爲Standard IO。在大部分情況下Standard IO都是不能一步到位解決我們問題的，需要我們自行甄別以及進一步引導，這幾乎無法用於複雜任務，所以一般被作爲各類優化實驗中的對比參照。
5.1.2 Chain of Thought (CoT)
在2022年，著名的Chain of thought(CoT) [11] 論文的發表爲AI對複雜任務的處理起了關鍵作用，即將一個複雜任務拆分成多個可管理的簡單子任務，讓大模型一步步地去思考，使每個小任務的提示和推理都是可控的。
可以簡單理解爲，“一個問題，不直接讓大模型給出結果，而是讓大模型一步一步的推理產生推論，並最終給出結果”。這個技術常常在Zero-Shot/Few-Shot下取得的結果很好。CoT已經是AI應用工程裏的必備範式了，就好像面向過程的開發模式一樣，接下來我們會一直使用他。
5.2 Chains架構
到這裏不得不提一下Chains[24]，Chains是著名的大模型應用開發框架Langchain提供的一個模塊，名如其義，chains的架構可以理解爲是CoT的落地及延伸，從最基礎的LLMChain再到常見場景的：APIChain、Retrieval QAChain、SQL Chain等等：
可以看到，在Chains架構中，每一個從Prompt到Answer的過程，都被標準化爲不同類型的LLMChain。
整個需求從提出到結果的具體流程則被抽象成多個LLMChain的串聯，在表現形式上非常像我們熟知的結構化以及函數式編程。
這是一個好消息，如果說Prompts和Answer是水和土壤，有了CoT的理論指導加上Chains的架構就好像開渠造河，將原本由AI隨意發散而不可控的推理過程固化到了Chain和Chain的連接上，讓一切都回歸到我們認知中流程應有的樣子。
但這真的是未來的AI應用開發嗎？Chains這種依賴人腦思考並固化推理過程的做法就是AI的全部嗎？
說到這裏，可以思考一個問題：
在AI領域中我們是否用AI這塊金子做鋤頭，我們解決需求的方式是鋤地嗎？在你的直覺中是否認爲AI的能力和用法不僅僅如此，這是否是傳統架構或者編程範式限制了我們的想象力？
5.3 更好的推理
5.3.1 CoT Self-Consistency(SC)
2023年5月，SelfCheckGPT[7] 論文中提到一種稱爲Self-Consistency的機制爲幻覺檢測作出了重要貢獻，可以簡單理解爲“一個問題，讓多個人參與多步思考和回答，最終由另一個人去評分，選出一個最佳答案。”
爲一個問題一次性生成多個CoT，併爲每個CoT的推論投票，最終得到最接近結果的推論，投票的是一個評價函數，常用的是BERT Score或n-gram。
5.3.2 Tree of Thought (ToT)
還是在今年，Tree of Thoughts（簡稱ToT）論文[10]發表。如果說CoT是一條鏈，那麼ToT是由多條CoT鏈構成的一棵樹，ToT揭示了AI是可以通過推理決策過程自主延伸的，這是一個重大的突破。
CoT強調的是任務分解爲子任務的過程，而ToT則強調了分解任務就是生成多個思考過程，最終整個ToT會形成一個思維樹結構，這樣我們可以方便的將複雜問題到結果的思維路徑作爲Tree這樣的經典數據結構，使用廣度優先(BFS)或深度優先(DFS)查找來解決一個複雜問題，其中思維路徑也就是CoT的每個推論狀態則由前面提到的Self-Consistency或者其它等更先進方式去評估。
通過這種方式形成的以大模型自我推理決策的Tree結構是基於AI的場景下鑽和邏輯自洽來完成的，簡單來說，它替代了之前人類要做的關於理解、分析、執行、驗證的整個過程在反覆推演直到得出正確結果的整個過程。
六、增強語言模型 (ALM)
說到這裏，我們已經擁有了有限範圍內的自動推理和幻覺識別能力了，但大模型的潛力還不止這些。圖靈獎的Yann LeCun（楊立昆）在2023年年初發表的論文裏提到了增強語言模型Augmented Language Model (ALM)這個概念，提到了關於ALM的三個部分：
- 推理：將潛在複雜任務分解爲簡單子任務，子任務是可以用語言模型自身能解決或者調用其他工具可解決。
- 行爲：ALM調用的工具會對虛擬或者真實世界產生影響並觀測到結果。
- 工具：語言模型通過規則或者特殊token調用外部模塊的能力，包括檢索外部信息的檢索系統，或者可以調用機器手臂的工具等。
當下我們能使用的大模型的上下文長度都太小了，無法跟上應用規模的擴增，因此大模型應當有從外部獲取數據或者影響外部來擴充上下文的能力，這裏的這個外部我們稱作爲環境。
比如“大模型操作機械手從桌上拿起了一杯咖啡”[16]，對於這個Act來說Tools是機械手，Action是拿起，Action Input是桌上的咖啡，而"咖啡在機械手中”，“桌上沒有咖啡了”則是Observation[16]。
圖中這個WebGPT[17] 的示例非常像gpt版bing，他是一個比較純粹的Act類大模型，向WebGPT提出Question時，WebGPT會向Web搜索並給出建議結果，用戶可以排序過濾這些結果後，再由WebGPT加工生成Answer。
ReAct [2][12]
之前，Acting和Reasoning一直是分開玩的，即使做在一起也並非以架構思維去看待，在2022年10月，ReAct的提出，最終Reasoning和Acting被連接在一起，並已經成爲當下最能打的事實上的標準。那麼對於這個架構，應用工程化的實踐是怎麼樣的呢？
七、Agents架構
自今年4月的AutoGPT初始版本驚豔面世起就迅速在AI應用圈子傳的火熱，其一原因是AutoGPT的表現似乎更加貼近我們對AI應用架構的嚮往：
對於AutoGPT，我們只需要給他設定一個需求目標並授予他資源以及向資源交互的能力，再提供一組限制他行爲的規則，那麼他就可以通過“自問自答”的方式逐漸接近目標，再借助對結果的評估，最終完成需求。
很典型的，與Chains依賴人腦思考並固化推理過程的做法不同，他似乎在讓AI自我啓發的產生推理過程。相比chains架構，AutoGPT的Reasoing、Acting過程都是自動的，在實踐上否定了人類在Prompts工程上的優勢。
但這種未經修飾的原始自問自答的方式雖然可以幫助我們解決一些複雜的問題，但其推理決策能力相比人腦思考並固化推理決策過程的方式低效太多，具體表現在解決現實世界決策任務方面的有效性和靈活性不足。其參與現實世界的能力有限以及缺乏基準導致了這些不確定性。因此還需要更多的優化才能接近我們對AI應用架構的理想設計。
業界也早就注意到了推理決策過程在應用架構中的重要性，併爲Auto-GPT類似應用做有效性和靈活性的基準考量。從LangChain Agents 還有最近的 huggingface 公佈的還在試驗階段的 Transformers Agent，還有遊戲開發領域的 Unity ML-Agents 中，我學習到了當下階段按場景分化的更加完善的AI應用架構即Agents架構：
Agents [13] [24]
一個典型的Agents架構包括有以下部件：
7.1 Agent
一個調優的專用於推理與動作（reasoning and acting）的大模型，他的核心能力是規劃任務和反思\持續完善，需要有強大的推理決策能力。
7.1.1 任務規劃
任務規劃：將大型任務分解爲更小的可被管理的子目標，這樣就可以高效的執行復雜任務。
XoT & ReWOO [4]
之前分享推理時提到的XoT（CoT、Cot-SC、ToT）都是比較典型的。另外介紹ReWOO，這也是一個基於計劃的方案，思路是，當問題被提出時，制定出解決這個問題的各個Plan，並把Plan的結果留空（稱爲藍圖），Plan作爲一個個的Act交由Worker執行，執行的結果被填充到這個藍圖中，最終交由大模型得出結果，與一般方案不同，他不需要按步就班的去執行，這是突出“規劃”能力的一個很好的方案。
7.1.2 反思和持續完善
再是反思和持續完善，簡單來說就是爲大模型提供改進方案，幫助它從之前的錯誤中去學習，以更好的完成將來的任務。
ART[6] & Reflexion[15] [8]
拿ART來說，這是一個需要監督的方案，可以將發生過的推理過程沉澱下來，並在將來召回再使用。過程可以描述爲：一個Task Library存放了多種類型任務的CoT，當向ART實例提問時，會從TaskLibrary中找到最適合的Task案例與用戶的問題一起向大模型提問，最終結果由人腦評審並修正，結果會持久化到TaskLibrary。
而右邊提到的Reflexion則將人腦部分換成了語言模型，轉換成了由大模型自我學習優化自身行爲，通過嘗試、錯誤和自我反思來解決決策、編程和推理任務的架構。
在業界中比較優秀的案例有ReAct、BabyAGI等等，而ReAct是當下的事實標準，影響力深遠。而OpenAI也在最近公佈的Function Call中提供了基於GPT3.5 turbo \ 4.0的調優規劃模型(0613版)。
7.2 Memory
memory包括Context和History[13]。
7.2.1 Context
語境上下文，這個我們比較熟悉了，類似人腦的STM(Short-term memory 短期記憶)，爲Agent提供上下文能力，當下大模型的提示詞工程化就是基於上下文的。
7.2.2 History
回憶，類似人腦的LTM(Long-term memory 長期記憶），爲Agent提供了存儲和召回關聯數據的能力。
RAG[9] [14] & FLARE [8]
像WebGPT一樣檢索數據就是非常常見的場景，區別於傳統的內容檢索，我們也有一些通過大模型增強檢索的方案，如：RAG、FLARE等。
在實踐中通常選擇支持快速最大內積搜索（MIPS）的近似最近鄰 (ANN) 算法數據庫與這些方案配套，這塊有很多向量數據庫可供選擇了，也是當下市場上的熱門領域，不過多闡述，有興趣的同學可以瞭解下阿里雲的基於Tail的VectorDB，以及雲原生向量數據倉庫AnalyticDB PostgreSQL版，這裏就不詳細介紹了。
7.3 Tools
一組工具集或者Agent可以利用的所有外部資源，這是Agent可調用、可執行的能力，它既可以是一個函數、api，還可以是其它任何大模型，包括另一個Agent應用等等。[13]
ChatGPT的插件以及OpenAI API Function Calls都是Tools應用範疇的最佳案例。
當下適用於互聯網的常用思路是提供不同領域的api以及這些api的說明用法文檔，由Agent的推理去判斷需要使用的api在Tools中是否存在，這是個不斷查閱、調用、證實的過程：
API Bank: Augment Tool[3]
API Bank是一個Benchmark工具，在他的論文裏爲我們提供了一個可行的API調用思路：
- Step1. 向Agent提供API Manual Agent可以在它各個規劃任務中，使用關鍵詞去API Manual中檢索並總結出所需API用法，用法說明可以按Prompts Engineering提出的方案，利用Few-Shot或者Zero-Shot CoT去引導Agent。
- Step2. 向Agent提供API和輸入檢查器 當Agent已經掌握API的用法後，Agent可以生成API所需參數，並調用API獲取結果，這個過程需要不斷的檢查輸入的參數是否正確，以及評估輸出的結果是否符合預期。
八、對未來的思考
相比Chains，Agents真正的發揮了AI的潛力，也是即將開始流行的先進架構。在我對Agents的理解中，它更像一個圖靈機的實現架構而不是我們平時討論的應用層架構。
我們回憶一下圖靈理論架構爲支撐的馮諾依曼架構或者近似的哈佛架構。
一個事實是，在馮諾依曼架構或者哈佛架構設備的實際開發中，我們會去關心如何使用相應協議去尋址去讀寫總線操作不同設備，如UART、I2C、SPI總線協議，這都是我們要學習掌握的，但我們基本不會關心CPU中的CU、ALU等單元。
另一個事實是，PC CPU內部是多總線的哈佛架構，而在CPU外又是基於單一總線的馮諾依曼架構，而片上系統（SOC）又會在不同場景DSP、ARM等進一步集成與高速運算相關的部件。
計算機架構這樣求同存異的繼續發展下去，將這些單元與高速存儲及總線等作爲抽象概念去進一步封裝。而AI應用也是類似的，Agent會將相關的規劃反思改進能力不斷的作爲自身的核心能力封裝。
因此，對於未來的AI應用極有可能不是在傳統計算機上運行的程序，而是標準化的需求，在以規劃能力專精的Agent 大模型作爲CPU的AI計算機虛擬實例上直接運行的，而我們今天所談論的應用架構，也會沉積到底層轉變爲AI計算機的核心架構。
AI計算機中以規劃決策專精的Agent 大模型將會以規劃決策能力的評估(Benchmark)取代傳統以核心數、頻率GHz爲標準的計算單元評估體系，而AI計算機依賴的外圍設備即Tools也會在不同的專業領域中更加深入以提供更專業的執行能力。
最終AI計算機將圖靈完備，通過AI的自舉將迭代產物從工程領域提升到工業領域。
而AI廠商也將從當下以MetaGPT、AgentVerse等Multi-Agents方案轉變爲對AI計算機以及相關集羣或其它整合方案廠商，技術人員可能成爲AI計算機架構研發，或者不再單一職責，轉變爲需求設計和開發落地二合一的“高階角色”，一人公司時代可能會提前到來。
作者｜偏左
點擊立即免費試用雲產品 開啓雲上實踐之旅！
本文爲阿里雲原創內容，未經允許不得轉載。