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