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

但他們的共同之處，是過去一年里一直在大模型之上構建真實應用程序，而不只是炫酷的Demo演示，他們認為：

現在正是非機器學習工程師或科學家，也能把AI構建到產品中的時候。

在他們的一系列分享中，網友熱議的亮點包括但不限于：

-何時用長上下文、何時RAG、何時微調模型

多樣化輸出不止提高溫度，改變提示詞中示例的順序也影響結果
長上下文不會讓RAG過時
“實習生測試”：如果大學生能根據提示詞完成任務，說明比較完善了
每個大模型都有自己的偏好，Claude更喜歡XML格式，GPT系列更喜歡Markdown和JSON
如果靠提示詞已完成了90%的任務，微調可能就不值得投資
大模型當裁判評估結果可能起作用，但不是萬能的
……
總之，無論是大廠工程師、創(chuàng)業(yè)者還是參加個人開發(fā)者，都值得一看。

全程高能干貨分享
提示詞、RAG和微調都是改善大模型輸出結果的有效方法。

但是何時該用何種方法，還沒有定論。

作者們認為，需要根據具體的應用場景、任務需求、成本效益和性能目標來做出決策：

建議在開發(fā)新應用程序時從提示詞開始
需要大模型掌握新知識時優(yōu)先使用RAG
當需要針對特定任務優(yōu)化時再考慮微調
最后，他們還重點討論了對大模型應用的評估和監(jiān)測，認為是應該貫穿開發(fā)全流程的重要環(huán)節(jié)。

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

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

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

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

將關鍵決策、待辦事項和執(zhí)行者提取為結構化格式
檢查提取的詳細信息與原始會議記錄的一致性
從結構化詳情生成簡明摘要

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

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

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

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

在提示詞方面，作者們還提出了更多具體經驗。

對于給大模型提供示例的上下文學習：

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

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