基礎模型 REST API 參考
本文提供 Databricks Foundation 模型 API 及其支援的模型一般 API 資訊。 基礎模型 API 的設計類似於 OpenAI 的 REST API,讓移轉現有的專案更容易。 每個令牌付費和布建的輸送量端點都接受相同的 REST API 要求格式。
端點
每個每個令牌付費模型都有單一端點,而且使用者可以使用 HTTP POST 要求與這些端點互動。 您可以使用 API 或服務 UI 來建立布建的輸送量端點。 只要兩個服務模型都公開相同的 API 格式,這些端點也會針對 A/B 測試的每個端點支援多個模型。 例如,這兩個模型都是聊天模型。
要求和回應會使用 JSON,確切的 JSON 結構取決於端點的工作類型。 聊天和完成端點支援串流回應。
按令牌付費工作負載支援特定模型,請參閱 這些模型和已接受 API 格式的按令牌 付費支援模型。
使用方式
回應包含 usage
子訊息,其會報告要求和回應中的令牌數目。 此子訊息的格式在所有工作類型中都相同。
欄位 | 類型 | 描述 |
---|---|---|
completion_tokens |
整數 | 產生的令牌數目。 不包含在內嵌回應中。 |
prompt_tokens |
整數 | 輸入提示字元中的令牌數目。 |
total_tokens |
整數 | 令牌總數。 |
對於像是 llama-2-70b-chat
使用者提示的模型,會在傳遞至模型之前,先使用提示範本進行轉換。 針對每個令牌的付費端點,系統提示可能也會新增。 prompt_tokens
包含伺服器新增的所有文字。
聊天工作
聊天工作已針對具有模型的多回合交談進行優化。 每個要求都會描述到目前為止的對話,其中 messages
字段必須在 和 assistant
角色之間user
交替,並以訊息結尾user
。 模型回應會在交談中提供下一 assistant
則訊息。
聊天要求
欄位 | 預設 | 類型 | 描述 |
---|---|---|---|
messages |
ChatMessage 清單 | 必要。 代表目前交談的訊息清單。 | |
max_tokens |
nil |
大於零或 nil 的整數,代表無限大 |
要產生的令牌數目上限。 |
stream |
true |
布林值 | 將回應串流回用戶端,以允許要求的部分結果。 如果要求中包含此參數,則會使用伺服器 傳送的事件 標準來傳送回應。 |
temperature |
1.0 |
Float in [0,2] | 取樣溫度。 0 是具決定性的,且較高的值引進了更多的隨機性。 |
top_p |
1.0 |
浮點數 (0,1] | 用於核取樣的機率臨界值。 |
top_k |
nil |
大於零或 nil 的整數,代表無限大 |
定義最可能用於 top-k-filtering 的 k 標記數目。 將此值設定為 1,讓輸出具決定性。 |
stop |
[] | 字串或清單[字串] | 當 遇到 中的任何序列時,模型會停止產生進一步的 stop 令牌。 |
n |
1 | 大於零的整數 | 當指定時n ,API 會傳n 回獨立的聊天完成。 建議用於在相同輸入上產生多個完成的工作負載,以節省額外的推斷效率和節省成本。 僅適用於布建的輸送量端點。 |
tool_choice |
nil |
字串或 ToolChoiceObject | 僅搭配欄位使用 tools 。 tool_choice 支援各種關鍵字字串,例如 auto 、 required 與 none 。 auto 表示您讓模型決定哪一種(如果有的話)工具與使用有關。 auto 如果模型不認為 中的任何工具tools 都相關,模型會產生標準助理訊息,而不是工具呼叫。 required 表示模型會在 中 tools 挑選最相關的工具,而且必須產生工具呼叫。 none 表示模型不會產生任何工具呼叫,而必須產生標準助理訊息。 若要使用 中 tools 定義的特定工具強制呼叫工具,請使用 ToolChoiceObject。 根據預設,如果 tools 欄位已填入 tool_choice = "auto" 。 否則, tools 欄位預設為 tool_choice = "none" |
tools |
nil |
ToolObject | 模型可以呼叫的清單 tools 。 function 目前,是唯一支援的tool 型別,最多支援 32 個函式。 |
ChatMessage
欄位 | 類型 | 描述 |
---|---|---|
role |
String | 必要。 訊息作者的角色。 可以是"system" 、 "user" "assistant" 或 "tool" 。 |
content |
String | 訊息的內容。 不涉及工具呼叫的聊天工作所需 。 |
tool_calls |
ToolCall 清單 | 模型產生的清單 tool_calls 。 欄位必須具有 role as "assistant" 且沒有規格 content 。 |
tool_call_id |
String | 當 為 "tool" 時role ,與訊息所回應之 相關聯的ToolCall 標識符。 其他 role 選項必須是空的。 |
system
角色只能使用一次,做為交談中的第一則訊息。 它會覆寫模型的預設系統提示字元。
ToolCall
模型的工具呼叫動作建議。 請參閱 Azure Databricks 上的函式呼叫。
欄位 | 類型 | 描述 |
---|---|---|
id |
String | 必要。 此工具呼叫建議的唯一標識符。 |
type |
String | 必要。 只支援 "function" 。 |
function |
FunctionCallCompletion | 必要。 模型建議的函式呼叫。 |
FunctionCallCompletion
欄位 | 類型 | 描述 |
---|---|---|
name |
String | 必要。 模型建議的函式名稱。 |
arguments |
Object | 必要。 函式的自變數做為串行化的 JSON 字典。 |
ToolChoiceObject
請參閱 Azure Databricks 上的函式呼叫。
欄位 | 類型 | 描述 |
---|---|---|
type |
String | 必要。 工具的型別。 目前僅支援 "function" 。 |
function |
Object | 必要。 對象,定義要呼叫表單{"type": "function", "function": {"name": "my_function"}} 的工具,其中 "my_function 是字段中 FunctionObjecttools 的名稱。 |
ToolObject
請參閱 Azure Databricks 上的函式呼叫。
欄位 | 類型 | 描述 |
---|---|---|
type |
String | 必要。 工具的型別。 目前僅支援 function 。 |
function |
FunctionObject | 必要。 與工具相關聯的函式定義。 |
FunctionObject
欄位 | 類型 | 描述 |
---|---|---|
name |
String | 必要。 要呼叫函式的名稱。 |
description |
Object | 必要。 函式的詳細描述。 此模型會使用此描述來瞭解函式與提示的相關性,併產生具有較高精確度的工具呼叫。 |
parameters |
Object | 函式接受的參數,描述為有效的 JSON 架構 物件。 如果呼叫此工具,則工具呼叫會符合提供的 JSON 架構。 省略參數會定義不含任何參數的函式。 的數目 properties 限制為15個索引鍵。 |
聊天回應
對於非串流要求,回應是單一聊天完成物件。 對於串流要求,回應是 text/event-stream
每個事件都是完成區塊物件。 完成和區塊物件的最上層結構幾乎完全相同:只有 choices
不同的類型。
欄位 | 類型 | 描述 |
---|---|---|
id |
String | 聊天完成的唯一標識碼。 |
choices |
List[ChatCompletionChoice] 或 List[ChatCompletionChunk] (streaming) | 聊天完成文字的清單。 n 如果指定參數, n 則會傳回選項。 |
object |
String | 物件類型。 等於 "chat.completions" 非串流或 "chat.completion.chunk" 串流。 |
created |
整數 | 聊天完成的時間以秒為單位。 |
model |
String | 用來產生回應的模型版本。 |
usage |
使用方式 | 令牌使用方式元數據。 串流回應上可能不存在。 |
ChatCompletionChoice
欄位 | 類型 | 描述 |
---|---|---|
index |
整數 | 所產生選項清單中的選擇索引。 |
message |
ChatMessage | 模型傳回的聊天完成訊息。 角色將會是 assistant 。 |
finish_reason |
String | 模型停止產生權杖的原因。 |
ChatCompletionChunk
欄位 | 類型 | 描述 |
---|---|---|
index |
整數 | 所產生選項清單中的選擇索引。 |
delta |
ChatMessage | 來自模型所產生串流回應的聊天完成訊息部分。 保證只會填入第一個區塊 role 。 |
finish_reason |
String | 模型停止產生權杖的原因。 只有最後一個區塊才會填入此專案。 |
完成工作
文字完成工作是用來產生單一提示的回應。 不同於聊天,此工作支援批次輸入:可以在一個要求中傳送多個獨立提示。
完成要求
欄位 | 預設 | 類型 | 描述 |
---|---|---|---|
prompt |
字串或清單[字串] | 必要。 模型的提示。。 | |
max_tokens |
nil |
大於零或 nil 的整數,代表無限大 |
要產生的令牌數目上限。 |
stream |
true |
布林值 | 將回應串流回用戶端,以允許要求的部分結果。 如果要求中包含此參數,則會使用伺服器 傳送的事件 標準來傳送回應。 |
temperature |
1.0 |
Float in [0,2] | 取樣溫度。 0 是具決定性的,且較高的值引進了更多的隨機性。 |
top_p |
1.0 |
浮點數 (0,1] | 用於核取樣的機率臨界值。 |
top_k |
nil |
大於零或 nil 的整數,代表無限大 |
定義最可能用於 top-k-filtering 的 k 標記數目。 將此值設定為 1,讓輸出具決定性。 |
error_behavior |
"error" |
"truncate" 或 "error" |
針對逾時和超過內容長度的錯誤。 其中一個: "truncate" (傳回盡可能多的令牌)和 "error" (傳回錯誤)。 此參數只接受每個令牌端點的付費。 |
n |
1 | 大於零的整數 | 當指定時n ,API 會傳n 回獨立的聊天完成。 建議用於在相同輸入上產生多個完成的工作負載,以節省額外的推斷效率和節省成本。 僅適用於布建的輸送量端點。 |
stop |
[] | 字串或清單[字串] | 當 遇到 中的任何序列時,模型會停止產生進一步的 stop 令牌。 |
suffix |
"" |
String | 附加至每個完成結尾的字串。 |
echo |
false |
布林值 | 傳回提示以及完成。 |
use_raw_prompt |
false |
布林值 | 如果 true 為 ,則直接將 傳遞 prompt 至模型,而不需要任何轉換。 |
完成回應
欄位 | 類型 | 描述 |
---|---|---|
id |
String | 文字完成的唯一標識碼。 |
choices |
CompletionChoice | 文字完成的清單。 針對傳入的每個提示,如果n 已指定,n 就會產生選擇。 預設值 n 為 1。 |
object |
String | 物件類型。 等於 "text_completion" |
created |
整數 | 完成的時間以秒為單位。 |
usage |
使用方式 | 令牌使用方式元數據。 |
CompletionChoice
欄位 | 類型 | 描述 |
---|---|---|
index |
整數 | 要求中提示的索引。 |
text |
String | 產生的完成。 |
finish_reason |
String | 模型停止產生權杖的原因。 |
內嵌工作
內嵌工作會將輸入字串對應至內嵌向量。 每個要求中都可以將許多輸入批處理在一起。
內嵌要求
欄位 | 類型 | 描述 |
---|---|---|
input |
字串或清單[字串] | 必要。 要內嵌的輸入文字。 可以是字串或字串清單。 |
instruction |
String | 傳遞至內嵌模型的選擇性指示。 |
指示是選擇性且高度特定的模型。 例如,BGE 作者在編製區塊索引時,不建議使用指示 "Represent this sentence for searching relevant passages:"
來擷取查詢。 Instructor-XL 等其他模型支持各種不同的指令字串。
內嵌回應
欄位 | 類型 | 描述 |
---|---|---|
id |
String | 內嵌的唯一標識碼。 |
object |
String | 物件類型。 等於 "list" 。 |
model |
String | 用來建立內嵌的內嵌模型名稱。 |
data |
EmbeddingObject | 內嵌物件。 |
usage |
使用方式 | 令牌使用方式元數據。 |
EmbeddingObject
欄位 | 類型 | 描述 |
---|---|---|
object |
String | 物件類型。 等於 "embedding" 。 |
index |
整數 | 內嵌在模型所產生的內嵌清單中之內嵌的索引。 |
embedding |
List[Float] | 內嵌向量。 每個模型都會傳回固定大小向量(BGE-Large 為 1024) |
其他資源
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應