簡單概括
你應該使用自己的模型，還是使用 LLM API？建立你自己的模型可以讓你完全控制，但需要資料收集、訓練和部署方面的專業知識。LLM API 使用起來更簡單，但會將資料傳送給第三方，並對提供商有強烈依賴。這篇部落格讓你可以將 LLM 的便利性與定製模型的控制性和效率相結合。
在一個關於識別新聞報導中投資者情緒的案例研究中，我們展示瞭如何使用開源 LLM 建立合成資料，並在幾個步驟中訓練你的定製模型。我們定製的 RoBERTa 模型可以分析大型新聞資料集，與 GPT4 相比效能一致都是 (94% acc 和 0.94 的 F1 macro)，我們只需 2.7 美元，排碳 0.12kg，延遲 0.13s ; 而 GPT4 要費 3061 美元，排碳約 735 到 1100 kg ，延遲多秒。這裡提供了 notebooks 方便你用於自己的研究。
1. 問題: 你的使用案例沒有資料
想象一下你的老闆讓你去建一個你公司的情感分析系統。你可以在 Hugging Face Hub 上找到 100,000+ 個資料集，這其中包含標題含有 “sentiment” 的欄位的資料集， Twitter 上的情感資料集、詩歌中的情感或以希伯來語的情感資料集。這很好，但比如你在一家金融機構工作並且你追蹤你投資組合中特定品牌的市場情緒，那麼你可能會發現上面這些資料集沒有一個有用的。雖然機器學習需要處理數百萬的任務公司，但正巧別人已經收集併發布你公司的這個案例的資料集的可能性機會幾乎為零。
由於對特定領域的資料集和模型的缺失，許多人嘗試用更加通用的 LLM。這些模型都非常大和通用，以至於它們可以開箱即用，並實現令人印象深刻的準確度。它們的易於使用的 API 消除了對微調和對部署的專業知識的需求。但他們最主要的缺點是大小和可控性: 大小超過十億到萬億的引數執行在計算叢集中，控制權只在少數的幾家公司手中。
2. 解決方案: 合成資料來高效蒸餾學生模型
在 2023 年，一個東西根本的改變了機器學習的藍圖，LLM 開始達到和人類資料標註者相同的水平。現在有大量的證據表明，最好的 LLM 比眾包工人更勝一籌，並且在建立高質量 (合成的) 資料中部分達到了專家水平 (例如 Zheng et al. 2023, Gilardi et al. 2023, He et al. 2023)。這一進展的重要性怎麼強調都不為過。建立定製模型的關鍵瓶頸在於招募和協調人工工作者以創造定製訓練資料的資金、時間和專業知識需求。隨著大型語言模型 (LLMs) 開始達到人類水平，高質量的資料標註現在可以透過 API 獲得; 可複製的註釋指令可以作為提示 prompt 傳送; 合成資料幾乎可以立即返回，唯一的瓶頸就剩計算能力了。
在 2024 年，這種方法將變得具有商業可行性，並提升開源對大中小企業的重要性。在 2023 年的大部分時間裡，由於 LLM API 提供商的限制性商業條款，LLMs 的商業用途在標註資料方面被阻止。隨著像 Mistral 的 Mixtral-8x7B-Instruct-v0.1 這樣的模型的推出，LLM 資料標註和合成資料現在對商業用途開放。Mixtral 的表現與 GPT3.5 相當，並且由於它的 Apache 2.0 許可證，其合成資料輸出可以作為商業用例中較小、專業化的模型 (“學生”) 的訓練資料。這篇部落格提供了一個示例，這將顯著加快你自己的定製模型的建立速度，同時大幅降低長期推理成本。
3. 案例分析: 監控金融情緒
想象你是一個資料科學家，正在為一家大型投資公司工作。你的任務是監控經濟新聞情緒，以幫助公司做出投資決策。最近，你有兩個主要選擇:
- 你可以微調你自己的模型。這需要編寫標註指令，建立標註介面，招人，引入質量保證措施以處理低質量資料，在這個資料上微調模型，並部署。
- 或者，你可以按照指令將資料傳送到 LLM API。你完全跳過微調和部署步驟，將資料分析過程簡化為編寫指令 (提示)，然後傳送給 API 背後的“LLM 標註器”。在這種情況下，LLM API 就是你的最終推理解決方案，你直接使用 LLM 的輸出進行分析。
儘管選項 2 在推理時間上更貴，並且需要你傳送敏感資料到第三方，但選項 2 比選項 1 更容易設定，因此被許多開發人員使用。
在 2024 年，合成資料將提供第三個選項: 結合選項 1 的成本效益與選項 2 的簡易性。你可以使用一個 LLM (老師模型) 去標註一個你的小資料樣本，並在這個資料集上微調一個小的，高效的語言模型 (學生模型)。這種方法可以在幾步內執行完成。
3.1 給 LLM 提示來標註你的資料
我們使用 financial_phrasebank 情感資料集作為示例，但你可以將程式碼適配到任何其他用例。financial_phrasebank 任務是一個 3 類分類任務，其中 16 位專家從投資者視角對芬蘭公司金融新聞中的句子進行“積極”/“消極”/“中性”標註 ( Malo et al. 2013 )。例如，資料集中包含這樣一句話: “對於 2010 年最後一個季度，Componenta 的淨銷售額翻倍，達到 1.31 億歐元，而去年同期為 7600 萬歐元”，標註者從投資者視角將其歸類為“積極”。
我們首先安裝一些必需的庫。
!pip install datasets # for loading the example dataset
!pip install huggingface_hub # for secure token handling
!pip install requests # for making API requests
!pip install scikit-learn # for evaluation metrics
!pip install pandas # for post-processing some data
!pip install tqdm # for progress bars
然後，我們可以下載帶有專家標註的示例資料集。
from datasets import load_dataset
dataset = load_dataset("financial_phrasebank", "sentences_allagree", split='train')
# create a new column with the numeric label verbalised as label_text (e.g. "positive" instead of "0")
label_map = {
i: label_text
for i, label_text in enumerate(dataset.features["label"].names)
}
def add_label_text(example):
example["label_text"] = label_map[example["label"]]
return example
dataset = dataset.map(add_label_text)
print(dataset)
# Dataset({
# features: ['sentence', 'label', 'label_text'],
# num_rows: 2264
#})
現在我們寫一個短的標註指令，針對 financial_phrasebank 任務，並將其格式化為一個 LLM 提示。這個提示類似於你通常提供給眾包工人的指令。
prompt_financial_sentiment = """\
You are a highly qualified expert trained to annotate machine learning training data.
Your task is to analyze the sentiment in the TEXT below from an investor perspective and label it with only one the three labels:
positive, negative, or neutral.
Base your label decision only on the TEXT and do not speculate e.g. based on prior knowledge about a company.
Do not provide any explanations and only respond with one of the labels as one word: negative, positive, or neutral
Examples:
Text: Operating profit increased, from EUR 7m to 9m compared to the previous reporting period.
Label: positive
Text: The company generated net sales of 11.3 million euro this year.
Label: neutral
Text: Profit before taxes decreased to EUR 14m, compared to EUR 19m in the previous period.
Label: negative
Your TEXT to analyse:
TEXT: {text}
Label: """
這個標註指令現在可以被傳遞給 LLM API。對於這個例子，我們使用免費 Hugging Face 無服務的推理 API。這個 API 是測試流行模型的理想選擇。請注意，如果你傳送次數過多，尤其是分享給過多使用者，你可能會遇到速率限制。對於更大的工作流，我們推薦建立一個 專用推理端點。專用推理端點對於你自己的付費 API 尤為重要，特別是你可以靈活的控制開和關。
我們登入 huggingface_hub 庫，簡單安全的填入我們的 API token。或者，你也可以定義你自己的 token 作為環境變數。(詳情可以參考 文件)。
# you need a huggingface account and create a token here: https://huggingface.co/settings/tokens
# we can then safely call on the token with huggingface_hub.get_token()
import huggingface_hub
huggingface_hub.login()
我麼定義一個簡單的 generate_text 函式，用於傳送我們的提示 prompt 和資料到 API。
import os
import requests
# Choose your LLM annotator
# to find available LLMs see: https://huggingface.co/docs/huggingface_hub/main/en/package_reference/inference_client#huggingface_hub.InferenceClient.list_deployed_models
API_URL = "https://api-inference.huggingface.co/models/mistralai/Mixtral-8x7B-Instruct-v0.1"
# docs on different parameters: https://huggingface.co/docs/api-inference/detailed_parameters#text-generation-task
generation_params = dict(
top_p=0.90,
temperature=0.8,
max_new_tokens=128,
return_full_text=False,
use_cache=False
)
def generate_text(prompt=None, generation_params=None):
payload = {
"inputs": prompt,
"parameters": {**generation_params}
}
response = requests.post(
API_URL,
headers={"Authorization": f"Bearer {huggingface_hub.get_token()}"},
json=payload
)
return response.json()[0]["generated_text"]
作為 LLM 可能不會總是返回標籤相同的標準化格式，我們還可以定義一個短 clean_output 函式，將 LLM 從字串輸出對映到我們的三個可能標籤。
labels = ["positive", "negative", "neutral"]
def clean_output(string, random_choice=True):
for category in labels:
if category.lower() in string.lower():
return category
# if the output string cannot be mapped to one of the categories, we either return "FAIL" or choose a random label
if random_choice:
return random.choice(labels)
else:
return "FAIL"
我們現在可以將我們的文字傳送給 LLM 進行標註。下面的程式碼將每一段文字傳送到 LLM API，並將文字輸出對映到我們的三個清晰類別。注意: 在實際操作中，逐個文字迭代並將它們分別傳送到 API 是非常低效的。API 可以同時處理多個文字，你可以非同步地批次向 API 傳送文字來顯著加快 API 呼叫速度。你可以在本部落格的 復現倉庫 中找到最佳化後的程式碼。
output_simple = []
for text in dataset["sentence"]:
# add text into the prompt template
prompt_formatted = prompt_financial_sentiment.format(text=text)
# send text to API
output = generate_text(
prompt=prompt_formatted, generation_params=generation_params
)
# clean output
output_cl = clean_output(output, random_choice=True)
output_simple.append(output_cl)
基於這個輸出，我麼可以計算指標來檢視模型在不對其進行訓練的情況下是否準確地完成了任務。
from sklearn.metrics import classification_report
def compute_metrics(label_experts, label_pred):
# classification report gives us both aggregate and per-class metrics
metrics_report = classification_report(
label_experts, label_pred, digits=2, output_dict=True, zero_division='warn'
)
return metrics_report
label_experts = dataset["label_text"]
label_pred = output_simple
metrics = compute_metrics(label_experts, label_pred)
基於簡單的提示 prompt，LLM 正確分類了 91.6% 的文字 (0.916 準確率和 0.916 F1 macro)。考慮到它沒有訓練來完成這個具體任務，這相當不錯。
我們透過使用兩個簡單的提示 Prompt 技巧來進一步提升精度: 思維鏈 COT 和 自我一致 SC。CoT 要求模型首先對正確的標籤進行推理，然後再做出標註決策，而不是立即決定正確的標籤。SC 意味著多次向同一個 LLM 傳送相同文字的相同提示。SC 有效地為 LLM 提供了針對每段文字的多條不同的推理路徑，如果 LLM 回應“積極”兩次和“中性”一次，我們選擇多數 (“積極”) 作為正確的標籤。這是我們為 CoT 和 SC 更新的提示:
prompt_financial_sentiment_cot = """\
You are a highly qualified expert trained to annotate machine learning training data.
Your task is to briefly analyze the sentiment in the TEXT below from an investor perspective and then label it with only one the three labels:
positive, negative, neutral.
Base your label decision only on the TEXT and do not speculate e.g. based on prior knowledge about a company.
You first reason step by step about the correct label and then return your label.
You ALWAYS respond only in the following JSON format: {{"reason": "...", "label": "..."}}
You only respond with one single JSON response.
Examples:
Text: Operating profit increased, from EUR 7m to 9m compared to the previous reporting period.
JSON response: {{"reason": "An increase in operating profit is positive for investors", "label": "positive"}}
Text: The company generated net sales of 11.3 million euro this year.
JSON response: {{"reason": "The text only mentions financials without indication if they are better or worse than before", "label": "neutral"}}
Text: Profit before taxes decreased to EUR 14m, compared to EUR 19m in the previous period.
JSON response: {{"reason": "A decrease in profit is negative for investors", "label": "negative"}}
Your TEXT to analyse:
TEXT: {text}
JSON response: """
這是一個 JSON 提示，我們要求 LLM 返回一個結構化的 JSON 字串，其中 “reason” 作為一個鍵，“label” 作為另一個鍵。JSON 的主要優點是我們可以將其解析為 Python 字典，然後提取 “label” 。如果我們想了解 LLM 選擇這個標籤的原因，我們也可以提取 “reason”。
process_output_cot 函式解析 LLM 返回的 JSON 字串，並且如果 LLM 沒有返回有效的 JSON，它會嘗試使用上面定義的 clean_output 函式透過簡單的字串匹配來識別標籤。
import ast
def process_output_cot(output):
try:
output_dic = ast.literal_eval(output)
return output_dic
except Exception as e:
# if json/dict parse fails, do simple search for occurance of first label term
print(f"Parsing failed for output: {output}, Error: {e}")
output_cl = clean_output(output, random_choice=False)
output_dic = {"reason": "FAIL", "label": output_cl}
return output_dic
現在，我們可以使用上面新的提示重複使用我們的 generate_text 函式，用 process_output_cot 處理 JSON 的 COT 輸出，並且為了 SC 多次傳送每個提示。
self_consistency_iterations = 3
output_cot_multiple = []
for _ in range(self_consistency_iterations):
output_lst_step = []
for text in tqdm(dataset["sentence"]):
prompt_formatted = prompt_financial_sentiment_cot.format(text=text)
output = generate_text(
prompt=prompt_formatted, generation_params=generation_params
)
output_dic = process_output_cot(output)
output_lst_step.append(output_dic["label"])
output_cot_multiple.append(output_lst_step)
對於每段文字，我們現在的 LLM 標註器有了三次嘗試來識別正確標籤，並採用了三種不同的推理路徑。下面的程式碼從這三條路徑中選擇了多數標籤。
import pandas as pd
from collections import Counter
def find_majority(row):
# Count occurrences
count = Counter(row)
# Find majority
majority = count.most_common(1)[0]
# Check if it's a real majority or if all labels are equally frequent
if majority[1] > 1:
return majority[0]
else: # in case all labels appear with equal frequency
return random.choice(labels)
df_output = pd.DataFrame(data=output_cot_multiple).T
df_output['label_pred_cot_multiple'] = df_output.apply(find_majority, axis=1)
現在，我們可以比較我們的改進的 LLM 標籤與專家標籤，並計算指標。
label_experts = dataset["label_text"]
label_pred_cot_multiple = df_output['label_pred_cot_multiple']
metrics_cot_multiple = compute_metrics(label_experts, label_pred_cot_multiple)
CoT 和 SC 將效能提升到了 94.0% 的準確率和 0.94 的 F1 macro。透過給模型時間來考慮其標籤決策，並給予它多次嘗試，我們提升了效能。請注意，CoT 和 SC 需要額外的計算資源。我們本質上是在用計算資源購買標註的準確性。
現在，我們透過這些簡單的 LLM API 呼叫建立了一個合成訓練資料集。我們在做出標籤決策之前，讓 LLM 嘗試了三種不同的推理路徑來標註每段文字。結果是，這些標籤與人類專家的高度一致，並且我們得到了一個高質量的資料集，可以用來訓練更高效、更專業的模型。
df_train = pd.DataFrame({
"text": dataset["sentence"],
"labels": df_output['label_pred_cot_multiple']
})
df_train.to_csv("df_train.csv")
請注意，在這篇部落格文章的 完整復現指令碼 中，我們還將僅基於專家標註建立一個測試集，以評估所有模型的質量。所有指標始終基於這個人類專家測試集。
3.2 將開源模型與專有模型進行比較
使用開源的 Mixtral 模型建立的這種資料的主要優勢在於，這些資料在商業上完全可用，且沒有法律上的不確定性。例如，使用 OpenAI API 建立的資料受 OpenAI 商業條款 的約束，這些條款明確禁止將模型輸出用於訓練與他們的產品和服務競爭的模型。這些條款的法律價值和意義尚不明確，但它們為使用 OpenAI 模型合成的資料訓練模型的商業使用引入了法律上的不確定性。任何使用合成資料訓練的更小、更高效的模型都可能被視為競爭者，因為它減少了對 API 服務的依賴。
開源的 Mistral 的 Mixtral-8x7B-Instruct-v0.1 與 OpenAI 的 GPT3.5 和 GPT4 之間合成的資料質量如何比較呢？我們使用 gpt-3.5-turbo-0613 和 gpt-4-0125-preview 執行了上述相同的流程和提示，並在下表中報告了結果。我們看到，Mixtral 在這個任務上的表現優於 GPT3.5，並且與 GPT4 相當，這取決於提示型別。(我們沒有顯示新版本的 gpt-3.5-turbo-0125 的結果，因為不知何故，這個模型的表現比舊版本的預設 gpt-3.5-turbo-0613 要差)。
請注意，這並不意味著 Mixtral 總是比 GPT3.5 更好，與 GPT4 相當。GPT4 在多個基準測試上的表現更好。主要想表達的是，開源模型現在可以建立高質量的合成資料。
3.3 理解並驗證你合成的資料
所有這些在實踐中意味著什麼呢？到目前為止，結果只是由一些黑盒 LLM 標註的資料。我們只能計算指標，因為我們有來自示例資料集的專家標註的參考資料。如果在真實世界的場景中沒有專家標註，我們如何信任 LLM 的標註呢？
在實踐中，無論你使用哪種標註器 (人類標註或 LLM )，你只能信任你自己驗證過的資料。指令/提示總是包含一定程度的模糊性。即使是一個完美智慧的標註也可能犯錯誤，並且在面對通常模糊的現實世界資料時，必須做出不明確的決定。
幸運的是，隨著近年來開源工具的出現，資料驗證變得更加簡單: Argilla 提供了一個免費的介面，用於驗證和清理非結構化的 LLM 輸出; LabelStudio 使你能夠以多種方式標註資料; CleanLab 提供了一個用於標註和自動清理結構化資料的介面; 對於快速和簡單的驗證，僅在簡單的 Excel 檔案中標註也可能是可以的。
花些時間標註文字，以瞭解資料和其模糊性，這是非常重要的。你會很快發現模型犯了一些錯誤，但也會有幾個例子，正確的標籤是不明確的，有些文字你更同意 LLM 的決定，而不是建立資料集的專家。這些錯誤和模糊性是資料集建立的正常部分。實際上，只有極少數現實世界的任務中，人類專家的基線是完全一致的。這是一個古老的見解，最近被機器學習文獻“重新發現”，即人類資料是一個有缺陷的金標準 (Krippendorf 2004, Hosking et al. 2024)。
在標註介面不到一個小時的時間裡，我們更好地瞭解了我們的資料並糾正了一些錯誤。然而，為了可復現性，以及展示純粹合成資料的質量，我們在下一步繼續使用未清理的 LLM 標註。
3.4 使用 AutoTrain 調整你高效、專業的模型
到目前為止，我們已經經歷了一個標準的流程，即透過 API 提示 LLM 並驗證輸出。現在，進入一個額外的步驟，以實現顯著的資源節約: 我們將在 LLM 的合成資料上微調一個更小、更高效和專業化的 LM。這個過程也被稱為“蒸餾”，其中較大模型的輸出 (“教師”) 用於訓練一個較小的模型 (“學生”)。雖然這聽起來很複雜，但它本質上只意味著我們使用資料集中的原始 text ，並將 LLM 的預測作為我們微調的 labels 。如果你以前訓練過分類器，你知道，使用 transformers 、 sklearn 或其他庫，你只需要這兩個列來訓練一個分類器。
我們使用 Hugging Face 的 AutoTrain 解決方案使這個過程更加簡單。AutoTrain 是一個無程式碼介面，它使你能夠上傳一個帶有標記資料的 .csv 檔案，該服務然後使用它為你自動微調模型。這消除了為訓練你自己的模型編寫程式碼或深入微調專業知識的需求。
在 Hugging Face 網站上，我們首先在頂部點選 “Spaces”，然後點選 “Create new Space”。然後選擇 “Docker”>“AutoTrain” 並選擇一個小型 A10G GPU，每小時成本為 $1.05。AutoTrain 的空間將然後初始化。然後，我們可以透過介面上傳我們的合成訓練資料和專家測試資料，並調整不同的欄位，如下面的截圖所示。填寫所有內容後，我們可以點選 “Start Training”，並在 Space 的日誌中跟蹤訓練過程。僅在 1811 個資料點上訓練一個小型的 RoBERTa-base 模型 (~0.13 B 引數) 非常快，可能不需要超過幾分鐘。一旦訓練完成，模型將自動上傳到你的 HF 個人資料。一旦訓練完成，space 就會停止，整個過程最多應該需要 15 分鐘，成本不到 $1。
如果你願意，你也可以完全在你自己的硬體上本地使用 AutoTrain，請參閱我們的 文件。高階使用者當然總是可以編寫自己的訓練指令碼，但對於這些預設的超引數，AutoTrain 的結果對於許多分類任務來說應該足夠了。
我們最終微調的約 0.13B 引數的 RoBERTa-base 模型與更大的 LLM 相比表現如何？下圖顯示，在 1811 個文字上微調的自定義模型達到了 94% 的準確率，與它的老師 Mixtral 和 GPT4 一樣！一個小型模型當然無法與一個更大型的 LLM 出廠即戰，但透過在一些高質量資料上進行微調，它可以達到在它所專長的任務上與大型 LLM 相同的效能水平。
3.5 不同方法的利弊
我們在開始時討論的三種方法的總體優缺點是什麼:(1) 手動建立你自己的資料和模型，(2) 僅使用 LLM API，或者 (3) 使用 LLM API 建立用於專業模型的合成資料？下面的表格顯示了不同因素之間的權衡，我們將在下面根據我們的示例資料集討論不同的指標。
讓我們從任務效能開始。如上所示，專業模型與更大型的 LLM 表現相當。微調後的模型只能執行我們訓練它執行的特定任務，但它在執行這個特定任務方面表現非常好。要建立更多訓練資料來將模型適應到新的領域或更復雜的任務是輕而易舉的。多虧了 LLM 的合成資料，由於缺乏專業資料而導致的低效能不再是問題。
其次，計算成本和推理速度。實際中的主要計算成本將是推理，即在訓練後執行模型。假設在你的生產用例中，你需要在給定時間段內處理 100 萬句話。我們的微調 RoBERTa-base 模型在一個帶有 16GB RAM 的小型 T4 GPU 上執行效率很高，在 推理端點 上的成本為每小時 $0.6。它具有 0.13s 的延遲和每秒 61 句話的吞吐量 ( batch_size=8 )。這使得處理 100 萬句話的總成本為 $2.7。
使用 GPT 模型，我們可以透過計算 token 來計算推理成本。處理 100 萬句話的 toekn 將花費 GPT3.5 約 $153，GPT4 約 $3061。這些模型的延遲和吞吐量更加複雜，因為它們根據一天中的當前伺服器負載而變化。任何使用 GPT4 的人都清楚，延遲通常可以是多秒，並且受到速率限制。請注意，速度是任何 LLM (API) 的問題，包括開源 LLM。許多生成型 LLM 由於過大而無法快速執行。
訓練計算成本往往不太相關，因為 LLM 可以不經過微調直接使用，且小型模型的微調成本相對較小 (微調 RoBERTa-base 的成本不到 $1)。只有在需要將大型生成型 LLM 專門化以執行特定生成任務時，才需要投資從頭開始預訓練模型。當微調一個更大的生成型 LLM 以使其適應特定生成任務時，訓練成本可能變得相關。
第三，在時間和專業知識方面的投資。這是 LLM API 的主要優勢。與手動收集資料、微調定製模型和部署相比，向 API 傳送指令要容易得多。這正是使用 LLM API 建立合成資料變得重要的地方。建立良好的訓練資料變得顯著更容易。然後，微調和部署可以由 AutoTrain 等服務和專業推理端點處理。
第四，控制。這可能是 LLM API 的主要缺點。按設計，LLM API 使你依賴於 LLM API 提供商。你需要將敏感資料傳送到別人的伺服器，並且你無法控制系統的可靠性和速度。自己訓練模型可以讓你選擇如何和在哪裡部署它。
最後，環境影響。由於缺乏有關模型架構和硬體基礎設施的資訊，很難估計 GPT4 等封閉模型的能源消耗和二氧化碳排放。我們找到的 最佳 (但非常粗略) 估計 顯示，GPT4 查詢的能源消耗約為 0.0017 至 0.0026 千瓦時。這將是分析 100 萬句話的大致 1700 至 2600 千瓦時。根據 EPA 二氧化碳當量計算器，這相當於 0.735 至 1.1 公噸二氧化碳，或平均汽車行駛 1885 至 2883 英里。請注意，實際二氧化碳排放可以根據 LLM 特定計算區域的能源混合而有很大差異。與我們的自定義模型相比，這個估計要容易得多。使用自定義模型分析 100 萬句話，在一個 T4 GPU 上大約需要 4.52 小時，在 US East N. Virginia 的 AWS 伺服器上，這相當於大約 0.12 公斤二氧化碳 (見 ML CO2 Impact calculator)。與具有 (據稱) 8x220B 引數的通用 LLM 相比，執行一個專門化的模型 (約 0.13B 引數) 的效率低下得多。
結論
我們已經展示了使用 LLM 建立合成資料來訓練一個更小、更高效的模型的巨大好處。雖然這個例子只處理了投資者情緒分類，但同樣的流程可以應用於許多其他任務，從其他分類任務 (例如，客戶意圖檢測或有害內容檢測)，到 token 分類 (例如，命名實體識別或 PII 檢測)，或生成任務 (例如，總結或問答)。
在 2024 年，公司建立自己的高效模型、控制自己的資料和基礎設施、減少二氧化碳排放、節省計算成本和時間，而不必妥協準確性的難度從未如此之低。
現在，親自動手嘗試一下！你可以在本部落格文章中找到所有數字的完整復現程式碼，以及更高效的非同步函式和批次 API 呼叫的程式碼，在 復現倉庫 中。我們邀請你複製並適配我們的程式碼以應用於你的用例！
英文原文: https://hf.co/blog/synthetic-data-save-costs
原文作者: Moritz Laurer
譯者: innovation64