.NET 控制台應用程式示範了 Azure OpenAI LogProbs 如何用於品質資訊檢索的四個範例:
git clone https://github.com/bartczernicki/AzureOpenAILogProbs.git
{
"AzureOpenAI" : {
"ModelDeploymentName" : "gpt-4-2024-04-09" , // Any Azure OpenAI GPT-4o-mini, GPT-4o or GPT3.5 model should perform well
"APIKey" : "YOURAZUREOPENAIKEY" ,
"Endpoint" : "https://YOURAZUREOPENAIENDPOINT.openai.azure.com/"
}
}
dotnet build
dotnet run
在此設定中,法學碩士將獲得維基百科關於紐約大都會棒球隊歷史的文章中的選定段落。完整的文章可以在這裡找到:https://en.wikipedia.org/wiki/New_York_Mets。這是每個提示中始終提供的上下文(基礎資訊)。
此外,也提供了20對問答。清單中的每個項目都有一個關於 Mets 維基百科文章的問題,並配有人工評估對/錯,如果提供的維基百科文章中有足夠的資訊來回答該問題。每個問題都會發送給法學碩士,然後法學碩士將評估是否有足夠的資訊來回答該問題。這個答案將與人類的評估(邏輯真理)進行比較。 20 個問題清單中的兩個範例:
new Question { Number = 1 , EnoughInformationInProvidedContext = true , QuestionText = " When where the Mets founded? " } ,
new Question { Number = 2 , EnoughInformationInProvidedContext = true , QuestionText = " Are the Mets a baseball team or basketball team? " } ,
預設情況下,檢查令牌日誌機率的功能處於關閉狀態。若要啟用此功能,應將IncludeLogProbativity屬性設為 true。這不會花費任何額外的令牌,也不會讓 API 呼叫花費更多的錢。然而,這會稍微增加傳回的 JSON 物件的負載。例如,使用新的 OpenAI .NET 函式庫,它會作為 ChatCompletionOptions 類別的屬性公開。
chatCompletionOptions . IncludeLogProbabilities = true ;
.NET 函式庫中包含控制每個 API 呼叫傳回的日誌機率數量的功能。這提供了具有各自機率的標記數組/列表。在統計學中,這稱為機率質量函數 (PMF),因為它是機率的離散分佈。注意:在 Azure OpenAI 上,目前最大值為 5,在 OpenAI 10 上(對於大多數 API)。例如,使用新的 OpenAI .NET 函式庫,它會作為 ChatCompletionOptions 類別的屬性公開。
chatCompletionOptions . TopLogProbabilityCount = 5 ;
該解決方案還包括設定 (LLM) 模型的每個預期輸出的溫度的能力。預設值為 0.3f(浮點數),但可以增加到 2f 以獲得更多創造力和變化。
internal static class GenAI
{
// To simulate more variance in selecting lower probability tokens, increase the temperature to between 1.4 - 2.0.
public const float OPENAITEMPATURE = 0.3f ;
.. .
這本質上是該解決方案的核心設定。其餘程式碼是 C# 程式碼,用於連接服務的輸入/輸出,並確保計算正確執行並在控制台應用程式中視覺化。
什麼是 LogProb(對數機率)?大多數目前的 LLM 透過預測下一個令牌並迭代每個令牌直到到達停止點(即最大令牌長度,完成使用者指令)來處理提示指令。對於考慮輸出的每個令牌,都透過內部 LLM 管道進行處理,該管道輸出可供選擇的「最佳匹配」令牌的統計機率分佈。基於配置(溫度、top_p 等),可以計算這些令牌機率,然後 LLM 根據不同的配置選擇下一個「最佳匹配」令牌。由於這些 LLM 本質上是機率性的,因此您可能會看到發送到 (LLM) 模型的相同提示指令的不同標記輸出。
以下是一個問答場景的範例,以及選擇回答以下問題的兩個標記(單字)的相關機率: “誰是美國第一任總統?” 。在下面的範例中,模型回答了兩個標記“George”“Washington”,標記機率分別為 99.62% 和 99.99%。請注意,還有其他標記可供選擇,但法學碩士固有的知識和推理能力(來自大量數據的訓練)自信地增加了這兩個標記的機率:「喬治」和「華盛頓」。
有一些設置可以校準法學碩士的嚴格程度或創造性。例如,您可能聽說過一種名為「溫度」的 (LLM) 模型設置,它本質上增加了選擇較低機率標記的機會。
需要更多資訊嗎? Azure OpenAI LogProbs 背景推薦閱讀:
有各種經過驗證的新改進技術,它們使用對一個模型或多個模型的多次呼叫來得出回應、結論或品質決策。目前,LLM 在 GenAI 生產系統中使用的大多數方式是透過提供額外的上下文資訊來接地(RAG)。 (LLM) 模型被要求回答問題、對該資訊進行推理等。
Azure OpenAI LogProbs 是一種先進的技術,可以幫助測量模型回應的置信度(機率)。這種巨大的能力可以使 GenAI 系統能夠自我糾正或指導使用者/代理商獲得更高品質的回應。
下面透過 GenAI 工作流程圖說明了 LogProbs 的強大功能。請注意,有兩條路徑(左和右):
範例輸出:
請注意,上圖說明了 LLM 的 True 和 False 輸出以及 True 或 False 輸出的機率。由於「True」或「False」是回應中的第一個也是唯一的標記,因此可以使用第一個標記 (LogProb) 機率。這種方法有幾個問題:
Brier 分數將根據模型功能、提示和問題上下文而有所不同。透過保持提示和上下文相同,可以比較整體模型的準確性效能。請注意下面比較 GPT-4o 和 GPT-4o-mini 模型的 Brier 分數。 GPT-4o-mini 模型的 Brier 分數較低,這意味著它在預測正確答案反應的機率方面更加準確。事實上,GPT-4o-mini 正確地得出了20 個問題中的18 個問題的最終答案,而GPT-4o 模型正確地得出了20 個問題中的17 個問題的最終答案(如果上下文中有足夠的資訊來回答問題)問題。請注意,GPT-4o-mini 的平均 Brier 分數為 0.083(低於 0.1),這表示預測表現優異。因此,GPT-4o-mini 模型的 Brier 分數較低(較好)。這從經驗上表明,它在量化有足夠資訊來回答所提供的提示問題的機率方面更加準確。
範例輸出:
若要傳回多個日誌機率,請將 LogProbativityPerToken 設為 5(截至撰寫本文時目前的 Azure OpenAI 最大值):
chatCompletionOptions.Temperature = 0.3f; // Higher Temperature setting will use tokens with much lower probability
chatCompletionOptions.IncludeLogProbabilities = true;
// For the Confidence Score, we want to investigate 5 of the top log probabilities (PMF)
chatCompletionOptions.TopLogProbabilityCount = 5;
範例輸出:
以下是傳回 5 個 LogProbs 令牌及其各自機率時的令牌機率分佈範例。在下面的直方圖中,「置信度分數:1」的機率為 42.3%;這意味著模型認為回答問題的置信度分數=1 非常低,且機率較低為 42.3%。如果您僅選擇模型傳回的最高置信度分數,則可能會遺失其他標記(標記編號 2 - 5)的大量其他資訊。在這種情況下,還有大約 57% 的資訊可以使用其他令牌機率來計算「加權」置信度分數,該置信度分數從 1 -> 2.3 進行校準。
範例輸出:
這個 repo 沒有涉及模型置信度得分的校準,也沒有涉及模型機率 LogProbs 的校準。由於法學碩士本質上是神經網絡,因此它們可能無法針對特定任務或領域進行校準。基本上,當 LLM 表示其置信度為 8/10 或確定機率為 80% 時,模型應該在大約 80% 的時間內正確(在錯誤率範圍內)。
統計模擬顯示 10,000,000 次模擬和 100 個問題 80% 校準的預期範圍:
這些校準技術適用於現實場景。考慮 Mainifold Markets (https://manifold.markets/),人類超級預測者會對事件的機率下注。這些人類超級預測者的集體智慧在預測現實世界事件方面得到了高度校準!
來自 Manifold Markets 的數千個預測的真實預測環境中的校準範例:
校準這個主題並不新鮮,決策理論和機器學習領域已經對其進行了研究。您可以應用決策智慧(認知科學)和機器學習技術來進一步校準模型效能。