AI 概念

本節介紹 Spring AI 使用的核心概念。我們建議您仔細閱讀，以理解 Spring AI 實作背後的概念。

模型

AI 模型是旨在處理和生成資訊的演算法，通常模仿人類的認知功能。透過從大型資料集中學習模式和洞察，這些模型可以做出預測、生成文字、圖像或其他輸出，從而增強各行各業的各種應用。

AI 模型有很多不同的類型，每種類型都適用於特定的使用案例。雖然 ChatGPT 及其生成式 AI 功能透過文字輸入和輸出吸引了使用者，但許多模型和公司提供多樣化的輸入和輸出。在 ChatGPT 之前，許多人對文字轉圖像生成模型（如 Midjourney 和 Stable Diffusion）感到著迷。

下表根據輸入和輸出類型對幾種模型進行分類

Model types

Spring AI 目前支援處理語言、圖像和音訊輸入和輸出的模型。前表中的最後一列，它接受文字作為輸入並輸出數字，更常被稱為嵌入文字，並且代表 AI 模型中使用的內部資料結構。Spring AI 支援嵌入，以實現更進階的使用案例。

像 GPT 這樣的模型與眾不同之處在於它們的預訓練性質，正如 GPT—Chat Generative Pre-trained Transformer 中的 "P" 所表示的那樣。這種預訓練功能將 AI 轉變為通用的開發人員工具，而不需要廣泛的機器學習或模型訓練背景。

提示詞

提示詞是基於語言的輸入的基礎，這些輸入引導 AI 模型產生特定的輸出。對於熟悉 ChatGPT 的人來說，提示詞可能看起來僅僅是在對話方塊中輸入並發送到 API 的文字。然而，它包含的不僅僅是這些。在許多 AI 模型中，提示詞的文字不僅僅是一個簡單的字串。

ChatGPT 的 API 在一個提示詞中有多個文字輸入，每個文字輸入都被分配一個角色。例如，有系統角色，它告訴模型如何行為並設定互動的背景。還有使用者角色，它通常是來自使用者的輸入。

撰寫有效的提示詞既是一門藝術，也是一門科學。ChatGPT 是為人類對話而設計的。這與使用像 SQL 這樣的東西來「提問」截然不同。人們必須像與另一個人交談一樣與 AI 模型溝通。

這種互動方式非常重要，以至於「提示詞工程」一詞已成為一個獨立的學科。有大量新興技術可以提高提示詞的有效性。投入時間撰寫提示詞可以大幅改善產生的輸出。

分享提示詞已成為一種社群實踐，並且正在對此主題進行積極的學術研究。舉例來說，創建有效的提示詞可能有多麼違反直覺（例如，與 SQL 形成對比），一份最近的研究論文發現，您可以使用的最有效的提示詞之一是以「深呼吸，然後逐步處理」這句話開頭。這應該能讓您了解語言為何如此重要。我們尚未完全了解如何最有效地利用這項技術的先前迭代版本，例如 ChatGPT 3.5，更不用說正在開發的新版本了。

提示詞範本

創建有效的提示詞涉及建立請求的上下文，並將請求的部分內容替換為使用者輸入特定的值。

此過程使用傳統的基於文字的範本引擎來創建和管理提示詞。Spring AI 為此目的採用 OSS 庫 StringTemplate。

例如，考慮以下簡單的提示詞範本

Tell me a {adjective} joke about {content}.

在 Spring AI 中，提示詞範本可以比作 Spring MVC 架構中的「View」。模型物件（通常是 java.util.Map）用於填充範本中的佔位符。「呈現」的字串成為提供給 AI 模型的提示詞內容。

發送到模型的提示詞的特定資料格式存在相當大的變異性。提示詞最初以簡單的字串開始，後來發展為包含多個訊息，其中每個訊息中的每個字串都代表模型的一個獨特角色。

嵌入

嵌入是文字、圖像或影片的數值表示，用於捕捉輸入之間的關係。

