一個時代徹底結束了，投資達2000億美元，分享我們落地大模型的路徑、方法、踩坑！

最近一年，LLM（大型語言模型）已經成熟到可以投入實際套用中了。預計到 2025 年，AI 領域的投資會飆升到 2000 億美元。現在，不只是機器學習專家，任何人都能輕松地把 AI 技術融入自己的產品裏。

我們整理了一些關鍵的機器學習經驗和技巧，這些對於開發基於 LLM 的產品特別重要。掌握了這些，即使你不是機器學習專家，也能在競爭中站穩腳跟。

今天這篇文章，是我們結合自己的實踐經驗和行業案例，希望能幫你打造成功的 LLM 產品。雖然我們的經驗可能不是行業標準，但肯定能給你一些有用的建議和教訓。

戰術要點

提示詞設計

我們建議在開發新套用時從提示設計開始。它的作用既容易被低估也容易被高估。被低估是因為正確的提示技術使用得當可以帶來顯著效果。被高估是因為即使是基於提示的套用也需要大量的工程工作才能執行良好。

充分利用基本提示技巧

一些提示技術在各種模型和任務中都能提高效能：n-shot 提示與上下文學習、鏈式思維以及提供相關資源。

透過 n-shot 提示進行上下文學習的基本思路是為 LLM 提供一些範例，這些範例展示了任務要求，並引導模型輸出符合預期。以下是一些建議：

在鏈式 思維 （ CoT ）提示中，我們鼓勵 LLM 在返回最終答案之前解釋其思維過程。可以把它想象成給 LLM 一個草稿本，這樣它就不必全都記在腦海中。最初的方法是簡單地在指令中添加短語 「讓我們一步一步思考」。

但是，我們發現使 CoT 更具體很有幫助，透過添加一兩句話的具體說明，通常可以顯著降低幻覺率。例如，當要求 LLM 總結會議記錄時，我們可以明確步驟，例如：

提供相關資源是擴充套件模型知識庫、減少幻覺並增加使用者信任的強大機制。通常透過檢索增強生成（RAG）實作，為模型提供它可以在響應中直接利用的文本片段是一個基本技巧。

在提供相關資源時，光包含它們還不夠；不要忘記告訴模型優先使用這些資源，直接參照它們，有時在資源不足時提及它們。這些都有助於將 Agent 的響應 「基於」 資源庫。

結構化輸入和輸出

結構化輸入和輸出幫助模型更好地理解輸入，並返回可以可靠整合到下遊系統的輸出。 為你的輸入添加序列化格式可以提供更多線索，指示上下文中 Token 之間的關系，向特定 Token 添加附加後設資料（如型別），或將請求與模型訓練數據中的類似範例關聯。

結構化輸出也有類似的作用，但它還簡化了與系統下遊元件的整合。Instructor 和 Outlines 在結構化輸出方面表現良好。（如果你正在匯入一個 LLM API SDK，請使用 Instructor；如果你在匯入 Huggingface 用於自托管模型，請使用 Outlines。）結構化輸入清晰地表達任務，並類似於訓練數據的格式，提高了獲得更好輸出的機率。

使用結構化輸入時，請註意每個 LLM 家族都有自己的偏好。 Claude 喜歡 XML，而 GPT 更喜歡 Markdown 和 JSON。使用 XML，你甚至可以透過提供 response 標簽來預填 Claude 的響應。

messages=[
{
"role": "user",
"content": """Extract the <name>, <size>, <price>, and <color> 
from this product description into your <response>.
<description>The SmartHome Mini 
is a compact smart home assistant 
available in black or white for only $49.99. 
At just 5 inches wide, it lets you control
lights, thermostats, and other connected 
devices via voice or app—no matter where you
place it in your home. This affordable little hub
brings convenient hands-free control to your
smart devices.
</description>"""
},
{
"role": "assistant",
"content": "<response><name>"
} 
]

設計簡潔提示詞

在軟體開發中，有一種常見的反模式叫 「萬能物件」，即一個類或函式承擔所有任務。這在提示詞設計中也是同樣的道理。

提示詞通常從簡單開始：幾句指令，幾個例子，然後就可以了。但隨著我們試圖提升效能並處理更多的邊緣情況，復雜性開始增加。指令變多了，多步驟推理也出現了，例子變成了幾十個。不知不覺中，原本簡單的提示詞變成了一個包含 2000 個 Token 的龐然大物。但是，處理更常見和簡單輸入的效能反而變差了！

就像我們在保持系統和程式碼簡潔方面努力一樣，我們也應在提示詞設計中保持簡潔。與其為會議記錄總結設計一個包羅永珍的提示詞，不如將其拆分為幾個步驟：

這樣，我們就把一個復雜的提示詞拆分成了多個簡單、專註且易於理解的提示詞。透過拆分提示 詞 ，我們可以分別叠代和評估每個提示 詞 。

設計上下文 Token

重新思考並挑戰你對代理所需上下文量的傳統認知。就像米開朗基羅那樣，不是去堆砌，而是要精心雕琢，去除不必要的部份，讓作品的真正形態顯現出來。RAG 雖然是一種廣泛使用的方法，用於收集所有可能相關的資訊，但關鍵在於你如何從中提取出真正需要的部份。

我們發現，將最終提示詞放在一個空白頁面上閱讀，確實有助於重新思考上下文。透過這種方法，我們發現了冗余、自相矛盾的語言和糟糕的格式。

另一個關鍵最佳化是上下文的結構。文件堆積對人類無用，對 Agent 也一樣無用。仔細考慮如何結構化上下文，突出各部份之間的關系，並盡量簡化提取過程。

資訊檢索/RAG

除了直接提問之外，透過在提示中融入知識也是一種引導 LLM 的有效策略。這為模型提供了一個上下文基礎，使其能夠進行上下文學習，這種方法被稱作檢索增強生成（RAG）。

業界人士已經發現，RAG 在提供知識、提升輸出品質方面表現出色，而且相比於微調模型，它所需的工作量和成本要低得多。 RAG 的效果好壞，關鍵在於檢索到的文件是否具有高度的相關性、資訊密度以及詳盡的細節。

RAG 輸出的品質依賴於檢索到的文件的品質，這可以從幾個方面考慮。

第一個指標是相關性 ，通常透過排名指標如平均倒數排名（MRR）或歸一化折扣累積增益（NDCG）來量化。MRR 評估系統將第一個相關結果放在排名列表中的位置，而 NDCG 考慮所有結果的相關性及其位置。

它們衡量系統在將相關文件排名靠前和不相關文件排名靠後方面的效果。例如，如果我們檢索使用者總結以生成電影評論總結，我們會希望為特定電影的評論排名更高，同時排除其他電影的評論。

像傳統推薦系統一樣，檢索到的計畫的排名將對 LLM 在下遊任務中的表現產生重大影響。為了衡量影響，執行一個基於 RAG 的任務，但將檢索到的計畫隨機打亂 ——RAG 輸出的表現如何？

其次，我們還要考慮資訊密度。 如果兩個文件同樣相關，我們應該更喜歡更簡潔且沒有多余細節的那個。回到我們的電影例子，我們可能會認為電影劇本和所有使用者評論在廣義上都是相關的。然而，頂級評論和編輯評論可能會更密集。

