Logprobs 作為機率的對數值,反映了模型對每個 token 的信心度。理解 Logprobs 有助於評估模型輸出品質、進行模型校準以及分析提示內容。在分類別任務中,Logprobs 可用於調整模型輸出,使其更符合實際需求,例如判斷電子郵件是否專業。此外,Logprobs 還能幫助檢測提示內容中的異常,例如拼寫錯誤。選擇合適的 LLM 時,需要考量模型的智慧程度、速度、成本、易用性和功能性等因素。Anthropic、Mistral、Cohere、Google 和 Meta 等供應商提供了多種模型選擇。針對特定任務,可以透過微調技術(如完整微調和 LoRA 微調)提升模型效能。LoRA 微調作為一種引數高效的技術,適用於資料量較小或需要快速調整模型的場景。最後,對話式代理賦予 LLM 與外部世界互動的能力,使其能執行更複雜的任務。
超越文字:Logprobs 的應用
在探討大語言模型(LLM)時,我們通常將其視為「輸入文字」後產生「輸出文字」的過程。然而,除了文字輸出之外,還有一些技巧可以分析模型對文字的看法,這些看法是以數值形式呈現的,例如 logprobs(機率的對數值)。Logprobs 代表模型對每個 token 機率的評估,瞭解這些數值有助於我們更好地掌握模型的輸出品質和信心度。
Logprobs 的基本概念
在第二章中,我們討論了 LLM 如何計算下一個 token 的機率分佈。這些機率以 logprobs 的形式傳回,logprobs 是機率的對數值。一個 logprob 值為負數,其值越負,表示模型認為該 token 的機率越低。若 logprob 為 0,表示模型對該 token 充滿信心。要將 logprob 轉換為標準機率,可以使用指數函式(exp)。例如,如果「Yes」和「No」的 logprobs 分別為 -0.405 和 -1.099,那麼模型對「Yes」的信心度約為 66%,而對「No」的信心度約為 33%。
如何取得 Logprobs
在使用 OpenAI API 的模型中,可以請求傳回 logprobs,如圖 2-12 所示。這樣不僅能獲得模型最終選擇的 token 機率,還能得到模型考慮過但未採用的 token 機率。由於模型在生成文字時本就會計算這些機率,檢索它們並不需要額外的計算資源。
Logprobs 的應用
利用 logprobs 可以進行多種有趣的操作,例如評估答案品質、讓模型估計其信心度,以及在文字中找出關鍵位置。
評估答案品質
Logprobs 可以用來評估模型的信心度,從而判斷其答案的可靠性。將 logprobs 相加可以顯示模型對整個文字的信心度。然而,對於較長的文字,由於表達方式的多樣性,這種評估方法的準確性可能會降低。因此,平均 logprobs 成為一個更有效的評估方法。
簡單平均 logprobs(將所有 logprobs 相加後除以 token 數量)是一種有效的方法,尤其是在資料稀缺或時間有限的情況下。Albert 在開發 GitHub Copilot 時發現,對生成文字的前幾個 token 的機率進行平均,可以預測整體品質。這種平均方法提供了數值化的品質指標。
實際應用範例
- 僅在模型充滿信心時顯示修正建議。
- 當模型遇到困難時發出警告。
- 在模型遇到困難時提供更多上下文或重試。
- 切換到更智慧(但更昂貴)的 LLM 以獲得更好的結果。
- 僅在模型非常確定需要干預時才打斷使用者。
重點解讀:Logprobs 與模型信心度
Logprobs 提供了一個視窗,讓我們得以一窺模型的「思考過程」。透過分析 logprobs,我們可以更好地理解模型的信心度,並據此調整應用的行為。這不僅能提升使用者經驗,還能讓我們更有效地利用 LLM 的能力。
使用Logprobs提升大語言模型(LLM)的分類別能力與校準
大語言模型(LLM)在進行分類別任務時,能夠藉由logprobs獲得模型決策過程中的信心度和可靠性。本文將探討LLM在分類別任務中的應用,以及如何利用logprobs進行校準和最佳化。
分類別任務與LLM的挑戰
分類別是機器學習中的基本任務,涉及將特定例項歸類別到預定義的類別中。LLM雖然是為生成長篇、創意文字而設計,但在處理依賴公共知識和常識的分類別任務時,只要提示工程設計得當,也能表現出色。
設計有效的提示
要使LLM正確執行分類別任務,提示的設計至關重要。有效的提示應該引導模型明確選擇其中一個選項。例如,若要判斷一封電子郵件是否專業,可以詢問模型:
這封電子郵件是否專業?請以以下格式回答:
1. 是 / 否
2. 說明
這種格式不僅要求模型給出明確的答案,還要求提供解釋,有助於理解模型的決策過程。
Logprobs在分類別中的作用
Logprobs提供了模型對每個輸出標記(token)的信心度,這對於理解模型的決策過程至關重要。在分類別任務中,logprobs可以用於校準模型的輸出,使其更符合實際需求。
校準模型輸出
校準是指調整模型的信心度,使其更貼近真實的信心度。例如,在判斷電子郵件是否專業的應用中,如果模型過於嚴格,可以透過調整logprobs來降低門檻,使其更傾向於認為電子郵件是專業的。
# 示例:調整logprobs以校準模型輸出
def calibrate_logprobs(logprobs, bias):
for token, logprob in logprobs.items():
logprobs[token] += bias.get(token, 0)
return logprobs
# 假設的logprobs和偏差值
logprobs = {"Yes": -0.5, "No": -0.8}
bias = {"Yes": 0.3}
calibrated_logprobs = calibrate_logprobs(logprobs, bias)
print(calibrated_logprobs)
Logit Bias的應用
許多模型提供者在其API中提供logit bias功能,允許使用者直接傳遞偏差值($a_{tok}$),從而調整模型的輸出。這樣,使用者無需手動修改logprobs即可實作校準。
利用Logprobs分析提示內容
Logprobs不僅可以用於理解模型的輸出,還可以用於分析提示內容本身。透過設定echo引數為true,可以取得提示內容的logprobs,從而檢測出乎意料的部分,例如拼寫錯誤。
示例:檢測拼寫錯誤
# 假設API呼叫傳回的logprobs
logprobs_for_prompt = {"compl": -13.0, "completion": -2.0}
# 分析logprobs以檢測異常
for token, logprob in logprobs_for_prompt.items():
if logprob < -10:
print(f"發現異常token:{token},其logprob為:{logprob}")
選擇適當的模型
在開發人工智慧軟體時,選擇合適的大語言模型(LLM)至關重要。本章將探討選擇LLM時需要考慮的關鍵因素。
模型選擇的重要性
選擇正確的LLM對於AI軟體開發專案的成功至關重要。由於新模型不斷湧現,推薦特定的模型可能會很快過時。因此,本章將重點介紹指導模型選擇的基本原則。
模型選擇的考量因素
在選擇LLM時,需要考慮以下因素(按重要性順序排列):
- 智慧程度:模型的答案與具有強大主題專業知識的智慧人類專家的答案有多接近?這對於需要複雜推理或非常準確答案的應用程式尤為重要。
- 速度:需要等待多久才能得到答案?這對於與使用者直接互動的應用程式尤為重要。
- 成本:執行推理的成本是多少,無論是直接支付給模型提供者還是GPU成本?這對於頻繁請求模型的應用程式尤為重要。
- 易用性:有多少工作可以方便地完成,例如安排GPU、佈署模型、重新啟動當機的例項、路由、快取等?
- 功能性:模型是否具有指示、聊天和工具使用的功能?是否提供logprobs?是否可以處理影像和語言?
特殊需求
某些開發者可能有特定的需求,例如:
- 非商業或開源模型
- 在特定資料上訓練的模型
- 資料駐留在特定國家
- 避免在外部記錄
這些需求可以快速縮小可用模型的範圍。
內容解密:
在選擇LLM時,必須根據具體需求權衡各種因素。沒有一個模型能夠滿足所有需求,因此需要仔細評估和選擇。
模型供應商的選擇
選擇模型供應商通常是第一步。供應商提供各種模型,可以根據特定功能和需求進行選擇。一些知名的供應商包括:
- Anthropic:強調人類對齊和AI安全,其Claude 3.5 Sonnet模型在2024年躍居多個LLM基準測試的首位。
- Mistral:專注於高效、開放權重的模型,適合需要非常特殊組態的應用程式。
- Cohere:在高效能RAG應用程式中很受歡迎。
- Google:與Google生態系統強烈整合,擁有尖端研究和大規模基礎設施。
- Meta:大型、高能力的開放存取模型。
程式碼範例:使用LiteLLM統一API
from litellm import completion
# 使用LiteLLM統一API呼叫不同模型的範例
response = completion(
model="claude-3.5-sonnet",
messages=[{"content": "Hello, how are you?", "role": "user"}]
)
print(response)
內容解密:
此程式碼範例展示瞭如何使用LiteLLM提供的統一API來呼叫不同的LLM。在這個例子中,我們使用了Claude 3.5 Sonnet模型,並向它發送了一條使用者訊息。LiteLLM使得在不同模型之間切換變得更加容易。
自行託管模型的考量
如果不需要高階模型,可以考慮自行託管開源LLM,如LLaMA或Mistral。雖然這需要大量的努力,但像Hugging Face這樣的平台可以簡化這一過程。
此圖示說明瞭根據需求選擇合適模型的決策流程。
內容解密:
圖表顯示了在決定是否使用LLM-as-a-service或自行託管開源LLM時的關鍵決策點。如果需要高階模型,通常選擇LLM-as-a-service;否則,可以考慮自行託管。自行託管可以藉助Hugging Face等平台來簡化流程。
總之,選擇合適的LLM需要綜合考慮多種因素,包括智慧程度、速度、成本、易用性和功能性等。根據具體需求選擇合適的模型供應商或考慮自行託管開源模型,可以更好地滿足專案需求。
選擇適當的模型與微調技術
在選擇大語言模型(LLM)提供者時,您通常需要在供應商提供的多種模型之間進行選擇。除了考慮模型的功能外,模型大小是一個重要的決定因素。無論延遲是否重要,產出品質與成本之間的權衡始終是一個挑戰。通常,您會希望選擇能夠可靠完成任務的最小模型。
在原型設計階段,可以使用比預期稍大的模型。隨著新型旗艦模型的發布,舊模型往往會隨著時間變得更便宜。因此,當您的公開測試版推出時,將會有更好的模型可供選擇。如果您的提示工程和後處理已經針對更好的模型進行了最佳化,那麼您將會受益。
您可能永遠都不想從頭開始建立和訓練自己的模型,但您可能會想要對現有的模型進行微調,使其專門針對您的應用程式將要使用的任務。這個過程稱為微調。雖然這個主題超出了本文的範圍,但我們希望讓您熟悉基本概念,以便您能夠判斷這是否是一個有前途的想法,以及是否值得投入更多時間。
微調的基本概念
當LLM首次接受訓練時,它實際上是讀取大量的檔案並學習如何模仿它們。在微調過程中,您向模型提供新的檔案,並訓練它模仿這些檔案。這通常會降低模型產生通用檔案的能力,但可以顯著提高模型產生您預期在工作中看到的檔案型別的能力。
要微調模型,您需要一組展示成功互動的訓練檔案。這些檔案應該具有事實正確的答案,只使用您希望模型學習的背景資訊,並遵守預期的格式。您該如何收集這些範例呢?您可以自己建立一些,僱用承包商,甚至合成它們。如果您的應用程式有使用者,您可能會根據接受的建議或使用者點贊等成功指標收集範例。如果您的應用程式自動執行以前由人工完成的任務,您可以使用他們的互動作為範例。是否能夠收集這些範例是決定微調是否值得的關鍵。
微調的不同方法
根據您提出的訓練檔案數量,您將有不同種類別的微調選項。我們將在這裡討論主要的選項,並在表7-2中進行了總結。
完整微調(Full Fine-Tuning)
完整微調,或稱為持續預訓練,只是使用不同檔案的訓練過程的延續。這意味著模型的數十億個引數都會被調整,並且需要時間、計算能力和許多範例來以正確的方式調整引數。與所有神經網路訓練一樣,這不是向人類解釋一個概念並期望他們透過理解來學習。這更像是河床的形成:您將成千上萬的訓練檔案傾倒在模型上,慢慢地,一條溝槽被刻出來。優點是,這條新溝槽可以是任何東西。原始模型是起點,但您可以教它全新的事實和新的領域。
低秩適應(Low-Rank Adaptation, LoRA)
LoRA是一種引數高效的微調技術,旨在使模型訓練更有效率。其關鍵思想是,當您不需要模型學習全新的東西時,您不必調整其所有引數。相反,LoRA專注於LLM中的幾個關鍵引數矩陣,並訓練一個“差異”到這些矩陣,這對於每個原始矩陣是一個差異矩陣,它被新增到原始矩陣中,但具有較少的自由度(因此,它是低秩的)。
這種方法具有實用上的好處——由於差異很小,它們可以輕易地在虛擬機器之間共用,一個佈署可以處理多個差異,從而允許您在同一台機器上使用不同的模型。更重要的是,LoRA微調相對較快,通常需要幾個小時或幾天,使其成為一個計算效率高的選項。
然而,也有缺點:根據LoRA維度(衡量您訓練的差異的自由度的數字),模型的學習能力是有限的。一般來說,一個好的直覺是,LoRA並不是真的教會模型新的技巧。相反,LoRA教會模型哪些它已經能夠執行的技巧應該被期待使用,以及如何使用。特別是,這包括諸如要注意提示中的什麼,如何解釋它,以及在完成中對模型有什麼期望。格式和風格很容易透過LoRA學習。LoRA擅長做的另一件事是給予模型關於它應該為您的領域假設的先驗分佈的一般感覺。
讓我們透過一個例子來解釋最後一點。假設您的應用程式幫助人們選擇旅遊目的地,並且您的所有客戶都來自歐洲。作為歐洲人,他們的首選建議將與來自美國的人有非常不同的分佈。納帕谷很遙遠,而摩納哥就在附近。微調可以教會模型這一點,但公平地說,您也可以這樣做:您可以在提示中新增客戶是歐洲人,因此模型應該根據這一點選擇目的地。但是,您不知道的其他因素呢?也許您的應用程式的大多數使用者都是學生,他們正在尋找預算目的地。您的應用程式遙測資料可能顯示,建議摩納哥通常會得到大拇指,但每次您建議布拉格時,使用者都會購買機票。如果您有這樣的資料來提供,LoRA微調擅長於使模型適應這種分佈變化,無論它取決於您意識到的方面(對預算目的地的偏好)還是其他因素。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 大語言模型 Logprobs 技術應用與分析
package "LLM Logprobs 技術應用" {
package "Logprobs 基礎" {
component [機率對數值] as logprob
component [Token 信心度] as token
component [機率轉換] as convert
}
package "應用場景" {
component [答案品質評估] as quality
component [模型校準] as calibrate
component [分類任務] as classify
}
package "進階應用" {
component [模型選擇] as select
component [LoRA 微調] as lora
component [對話式代理] as agent
}
}
logprob --> token : 反映信心度
token --> convert : exp() 轉換
convert --> quality : 品質評估
quality --> calibrate : 模型校準
calibrate --> classify : 分類決策
classify --> select : 模型選擇
select --> lora : 高效微調
lora --> agent : 代理構建
note right of logprob
Logprobs 特性:
- 負數值表示
- 0 表示高信心
- 無額外計算成本
end note
note right of quality
實際應用:
- 信心度顯示建議
- 困難時發出警告
- 動態切換模型
end note
@enduml
此圖示說明瞭選擇微調方法的決策流程
內容解密:
- 決策起點:流程從評估是否有足夠的訓練檔案開始。
- 條件分支:根據是否有足夠的訓練檔案,決定是否進行完整微調。
- 進一步評估:如果沒有足夠的訓練檔案,則評估是否需要高效微調。
- 選擇微調方法:根據需求選擇完整微調或LoRA微調。
- 結果評估:最終對微調效果進行評估,以確定是否達到預期目標。
選擇模型的考量
在選擇LLM時,除了考慮模型的整體效能外,還需要考慮模型的規模和微調能力。較小的模型可能在成本和延遲方面具有優勢,而較大的模型則可能提供更好的產出品質。透過原型設計和測試,可以找到在成本和效能之間取得最佳平衡的模型。
微調技術的重要性
微調技術使LLM能夠適應特定的任務和領域,從而提高其在特定應用中的效能。完整微調和LoRA微調各有其優缺點,選擇適合的微調方法取決於具體的需求和資源限制。
完整微調 vs. LoRA微調
- 完整微調能夠使模型學習新的知識和領域,但需要大量的計算資源和訓練資料。
- LoRA微調則是一種更高效的方法,透過調整模型的關鍵引數來適應新的任務,而不需要修改所有引數。
對話式代理(Conversational Agency)的進階技術
在第三章中,我們討論了從文字完成模型到聊天模型的轉變。聊天模型本身只能意識到訓練資料中的資訊以及使用者剛剛告訴它的資訊。聊天模型無法主動取得訓練期間不可用的資訊,也無法代表使用者與外界互動並採取外部行動。
對話式代理的挑戰與進步
目前,LLM 社群正在透過對話式代理(Conversational Agency)克服這些限制。所謂的代理能力,是指一個實體能夠以自主和自導的方式完成任務並實作目標的能力。本章討論的對話式代理提供了一種類別似於聊天的體驗——使用者與助手之間的來回對話——但增加了助手能夠接觸到真實世界、學習新資訊並與真實世界的資產互動的能力。
建構對話式代理的先進方法
在本章中,我們將介紹幾種根據 LLM 的對話式代理的最新建構方法。我們將探討模型如何使用工具來接觸外部世界,如何透過條件設定使其更好地推理問題空間,以及如何收集最佳上下文以促進長時間或複雜的互動。讀完本章後,您將能夠建立自己的對話式代理,使其能夠代表您執行引導任務。
工具的使用
單獨工作的語言模型在能實作的功能上存在侷限性。當然,與聊天助手對話是很有趣的,因為在某些方面,它是數位世界的精髓。您可以從廣泛的話題中學習任何您想知道的東西,模型可以借鑒多樣化的思想流派並幫助您進行腦力激盪。
對話式代理中的工具使用範例
# 使用工具呼叫外部 API 取得最新資訊
import requests
def get_latest_news(topic):
api_url = f"https://newsapi.org/v2/everything?q={topic}&apiKey=YOUR_API_KEY"
response = requests.get(api_url)
return response.json()
# LLM 模型根據輸入決定是否呼叫工具
def conversational_agent(user_input):
if "最新新聞" in user_input:
topic = user_input.split("關於")[1]
news = get_latest_news(topic)
return f"根據最新訊息,{topic} 的相關新聞如下:{news}"
else:
return "我還無法處理這個請求。"
# 測試對話式代理
print(conversational_agent("告訴我關於人工智慧的最新新聞"))
內容解密:
get_latest_news函式:此函式負責呼叫外部 API 以取得指定主題的最新新聞。它使用了requests函式庫來傳送 HTTP 請求,並傳回 JSON 格式的回應結果。conversational_agent函式:該函式模擬了一個簡單的對話式代理。它根據使用者的輸入決定是否呼叫get_latest_news工具來取得資訊。如果使用者的輸入包含「最新新聞」,則提取主題並呼叫工具;否則,傳回無法處理該請求的訊息。- 外部 API 呼叫:這裡展示瞭如何透過程式碼與外部世界互動,取得即時資訊並將其納入對話式代理的回應中。
未來趨勢與實務應用評估
對話式代理的發展趨勢顯示,未來的 LLM 將更加註重自主性和互動能力。這不僅意味著模型需要具備更強的推理和決策能力,還需要能夠無縫地與外部工具和系統整合,以提供更豐富和即時的服務。