六位一線 AI 工程師和創(chuàng)業(yè)者,把在大模型應(yīng)用開發(fā)上摸爬滾打一整年的心得,全!分!享!了!
(奇怪的六一兒童節(jié)大禮包出現(xiàn)了)
這篇干貨長文,一時間成為開發(fā)者社區(qū)熱議的話題。
有網(wǎng)友評價為,大模型領(lǐng)域少有的“有操作性”的實用見解,非常值得一讀。
這 6 位作者來自不同背景,比如有大廠工程師,也有獨立開發(fā)者,還有咨詢顧問。
但他們的共同之處,是過去一年里一直在大模型之上構(gòu)建真實應(yīng)用程序,而不只是炫酷的 Demo 演示,他們認(rèn)為:
現(xiàn)在正是非機器學(xué)習(xí)工程師或科學(xué)家,也能把 AI 構(gòu)建到產(chǎn)品中的時候。
在他們的一系列分享中,網(wǎng)友熱議的亮點包括但不限于:
-何時用長上下文、何時 RAG、何時微調(diào)模型
多樣化輸出不止提高溫度,改變提示詞中示例的順序也影響結(jié)果
長上下文不會讓 RAG 過時
“實習(xí)生測試”:如果大學(xué)生能根據(jù)提示詞完成任務(wù),說明比較完善了
每個大模型都有自己的偏好,Claude 更喜歡 XML 格式,GPT 系列更喜歡 Markdown 和 JSON
如果靠提示詞已完成了 90% 的任務(wù),微調(diào)可能就不值得投資
大模型當(dāng)裁判評估結(jié)果可能起作用,但不是萬能的
……
總之,無論是大廠工程師、創(chuàng)業(yè)者還是參加個人開發(fā)者,都值得一看。
全程高能干貨分享
提示詞、RAG 和微調(diào)都是改善大模型輸出結(jié)果的有效方法。
但是何時該用何種方法,還沒有定論。
作者們認(rèn)為,需要根據(jù)具體的應(yīng)用場景、任務(wù)需求、成本效益和性能目標(biāo)來做出決策:
建議在開發(fā)新應(yīng)用程序時從提示詞開始
需要大模型掌握新知識時優(yōu)先使用 RAG
當(dāng)需要針對特定任務(wù)優(yōu)化時再考慮微調(diào)
最后,他們還重點討論了對大模型應(yīng)用的評估和監(jiān)測,認(rèn)為是應(yīng)該貫穿開發(fā)全流程的重要環(huán)節(jié)。
提示詞篇
很多開發(fā)者都陷入了一個誤區(qū):以為設(shè)計一個涵蓋一切的“終極提示詞”就能完美解決問題。
就像過去軟件開發(fā)中也有希望一個類或函數(shù)可以完成所有事情的誤區(qū)。
實際情況恰恰相反,隨著需求的復(fù)雜化,這樣的 Prompt 會越來越臃腫,性能反而每況愈下。
那么正確的做法是什么呢?提示詞也應(yīng)該像代碼一樣保持簡潔,以會議記錄總結(jié)場景來說,可以分解為以下步驟:
將關(guān)鍵決策、待辦事項和執(zhí)行者提取為結(jié)構(gòu)化格式
檢查提取的詳細(xì)信息與原始會議記錄的一致性
從結(jié)構(gòu)化詳情生成簡明摘要
通過拆分,每個提示詞都簡單、突出重點且易于理解,更重要的是接下來可以單獨迭代和評估每個提示詞。
比如思維鏈鼓勵 AI 在最終回答之前寫下思維過程,除了“一步一步思考”之外,還可以用一些技巧顯著降低幻覺。
還以會議記錄總結(jié)場景為例,迭代后的提示詞示例為:
- 首先,在草稿中列出關(guān)鍵決策、待辦事項和相關(guān)執(zhí)行者。
- 然后,檢查草稿中的細(xì)節(jié)是否與文字記錄相符。
- 最后,根據(jù)要點合成簡潔的總結(jié)。
在提示詞方面,作者們還提出了更多具體經(jīng)驗。
對于給大模型提供示例的上下文學(xué)習(xí):
提示詞中的示例數(shù)量追求≥5(也不要害怕用上幾十個)。太少會讓模型過度遵循特定示例、損害泛化能力。
示例應(yīng)該反映預(yù)期的輸入分布。比如做電影劇情總結(jié),示例中不同類型電影的比例大致應(yīng)與實踐中期望看到的相同。
不一定需要提供完整的輸入-輸出對。在許多情況下,只有輸出的示例就足夠了。
如果所用的大模型支持工具調(diào)用,則示例也應(yīng)包含希望 AI 使用的工具。
對于結(jié)構(gòu)化輸入輸出:
優(yōu)化上下文結(jié)構(gòu),讓模型更容易理解和處理。單純打包一堆文件人類看著頭疼,AI 看著也費勁。
只保留必要信息,像雕刻藝術(shù)家一樣剔除冗余、自相矛盾和格式化錯誤。
每個大模型都有自己的偏好,Claude 更喜歡 xml 格式,GPT 系列更喜歡 Markdown 和 JSON。
比如給 Claude 的提示詞,甚至可以用 xml tag 來預(yù)填充輸出模板。
RAG(檢索增強生成)篇
不要忘記關(guān)鍵詞搜索
基于 Embedding 的 RAG 演示很多,讓人們?nèi)菀淄浶畔z索領(lǐng)域數(shù)十年來積累的經(jīng)驗。
作者認(rèn)為向量檢索無疑是強大的工具,但不是全部。雖然擅長捕獲高級語義相似性,但它們可能難以處理更具體的關(guān)鍵字,比如人名、首字母縮略詞或者 ID。
不要忘記傳統(tǒng)的關(guān)鍵詞匹配(如 BM25 算法),在大多數(shù)情況下,混合關(guān)鍵字匹配和向量搜索效果最好:
先匹配最明顯的關(guān)鍵詞,再對同義詞、上位概念和拼寫錯誤做向量查詢,以及多模態(tài)向量查詢。
RAG 輸出的質(zhì)量取決于檢索文檔的質(zhì)量
具體來說,檢索文檔的質(zhì)量又取決于幾個因素。
第一個也是最明顯的指標(biāo)是相關(guān)性。與傳統(tǒng)推薦系統(tǒng)一樣,檢索到的項目的排名對大模型輸出產(chǎn)生重大影響,要衡量這種影響,可以試試打亂順序并觀察大模型行為變化。
第二個是信息密度。如果兩份文檔同樣相關(guān),應(yīng)該選擇更簡潔、無關(guān)細(xì)節(jié)更少的那個。
最后是信息的詳細(xì)程度,附加的詳細(xì)信息可以幫助大模型更好地理解。
優(yōu)先 RAG,而不是對新知識微調(diào)
RAG 和微調(diào)都可讓大模型掌握新知識并提高特定任務(wù)的性能。那么,應(yīng)該優(yōu)先選擇哪一個呢?
微軟一篇論文比較 RAG 與無監(jiān)督微調(diào)(又叫持續(xù)預(yù)訓(xùn)練),發(fā)現(xiàn)對于新知識 RAG 性能始終優(yōu)于微調(diào)。
△arxiv.org/abs/2312.05934
除了改進(jìn)性能之外,RAG 容易更新而且成本更低。如果知識庫中發(fā)現(xiàn)錯誤,RAG 方法只需簡單刪除有問題的文檔即可。
RAG 還可以給文檔權(quán)限提供更細(xì)粒度的控制,確保每個用戶只能訪問自己有權(quán)限的文檔,不會泄露信息。
長上下文不會讓 RAG 過時
首先,即使上下文窗口達(dá)到一千萬 tokens,仍然需要一種方法來選擇要輸入模型的信息。
其次,除了簡單大海撈針評估之外,還沒有看到令人信服的數(shù)據(jù)表明模型可以在如此大的上下文進(jìn)行有效的推理。
如果沒有良好的檢索和排名,干擾因素可能淹沒模型,甚至可能用完全不相關(guān)的信息填滿了上下文窗口。
最后還有成本問題,Transformer 的推理成本隨上下文長度二次增長,過度依賴長上下文可能不劃算。
微調(diào)篇
當(dāng)最巧妙的提示詞設(shè)計也無法完成一些任務(wù)時,可能就需要考慮微調(diào)了。
雖然微調(diào)可能是有效的,但它會帶來巨大的成本。必須注釋微調(diào)數(shù)據(jù)、執(zhí)行微調(diào)和評估模型,并最終自行部署模型。因此,請考慮較高的前期成本是否值得。
作者們的經(jīng)驗是:
如果提示詞已完成了 90% 的任務(wù),那么微調(diào)可能不值得投資。
如果確定要微調(diào),可以考慮合成數(shù)據(jù)或開源數(shù)據(jù)集,降低人工收集注釋數(shù)據(jù)的成本。
Agent 與工作流
最成功的 Agent 開發(fā)者可能也是工程師團(tuán)隊的管理者,因為給 AI 制定計劃的過程和管理初級員工的方式類似。
我們給人類新手明確的目標(biāo)和具體的計劃,而不是模糊的開放式指示,對 Agent 也應(yīng)該這樣做。
優(yōu)先考慮確定性工作流程
Agent 被期待動態(tài)對用戶請求做反應(yīng),但隨著執(zhí)行步數(shù)增加,失敗的可能性指數(shù)增加,并且從錯誤中恢復(fù)的機會很小。
一種有前途的方法是使用 Agent 系統(tǒng)來生成確定性計劃,然后以結(jié)構(gòu)化、可重復(fù)的方式執(zhí)行這些計劃,好處包括:
生成的計劃可以作為提示詞中的少數(shù)樣本,或微調(diào)數(shù)據(jù)。
使系統(tǒng)更加容易測試和調(diào)試,失敗可以追溯到計劃中的具體步驟。
生成的計劃可以表示為有向無環(huán)圖 (DAG),相對于靜態(tài)提示詞,它更容易理解和適應(yīng)新情況。
多樣化輸出不止提高溫度
如果任務(wù)需要輸出的多樣性,比如根據(jù)用戶之前購買過的產(chǎn)品推薦新產(chǎn)品,簡單增加大模型的溫度參數(shù)可能會產(chǎn)生問題。
如果溫度太高,可能會生成不存在的產(chǎn)品,甚至輸出亂碼。
其他增加輸出多樣性的方法包括:
最簡單的是調(diào)整提示詞內(nèi)的元素順序,打亂用戶歷史購買記錄的順序,就可能產(chǎn)生顯著差異。
還可以在上下文中保留前幾輪的輸出,并要求大模型避免重復(fù)最近推薦過的產(chǎn)品。
另一個策略是改變提示詞的措辭,比如“選擇用戶喜歡經(jīng)常使用的產(chǎn)品”和“選擇用戶可能會推薦給朋友的產(chǎn)品”。
評估與監(jiān)測
大模型的輸入和輸出是任意文本,要完成的任務(wù)是多種多樣的。盡管如此,嚴(yán)格且深思熟慮的評估仍至關(guān)重要。
從真實的輸入 / 輸出樣本中創(chuàng)建基于斷言的單元測試
作者建議創(chuàng)建由生產(chǎn)中的輸入和輸出樣本組成的單元測試,并基于至少 3 個指標(biāo)測試。
3 個指標(biāo)是實踐中總結(jié)出來的,更少可能表明任務(wù)沒有充分定義,或過于開放。
這些單元測試應(yīng)該由工作流的任何更改觸發(fā),無論是編輯提示詞、通過 RAG 添加新上下文還是其他修改。
大模型當(dāng)裁判可能起作用,但不是萬能的
作者認(rèn)為,讓最強大的模型當(dāng)裁判、給其他模型的輸出打分,用于定性比較優(yōu)劣可能有用,但具體輸贏的幅度就沒什么參考價值了。
不要讓大模型在量表上對單個輸出進(jìn)行評分,而是提供兩個選項,要求選擇更好的一個,這往往會帶來更穩(wěn)定的結(jié)果。
提供的選項順序可能會影響結(jié)果,為了緩解這種情況,請將每個成對比較進(jìn)行兩次,每次交換順序。
在某些情況下,兩種選擇可能同樣好。因此允許大模型宣布平局,這樣就不會武斷地選一個勝者。
使用思維鏈:要求大模型在給出最終偏好之前解釋其決定,可以提高評估的可靠性,還可以讓更小的模型獲得與大模型類似的結(jié)果。
(這部分流程通常處于并行批處理模式,思維鏈帶來的額外延遲并不造成問題。)
大模型往往偏向于較長的回答,為減少這種情況,請確保成對的回答長度相似。
“實習(xí)生測試”
如果將提示詞(包括上下文)作為一項任務(wù),交給相關(guān)專業(yè)的普通大學(xué)生,他們能成功嗎?需要多長時間?
如果大學(xué)生都做不到,就該考慮如何給大模型提供更豐富的上下文資料了。
如果根本無法通過改進(jìn)上下文來解決這個問題,那么這就是對當(dāng)代大模型來說太難的任務(wù)。
如果大學(xué)生能做到,但需要一段時間。可以嘗試降低任務(wù)的復(fù)雜性。分解任務(wù),或某些方面是否可以更加模板化。
如果大學(xué)生能做到,而且很快,但大模型不行。那么就該深入研究大模型反饋的數(shù)據(jù)了。嘗試找到失敗的模式,讓模型在輸出之前或之后解釋自己。
過分強調(diào)某些指標(biāo)可能影響整體
著名的古德哈特定律表示,“當(dāng)一項指標(biāo)成為目標(biāo)時,它就不再是一項好指標(biāo)”。
比如針對長上下文的“大海撈針”測試最早是網(wǎng)友提出的,迅速成為行業(yè)通用方法之后,就很容易針對性優(yōu)化、刷榜。
更好的指標(biāo)可能正是復(fù)雜的實際任務(wù),比如“給定一個小時的會議記錄,大模型能否總結(jié)出關(guān)鍵決策、待辦事項和相關(guān)負(fù)責(zé)人”。
這項任務(wù)更切合實際,超越了死記硬背的范疇,還考慮到了解析復(fù)雜討論、識別相關(guān)信息和歸納總結(jié)的能力。
在總結(jié)中強調(diào)事實一致性可能會導(dǎo)致摘要不那么具體(因此不太可能與事實不一致),也可能不那么相關(guān)。
反之,如果強調(diào)寫作風(fēng)格和口才,則可能導(dǎo)致更多花哨的話術(shù),從而造成與事實不符的情況。
LLMs 甚至?xí)诓粦?yīng)該返回輸出時返回輸出
大模型經(jīng)常會在不應(yīng)該生成輸出的情況下生成輸出??赡苁菬o害但無意義的輸出,也可能是更嚴(yán)重有害輸出。
例如,當(dāng)被要求從文檔中提取特定屬性或元數(shù)據(jù)時,大模型可能會自信地返回不存在的結(jié)果??梢試L試讓大模型回答“不適用”或“不知道”,但也并非萬無一失。
雖然謹(jǐn)慎的提示工程可以在一定程度上起作用,但還應(yīng)輔之以強大的“護(hù)欄”機制,以檢測和過濾 / 重新生成不受歡迎的輸出。
例如,OpenAI 提供了一個內(nèi)容過濾 API,可識別不安全的響應(yīng),如仇恨言論、自殘或性內(nèi)容。同樣,還有許多用于檢測個人身份信息 (PII) 的軟件包。這樣做的好處之一是,”護(hù)欄”在很大程度上與場景無關(guān),因此可廣泛應(yīng)用于特定語言的所有輸出。
此外,通過精確檢索,如果沒有相關(guān)文檔,系統(tǒng)也可以確定地回答 “我不知道”。
在實際應(yīng)用中,最好持續(xù)記錄輸入和輸出,以便進(jìn)行調(diào)試和監(jiān)控。
幻覺很難徹底解決
與安全問題不同,幻覺可能很難被發(fā)現(xiàn)。
根據(jù)作者們從大模型供應(yīng)商那里了解到的情況,要將幻覺率降低到 2% 以下是非常困難的,即使是在摘要等簡單任務(wù)中也是如此。
為了解決這個問題,可以將提示工程(生成的上游)和事實不一致護(hù)欄(生成的下游)結(jié)合起來。
對于提示詞工程,思維鏈等技術(shù)可以讓大模型在最終返回輸出之前解釋其推理,從而幫助減少幻覺。然后,可以應(yīng)用事實不一致護(hù)欄來評估摘要的事實性,并過濾或重新生成。
技術(shù)篇結(jié)束,還有運營、戰(zhàn)略篇
對于這篇精彩的實戰(zhàn)經(jīng)驗分享,沃頓商學(xué)院教授 Ethan Molick 推薦并感慨:
這篇文章顯示了從傳統(tǒng)軟件角度來看,使用大模型是多么奇怪,以及人們還有多少東西需要學(xué)習(xí)。
事實上這只是六位作者完整分享的三分之一:戰(zhàn)術(shù)篇。
第二部分運營篇也剛剛發(fā)布,圍繞數(shù)據(jù)、模型、產(chǎn)品、團(tuán)隊發(fā)展四個話題展開分享。
接下來還有最后一部分戰(zhàn)略篇,也是狠狠期待了。
最后,不妨再來認(rèn)識一下六位作者。
Eugene Yan
他目前是亞馬遜高級應(yīng)用科學(xué)家,負(fù)責(zé)構(gòu)建服務(wù)全球數(shù)百萬客戶的推薦系統(tǒng),并應(yīng)用大語言模型來更好地服務(wù)客戶。
此前,他曾在 Lazada(被阿里巴巴收購)和一家健康科技初創(chuàng)公司領(lǐng)導(dǎo)機器學(xué)習(xí)團(tuán)隊。他在 eugeneyan.com 和 ApplyingML.com 上撰寫并發(fā)表關(guān)于機器學(xué)習(xí)、推薦系統(tǒng)、大語言模型及工程方面的文章和演講。
Bryan Bischof
Bryan Bischof 是 Hex 的 AI 負(fù)責(zé)人,領(lǐng)導(dǎo)工程師團(tuán)隊開發(fā)了 Magic—— 數(shù)據(jù)科學(xué)和分析助手。
他在數(shù)據(jù)領(lǐng)域有豐富的工作經(jīng)驗,曾創(chuàng)建了 Blue Bottle Coffee、Weights and Biases 的數(shù)據(jù)團(tuán)隊,領(lǐng)導(dǎo)了 Stitch Fix 的多個項目,還曾與 O’Reilly 合寫了“Building Production Recommendation Systems”一書,并在羅格斯大學(xué)教授數(shù)據(jù)科學(xué)和分析課程。他擁有純數(shù)學(xué)博士學(xué)位。
Charles Frye
Charles Frye 在加州伯克利獲得了神經(jīng)網(wǎng)絡(luò)優(yōu)化方面的博士學(xué)位。
他通過在 Weights and Biases、Full Stack Deep Learning 和 Modal 的教育和咨詢工作,教授了數(shù)千人從線性代數(shù)基礎(chǔ)到 GPU 奧秘以及構(gòu)建可行商業(yè)模式的整個 AI 應(yīng)用開發(fā)過程。
Hamel Husain
Hamel Husain 是一位擁有超過 25 年經(jīng)驗的機器學(xué)習(xí)工程師。
他曾就職于 Airbnb 和 GitHub 等,參與了 OpenAI 用于代碼理解的早期大語言模型研究,還領(lǐng)導(dǎo)許多受歡迎的開源機器學(xué)習(xí)工具。Hamel 目前是一名幫助公司將 LLM 投入運營加速其 AI 產(chǎn)品開發(fā)的獨立顧問。
Jason Liu
Jason Liu 是一位知名的機器學(xué)習(xí)顧問,在個性化算法、搜索優(yōu)化、合成數(shù)據(jù)生成和 MLOps 系統(tǒng)方面擁有技術(shù)專長。
他曾在 Stitchfix 創(chuàng)建了一個處理每日 3.5 億次請求的推薦框架和可觀測性工具,還曾在 Meta、紐約大學(xué)以及 Limitless AI 和 Trunk Tools 等初創(chuàng)公司擔(dān)任重要角色。
Shreya Shankar
Shreya Shankar 是加州伯克利計算機科學(xué)博士生和機器學(xué)習(xí)工程師。
她曾是兩家初創(chuàng)公司的首席機器學(xué)習(xí)工程師,從零開始構(gòu)建 AI 產(chǎn)品。她的工作重點是通過以人為中心的方法解決生產(chǎn)級機器學(xué)習(xí)系統(tǒng)中的數(shù)據(jù)挑戰(zhàn),研究成果發(fā)表在 VLDB、SIGMOD、CIDR 和 CSCW 等頂級數(shù)據(jù)管理和人機交互會議上。
另外,作者們還計劃舉辦一場線上直播(北京時間 6 月 21 日上午),就大模型產(chǎn)品開發(fā)展開更多分享,感興趣的朋友可以報名了。
閱讀原文
https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-i/
https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-ii/
線上直播活動:
https://lu.ma/e8huz3s6
參考鏈接:
[1]https://news.ycombinator.com/item?id=40508390
本文來自微信公眾號:量子位 (ID:QbitAI),作者:夢晨 西風(fēng)
廣告聲明:文內(nèi)含有的對外跳轉(zhuǎn)鏈接(包括不限于超鏈接、二維碼、口令等形式),用于傳遞更多信息,節(jié)省甄選時間,結(jié)果僅供參考,IT之家所有文章均包含本聲明。