聊天模型
概述
大型語言模型 (LLM) 是先進的機器學習模型,擅長處理各種與語言相關的任務,例如文本生成、翻譯、摘要、問答等,而無需為每個場景進行特定任務的微調。
現代 LLM 通常透過聊天模型介面存取,該介面接受 訊息 列表作為輸入,並返回 訊息 作為輸出。
最新一代的聊天模型提供額外功能
- 工具調用:許多流行的聊天模型提供原生的 工具調用 API。此 API 允許開發人員建構豐富的應用程式,使 LLM 能夠與外部服務、API 和資料庫互動。工具調用也可用於從非結構化資料中擷取結構化資訊並執行各種其他任務。
- 結構化輸出:一種使聊天模型以結構化格式(例如符合給定架構的 JSON)回應的技術。
- 多模態:處理文本以外資料的能力;例如,圖像、音訊和視訊。
功能
LangChain 為使用來自不同提供者的聊天模型提供一致的介面,同時為監控、偵錯和最佳化使用 LLM 的應用程式的效能提供額外功能。
- 與許多聊天模型提供者(例如 Anthropic、OpenAI、Ollama、Microsoft Azure、Google Vertex、Amazon Bedrock、Hugging Face、Cohere、Groq)整合。請參閱 聊天模型整合 以取得支援模型的最新列表。
- 使用 LangChain 的 訊息 格式或 OpenAI 格式。
- 標準 工具調用 API:用於將工具綁定到模型、存取模型發出的工具調用請求以及將工具結果發送回模型的標準介面。
- 用於透過
with_structured_output
方法結構化輸出的標準 API。 - 提供對 非同步程式設計、高效批處理、豐富的串流 API 的支援。
- 與 LangSmith 整合,用於監控和偵錯基於 LLM 的生產級應用程式。
- 額外功能,例如標準化 token 使用量、速率限制、快取 等。
整合
LangChain 有許多聊天模型整合,可讓您使用來自不同提供者的各種模型。
這些整合分為兩種型別
- 官方模型:這些模型是 LangChain 和/或模型提供者官方支援的模型。您可以在
langchain-<provider>
套件中找到這些模型。 - 社群模型:有些模型主要由社群貢獻和支援。您可以在
langchain-community
套件中找到這些模型。
LangChain 聊天模型以在類別名稱前加上「Chat」的慣例命名(例如,ChatOllama
、ChatAnthropic
、ChatOpenAI
等)。
請查看 聊天模型整合 以取得支援模型的列表。
名稱中不包含「Chat」前綴或名稱中包含「LLM」後綴的模型通常是指不遵循聊天模型介面的舊模型,而是使用接受字串作為輸入並返回字串作為輸出的介面。
介面
LangChain 聊天模型實作 BaseChatModel 介面。由於 BaseChatModel
也實作 Runnable 介面,因此聊天模型支援 標準串流介面、非同步程式設計、最佳化的 批處理 等。請參閱 Runnable 介面 以取得更多詳細資訊。
聊天模型的許多關鍵方法都對 訊息 進行操作作為輸入,並返回訊息作為輸出。
聊天模型提供一組標準參數,可用於配置模型。這些參數通常用於控制模型的行為,例如輸出的溫度、回應中的最大 token 數以及等待回應的最大時間。請參閱 標準參數 區段以取得更多詳細資訊。
在文件中,我們經常交替使用術語「LLM」和「聊天模型」。這是因為大多數現代 LLM 都是透過聊天模型介面向使用者公開的。
但是,LangChain 也實作了不遵循聊天模型介面的舊 LLM,而是使用接受字串作為輸入並返回字串作為輸出的介面。這些模型通常在名稱中沒有「Chat」前綴(例如,Ollama
、Anthropic
、OpenAI
等)。這些模型實作 BaseLLM 介面,並且可能以「LLM」後綴命名(例如,OllamaLLM
、AnthropicLLM
、OpenAILLM
等)。一般而言,使用者不應使用這些模型。
關鍵方法
聊天模型的關鍵方法是
- invoke:與聊天模型互動的主要方法。它接受 訊息 列表作為輸入,並返回訊息列表作為輸出。
- stream:一種允許您在產生聊天模型輸出時串流輸出的方法。
- batch:一種允許您將多個請求批次處理到聊天模型,以實現更有效率的處理的方法。
- bind_tools:一種允許您將工具綁定到聊天模型以在模型執行環境中使用的方法。
- with_structured_output:
invoke
方法的包裝器,適用於原生支援 結構化輸出 的模型。
其他重要方法可以在 BaseChatModel API 參考 中找到。
輸入和輸出
現代 LLM 通常透過聊天模型介面存取,該介面接受 訊息 作為輸入,並返回 訊息 作為輸出。訊息通常與角色(例如,「系統」、「人類」、「助理」)和一個或多個內容區塊相關聯,這些內容區塊包含文本或可能的多模態資料(例如,圖像、音訊、視訊)。
LangChain 支援兩種訊息格式與聊天模型互動
- LangChain 訊息格式:LangChain 自己的訊息格式,預設使用,並在 LangChain 內部使用。
- OpenAI 的訊息格式:OpenAI 的訊息格式。
標準參數
許多聊天模型都有標準化參數,可用於配置模型
參數 | 描述 |
---|---|
model | 您要使用的特定 AI 模型的名稱或識別碼(例如,"gpt-3.5-turbo" 或 "gpt-4" )。 |
temperature | 控制模型輸出的隨機性。較高的值(例如 1.0)使回應更具創造力,而較低的值(例如 0.0)使它們更具確定性和重點。 |
timeout | 在取消請求之前,等待模型回應的最長時間(以秒為單位)。確保請求不會無限期地掛起。 |
max_tokens | 限制回應中 token(單字和標點符號)的總數。這控制了輸出可以有多長。 |
stop | 指定停止序列,指示模型何時應停止產生 token。例如,您可以使用特定的字串來表示回應的結束。 |
max_retries | 如果系統因網路逾時或速率限制等問題而請求失敗,系統將嘗試重新發送請求的最大次數。 |
api_key | 與模型提供者進行身份驗證所需的 API 金鑰。這通常在您註冊存取模型時發出。 |
base_url | 發送請求的 API 端點的 URL。這通常由模型提供者提供,並且對於引導您的請求是必要的。 |
rate_limiter | 可選的 BaseRateLimiter,用於間隔請求以避免超過速率限制。請參閱下面的 速率限制 以取得更多詳細資訊。 |
一些重要的注意事項
- 標準參數僅適用於公開具有預期功能的參數的模型提供者。例如,某些提供者不公開最大輸出 token 的配置,因此在這些提供者上無法支援 max_tokens。
- 標準參數目前僅在具有自己整合套件的整合上強制執行(例如
langchain-openai
、langchain-anthropic
等),它們在langchain-community
中的模型上不強制執行。
聊天模型也接受特定於該整合的其他參數。若要尋找聊天模型支援的所有參數,請前往該模型的各自 API 參考。
工具調用
聊天模型可以調用 工具 來執行任務,例如從資料庫提取資料、發出 API 請求或執行自訂程式碼。請參閱 工具調用 指南以取得更多資訊。
結構化輸出
可以請求聊天模型以特定格式(例如,JSON 或符合特定架構)回應。此功能對於資訊擷取任務非常有用。請在 結構化輸出 指南中閱讀有關該技術的更多資訊。
多模態
大型語言模型 (LLM) 不僅限於處理文本。它們還可以用於處理其他類型的資料,例如圖像、音訊和視訊。這稱為 多模態。
目前,只有部分 LLM 支援多模態輸入,幾乎沒有模型支援多模態輸出。請查閱特定模型文件以取得詳細資訊。
上下文窗口
聊天模型的上下文窗口是指模型一次可以處理的最大輸入序列大小。雖然現代 LLM 的上下文窗口非常大,但它們仍然存在開發人員在使用聊天模型時必須牢記的限制。
如果輸入超出上下文窗口,模型可能無法處理整個輸入並可能引發錯誤。在對話應用程式中,這尤其重要,因為上下文窗口決定了模型在整個對話過程中可以「記住」多少資訊。開發人員通常需要管理上下文窗口內的輸入,以在不超過限制的情況下維持連貫的對話。有關處理對話中記憶體的更多詳細資訊,請參閱 記憶體。
輸入的大小以 token 衡量,token 是模型使用的處理單位。
進階主題
速率限制
許多聊天模型提供者對在給定時間段內可以發出的請求數量施加限制。
如果您達到速率限制,您通常會收到來自提供者的速率限制錯誤回應,並且需要等待才能發出更多請求。
您有幾種選擇來處理速率限制
- 嘗試透過間隔請求來避免達到速率限制:聊天模型接受可以在初始化期間提供的
rate_limiter
參數。此參數用於控制向模型提供者發出請求的速率。在基準測試模型以評估其效能時,間隔向給定模型發出的請求是一種特別有用的策略。請參閱 如何處理速率限制 以取得有關如何使用此功能的更多資訊。 - 嘗試從速率限制錯誤中恢復:如果您收到速率限制錯誤,您可以等待一段時間,然後再重試請求。每次後續的速率限制錯誤都可以增加等待時間。聊天模型具有
max_retries
參數,可用於控制重試次數。請參閱 標準參數 區段以取得更多資訊。 - 回退到另一個聊天模型:如果您在一個聊天模型中達到速率限制,您可以切換到另一個未受速率限制的聊天模型。
快取
聊天模型 API 可能很慢,因此一個自然的問題是是否快取先前對話的結果。從理論上講,快取可以透過減少向模型提供者發出的請求數量來幫助提高效能。實際上,快取聊天模型回應是一個複雜的問題,應謹慎處理。
原因是如果依賴於快取模型的確切輸入,則在對話中的第一次或第二次互動後不太可能獲得快取命中。例如,您認為有多少對話以完全相同的訊息開始?完全相同的三條訊息呢?
另一種方法是使用語義快取,您可以在其中根據輸入的含義而不是確切的輸入本身來快取回應。這在某些情況下可能有效,但在其他情況下則無效。
語義快取在應用程式的關鍵路徑上引入了對另一個模型的依賴性(例如,語義快取可能依賴於 嵌入模型 將文本轉換為向量表示),並且不能保證準確地捕捉輸入的含義。
但是,在某些情況下,快取聊天模型回應可能是有益的。例如,如果您有一個用於回答常見問題的聊天模型,則快取回應可以幫助減少模型提供者、成本的負載,並縮短回應時間。
請參閱 如何快取聊天模型回應 指南以取得更多詳細資訊。