最後，考慮文件提供的細節程度。 假設我們正在構建一個 RAG 系統來生成 SQL 查詢。我們可以簡單地提供表模式和列名作為上下文。但是，如果我們包括列描述和一些代表性值呢？額外的細節可以幫助 LLM 更好地理解表的語意，從而生成更正確的 SQL。

不要忘記關鍵字搜尋：把它作為基線並在混合搜尋中使用

嵌入式 RAG 演示的普遍存在使得我們容易忘記資訊檢索領域幾十年的研究和解決方案。

盡管嵌入確實是一個強大的工具，但它們並不是萬能的。

首先，雖然它們在捕捉高級語意相似性方面表現出色，但在處理更具體的基於關鍵字的查詢時（如搜尋名字、縮寫或 ID），可能會表現不佳。關鍵字搜尋（如 BM25）專為此設計。經過多年的關鍵字搜尋，使用者可能已經習慣了這一點，如果他們期望檢索到的文件沒有被返回，可能會感到沮喪。

其次，使用關鍵字搜尋時，更容易理解為什麽會檢索到某個文件 —— 我們可以檢視匹配查詢的關鍵字。相比之下，基於嵌入的檢索則不太可解釋。最後，感謝經過幾十年最佳化和實際測試的 Lucene 和 OpenSearch 系統，關鍵字搜尋通常在計算上更高效。

在大多數情況下，混合方法效果最好：關鍵字匹配用於明顯的匹配，而嵌入用於同義詞、上位詞和拼寫錯誤，以及多模態（如影像和文本）。

優先使用 RAG 而不是微調來獲取新知識

RAG 和微調都可以用來將新資訊整合到 LLM 中並提高特定任務的效能。那麽，我們應該首先嘗試哪一個？

最近的研究表明 RAG 可能更有優勢。一項研究比較了 RAG 與無監督微調（即持續預訓練），評估了它們在 MMLU 子集和當前事件中的表現。他們發現，RAG 在訓練期間遇到的知識以及全新的知識方面均優於微調。在另一篇論文中，他們比較了 RAG 與在農業數據集上的有監督微調。同樣，RAG 的效能提升比微調更大，特別是對於 GPT-4。

除了效能提升外，RAG 還具有幾個實際優勢。首先，與持續預訓練或微調相比，維護檢索索引更加容易且便宜。其次，如果我們的檢索索引中包含有害或偏見內容的問題文件，我們可以輕松刪除或修改這些有問題的文件。

此外，RAG 中的 R 提供了更細粒度的控制。例如，如果我們為多個組織托管一個 RAG 系統，透過分區檢索索引，我們可以確保每個組織只能檢索他們自己的索引中的文件。這確保了我們不會無意中將一個組織的資訊暴露給另一個組織。

長上下文模型不會讓 RAG 過時

隨著 Gemini 1.5 提供高達 10M Token 大小的上下文視窗，一些人開始質疑 RAG 的未來。

雖然長上下文對於分析多份文件或與 PDF 聊天等用例來說將是一個改變遊戲規則的因素，但關於 RAG 的消亡的傳言被大大誇大了。

首先，即使有 10M Token 的上下文視窗，我們仍然需要一種方法來選擇要傳送到模型的資訊。其次，除了狹隘的大海撈針式評估之外，我們還沒有看到令人信服的數據表明模型可以有效地處理如此大的上下文。因此，如果沒有好的檢索（和排名），我們冒著用分心的內容淹沒模型的風險，甚至可能將完全不相關的資訊填充到上下文視窗中。

最後，是成本問題。Transformer 的推理成本隨上下文長度呈二次（或線性）增長。僅僅因為存在一個模型可以在回答每個問題之前讀取你的組織的整個 Google Drive 內容，並不意味著這是一個好主意。類比一下我們如何使用 RAM：我們仍然從磁盤讀寫，即使存在具有數十 TB RAM 的計算例項。

所以不要急著扔掉你的 RAG。這種模式即使在上下文視窗擴大後仍將有用。

調整和最佳化工作流

提示 LLM 只是開始。為了最大限度地利用它們，我們需要超越單個提示並接受工作流。例如，我們如何將一個復雜的任務拆分成多個簡單的任務？什麽時候微調或緩存有助於提高效能和降低延遲 / 成本？下面，我們分享了一些經過驗證的策略和實際的例子，幫助你最佳化和構建可靠的 LLM 工作流。

逐步、多回合的 「流」 可以帶來大幅提升。

我們已經知道，透過將一個大提示分解成多個小提示，可以獲得更好的結果。AlphaCodium 就是一個例子：透過從單一提示轉變為多步驟工作流，他們將 GPT-4 在 CodeContests 上的準確率（pass@5）從 19% 提高到 44%。該工作流包括：

目標明確的小任務是最佳的 Agent 或流程提示。不要求每個 Agent 提示都請求結構化輸出，但結構化輸出有助於與協調 Agent 與環境互動的系統介面。

一些嘗試的建議：

現在優先考慮確定性工作流

雖然 AI Agent 可以動態響應使用者請求和環境，但它們的非確定性使其部署成為一個挑戰。Agent 采取的每一步都有可能失敗，恢復錯誤的機率很低。因此，Agent 成功完成多步驟任務的可能性隨著步驟數量的增加而呈指數下降。結果是， 構建 Agent 的團隊發現很難部署可靠的 Agent 。

一個有效的方法是擁有生成確定性計劃的 Agent 系統，然後以結構化、可重復的方式執行這些計劃。在第一步中，給定一個高層次的目標或提示，Agent 生成一個計劃。然後，按確定性方式執行該計劃。這使每一步都更可預測和可靠。其好處包括：

最成功的 Agent 構建者可能是那些善於管理初級工程師的人，因為生成計劃的過程類似於我們如何指導和管理初級工程師。我們給初級工程師明確的目標和具體的計劃，而不是模糊的開放式指示，我們也應該對我們的智慧體這樣做。

最後，構建可靠的、可工作的 Agent 的關鍵可能在於采用更結構化、確定性的方法，以及收集數據以最佳化提示和微調模型。否則，我們將構建一些有時可能表現出色的 Agent，但平均而言，會讓使用者失望，導致使用者留存率下降。

超越 temperature 獲得更多樣化的輸出

假設你的任務需要 LLM 的輸出具有多樣性。也許你正在編寫一個 LLM 管道，以根據使用者之前購買的產品列表推薦購買目錄中的產品。當你多次執行提示時，你可能會註意到結果推薦過於相似 —— 所以你可能會增加 LLM 請求中的 temperature 參數。

簡而言之，增加 temperature 參數使 LLM 的響應更加多樣化。在采樣時，下一個 Token 的機率分布變得更平坦，這意味著通常不太可能的 Token 更有可能被選擇。然而，增加 temperature 時，你可能會註意到一些與輸出多樣性相關的故障模式。例如：

換句話說，增加 temperature 並不保證 LLM 會從你期望的機率分布（例如，均勻隨機）中采樣輸出。然而，我們還有其他技巧可以增加輸出多樣性。最簡單的方法是調整提示中的元素。例如，如果提示樣版包含一個計畫列表，如歷史購買記錄，每次插入提示時打亂這些計畫的順序會產生顯著影響。

