共用方式為

建置衍生式 AI 解決方案的開發人員的重要概念和考慮

  • 發行項

大型語言模型（LLM）是驚人的，但即使它們也有其限制。 開發人員需要了解這些限制、哪些 LLM 能夠「現成」，以及如何調整它們，以取得他們正在建置的產生 AI 解決方案的最佳結果。 本文會識別數個挑戰和限制因素，並說明克服這些挑戰的常見方式，並控制內容產生程式，而不論您要建置在應用程式中的哪種類型的產生 AI 功能。

使用 LLM 時的工程挑戰

使用 LLM 時要注意的最重大挑戰或限制：

  • 知識截斷 - 由於訓練 LLM 的成本很高，他們的知識主體僅限於他們在某個時間點接受訓練的內容。 如果沒有任何外掛程式或其他住宿，他們就無法存取實時數據，也無法存取私人數據。

  • 幻覺 - LLM 會使用統計機率和一點隨機性來產生資訊。 有機制可以保持產生的回應符合人類意圖的問題，以及他們訓練的資訊，但有可能建立不正確回復。

  • 透明度 - 同樣地，由於模型定型的方式，他們不再能夠存取他們訓練的基礎知識。 即使他們這樣做，也不能保證資訊是真實和立足於第一位的。 此外，沒有驗證步驟可確保產生的回應正確無誤。

  • 沒有領域特定知識 - 類似於「知識截止」，如果您有私人資訊，例如僅限內部的公司檔，LLM 並未針對這項資訊進行訓練，因此沒有領域特定知識。

您可以做些什麼來減輕 LLM 的可能挑戰或問題，並取得最佳可能的結果，以協助您的使用者和組織？ 首先，瞭解您可以補充 LLM 從何處取得其數據的方式。

瞭解 LLM 取得其資訊的位置

從 LLM 取得最佳結果的起點是瞭解 LLM 取得其資訊的位置或方式。 下列類別代表 LLM 如何與各種資訊來源互動以產生回應的不同方法。

圖表描述三種不同類型的擷取產生，其中最上層的擷取產生與最預先定型的知識相互關聯，然後擷取增強的產生，然後在底部擷取中心產生與最擷取的知識相互關聯。

  • 擷取關閉世代 （ROG） - 這是傳統方式 LLM 的運作方式，其中模型只會根據所定型的知識產生回應，而不會在產生過程中存取或擷取任何外部資訊。 模型的知識是靜態的，僅限於截至截止日期為止其定型數據中包含的內容。 除了創造性的寫作，它還可以回答因特網上隨時可用的信息問題。

  • 擷取增強世代 （RAG） - 結合 LLM 的產生功能，以及即時從外部資料庫或檔擷取資訊的能力。 模型會查詢外部來源以尋找相關信息，然後用來通知其回應。 此方法可讓模型提供比僅預先定型知識更精確且最新的資訊。 使用案例包括事實檢查、根據實時數據或私人網域特定數據回答問題。

  • 擷取中心產生 （RCG） - 更強調外部擷取的內容，通常圍繞從外部來源擷取的資訊建構回應。 模型可能會直接將擷取的大型文字區段納入其輸出、編輯或標註，以符合用戶的查詢。 這種方法可視為擷取型和產生方法之間的混合式方法，其中平衡可能會嚴重偏向擷取的資訊，而該資訊會優先於模型本身的產生功能。 使用案例包括較長檔的摘要、研究協助，跨多個類似檔提供比較和主題探索，以及將不同材料來源的編譯或定序編譯或定序納入合併的輸出。

擷取關閉世代（ROG）的一個很好的範例是 ChatGPT。 相反地，如有必要，Copilot（透過 Bing）使用來自新聞來源的外部來源來擴充 LLM（並提供這些來源的連結）。

第一眼，「擷取增強世代」和「擷取中心產生」（RCG）聽起來類似，因為兩者都涉及將外部資訊整合到語言產生程式中。 不過，其優先順序和利用產生程式內擷取的資訊的方式有所不同。

