ChatGPT 的出現讓大模型再一次成為業界的關注熱點，然而，并不是每個組織都要去訓練及生成大模型的，而且各個組織的技術積累和計算資源也不太允許這樣去做。更多的時候， 我們還是基于大模型開發業務應用。所謂智能原生（AI Native），往往是指那些沒有大模型就無法成立的應用，那是一些新的業務機會和挑戰。很多時候， 我們還只是Applied AI， 即通過AI 尤其是大模型為應用賦能。
不論是AI 原生還是AI 賦能的應用，都會面臨如何構建基于大模型APP 的問題，基于大模型的App 在系統架構和開發方式上有什么不同呢？
1. 試圖理解LLM 的能力邊界
AI 并不神秘， 也不存在迷信。應用任何一種技術都應該了解它的能力邊界，不但知道它能干什么，還要知道它不能干什么，或者至少要知道這種技術當前的局限是什么。
1.1 LLM 的基本能力
到目前為止，大模型的主要能力如下：
使用LLM進行語言理解和處理，而不是作為知識源
LLM是在互聯網上的大量文本數據上進行預訓練的，這些訓練數據為大模型提供了知識。這也允許大模型在廣泛的任務中進行泛化，然后下游進行微調。
在構建基于大模型的App時，很容易將這些LLM簡單地用作知識/事實源（即搜索引擎）。實際上，我們應該利用LLM強大的語言理解和處理能力。這將允許它“理解”用戶請求并提供“響應”。它應該提供與目標應用程序相關的知識和數據，并且只應從我們提供的數據返回事實/信息。
LLM也可以用于基本的推理
除了語言理解之外，在逐步提示下工作時，一些LLM在基本推理方面的表現也不錯。這可以讓我們利用LLM將用戶請求/響應分解為較小的任務。
使用LLM進行審查，評估和反饋
LLM在審查文本并報告其中的問題方面比從頭開始生成文本要有效得多。因此，我們盡可能多地使用這種技術，將LLM的輸出發送回LLM并要求它反復檢查輸出。
使用LLM進行文本轉換，擴展，摘要
這是NLP自身的能力，將非結構化文本轉換為JSON格式，反之亦然，擴展短文本或者摘要長文本。
1.2 讓LLM 回答它無法知道的問題
在老碼農看來， LLM 體現出的涌現能力仍然是基于現有數據推理的潛在關系，真正的無中生有往往是幻覺的來源。一般來說，我們有兩種不同的方法來讓大語言模型回答LLM無法知道的問題：模型微調和上下文注入。
將預訓練模型調優的過程稱為Fine-tuning，指的是使用額外的數據對現有的語言模型進行訓練，以優化其針對特定任務的表現。與從頭開始訓練語言模型不同，我們使用已經預訓練過的模型，如LLama，并通過添加特定于用例的訓練數據來調整模型以適應特定任務的需求。微調是調整模型以適應特定任務的一種方式，但它并不能真正向模型中注入新的領域知識。這是因為該模型已經在大量的通用語言數據上進行了訓練，而特定領域數據通常不足以取代模型已學習到的內容。換句話說，微調幫助模型適應了其語言交流的方式，但不一定是它所傳達的內容。
使用上下文注入時，我們不修改語言模型，而是專注于修改提示本身并將相關上下文插入到提示中，其工作原理可能是這樣的：
因此，需要思考如何為提示語提供正確的信息, 需要一個能夠識別最相關數據的過程。通過使用嵌入技術，我們可以將文本轉換為向量，從而在多維嵌入空間中表示文本。在空間中距離較近的點通常在相似的上下文中使用。為了避免相似性搜索耗時過長，一般會將向量存儲在向量數據庫中并進行索引。
2. 基于大模型 API 的簡單應用構建所面臨的問題
構建大模型App 最直接的方式是在LLM API上創建一個簡單的應用程序層，可以將LLM與應用程序的用例、數據和用戶會話聯系起來，可用于維護與用戶的先前交互的記憶和狀態，或將目標分解為較小的任務和子任務。
但是，在LLM之上構建簡單的應用程序層存在著一些不足：
- 對用戶的響應將是不可預測的，并且會包含幻覺。
- 響應將不與目標應用程序的數據和用例相關。
- 無法為自己的產品建立護城河，任何人都可以輕松地實現相同的結果。
- LLM API 的成本較高，而且可能相當高。
- LLM是無狀態的，沒有代理功能。
相反，我們需要使用自己的專有數據和知識構建護城河，需要減少不必要的調用，并在可能的情況下使用更便宜的模型，還需要迭代地編排和自動化底層LLM，以改進任務規劃和推理能力。
那么，面對基于大模型的App， 是否存在通用性或具有指導性的參考架構呢？
3. 大模型App 的系統架構思考
基于LLM 的應用開發框架（例如LangChain）提供了圍繞大模型構建應用程序的結構化方法。但是，這里從抽象層嘗試給出大模型App 的系統架構。
3.1 應用編排器
編排器簡單地位于應用程序棧的下方，并將其他模塊連接在一起。其中，構建多租戶組件非常重要。這將確保：
- 為每個用戶進行個性化設置
- 隱私保護，確保只為正確的用戶檢索記憶，上下文等。
而且，以下的每個模塊都需要考慮多個多租戶實例的設計。
3.2 任務計劃器
一個不錯的方法是獲得用戶的請求/目標，并使用模型將其分解為子任務。每個子任務可以根據應用程序進一步分解為較小的任務/目標。這是一個持續的過程，隨著用戶完成目標，LLM可以用于擴展當前任務和子任務，或者修剪不再必要的任務。許多框架和開源項目都提供此類功能，一個典型的示例可能是AutoGPT。
一般地，可以按以下方式進行處理：
- 獲取用戶目標并將其發送到具有良好推理功能的LLM
- 提示LLM將其分解為子任務并返回為JSON列表
- 將子任務保存到數據庫中
- 應用程序可以根據子任務更新用戶界面
- 根據需要迭代為較小的子任務
3.3 上下文數據向量存儲
一般地，我們可能不應該在目標應用程序中使用預訓練的LLM知識，而是為每個提示提供任何必要的上下文信息，并指定LLM僅基于提示中包含的信息進行響應。這將確保響應與目標應用程序和用例相關。通過使用向量嵌入和向量數據庫，可以根據語義檢索每個提示的子集的上下文數據，從而實現更高的效率，提升性能并降低成本。
該方法如下所示：
- 每當有新的上下文信息時，將其分成若干部分，并使用LLM生成向量嵌入。然后將嵌入存儲在向量數據庫中，還將在每個嵌入中存儲附加信息（例如URL、圖像、源文本等）。
- 在向LLM發送請求之前，始終將請求作為查詢發送到向量存儲中。獲取前N個相關結果并將它們添加到請求提示中，指定LLM應僅使用提示中的信息，然后提交提示詞。
- 收到響應后，將其與發送的上下文數據進行比較，確保沒有幻覺并且它與目標應用程序的數據相關。
- 進行迭代，其中響應用于生成對向量數據庫的新查詢，然后使用結果作為下一個LLM的提示詞。
- 還可以要求LLM生成一個查詢到向量存儲，以獲取所需的附加信息。
需要要注意的，從向量數據庫接收到的記錄除了文本之外還包含其他數據，可能是圖像、URL、視頻URL等，目標應用程序可以使用此信息增強用戶界面的響應。
3.4 記憶型數據的向量存儲
記憶型數據的向量存儲類似于上下文數據的向量存儲，但是，它由先前使用應用程序生成的LLM提示和響應的鍵值對進行填充。目標是允許LLM參考以前的交互，以個性化用戶需求并引導走向正確的方向。
記憶數據也可以使用時間戳、位置等進行標記，以允許過濾或對相關記憶數據的修剪。
一般用例：
- 根據用戶在用戶界面中的操作，發出請求。請求轉換為向量嵌入，并發送到內存向量存儲中以檢索任何相關的記憶數據。
- 記憶可能包括特定的交互，例如，用戶發表過評論
- 然后將記憶與用戶請求以及從上下文存儲中提取的任何上下文一起添加到提示中。在提示中，記憶可能以“這里是以前的交互列表，請在響應時考慮這些，以確保您遵守以前的請求和偏好”的文本為前綴。
- 然后，將提示發送到LLM。
- 生成的提示和響應在當前會話期間轉換為向量嵌入，并存儲在內存向量存儲中。只要它們在未來的LLM交互中具有語義相關性，就會檢索它們。
3.5 提示管理器
很多時候，尤其是相對復雜的場景中，提示詞往往冗長而復雜。構建一個提示管理器，它可以接受許多屬性并以正確的結構構建提示。
另外，為了能夠在目標應用程序中使用響應，必須能夠預測將收到的格式。最好的方法是在提示詞中提供預期的JSON格式。這種JSON格式可以包括要修改的UI元素、要采取的操作等屬性。
3.6 響應管理器
響應管理器類似于提示管理器，但它用于驗證響應，可以處理以下內容：
- 檢查響應格式以確保符合提示中發送的要求。（例如，驗證JSON格式）
- 驗證響應是否符合加載的上下文和內存數據，以確保其不是幻覺。
- 將響應發送回LLM，以及原始提示，并要求LLM決定我們是否有良好的質量響應。
- 檢查LLM的響應是否存在不良內容、負面情緒等。
如果響應管理器認為當前的LLM響應存在問題，那么它可以生成一個帶有拒絕原因的新提示，并將其提交給LLM以獲取新的響應。這可以迭代地進行，直到響應滿足所有標準和安全檢查。
3.7 效果評估器
LLM可以很好地評估用戶的提示詞并根據預定義的標準對其進行評分。一種常見的方式是在完成任務后，提示用戶提供反饋，然后通過這些提示，LLM根據以下標準評估反饋：
- 用戶是否報告了任何不滿？(-1=未知，0=沒有不滿，10=嚴重不滿)
- 用戶是否喜歡這個體驗？(-1=未知，0=完全不喜歡，10=非常喜歡)
- 用戶是否感覺完成了目標？(-1=未知，0=沒有，10=完全達到)
- 等等。
最后，LLM將以JSON格式返回反饋，評估結果可以存儲在數據庫中，還可以使用這些結果構建新的功能。
3.8 大模型管理器
每一種大模型模型都有著自己的優缺點，我們可能需要利用多個LLM來進行應用程序的開發，以充分利用它們的優勢。選擇要使用的模型時，一般的考慮因素如下：
- LLM推理成本和API成本
- 針對不同的用例場景篩選大模型的類型。例如，使用編碼器模型進行情感分析，使用解碼器模型進行文本生成或聊天，對于基本的文本操作，選擇較小、更快、更便宜的模型。
- 文本嵌入模型用于語義搜索和生成向量嵌入
- 微調模型以在特定任務上獲得更好的性能
- 指令微調模型可以充當的助手，例如RLHF的應用
LLM提供商一般會允許我們對每個請求選擇要使用的模型，一個請求的輸出也可以鏈接到第二個模型進行文本操作或審查。例如，當需要重要推理任務時，可以使用GPT-4，然后使用GPT-3進行基本文本操作或完成。這將有助于控制API成本，并確保為每個請求使用最合適的模型。我們還可以為某些任務使用開源更便宜的模型。
通過大模型管理器，可以將API和模型使用之間的差異從應用程序中抽象出來，還可以使用LLM的插件方法，輕松引入新模型。
4. 構建大模型App 的簡單示例
構建一個基于大模型的app，大概可以采用以下步驟：
- 在待創建或已有的App中引入用戶顯式用自然語言進行交互的入口（也可以采用隱式方式）；
- 明確所需解決的問題領域空間，加載目標領域的文檔內容，并對文本進行分割；
- 采用嵌入模型，將文本數據生成向量；
- 構建面向向量存儲的向量數據庫并構建索引；
- 選擇目標模型，將API 引入系統；
- 創建 prompt 模版，并支持配置和優化；
4.1 引入自然語言交互
每個App 都有相應的用戶交互設計（UI/UX），為了通過大模型為應用賦能，面對非結構化數據，例如工作描述、簡歷、電子郵件、文本文檔、PowerPoint 幻燈片、語音錄音、視頻和社交媒體， 自然語言交互有著廣泛的應用場景。
自然語言的引入一般會以助手的方式呈現，可以直接采用chat的方式，簡單而言，是在產品中引入了可以查看歷史記錄的輸入框。
4.2 文檔加載與文件分割
有很多現成的文檔加載器，可以用于html頁面、S3、PDF、office文檔等的加載器。一般地，可以利用企業中現有的文集存儲或者知識庫，采用批處理的方式完成目標數據集的加載， 然后采用事件觸發的方式實現實時加載。
然后，需要將文本分成較小的文本塊。每個文本塊在嵌入空間中表示一個數據點，使計算機能夠確定這些塊之間的相似性。常見的方式是使用較大的文本塊，但也可以進行一些實驗，找到最適合用例的最佳大小。請記住，每個LLM都有token限制（GPT 3.5的令牌限制為4000個），需要確保整個提示的token數不超過單次LLM API 調用的token限制。
4.3 文本數據的向量生成
我們需要將文本轉換為可理解和可比較算法的形式，必須找到一種將人類語言轉換為比特和字節的數字形式的方法。嵌入模型通過分析單詞通常出現的上下文來嘗試學習這個目標。嵌入式模型為我們提供了嵌入空間中每個單詞的向量。最后，通過用向量表示它們，進而能夠進行數學計算，例如計算單詞之間的相似度作為數據點之間的距離。
將文本轉換為嵌入，常見的方法有word2Vec，GloVe，fastText或ELMo。以Word2Vec為例，為了在嵌入空間中捕捉單詞之間的相似性，Word2Vec使用了一個簡單的神經網絡。實際上，現有的模型要大得多，因此以更高維度的空間表示單詞，例如OpenAI的Ada嵌入模型使用了1536個維度，訓練過程結束后，各個權重就描述了在嵌入空間中的位置。這些預訓練向量使我們能夠以如此精確的方式捕捉單詞及其意義之間的關系，以至于我們可以對它們進行計算。我們還可以選擇不同的嵌入模型，如Ada、Davinci、Curie和Babbage。其中，Ada-002目前是最快且成本最低的模型，而Davinci通常能夠提供較高的準確性和性能。
我們使用嵌入模型的目標是將文本塊轉換為向量。在Ada-002中，這些向量具有1536個輸出維度，這意味著它們表示一個在1536維空間中具有特定位置或方向的點。將文本塊和用戶的問題表示為向量時為了確定兩個數據點之間的相似度，需要計算它們在多維空間中的接近程度，這可以通過距離度量來實現。
4.4 構建向量數據庫并創建索引
將文本數據轉換為向量只是第一步，為了能夠高效地搜索我們的嵌入向量，我們需要將它們存入向量數據庫并進行索引。
向量數據庫是一種專為存儲和檢索可以表示為向量的大量數據而優化的數據存儲類型。這些類型的數據庫允許根據各種標準（如相似度度量或其他數學運算）高效地查詢和檢索數據子集。索引是向量數據庫的重要組成部分，提供了一種將查詢映射到向量存儲中最相關文檔或項的方法，而不必計算每個查詢與每個文檔之間的相似度。
常見的一些向量數據庫如下所示：
4.5 模型選擇與API 應用
當選擇模型的時候，可以遵循上文提到的那些原則。以Open AI 平臺為例，Text-davinci-003模型可能目前是最大且最強大的模型。另一方面，像Text-ada-001這樣的模型更小、更快速，而且更具成本效益。與最強大的模型Davinci相比，Ada更便宜。因此，如果Ada的性能滿足我們的需求，不僅可以省錢，還可以實現更短的響應時間。
我們也可以先使用Davinci進行嘗試，然后評估是否也可以使用Ada獲得足夠好的結果。在模型選擇后，首先要設置API key獲得訪問權限，然后再嘗試設置一些首選項，在不同的參數中進行一些調試。
4.6 Prompt 模版的配置優化與使用
Prompt提示指定了模型回答問題所需的模式即所需的行為風格，希望LLM在其中生成答案。將Prompt提示應用在LLM上，這里有一些簡單的示例：
- 摘要生成：“將以下文本總結為3段供高管閱讀：[文本]”
- 知識提取：“基于這篇文章：[文本]，在購買房屋之前人們應該考慮哪些因素？”
- 寫作內容（例如郵件、信息、代碼）：“給[人名]發送一封郵件，詢問項目文檔的進展情況。使用非正式、友好的語氣。”
- 語法和風格改進：“將這段文本改正為標準英語，并改變語氣為更友好的：[文本]”
- 分類：“將每條消息分類為訂單的類型：[文本]”
除了對Prompt及其模版的管理和使用，我們還可以對大模型的限制，只允許LLM 利用指定數據庫中存儲的信息。這個限制使我們能夠提供LLM生成回答所依賴的來源，這對于可追溯性和建立信任至關重要。此外，它還幫助解決了生成不可靠信息的問題，并能夠提供可以在企業環境中用于決策的答案。
5 小結
當然，我們可以利用一些現有的或者發展中的應用框架或者平臺，例如開源框架LangChain。如果覺得LangChain 用起來不夠簡潔， 可以嘗試一下LLMFarm，LLMFarm可以簡單地類比為可視化的LangChain。如果仍然覺得復雜， 還可以嘗試使用藍鶯IM 基于大模型的企業知識庫。
因此，構建一個基于大模型的應用并沒有想象中的那么困難， 但充分利用大模型的能力來為業務賦能卻不是那么容易，仍然需要探索并尋找最佳實踐。
