我們公司落地大模型的路徑、方法和坑

李木子?AI大模型實驗室?2024年07月02日 18:35?北京

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

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

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

#01

戰術要點

提示詞設計

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

充分利用基本提示技巧

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

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

• 如果 n 值太低，模型可能會過度依賴這些特定示例，影響其泛化能力。通常，n 值應不小于 5，有時甚至可以達到幾十個。

• 示例應代表預期的輸入分布。例如，如果你正在構建一個電影總結器，應該包括來自不同類型的電影樣本，比例大致與實際情況相符。

• 你不一定需要提供完整的輸入 - 輸出對。在多數情況下，僅提供期望輸出的示例就足夠了。

• 如果你使用的是支持工具的 LLM，那么你的 n-shot 示例也應該包括你希望 Agent 使用的工具。

在鏈式思維（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?youplace?it?in?your?home.?This?affordable?little?hubbrings?convenient?hands-free?control?to?yoursmart?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 與環境交互的系統接口。

一些嘗試的建議：

• 明確的計劃步驟，盡可能具體。

• 將原始用戶提示重寫為 Agent 提示。小心，這個過程是有損的！

• Agent?行為如線性鏈、DAG 和狀態機；不同的依賴和邏輯關系對于不同的規模可能更或更不合適。你能否從不同的任務架構中擠出性能優化？

• 計劃驗證；你的計劃可以包括如何評估其他智能體響應的指令，以確保最終的組合工作良好。

• 具有固定上游狀態的提示工程 —— 確保你的 Agent 提示在可能發生的各種變體中進行評估。

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

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

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

• 生成的計劃可以作為少樣本示例來提示或微調 Agent。

• 確定性執行使系統更可靠，因此更容易測試和調試。此外，故障可以追溯到計劃中的具體步驟。

• 生成的計劃可以表示為有向無環圖（DAG），相對于靜態提示，它們更容易理解和適應新情況。

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

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

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

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

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

• 目錄中一些可能適合的產品可能從未被 LLM 輸出。

• 如果某些產品在訓練時非常可能跟隨提示，它們可能會在輸出中過度代表。

• 如果?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 在李克特量表上對單個輸出評分，而是給它兩個選項并讓它選擇更好的一個。這往往會有更穩定的結果。

• 控制位置偏差：選項的順序會影響 LLM 的決策。為了減輕這一點，每次成對比較時交換選項順序兩次。只是要確保在交換后將勝利歸因于正確的選項！

• 允許平局：在某些情況下，兩者可能同樣好。因此，允許 LLM 宣布平局，這樣它就不必任意選擇一個贏家。

• 使用鏈式思考：讓 LLM 在給出最終偏好之前解釋其決定，可以提高評估的可靠性。作為額外獎勵，這允許你使用較弱但速度更快的 LLM，并仍然取得類似的結果。因為管道的這部分通常是批處理模式，因此鏈式思考帶來的額外延遲不是問題。

• 控制響應長度：LLM 往往偏向更長的響應。為了減輕這一點，確保響應對的長度相似。

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 檢索的資源時，如果輸出是結構化的并識別資源是什么，你應該能夠手動驗證它們是否來自輸入上下文。

#02

運作：開發和管理 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：用戶可以選擇放大并下載圖片（強正面），變換圖片（正面）或生成新圖片集（負面）

• 聊天機器人：用戶可以對響應提供點贊（正面）或點踩（負面），如果響應真的很糟糕，可以選擇重新生成響應（強負面）

反饋可以是顯性的也可以是隱性的。顯性反饋是用戶響應我們產品請求而提供的信息；隱性反饋是我們從用戶交互中學到的信息，而無需用戶故意提供反饋。

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

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

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

• 可靠性：99.9% 的正常運行時間，符合結構化輸出

• 無害性：不生成冒犯性、NSFW 或其他有害內容

• 事實一致性：忠于提供的上下文，不編造內容

• 有用性：與用戶需求和請求相關

• 可擴展性：延遲 SLA，支持的吞吐量

• 成本：因為我們沒有無限的預算

• 以及更多：安全性、隱私、公平性、GDPR、DMA 等。

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

根據用例校準風險容忍度

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

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

團隊與角色

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

專注于流程而不是工具

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

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

不斷進行嘗試

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

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

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

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

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

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

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

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

不要陷入 “AI 工程是我需要的全部” 陷阱

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

• 數據科學家：“比任何軟件工程師更擅長統計，比任何統計學家更擅長軟件工程的人”

• 機器學習工程師（MLE）：以軟件工程為中心的機器學習觀點

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

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

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

• 首先，專注于構建產品。這可能包括 AI 工程師，但不一定。AI 工程師在快速原型設計和產品迭代（UX，管道等）方面很有價值。

• 接下來，通過對系統進行檢測和收集數據來創建正確的基礎。根據數據的類型和規模，你可能需要平臺和 / 或數據工程師。你還必須有查詢和分析這些數據以調試問題的系統。

• 接下來，你最終希望優化 AI 系統。這不一定涉及訓練模型。基本步驟包括設計指標、構建評估系統、運行實驗、優化 RAG 檢索、調試隨機系統等。MLE 在這方面非常擅長（盡管 AI 工程師也可以掌握這些技能）。除非你已經完成了前期步驟，否則通常沒有必要雇傭 MLE。

• 除此之外，你隨時都需要領域專家。在小公司中，這理想情況下是創始團隊 —— 在大公司中，產品經理可以扮演這一角色。了解角色的進展和時間安排至關重要。在錯誤的時間雇傭人員（例如，過早雇傭 MLE）或以錯誤的順序構建是浪費時間和金錢，并導致人員流動。此外，在階段 1-2 期間定期與 MLE 核對（但不要全職雇傭他們）將幫助公司構建正確的基礎。

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

#03

戰略：利用 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 應用程序。

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

• 為你的業務構建自定義文本到 SQL 功能

• 構建一個聊天機器人與你的文檔對話

• 將公司的知識庫與客戶支持聊天機器人整合在一起

雖然以上是 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 比率”，數據中心內部和硅層的深度創新和投資仍有望彌補這一不足。

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

#04

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

我們知道，制作 LLM 演示非常有趣。只需幾行代碼、一個矢量數據庫和一個精心制作的提示，我們就能創造出?奇跡?。在過去的一年里，這種魔力被比作互聯網、智能手機甚至印刷機。

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

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

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