5億個(gè)token之后，我們得出關(guān)于GPT的七條寶貴經(jīng)驗(yàn) 精華
自 ChatGPT 問世以來，OpenAI 一直被認(rèn)為是全球生成式大模型的領(lǐng)導(dǎo)者。2023 年 3 月，OpenAI 官方宣布，開發(fā)者可以通過 API 將 ChatGPT 和 Whisper 模型集成到他們的應(yīng)用程序和產(chǎn)品中。在 GPT-4 發(fā)布的同時(shí) OpenAI 也開放了其 API。
一年過去了，OpenAI 的大模型使用體驗(yàn)究竟如何，行業(yè)內(nèi)的開發(fā)者怎么評價(jià)？
最近，初創(chuàng)公司 Truss 的 CTO Ken Kantzer 發(fā)布了一篇題為《Lessons after a half-billion GPT tokens》的博客，闡述了在使用 OpenAI 的模型（85% GPT-4、15% GPT-3.5）處理完 5 億個(gè) token 之后，總結(jié)出的七條寶貴經(jīng)驗(yàn)。
Ken Kantzer
機(jī)器之心對這篇博客進(jìn)行了不改變原意的編譯、整理，以下是博客原文內(nèi)容：
經(jīng)驗(yàn) 1：prompt，少即是多
我們發(fā)現(xiàn)，如果 prompt 中的信息已經(jīng)是常識，那么該 prompt 不會(huì)幫助模型產(chǎn)生更好的結(jié)果。GPT 并不愚蠢，如果您過度指定，它實(shí)際上會(huì)變得混亂。
這與編碼不同，編碼中的一切都必須是明確的。
舉一個(gè)讓我們感到困擾的例子：
pipeline 的一部分讀取一些文本塊，并要求 GPT 將其分類為與美國 50 個(gè)州之一相關(guān)。這不是一項(xiàng)艱巨的任務(wù)，可以使用字符串 / 正則表達(dá)式，但有足夠多奇怪的極端情況，因此需要更長的時(shí)間。所以我們的第一次嘗試大致是這樣的：
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} ... ]這有時(shí)會(huì)起作用（約超過 98% 的情況），但失敗的情況足以讓我們不得不進(jìn)行更深入的挖掘。
在調(diào)查時(shí)，我們注意到字段「名稱」始終返回州的全名，盡管我們沒有明確要求它這樣做。
因此，我們改用對名稱進(jìn)行簡單的字符串搜索來查找狀態(tài)，然后模型就一直運(yùn)行良好。
總而言之，GPT 顯然知道 50 個(gè)州。當(dāng) prompt 更加模糊時(shí)，GPT 的質(zhì)量和泛化能力都可以提高，這太瘋狂了 —— 這是高階思維的典型標(biāo)志。
經(jīng)驗(yàn) 2：不需要 langchain
你只需要 chat API，不需要 langchain，甚至可能不需要 OpenAI 去年在其 API 中發(fā)布的任何其他內(nèi)容。
Langchain 是過早抽象的完美例子。我們開始認(rèn)為我們必須使用它。但相反，數(shù)百萬個(gè) token 之后，我們可能在生產(chǎn)中使用了 3-4 個(gè)非常多樣化的 LLM 函數(shù)，而我們的 openai_service 文件中仍然只有一個(gè) 40 行的函數(shù)：
def extract_json(prompt, variable_length_input, number_retries)我們使用的唯一 API 是 chat API。我們不需要 JSON 模式、函數(shù)調(diào)用等等（盡管我們做了所有這些），我們甚至不使用系統(tǒng) prompt。gpt-4-turbo 發(fā)布時(shí)，我們更新了代碼庫中的一個(gè)字符串。
這就是強(qiáng)大的廣義模型的美妙之處 —— 少即是多。
該函數(shù)中的 40 行代碼大部分都是圍繞 OpenAI API 被關(guān)閉的 500s/socket 的錯(cuò)誤處理。
我們內(nèi)置了一些自動(dòng)截?cái)喙δ埽虼瞬槐負(fù)?dān)心上下文長度限制，我們有自己專有的 token 長度估計(jì)器。
if s.length > model_context_size * 3
# truncate it!
end在存在大量句點(diǎn)或數(shù)字的極端情況下（token ratio < 3 characters /token），這種方法會(huì)失敗。所以還有另一個(gè)專有的 try/catch 重試邏輯：
if response_error_code == "context_length_exceeded"
s.truncate(model_context_size * 3 / 1.3)我們已經(jīng)依靠上述方法取得了很大進(jìn)展，并且該方法足夠靈活，可以滿足我們的需求。
經(jīng)驗(yàn) 3：通過流式 API 改善延遲并向用戶顯示變速輸入的單詞是 ChatGPT 一項(xiàng)重大的用戶體驗(yàn)創(chuàng)新
我們曾經(jīng)認(rèn)為這只是一個(gè)噱頭，但實(shí)際上用戶對「變速輸入字符」的反應(yīng)非常積極 —— 這感覺就像是人工智能的鼠標(biāo) / 光標(biāo)用戶體驗(yàn)時(shí)刻。
經(jīng)驗(yàn) 4：GPT 不擅長產(chǎn)生零假設(shè)
「如果找不到任何內(nèi)容，則返回空輸出」—— 這可能是我們遇到的最容易出錯(cuò)的 prompting 語言。在此情況下，GPT 不僅會(huì)經(jīng)常出現(xiàn)幻覺而不返回任何內(nèi)容，還會(huì)導(dǎo)致「缺乏信心」，返回空白的次數(shù)比應(yīng)有的要多。
我們大多數(shù)的 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]”
有一段時(shí)間，我們會(huì)遇到 bug，[文本塊] 可能為空，幻覺不時(shí)出現(xiàn)。順便說一句，GPT 很喜歡幻想面包店，這里有一些很棒的面包店：
- 陽光面包店
- 金糧面包店
- 極樂面包店
幸運(yùn)的是，解決方案是修復(fù)該 bug，并在沒有文本的情況下根本不向其發(fā)送 prompt。
經(jīng)驗(yàn) 5：「上下文窗口」命名不當(dāng)
「上下文窗口」只會(huì)因輸入而變大，而不會(huì)因輸出而變大。
一個(gè)鮮為人知的事實(shí)是，GPT-4 的輸入窗口可能有 128k token，但輸出窗口卻只有區(qū)區(qū) 4k！
我們經(jīng)常要求 GPT 返回 JSON 對象的列表 —— 一個(gè) json 任務(wù)的數(shù)組列表，其中每個(gè)任務(wù)都有一個(gè)名稱和一個(gè)標(biāo)簽，而 GPT 無法返回超過 10 項(xiàng)。
我們最初認(rèn)為這是因?yàn)樯舷挛拇翱诖笮∈?4k，但我們發(fā)現(xiàn) 10 個(gè)項(xiàng)目，可能只有 700-800 個(gè) token，GPT 就會(huì)停止。
經(jīng)驗(yàn) 6：向量數(shù)據(jù)庫和 RAG / 嵌入對我們普通人來說幾乎毫無用處
我認(rèn)為矢量數(shù)據(jù)庫 / RAG 確實(shí)是用于搜索的，以下是一些原因：
1. 相關(guān)性沒有界限。有一些解決方案，你可以創(chuàng)建自己的相關(guān)性截止啟發(fā)式，但它們并不可靠。在我看來，這確實(shí)「殺死了 RAG」—— 你總是冒著用不相關(guān)的結(jié)果危害檢索的風(fēng)險(xiǎn)；或者過于保守，錯(cuò)過重要的結(jié)果。
2. 為什么要將向量放入專門的專有數(shù)據(jù)庫中，遠(yuǎn)離所有其他數(shù)據(jù)？除非你處理的是 google/bing 規(guī)模的工作，否則上下文的丟失絕對不值得進(jìn)行權(quán)衡。
3. 除非你正在進(jìn)行非常開放的搜索（例如整個(gè)互聯(lián)網(wǎng)），否則用戶通常不喜歡返回他們沒有直接輸入的內(nèi)容的語義搜索。
在我看來（未經(jīng)驗(yàn)證），對于大多數(shù)搜索案例，LLM 的更好用法是使用正常的完成 prompt 將用戶的搜索轉(zhuǎn)換為分面搜索（faceted-search），甚至是更復(fù)雜的查詢。但這根本不是 RAG。
經(jīng)驗(yàn) 7：幻覺基本上不會(huì)發(fā)生
我們的每個(gè)用例本質(zhì)上都是「這是一段文本，從中提取一些內(nèi)容」。通常，如果要求 GPT 提供一段文本中提到的公司名稱，它不會(huì)為你提供「隨機(jī)公司」（除非文本中沒有公司，即零假設(shè)問題）。
類似地，GPT 并不會(huì)真正產(chǎn)生幻覺代碼。如果用例完全、詳細(xì)，那么 GPT 實(shí)際上非?？煽?。
本文轉(zhuǎn)自 機(jī)器之心 ，作者：機(jī)器之心
