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

今天小編分享的财經經驗：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 都是以下形式：

"Here ’ s a block of text that ’ s making a statement about a company, I want you to output JSON that extracts these companies. If there ’ s nothing relevant, return a blank. Here ’ s the text: [ block of text ] "  

有一段時間，我們會遇到 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 氪經授權發布。