把關你的荷包，怎樣節省使用 OpenAI API token

每個月打開 OpenAI API 帳單，會懷疑它是否多了一個零。解決方式有：避免重複文章、明確而有限的答案選項、將多次請求包裹成一次請求、不要機器人額外解釋、選擇合適的模型、長文章分割策略、小量測試

Photo by Siyan Ren on StockSnap

解決方式

1. 避免重複文章

當文章資料量大時，可能沒注意到將重複文章內容送到 OpenAI API。請參考這篇文章 MySQL 如何尋找重複的文章 (文字類型資料)。

如果呼叫 OpenAI API 的任務的結果，不會需要經常變化。就可以考慮將結果儲存，重複使用。例如：短文的文章翻譯結果儲存，再呼叫 API 重新翻譯之前，可以檢查是否先前已經翻譯過

2. 文章資料前處理

例如：標點符號、emoji、網址等可以視專案需要，事先從文章內容中移除。

3. 明確而有限的答案選項

初期還在探索階段，會向 ChatGPT 提出開放式問題，並且期望它給予你讓你驚艷、有創意的答案。但開放式問題通常會得到更長的答案，也代表會增加成本。如果想要得到簡潔且划算的答案，建議提供明確且有限的選項，讓 AI 從中選擇。

提示 (prompt) 例子

請從以下文章內容粹取出數個重要的關鍵字
```
文章內容
```

修改後的提示

請幫我從文章內容選出一個或多個關鍵字。可用的關鍵字清單：科技, 法律, 政治, 商業, 生活。如果沒有則回答 NA。不需要額外解釋
```
文章內容
```

4. 將多次請求包裹成一次請求

如果文章內容相對比較短，例如文章標題或者是比較簡短的使用者留言。則可以將文章內容合併成一次的請求。

修改後的提示

每一行代表文章的編號和內容。每篇文章，請選擇以下的關鍵字：keyword1、keyword2、keyword3、keyword4、keyword5。以CSV格式回答："文章編號"，"逗號分隔的關鍵字"
```
No1. 第一篇文章的短文內容（不含換行符號）
No2. 第二篇文章的短文內容（不含換行符號）
...
No5. 第五篇文章的短文內容（不含換行符號）
```

API 請求時需要考量 max_length ，因此可以自行決定要將多少篇短文合併。

5. 不要機器人額外解釋

比較 GPT 3 跟 GPT 4，前者是省話一哥。使用 GPT-4 API 處理分類或關鍵字萃取時，有時候會遇到真實資料的狀況，導致機器人回覆「對不起，我需要更多的資訊才能進行分析。請提供一些使用者的留言或評論。」機器人會用各種文字來解釋它找不到的狀況，反而浪費 token。可以在 prompt 要求「如果沒有則回答NA。不要額外解釋。」

修改提示

請幫我從文章內容選出一個或多個關鍵字。可用的關鍵字清單：科技, 法律, 政治, 商業, 生活。如果沒有則回答 NA。不需要額外解釋
```
文章內容
```

6. 選擇合適的模型 (model)

實務上會將比較複雜的任務交給 GPT-4，而將比較簡單的任務 (例如：翻譯) 交給 GPT-3.5。選擇合適的模型，也可以達到節省荷包的效果。關於不同模型的功用，請參考文件：Models - OpenAI API

7. 選擇長文章分割策略 (chunk)

不同模型的最大可處理 tokens 數不同。API 參數 max_length，包含 prompt 輸入和輸出。不同模型 gpt3.5-turbo 可處理約 4千 (4,097) token 、gpt-3.5-turbo-16k 約一萬六 (16,385 tokens) token、gpt-4 是八千 (8,192) token。當超過現有模型 token 上限時，就會需要決定分割長文章，再依次送給 API 處理。

也可以視專案需求決定是否要分割長文章？如果不分割長文章，代表只能取文章部分內容：只取長文章的開頭段落，還是最後面段落？

分割長文章的方式，則可以參考 LangChain 的 text-split-explorer 分割文章的變數有 (1) 分隔符號：換行符號或者是空白、(2) chunk_size：每個區塊要包含的文字數 (characters)、(3) chunk_overlap：區塊前後要重複多少文字數 (characters)。

8. 大量文章 API 請求前，先小量測試

先跑約十篇的小量文章的測試，確認結果符合預期後，再進行大量文章的 API 呼叫。

將 OpenAI API 的回答結構化，則可以節省後續資料清理的功夫。可參考自訂 ChatGPT 回答問題的方式，快速結構化文章

Err

搜尋此網誌