在接下來的文章里，我們將分享一些關于大語言模型（LLM）技術核心組件的最佳實踐，包括：提升質量和可靠性的提示技巧、評估輸出的策略、改進檢索增強生成、調整和優(yōu)化工作流程等四部分。我們還將探討如何設計人類參與的工作流程。盡管這項技術仍在迅速發(fā)展，但我們希望這些經驗教訓——我們一起進行的無數實驗的成果——能夠經受時間的考驗，并幫助您構建并交付強大的LLM應用程序。

大語言模型（LLMs）的時代充滿了讓人興奮的機遇。在過去的一年里，LLMs的性能已經“足夠好”以至于可以用于現實世界的應用，預計會在2025年前帶動大約2000億美元的人工智能投資。LLMs也廣泛使得所有人，而不只是機器學習工程師和科學家，都能夠將人工智能帶入他們的產品中。雖然構建AI產品的門檻已經降低，但要創(chuàng)造出一個體驗優(yōu)秀的產品仍然是一個艱巨的挑戰(zhàn)。

在過去一年中，Eugene Yan、Bryan Bischof 、Charles Frye 等一直在LLMs之上構建他們的應用程序。他們寫這篇文章的目標是，以自己的經驗為基礎，創(chuàng)建一個關于圍繞LLMs構建成功產品的實用指南，并列出實際成功的例子，分享一些建議和教訓，供任何構建LLMs產品的人參考。

原文：

https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-i/

01.提示工程（Prompting）

我們建議在開發(fā)新應用時從提示工程（Prompting）開始。人們很容易低估或者低估它的重要性。正確的提示技巧，若使用得當的情況下，可以讓我們取得很大的進展，所以它往往被低估；但是，即使是基于提示的應用程序也需要圍繞提示進行大量工程開發(fā)才能很好地工作，因此其重要性也容易被高估。

1. 重視從基本的提示技巧中獲得最大收益

有幾種提示技巧在不同模型和任務中都能有助于提升性能：

n-shot 提示與上下文學習

利用n-shot 提示進行上下文中學習的思路是提供給LLM一些示例，這些示例展示了任務要求，并使輸出符合我們的期望。一些建議：

• 如果 n 過低，模型可能會過度依賴這些特定示例，影響其泛化能力。一般來說，n 應該不小于 5，甚至可以達到幾十個。
• 示例應能代表預期輸入的分布。如果您正在構建一個電影摘要生成器，請包含不同類型的樣本，比例大致與實際情況相符。
• 不一定要提供完整的輸入輸出對。在很多情況下，僅提供期望輸出的示例就足夠了。
• 如果您使用支持工具的大語言模型，您的 n-shot 示例也應包括您希望智能體使用的工具。

思維鏈（CoT）提示

在思維鏈（CoT）提示中，我們鼓勵LLM在返回最終答案之前解釋其思考過程?？梢詫⑵湟暈闉長LM提供一個草稿本，這樣它就不必全部在記憶中完成。最初的方法是簡單地在指示中添加“l(fā)ets think step by step（讓我們一步一步思考）”這句話。然而，我們發(fā)現使鏈式思維更具體，通過添加一兩句額外的說明，可以顯著降低幻覺率。

當要求大語言模型總結會議記錄時，我們可以明確步驟，例如：

首先，在草稿本上列出關鍵決策、后續(xù)事項及相關責任人。

然后，檢查草稿本中的細節(jié)與會議記錄事實上是否一致。

最后，將關鍵點綜合成一份簡潔的摘要。

最近，人們開始懷疑這種技術是否像人們認為的那樣強大。此外，關于在使用思維鏈時推理過程中究竟發(fā)生了什么，存在相當大的爭議。無論如何，嘗試這種技術是值得的。

提供相關資源

提供相關資源是一種擴展模型知識庫、減少幻覺并增加用戶信任的強有力機制。通常通過檢索增強生成（RAG）實現，為模型提供它可以直接在回應中使用的文本片段是一種基本技巧。提供相關資源時，僅僅包括這些資源是不夠的；別忘了告訴模型優(yōu)先使用這些資源，直接提及它們，有時還要提及當資源不足時的情況。這些有助于讓智能體的響應基于一組資源。

結構化你的輸入和輸出

結構化輸入和輸出可以幫助模型更好地理解輸入，并返回能夠可靠集成到下游系統中的輸出。為您的輸入添加序列化格式可以為模型提供更多關于上下文中tokens之間關系的線索，為特定tokens提供額外的元數據（如類型），或將請求與模型訓練數據中的類似示例聯系起來。