此外，保持一個最近輸出的短列表可以防止冗余。在我們的推薦產品例子中，透過指示 LLM 避免建議最近列表中的計畫，或拒絕和重新采樣類似於最近建議的輸出，我們可以進一步多樣化響應。另一種有效策略是改變提示中使用的措辭。例如，使用 「選擇一個使用者會經常使用的產品」 或 「選擇一個使用者可能會推薦給朋友的產品」 這樣的短語可以改變重點，從而影響推薦產品的多樣性。

緩存被低估了

緩存節省了成本，並透過消除對相同輸入重新計算響應的需求來消除生成延遲。此外，如果響應之前已經經過稽核，我們可以提供這些經過稽核的響應，減少提供有害或不適當內容的風險。

一種簡單的緩存方法是使用正在處理的計畫的唯一 ID，例如，如果我們正在總結新文章或產品評論。當請求進來時，我們可以檢查緩存中是否已經存在摘要。如果有，我們可以立即返回它；如果沒有，我們生成、稽核並提供它，然後將其儲存在緩存中以供將來請求。

對於更開放的查詢，我們可以借用搜尋領域的技術，該領域也利用緩存處理開放輸入。自動補全和拼寫校正等功能也有助於規範使用者輸入，從而提高緩存命中率。

什麽時候進行微調

我們可能有一些任務，即使經過精心設計的提示也無法完成。例如，即使經過大量提示工程，我們的系統仍可能無法返回可靠的高品質輸出。如果是這樣，那麽可能需要為你的特定任務微調模型。

盡管微調可以有效，但它成本很高。 我們必須註釋微調數據、微調和評估模型，並最終自托管它們。因此，考慮是否值得進行高額的前期投資。如果提示能讓你達到 90% 的目標，那麽微調可能不值得投資。然而，如果我們決定進行微調，為了降低收集人工註釋數據的成本，我們可以生成並微調合成數據，或基於開源數據進行啟動。

評估和監控

評估 LLM 可能是一個雷區。LLM 的輸入和輸出是任意文本，我們給它們設定的任務也是多種多樣的。然而，嚴格和深思熟慮的評估至關重要 ——OpenAI 的技術領導者從事評估工作並對各個評估提供反饋並非巧合。

評估 LLM 應用程式需要多樣的定義和簡化：這只是單元測試，或者更像是可觀測性，或者只是數據科學。我們發現所有這些觀點都很有用。在以下部份中，我們提供了一些關於構建評估和監控管道的重要經驗教訓。

從實際輸入/輸出範例中建立基於斷言的單元測試

建立單元測試（即斷言），包括生產環境中的輸入和輸出範例，並基於至少三個標準對輸出進行期望。雖然三個標準似乎是任意的，但它是一個實用的起點；更少的標準可能表明你的任務定義不夠明確或過於開放，例如一個通用聊天機器人。這些單元測試或斷言應該在任何管道更改時觸發，無論是編輯提示、透過 RAG 添加新上下文或其他修改。

考慮從指定所有響應中包含或排除的短語或想法的斷言開始。還可以考慮檢查單詞、計畫或句子數量是否在範圍內。對於其他型別的生成，斷言可能看起來不同。執行 - 評估是一種強大的程式碼生成評估方法，其中你執行生成的程式碼並確定執行時狀態是否滿足使用者請求。

最後，按客戶預期使用你的產品（即 「dogfooding」）可以提供對實際數據中失敗模式的見解。這種方法不僅有助於辨識潛在的弱點，還提供了可轉化為評估的生產樣本。

LLM-as-Judge 可以工作（有時），但它不是萬能的

LLM-as-Judge，即使用強大的 LLM 來評估其他 LLM 的輸出，一直受到一些人的質疑（我們中一些人最初也是極大的懷疑者）。盡管如此，當實施得當時，LLM-as-Judge 與人類判斷的相關性相當不錯，至少可以幫助建立對新提示或技術效能的先驗知識。特別是當進行成對比較時（例如，控制與處理），LLM-as-Judge 通常能正確判斷方向，盡管勝負的振幅可能不盡相同。

以下是一些從 LLM-as-Judge 中獲得最大收益的建議：

LLM-as-Judge 的一個特別強大的套用是檢查新的提示策略是否回歸。如果你已經跟蹤了一組生產結果，有時你可以用新的提示策略重新執行這些生產範例，並使用 LLM-as-Judge 快速評估新策略可能出現的問題。

不過， LLM-as-Judge 並不是萬能的。 語言的一些微妙方面，即使是最強的模型也難以可靠地評估。此外，我們發現傳統的分類器和獎勵模型可以比 LLM-as-Judge 達到更高的準確性，並且成本和延遲更低。對於程式碼生成，LLM-as-Judge 可能比直接的評估策略（如執行 - 評估）要弱。

「實習生測試」 用於評估生成

我們喜歡在評估生成時使用以下 「實習生測試」：如果你將語言模型的確切輸入，包括上下文，作為任務交給相關專業的普通大學生，他們能否成功？需要多長時間？

如果答案是否定的，因為 LLM 缺乏所需的知識，考慮豐富上下文的方法。

如果答案是否定的，並且我們無法透過改善上下文來解決它，那麽我們可能遇到了一個對於當前 LLM 來說太難的任務。

如果答案是肯定的，但需要一些時間，我們可以嘗試減少任務的復雜性。它是否可分解？任務的哪些方面可以樣版化？

如果答案是肯定的，他們會很快完成，那麽是時候深入研究數據了。模型做錯了什麽？我們能找到失敗模式嗎？嘗試讓模型在響應之前或之後解釋自己，幫助你建立一個心智模型。

過分強調某些評估可能會損害整體效能

一個例子是大海撈針（NIAH）評估。最初的評估幫助量化了上下文大小增延長的模型召回率，以及針的位置如何影響召回率。但是，它被過分強調了，評估涉及將一個特定短語（「特殊魔法 {city} 數位是：{number}」）插入到重復 Paul Graham 文章的長文件中，然後提示模型回憶魔法數位。

雖然一些模型實作了近乎完美的召回率，但 NIAH 是否真正反映了現實套用中所需的推理和召回能力值得懷疑。考慮一個更實際的場景：給定一個小時的會議記錄，LLM 能否總結關鍵決策和下一步，並正確歸屬每項內容給相關人員？這個任務更現實，超越了死記硬背，並且考慮了解析復雜討論、辨識相關資訊和合成摘要的能力。

另外，過分強調 NIAH 評估可能會導致提取和總結任務的效能下降。因為這些 LLM 如此微調，以至於關註每句話，它們可能會開始將無關的細節和幹擾項視為重要，從而將它們包括在最終輸出中（當它們不應該這樣做時！）

這也適用於其他評估和用例。例如，總結。一種對事實一致性的強調可能導致總結變得不那麽具體（因此不太可能出現事實不一致），可能不那麽相關。相反，對寫作風格和優雅的強調可能會導致更花哨的、市場型別的語言，這可能會引入事實不一致。

簡化註釋到二進制任務或成對比較

為模型輸出提供開放式反饋或在李克特量表上評分是認知上非常耗費精力的。結果是，收集的數據更具噪音 —— 由於人類評分者之間有差異 —— 因此不太有用。一種更有效的方法是簡化任務並減少註釋者的認知負擔。兩種有效的任務是二進制分類和成對比較。