在RAG系統中，外部數據擷取是用來 增強 預先定型語言模型的產生功能。 擷取的資訊會提供模型用來通知其回應的更多內容或特定數據。 在這裡，語言模型的產生層面仍然是回應的核心，而擷取的數據會作為 支援元素 來增強精確度或深度。

另一方面，RCG 系統更強調擷取的資訊本身。 在這些系統中，擷取的數據通常是 回應的中心 部分，其作用主要是精簡、格式化或稍微增強擷取的文字。 當信息的正確性和直接相關性至關重要時，特別會使用此方法，而且需要較少的創造性合成或推斷。

外部擷取支援RAG和 RCG 之數據的機制會在儲存檔向量化內嵌與微調 LLM 的文章中討論，這兩種常見方法可根據初始定型來補充 LLM 可用的知識。

瞭解擷取模型之間的差異有助於為特定應用程式選擇正確的方法，平衡創意合成的需求，以及對源材料精確度和精確度的需求。

了解影響推斷運作方式的因素

由於您可能熟悉 ChatGPT 的 Web 型使用者介面，因此瞭解其如何運作來回答問題，可協助您瞭解在您自己的應用程式中建置產生 AI 功能時，將非常重要的概念。

當使用者與 ChatGPT 聊天時，使用者介面設計會提供長時間執行的聊天會話的錯覺，該會話會在您與 LLM 之間進行數次來回交換時維持狀態。 事實上，針對指定的聊天會話，所有提示和所有 LLM 的回應（也稱為 完成）都會隨每個新的提示一起傳送。 因此，隨著交談的成長，您會將越來越多的文字傳送給 LLM 進行處理，而所有先前的提示和完成。 ChatGPT 會在撰寫對目前提示的回應時，使用整個聊天會話的內容，而不只是目前的提示。 整個聊天會話稱為 內容視窗。

視您使用的 ChatGPT 版本而定，有內容窗口長度限制。 撰寫對最新提示的回應時，將會忽略超過內容窗口長度限制的任何聊天交談部分。

長時間交談一開始可能看起來是個好主意，但長內容視窗可能會影響處理提示和撰寫完成所需的計算量。 這會影響回應的延遲，以及 OpenAI 處理要求的成本。

ChatGPT 的內容視窗限制為何？ 或者，ChatGPT 可以搭配使用多少個字？ 內容視窗限制取決於您正在使用的 LLM 模型、版本和版本。 此外，內容長度會以標記來測量，而不是以單字來測量。 令牌是模型可以了解和產生的最小文字單位。 這些單位可以是單字、部分文字（例如音節或詞幹），甚至是個別字元。 令牌是自然語言處理的核心（NLP）。

令牌的使用會影響開發人員的兩個重要考慮：

  • 內容視窗限制上限
  • 每個提示和完成的價格

什麼是令牌化？

「令牌化」是將文字轉換成令牌的程式。 這是使用 LLM 準備訓練或推斷數據的重要步驟（根據提示撰寫完成的程式）。 此程式牽涉到數個步驟，包括將複雜文字分解成可管理的片段（標記），模型接著可以處理。 此程序很簡單，例如以空格和標點符號分隔文字，或更複雜的程式，涉及複雜的演算法來處理不同的語言、花樣（文字結構），以及語法（文字排列）。 LLM 研究人員和開發人員會根據他們嘗試完成的工作來決定令牌化的方法。 OpenAI 有一個 實用的頁面 ，可說明令牌化的詳細資訊，甚至還有一個計算機來說明句子或段落如何細分成標記。

當 OpenAI Tokenizer 頁面底部的附注指出，在一般英文文字中，一個令牌相當於大約四個字元。 這表示，平均每個令牌有100個標記大約等於75個單字，或四分之三的文字。

OpenAI Tokenizer 頁面也會討論 tiktoken，這是 Python 和 JavaScript 的套件，可讓您以程式設計方式估計將用於傳送至 OpenAI API 之指定提示的令牌數量。

令牌使用量會影響計費

