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)化詳情生成簡明摘要
通過拆分,每個提示詞都簡單、突出重點且易于理解,更重要的是接下來可以單獨迭代和評估每個提示詞。
比如思維鏈鼓勵A(yù)I在最終回答之前寫下思維過程,除了“一步一步思考”之外,還可以用一些技巧顯著降低幻覺。
還以會議記錄總結(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。