在二進制分類中，註釋者被要求對模型的輸出做出簡單的是或否的判斷。他們可能被問及生成的摘要是否與源文件事實一致，或提議的響應是否相關，或是否包含有害內容。與李克特量表相比，二進制決策更精確，評分者之間的一致性更高，產量也更高。Doordash 就是透過一系列是非問題樹來設定選單計畫標註佇列的。

在成對比較中，註釋者會看到一對模型響應，並被要求哪個更好。因為人類更容易說 「甲比乙好」 而不是單獨給甲或乙評分，這會導致更快和更可靠的註釋（相對於李克特量表）。

（無參考）評估和護欄可以互換使用

護欄有助於捕捉不適當或有害內容，而評估有助於衡量模型輸出的品質和準確性。在無參考評估的情況下，它們可以被視為同一枚硬幣的兩面。無參考評估是不依賴於 「黃金」 參考（如人工編寫的答案）的評估，可以僅根據輸入提示和模型的響應評估輸出的品質。

一些範例是摘要評估，其中我們只需考慮輸入文件，以評估摘要的事實一致性和相關性。如果摘要在這些指標上的得分很低，我們可以選擇不向使用者展示它，有效地將評估用作護欄。同樣，無參考轉譯評估可以在不需要人工轉譯參考的情況下評估轉譯的品質，再次允許我們將其用作護欄。

LLM 會返回它們不應該返回的輸出

使用 LLM 的一個關鍵挑戰是它們經常會生成不應該生成的輸出。這可能導致無害但荒謬的響應，或更嚴重的問題，如有害或危險的內容。例如，當被要求從文件中提取特定內容或後設資料時，LLM 可能自信地返回值，即使這些值實際上並不存在。或者，模型可能會因為我們提供了非英文的文件而以非英文語言響應。

雖然我們可以嘗試提示 LLM 返回 「不可用」 或 「未知」 的響應，但這並不是萬無一失的。即使日誌機率可用，它們也是輸出品質的糟糕指標。雖然日誌機率指示 Token 出現在輸出中的可能性，但它們不一定反映生成文本的正確性。

相反，對於訓練以響應查詢和生成連貫響應的指令調整模型，日誌機率可能不太校準。因此，雖然高日誌機率可能表明輸出流暢且連貫，但這並不意味著它準確或相關。

雖然謹慎的提示工程在某種程度上有所幫助，但我們應該輔以強大的護欄來檢測和過濾/重新生成不需要的輸出。例如，OpenAI 提供了一個內容稽核 API，可以辨識仇恨言論、自殘或性內容等不安全響應。

同樣，有許多包可以檢測個人身份資訊（PII）。一個好處是，護欄在很大程度上與用例無關，因此可以廣泛套用於給定語言的所有輸出。此外，透過精確檢索，如果沒有相關文件，我們的系統可以確定性地回答 「我不知道」。

這裏的一個推論是，LLM 可能在預期輸出時未能生成輸出。這可能由於各種原因，從 API 提供商的長尾延遲等簡單問題到更復雜的問題，如輸出被內容稽核過濾器阻止。因此，重要的是始終記錄輸入和（可能缺乏的）輸出以進行偵錯和監控。

幻覺是一個頑固的問題

與內容安全或 PII 缺陷相比，幻覺（即事實不一致）是頑固且更難檢測的問題。它們更常見，基線發生率為 5-10％，從我們了解到的 LLM 提供商的情況來看，即使在簡單任務（如摘要）上，將其降低到 2％以下也很困難。

為了解決這個問題，我們可以結合提示工程（生成上遊）和事實不一致護欄（生成下遊）。對於提示工程，鏈式思考等技術透過讓 LLM 解釋其推理以減少幻覺。然後，我們可以套用事實不一致護欄評估摘要的事實性，並過濾或重新生成幻覺。

在某些情況下，幻覺可以透過確定性檢測到。當使用 RAG 檢索的資源時，如果輸出是結構化的並辨識資源是什麽，你應該能夠手動驗證它們是否來自輸入上下文。

操作 LLM 應用程式時，我們會遇到一些與操作傳統軟體系統相似的問題，但這些問題通常會帶來新的挑戰，使工作更具活力。同時，LLM 應用程式還會引發全新的問題。我們將這些問題及其答案分為四個部份：數據、模型、產品和人員。

運作：開發和管理 LLM 應用程式以及構建團隊

數據

就像食材的品質決定了菜肴的味道一樣，輸入數據的品質決定了機器學習系統的效能。此外， 輸出數據是判斷產品是否正常工作的唯一標準 。所有作者都非常重視數據，每周花費數小時來審查輸入和輸出數據，以更好地理解數據分布：它的模式、邊緣情況以及模型的局限性。

檢查開發與生產的偏差

在傳統機器學習管道中，常見的錯誤來源是訓練與服務的偏差。這種情況發生在訓練數據與模型在生產中遇到的數據不一致時。雖然我們可以在無需訓練或微調的情況下使用 LLM，因此不存在訓練集，但開發與生產數據的偏差仍然存在。

基本上，我們在開發過程中測試系統的數據應該與系統在生產中面臨的數據相似。否則，我們可能會發現生產準確性受到影響。

LLM 的開發與生產偏差可以分為兩種型別：結構性和內容性。 結構性偏差包括格式不一致的問題 ，例如 JSON 字典與列表型別值之間的差異，不一致的大小寫，以及拼寫錯誤或句子碎片等錯誤。

這些錯誤可能導致模型效能不可預測，因為不同的 LLM 訓練於特定的數據格式，提示詞對細微變化非常敏感。基於內容或 「語意」 的偏差指的是數據的意義或上下文的差異。

與傳統機器學習一樣，定期衡量 LLM 輸入/輸出對之間的偏差是有用的。簡單的指標如輸入和輸出的長度或特定的格式要求（例如 JSON 或 XML）是跟蹤變化的直接方法。對於更 「高級」 的漂移檢測，考慮對輸入/輸出對的嵌入進行聚類以檢測語意漂移，例如使用者討論話題的變化，這可能表明他們正在探索模型之前未接觸過的領域。

在測試更改（如提示詞工程）時，確保保留的數據集是最新的並反映了最近的使用者互動型別。例如，如果生產輸入中常見拼寫錯誤，它們也應該出現在保留數據中。除了數值偏差測量外，進行輸出的定性評估也很有幫助。

定期審查模型的輸出 —— 一種被稱為 「氛圍檢查」 的做法 —— 確保結果符合預期並且仍然與使用者需求相關。最後，將不確定性引入偏差檢查也是有用的 —— 透過對測試數據集中的每個輸入多次執行管道並分析所有輸出，我們增加了捕捉偶發異常的可能性。

每天檢視 LLM 的輸入和輸出樣本

LLM 是動態的，並且在不斷演變。盡管它們具有令人印象深刻的零樣本能力和經常令人愉快的輸出，但它們的失敗模式可能是高度不可預測的。對於客製任務，定期審查數據樣本對於發展對 LLM 效能的直觀理解至關重要。

來自生產的輸入 - 輸出對是 LLM 應用程式的 「真實事物、真實地方」（genchi genbutsu），它們是不可替代的。最近的研究指出，開發人員對 「好」 與 「壞」 輸出的認知會隨著他們與更多數據的互動而發生變化（即標準漂移）。

