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

大語言模型（LLMs）的時(shí)代充滿了讓人興奮的機(jī)遇。在過去的一年里，LLMs的性能已經(jīng)“足夠好”以至于可以用于現(xiàn)實(shí)世界的應(yīng)用，預(yù)計(jì)會(huì)在2025年前帶動(dòng)大約2000億美元的人工智能投資。LLMs也廣泛使得所有人，而不只是機(jī)器學(xué)習(xí)工程師和科學(xué)家，都能夠?qū)⑷斯ぶ悄軒胨麄兊漠a(chǎn)品中。雖然構(gòu)建AI產(chǎn)品的門檻已經(jīng)降低，但要?jiǎng)?chuàng)造出一個(gè)體驗(yàn)優(yōu)秀的產(chǎn)品仍然是一個(gè)艱巨的挑戰(zhàn)。

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

原文：

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

01.提示工程（Prompting）

我們建議在開發(fā)新應(yīng)用時(shí)從提示工程（Prompting）開始。人們很容易低估或者低估它的重要性。正確的提示技巧，若使用得當(dāng)?shù)那闆r下，可以讓我們?nèi)〉煤艽蟮倪M(jìn)展，所以它往往被低估；但是，即使是基于提示的應(yīng)用程序也需要圍繞提示進(jìn)行大量工程開發(fā)才能很好地工作，因此其重要性也容易被高估。

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

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

n-shot 提示與上下文學(xué)習(xí)

做交互设计10年，我为何转岗到产品经理？

真正转岗之后，我发现很多工作还是超出了自己的想象。产品经理的工作确实比较杂。理论上，产品经理的工作包括了产品的方方面面，从市场研究、用户调研、数据分析...

查看详情 >

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

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

思維鏈（CoT）提示

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

當(dāng)要求大語言模型總結(jié)會(huì)議記錄時(shí)，我們可以明確步驟，例如：

首先，在草稿本上列出關(guān)鍵決策、后續(xù)事項(xiàng)及相關(guān)責(zé)任人。

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

最后，將關(guān)鍵點(diǎn)綜合成一份簡潔的摘要。

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

提供相關(guān)資源

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

結(jié)構(gòu)化你的輸入和輸出

結(jié)構(gòu)化輸入和輸出可以幫助模型更好地理解輸入，并返回能夠可靠集成到下游系統(tǒng)中的輸出。為您的輸入添加序列化格式可以為模型提供更多關(guān)于上下文中tokens之間關(guān)系的線索，為特定tokens提供額外的元數(shù)據(jù)（如類型），或?qū)⒄?qǐng)求與模型訓(xùn)練數(shù)據(jù)中的類似示例聯(lián)系起來。

例如，互聯(lián)網(wǎng)上許多關(guān)于編寫SQL的問題都是通過指定SQL模式開始的。因此，你可能期望有效的Text-to-SQL提示應(yīng)包括結(jié)構(gòu)化的模式定義。

結(jié)構(gòu)化輸出具有類似的目的，但它也簡化了與系統(tǒng)下游組件的集成。Instructor和Outlines適合用于結(jié)構(gòu)化輸出。（如果你正在導(dǎo)入LLM API SDK，使用Instructor；如果您正在導(dǎo)入 Huggingface 進(jìn)行自托管模型，請(qǐng)使用Outlines）。結(jié)構(gòu)化輸入清晰地表達(dá)任務(wù)，并且類似于訓(xùn)練數(shù)據(jù)的格式，增加了獲得更好輸出的可能性。

使用結(jié)構(gòu)化輸入時(shí)，請(qǐng)注意每個(gè)大語言模型都有自己的偏好。Claude偏好xml，而GPT偏好Markdown和JSON。使用XML，你甚至可以通過提供一個(gè) response標(biāo)簽來預(yù)填Claude的響應(yīng)，就像這樣。

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

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

提示通常開始很簡單：幾句指令，幾個(gè)例子，就可以開始使用了。但是當(dāng)我們?cè)噲D提高性能和處理更多邊緣情況時(shí)，復(fù)雜性就會(huì)悄然而至。更多指令、多步推理、幾十個(gè)例子。在我們意識(shí)到之前，最初簡單的提示現(xiàn)在已經(jīng)變成了一個(gè)2000個(gè)token的復(fù)合體。更糟的是，它在更常見和直接的輸入上性能還下降了！GoDaddy 把這個(gè)作為他們?cè)谑褂么笳Z言模型時(shí)的首要經(jīng)驗(yàn)。

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