例如，互聯網上許多關于編寫SQL的問題都是通過指定SQL模式開始的。因此，你可能期望有效的Text-to-SQL提示應包括結構化的模式定義。

結構化輸出具有類似的目的，但它也簡化了與系統下游組件的集成。Instructor和Outlines適合用于結構化輸出。（如果你正在導入LLM API SDK，使用Instructor；如果您正在導入 Huggingface 進行自托管模型，請使用Outlines）。結構化輸入清晰地表達任務，并且類似于訓練數據的格式，增加了獲得更好輸出的可能性。

使用結構化輸入時，請注意每個大語言模型都有自己的偏好。Claude偏好xml，而GPT偏好Markdown和JSON。使用XML，你甚至可以通過提供一個 response標簽來預填Claude的響應，就像這樣。

2. 編寫短而精的提示詞，專注做好一件事

在軟件開發(fā)中，有一個常見的反模式叫“萬能對象”，即一個類或函數承擔了所有的功能。提示詞也有類似的問題。

提示通常開始很簡單：幾句指令，幾個例子，就可以開始使用了。但是當我們試圖提高性能和處理更多邊緣情況時，復雜性就會悄然而至。更多指令、多步推理、幾十個例子。在我們意識到之前，最初簡單的提示現在已經變成了一個2000個token的復合體。更糟的是，它在更常見和直接的輸入上性能還下降了！GoDaddy 把這個作為他們在使用大語言模型時的首要經驗。

就像我們努力保持系統和代碼的簡約一樣，我們的提示也應該如此。我們不應該擁有一個用于會議記錄的全能型提示，我們可以將其分解為步驟：

1. 將關鍵決策、行動項目和責任人提取成結構化格式
2. 檢查提取的詳情與原始記錄的一致性
3. 從結構化的細節(jié)生成簡潔的摘要

因此，我們將單一的提示分解成了多個簡單、專注且易于理解的提示。通過分解，我們可以分別迭代和評估每個提示詞的效果。

3. 精心設計你的上下文信息

重新思考你的需求，然后反思實際需要向agent發(fā)送多少上下文。像米開朗琪羅那樣，不是不斷堆砌石料——而是剔除多余的材料，直到雕塑顯現出來。檢索增強生成（RAG）是一個流行的方法，用來匯集所有可能相關的信息塊，但是你如何提取必要的內容呢？

我們發(fā)現，將最終發(fā)送給模型的提示詞——包括所有的上下文構建、元提示詞和 RAG 結果——放在一張空白頁上閱讀，確實有助于重新思考上下文。通過這種方法，我們發(fā)現了冗余、自相矛盾的語言和糟糕的格式。

另一個關鍵的優(yōu)化是你的上下文結構。如果你的文檔袋（bag-of-docs）表示法對人類不友好，不要假設它對agent有用。仔細考慮你如何構建上下文，強調其各部分之間的關系，并盡可能簡化提取過程。

02.檢索增強生成（RAG）

除了提示工程之外，還有一種有效的方法是在提示中提供知識。這種方法將使LLMs錨定在提供的上下文上，用于上下文學習，這被稱為檢索增強生成（RAG）。實踐中發(fā)現，RAG在提供知識和改善輸出方面有效，而且與微調相比需要的努力和成本更少。RAG的好壞取決于檢索文檔的相關性、信息密度和詳細程度。

1. RAG輸出質量取決于檢索文檔的質量，而文檔的質量又可以從幾個因素考慮

第一個也是最明顯的衡量指標是文檔的相關性。相關性通常通過排名指標進行量化，例如平均倒數排名（MRR）或歸一化折扣累計增益（NDCG）。MRR評估系統在排名列表中將首個相關結果置于何處的能力，而NDCG則考慮所有結果的相關性及其位置。這些指標衡量系統將相關文檔排在更高位置、不相關文檔排在更低位置的。例如，如果我們檢索用戶評論來生成電影評論摘要，我們希望將特定電影的評論排名更高，同時排除與其他電影有關的評論。

與傳統推薦系統類似，檢索到的項目排名將對 LLM 在下游任務中的表現產生重大影響。為了衡量這種影響，可以運行一個基于 RAG 的任務，但將檢索到的項目順序打亂，然后觀察 RAG 輸出的表現如何。