每個 Azure OpenAI API 都有不同的計費方法。 若要使用聊天完成 API 處理和產生文字，您會根據您提交為提示的令牌數目，以及產生結果的令牌數目（完成）。

每個 LLM 模型（例如 gpt-3.5、gpt-3.5-turbo、gpt-4 等）通常有不同的價格，這反映了處理和產生令牌所需的計算量。 很多時候，價格會顯示為「每 1,000 個令牌的價格」或「每一百萬個令牌的價格」。

此定價模式會對您設計用戶互動的方式，以及您新增的前置和後置處理量產生重大影響。

系統與使用者提示

至此，討論只著重於「使用者提示」–構成使用者與 ChatGPT 之間交換的提示。

OpenAI 引進了「系統提示」（也稱為「自定義指示」），這是您定義並新增至所有聊天交談的超額指示集。 請將它視為一組您想要 LLM 在每次開始新的聊天會話時一律觀察的中繼指示。 例如，您可以將系統提示設定為「一律以海庫的詩意形式回應」。從那一點開始，對 ChatGPT 的每個新提示都會產生包含答案的 haiku。

雖然「在 haiku 窗體中回復」不是有用的範例，但它確實說明您可以藉由修改提示本身來影響 LLM 完成到提示的想法。

為何要修改使用者的提示？ 如果您要為專業物件建置產生 AI 功能或應用程式，其中可能包含公司員工、客戶和合作夥伴，您無疑會想要新增保護，以限制允許其回答的主題或領域範圍。

但是修改使用者的提示只是改善使用者文字產生體驗的一種方法。

改善 ChatGPT 中使用者文字產生體驗的方法

為了改善文字產生結果，開發人員只能只改善提示，而且有許多提示工程技術可以協助。 不過，如果您要建置自己的產生 AI 應用程式，有數種方式可改善使用者的文字產生體驗，而您可能想要嘗試實作其中所有專案：

  • 以程序設計方式修改使用者提示
  • 實作推斷管線
  • 擷取增強世代（其他文章中討論）
  • 微調（在其他文章中討論）

以程序設計方式修改使用者提示

從程式設計的觀點來看，沒有特殊的 API 可用來將系統提示新增至使用者的交談。 您只需要視需要將指示附加至提示。 不過，有一些改善使用者提示的技術：

  • 關係型 Priming：製作系統提示，以明確設定所需網域內的交談內容。 這牽涉到在每個互動開始時提供簡短的描述或一組指示，引導 AI 留在問題領域。
  • 範例型指引：在初始提示中包含與您的網域相關的問題和解答類型範例。 這有助於 AI 瞭解預期的回應類型。

此外，可以套用所有提示工程技術。 如果您能以某種方式以程序設計方式完成這項作業，您可以代表使用者改善使用者的提示。

此方法的注意事項是提示越長，每次呼叫 LLM 的成本就越高。 即便如此，這可能是討論的最便宜的方法。

實作推斷管線

除了以程序設計方式修改使用者的提示之外，下一個步驟是建立整個推斷管線。

推斷管線是端對端程式，它接受原始輸入（例如文字或影像）並「清理」，再使用它來執行主要提示（前置處理）或檢查完成，以確保它符合使用者的需求，再向用戶顯示它（後續處理）。

前置處理可能涉及關鍵詞檢查、相關性評分或轉換查詢，以更符合預期的領域語言。 例如，您可以分析使用者提交的初始提示，然後從詢問 LLM 是否有意義、如果它位於您願意接受的界限內、以錯誤內部部署為基礎，或需要重新撰寫，以避免某些偏差。 如果 LLM 分析提示並發現問題，您可以進一步：要求 LLM 重新措辭提示，以可能改善答案。

後續處理可能涉及驗證答案對網域的相關性和適當性。 這可能包括移除或標幟不符合網域需求的解答。 例如，您可能想要檢查 LLM 所提供的完成，以確保它符合您的品質和安全需求。 您可以要求 LLM 評估答案，看看它是否確實符合您要求它遵守的要求。 如果沒有，您可以要求 LLM 修改完成，並重複此作業，直到您有令人滿意的結果為止。