1. 將關(guān)鍵決策、行動(dòng)項(xiàng)目和責(zé)任人提取成結(jié)構(gòu)化格式
2. 檢查提取的詳情與原始記錄的一致性
3. 從結(jié)構(gòu)化的細(xì)節(jié)生成簡潔的摘要

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

3. 精心設(shè)計(jì)你的上下文信息

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

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

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

02.檢索增強(qiáng)生成（RAG）

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

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

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

與傳統(tǒng)推薦系統(tǒng)類似，檢索到的項(xiàng)目排名將對(duì) LLM 在下游任務(wù)中的表現(xiàn)產(chǎn)生重大影響。為了衡量這種影響，可以運(yùn)行一個(gè)基于 RAG 的任務(wù)，但將檢索到的項(xiàng)目順序打亂，然后觀察 RAG 輸出的表現(xiàn)如何。

其次，我們還想考慮信息密度。如果兩份文檔同樣相關(guān)，我們應(yīng)該更偏好那些更簡潔且不必要細(xì)節(jié)較少的文檔?；氐轿覀兊碾娪笆纠?，從廣義上講，我們可能會(huì)認(rèn)為電影劇本和所有用戶評(píng)論都相關(guān)。然而，高評(píng)價(jià)的評(píng)論和編輯評(píng)論可能在信息上更為密集。

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

2. 不要忘記關(guān)鍵詞搜索：將其用于基準(zhǔn)和混合搜索

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

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

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

— Aravind Srinivas, CEO Perplexity.ai

幾個(gè)月來我們一直向客戶和合作伙伴反復(fù)強(qiáng)調(diào)：使用簡單的嵌入進(jìn)行相似檢索會(huì)產(chǎn)生非常雜亂的結(jié)果，還不如從關(guān)鍵詞搜索開始。

— Beyang Liu, CTO Sourcegraph

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

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

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

3. 對(duì)于新知識(shí)首選RAG，而不是微調(diào)

RAG和微調(diào)都可以用來將新信息納入大語言模型并提高特定任務(wù)上的性能。那么，我們應(yīng)該首先嘗試哪個(gè)？

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

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

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

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

Gemini 1.5提供了多達(dá)1000萬個(gè)tokens的上下文窗口，一些人開始質(zhì)疑RAG的未來。

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

— Yao Fu

雖然長上下文將會(huì)對(duì)用例如分析多份文件等應(yīng)用中是一個(gè)變革，但關(guān)于RAG即將過時(shí)的傳言被大大夸張了。

首先，即使有一個(gè)1000萬tokens的上下文窗口，我們?nèi)匀恍枰环N方法來選擇信息來喂給模型。其次，除了狹義的“大海撈針”評(píng)估之外，我們還沒看到有力的數(shù)據(jù)證明模型能有效地推理如此大的上下文。因此，如果沒有好的檢索和排序，我們有可能用干擾信息使模型不堪重負(fù)，或者甚至可能用完全不相關(guān)的信息填滿上下文窗口。

最后，是成本問題。Transformer的推理成本與上下文長度呈二次方（或在空間和時(shí)間上呈線性）增長。僅僅因?yàn)榇嬖谝粋€(gè)模型在回答每個(gè)問題之前能讀取你組織的整個(gè)Google Drive內(nèi)容，并不意味著這是個(gè)好主意?？紤]到我們?nèi)绾问褂肦AM的類比：即使存在運(yùn)行數(shù)十TB RAM的計(jì)算實(shí)例，我們還是會(huì)從磁盤進(jìn)行讀寫。

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

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

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

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

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

這個(gè)工作流包括：

反思問題

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

具有明確目標(biāo)的小任務(wù)非常適合作為agent或流程提示。雖然不是每個(gè)智能體提示都需要結(jié)構(gòu)化輸出，但結(jié)構(gòu)化輸出有助于與協(xié)調(diào)智能體與環(huán)境互動(dòng)的系統(tǒng)進(jìn)行接口對(duì)接。

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

