【CSDN 編者按】在過去的六個月中，我們公司釋出了一些大型語言模型的重要功能，我在Hacker News上讀到的關于大型語言模型的介紹與我遇到的實際情況有很大的不同，是以我想分享一些在處理了大約5億個标記後我學習到的一些經驗教訓。
原文連結：https://kenkantzer.com/lessons-after-a-half-billion-gpt-tokens/
未經允許，禁止轉載!
作者 | KEN KANTZER 責編 | 夏萌
譯者 | 彎月出品 | CSDN（ID：CSDNnews）
首先是一些背景介紹：
- 我們使用的是OpenAI模型。
- 使用比例為GPT-4：85%，GPT-3.5：15%。
- 我們專門處理了文本，是以沒有gpt-4-vision、Sora、whisper等等。
- 我們的用例是B2B，重點做摘要/分析/提取。
- 5 億 token 并沒有想象中那麼龐大，大約是75萬頁的文本。
第一課：提示越少越好
我們發現，對于某些常識，提示中無需枚舉确切的清單，不做過多的說明得到的結果更好。GPT并不愚蠢，如果過于具體，它反而會感到困惑。
這與寫代碼有着本質的差別，在代碼中一切都必須明确。
下面這個例子說明了這個問題：
我們的流水線中有一部分是讀取一些文本塊，并要求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} ... ]
以下是一段文本。一個字段應該是“locality_id”，應為50個州或聯邦政府之中的一個的ID，使用以下清單：
[{"locality: "Alabama", "locality_id": 1}, {"locality: "Alaska", "locality_id": 2} ... ]
雖然這個提示有時有效（我估計機率超過98%），但失敗的次數非常多，以至于我們不得不深入挖掘。
在調查的過程中，我們注意到另一個字段“name”始終傳回州的全名，而且是正确的州名，但我們并沒有這樣的明确要求。
是以我們改為使用name來執行簡單的字元串搜尋，如此就可以正常工作了。
我認為，總的來說，更好的方法應該是告訴GPT：“你肯定知道50個州，是以隻需給我相關的完整名稱，或者是與政府有關的聯邦名稱。”
很意外，對不對？提示越模糊，GPT的品質越好，且泛化能力就越強，這是典型的更進階别的委托和思考。
第二課：你不需要Langchain。你甚至可能不需要 OpenAI 在過去一年中釋出的其他任何東西。隻需要chat API。
Langchain 是過早抽象的完美例子。起初，我們以為我們必須使用它，因為網上就是這麼說的。然而，在使用了幾百萬個token後，生産中大約有3~4個截然不同的大型語言模型功能，而且我們的 openai_service 檔案仍然隻有一個 40 行的函數：
我們唯一使用的 API 就是 chat。我們一直在提取 json。我們不需要 JSON 模式，不需要函數調用，也不需要助手（盡管我們都有）。我們甚至不使用系統提示（也許我們應該使用……）。gpt-4-turbo 釋出時，我們隻需更新代碼庫中的一個字元串。
這是一個強大的通用模型的美妙之處：少即是多。
上面的函數大約包含40行代碼，其中大部分都是處理 OpenAI API 的正常 500 錯誤 / socket 關閉。
我們建構了一些自動截斷功能，是以無需擔心上下文長度限制。我們有自己的專有 token 長度估算器。代碼如下：
在極端情況下，比如有很多句号或數字時（在這些情況下，token 比例為每個 token 少于 3 個字元），這段代碼會失敗。是以，我們有另一個專有的嘗試 / 捕獲重試邏輯：
我們通過這種方法取得了相當大的進展，足夠靈活，可以滿足我們的需求。
第三課：使用流式 API 來改善延遲，并用不定的速度向使用者顯示正在輸出的字元實際上是 ChatGPT 的一個重大 UX 創新。
我們曾以為這隻是一個噱頭，但對于看到以不确定的速度輸出的字元（就像逐個打出來的字母），使用者的回報非常積極，感覺就像是 AI 的滑鼠/光标 UX 時刻。
第四課：GPT 非常不擅長生成空假設
我們遇到的最容易出錯的提示語言是：“如果你找不到任何内容，請傳回一個空輸出”。GPT 經常傳回一些莫名其妙的東西，還會導緻它經常缺乏信心，傳回空白的次數超過了預期。
我們大多數的提示都是下面這種形式：
“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]”
“下面是一段關于一家公司的陳述文本，我希望你輸出提取這些公司的 JSON。如果沒有相關内容，請傳回空白。文本如下：[文字内容]”。
有一段時間，我們有一個 bug，[文字内容] 可能為空。GPT 經常傳回一些莫名其妙的文字。順便說一句，GPT 很喜歡與面包店有關的詞彙，比如：
- Sunshine Bakery（陽光面包店）
- Golden Grain Bakery（金色谷物面包店）
- Bliss Bakery（幸福面包店）
幸運的是，解決方案是修複 bug，如果沒有文字，則不發送提示。但是，當很難在程式中定義“空”，而且你需要 GPT 自行斟酌時，情況就會變得很糟糕。
第五課：“上下文視窗”是一個錯誤的說法，越來越大的隻是輸入，而不是輸出
有一個鮮為人知的事實：GPT-4 有一個 128k token 的輸入視窗，但它的輸出視窗仍然隻有 4k！“上下文視窗”這個叫法很迷惑。
但實際的問題更嚴重，我們經常要求 GPT 傳回一個 JSON 對象清單。别想得太複雜：隻是一個JSON 任務清單的數組，每個任務都有一個名稱和一個标簽。
然而，GPT 傳回的資料不超過 10 個。我們試了試 15 個，結果成功率隻有 15%。
最初，我們以為這是因為上下文視窗隻有 4k，但我們檢查後發現 10 個資料隻有 700~800 個 token，但 GPT 就會停止。
當然，你也可以給它一個提示，一次隻提出一個任務，然後給它（提示 + 任務），再提出下一個任務等等。但如果你需要和GPT 玩電話遊戲，則必須處理 Langchain 之類的問題。
第六課：對于我們這些普通使用者來說，向量資料庫和 RAG/嵌入基本上毫無用處
我已經試過了，但每當我以為我有一個殺手級用例可以用于 RAG/嵌入時，我都感到困惑。
我認為，向量資料庫/RAG 實際上是為搜尋而設計的。僅限于搜尋。就像谷歌和 Bing 搜尋一樣。原因如下：
- 相關度沒有截止點。有一些解決方案，似乎可以通過啟發式為相關度建立截止點，但實際上根本不可靠。在我看來，這破壞了 RAG，你總是冒着檢索到無關結果的風險，或者太保守，你會錯過重要的結果。
- 為什麼要将向量放在一個專門的、專有的資料庫中，遠離所有其他的資料？除非你的資料量能達到谷歌或 Bing 的規模，否則這種上下文的丢失絕對不值得。
- 除非你正在進行開放式的搜尋，比如說整個網際網路，使用者通常不喜歡語義搜尋，因為會傳回使用者沒有直接輸入的内容。對于在業務應用程式中搜尋的大多數應用程式來說，使用者是領域專家，他們不需要你去猜測他們可能想要什麼，他們會明确告訴你。
在我看來（純猜測），對于大多數搜尋案例來說，大型語言模型的一個更好的用途是使用普通的完成提示将使用者的搜尋轉換為分面搜尋，甚至是更複雜的查詢（甚至是 SQL！）。但這根本不是 RAG。
第七課：基本不會出現幻覺
我們的用例基本上都是“下面是一段文本，從中提取一些内容。”一般來說，如果讓 GPT 從一段文本中提取公司名稱，它不會胡亂給你一個公司（除非文本中沒有公司，但這是上面提到的零假設問題！）。
同樣，我相信如果你是一個工程師，你也注意到了這一點：實際上 GPT 基本不會出現幻覺，它不會創造變量，或者在重寫你發送給它的代碼塊時随機引入拼寫錯誤。當你要求它給你一些内容時，它會産生一種幻覺：标準庫函數存在，但這更像是零假設。也就是說，它不知道如何表達“我不知道”。
但如果你的用例是：“上下文完整的細節如下，請分析/總結/提取”，那麼它是非常可靠的。我認為最近釋出的很多産品都強調了這個确切的用例。
是以關鍵在于，優質的資料輸入，優質的 GPT token 響應輸出。
總結
下面是一些常見問題的答複：
問：我們會實作通用人工智能嗎？
答：不會。至少不是 transformers + 網際網路資料 + 價值億萬美元的基礎設施的方法。
問：GPT-4 真的有用嗎？這一切都是營銷？
答：百分百有用。如今的 AI 就像網際網路的早期階段。
問：AI 會導緻所有人都失業嗎？
答：不會。我認為 AI 隻不過降低了普通人使用機器學習/人工智能的門檻。