其次，我們還想考慮信息密度。如果兩份文檔同樣相關，我們應該更偏好那些更簡潔且不必要細節(jié)較少的文檔。回到我們的電影示例，從廣義上講，我們可能會認為電影劇本和所有用戶評論都相關。然而，高評價的評論和編輯評論可能在信息上更為密集。

最后，考慮文檔提供的細節(jié)水平。想象我們正在構建一個 RAG 系統，從自然語言生成 SQL 查詢。我們可以簡單地提供表結構和列名作為上下文，但如果包括列描述和一些代表性值，額外的細節(jié)將幫助 LLM 更好地理解表的語義，從而生成更正確的 SQL。

2. 不要忘記關鍵詞搜索：將其用于基準和混合搜索

鑒于基于嵌入（Embedding）的RAG如此普遍，很容易讓人忘記或忽視信息檢索領域幾十年的研究和解決方案。

盡管嵌入式搜索無疑是一個強大的工具，但它們并非萬能。首先，雖然它們擅長捕捉高層次的語義相似性，但它們可能在處理更具體的基于關鍵詞的查詢時遇到困難，就像用戶搜索名稱（例如，Ilya）、縮寫（例如，RAG）或ID（例如，claude-3-sonnet）時?；陉P鍵詞的搜索，如BM25，專門為此設計。而且，經過多年的基于關鍵詞的搜索，用戶很可能已經將其視為理所當然，并且如果他們希望檢索的文檔沒有被返回，可能會感到沮喪。

向量嵌入并不是搜索的萬能解決方案。事實上，在使用語義相似搜索進行重新排序之前的步驟才是最關鍵和費力的。要真正實現比 BM25 或全文搜索更好的效果是非常困難的。

— Aravind Srinivas, CEO Perplexity.ai

幾個月來我們一直向客戶和合作伙伴反復強調：使用簡單的嵌入進行相似檢索會產生非常雜亂的結果，還不如從關鍵詞搜索開始。

— Beyang Liu, CTO Sourcegraph

其次，使用關鍵詞搜索檢索到文檔的原因更直觀——我們可以查看與查詢匹配的關鍵詞。相比之下，基于嵌入的檢索解釋性較差。最后，得益于像Lucene和OpenSearch這樣經過數十年優(yōu)化和實戰(zhàn)檢驗的系統，關鍵詞搜索通常在計算上更高效。

在大多數情況下，混合使用效果最佳：對于明顯的匹配使用關鍵詞匹配，對于同義詞、上位詞、拼寫錯誤以及多模態(tài)（例如，圖片和文本）使用嵌入。Shortwave分享了他們如何構建他們的RAG流水線，包括查詢重寫、關鍵詞+嵌入檢索和排名。

在大多數情況下，混合搜索是最有效的：關鍵詞匹配用于明顯的匹配，而嵌入用于同義詞、上位詞和拼寫錯誤，以及多模態(tài)（如圖像和文本）。Shortwave 分享了他們如何構建 RAG 管道，包括查詢重寫、關鍵詞 + 嵌入檢索和排序。

3. 對于新知識首選RAG，而不是微調

RAG和微調都可以用來將新信息納入大語言模型并提高特定任務上的性能。那么，我們應該首先嘗試哪個？

最近的研究表明RAG可能更具優(yōu)勢。一項研究將RAG與無監(jiān)督微調（又稱持續(xù)預訓練）進行了比較，評估了它們在MMLU的一個子集和當前事件上的表現。他們發(fā)現RAG在訓練過程中遇到的知識以及完全新的知識方面，持續(xù)地優(yōu)于微調。在另一篇論文中，他們將RAG與在農業(yè)數據集上的監(jiān)督微調進行了比較。同樣，RAG帶來的性能提升大于微調，尤其是對GPT-4（參見該論文的表20）。

除了性能提升，RAG還帶來了幾個實際優(yōu)勢。首先，與持續(xù)預訓練或微調相比，保持檢索索引更新更容易——也更便宜！其次，如果我們的檢索索引含有包含有害或有偏見內容的問題文檔，我們可以輕松地刪除或修改這些問題文檔。

此外，RAG中的R提供了更細致的控制，以便我們檢索文檔。例如，如果我們?yōu)槎鄠€組織托管RAG系統，通過劃分檢索索引，我們可以確保每個組織只能從它們自己的索引中檢索文檔。這確保我們不會無意中將一個組織的信息暴露給另一個組織。

