5億個token之後,我們得出關於GPT的七條寶貴經驗

自 ChatGPT 問世以來,OpenAI 一直被認爲是全球生成式大模型的領導者。2023 年 3 月,OpenAI 官方宣佈,開發者可以通過 API 將 ChatGPT 和 Whisper 模型集成到他們的應用程序和產品中。在 GPT-4 發佈的同時 OpenAI 也開放了其 API。

一年過去了,OpenAI 的大模型使用體驗究竟如何,行業內的開發者怎麼評價?

最近,初創公司 Truss 的 CTO Ken Kantzer 發佈了一篇題爲《Lessons after a half-billion GPT tokens》的博客,闡述了在使用 OpenAI 的模型(85% GPT-4、15% GPT-3.5)處理完 5 億個 token 之後,總結出的七條寶貴經驗。

Ken Kantzer

機器之心對這篇博客進行了不改變原意的編譯、整理,以下是博客原文內容:

經驗 1:prompt,少即是多

我們發現,如果 prompt 中的信息已經是常識,那麼該 prompt 不會幫助模型產生更好的結果。GPT 並不愚蠢,如果您過度指定,它實際上會變得混亂。

這與編碼不同,編碼中的一切都必須是明確的。

舉一個讓我們感到困擾的例子:

pipeline 的一部分讀取一些文本塊,並要求 GPT 將其分類爲與美國 50 個州之一相關。這不是一項艱鉅的任務,可以使用字符串 / 正則表達式,但有足夠多奇怪的極端情況,因此需要更長的時間。所以我們的第一次嘗試大致是這樣的:

Here's a block of text. One field should be "locality_id", and it should be the ID of one of the 50 states, or federal, using this list:

[{"locality: "Alabama", "locality_id": 1}, {"locality: "Alaska", "locality_id": 2} ... ]

這有時會起作用(約超過 98% 的情況),但失敗的情況足以讓我們不得不進行更深入的挖掘。

在調查時,我們注意到字段「名稱」始終返回州的全名,儘管我們沒有明確要求它這樣做。

因此,我們改用對名稱進行簡單的字符串搜索來查找狀態,然後模型就一直運行良好。

總而言之,GPT 顯然知道 50 個州。當 prompt 更加模糊時,GPT 的質量和泛化能力都可以提高,這太瘋狂了 —— 這是高階思維的典型標誌。

經驗 2:不需要 langchain

你只需要 chat API,不需要 langchain,甚至可能不需要 OpenAI 去年在其 API 中發佈的任何其他內容。

Langchain 是過早抽象的完美例子。我們開始認爲我們必須使用它。但相反,數百萬個 token 之後,我們可能在生產中使用了 3-4 個非常多樣化的 LLM 函數,而我們的 openai_service 文件中仍然只有一個 40 行的函數:

def extract_json(prompt, variable_length_input, number_retries)

我們使用的唯一 API 是 chat API。我們不需要 JSON 模式、函數調用等等(儘管我們做了所有這些),我們甚至不使用系統 prompt。gpt-4-turbo 發佈時,我們更新了代碼庫中的一個字符串。

這就是強大的廣義模型的美妙之處 —— 少即是多。

該函數中的 40 行代碼大部分都是圍繞 OpenAI API 被關閉的 500s/socket 的錯誤處理。

我們內置了一些自動截斷功能,因此不必擔心上下文長度限制,我們有自己專有的 token 長度估計器。

if s.length > model_context_size * 3

# truncate it!

end

在存在大量句點或數字的極端情況下(token ratio < 3 characters /token),這種方法會失敗。所以還有另一個專有的 try/catch 重試邏輯:

if response_error_code == "context_length_exceeded"

s.truncate(model_context_size * 3 / 1.3)

我們已經依靠上述方法取得了很大進展,並且該方法足夠靈活,可以滿足我們的需求。

經驗 3:通過流式 API 改善延遲並向用戶顯示變速輸入的單詞是 ChatGPT 一項重大的用戶體驗創新

我們曾經認爲這只是一個噱頭,但實際上用戶對「變速輸入字符」的反應非常積極 —— 這感覺就像是人工智能的鼠標 / 光標用戶體驗時刻。

經驗 4:GPT 不擅長產生零假設

「如果找不到任何內容,則返回空輸出」—— 這可能是我們遇到的最容易出錯的 prompting 語言。在此情況下,GPT 不僅會經常出現幻覺而不返回任何內容,還會導致「缺乏信心」,返回空白的次數比應有的要多。

我們大多數的 prompt 都是以下形式:

有一段時間,我們會遇到 bug,[文本塊] 可能爲空,幻覺不時出現。順便說一句,GPT 很喜歡幻想麪包店,這裡有一些很棒的麪包店:

陽光面包店

金糧麪包店

極樂麪包店

幸運的是,解決方案是修復該 bug,並在沒有文本的情況下根本不向其發送 prompt。

經驗 5:「上下文窗口」命名不當

「上下文窗口」只會因輸入而變大,而不會因輸出而變大。

一個鮮爲人知的事實是,GPT-4 的輸入窗口可能有 128k token,但輸出窗口卻只有區區 4k!

我們經常要求 GPT 返回 JSON 對象的列表 —— 一個 json 任務的數組列表,其中每個任務都有一個名稱和一個標籤,而 GPT 無法返回超過 10 項。

我們最初認爲這是因爲上下文窗口大小是 4k,但我們發現 10 個項目,可能只有 700-800 個 token,GPT 就會停止。

經驗 6:向量數據庫和 RAG / 嵌入對我們普通人來說幾乎毫無用處

我認爲矢量數據庫 / RAG 確實是用於搜索的,以下是一些原因:

1. 相關性沒有界限。有一些解決方案,你可以創建自己的相關性截止啓發式,但它們並不可靠。在我看來,這確實「殺死了 RAG」—— 你總是冒着用不相關的結果危害檢索的風險;或者過於保守,錯過重要的結果。

2. 爲什麼要將向量放入專門的專有數據庫中,遠離所有其他數據?除非你處理的是 google/bing 規模的工作,否則上下文的丟失絕對不值得進行權衡。

3. 除非你正在進行非常開放的搜索(例如整個互聯網),否則用戶通常不喜歡返回他們沒有直接輸入的內容的語義搜索。

在我看來(未經驗證),對於大多數搜索案例,LLM 的更好用法是使用正常的完成 prompt 將用戶的搜索轉換爲分面搜索(faceted-search),甚至是更復雜的查詢。但這根本不是 RAG。

經驗 7:幻覺基本上不會發生

我們的每個用例本質上都是「這是一段文本,從中提取一些內容」。通常,如果要求 GPT 提供一段文本中提到的公司名稱,它不會爲你提供「隨機公司」(除非文本中沒有公司,即零假設問題)。

類似地,GPT 並不會真正產生幻覺代碼。如果用例完全、詳細,那麼 GPT 實際上非常可靠。

https://kenkantzer.com/lessons-after-a-half-billion-gpt-tokens/

本文來自微信公衆號“機器之心”(ID:almosthuman2014),36氪經授權發佈。