雖然開發人員可以預先提出一些評估 LLM 輸出的標準，但這些預定義標準通常是不完整的。例如，在開發過程中，我們可能會更新提示以增加良好響應的機率並減少不良響應的機率。這種評估、重新評估和標準更新的叠代過程是必要的，因為在不直接觀察輸出的情況下，很難預測 LLM 的行為或人類的偏好。

為有效管理這一過程，我們應記錄 LLM 的輸入和輸出。透過每天檢查這些日誌的樣本，我們可以快速辨識和適應新的模式或故障模式。當我們發現新的問題時，可以立即編寫斷言或評估來解決它。同樣，對故障模式定義的任何更新都應反映在評估標準中。這些 「氛圍檢查」 是壞輸出的訊號；程式碼和斷言將其操作化。最後，這種態度必須被社會化，例如透過將輸入和輸出的審查或註釋添加到你的輪值中。

使用模型

使用 LLM API 時，我們可以依賴少數供應商的智慧。這是一個好處，但這些依賴關系也帶來了效能、延遲、吞吐量和成本上的權衡。此外，隨著更好的新模型不斷出現（過去一年幾乎每月都有），我們應準備好在淘汰舊模型並遷移到新模型時更新我們的產品。在本節中，我們分享了與我們無法完全控制的技術合作的經驗，這些技術不能自行托管和管理。

生成結構化輸出以簡化下遊整合

對於大多數實際用例，LLM 的輸出將透過某種機器可讀格式被下遊應用程式消耗。例如，Rechat（一種房地產 CRM）需要結構化響應以便前端渲染小部件。同樣，Boba（一種生成產品戰略想法的工具）需要結構化輸出，包括標題、摘要、可行性評分和時間範圍等欄位。最後，LinkedIn 分享了如何將 LLM 約束生成 YAML，然後用於決定使用哪些技能以及提供呼叫技能的參數。

這種套用模式是 Postel 定律的極端版本：在接受方面要寬容（任意自然語言），在發送方面要保守（型別化的機器可讀物件）。因此，我們期望它具有極高的耐用性。

目前，Instructor 和 Outlines 是從 LLM 中引導結構化輸出的事實標準。如果你使用的是 LLM API（例如 Anthropic，OpenAI），請使用 Instructor；如果你使用的是自托管模型（例如 Hugging Face），請使用 Outlines。

跨模型遷移提示是件苦差事

有時，我們精心制作的提示在一個模型上效果極佳，但在另一個模型上卻表現不佳。這種情況可能發生在我們在不同模型供應商之間切換時，也可能發生在我們升級同一模型的不同版本時。

因此，如果我們必須跨模型遷移提示，預計這將比簡單地交換 API 端點花費更多時間。不要假設使用相同的提示會產生類似或更好的結果。此外，擁有可靠的自動化評估有助於在遷移前後測量任務效能，並減少手動驗證所需的工作量。

版本控制和固定你的模型

在任何機器學習管道中，「改變任何事情都會改變一切」。這在我們依賴的 LLM 等元件上尤為相關，這些元件我們無法自行訓練，可能在我們不知情的情況下發生變化。

幸運的是，許多模型提供商提供了 「固定」 特定模型版本的選項（例如 gpt-4-turbo-1106）。這使我們能夠使用特定版本的模型權重，確保其保持不變。在生產中固定模型版本可以避免模型行為的意外變化，這些變化可能導致客戶投訴，例如輸出過於冗長或其他不可預見的故障模式。

此外，考慮維護一個影子管道，模擬你的生產設定，但使用最新的模型版本。這使得能夠安全地進行實驗和測試新版本。一旦驗證了這些新模型輸出的穩定性和品質，可以放心地在生產環境中更新模型版本。

選擇能夠完成工作的最小模型

在開發新應用程式時，使用最大的、最強大的模型是很有誘惑力的。但一旦確定任務在技術上是可行的，就值得嘗試是否較小的模型可以實作類似的結果。

較小模型的好處是延遲和成本更低。雖然它可能較弱，但鏈式思考、n-shot 提示和上下文學習等技術可以幫助較小的模型超越其自身能力。除了 LLM API，微調特定任務也可以幫助提高效能。

總而言之，使用較小模型精心設計的工作流程往往可以匹敵甚至超越單個大型模型的輸出品質，同時速度更快且成本更低。從長遠來看，我們預計將看到更多小型模型流工程的例子，以實作輸出品質、延遲和成本的最佳平衡。

重點是，不要忽視較小的模型。雖然很容易將大型模型用於每個問題，但透過一些創造力和實驗，我們通常可以找到更有效的解決方案。

產品

雖然新技術提供了新可能性，但構建優秀產品的原則是永恒的。因此，即使我們是第一次解決新問題，也不必在產品設計上重新發明輪子。將 LLM 應用程式開發基礎紮根於堅實的產品基礎，可以讓我們為服務的人提供真正的價值。

盡早且頻繁地讓設計參與

擁有設計師將推動你理解和深思如何構建和呈現產品給使用者。我們有時將設計師刻板印象化為只負責讓事物變得漂亮的人。但不僅限於使用者介面，他們還會重新思考如何改進使用者體驗，即使這意味著打破現有規則和範式。

設計師特別擅長將使用者需求重新定義為各種形式。有些形式比其他形式更易於解決，因此，它們可能提供更多或更少的 AI 解決方案機會。與許多其他產品一樣，構建 AI 產品應以完成的工作為中心，而不是驅動它們的技術。

專註於問自己：「使用者要求這個產品為他們完成什麽工作？這個工作是聊天機器人擅長的嗎？自動完成怎麽樣？也許是其他東西！」 考慮現有的設計模式及其與待完成的工作的關系。這些都是設計師為你的團隊帶來的寶貴資產。

為人機互動設計你的使用者體驗

獲得高品質註釋的一種方法是將人機互動（HITL）整合到使用者體驗（UX）中。透過允許使用者輕松提供反饋和修正，我們可以改進即時輸出並收集有價值的數據來改進我們的模型。

想象一下一個電子商務平台，使用者上傳並分類他們的產品。有幾種方法可以設計 UX：

1. 使用者手動選擇正確的產品類別；LLM 定期檢查新產品並在後台糾正分類錯誤。

2. 使用者根本不選擇任何類別；LLM 定期在後台分類產品（可能有錯誤）。

3. LLM 即時建議產品類別，使用者可以根據需要驗證和更新。

雖然所有三種方法都涉及 LLM，但它們提供了非常不同的 UX。第一種方法將初始負擔放在使用者身上，讓 LLM 充當後處理檢查。第二種方法要求使用者零努力，但不提供透明度或控制。第三種方法找到了正確的平衡。

透過讓 LLM 預先建議類別，我們減少了使用者的認知負擔，他們不必學習我們的分類法來對其產品進行分類！同時，透過允許使用者審查和編輯建議，他們對如何分類產品有最終決定權，將控制權牢牢掌握在自己手中。作為獎勵，第三種方法為模型改進建立了一個自然的反饋迴圈。好的建議被接受（正面標簽），壞的建議被更新（負面標簽然後是正面標簽）。

這種建議、使用者驗證和數據收集的模式在多個應用程式中常見：