4. 長上下文窗口不會讓RAG失去作用

Gemini 1.5提供了多達1000萬個tokens的上下文窗口，一些人開始質疑RAG的未來。

我認為 Sora 對 Gemini 1.5 的宣傳大大夸大了。一個 1000 萬 tokens 的上下文窗口實際上使大多數現有的 RAG 框架變得不必要——你只需將你的數據放入上下文中，像往常一樣與模型對話。想象一下，這對那些大部分工程努力都集中在 RAG 上的初創(chuàng)公司/智能體/LangChain 項目會產生怎樣的影響 ?? 簡單一句話：這個 1000 萬的上下文殺死了 RAG。干得好，Gemini。

— Yao Fu

雖然長上下文將會對用例如分析多份文件等應用中是一個變革，但關于RAG即將過時的傳言被大大夸張了。

首先，即使有一個1000萬tokens的上下文窗口，我們仍然需要一種方法來選擇信息來喂給模型。其次，除了狹義的“大海撈針”評估之外，我們還沒看到有力的數據證明模型能有效地推理如此大的上下文。因此，如果沒有好的檢索和排序，我們有可能用干擾信息使模型不堪重負，或者甚至可能用完全不相關的信息填滿上下文窗口。

最后，是成本問題。Transformer的推理成本與上下文長度呈二次方（或在空間和時間上呈線性）增長。僅僅因為存在一個模型在回答每個問題之前能讀取你組織的整個Google Drive內容，并不意味著這是個好主意?？紤]到我們如何使用RAM的類比：即使存在運行數十TB RAM的計算實例，我們還是會從磁盤進行讀寫。

所以，不要急著把你的RAG扔掉。即使上下文窗口的大小增長，這種模式仍然會很有用。

03.調整和優(yōu)化工作流程

提示工程只是開始。為了最大限度地利用它們，我們需要思考超越單個提示的范圍，并擁抱工作流程。例如，我們如何將一個單一復雜任務分解為多個更簡單的任務？微調或緩存在提高性能和減少延遲/成本時何時有幫助？在本節(jié)中，我們將分享經過驗證的策略和現實世界的例子，以幫助您優(yōu)化和構建可靠的大語言模型工作流程。

1. 逐步、多回合的流程可以提升效果

我們已經知道，將一大段提示詞分解為若干個小段提示詞可以取得更好的效果。一個例子是 AlphaCodium：他們從單個提示切換到多步驟工作流程，將GPT-4在CodeContests上的準確率（pass@5）從19％提高到44％。

這個工作流包括：

反思問題

1. 在公共測試中進行推理
2. 生成可能的解決方案
3. 對可能的解決方案進行排序
4. 生成模擬測試
5. 在公共和模擬測試中迭代解決方案

具有明確目標的小任務非常適合作為agent或流程提示。雖然不是每個智能體提示都需要結構化輸出，但結構化輸出有助于與協調智能體與環(huán)境互動的系統進行接口對接。

下面是一些值得嘗試的事情