嵌入的工作原理是將文字、圖像和影片轉換為浮點數陣列，稱為向量。這些向量旨在捕捉文字、圖像和影片的含義。嵌入陣列的長度稱為向量的維度。

透過計算兩段文字的向量表示之間的數值距離，應用程式可以確定用於產生嵌入向量的物件之間的相似性。

Embeddings

作為探索 AI 的 Java 開發人員，沒有必要理解這些向量表示背後複雜的數學理論或具體實作。基本了解它們在 AI 系統中的作用和功能就足夠了，尤其是在您將 AI 功能整合到您的應用程式中時。

嵌入在實際應用中尤其相關，例如檢索增強生成 (RAG) 模式。它們使數據能夠表示為語義空間中的點，這類似於歐幾里得幾何的二維空間，但在更高的維度中。這意味著，就像歐幾里得幾何平面上的點可以根據其坐標遠近一樣，在語義空間中，點的鄰近性反映了含義的相似性。關於相似主題的句子在這個多維空間中定位得更近，就像圖表上彼此靠近的點一樣。這種鄰近性有助於文字分類、語義搜尋，甚至產品推薦等任務，因為它允許 AI 根據相關概念在這個擴展的語義景觀中的「位置」來辨別和分組相關概念。

您可以將這個語義空間視為一個向量。

Token

Token 是 AI 模型運作方式的基礎構建模組。在輸入時，模型將單字轉換為 token。在輸出時，它們將 token 轉換回單字。

在英文中，一個 token 大約相當於 75% 的單字。作為參考，莎士比亞的全集總共約 90 萬個單字，翻譯成約 120 萬個 token。

Tokens

也許更重要的是 Token = 金錢。在託管 AI 模型的上下文中，您的費用取決於使用的 token 數量。輸入和輸出都會計入總 token 數。

此外，模型受 token 限制的約束，這限制了單個 API 呼叫中處理的文字量。此閾值通常稱為「上下文視窗」。模型不處理任何超過此限制的文字。

例如，ChatGPT3 的 token 限制為 4K，而 GPT4 提供不同的選項，例如 8K、16K 和 32K。Anthropic 的 Claude AI 模型具有 100K token 限制，而 Meta 最近的研究產生了一個 1M token 限制模型。

若要使用 GPT4 總結莎士比亞的全集，您需要設計軟體工程策略來分割資料，並在模型的上下文視窗限制內呈現資料。Spring AI 專案可以幫助您完成這項任務。

結構化輸出

AI 模型的輸出傳統上以 java.lang.String 的形式到達，即使您要求回覆以 JSON 格式呈現。它可能是正確的 JSON，但它不是 JSON 資料結構。它只是一個字串。此外，在提示詞中要求「JSON 格式」並非 100% 準確。

這種複雜性導致了一個專業領域的出現，該領域涉及創建提示詞以產生預期輸出，然後將產生的簡單字串轉換為可用於應用程式整合的資料結構。

Structured Output Converter Architecture

結構化輸出轉換採用精心設計的提示詞，通常需要與模型進行多次互動才能達到所需的格式。

將您的資料和 API 引入 AI 模型

您如何為 AI 模型配備它未經訓練的資訊？

請注意，GPT 3.5/4.0 資料集僅擴展到 2021 年 9 月。因此，模型表示它不知道需要超出該日期知識的問題的答案。一個有趣的瑣事是，這個資料集約為 650GB。

存在三種技術可以自訂 AI 模型以整合您的資料

  • 微調：這種傳統的機器學習技術涉及調整模型並更改其內部權重。然而，由於 GPT 等模型的大小，對於機器學習專家來說，這是一個具有挑戰性的過程，並且資源密集程度極高。此外，某些模型可能不提供此選項。

  • 提示詞填充：一種更實際的替代方案是在提供給模型的提示詞中嵌入您的資料。考慮到模型的 token 限制，需要技術在模型的上下文視窗內呈現相關資料。這種方法俗稱為「填充提示詞」。Spring AI 庫可幫助您實作基於「填充提示詞」技術的解決方案，也稱為 檢索增強生成 (RAG)。

