6位作者來自不同背景，比如有大廠工程師，也有獨(dú)立開發(fā)者，還有咨詢顧問。

但他們的共同之處，是過去一年里一直在大模型之上構(gòu)建真實(shí)應(yīng)用程序，而不只是炫酷的Demo演示，他們認(rèn)為：

現(xiàn)在正是非機(jī)器學(xué)習(xí)工程師或科學(xué)家，也能把AI構(gòu)建到產(chǎn)品中的時候。

在他們的一系列分享中，網(wǎng)友熱議的亮點(diǎn)包括但不限于：

-何時用長上下文、何時RAG、何時微調(diào)模型

多樣化輸出不止提高溫度，改變提示詞中示例的順序也影響結(jié)果
長上下文不會讓RAG過時
“實(shí)習(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)
最后，他們還重點(diǎn)討論了對大模型應(yīng)用的評估和監(jiān)測，認(rèn)為是應(yīng)該貫穿開發(fā)全流程的重要環(huán)節(jié)。

提示詞篇
很多開發(fā)者都陷入了一個誤區(qū)：以為設(shè)計(jì)一個涵蓋一切的“終極提示詞”就能完美解決問題。

就像過去軟件開發(fā)中也有希望一個類或函數(shù)可以完成所有事情的誤區(qū)。

實(shí)際情況恰恰相反，隨著需求的復(fù)雜化，這樣的Prompt會越來越臃腫，性能反而每況愈下。

那么正確的做法是什么呢？提示詞也應(yīng)該像代碼一樣保持簡潔，以會議記錄總結(jié)場景來說，可以分解為以下步驟：

將關(guān)鍵決策、待辦事項(xiàng)和執(zhí)行者提取為結(jié)構(gòu)化格式
檢查提取的詳細(xì)信息與原始會議記錄的一致性
從結(jié)構(gòu)化詳情生成簡明摘要

通過拆分，每個提示詞都簡單、突出重點(diǎn)且易于理解，更重要的是接下來可以單獨(dú)迭代和評估每個提示詞。

比如思維鏈鼓勵A(yù)I在最終回答之前寫下思維過程，除了“一步一步思考”之外，還可以用一些技巧顯著降低幻覺。

還以會議記錄總結(jié)場景為例，迭代后的提示詞示例為：

- 首先，在草稿中列出關(guān)鍵決策、待辦事項(xiàng)和相關(guān)執(zhí)行者。
- 然后，檢查草稿中的細(xì)節(jié)是否與文字記錄相符。
- 最后，根據(jù)要點(diǎn)合成簡潔的總結(jié)。

在提示詞方面，作者們還提出了更多具體經(jīng)驗(yàn)。

對于給大模型提供示例的上下文學(xué)習(xí)：

提示詞中的示例數(shù)量追求≥5（也不要害怕用上幾十個）。太少會讓模型過度遵循特定示例、損害泛化能力。
示例應(yīng)該反映預(yù)期的輸入分布。比如做電影劇情總結(jié)，示例中不同類型電影的比例大致應(yīng)與實(shí)踐中期望看到的相同。
不一定需要提供完整的輸入-輸出對。在許多情況下，只有輸出的示例就足夠了。
如果所用的大模型支持工具調(diào)用，則示例也應(yīng)包含希望AI使用的工具。
對于結(jié)構(gòu)化輸入輸出：

優(yōu)化上下文結(jié)構(gòu)，讓模型更容易理解和處理。單純打包一堆文件人類看著頭疼，AI看著也費(fèi)勁。
只保留必要信息，像雕刻藝術(shù)家一樣剔除冗余、自相矛盾和格式化錯誤。
每個大模型都有自己的偏好，Claude更喜歡xml格式，GPT系列更喜歡Markdown和JSON。