AI 概念

本節描述了 Spring AI 使用的核心概念。我們強烈建議您仔細閱讀，以理解 Spring AI 實現背後的思想。

模型

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

AI 模型有許多不同的型別，每種型別都適合特定的用例。雖然 ChatGPT 及其生成式 AI 能力透過文字輸入和輸出來吸引使用者，但許多模型和公司提供多樣化的輸入和輸出。在 ChatGPT 之前，許多人對 Midjourney 和 Stable Diffusion 等文字到影像生成模型著迷。

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

Model types

Spring AI 目前支援處理語言、影像和音訊輸入和輸出的模型。上表中最後一行的模型接受文字作為輸入並輸出數字，這更常被稱為文字嵌入，表示 AI 模型內部使用的資料結構。Spring AI 支援嵌入以支援更高階的用例。

像 GPT 這樣的模型之所以與眾不同，在於它們的預訓練特性，GPT 中的 "P" 表示生成式預訓練 Transformer (Generative Pre-trained Transformer)。這種預訓練特性將 AI 轉變為一種通用的開發工具，不再需要廣泛的機器學習或模型訓練背景。

提示詞 (Prompts)

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

ChatGPT 的 API 在一個提示詞內有多個文字輸入，每個文字輸入都被分配了一個角色。例如，有系統角色，它告訴模型如何表現並設定互動的上下文。還有使用者角色，這通常是使用者的輸入。

精心設計有效的提示詞既是一門藝術也是一門科學。ChatGPT 旨在進行人類對話。這與使用 SQL 這樣的方式來“提問”完全不同。必須像與另一個人交談一樣與 AI 模型進行交流。

這種互動風格的重要性使得“提示工程 (Prompt Engineering)”成為了一門獨立的學科。有一系列正在迅速發展的技術可以提高提示詞的有效性。投入時間來設計一個提示詞可以極大地改善產生的輸出結果。

分享提示詞已成為一種普遍做法，並且正在對該主題進行積極的學術研究。作為一個例子，說明建立有效提示詞（例如，與 SQL 對比）可能多麼違反直覺，最近的一篇研究論文發現，你能使用的最有效的提示詞之一以短語“深呼吸，一步一步來 (Take a deep breath and work on this step by step.)”開頭。這應該能讓你明白語言為何如此重要。我們尚未完全理解如何最有效地利用這項技術的先前迭代版本，例如 ChatGPT 3.5，更不用說正在開發的新版本了。

提示模板 (Prompt Templates)

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

此過程使用傳統的基於文字的模板引擎進行提示詞建立和管理。Spring AI 使用 OSS 庫 StringTemplate 來實現此目的。

例如，考慮一個簡單的提示模板

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

在 Spring AI 中，提示模板可以類比於 Spring MVC 架構中的“檢視 (View)”。提供一個模型物件（通常是一個 java.util.Map）來填充模板中的佔位符。“渲染”後的字串成為提供給 AI 模型的提示詞內容。

傳送給模型的提示詞的具體資料格式存在相當大的差異。最初是簡單的字串，但提示詞已經演變為包含多條訊息，其中每條訊息中的每個字串都代表模型的一個不同角色。

嵌入 (Embeddings)

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

嵌入透過將文字、影像和影片轉換為浮點數陣列（稱為向量）來工作。這些向量旨在捕獲文字、影像和影片的含義。嵌入陣列的長度稱為向量的維度。

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

Embeddings

作為探索 AI 的 Java 開發者，無需理解這些向量表示背後複雜的數學理論或具體的實現細節。只需對它們在 AI 系統中的作用和功能有一個基本瞭解即可，尤其是在將 AI 功能整合到應用程式中時。

嵌入在實際應用中尤其相關，例如檢索增強生成（RAG）模式。它們能夠將資料表示為語義空間中的點，類似於歐幾里得幾何學中的二維空間，但在更高的維度中。這意味著就像歐幾里得幾何學中平面上的點根據其座標可以接近或遠離一樣，在語義空間中，點的接近程度反映了意義上的相似性。關於相似主題的句子在這個多維空間中的位置更接近，就像圖上相互靠近的點一樣。這種接近性有助於執行文字分類、語義搜尋甚至產品推薦等任務，因為它允許 AI 根據概念在這個擴充套件的語義景觀中的“位置”來區分和分組相關的概念。

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