制定盡可能詳細的計劃步驟。可以考慮從預定義的計劃中進行選擇 (參考 https://youtu.be/hGXhFa3gzBs?si=gNEGYzux6TuB1del)

將原始用戶提示轉化為智能體提示，但要注意，這個過程可能會有信息損失！

將智能體行為設計成線性鏈、DAG 和狀態(tài)機的形式；不同的依賴關系和邏輯關系適用于不同的任務規(guī)模。能否通過不同的任務架構來優(yōu)化性能？

計劃驗證；在你的計劃中包含如何評估其他智能體響應的指導，以確保最終組合效果良好。

通過固定的上游狀態(tài)進行提示工程——確保你的智能體提示能夠應對可能發(fā)生的各種情況。

2. 優(yōu)先考慮確定性工作流

雖然AI agent可以動態(tài)地響應用戶請求和環(huán)境，但它們的非確定性特征使得部署它們成為一大挑戰(zhàn)。agent采取的每一步都有失敗的可能性，而且從錯誤中恢復的可能性很小。因此，隨著步驟數量的增加，agent成功完成多步驟任務的可能性呈指數級下降。結果是，構建agent的團隊發(fā)現很難部署可靠的agent。

一種有效的方法是擁有能產生確定性計劃的agent系統，然后以結構化、可復制的方式執(zhí)行這些計劃。在第一步，給定一個高級目標或提示，agent生成一個計劃。然后，計劃被確定性地執(zhí)行。這使每一步都更可預測和可靠。

好處包括：

1. 生成的計劃可以作為少樣本示例，用于提示或微調智能體。
2. 確定性執(zhí)行使系統更加可靠，便于測試和調試，且可以精確定位失敗步驟。
3. 生成的計劃可以表示為有向無環(huán)圖 (DAG)，比起靜態(tài)提示更容易理解和適應新情況。

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

最終，可靠、有效的agent的關鍵可能在于采用更加結構化、確定性的方法，以及收集數據來精煉提示和微調模型。如果沒有這個，雖然智能體在某些情況下表現出色，但整體表現可能會讓用戶失望，導致用戶流失

3. 調節(jié)temperature參數獲得更多樣性的輸出

假設你的需求是關注LLM輸出的多樣性。例如，你正在設計一個 LLM 流程，根據用戶之前購買的產品列表推薦新產品。當你多次運行提示時，可能會發(fā)現結果推薦過于相似，因此你可能會考慮增加 LLM 請求中的溫度參數。

簡而言之，增加溫度參數使LLM響應更加多樣化。在采樣時，下一個tokens的概率分布變得更加平坦，這意味著通常較不可能的tokens被更頻繁地選擇。盡管如此，當增加溫度時，你可能會注意到一些與輸出多樣性相關的失敗模式。例如，目錄中一些非常適合的產品可能從未被 LLM 推薦，而某些產品因為在訓練時被認為非常適合而頻繁出現。如果溫度過高，輸出可能會包含不存在的產品或一些無意義的內容。

換句話說，增加溫度并不保證LLM會從你期望的概率分布（例如，均勻隨機）中抽樣輸出。盡管如此，我們還有其他方法來增加輸出的多樣性。最簡單的方法是調整提示中的內容。例如，如果提示模板包括一個項目列表，比如歷史購買，每次將這些項目插入提示時隨機排序，可以使差異顯著。

此外，保留最近輸出的簡短列表可以幫助防止冗余。在我們推薦產品的例子中，通過指示LLM避免建議來自這個最近列表的項目，或者拒絕和重新抽樣與最近建議類似的輸出，我們可以進一步多樣化響應。另一種有效的策略是變化提示中使用的措辭。例如，加入短語如“選擇一個用戶會經常使用并喜歡的項目”或“選擇一個用戶可能會推薦給朋友的產品”可以轉移焦點，從而影響推薦產品的多樣性。

4. 緩存被低估了

緩存可以節(jié)省成本，并消除了生成延遲。此外，如果一個響應之前已經過安全審查，我們可以提供這些經過審核的響應，減少提供有害或不當內容的風險。

緩存的一種直接方法是為被處理的項目使用唯一ID，比如我們在總結新聞文章或產品評論時。當一個請求進來時，我們可以檢查緩存中是否已經存在一個摘要。如果是，我們可以立即返回它；如果不是，我們生成它，進行安全審查，提供它，然后將它存儲在緩存中以供未來的請求使用。

對于更開放式的查詢，我們可以借鑒搜索領域的技術，搜索也利用緩存來處理開放式輸入。如自動完成和拼寫糾正等功能也有助于規(guī)范用戶輸入，從而提高緩存命中率。

5. 何時需要進行微調

我們可能有一些任務，即使是設計最巧妙的提示也難以勝任。例如，即使在進行了大量的提示工程之后，我們的系統可能仍然離返回可靠、高質量輸出有一段距離。如果是這樣，那么可能需要針對您的特定任務對模型進行微調。

成功的例子包括：

1. Honeycomb 的自然語言查詢助手：最初，“編程指南”與 n-shot 樣例一起提供給提示以進行上下文理解。雖然這效果尚可，但微調模型后，在特定領域語言的語法和規(guī)則上輸出更好。
2. ReChat 的 Lucy：LLM 需要以一種非常特定的格式生成響應，該格式結合了結構化和非結構化數據，以便前端正確呈現。微調對于讓它一致運行至關重要。

盡管微調可以有效，但它伴隨著顯著的成本增加。我們不得不標注微調數據、微調和評估模型，最終自行托管它們。因此，考慮較高的前期成本是否值得。如果提示讓你走了90%的路，那么微調可能不值得投資。然而，如果我們確實決定進行微調，為了降低收集人工注釋數據的成本，我們可以生成并在合成數據上進行微調，或者利用開源數據引導。

04.評估與監(jiān)控

評估大語言模型 (LLMs) 是一個復雜的過程。LLM的輸入和輸出都是任意文本，我們給它們設置的任務也多種多樣。盡管如此，嚴密而深思熟慮的評估是至關重要的——OpenAI的技術領導在評估方面投入了大量工作并非無效。

評估 LLM 應用的方式多種多樣：有些人認為它像單元測試，有些人覺得它更類似于可觀察性，還有人認為它就是數據科學的一部分。我們發(fā)現這些觀點各有其價值。在接下來的部分中，我們將分享一些我們在構建評估和監(jiān)控管道方面的重要經驗教訓。

1. 從真實輸入/輸出樣本創(chuàng)建幾個斷言（Assertion）的單元測試

創(chuàng)建單元測試，包括來自生產的輸入和輸出樣本，基于至少三個標準對輸出設定期望。盡管三個標準可能看起來是任意的，但這是一個實際開始的數字；更少可能表明您的任務定義不夠充分或太開放，就像一個通用聊天機器人。無論是編輯提示、通過RAG添加新上下文還是其他修改，這些單元測試或斷言應該被任何對管道的改動所觸發(fā)。

這篇文章有一個基于斷言測試（斷言是在編程中用來檢驗程序的某個條件是否為真的一種語句。如果斷言的條件為真，程序可以繼續(xù)執(zhí)行；如果條件為假，則程序會拋出錯誤或異常，通常會中斷執(zhí)行。在單元測試中，斷言用來確保代碼的某個具體行為或輸出符合預期。）的實際用例示例。

可以考慮從指定包含或排除在所有響應中的短語或觀點的斷言開始。還要考慮檢查以確保單詞、項目或句子的數量在一個范圍內。對于其他類型的生成，斷言可能看起來不同。執(zhí)行評估是評估代碼生成的強大方法，在其中您運行生成的代碼并確定運行時狀態(tài)對于用戶請求來說是足夠的。

例如，如果用戶請求一個名為foo的新功能；那么在執(zhí)行agent生成的代碼之后，foo應該是可調用的！“執(zhí)行 – 評估方法”的一個挑戰(zhàn)是，agent的代碼經常會使運行時狀態(tài)與目標代碼略有不同。將斷言“放寬”到任何可行答案都會滿足的最弱假設是有效的。

最后，按照客戶預期的方式使用您的產品（即“自用”，dogfooding）可以提供關于實際數據故障模式的測試。這種方法不僅有助于識別潛在的弱點，而且還提供了一個有用的生產樣本來源，這些樣本可以轉換成評估。

2. LLM-as-Judge有用，但不是靈丹妙藥

有些人對于使用強大的LLM來評估其他LLM的輸出（LLM-as-Judge）抱有懷疑。（我們中的一些人最初也是巨大的懷疑者。）然而，當執(zhí)行得當時，LLM-as-Judge與人類判斷有相當的相關性，并且至少可以幫助構建關于新提示或技術可能如何表現的先驗。特別是，當進行成對比較（例如，對照組與處理組）時，LLM-as-Judge通常能判斷出正確的方向，盡管勝/敗的幅度可能會有噪聲。

以下是一些建議，以充分利用LLM-as-Judge：

1. 使用成對比較：不要讓大語言模型在 Likert 量表上對單個輸出進行評分，而是給它呈現兩個選項并讓它選擇較好的一個。這往往能帶來更穩(wěn)定的結果
2. 控制位置偏差：選項的呈現順序會影響大語言模型的決策。為了減少這種偏差，每次成對比較時都交換選項的順序進行兩次。只要確保在交換后將勝利歸因于正確的選項即可。
3. 允許平局：在某些情況下，兩種選項可能同樣好。因此，允許大語言模型宣告平局，以避免其不得不隨意選擇一個優(yōu)勝者。
4. 使用 Chain-of-Thought 方法：在給出最終選擇前，要求大語言模型解釋其決策過程，這可以提高評估的可靠性。一個額外的好處是，你可以使用一個較弱但更快的大語言模型，仍能達到類似的結果。因為這一部分通常是在批處理模式下進行的，Chain-of-Thought 增加的延遲并不是問題
5. 控制回復長度：大語言模型傾向于偏向較長的回復。為了減少這種偏差，確保回復的長度相似。

LLM-as-Judge 的一個特別有用的應用是檢查新的提示策略是否會出現退步。如果您已經有了一系列生產結果，有時您可以用新的提示策略重新運行這些生產示例，并使用LLM-as-Judge來快速評估新策略可能遇到的問題。

這有一個簡單但有效的方法 ，以迭代LLM-as-Judge，我們記錄大模型的回復、評判的解釋 (即 CoT) 和最終結果。然后與其他人一起檢查這些記錄，以確定改進的領域。經過三次迭代，人類與大語言模型的判斷一致性從 68% 提高到了 94%！

LLM-as-Judge并非萬能，在一些微妙的語言方面，即使是最強大的模型也無法可靠評估。此外，我們發(fā)現傳統的分類器和獎勵模型可以比LLM-as-Judge實現更高的準確性，而且成本更低，延遲更短。對于代碼生成，LLM-as-Judge可能比執(zhí)行評估等更直接的評估策略更弱。

3. 用于評估生成的“實習生測試”

在評估生成時，我們喜歡使用以下的“實習生測試”：如果你將完全相同的輸入，包括上下文，交給一個相關專業(yè)的普通大學生作為任務，他們能否成功完成？需要多長時間？

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

如果答案是否定的，我們簡單地無法改善上下文來解決它，那么我們可能遇到了對當代LLM來說過于艱難的任務。

如果答案是肯定的，但需要一段時間，我們可以嘗試減少任務的復雜性。它能分解嗎？是否有任務的某些方面可以更加模板化？

如果答案是肯定的，而且很快就能完成，那么就需要深入分析數據。模型做錯了什么？我們能找到失敗的模式嗎？可以嘗試在模型響應前后讓它解釋自己的思路，以幫助我們理解模型的工作原理

4. 過分強調某些評估可能會降低整體性能

“當一個衡量標準變成目標時，它就不再是一個好的衡量標準。”

— 古德哈特法則

這方面的一個例子是“針堆中的針 (NIAH)”評估。最初的評估是為了量化隨著上下文規(guī)模的增加，模型的召回率及其受針的位置影響的程度。然而，這一評估被過分強調，以至于在 Gemini 1.5 的報告中成為圖 1 的內容。該評估方法是在一個包含多篇 Paul Graham 文章的長文檔中插入一個特定短語 (“The special magic number is:”)，然后要求模型回憶出這個魔術數字。

雖然有些模型實現了接近完美的召回，但值得懷疑的是NIAH是否真正反映了應用中所需的推理和召回能力?？紤]一個更實際的場景：給定一個小時長會議的文字記錄，LLM能否總結關鍵決策和下一步行動，并正確將每個項目歸屬于相關人士？這一任務更加現實，不僅需要死記硬背，還需要解析復雜討論、識別關鍵信息并進行綜合總結的能力。