新增前置處理步驟有一個警告：每次您在推斷管線中新增對 LLM 的呼叫時，您都會增加整體延遲（回應時間），以及每次與用戶互動的成本。 身為經驗豐富的軟體開發人員，您可能已經意識到這些由影響軟體系統預算、效能和有效性的領導階層所做出的權衡取捨。

建置進階擷取增強產生系統一文深入探討建置推斷管線的特定步驟。

影響完成的其他因素

除了以程序設計方式修改提示、建立推斷管線和其他技術之外，在使用「擷取增強產生」和「微調」擴充大型語言模型中會討論進一步的詳細數據。 此外，有一些參數可在呼叫 Azure OpenAI API 時加以修改。

聊天 端點檔 會列出必要的和選擇性參數，以傳遞可能會影響完成的各個層面。 如果您改用 SDK，請參閱 SDK 檔，以取得您選擇的語言。 如果您想要實驗參數，您可以在遊樂場中執行此動作。

  • 溫度：控制模型所產生的輸出隨機性。 在零時，模型會變得具決定性，一致地從其定型數據中選取最有可能的下一個標記。 在 1 的溫度下，模型會在選擇高機率標記和將隨機性引入輸出之間取得平衡。

  • 最大令牌：控制回應的最大長度。 設定較高或較低的限制可能會影響所產生內容的詳細數據和範圍。

  • 前 P （核取樣）：與溫度搭配使用，以控制回應的隨機性。 前 P 限制 AI 在產生每個權杖時，只考慮機率品質的前 P 百分比。 較低的值會導致更專注且可預測的文字，而較高的值則允許更多多樣性。

  • 頻率懲罰：減少重複相同行或片語的模型的可能性。 增加此值有助於避免產生文字中的備援。

  • 存在懲罰：鼓勵模型在完成時引進新的概念和詞彙。 存在懲罰有助於產生更多樣化和創造性的輸出。

  • 停止序列：您可以指定一或多個序列，指示 API 停止產生進一步的令牌。 存放區序列可用於控制輸出的結構，例如在句子或段落結尾結束完成。

  • Logit 偏差：可讓您修改完成時出現指定令牌的可能性。 Logit Bias 可用來引導特定方向完成，或隱藏不想要的內容。

瞭解 openAI 保護Microsoft

除了將 LLM 的響應系結至特定主題或網域之外，您也可能會擔心使用者詢問的 LLM 問題種類。 請務必考慮其產生的答案類型。

首先，API 呼叫 Microsoft OpenAI Services 會自動篩選它發現可能令人反感的內容，並將其回報給許多篩選類別。

您可以直接使用 OpenAI 的仲裁 API，明確檢查任何內容是否有潛在的有害內容。

其次，您可以使用 Azure AI 內容安全性來協助進行文字仲裁、影像仲裁、越獄風險偵測，以及受保護的材料偵測。 這會結合入口網站設定、設定和報告體驗，以及您可以新增至應用程式以識別有害內容的程序代碼。

可能會影響應用程式設計決策的最終考慮

瞭解令牌化、定價、內容視窗，以及實作程序設計改善，以增強使用者的文字產生體驗會影響您設計產生 AI 系統的方式。 以下是本文所要考慮的事項清單，以及其他會影響應用程式設計決策的專案：

  • 根據成本考慮評估使用最新 AI 模型的必要性。 成本較低的模型可能足以滿足應用程式的需求，以預算條件約束平衡效能。
  • 請考慮將內容窗口長度優化，以管理成本，而不會影響用戶體驗。 修剪交談中不必要的部分可能會降低處理費用，同時維持高質量的互動。
  • 評估輸入和輸出的令牌化和粒度如何影響效能。 瞭解所選 LLM 如何處理令牌化，可協助您將 API 呼叫的效率優化，並可能降低成本並改善回應時間。

如果您想要立即開始實驗建置產生式 AI 解決方案，建議您先 看看使用您自己的 Python 數據範例開始使用聊天。 .NET、Java 和 JavaScript 也提供教學課程版本。