制定盡可能詳細(xì)的計(jì)劃步驟?？梢钥紤]從預(yù)定義的計(jì)劃中進(jìn)行選擇 (參考 https://youtu.be/hGXhFa3gzBs?si=gNEGYzux6TuB1del)

將原始用戶提示轉(zhuǎn)化為智能體提示，但要注意，這個(gè)過程可能會(huì)有信息損失！

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

計(jì)劃驗(yàn)證；在你的計(jì)劃中包含如何評(píng)估其他智能體響應(yīng)的指導(dǎo)，以確保最終組合效果良好。

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

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

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

一種有效的方法是擁有能產(chǎn)生確定性計(jì)劃的agent系統(tǒng)，然后以結(jié)構(gòu)化、可復(fù)制的方式執(zhí)行這些計(jì)劃。在第一步，給定一個(gè)高級(jí)目標(biāo)或提示，agent生成一個(gè)計(jì)劃。然后，計(jì)劃被確定性地執(zhí)行。這使每一步都更可預(yù)測(cè)和可靠。

好處包括：

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

最成功的agent構(gòu)建者可能是那些管理初級(jí)工程師經(jīng)驗(yàn)豐富的人，因?yàn)樯捎?jì)劃的過程類似于我們?nèi)绾沃笇?dǎo)和管理初級(jí)人員。我們給初級(jí)人員明確的目標(biāo)和具體的計(jì)劃，而不是模糊的開放式指導(dǎo)，我們也應(yīng)該對(duì)我們的agent做同樣的事情。

最終，可靠、有效的agent的關(guān)鍵可能在于采用更加結(jié)構(gòu)化、確定性的方法，以及收集數(shù)據(jù)來精煉提示和微調(diào)模型。如果沒有這個(gè)，雖然智能體在某些情況下表現(xiàn)出色，但整體表現(xiàn)可能會(huì)讓用戶失望，導(dǎo)致用戶流失

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

假設(shè)你的需求是關(guān)注LLM輸出的多樣性。例如，你正在設(shè)計(jì)一個(gè) LLM 流程，根據(jù)用戶之前購買的產(chǎn)品列表推薦新產(chǎn)品。當(dāng)你多次運(yùn)行提示時(shí)，可能會(huì)發(fā)現(xiàn)結(jié)果推薦過于相似，因此你可能會(huì)考慮增加 LLM 請(qǐng)求中的溫度參數(shù)。

簡而言之，增加溫度參數(shù)使LLM響應(yīng)更加多樣化。在采樣時(shí)，下一個(gè)tokens的概率分布變得更加平坦，這意味著通常較不可能的tokens被更頻繁地選擇。盡管如此，當(dāng)增加溫度時(shí)，你可能會(huì)注意到一些與輸出多樣性相關(guān)的失敗模式。例如，目錄中一些非常適合的產(chǎn)品可能從未被 LLM 推薦，而某些產(chǎn)品因?yàn)樵谟?xùn)練時(shí)被認(rèn)為非常適合而頻繁出現(xiàn)。如果溫度過高，輸出可能會(huì)包含不存在的產(chǎn)品或一些無意義的內(nèi)容。

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

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

4. 緩存被低估了

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

緩存的一種直接方法是為被處理的項(xiàng)目使用唯一ID，比如我們?cè)诳偨Y(jié)新聞文章或產(chǎn)品評(píng)論時(shí)。當(dāng)一個(gè)請(qǐng)求進(jìn)來時(shí)，我們可以檢查緩存中是否已經(jīng)存在一個(gè)摘要。如果是，我們可以立即返回它；如果不是，我們生成它，進(jìn)行安全審查，提供它，然后將它存儲(chǔ)在緩存中以供未來的請(qǐng)求使用。

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

5. 何時(shí)需要進(jìn)行微調(diào)

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

成功的例子包括：

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

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

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

評(píng)估大語言模型 (LLMs) 是一個(gè)復(fù)雜的過程。LLM的輸入和輸出都是任意文本，我們給它們?cè)O(shè)置的任務(wù)也多種多樣。盡管如此，嚴(yán)密而深思熟慮的評(píng)估是至關(guān)重要的——OpenAI的技術(shù)領(lǐng)導(dǎo)在評(píng)估方面投入了大量工作并非無效。

評(píng)估 LLM 應(yīng)用的方式多種多樣：有些人認(rèn)為它像單元測(cè)試，有些人覺得它更類似于可觀察性，還有人認(rèn)為它就是數(shù)據(jù)科學(xué)的一部分。我們發(fā)現(xiàn)這些觀點(diǎn)各有其價(jià)值。在接下來的部分中，我們將分享一些我們?cè)跇?gòu)建評(píng)估和監(jiān)控管道方面的重要經(jīng)驗(yàn)教訓(xùn)。

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

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

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

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

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