反饋可以是顯性的也可以是隱性的。顯性反饋是使用者響應我們產品請求而提供的資訊；隱性反饋是我們從使用者互動中學到的資訊，而無需使用者故意提供反饋。

程式碼助手和 Midjourney 是隱性反饋的例子，而點贊和點踩是顯性反饋。 如果我們設計好我們的 UX，就像程式碼助手和 Midjourney 一樣，我們可以收集大量隱性反饋來改進我們的產品和模型。

嚴格按照需求層次劃分優先順序

當我們考慮將演示投產時，我們需要考慮以下需求：

如果我們試圖一次性解決所有這些需求，我們將永遠不會釋出任何東西。因此，我們需要嚴格地優先考慮。這意味著明確什麽是不可協商的（例如，可靠性、無害性），沒有這些我們的產品無法執行或不可行。這一切都是關於辨識最小可愛的產品。我們必須接受第一個版本不會完美，然後釋出和叠代。

根據用例校準風險容忍度

在決定語言模型和應用程式的審查級別時，考慮用例和受眾。對於提供醫療或財務建議的面向客戶的聊天機器人，我們需要非常高的安全性和準確性標準。錯誤或不良輸出可能會造成實際傷害並侵蝕信任。

但對於不太關鍵的應用程式，例如推薦系統，或面向內部的應用程式如內容分類或摘要，過於嚴格的要求只會拖慢進度而不會增加太多價值。

團隊與角色

定義任何工作職能都不容易，但在這個新領域撰寫職位描述比其他領域更具挑戰性。我們將放棄交叉職位標題的維因圖或職位描述建議。我們將承認新角色 ——AI 工程師 —— 的存在並討論其位置。重要的是，我們將討論團隊的其他成員及其職責應如何分配。

專註於流程而不是工具

面對新範式，如 LLM，軟體工程師傾向於偏愛工具。因此，我們忽略了工具應解決的問題和過程。在這樣做的過程中，許多工程師承擔了意外的復雜性，這對團隊的長期生產力產生了負面影響。

除了意外的復雜性外，工具通常還不夠完善。LLM 的元件遠不止提示編寫和評估。重要的是 AI 工程師在采用工具之前要了解流程。

不斷進行嘗試

ML 產品與實驗深度交織。不僅是 A/B、隨機對照試驗型別，還包括對系統最小可能元件的頻繁修改和離線評估。每個人對評估的熱情並不是關於信任和信心 —— 而是關於使實驗成為可能！評估越好，實驗叠代速度越快，從而系統最佳版本的收斂速度越快。

嘗試不同方法解決同一問題很常見，因為實驗現在很便宜。收集數據和訓練模型的高成本最小化 —— 提示工程幾乎只需要人力時間。將你的團隊定位，使每個人都掌握提示工程的基本知識。這鼓勵每個人進行實驗，並帶來組織內的多樣化想法。

此外，不僅僅是探索實驗 —— 也利用它們來開發！有一個新任務的工作版本嗎？考慮讓團隊中的其他人用不同的方法解決它。嘗試另一種更快的方法。研究鏈式思考或少樣本提示等技術，以提高品質。不要讓工具阻礙實驗；如果是這樣，重建它或購買更好的工具。

最後，在產品/計畫規劃期間，留出時間來構建評估並進行多次實驗。將產品規範視為工程產品，但增加明確的評估標準。在路線圖制定期間，不要低估實驗所需的時間 —— 預計在獲得生產批準之前要進行多次開發和評估叠代。

讓每個人都能使用新 AI 技術

隨著生成式 AI 的套用增加，我們希望整個團隊 —— 不僅僅是專家 —— 理解並能夠使用這項新技術。沒有比實際使用它更好的方法來培養對 LLM 工作原理（如延遲、故障模式、使用者體驗）的直覺。LLM 相對容易獲取：無需編程即可提高管道效能，每個人都可以透過提示工程和評估開始貢獻。

這很大程度上取決於教育。可以從提示工程的基礎知識開始，使用 n-shot 提示和鏈式思考等技術幫助模型朝向期望的輸出。了解技術方面的人還可以學習更技術的方面，例如 LLM 是如何自回歸的。換句話說，雖然輸入 Token 是並列處理的，但輸出 Token 是順序生成的。因此，延遲更多是輸出長度的函式而不是輸入長度 —— 這是設計 UX 和設定效能期望時的關鍵考慮因素。

我們還可以進一步提供實踐實驗和探索的機會。也許是黑客馬拉松？雖然整個團隊花幾天時間進行推測性計畫黑客似乎成本高昂，但結果可能會讓你驚訝。

不要陷入 「AI 工程是我需要的全部」 陷阱

隨著新職位名稱的出現，最初往往會誇大與這些角色相關的能力。這通常會導致隨著這些工作的實際範圍變得清晰而進行的痛苦調整。新進入者以及招聘經理可能會誇大或對期望值過高。在過去十年中值得註意的例子包括：

最初，許多人認為單靠數據科學家就足以完成數據驅動的計畫。然而，事實證明，數據科學家必須與軟體和數據工程師合作，才能有效地開發和部署數據產品。

這種誤解在新角色 AI 工程師中再次出現，一些團隊認為 AI 工程師是唯一需要的角色。實際上，構建機器學習或 AI 產品需要廣泛的專業角色。我們與十幾家公司就 AI 產品進行了咨詢，始終發現他們陷入了 「AI 工程是我需要的全部」 的陷阱。因此，產品往往難以擴充套件到演示之外，因為公司忽略了構建產品涉及的重要方面。

以下是構建 AI 產品過程中所需角色型別及其所需時間的大致進展：

這樣，透過對角色的合理分配和管理，團隊可以更高效地開發和部署 LLM 應用程式，從而實作最佳的產品效果。

戰略：利用 LLM 打造產品，避免被淘汰

成功的產品需要深思熟慮的規劃和嚴格的優先級排序 ，而不是無休止的原型設計或追隨最新的模型釋出或趨勢。下面，我們將深入探討打造優秀 AI 產品的戰略考量。我們還將探討團隊將面臨的關鍵權衡，如何時構建、何時購買，並為早期 LLM 套用開發戰略提出建議。

在 PMF 之前不使用 GPU

要想成為偉大的產品，你的產品就不能僅僅是對他人應用程式介面的簡單包裝。但反其道而行之，代價可能會更高。在過去的一年中，風險投資也投入了大量資金，其中包括令人瞠目的 60 億美元 A 輪融資，都用在了培訓和客製沒有明確產品願景或目標市場的模型上。

從頭開始培訓（幾乎）毫無意義

對於大多數企業來說，從頭開始預訓練 LLM 是一種不切實際的做法。

雖然這很令人興奮，而且似乎其他人都在這麽做，但開發和維護機器學習基礎架構需要大量資源。這包括收集數據、訓練和評估模型以及部署模型。如果你還在驗證產品與市場的契合度，這些工作就會占用開發核心產品的資源。即使你擁有計算、數據和技術能力，經過預培訓的 LLM 也可能在幾個月後就會過時。

在證明有必要之前不要微調

對於大多數企業來說，微調更多是出於 「望梅止渴」，而非清晰的戰略思考。

企業過早地投資微調，試圖擺脫：只是另一種包裝 「的說法。實際上，微調是一種重型機械，只有在收集了大量例項，證明其他方法無法滿足需要時，才能部署微調。

