萬(wàn)字經(jīng)驗 | 使用大模型(LLMs)構建產(chǎn)品一年后,我們有些經(jīng)驗想告訴你

1 評論 2300 瀏覽 15 收藏 46 分鐘

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

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

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

原文:

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

01.提示工程(Prompting)

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

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

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

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

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

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

思維鏈(CoT)提示

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

當要求大語(yǔ)言模型總結會(huì )議記錄時(shí),我們可以明確步驟,例如:

首先,在草稿本上列出關(guān)鍵決策、后續事項及相關(guān)責任人。

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

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

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

提供相關(guān)資源

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

結構化你的輸入和輸出

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

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

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

使用結構化輸入時(shí),請注意每個(gè)大語(yǔ)言模型都有自己的偏好。Claude偏好xml,而GPT偏好Markdown和JSON。使用XML,你甚至可以通過(guò)提供一個(gè) response標簽來(lái)預填Claude的響應,就像這樣。

2. 編寫(xiě)短而精的提示詞,專(zhuān)注做好一件事

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

提示通常開(kāi)始很簡(jiǎn)單:幾句指令,幾個(gè)例子,就可以開(kāi)始使用了。但是當我們試圖提高性能和處理更多邊緣情況時(shí),復雜性就會(huì )悄然而至。更多指令、多步推理、幾十個(gè)例子。在我們意識到之前,最初簡(jiǎn)單的提示現在已經(jīng)變成了一個(gè)2000個(gè)token的復合體。更糟的是,它在更常見(jiàn)和直接的輸入上性能還下降了!GoDaddy 把這個(gè)作為他們在使用大語(yǔ)言模型時(shí)的首要經(jīng)驗。

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

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

因此,我們將單一的提示分解成了多個(gè)簡(jiǎn)單、專(zhuān)注且易于理解的提示。通過(guò)分解,我們可以分別迭代和評估每個(gè)提示詞的效果。

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

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

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

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

02.檢索增強生成(RAG)

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

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

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

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

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

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

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

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

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

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

— Aravind Srinivas, CEO Perplexity.ai

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

— Beyang Liu, CTO Sourcegraph

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

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

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

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

RAG和微調都可以用來(lái)將新信息納入大語(yǔ)言模型并提高特定任務(wù)上的性能。那么,我們應該首先嘗試哪個(gè)?

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

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

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

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

Gemini 1.5提供了多達1000萬(wàn)個(gè)tokens的上下文窗口,一些人開(kāi)始質(zhì)疑RAG的未來(lái)。

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

— Yao Fu

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

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

最后,是成本問(wèn)題。Transformer的推理成本與上下文長(cháng)度呈二次方(或在空間和時(shí)間上呈線(xiàn)性)增長(cháng)。僅僅因為存在一個(gè)模型在回答每個(gè)問(wèn)題之前能讀取你組織的整個(gè)Google Drive內容,并不意味著(zhù)這是個(gè)好主意??紤]到我們如何使用RAM的類(lèi)比:即使存在運行數十TB RAM的計算實(shí)例,我們還是會(huì )從磁盤(pán)進(jìn)行讀寫(xiě)。

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

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

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

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

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

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

反思問(wèn)題

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

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

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

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

將原始用戶(hù)提示轉化為智能體提示,但要注意,這個(gè)過(guò)程可能會(huì )有信息損失!

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

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

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

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

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

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

好處包括:

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

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

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

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

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

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

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

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

4. 緩存被低估了

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

緩存的一種直接方法是為被處理的項目使用唯一ID,比如我們在總結新聞文章或產(chǎn)品評論時(shí)。當一個(gè)請求進(jìn)來(lái)時(shí),我們可以檢查緩存中是否已經(jīng)存在一個(gè)摘要。如果是,我們可以立即返回它;如果不是,我們生成它,進(jìn)行安全審查,提供它,然后將它存儲在緩存中以供未來(lái)的請求使用。

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

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

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

成功的例子包括:

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

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

04.評估與監控

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

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

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

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

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

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

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

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

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

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

以下是一些建議,以充分利用LLM-as-Judge:

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

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

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

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

3. 用于評估生成的“實(shí)習生測試”

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

如果答案是否定的,因為L(cháng)LM缺乏所需的知識,考慮方法來(lái)豐富上下文。

如果答案是否定的,我們簡(jiǎn)單地無(wú)法改善上下文來(lái)解決它,那么我們可能遇到了對當代LLM來(lái)說(shuō)過(guò)于艱難的任務(wù)。

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

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

4. 過(guò)分強調某些評估可能會(huì )降低整體性能

“當一個(gè)衡量標準變成目標時(shí),它就不再是一個(gè)好的衡量標準?!?/p>

— 古德哈特法則

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

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

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

此外,過(guò)分強調NIAH評估可能會(huì )導致大模型在提取和總結任務(wù)上的性能降低。由于這些大模型被微調到關(guān)注每一句話(huà),它們可能開(kāi)始將不相關(guān)的細節和分散注意力的內容當作重要內容,因此在最終輸出中包含它們(實(shí)際上不應該包含)!

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

5. 將標注任務(wù)簡(jiǎn)化為二元判斷或者成對比較

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

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

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

如果你正在開(kāi)始編寫(xiě)標簽指南,這里有一些來(lái)自谷歌和必應搜索的指南。

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

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

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

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

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

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

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

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

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

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

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

本文由 @小布Bruce 原創(chuàng )發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可,禁止轉載

題圖來(lái)自Pixabay,基于CC0協(xié)議

該文觀(guān)點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)

更多精彩內容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 歡迎關(guān)注我的公眾號,一起交流,https://mp.weixin.qq.com/s/jz-zi3hn6XQHsnn34y5NXw

    來(lái)自北京 回復