最后，按照客戶預(yù)期的方式使用您的產(chǎn)品（即“自用”，dogfooding）可以提供關(guān)于實(shí)際數(shù)據(jù)故障模式的測(cè)試。這種方法不僅有助于識(shí)別潛在的弱點(diǎn)，而且還提供了一個(gè)有用的生產(chǎn)樣本來源，這些樣本可以轉(zhuǎn)換成評(píng)估。

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

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

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

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

LLM-as-Judge 的一個(gè)特別有用的應(yīng)用是檢查新的提示策略是否會(huì)出現(xiàn)退步。如果您已經(jīng)有了一系列生產(chǎn)結(jié)果，有時(shí)您可以用新的提示策略重新運(yùn)行這些生產(chǎn)示例，并使用LLM-as-Judge來快速評(píng)估新策略可能遇到的問題。

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

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

3. 用于評(píng)估生成的“實(shí)習(xí)生測(cè)試”

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

如果答案是否定的，因?yàn)長LM缺乏所需的知識(shí)，考慮方法來豐富上下文。

如果答案是否定的，我們簡單地?zé)o法改善上下文來解決它，那么我們可能遇到了對(duì)當(dāng)代LLM來說過于艱難的任務(wù)。

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

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

4. 過分強(qiáng)調(diào)某些評(píng)估可能會(huì)降低整體性能

“當(dāng)一個(gè)衡量標(biāo)準(zhǔn)變成目標(biāo)時(shí)，它就不再是一個(gè)好的衡量標(biāo)準(zhǔn)?！?/p>

— 古德哈特法則

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

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

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

此外，過分強(qiáng)調(diào)NIAH評(píng)估可能會(huì)導(dǎo)致大模型在提取和總結(jié)任務(wù)上的性能降低。由于這些大模型被微調(diào)到關(guān)注每一句話，它們可能開始將不相關(guān)的細(xì)節(jié)和分散注意力的內(nèi)容當(dāng)作重要內(nèi)容，因此在最終輸出中包含它們（實(shí)際上不應(yīng)該包含）！

這種情況也可能適用于其他評(píng)估和使用場(chǎng)景。例如，在生成摘要時(shí)，過分強(qiáng)調(diào)事實(shí)一致性可能導(dǎo)致摘要內(nèi)容不夠具體 (因此不太可能在事實(shí)上一致) 并且可能不夠相關(guān)。反之，過分強(qiáng)調(diào)寫作風(fēng)格和文采可能導(dǎo)致語言更加華麗，但同時(shí)可能引入事實(shí)上的不一致。

5. 將標(biāo)注任務(wù)簡化為二元判斷或者成對(duì)比較

開放式反饋或用 李克特量表 對(duì)模型輸出進(jìn)行評(píng)分，認(rèn)知負(fù)擔(dān)較大。結(jié)果，收集的數(shù)據(jù)更加嘈雜——由于人類評(píng)分員之間的變異性——因此不太有用。一種更有效的方法是簡化任務(wù)，減少標(biāo)注者的認(rèn)知負(fù)擔(dān)。工作良好的兩項(xiàng)任務(wù)是二元分類和成對(duì)比較。

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

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

如果你正在開始編寫標(biāo)簽指南，這里有一些來自谷歌和必應(yīng)搜索的指南。

保護(hù)措施和評(píng)估可以互換使用

保護(hù)措施有助于捕捉不適當(dāng)或有害的內(nèi)容，而評(píng)估則有助于衡量模型輸出的質(zhì)量和準(zhǔn)確性。對(duì)于無參考評(píng)估而言，它們可以被視為一體兩面。無參考評(píng)估是指不依賴于“標(biāo)準(zhǔn)”參考（例如人類編寫的答案）的評(píng)估，能夠僅基于輸入提示和模型的響應(yīng)來評(píng)估輸出的質(zhì)量。

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

6. 大模型即使不應(yīng)該輸出也會(huì)輸出

與LLM合作的一個(gè)主要挑戰(zhàn)是，它們經(jīng)常會(huì)生成輸出，即使它們不應(yīng)該這樣做。這可能導(dǎo)致無害但毫無意義的回應(yīng)，或者更嚴(yán)重的缺陷，如有害或危險(xiǎn)內(nèi)容。例如，當(dāng)被要求從文檔中提取特定屬性或元數(shù)據(jù)時(shí)，LLM可能會(huì)自信地返回值，即使這些值實(shí)際上并不存在?；蛘?，模型可能會(huì)用非英語回應(yīng)，因?yàn)槲覀冊(cè)谏舷挛闹刑峁┝朔怯⒄Z文檔。

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

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

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

7. 大模型的幻覺是個(gè)頑固的問題

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

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