這是一個 實際應用中 NIAH 評估 的例子。使用 醫(yī)生與患者視頻通話的記錄，大模型被詢問關于患者藥物的信息。它還包括一個更具挑戰(zhàn)性的 NIAH 評估，插入了一個關于隨機披薩配料的短語，例如“制作完美披薩所需的秘密配料是：濃咖啡浸泡的棗子、檸檬和山羊奶酪?！痹谒幬锶蝿丈系恼倩芈始s為 80%，而在披薩任務上的召回率約為 30%。

此外，過分強調NIAH評估可能會導致大模型在提取和總結任務上的性能降低。由于這些大模型被微調到關注每一句話，它們可能開始將不相關的細節(jié)和分散注意力的內容當作重要內容，因此在最終輸出中包含它們（實際上不應該包含）！

這種情況也可能適用于其他評估和使用場景。例如，在生成摘要時，過分強調事實一致性可能導致摘要內容不夠具體 (因此不太可能在事實上一致) 并且可能不夠相關。反之，過分強調寫作風格和文采可能導致語言更加華麗，但同時可能引入事實上的不一致。

5. 將標注任務簡化為二元判斷或者成對比較

開放式反饋或用 李克特量表 對模型輸出進行評分，認知負擔較大。結果，收集的數據更加嘈雜——由于人類評分員之間的變異性——因此不太有用。一種更有效的方法是簡化任務，減少標注者的認知負擔。工作良好的兩項任務是二元分類和成對比較。

