這次不是文章，是OpenAI的talk，乾貨滿滿。
直接把在飛書文檔上記的筆記當過來了。
------------------------------------------
找到問題；如何解決它；用什麼tools
優化LLM很困難
- 很難分離信號和噪音，找到問題“是什麼”
- LLM表現抽象且難以衡量，不知道問題“有多大”
- 很難知道何時用何種方法解決問題
優化LLM性能並不總是線性的：RAG和Fine-tuning解決了不同的問題，有時需要其中一個，有時需要兩者
- 上下文優化：模型需要知道什麼
- LLM優化： 模型需要如何行動（採取什麼方法）
優化流程
經典流程從Prompt engineering開始：
有了prompt，對輸出進行一致評估：這是context問題還是LLM行動問題？
需要更多相關上下文 -> RAG；
需要更一致的指令遵循 -> Fine-tuning；
或者兩者兼有。
- 有了prompt，創建評估，找到基線；
- 爲模型提供幾個輸入-輸出示例，說明你希望模型如何行動；
- 這些少量示例大大提升了模型性能，連接知識庫使該過程工業化 => RAG；
- 現在有了相關上下文，但模型並沒有以我們想要的格式/風格輸出，微調模型 => Fine-tuning；
- 檢索效果不好，需要內容與模型需求更加相關 => 優化RAG；
- 用RAG引入的新示例再來微調模型。
Prompt engineering
Prompt成功案例
通過prompt告訴模型我們想要如何行動，但我們往往不知道哪些token對模型是最有效的。
好的開始方式是展示而不是講述問題：提供少量示例（輸入-輸出對），並展示希望模型做出的反應。
希望可以工業化，few-shot示例能夠基於用戶需求，基於問題的上下文
RAG
這裏用了個考試的例子很有意思：prompt提供完成考試需要的指示，微調學到的是回答問題的方法論，RAG就是開卷。如果模型知道方法論，知道它要找什麼，RAG讓模型可以打開書本，翻到正確的書頁並提取需要的內容。
適用於爲模型引入新的知識。
減少幻覺：提供上下文內容，並告訴模型只用上下文內容而不是先前的知識來回答問題。
讓模型去學新的語言、格式等等，更多是微調做的事情（學習方法論）而不是RAG。
RAG成功案例
RAG pipeline + LLM + 兩個知識庫，需求：獲取用戶問題，決定用哪個知識庫，發起查詢並用它回答問題。
45% baseline
簡單的檢索
=> 65% （20次迭代）
HyDE對有些用例很有用，有些不行；
FT嵌入層效果好，但貴且慢；
分塊&嵌入，嘗試不同大小的信息塊，嵌入不同的內容；
=> 85%
Reranking用交叉編碼器對結果重新排序，或使用基於規則的內容（想要最新的內容）；
Classification讓模型對這兩個域進行分類，根據被分到哪個類，在prompt中提供額外的元數據；
=> 98%
進一步PE，更好地設計prompt
查看做錯的問題類別，引入tools（從文檔中提取結構化數據：SQL tool輸入變量執行查詢，返回結構化數據答案
Query expansion 一起問了多個問題，把問題解析爲查詢列表，並行執行，合成答案
整個過程沒有用到微調，此處要解決的每個問題都是context：要麼沒有給正確的上下文，要麼模型不知道哪個上下文塊是正確的。知道自己要解決的問題是什麼，是非常重要且必要的。
RAG反面教材
需求：減輕幻覺，只用知識庫內容。有人類檢查並標記幻覺。
如果告訴模型只用上下文內容，但搜索效果不好，那麼模型很難得到正確答案。
評估RAG時，實際上也在評估可能出錯的其它整個軸：LLM、搜索……
RAG開源評估框架
Ragas分解了不同的評估指標，可以開箱直用或根據自己的需求調整。
有四個評估指標，其中兩個衡量LLM問題回答得有多好，另兩個衡量上下文與問題的相關程度。
LLM生成指標：
忠誠度 - 把回答分解成事實，把每個事實和內容對比，如果不相符即爲幻覺（返回的數值高於閾值）
回答相關度 - 有時模型充分利用得到的內容給出答案，但與用戶的問題無關（需要讓模型決定是否用某個內容）
內容檢索指標：（對客戶最有用）
並不是給模型的上下文chunks越多效果就越好，內容越多反而越可能會出現幻覺/忘記中間的內容（lost in the middle），我們只需要精確的上下文片段，用更少的內容獲取正確答案。
上下文精度 - 該指標評估檢索內容的信噪比，獲取每個內容塊並與答案比較，看答案中是否使用了該內容（判斷上下文更多能否帶來幫助）
上下文召回率 - 能否檢索到答案需要的所有相關信息，如果這個值低，說明需要優化檢索（增加reranking、FT嵌入層、嘗試不同的嵌入等）
微調
Def. 用現有的訓練過的模型，在更小的、領域特定的數據集上繼續訓練，來完成特定的任務
優點
和PE能打包到模型上下文窗口裏的token相比，微調過程中能爲模型展示更多的例子，實現更好的性能；
不用在提示中提供複雜的說明、上下文例子，每個提示發送的token更少，因此更便宜&高效；
微調通常是把較大模型的知識蒸餾到較小模型，和較小模型交互通常也會更加高效。
微調無需複雜指令、上下文學習或顯式模式
微調適合：
- 獲取基礎模型中已經存在的知識，並強調其中的一個子集；
- 修改/自定義模型輸出的結構或語氣（如JSON）；
- 在微調過程中可以給模型展示更多示例，因此可以教會模型複雜指令。
微調不適合：
- 向模型添加新知識
- 快速迭代新用例（微調是相對慢的反饋循環，不要從它開始）
微調成功案例
需求：輸入自然語言的設計mock描述，讓LLM輸出一組結構化的設計指南，來生成full-sized mock呈現給用戶
爲什麼微調有效？1. 不需要新的知識，需要具體的結構輸出 2. 有高質量訓練數據，有好的baseline來比較評估，瞭解微調目標
微調反面教材
需求：用AI充當寫作助手
問題：模型撰寫的文章沒有捕捉到特定的語氣（博客、社媒帖、email）=> 微調
收集了140k條Slack數據 - 格式化爲與微調兼容的格式 - 微調模型
需要考慮微調所選用的數據是否真的複製了想要模型作出的行爲
可行的是先用一兩百條Slack數據在模型上微調實驗，看它是否朝着期望的方向前進
如何微調
- 獲取數據集（下載開源數據集，在私人市場上購買數據，付費人工標記員，從更大模型蒸餾），收集、驗證、格式化
- 訓練，需要理解訓練過程中調整的超參數和它們對模型的影響，理解損失函數是否和不同下游任務的性能相關（比如功能性代碼片段可能會有多種實現方式，如果是next token prediction和精準token匹配，就會效果不好）
- 評估模型（聘請專家對輸出排名、採用不同模型的輸出並互相排名、用更強大的模型對輸出排名）
- 部署並進行推理（可以從推斷中採樣，構建新的數據集，進一步微調，和前兩步形成反饋循環）
Start small，開發一個小型高質量數據集，進行微調，評估模型，查看是否在朝着正確的方向前進（微調時查看輸出，瞭解它在哪些領域陷入困境，用新數據專門針對這些領域）
數據質量勝過數據數量，專注於更少的高質量數據
Fine-tuning + RAG
微調省去複雜指令和few-shot示例，節省了提示中的token，因此有更多空間留給檢索上下文
應用
Text-to-SQL：給定數據庫模式，從自然語言生成SQL查詢並回答問題
上下文檢索：簡單過濾，對收到的問題難度進行排名，在RAG中只帶回同等難度的示例
自我一致性檢查：構建並執行query，如果模型搞砸了會給它錯誤信息+一點註釋，然後再試一次（讓GPT自我修復）
PE - few-shot learning - HyDE - 增加示例 - 微調