詞元 (Tokens)

詞元是 AI 模型工作的基礎構建塊。在輸入時，模型將單詞轉換為詞元。在輸出時，模型將詞元轉換回單詞。

在英語中，一個詞元大約相當於一個單詞的 75%。作為參考，莎士比亞的全部作品總計約 900,000 個單詞，轉換為約 120 萬個詞元。

Tokens

也許更重要的是，詞元 = 金錢。在使用託管 AI 模型時，你的費用取決於所使用的詞元數量。輸入和輸出都會計入總詞元數。

此外，模型受詞元限制，這限制了單次 API 呼叫中處理的文字量。這個閾值通常被稱為“上下文視窗 (context window)”。模型不會處理超過此限制的任何文字。

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

為了用 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 模型以整合您的資料：

  • 微調 (Fine Tuning)：這是一種傳統的機器學習技術，涉及調整模型並改變其內部權重。然而，對於機器學習專家來說，這是一個具有挑戰性的過程，而且對於像 GPT 這樣大小的模型來說，資源消耗非常大。此外，有些模型可能不提供此選項。

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

Prompt stuffing

  • 工具呼叫 (Tool Calling)：此技術允許註冊工具（使用者定義的服務），將大型語言模型連線到外部系統的 API。Spring AI 極大地簡化了您編寫以支援工具呼叫所需的程式碼。

檢索增強生成 (Retrieval Augmented Generation)

一種稱為檢索增強生成（RAG）的技術已經出現，用於解決將相關資料納入提示詞中以獲得準確 AI 模型響應的挑戰。

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

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

  1. 在保持內容語義邊界的同時將文件分割成部分。例如，對於包含段落和表格的文件，應避免在段落或表格中間分割文件。對於程式碼，避免在方法的實現中間分割程式碼。

  2. 將文件的部分進一步分割成大小佔 AI 模型詞元限制很小百分比的部分。

RAG 的下一階段是處理使用者輸入。當需要 AI 模型回答使用者的提問時，該問題以及所有“相似”的文件片段都會被放入傳送給 AI 模型的提示詞中。這就是使用向量資料庫的原因。它非常善於查詢相似的內容。

Spring AI RAG

  • ETL 管道 提供了關於如何協調從資料來源提取資料並將其儲存在結構化向量儲存中的更多資訊，確保資料以最優格式儲存，以便在將其傳遞給 AI 模型時進行檢索。

  • ChatClient - RAG 解釋瞭如何使用 QuestionAnswerAdvisor 在應用程式中啟用 RAG 功能。

工具呼叫 (Tool Calling)

大型語言模型 (LLM) 在訓練後是固定的，導致知識陳舊，並且無法訪問或修改外部資料。

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

Spring AI 極大地簡化了您編寫以支援工具呼叫所需的程式碼。它為您處理工具呼叫對話。您可以將您的工具作為帶有 @Tool 註解的方法提供，並在您的提示選項中提供它，使其可供模型使用。此外，您可以在單個提示詞中定義和引用多個工具。

The main sequence of actions for tool calling

  1. 當我們要讓模型可以使用某個工具時，我們將該工具的定義包含在聊天請求中。每個工具定義包括一個名稱、一個描述以及輸入引數的模式。

  2. 當模型決定呼叫某個工具時，它會發送一個響應，其中包含工具名稱和根據定義的模式建模的輸入引數。

  3. 應用程式負責使用工具名稱識別並執行帶有提供的輸入引數的工具。

  4. 工具呼叫的結果由應用程式處理。

  5. 應用程式將工具呼叫結果傳送回模型。

  6. 模型使用工具呼叫結果作為附加上下文生成最終響應。

請參閱工具呼叫文件，瞭解如何在不同的 AI 模型中使用此功能的更多資訊。

評估 AI 響應

有效評估 AI 系統響應使用者請求的輸出對於確保最終應用程式的準確性和有用性至關重要。一些新興技術允許使用預訓練模型本身來實現此目的。

此評估過程涉及分析生成的響應是否與使用者意圖和查詢上下文一致。使用相關性、連貫性和事實準確性等指標來衡量 AI 生成響應的質量。

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

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

Spring AI 專案提供了一個 Evaluator API，目前提供對評估模型響應的基本策略的訪問。有關更多資訊，請參閱評估測試文件。