在二元分類中，要求標注者對模型的輸出做出簡單的是或否的判斷。他們可能會被詢問生成的摘要是否與源文檔在事實上是一致的，或者提出的回應是否相關，或者是否包含有害內容。與Likert量表相比，二元決策更精確，評分員之間更一致，并且提高了吞吐量。Doordash就是通過一系列是或否的問題為菜單條目設置標簽隊列的方式。

在成對比較中，向標注者提供一對模型響應，并詢問哪個更好。因為對于人類來說，說“A比B好”比單獨為A或B分配一個分數更容易，這導致更快和更可靠的標注（相對于Likert量表）。在Llama2聚會上，Llama2論文的作者之一Thomas Scialom確認，與收集監(jiān)督式微調數據（如書面回應）相比，成對比較更快、更便宜。前者的成本是每單位3.5美元，而后者的成本是每單位25美元。

如果你正在開始編寫標簽指南，這里有一些來自谷歌和必應搜索的指南。

保護措施和評估可以互換使用

保護措施有助于捕捉不適當或有害的內容，而評估則有助于衡量模型輸出的質量和準確性。對于無參考評估而言，它們可以被視為一體兩面。無參考評估是指不依賴于“標準”參考（例如人類編寫的答案）的評估，能夠僅基于輸入提示和模型的響應來評估輸出的質量。