一年前，許多團隊告訴我們，他們很想進行微調。但很少有人找到了產品與市場的契合點，大多數人對自己的決定感到後悔。如果你要進行微調，你最好真的確信，隨著基礎模型的不斷改進，你已經做好了反復進行微調的準備。

什麽情況下進行微調是正確的？如果用例所需的數據無法從用於訓練現有模型的大部份開放式網路規模數據集中獲得，而且你已經構建了一個 MVP，證明現有模型是不夠的。但要註意：如果模型構建者無法隨時獲得大量訓練數據，那麽你從哪裏獲得這些數據呢？

最後，請記住，由 LLM 驅動的套用不是一個科學展覽計畫；對它們的投資應與其對企業戰略目標和差異化競爭的貢獻相稱。

從推理 API 開始，但不要害怕自托管

有了 LLM API，初創企業就可以比以往任何時候都更容易地采用和整合語言建模功能，而無需從頭開始訓練自己的模型。Anthropic 和 OpenAI 等提供商提供通用 API，只需幾行程式碼就能將智慧融入你的產品。透過使用這些服務，你可以減少花費的精力，轉而專註於為客戶創造價值，這讓你可以驗證想法，並更快地實作產品與市場的契合。

但是，與資料庫一樣，托管服務並不適合每種使用情況，尤其是隨著規模和需求的增加。事實上，自托管可能是使用模型而不將機密 / 私人數據發送出網路的唯一方法，這在醫療保健和金融等受監管行業或合約義務或保密要求中是必需的。

此外，自托管還可以規避推理提供商施加的限制，如費率限制、模型報廢和使用限制。此外，自托管使您可以完全控制模型，從而更容易圍繞模型構建差異化的高品質系統。最後，自托管，尤其是微調，可以大規模降低成本。

叠代出偉大的產品

要想長期保持有利競爭，就必須跳出模式的束縛，考慮如何讓自己的產品與眾不同。執行速度固然重要，但它不應該是你唯一的優勢。

模型不是產品，圍繞它的系統才是

對於沒有建立模型的團隊來說，快速的創新步伐是一個福音，因為他們可以從一個 SOTA 模型遷移到下一個模型，在上下文大小、推理能力和價效比方面不斷追求進步，從而打造出越來越好的產品。

這種進步既令人興奮，又可以預見。綜上所述，這意味著模型很可能是系統中最不耐用的元件。

取而代之的是，將精力集中在能夠提供持久價值的方面，例如：

與原始模型能力相比，這些元件為產品品質提供了更堅實的護城河。

但這並不意味著在套用層構建就沒有風險。如果 OpenAI 或其他模型提供商想要提供可行的企業軟體，就不要把剪子對準他們需要剪掉的牦牛。

例如，一些團隊投資構建客製工具，以驗證專有模型的結構化輸出；在此方面進行最小程度的投資固然重要，但過深的投資並不能很好地利用時間。OpenAI 需要確保當你要求呼叫函式時，你得到的是有效的函式呼叫 -- 因為他們的所有客戶都希望如此。在此采用一些 「策略性拖延」，構建你絕對需要的功能，等待供應商對功能的明顯擴充套件。

從小事做起，建立信任

試圖為所有人提供面面俱到的產品是平庸的秘訣。要想創造出引人註目的產品，公司需要專門打造令人難忘的黏性體驗，讓使用者流連忘返。

考慮一下通用的 RAG 系統，它的目標是回答使用者可能提出的任何問題。缺乏專業化意味著該系統無法對近期資訊進行優先排序，無法解析特定領域的格式，也無法理解特定任務的細微差別。因此，使用者只能獲得膚淺、不可靠的體驗，無法滿足他們的需求。

為解決這一問題，應將重點放在特定領域和使用案例上。透過深入而非廣泛的方式縮小範圍。這將建立能與使用者產生共鳴的特定領域工具。專業化還能讓你直面系統的能力和局限性。對系統能做什麽和不能做什麽保持透明，能體現自我意識，幫助使用者了解系統在哪些方面能帶來最大價值，從而建立對產出的信任和信心。

構建 LLMOps，但要有正確的理由：更快的叠代

從根本上說，DevOps 與可復制的工作流程、左移或授權兩個披薩團隊無關，也絕對與編寫 YAML 檔無關。

DevOps 是要縮短工作與成果之間的反饋周期，從而不斷改進，而不是不斷出錯。它的根源可以追溯到精益創業運動、精益生產和豐田生產方式，後者強調 「一分鐘換模（Single Minute Exchange of Die）」 和 「改善（Kaizen）」。

MLOps 將 DevOps 的形式套用於 ML。我們有可重現的實驗，我們有一體式套件，讓模型構建者能夠進行交付。我們還有 YAML 檔。

但作為一個行業，MLOps 並沒有適應 DevOps 的功能。它沒有縮短模型與生產中的推論和互動之間的反饋差距。

令人欣慰的是，LLMOps 領域已經從思考諸如及時管理之類的小妖怪，轉向了阻礙叠代的難題：生產監控和持續改進，並透過評估進行關聯。

不要構建可以購買的 LLM 功能

大多數成功的企業都不是終身學習企業。與此同時，大多數企業都有機會透過終身學習來改進。

這兩點往往會誤導領導者匆忙地在系統中加裝 LLM，從而增加成本、降低品質，並將其作為徒有其表的 「AI」 功能釋出，同時附上令人生厭的閃光圖示。有一種更好的方法：專註於真正符合產品目標並能增強核心營運的 LLM 應用程式。

考慮一些浪費團隊時間的誤入歧途的冒險：

雖然以上是 LLM 應用程式的入門級套用，但幾乎所有產品公司都不應該自己構建這些應用程式。這些都是許多企業面臨的普遍問題，在有前景的演示和可靠的元件之間存在巨大差距，而這正是軟體公司的慣常做法。將寶貴的研發資源投入到當前 Y Combinator 批次解決的一般問題上是一種浪費。

如果這聽起來像是老生常談的商業建議，那是因為在當前的炒作浪潮中，人們很容易把任何 「LLM」 都誤認為是前沿的增量差異化技術，而忽略了哪些已經過時的套用。

AI 在迴圈中，人類在中心

目前，由 LLM 驅動的套用非常脆弱。它們需要大量的安全保護和防禦工程，而且仍然難以預測。此外，當範圍嚴格限定時，這些套用可能非常有用。這意味著 LLM 是加速使用者工作流程的絕佳工具。

雖然想象基於 LLM 的套用完全取代工作流程或替代工作職能可能很有誘惑力，但如今最有效的範例是半人馬機器人（例如半人馬西洋棋）。當有能力的人類與為快速利用而調整的 LLM 功能配對時，工作效率和完成任務的快樂程度都會大大提高。

對於那些在 ML 領域工作了很長時間的人來說，你可能會想到 「人機協同」 的概念，但沒那麽快：HITL 機器學習是一種建立在人類專家確保 ML 模型的行為符合預測的基礎上的範式。雖然相關，但我們在這裏提出的是更微妙的東西。LLM 驅動的系統不應成為當今大多數工作流程的主要驅動力；它們應該只是一種資源。