Prompt stuffing

  • 函式呼叫：此技術允許註冊自訂的使用者函式，將大型語言模型連接到外部系統的 API。Spring AI 大大簡化了您需要編寫的程式碼以支援 函式呼叫。

檢索增強生成

一種稱為檢索增強生成 (RAG) 的技術已經出現，以應對將相關資料整合到提示詞中以獲得準確 AI 模型回應的挑戰。

該方法涉及批次處理風格的程式設計模型，其中作業從您的文件中讀取非結構化資料，轉換它，然後將其寫入向量資料庫。在高層次上，這是一個 ETL（提取、轉換和載入）管道。向量資料庫用於 RAG 技術的檢索部分。

作為將非結構化資料載入向量資料庫的一部分，最重要的轉換之一是將原始文件分割成更小的片段。將原始文件分割成更小片段的程序有兩個重要的步驟

  1. 在保留內容的語義邊界的前提下，將文件分割成多個部分。例如，對於包含段落和表格的文件，應避免在段落或表格中間分割文件。對於程式碼，請避免在方法實作的中間分割程式碼。

  2. 將文件的各個部分進一步分割成大小佔 AI 模型 token 限制一小部分的片段。

RAG 的下一個階段是處理使用者輸入。當使用者的問題要由 AI 模型回答時，問題和所有「相似」的文件片段都會放入發送到 AI 模型的提示詞中。這就是使用向量資料庫的原因。它非常擅長尋找相似的內容。

Spring AI RAG

  • ETL 管道提供了有關協調從資料來源提取資料並將其儲存在結構化向量儲存庫中的流程的更多資訊，確保資料在傳遞給 AI 模型時處於最佳檢索格式。

  • ChatClient - RAG 說明如何使用 QuestionAnswerAdvisor 在您的應用程式中啟用 RAG 功能。

函式呼叫

大型語言模型 (LLM) 在訓練後會被凍結，導致知識陳舊，並且它們無法存取或修改外部資料。

函式呼叫機制解決了這些缺點。它允許您註冊自己的函式，以將大型語言模型連接到外部系統的 API。這些系統可以為 LLM 提供即時資料並代表它們執行資料處理操作。

Spring AI 大大簡化了您需要編寫的程式碼以支援函式調用。它為您處理函式調用對話。您可以將您的函式作為 @Bean 提供，然後在您的提示詞選項中提供函式的 bean 名稱以啟用該函式。此外，您可以在單個提示詞中定義和引用多個函式。

Function calling

  1. 執行聊天請求，同時發送函式定義資訊。後者提供 name、description（例如，解釋模型何時應呼叫函式）和 input parameters（例如，函式的輸入參數架構）。

  2. 當模型決定呼叫函式時，它將使用輸入參數呼叫函式，並將輸出返回給模型。

  3. Spring AI 為您處理此對話。它將函式呼叫分派到適當的函式，並將結果返回給模型。

  4. 模型可以執行多次函式呼叫以檢索它需要的所有資訊。

  5. 一旦獲得所有需要的資訊，模型將產生回應。

請參閱 函式呼叫 文件，以取得有關如何將此功能與不同 AI 模型搭配使用的更多資訊。

評估 AI 回應

有效評估 AI 系統對使用者請求的回應輸出，對於確保最終應用程式的準確性和實用性非常重要。幾種新興技術使得可以使用預訓練模型本身來達到此目的。

此評估過程涉及分析產生的回應是否符合使用者的意圖和查詢的上下文。相關性、連貫性和事實正確性等指標用於衡量 AI 生成回應的品質。

一種方法是將使用者的請求和 AI 模型的回應都呈現給模型，查詢回應是否與提供的資料一致。

此外，利用儲存在向量資料庫中的資訊作為補充資料可以增強評估過程，有助於確定回應相關性。

Spring AI 專案提供了一個 Evaluator API，目前可以存取評估模型回應的基本策略。請參閱 評估測試 文件以取得更多資訊。