例如，摘要評估 中，我們只需考慮輸入文檔即可評估摘要在事實一致性和相關性方面的表現。如果摘要在這些指標上得分較低，我們可以選擇不向用戶展示它，有效地將評估作為保護措施。類似地，無參考的翻譯評估 可以在不需要人工翻譯參考的情況下評估翻譯質量，同樣允許我們將其作為保護措施使用。

6. 大模型即使不應該輸出也會輸出

與LLM合作的一個主要挑戰(zhàn)是，它們經常會生成輸出，即使它們不應該這樣做。這可能導致無害但毫無意義的回應，或者更嚴重的缺陷，如有害或危險內容。例如，當被要求從文檔中提取特定屬性或元數據時，LLM可能會自信地返回值，即使這些值實際上并不存在?；蛘?，模型可能會用非英語回應，因為我們在上下文中提供了非英語文檔。

雖然我們可以嘗試提示LLM返回一個“不適用”或“未知”的響應，但這并非萬無一失。即使有日志概率 (log probabilities) 可用，它們也無法準確指示輸出質量。雖然日志概率顯示了一個詞元在輸出中出現的可能性，但它們不一定反映生成文本的正確性。相反，對于那些經過指令微調 (instruction-tuned) 的模型，即訓練來響應查詢并生成連貫回答的模型，日志概率可能校準得不夠好。因此，高日志概率可能意味著輸出流暢且連貫，但不代表其準確或相關。

雖然精心設計的提示工程可以在一定程度上有所幫助，我們應該用更強有力的保護措施來補充，以檢測和過濾/重新生成不需要的輸出。例如，OpenAI提供了一個內容審核 API，可以識別不安全的響應，如仇恨言論、自傷或性輸出。同樣，有許多包用于檢測個人身份信息 (PII) 。一個好處是保護措施大體上不受用例的影響，因此可以廣泛地應用于給定語言的所有輸出。此外，通過精確檢索，如果沒有相關的文檔的話，我們的系統可以確定地回應“我不知道”。

相應地，大語言模型有時在應該生成內容時卻未能生成。這可能是由于各種原因，從 API 提供者的長尾延遲等簡單問題到內容審核過濾器阻止輸出等復雜問題。因此，持續(xù)記錄輸入和 (可能缺失的) 輸出對于調試和監(jiān)控非常重要。

7. 大模型的幻覺是個頑固的問題

不同于內容安全或個人可識別信息（PII）缺陷，事實上，不一致性問題更頑固，且更難以檢測。它們更為常見，發(fā)生率在5 – 10%之間，而且根據我們從大模型（LLM）提供商那里學到的，即便是像摘要這樣的簡單任務，將其降至2%以下也頗具挑戰(zhàn)。

為了解決這個問題，我們可以結合使用提示工程（生成前）和事實不一致性防護措施（生成后）。對于提示工程，如思維鏈（CoT）通過讓LLM在最終返回輸出之前解釋其推理過程來幫助減少幻覺。然后，我們可以應用事實不一致防護措施來評估摘要的事實性，并過濾或重新生成幻覺。在某些情況下，可以確定性地檢測到幻覺。當使用來自RAG檢索的資源時，如果輸出是結構化的并且標識了資源是什么，你應該能夠手動驗證它們來源于輸入上下文。