以人類為中心，詢問 LLM 如何支持他們的工作流程，這將帶來截然不同的產品和設計決策。最終，這將促使你打造出與那些試圖迅速將所有責任外包給 LLM 的競爭對手不同的產品 —— 更好、更有用、風險更低的產品。

從提示、評估和數據收集開始

前面內容提供了大量的技巧和建議。這需要吸收很多東西。讓我們考慮一下最有用的建議：如果一個團隊想要構建一個 LLM 產品，他們應該從哪裏開始？

在過去的一年中，我們已經看到了足夠多的例子，開始確信成功的 LLM 應用程式都遵循著一致的軌跡。現在，我們介紹這本基本的 「入門」 手冊。核心理念是從簡單開始，只在需要時增加復雜性。一個合理的經驗法則是，每提高一個復雜度，通常都需要比前一個復雜度多付出至少一個數量級的努力。考慮到這一點……

從提示工程開始

首先進行提示工程。使用我們在戰術部份討論過的所有技巧。思維鏈、n-shot 範例以及結構化輸入和輸出幾乎總是個好主意。在嘗試從效能較弱的模型中榨取效能之前，先用效能最高的模型做原型。

只有在提示工程設計無法達到所需的效能水平時，才應考慮微調。如果有一些非功能性要求（如數據私密、完全控制和成本）阻礙了專有模型的使用，從而要求您自行托管，那麽這種情況就會更多。只要確保同樣的私密要求不會阻止你使用使用者數據進行微調即可！

建立評估並啟動數據飛輪

即使是剛剛起步的團隊也需要評估。否則，你將不知道你的提示工程是否足夠好，也不知道你的微調模型何時可以取代原始模型。

有效的 evals 針對你的任務並反映預期用例。我們推薦的第一級 evals 是單元測試。這種簡單的測試可以發現潛在的錯誤，並幫助我們在計畫初期做出設計決策。此外，還可檢視其他針對特定任務的 evals，如分類、總結等。

雖然單元測試和基於模型的評估很有用，但它們不能取代人工評估。讓人們使用你的模型/產品並提供反饋。這樣做有兩個目的，一是測量真實世界的效能和缺陷率，二是收集高品質的註釋數據，用於微調未來的模型。這就形成了一個正反饋迴圈，或稱數據飛輪，並隨著時間的推移不斷累積：

例如，在稽核 LLM 生成的摘要是否存在缺陷時，我們可能會在每個句子上標註細粒度的反饋，以確定事實不一致、不相關或風格不佳。然後，我們可以使用這些事實不一致註釋來訓練一個幻覺分類器，或者使用相關性註釋來訓練一個獎勵模型，對相關性進行評分。

透過建立資產，使其價值隨著時間的推移不斷復合，我們將建立 evals 從純粹的營運支出升級為戰略投資，並在此過程中建立我們的數據飛輪。

低成本認知的高級趨勢

1971 年，全錄公司 PARC 的研究人員預言了未來：一個充滿網路化個人電腦的世界，正是我們今天所處的環境。他們在乙太網路、圖形渲染、滑鼠和視窗等技術的發明過程中發揮了關鍵作用，為這個未來的到來做出了貢獻。

但他們也做了一項簡單的工作：他們研究了那些非常有用（如視訊顯示）但還不經濟（即足夠的 RAM 驅動一個視訊顯示需要數千美元）的套用。然後，他們研究該技術的歷史價格趨勢（類似莫耳定律），預測這些技術何時會變得經濟實惠。

我們可以對 LLM 技術采取同樣的方法，盡管我們沒有像每美元晶體管那樣簡潔的方法。我們可以采用一個流行的、長期使用的基準，比如大規模多工語言理解數據集，以及一種一致的輸入方法（五次提示）。然後，比較不同效能水平的語言模型在該基準上的執行成本。

自 OpenAI 的 Davinci 模型作為 API 推出以來的四年裏，在一百萬 Token（約 100 份本文件）的規模上執行一個效能相當的模型的成本已從 20 美元降至不到 10 美分 —— 僅用了六個月的時間就減少了一半。

同樣，截至 2024 年 5 月，透過 API 提供商或自行執行 Meta 的 LLama 3 8B 的成本僅為每百萬 Token 20 美分，其效能與 OpenAI 的 text-davinci-003 相似，後者是讓 ChatGPT 震驚世界的模型。

該模型在 2023 年 11 月底釋出時的價格也約為每百萬 Token 20 美元。 這在短短 18 個月內就提升了兩個數量級 —— 莫耳定律預測在同一時間段內僅會翻一番。

現在，讓我們來考慮一下 LLM 的一個非常有用的套用（生成視訊遊戲角色，如 Park 等人），但目前還不經濟。自該論文於 2023 年 8 月發表以來，成本已經下降了大約一個數量級，降至每小時 62.50 美元。我們可以預計，再過九個月，成本將降至每小時 6.25 美元。

與此同時，1980 年【吃豆人】發行時，今天的 1 美元可以買到一個信用點數，可以玩幾分鐘或幾十分鐘 —— 算作每小時 6 個遊戲，即每小時 6 美元。根據這一理論計算結果，令人信服的 LLM 增強型遊戲體驗將在 2025 年的某個時候變得經濟實惠。

這些趨勢都是新趨勢，只有幾年的歷史。但我們沒有理由期待這一行程在未來幾年放緩。即使我們可能已經耗盡了演算法和數據集中的低垂果實，例如超過了每參數約 20 個 Token 的 「Chinchilla 比率」，數據中心內部和矽層的深度創新和投資仍有望彌補這一不足。

這也許是最重要的戰略事實：今天還完全不可行的地面演示或研究論文，幾年後就會成為一種高級功能，不久後就會成為一種商品。我們在構建系統和組織時應牢記這一點。

0 到 1 的演示已經夠多了，是時候推出 1 到 N 的產品了

我們知道，制作 LLM 演示非常有趣。 只需幾行程式碼、一個向量資料庫和一個精心制作的提示，我們就能創造出✨奇跡✨。 在過去的一年裏，這種魔力被比作互聯網、智慧型手機甚至印刷機。

不幸的是，參與過實際軟體交付的人都知道，在受控環境下執行的演示與大規模可靠執行的產品之間存在天壤之別。

以自動駕駛汽車為例。1988 年，第一輛汽車由神經網路驅動。25 年後，Andrej Karpathy 第一次試駕了 Waymo。十年後，該公司獲得了無人駕駛授權證。從原型車到商業產品，經過了三十五年的嚴格工程設計、測試、改進和監管導航。

在工業界和學術界的不同領域，我們敏銳地觀察到了過去一年是 LLM 從 1 到 N 的第一年。我們希望我們學到的經驗 —— 從建立團隊的嚴格操作技術等戰術到內部建設哪些能力等戰略視角 —— 能在第二年及以後幫助你們，讓我們共同探索這項令人興奮的新技術。

·END·

最後給大家介紹一個AI知識社群，已經突破4w人，如果你想學習AI，了解一手最前沿的AI資訊和AI搞錢計畫，千萬不要錯過了，涵蓋AI編程，大模型開發套用，AI智慧體套用等程式設計師群體非常火熱的方向。

趁現在，破圈從付第一筆你想都不敢想的費用開始，機會也就在這一瞬，試一試的成本很低，但錯過的成本非常大！